Subject: RE: Valid Operations on MPLS Labels

From: "Rajeev Manur" <[email-masked]>
Date: Fri, 28 Jan 2000 15:30:08 -0800

we could also have any combination of these like 
SWAP followed by a PUSH,
POP followed by a SWAP 
POP and GO ( which is slightly different from POP ) etc.

we could also have POP & PUSH ( MPLS --> IP --> MPLS )

with regards,
Rajeev.

Force10 Networks
Santa Clara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bora
Akyol
Sent: Friday, January 28, 2000 2:47 PM
To: [email-masked]; [email-masked]
Subject: Valid Operations on MPLS Labels

What are valid operations that can be performed on MPLS labels?

Yes sounds simple, but is it really?

1. SWAP: Lookup on incoming label, determine egress interface, outgoing
label, swap labels, update TTL.

2. PUSH: Look up on incoming label, determine egress interface, swap
topmost label and push one or more labels. Fix TTL in top most label.

3. POP: This is where the MPLS arch document is confusing. Assuming that
Penultimate hop popping is not used:
 So far we know that we have to lookup on incoming label, determine
operation (in this case POP), pop topmost label.

If it reveals an IP packet, we do a route lookup and everything is OK.

If it reveals an MPLS packet underneath, then what are valid operations
that can be performed on the label that emerges after the topmost label
is popped. I would like to know whether a swap or a push can follow a
pop. I am willing to do another lookup on the resultant packet, but
don't want to get into a recursive pop or push paradigm.

Any thoughts?

Bora

---

From: Eric Gray <[email-masked]>
Date: Sun, 30 Jan 2000 12:50:29 -0500

Bora/Rajeev,

	Considering the "pop" operation by itself, there 
are essentially two things you could do with it.  This 
makes "pop" effectively two distinct instructions: pop-1 
and pop-2.  In one - call it pop-1 - the incoming label 
maps to:

    o	select logical output interface
    o	pop top label(s)
    o	forward remaining packet via selected interface

In the other, the incoming label maps to:

    o	pop top label(s)
    o	perform label-switch/swap based on the new top
        label (or - if the last label is removed - use
        routing based on the following IP header)

In the latter case, you have potential for recursion (at
least, you do if the last label has not been removed).  

	Also, if you consider the various combinations of 
"pop", "swap" and "push", you also need to include "pop 
label(s) and push label(s)" as a single instruction.  In 
this case, you do not need to perform a lookup (label 
switch/swap) based on the result since anything you might 
find can as easily be done in the original "pop/push". In
this case, you would not get recursion.

	However, in every case, the complexity of the
operation to be performed is limited to the complexity
your implementation is willing to accept since all of
these potential operations must be bound to a label by
the LSR implementation that will ultimately have to do
them.  If you don't want to implement complex pop/push
and swap operations, then don't.

	After all, the specifications point out that an
"LSR" can allocate implicit NULL labels to its peers and
never even see labels.  Of course, such an "LSR" needs
to be surrounded by fairly tolerant neighbors...