The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <A2BA7C0A67B1D411ACB500B0D078A8470FD97A@hermes.hyperchip.com>, Eyad 
Saheb writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C0504B.020EAF60
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Hello everyone,
> 
>     I have a question regarding the number of label lookups/operation
> required per packet.  Particularly, if a LSR does a lookup on an incoming
> packet it could result in another lookup.  For example, consider the case
> where a packet gets labeled upon entry into a MPLS domain.  At the following
> LSR, this packet/LSP can be further tunneled by adding another label to the
> stack.  This tunnel could itself be tunneled by another LSR, and so on,
> resulting in a considerable label stack.  Suppose that all the tunnels
> terminate on the same LSR.  The terminating LSR would perform a lookup,
> determine it is the end of the LSP, and pop the label.  However the next
> label would indicate the same thing, etc... This kind of situation can make
> it difficult for routers to maintain line-rate fowarding since there's no
> guarantee that the next lookup won't lead to another.  Is there a way around
> this (perhaps using penultimate hop popping)?  Does the MPLS architecture
> stipulate that situations like this should/must not occur ?
> 
> thanks,
> 
> 	Eyad


Combining VPN and LDP inside RSVP/TE and hierarchical TE tunnels you
could conceivably get 5-6 labels, although I haven't seen any network
design proposals that called for more than 3-4 at the very most.  With
PHP you can avoid having to do quite so many POPs at an egress but you
lose counter information, may lose some OAM capability (that no one
really has quite yet with or without PHP), and may lose some QoS
capabilty (again, that no one really has quite yet with or without
PHP).

If you are smart about it you may be able to load enough packet header
and a table with operations but maybe without labels and never go off
chip during the sequence of POP operations, only going off chip on a
SWAP or PUSH and in this way minimizing the effect of multiple
operations on a deep label stack.  If you can get enough bits on chip
you might be able to avoid going off chip entirely.  If you're smart
when you do the protocol part you can look at how many POPs will be
needed and ask for PHP on the inner tunnels (set up last) if the depth
may be too great for the packet rate and your hardware design.

Curtis