The MPLS WG Archive

[Sanjeev Rampal <srampal@cisco.com>]

Even if we only care about IP clients,  other issues (stemming from
the fact that ATM switches can peer into per-packet (cell)
headers, do merge operations etc) could impact the peer versus
overlay issue perhaps differently in the ATM than in the optical case ...

Grenville Armitage wrote:

> darren.freeland@bt.com wrote:
>         [..]
> > ATM is not the OTN.
>
> When MPLS first burst onto the ATM scene, there was much talk of being
> able to run ATM switches in a ships-in-the-night mode, partitioning
> the VCI/VPI space into blocks for allocation by PNNI and LDP(et al).
>
> The analogy with IP/ATM is pertinent in so far as we all thought ATM
> networks would be primarly built for other 'telco' services (migrating
> across from wherever...) and that IP would be just another client.
> For some ATM installations this was no doubt quite true, and the
> 'overlay' model a compelling solution. Yet for those people buying
> ATM gear primarily to haul IP traffic around their region(s), it
> seemed equally likely that optimizing the ATM control plane for a
> single 'client' (IP) was acceptable.
>
> I'm not sure it is constructive to insist there is an absolute
> either/or case to be made for IP/optics. Certainly for work coming
> out of the IETF environment it is hardly surprising the focus is
> on IP as the client layer. But this isn't the same as saying an
> OTN must be built as the IETF wants it. Ships-in-the-night is
> still feasible on boxes that switch lamdas, timeslots, ...
>
> cheers,
> gja
> ________________________________________________________________________
> Grenville Armitage                    http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley