Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE

From: Dimitry Haskin <[email-masked]>
Date: Mon, 12 Jun 2000 13:19:01 -0400

Curtis,

If I read you correctly, you're implying that both labeled and unlabeled IP
packets are encapsulated into the outer tunnel, i.e. the RSVP control
traffic is sent with a single MPLS header of outer tunnel. Is it correct? If
so, this is fine except that, as far as I know, some MPLS vendors (note that
it does not apply to the equipment I am most familiar with ;) would not be
able to handle this in their fast path. To support labeled and plain IP
packets in the same tunnel would require the fast path decision based on the
state of S-bit of the outer header which is problematic with some equipment.
In addition, I've heard that one particular vendor would not be able to
terminate MPLS tunnels unless it arrives with a Null IP label.

Dimitry 

> Tony Li writes:
> > 
> > 
> >  | How does one establish hierarchical tunnels using RSVP-TE?
> >  |  
> >  | I know that the label object can be deeper than one 
> label, but you need mo
> > re
> >  | than this to establish hierarchical tunnels.
> > 
> > 
> > A hierarchical tunnel requires the participation of at 
> least two LSRs.  The
> > operation of the LSR creating the innermost tunnel is 
> straightforward and
> > is unchanged from what has been endlessly discussed here.
> > 
> > For an LSR to create an outer tunnel, it simply creates 
> another tunnel and
> > specifies MPLS as the L3PID.  It then forwards packets 
> received on the
> > inner tunnel by pushing a label for the outer tunnel.  The 
> RSVP control
> > traffic for the inner tunnel is also forwarded through the 
> outer tunnel
> > after first being encapsulated with a null IP label.
> > 
> > Recurse, ad nauseum.
> > 
> > Simple, really.  ;-)
> > 
> > Tony
> 
> 
> Tony,
> 
> Two minor points.  
> 
> If the outer tunnel is constrained (by configuration) to accept only
> inner tunnels with one L3PID, then that L3PID can be placed on the
> outer tunnel.  If there are optimization possible for a particular
> L3PID (IP src/dst hash to split loading along the way comes to mind
> for IPv4) then putting the inner L3PID on the outer tunnel has
> advantages.
> 
> No where have I seen a requirement to put a null label on traffic
> destined to the egress LSR.  I had been assuming that if the IP packet
> under the top label has the address of the router ID of the egress
> under the outer label, then the packet would be delivered to the
> egress.  If the egress required PHP, then the penultimate LSR would
> put a null label on the control traffic for the the inner label and
> the egress would POP the null label and see its own IP address.
> Otherwise, the egress would see two null labels.
> 
> If I'm missing something and/or there will be any interoperability
> problem with the way I intended to encapsulate control traffic inside
> the outer label, please tell us about it.
> 
> Curtis
>

---

From: "James R. Leu" <[email-masked]>
Date: Mon, 12 Jun 2000 12:31:57 -0500

> it does not apply to the equipment I am most familiar with ;) would not be

See draft-ietf-mpls-arch-06.txt

3.10. The Next Hop Label Forwarding Entry (NHLFE)
   ...
   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.
   ...

> terminate MPLS tunnels unless it arrives with a Null IP label.

It seems the arch draft allows it, is this the same way others have interpreted
this?

Jim
-- 
James R. Leu

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 13 Jun 2000 00:06:39 -0400

In message <[email-masked]>, Dimitr
> terminate MPLS tunnels unless it arrives with a Null IP label.

Yes, this is what I meant.  The L3PID simply indicates what is under
the label stack, not what is under the top label.

It sounds like there needs to be some wording added to the drafts to
indicate how to deal with equipment that is limited in this way.  In
particular, draft-ietf-mpls-rsvp-lsp-tunnel-05.txt should have some
means to signal back to the ingress these limitations, or if we want
to be backward compatible with equipment that has these limitations,
we can just make the limitation the default and signal lack of this
limitation.  A sub-TLV in the IGP would be fine since it is not a per
LSP limitation but a per interface (assuming someone might make newer
interfaces that remove the limitation).

It would be quite easy to set up an outer LSP so that the inner
control traffic got a null label.  Always putting a null label over an
IP packet that is being used as control for the inner tunnel is
slightly wasteful, but not a big deal.

Does this means that one (or both) of those routers can't accept an
L3PID that indicates what is under the entire label stack?

Curtis

---

From: Yangguang Xu <[email-masked]>
Date: Tue, 13 Jun 2000 08:59:37 -0400

Hi,

Similar questions of CR-LDP: 

Why CR-LDP doesn't define timer like T301, 303 etc. in Q.2931 for LSP setup?
What's the underlying assumption that LSP doesn't need these timers? How can
CR-LDP guarantee the mapping response will eventually arrive for certain label
request?

Thanks,

Yangguang