The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jun> msg00371



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

What to do with an illegal label stack?

  • From: Eric Gray <eric.gray@sandburst.com>
  • Date: Mon, 25 Jun 2001 19:07:46 -0400
  • Cc: mpls@UU.NET

Sajith,

    Just to add to what you've said, each LSR is only supposed to
act on labels it has distributed and generally only those at the top
of the label stack.  An LSR will look at one or more lower labels
(in the label stack) if higher labels (starting at the top) are labels
distributed by the local LSR with a semantic meaning of "pop and
look again".

    The scenario in which the BOS bit is not correctly set will cause
some LSR somewhere to encounter something it thinks is a label
(but is not) and chances are that label will not be one it distributed.
In this case, it should recognize this as an error and discard the
offending packet.  The really thorny problem is when the LSR has
issued labels likely to occur in the first 32 bit word of an IP header.
For this reason, it could be a good idea to avoid using the label
0x45000 (for IPv4) or any label beginning with 0x6 (for IPv6)
whenever it is likely that packets may be received with the BOS bit
not correctly set - which (by the way) really should be NEVER.

    Otherwise, the only 'illegal' label stack is one that begins with
a label not distributed by the LSR that receives it.  In this case,
the only reasonable action is to drop the packet.

--
Eric Gray

You wrote:

> >An MPLS packet arrives with a label stack with no
> >bottom of stack bit set (e.g. 88 47 22 22 20 60 00 00
> >00 00 00 00...).
> >
> >Is any behavior mandated here?  Is it OK to forward
> >this packet, or must it be discarded?
>
> i believe there is no way a forwarding plane can detect
> this, unless there is an upper limit on number of labels
> in the stack defined by the standarad, which, i believe
> is not the case
>
> so the packet will be forwarded, unless there any other
> errors
>
> thanks
> sajith