Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE

From: "Abes, Andi" <[email-masked]>
Date: Tue, 13 Jun 2000 12:31:18 -0400

Curtis,

The PHP options brings up a question that I've asked a 
long time ago, but went un-answered:
Are "inner" labels restricted to be from the "platform"
label pool ?
Are there implementations that use "per-interface" label 
pools to allocate inner labels ?

It is concivable that an implementation will choose to
define an LSP (or set of them) as an interface. And, on
top of this interface manage a "per-interface" label pool.
This can help simplify routing for example.

If this is allowed, then the PHP solution will break, since
only the outer label identifys the incomming "interface".

Andi.

>-----Original Message-----
>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Tuesday, June 13, 2000 10:16 AM
>To: Kireeti Kompella
>Cc: [email-masked]; [email-masked]
>Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>
>In message <[email-masked]>, Kireeti 
>Kompella writes:
>> > Two POPs are needed to terminate a VPN tunnel.
>> 
>> Not if you use PHP.  You start popping one hop earlier, e.g., if
>> X is the PE attached to the customer, and Y the penultimate hop,
>> Y pops the "outer label" and forwards the packet with the "inner
>> label" identifying the VPN to X.  X looks at the inner (only!)
>> label, pops it and knows which customer to forward the packet to.
>> 
>> Corner case: a one-hop LSP carrying VPN info: don't put any "outer
>> label" in this case.
>> 
>> > Three might be needed
>> > if the outer tunnel on the VPN took its last hop through a FA-PSC.
>> 
>> Picture time:
>> 
>>     A ---- B ==== C ==== D ==== E ~~~~ customer
>>             <-43-  <-28-  <--3-
>>     <--71-- <-------- 3 -------
>> 
>>     <-- 32 for VPN to customer --
>> 
>> There's an FA-LSP from B to E.  E sends D an implicit NULL label,
>> D sends C label 28, C sends B 43.
>> 
>> Now, there's another LSP that wants to tunnel through the above
>> FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
>> B sends A label 71.
>> 
>> A and E agree on label 32 for the VPN.
>> 
>> The label stack for a packet to the customer is as follows:
>> 
>>     A ---- B ==== C ==== D ==== E ~~~~ customer
>>               43     28
>>        71
>>        32     32     32     32
>> 
>> Note that 71 -> 43 is not really a swap as much as a pop (PHP),
>> followed by a push (equivalent, but you get there differently).
>> 
>> It is interesting to first work out the case where the tunneled
>> LSP terminates beyond the tail of the FA-LSP, as the above example
>> is another 'corner case'.
>> 
>> Kireeti.
>
>
>Kireeti,
>
>PHP does remove POPs and make it easier to implement an egress LSR but
>it makes it very hard to collect statistics of packets and bytes
>received on an LSP at the egress.  Recall the discussion of OAM and
>loss measurements.  There is no way to count at the egress if the
>labels are lost.  Therefore in your example there is no way to
>determine loss over the FA-PSC tunnel or over the tunnel from A-E.
>
>Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jun 2000 09:19:46 -0400

In message <[email-masked]>, "Abes
> only the outer label identifys the incomming "interface".

I makes sense for the inner labels to be per platform because the
outer label can be rerouted and end up coming in on another interface.
If that reroute occurs cleanly (make before break), it should not be
nessecary to reroute the inner labels.

Curtis

---

From: "James R. Leu" <[email-masked]>
Date: Wed, 14 Jun 2000 08:29:29 -0500

On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:
<snip>

> nessecary to reroute the inner labels.

Are your saying that an ILM will have labels from multiple labelspaces?
That would require the label manager to do co-ordination of every label
allocation.

Or, are you saying that you have a special outer label which points to a new
ILM for all future lookups?  Depending how you implement this it will break the
proccesing when it is "IPv4 or label" under the top label.
(plus I don't think hardware implementors will like this approach)

Jim
-- 
James R. Leu

---

From: Eric Rosen <[email-masked]>
Date: Wed, 14 Jun 2000 11:08:01 -0400

Andi> The PHP options brings up a question that I've asked a 
Andi> long time ago, but went un-answered:
Andi> Are "inner" labels restricted to be from the "platform"
Andi> label pool ?

The only restriction is that you need to be able to interpret the label. 

If you always use a per-platform  label space only, you never have a problem
with this. 

If you want to  use a per-interface label space, you need  to do whatever it
takes to ensure that when you receive  a packet whose top label is from that
space, you  will be  able to determine  that the  label is from  that space.
This really means that you need to  be able to determine which of your label
distribution peers put the label on.

Andi> Are there implementations that use "per-interface" label 
Andi> pools to allocate inner labels ?

Andi> It is concivable that an implementation will choose to
Andi> define an LSP (or set of them) as an interface. And, on
Andi> top of this interface manage a "per-interface" label pool.
Andi> This can help simplify routing for example. 

In general, a router needs to know  which interface a packet came in on.  If
you are  treating an LSP as an  interface, therefore, you cannot  do PHP for
that LSP, or  you won't be able to  tell that an arriving packet  came in on
this interface.  In  this case, there is no reason why  the label beneath it
might not be from a per-interface label space; once you know the "interface"
over which the packet arrived, you know who put on the next label. 

However, depending on how you are setting up the LSP interface, you may want
the top label to come from a platform-specific space.

Andi> If this is allowed, then the PHP solution will break, since
Andi> only the outer label identifys the incoming "interface". 

The LSR on the receiving end  of the "interface" always has complete control
over whether  PHP is done, so  nothing breaks if the  implementation is done
correctly.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 14 Jun 2000 11:17:28 -0400

Jim> Are your saying that an ILM will have labels from multiple labelspaces?
Jim> That would require the label manager to do co-ordination of every label
Jim> allocation. 

In general, if you are  supporting a platform-specific label space, and also
supporting  one or  more per-interface  label spaces,  the platform-specific
label space will need to be distinct from the per-interface label spaces. 

I think  that the simplest thing is  just to use a  per-platform label space
(except in ATM,  of course).  You can still maintain the  notion that only a
subset of the  labels have been assigned to each  of your label distribution
peers, and  you can still  drop a packet  that arrives on a  given interface
with a top label  that wasn't assigned to the peer at  the other end of that
interface. 

Jim> Or, are you saying that you  have a special outer label which points to
Jim> a new ILM for all future lookups?  

As long as the platform-space  is distinct from the interface-space, you can
implement a single lookup table.

Jim> Depending how you  implement this it will break  the proccesing when it
Jim> is "IPv4 or label" under the top label. 

I would recommend that you implement it correctly rather than incorrectly ;-)

Jim> (plus I don't think hardware implementors will like this approach)

The  lookup tables  are set  up by  software, the  hardware guys  don't care
what's in them.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 15 Jun 2000 13:45:18 -0400

> That would require the label manager to do co-ordination of every label

By global I meant platform-specific.  There is no need at all to
coordinate label allocation across LSR.  An LSR many be using both
platform-specific and interface-specific labels.  This is not a hard
problem.

Curtis

---

From: Mukul Katiyar <[email-masked]>
Date: Thu, 15 Jun 2000 11:21:06 -0700

> platform-specific and interface-specific labels.  This is not a hard

Protection of LSPs using label stacking will
 imply that the inner most labels be allocated
on a per platform basis. This it self places a constrain on the
label space to be global from which all those LSPs that may be
protected with label stacking to allocate their labels from.
IMHO this is a probelm considering that LSPs which may need
protection (label allocated from global Label space) could co-exist 
with those which may not (not necessarily from global space).
Please correct me if I am missing some thing.
-Mukul

---

From: "Loa Andersson" <[email-masked]>
Date: Fri, 16 Jun 2000 14:09:06 +0200

Curtis,

when first reading this I thought that it would introduce unnecessary
(maybe unwanted) restrictions to the use of per interface labels. Is 
your idea that when you set up hierarchial LSP the inner labels always
should from a per platform space?

The architecture says:
"In MPLS, there is no notion of having a different label space for 
different levels of the hierarchy; when interpreting a label, the 
level of the label is irrelevant."

If we require that the "outest label" should also be from a per
platform space?

....?

/Loa

Curtis Villamizar wrote:

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: [email-masked]