Re: [mpls-linux-general] Performing quick multiple popping

[James R. L. <jl...@mi...>]

On Fri, Feb 02, 2001 at 01:18:55PM -0500, Francois Desloges wrote:
> Hello all.
>=20
> 	I have a question regarding the interpretation of LDP and its
> applicability in the _real_world_.
>=20
> 	MPLS architecture specifies that if the NextHop is the LSR itself
> (I'll say Myself from now on), you would pop the top label and then pro=
ceed with
> the next label.
>=20
> 	For obvious hardware acceleraton purpose I would like to distribute th=
e
> same label value for _all_ LSPs that terminate at a specific LSR and ne=
ed to
> distibute a label that means POP-and-send-to-myself.
>=20
> 	Do anybody knows a good reason not to do so ? Problems related to
> this practice in the real world ? How do this LDP implementation (and o=
thers if
> anybody has the experience :-) enables me to do so ?

Hello Francois,

Sorry for the delay in getting back to you about this question.
It is hard to give you a definite answer about this.  There are a couple =
of
things to consider when thinking about how to optimize multiple label pop=
ping.

1. Remember that any label an LSR or LER is switching on has been
allocated by the signalling protocols running on it.  If enough informati=
on
is known about why/how the label(s) were allocated, then yes, it is possi=
ble to
know that the LSR can pop X number of labels.  It would take intelligent
software to know all of the rules and conditions though.

2. When trying to pop X number of labels, it is possible that some of the
information about where the label came from, or treatment the packet shou=
ld
recieve (PHB QoS Cos etc), could be lost if the LSR doesn't inspect every
level.  For example, if the skipped labels are part of L-LSPs then, in th=
eory,
the info from #1 should catch it.  If the skipped labels are part of E-LS=
Ps
then I think the LSR has to inspect every label to achive the correct
treatment.  So by using the info from #1 the LSR can know whether optimiz=
ed
popping can be used or if "slow-fast" path must be used.

3.  When it doing individual labe processing t is only neccessary to hand=
le
a depth of 4 labels to be used at the edge of current MPLS domains, if yo=
u
want to play in the core you probably only need to support a depth of 3.

(the reason for choosing 4 at the edge and 3 in the core come from curren=
t
deployments and the limits of currently deployed implementations)

(when I say "support a depth of 3" that means that the LSR can manuipulat=
e
and operate on the top 3 labels, more may exist which were allocated
by other LSRs)

If you still have questions or want diagrams that show examples, I can tr=
y to
draw some for you.  It's too hard to explain them with just words
and ascii drawings :-)

Jim

> Thanks !
>=20
> --=20
> Fran=E7ois Desloges
> fd...@vi...
>=20
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

--=20
James R. Leu