Subject: RE: RSVP-TE Label Merge Question

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Wed, 9 Jan 2002 12:15:35 +0530

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:[email-masked]]
Sent: Wednesday, January 09, 2002 1:03 AM
To: 'Milk, Scott'; [email-masked]'
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:[email-masked]]
> Sent: Tuesday, January 08, 2002 9:53 AM
> To: [email-masked]'
> 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.

---

From: David Charlap <[email-masked]>
Date: Wed, 09 Jan 2002 10:39:58 -0500

Ashwin C. Prabhu wrote:
> Feng, Mark wrote:
>> Milk, Scott wrote:
>>>
>>> What happens to an allocated label for a second sender part of a
>>> session when the two sender label streams were merged somewhere
>>> upstream?
>>>
>>> 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.
>>>
>>> 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?
>>
>> 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.
> 
> 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.

You are describing LDP operation, not RSVP-TE.

Unless I've been missing something fundamental for the past two years,
an RSVP Path message must propagate all the way to the egress router
(except when WF-style reservations are used, which is not applicable for
MPLS).

This means that the LABEL_REQUEST object goes all the way to the egress.

The way I see it, if LSR1 decides to merge the two LSPs, then the labels
assigned by LSR2 and LER3 for one of them will be wasted.

The solution to the wastage is for LSR2 and LER3 to also assign the same
label for the two LSPs, but the question then becomes how they know that
they should do this.  In this case, it doesn't matter that LSR2 and LER3
are not merge capable - one the data plane it's still one label in, and
one label out.  But their choice to do this will fail if LSR1 is not
merge capable.

-- David