Subject: RE: multiple lookups per packet

From: Kalpesh Sheth <[email-masked]>
Date: Fri, 17 Nov 2000 14:35:48 -0500

This is a very good question and I, too would be interested in hearing what
other's have to say. As far as I know, this is the reason no body gurantees
line rate when you have more than one/two level of tunneling. In hardware
your processing time is governed by the worst-case scenario and in this
case, there is not end to it. MPLS architecture spec. does not address this.
Other than some proprietary way to handle this, I don't see how one can
maintain "line rate".
 
-Kalpesh Sheth

-----Original Message-----
From: Eyad Saheb [mailto:[email-masked]]
Sent: Thursday, November 16, 2000 11:01 PM
To: [email-masked]'
Subject: multiple lookups per packet

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

---

From: "S. Chkaravorty" <[email-masked]>
Date: Sun, 19 Nov 2000 11:11:07 -0500

All,

Do we have a response to these questions from the proponents of MPLS?
The line rate issue in the worst case of tunneling is a very valid
concern.

One of the largest product vendors have told me that MPLS does not work
well in the core where speed (optics_ckts) is the concern.  It is really
too complex given this "multi-tunneling" aspect, and with LDP, it is
still more complex (not accounting for versions of LDP) and then there
is the unresolved control plane debate between optics and IP.  It
appears that MPLS is a technology bandwagon on which a lot of us want a
ride but not sure where it is taking us.  Or is this a wrong way of
thinking?

Some of you must know that through variations of hardware and/or
software solution, a large number of start-ups are developing/providing
high-speed switching and QoS provisioning in the edge and also in the
core. It seems these folks are not waiting for the MPLS solution.

S.C.

Kalpesh Sheth wrote:

>  This is a very good question and I, too would be interested in
> hearing what other's have to say. As far as I know, this is the reason
> no body gurantees line rate when you have more than one/two level of
> tunneling. In hardware your processing time is governed by the
> worst-case scenario and in this case, there is not end to it. MPLS
> architecture spec. does not address this. Other than some proprietary
> way to handle this, I don't see how one can maintain "line
> rate".-Kalpesh Sheth
>
>          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

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Nov 2000 10:57:43 -0500

If you are designing  an LSR, what you have to be  concerned with is not how
large the label  stack could be in theory, but rather  with how many lookups
you need to  do to support the necessary functions.   Generally, you can use
php to  ensure that you don't  have to do  a label lookup unless  you really
need to know the results of  that label lookup to perform a certain function
properly. 

It's difficult to think of situations in  which you need to do more than two
lookups,  one to  get  a context,  and  a second  to  obtain the  forwarding
information relative  to that  context (either  by a label  lookup or  an IP
address lookup).  (We  could probably think of such  situations, but I'm not
sure how  realistic they  might be.)  Php  was invented precisely  to ensure
that you don't  end up with a  bunch of "sorry, look below"  labels when you
get to the egress.

You  don't need  to lose  QoS information  with php,  since the  QoS  can be
propagated downward when a label is  popped.  As Curtis points out, there is
some impact  on your ability to keep  per-LSP counts, and if  there were any
OAM capability that might be impacted as well.  

The issues inherent  in the handling of nested  tunnels are not particularly
MPLS-specific, any tunneling technology  which allows nested tunnels has the
same issues.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Nov 2000 11:03:24 -0500

SC> One of the largest product vendors  have told me that MPLS does not work
SC> well in the core where speed (optics_ckts) is the concern. 

Well, don't believe everything you hear.

SC> It is really too complex given this "multi-tunneling" aspect,

This makes  no sense to me.  Either  a particular node needs  to function as
the endpoint  of several nested  tunnels, or it  does not.  If it  does not,
then  it will  not need  to look  at  more than  one label,  so the  "multi-
tunneling aspect" is  irrelevant.  If the node does need  to function as the
endpoint of several nested tunnels, then it will need to do multiple lookups
regardless of whether MPLS  is used or not.  Use of MPLS  does not force one
into use of multi-tunneling mode.

---

From: Mark Stewart <[email-masked]>
Date: Mon, 20 Nov 2000 11:11:13 -0500

Hi All

comments inline

> The line rate issue in the worst case of tunneling is a very valid

Most vendors restrict the number of lookup operations that may be
performed in hardware at any hop on a single packet, having made an
educated guess as to how many their customers will need for most
practical applications. As the device has the capacity to reject the
establishment of LSP's which require a larger number of lookups there is
no real danger of it receiving such packets.

> One of the largest product vendors have told me that MPLS does not
> work well in the core where speed (optics_ckts) is the concern.

It sounds like said vendor doesn't have a good MPLS implementation yet.

> It is really too complex given this "multi-tunneling" aspect, and with
> LDP, it is still more complex (not accounting for versions of LDP) and
> then there is the unresolved control plane debate between optics and
> IP.

FUD

> It appears that MPLS is a technology bandwagon on which a lot of us
> want a ride but not sure where it is taking us.

Some of us are very comfortable with the way the MPLS
standards/technology is evolving and see it as promising greatly
improved network management and traffic engineering.

>  Or is this a wrong way of thinking?

yes

> software solution, a large number of start-ups are
> developing/providing high-speed switching and QoS provisioning in the
> edge and also in the core. It seems these folks are not waiting for
> the MPLS solution.
>

No one is arguing that MPLS is the only possible way of deploying IPQoS.
It provides a good solution which does not require the metropolitan and
long distance carriers to completely redesign their network design
strategies but instead extend them in a scalable fashion.

ciao

mark

>> hearing what other's have to say. As far as I know, this is the
>> reason no body gurantees line rate when you have more than one/two
>> level of tunneling. In hardware your processing time is governed by
>> the worst-case scenario and in this case, there is not end to it.
>> MPLS architecture spec. does not address this. Other than some
>> proprietary way to handle this, I don't see how one can maintain
>> "line rate".-Kalpesh Sheth
>>
>>      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
>>      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