Subject: MPLS Architecture Issue

From: Eric Gray <[email-masked]>
Date: Thu, 22 Jun 2000 13:45:37 -0700

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

---

From: Jonathan Lang <[email-masked]>
Date: Thu, 22 Jun 2000 15:06:43 -0700

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:[email-masked]]
> 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),
>

---

From: Theimer Thomas <[email-masked]>
Date: Mon, 26 Jun 2000 10:17:58 +0200

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
> From:	Eric Gray [SMTP:[email-masked]]
> Sent:	Thursday, June 22, 2000 10:46 PM