[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Yangquang

The one reason I think the port-id/label combination makes
sense is in the bundling/inverse multiplexing example given
in generalized-signaling-02.txt and quoted below.

   "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."   

However, I do not see other mechanisms that allow specify multiple 
links for this purpose. If we only need one set of object, 
the combination of port-id and label is less convincing, IMHO.  
I could also be missing other mechanisms that already address this, 
would appreciate a pointer.

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.

Regards,
-Fong

>  -----Original Message-----
>  From: Yangguang Xu [mailto:xuyg@lucent.com]
>  Sent: Wednesday, March 14, 2001 1:31 PM
>  To: Fong Liaw
>  Cc: ccamp@ops.ietf.org; mpls@uu.net
>  Subject: Re: Question regarding bi-directional connection set up
>  
>  
>  Fong,
>  
>  I totally agree with you that bi-directional LSP for 
>  SONET/SDH network is a
>  must. The issue is how to support it.
>  
>  It's useful to see how SONET/SDH NEs' ports are identified 
>  first. It is
>  different from IP router, which always use bi-directional 
>  interface ID (no
>  matter IP addressed or unnumbered). Some vendors identify 
>  the physical port
>  bi-directionally. (Port ID xxx actually indicate two 
>  physical ports, one IN, one
>  OUT). Other vendors identify the physical port 
>  uni-directionally. (transmitter
>  and receiver have different Port ID)
>  
>  This has two implications:
>  
>  (1) Label has directionality
>  (2) For SONET NEs whose port are bi-directionally 
>  identified, no upstream label
>  is needed for bi-directional LSPs
>  
>  Take a step further, Upstream label is not necessary at all. 
>  For optical
>  network, link connection creation direction is independent 
>  from the user traffic
>  flow direction (Here is where IP network is different from 
>  optical network).
>  When  A-----B want to set up a bi-directional link, either A 
>  or B can choose
>  which ports to use.  
>  
>  Regarding whether or not port ID should be part of the 
>  label. I think it should.
>  Port ID can be in the ERO but I don't think that's the good 
>  place because:
>  
>  (1) ERO is the result of source node source routing. It is 
>  in bundle ID
>  granularity. (a bundle ID is assigned to a collection of 
>  physicall ports that
>  share the same routing significance).
>  
>  (2) PortID + channel/subchannel ID is a meaningful unit. 
>  Breaking them into
>  pieces doesn't make sense
>  
>  All details can be found in 
>  
>  http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-
reorg-00.txt

Regards,

Yangguang  



>  > Yangquang
>  >
>  > I read your draft which puts port id in lable object
>  > and probably upstream label as well.  Do you not consider
>  > allowing asymmetric link for a connection a problem,
>  > in particular for SONET/SDH ?
>  >
> I think the rational of providing bi-directional LSP
> really should be enhanced to not just an optimization,
> but a MUST for SONET/SDH etc.