The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Jun> msg00277



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Hierarchical Tunnel Establishment in RSVP-TE

  • From: Chatur sharp <chatur_b@yahoo.com>
  • Date: Mon, 12 Jun 2000 11:37:09 -0700 (PDT)


Hi
I had this doubt after reading 2.1.4.b of
draft-ietf-mpls-label-encaps-07:

[ it has expired, but no replacement yet ???, ditto
for MPLS ARCH document.. ]
[text from draft]
.....

The operation to be performed on the label stack
before 
forwarding; this operation may be to replace the ....
....
....

>From this paragraph it would seem that the list of
operations allowed is:

1. Swap
2. Pop
3. Replace the top label with one or more additional
   entries on the stack. 

Does that mean that two pops cannot be performed ?
Surely this cannot be the case. Right ?

thanks
C.


--- "James R. Leu" <jleu@mindspring.com> wrote:
> On Mon, Jun 12, 2000 at 01:19:01PM -0400, Dimitry
> Haskin wrote:
> > 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
> 
> 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.
>    ...
> 
> > 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.
> 
> It seems the arch draft allows it, is this the same
> way others have interpreted
> this?
> 
> Jim
> -- 
> James R. Leu


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com