Tera Bit,
>> Is there anything intrinsic to DWDM which would prevent the ATM forum from building a transmission convergence sub-layer to it? <<
You bring up a good point which was on my mind during my last post to you, but seemed too far afield at the time. But no, there is no reason why ATM couldn't be mapped directly to lambda, no more than IP or GE over lambda, which are both being done.
A concern up until recently has been the ability to economically "concatenate" ATM payloads of lower orders into an envelope at the upper throughput OC-48c, since previous state of the art was limited to that of the OC-12c. It would hardly be worth it at the OC12c, but becomes more economically feasible at 48 and above rates in point to point applications.
Whether, or should I say just when, it's feasible to concatenate at 192, I believe will remain to be seen. Someone else chime in here, please, if this notion is now already dated, but I feel fairly confident that we're not there yet.
As with Packet over SONET, and packet over DWDM-derived lambda directly, this technique would be limited to all but the densest routes on an express basis.
For example, it would facilitate very nicely the aggregated ATM traffic from San Francisco to Miami direct, with no local stops in between at the current time.
Not until optical techniques are perfected to allow for optical drop and insert or routing methods, such as would be made possible by as-yet-unperfected means, possibly facilitated at some point in time by discretely tunable lasers at intermediate mesh points. Anyone having information in this area, please speak up.
At the present time, it's limited IMO to point-to-point applications, for all intents and purposes, if we stay with the premise that we are not going to use back-to-back breakout boxes at every node. The latter technique of using physical breakouts is what we're trying to get away from, though, as it would just defeat the purpose of taking the x over lambda approach, in the first place.
As you can see, then, at the current time the x over DWDM approach differs from that of normal ATM and IP networking schemes, in which one of their major strengths is the ability to switch and route cells or packets at intermediate points, in transit, or at any node in a network. Rather, it is like a home run at this time, straight to the seats.
>>The prevailing wisdom by many smart people is indeed, that the "ongoing improvements in class-of-service (CoS) and QoS characterizations in IP", will obsolete ATM. The argument, as you well know is that the ATM cell tax is inefficient. <<
Two things. First, I'd apply that general obsoleting rule primarily to those applications (routes) for the time being that are intrinsically IP, or where the mix of traffic precludes such things as unenlightened voice, or SNA, or any of hundreds of other proprietary flavors of networking situations that still require access and transport. I don't think that anyone would argue that the latter still favors ATM, where route aggregation is concerned.
Secondly, the tradeoff between which is better or worse, the cell tax in ATM, or the underutilized "head room" required for IP transport in an un-prioritized environment, is arguable. It does not yield the same conclusion in every networking application, sometimes yielding wide disparities depending on traffic mix, and is best assessed on a case by case basis. I invite feedback on this, as I do re: any other point being made here.
>>the efforts of the DiffServ/RSVP working groups may eventually provide acceptable QoS to IP.... they are just moving the "complicated" signalling mechanisms of ATM up the protocol stack.<<
See my comments to a later poster yesterday, wherein I assign some of this to diplomacy. [g] But yes, you're absolutely right about this. And I am not the one to say that this isn't the way to go. I see some merit in it, in other words. I like to think of this as the Andreesen effect, referring to the impact of the browser vis a vis the then state of the art text based Internet interface. Wherein, great improvements are achievable to an otherwise drudgerous task, in an apparently simplified manner.
The alternative would be to have kludgy gateways in place, to effectively do the same thing, at greater cost and complexity.
>> When do you (or anyone) expect their efforts to be deployed(and functioning)in a ILEC, CLEC, or ISP network?<<
Perhaps Curtis B. or others are looking in, who could give us a better insight into this. I don't know. Cisco has some ideas on how to effect this, as I'm sure others do as well, in their blueprints. Making it soup is another story, though.
The ongoing work being done in RSVP alone has been exhausting, and to a great deal disappointing. Perhaps there are fewer obstacles and more incentives at this time to introduce these later tools. I too would like to know the answer to that question. Anyone?
Regards, Frank Coluccio |
