The MPLS WG Archive

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

Ashwin C. Prabhu wrote:
> David Charlap wrote:
>> 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.
> 
> Yes i was talking about LDP.
> 
> I have still some more doubts can you please clarify it. If LDP
> can so this why can't RSVP ? Why should the label message go till
> the egress and why can't the LSR1 reply back ?
> Anyway the resources are shared by both of them ( Shared Explicit )?

First off, please don't send me personal e-mails with questions like
this.  If you have a question regarding the protocol, please ask it to
the entire working group so that eveyrbody can learn the answer.

Anyway, regarding your question, LDP and RSVP are not the same
protocol.  It is completely wrong to think that the two are doing the
same thing with different format packets.  LDP label request messages
are _NOT_ the same as Path messages.

LDP is only concerned with mapping labels on to FECs.  The eventual
existnance of LSPs through the network is an emergent property.  No
aspect of the protocol explicitly sets up an LSP across the network.

RSVP-TE is very different.  Every Path message originated is intended to
describe exactly one LSP.  It must be delivered to the egress node or
the LSP can not be eastablished.  The egress nost _MUST_ specifically
identify the sender in every Resv message that it sends.  This is a hard
requirement for FF and SE style.  It can not do this if it does not
receive a Path message from each sender.

-- David