AHhaha, [and Sector], this architecture does not avail itself to generalizations, the way you depict. Upon closer inspection, there appear to be three super headings of delivery possible by CLECs and other startup providers (and enterprise managers, more on this below), primarily, and at first, since the ILECs have been loathe, up to this time, to make them available from the start.
The three super headings of service offerings, IMO, will be:
(1) Purely Optical [lambda only]
(2) Standards-based data only [GE, ATM, IP, POS, etc.]
(3) Hybrid. [lambda + GE, ATM, IP, POS, etc.]
The Metro devices may be purchased by either the large end user who has dark fiber in place, or by established service providers. The options cited above may be supported by either group. But I'll focus here on the service provider perspective, since this will be the case in the majority of situations.
Most implementations, IMO, will initially fit the first two categories, where there is pent up demand already (again, this is partially because the incumbent carriers don't support them), with special requirements demanding of the third, but in a more limited sense, initially.
One such application that fits category 3, due to its being entirely missing from the mix for some reason (probably because it's not all that trendy these days, but one which nevertheless could be a big winner), IMO, is that of IBM's f-o- based ESCON connectivity.
ESCON is used for main frame local channel-class attachments, and it replaced what used to be the bus and tag channel adapter. Often, in order to reach local and remote processing centers within metro distances, users currently use either T-1, or T-3 or OC-3 thru OC-12 leased lines. OR they may elect to use proprietary whole fibers where distances and other cost factors (both financial costs, and route allocation costs) permit. [[A third, and probably more influential, inhibitor here to dark fiber is its lack of apparent availability, generally, and the hassle that it represents to the unknowing data center administrator, as to the ways of the "real" street-wise, and the wild.]]
Here, a user may elect to go with a purely optical delivery from the Metro box, using an Option 1 lambda to support their ESCON requirements. If the customer also needed GE connectivity, they may additionally go with the Option 2 MetroEdge device that satisfies this. They collectively wind up with Option 3, i.e., the hybrid delivery, where they have access to both Option 1 lambda [to satisfy ESCON) and an Option 2 standards based data link (to satisfy GE).
-------------------------------
When the delivery is purely optical (lambdas), many of your stated concerns about the use of caching and load management are highly relevant, but they go away, as they are the purview of the end user, and not that of the provider, in this case. The user in this instance is simply getting an optical pipe of near-infinite capacity (for all intents and purposes, ordinarily) mapped between multiple locations, or on a point-to-point basis, and what they (the sub) do with those pipes is ordinarily of no concern to the carrier. As it should be in this case.
On the other hand, when the protocol-specific (or multi-protocol) Metro Edge devices are used, then it becomes a function of normal networking parameters and tuning for the chosen protocol suite vis a vis user traffic profiling.
The jurisdictional divides and areas of responsibility are not constant here, since these are normally sorted out in a service level agreement between the provider and the user on a case by case basis. On that basis it is decided what part of the whole the carrier or service provider is guaranteeing, and what part the customer will maintain.
The jurisdictional issues will become interesting here, since a large percentage of uptake for this product will likely be to other SPs of varying persuasions. These will probably require and demand total and autonomous control of their own fate, and they will have proprietary interests at stake, often in competition with those providing the lambdas.
------------------------------------
Buffers and cache sizes do come into play, as you state, but these are normal features and characteristics of the specific boxes (of whose ever manufacture) that will be used in the OEM/integration process. These are normally tweaked, optioned or selected wholesale to suit a wide ranges of potential loads, performance criteria, etc., at the time of design or implementation. Sizing is often approximated during the design stage, but proper sizing of cache is almost always achieved after iterative testing in the real life environment.
So, here, too, your concerns are further reduced by proper design and configuration, aided by actual test and measurement at the time of installation, during which time maximum potential load simulations may also be performed.
The individual service provider (unless they have partial or full outsourcing responsibilities from design through delivery) is not the party who sets performance standards for the user, nor are they the ones who specify the configuration to handle the issues you cited.
User traffic management is the domain of the enterprise network group, unless they elect to toss it to the carrier in an partial or total outsourcing deal.
Once the lambda connection has been created, then it is possible to establish a business as usual format, from the carrier's perspective, only in a more economically appealing way for the provider. Which, hopefully, is passed along to the consumer or enterprise for reasons having solely to do with competitive pricing advantage.
-------------------
I think that the company was clever in couching this architecture in the classification of being one that is primarily an optical one.
In reality, and in its ultimate form, it is actually a data networking framework, which if fully deployed with all options, leaves the user absent of any optical interfacing, to speak of. But the attention grabber is its DDWDM, which has the cachet needed, and for this reason is, I'm sure, exactly what marketing wanted to convey. Clever, wouldn't you say?
Comments welcome.
Regards, Frank Coluccio |
