The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh
Bala, I think that there's a big difference between the service interface offered to a user (aka the front end) and the interface that a service device uses to attach to the rest of the network (aka the back end). There's no reason why the back end couldn't be GMPLS in peer mode even if the front end was something silly like ATM UNI. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Thursday, October 19, 2000 9:42 AM To: John Drake Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com |
|