The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Jan> msg00055



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RSVP-TE Label Merge Question

  • From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
  • Date: Wed, 9 Jan 2002 12:15:35 +0530

Title: RE: RSVP-TE Label Merge Question

Hello Feng & Scott

  When LSR1 receives a label request and since it is
  merge capable router. It doesn't send the request
  further to LSR2 since it has already label from the
  LSR2 and for the same session, and reply with the label
  mapping message with the new label.
  Note that at LSR1 the outsegment will have label L2
  for both insegment table.

  Please correct me if i am wrong.


Ashwin
 

-----Original Message-----
From: Feng, Mark [mailto:m_feng@trillium.com]
Sent: Wednesday, January 09, 2002 1:03 AM
To: 'Milk, Scott'; 'mpls@uu.net'
Subject: RE: RSVP-TE Label Merge Question


Actually, LSR2 cannot issue the same label to LSR1 for the exact reason.
This is mentioned in RFC3031. The idea is that the LSR cannot have a coarser
granularity than its downstream node.

Hope this helps.

- Mark

> -----Original Message-----
> From: Milk, Scott [mailto:Scott.Milk@marconi.com]
> Sent: Tuesday, January 08, 2002 9:53 AM
> To: 'mpls@uu.net'
> Subject: RSVP-TE Label Merge Question
>
>
>
> What happens to an allocated label for a second sender part
> of a session
> when the two sender label streams were merged somewhere upstream?
>
> Take the following example.  LSR1 interface to LSR2 IS merge
> capable.  LSR2
> interface to LER3 IS NOT merge capable.  LER1 and LER2 will
> both request
> connection to LER3 and are 2 senders of the same session.  Assume all
> criteria for merging traffic are met.
>
>   -LER1--
>          \
>          LSR1--LSR2--LER3
>   -LER2--/
>
>        LSR1     LSR2
>       ------   ------
>       Lx->L2   L2->L1
>       Ly->L2   L2(?)->L3
>
> LER1 establishes LSP to LER3.  LER3 provides LSR2 with label L1.  LSR2
> provids LSR1 with label L2.  When LER2 as a 2nd sender of the
> same session
> requests the connection, LER3 includes a different label L3
> for the second
> sender in RESV to LSR2 as LSR2 is not merge capable.  LSR2
> knowing that LSR1
> is merge capable issues the same label (L2) to LSR1 for both senders.
>
> So my question is, what happens to label L3 between LSR2 and
> LER3?  Clearly
> since the traffic is merged at LSR1, it will never be used. 
> This could be a
> problem for any number of consecutive non-merge capable links
> that follow a
> merge capable one.  Obviously this problem only effects
> non-merge ATM links
> so is this considered an insignificant problem? 
>
>
>
>
>
>
>

--------------------------------------------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please notify the
originator of the message.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Huawei Technologies India Pvt. Ltd.