The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

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