The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS Architecture Issue
Sorry, Playing catch-up and my previous mail on this subject lags behind the discussion... The bi-directionality in draft-lang-mpls-rsvp-oxc provides a good model for bi-directional LSPs in optical and non-optical networks. In a network built on ATM hardware it is also necessary to know whether the full bi-directionality of the switching will be used since it is often possible to reserve resources in such hardware in a uni-directional sense. Such function will also require an extension to the signaling protocol (or carnal knowledge amongst the switches) and draft-lang-mpls-rsvp-oxc could provide such a mechanism (although is perhaps heavy handed for this use). Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Jonathan Lang [mailto:jplang@calient.net] >Sent: Thursday, June 22, 2000 11:07 PM >To: 'Eric Gray'; Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric >Rosen' >Cc: Thomas D. Nadeau (E-mail); 'MPLS Mailing List' >Subject: RE: MPLS Architecture Issue > > >Eric, > >There were two drafts presented at the last meeting in Adelaide that >proposed bi-directional LSPs (draft-lang-mpls-rsvp-oxc-00.txt and >draft-saha-rsvp-optical-signaling-00.txt). These were >primarily a result of >optical constraints, but there is no reason they couldn't be used for >regular LSPs. > >Jonathan > >Calient Networks > >> -----Original Message----- >> From: Eric Gray [mailto:EGray@zaffire.com] >> Sent: Thursday, June 22, 2000 1:46 PM >> To: Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric Rosen' >> Cc: Eric Gray; Thomas D. Nadeau (E-mail); 'MPLS Mailing List' >> Subject: MPLS Architecture Issue >> >> >> Eric (et al), >> >> Tom earlier made the point that none of the >> MPLS drafts appear to introduce - let alone >> discuss or specify - the notion of bi-directional >> association of LSPs. There is the notion of use >> of Labels under circumstances in which specific >> hardware uses "labels" (VPI/VCI, and possibly >> DLCI, values) in both directions, but this is not >> the same thing. >> >> In an off-line discussion, we talked about the >> fact that the TE Requirements RFC (RFC2702) talks >> about the idea of bi-directional traffic trunks. >> It describes behaviors which might be hard for an >> NMS to model without being able to determine that >> an LSP-pair is used as a bidirectional LSP tunnel. >> But it is "only" an informational RFC. >> >> The Framework draft briefly mentions use of >> bi-directional LSPs as a possible solution to error >> reporting problems, but - as far as I know - none >> of the current set of "standards track" MPLS drafts >> addresses the concept of pairing of LSPs to form a >> bi-directional tunnel or trunk. >> >> Is it possible to add this to the Architecture >> at this point, do we need to create a standards track >> draft specifically for this purpose or is it enough >> to simply add appropriate "stuff" to the TE-MIB based >> on the informational RFC? >> >> -- >> Eric Gray >> >
|
|