The MPLS WG Archive

[Theimer Thomas <Thomas.Theimer@icn.siemens.de>]

Eric,

I also think it would be useful to address this issue in some more detail (at least) in the architecture document. In my view, there are two different cases of bi-directionality:

1. specific hardware (e.g. ATM, FR, most optical transport networks) may allow or require bidirectional communication to be established using MPLS. Both directions usually follow the same path through the same set of nodes, and each node along the path is aware of this association. This is addressed e.g. in draft-lang-mpls-rsvp-oxc-00.txt and draft-saha-rsvp-optical-signaling-00.txt for optical networks.

2. specific applications of MPLS may require a bidirectional communication path provided by MPLS. For this purpose, it may be sufficient to create a pair of unidirectional LSPs which are only bound together by the ingress/egress nodes. For intermediate nodes, the two LSPs are unrelated, and they may even follow different paths across the network. However, the application only works if both LSPs are up. One such application would be Tunneling Multiplexed Compressed RTP in MPLS as described in draft-theimer-tcrtp-mpls-00.txt.

So the MPLS architecture should address that

- a pair of unidirectional LSPs can be bound together to provide a bidirectional communication path

- forward and reverse direction may share the same path, either because the hardware technology works that way or because it is required in a specific application.

We should also make clear which of the cases we are talking about when referring to bidirectional LSPs.

Thomas
> -----Original Message-----
> From:	Eric Gray [SMTP:EGray@zaffire.com]
> Sent:	Thursday, June 22, 2000 10: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