Subject: Re: Question regarding bi-directional connection set up - And Port-ID in Label object

From: Yangguang Xu <[email-masked]>
Date: Thu, 15 Mar 2001 10:06:55 -0500

Fong,

> 
> Regarding how to encode the bi-directionality request,
> Removal of upstream label prevents pre-program the
> cross-connect, not desirable in some situation. So I would
> be in favor of keeping the upstream label object.
> 

I wasn't suggesting to get rid of upstream label (the concept). I proposed to
merge it with suggested label, label set into a single suggested label set
object. I gave reasons in my ID (draft-xu-ccamp-gmpls-sig-reorg-00.txt). A NE
should be able to specify labels of both directions for bi-directional LSP in
optical network. 

Thanks,

Yangguang

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 15 Mar 2001 16:31:09 +0100

Fong,

>    "An example of bundling is inverse
>    multiplexing, it is useful when a higher order signal needs to be
>    transported over a number of lower order signals, e.g. when a 10Gbps
>    signal must be transported over four 2.5Gbps signals. In that case,
>    the lower order signals must follow exactly the same path, and be
>    treated in the same way, in order to achieve the same characteristics
>    (e.g. delay). To support inverse multiplexing, a request is made to
>    open in parallel and in one single operation several LSPs at the same
>    time."

The above text is not aligned with today's transport layer capabilities
in SDH/SONET. VC-n/STS/VT virtual concatenated signals must NOT follow
exactly the same path, they may do so. The recent defined VC-n-Xv LCAS
(link capacity adjustment scheme) assumes that the group of X VC-n
signals is routed over at least two diverse routes. The need to co-route
all members of the group depends mainly on the differential delay that
the virtual concatenation egress point can accomodate. If it is very
low, you better co-route all signals. Otherwise, co-routing is not
necessary as long as the differential delay is less than the maximum
differential delay that the endpoint can compensate.

Regards,

Maarten

---

From: ietf <[email-masked]>
Date: Tue, 20 Mar 2001 14:22:31 -0700

Yangguang,

    I'm not sure that merging them is the right thing to do.
They do not represent the same thing.  I believe the
suggested label is the label the upstream would like the
downstream to assign/recognize while the upstream label
(I believe) is the label that the upstream _has_ assigned
for the use of the downstream in a corresponding reverse
LSP.

    There are two problems with trying to force the two to
be the same:

o    one is being assigned and the other is being requested
      (assignment may not occur as requested), and
o    it is not always the case that the same label can be
      assigned, in both directions, and associated with the
      two halves of the same bi-directional LSP.

--
Eric Gray

---

From: Yangguang Xu <[email-masked]>
Date: Mon, 26 Mar 2001 09:37:23 -0500

Eric, 

> for the use of the downstream in a corresponding reverse

I agree with your understanding. However, one of the key differences between
layer 1 transport network and IP network is data traffic direction is not
related to connection creation direction in transport network.

For example,  A----B----.....----F----G
(1) A uni-directional (user-traffic from A-->G) light path can be initiated
either by A or G
(2) So does a bi-directional light path

So, in layer 1 transport network, downstream/upstream is according to signaling
direction in control plane. It should have nothing to do with user plane
traffic.

Suggested label, upstream label ... are used to specify which trib to use for
light path. What we need to have is directionality attribute for label.

>       (assignment may not occur as requested), and

In layer 1 transport network, label is bound to certain physical resource.

Upstream label is only useful for a bi-directional LSP in a network where ports
are uni-directionally identified.

If all ports are uni-directional, this shouldn't happen. Label should
directionality attribute. 

>       two halves of the same bi-directional LSP.

Directionality should be one attribute for "bundling". Transmit ports, receive
ports and bi-directional ports can be assigned to different bundles, with unique
bundle ID.

Source node should choose the correct bundle ID for the connection it desires.

Regards,

Yangguang