The MPLS WG Archive

["Feng, Mark" <m_feng@trillium.com>]

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?  
> 
> 
> 
> 
> 
> 
>