Subject: RE: Query on draft-ietf-mpls-label-encaps

From: [email-masked]
Date: Fri, 13 Oct 2000 17:37:30 +0100

David Charlap wrote:

> Sudhanshu Jain wrote:
> > 
> > L3PID is the what used in setting up tunnel which are protocol aware.
> > 
> > But if a tunnel is being setup as a fat pipe, ( e.g. L3PID is not
> > present at setup time).
> > 
> > Is it possible for such a tunnel to carry multiprotocols via using 0
> > or 2 label at the bottom of the stack?
> > 
> > Is there any existing implementation which carry multi protocol over
> > single tunnel? If so, how do they carry protocol information
> > end-to-end?
> 
> Doing this is very problematic.
> 
> Eventually, the data will have to leave the MPLS tunnel.  When it does,
> some kind of L3PID information must exist, in order to place it in the
> L2 header of the network beyond the tunnel.  If multiple packets in the
> tunnel have different L3PIDs, how will the egress router be able to
> properly generate the L2 header?
> 
> In the ATM world, wrappers like AAL5 are used to carry this kind of
> information.
> 
> IMO, the only good way to carry multiple L3 protocols in a single LSP is
> to wrap the packets in something that can carry the protocol ID on a
> per-packet basis.
> 
> 
> If such a thing would be done, then (from MPLS's perspective), the
> tunnel would be carrying packets all of one type - the wrapper's type. 
> Whatever code on the ingress/egress that exists to add/remove these
> wrappers would then be responsible for preserving the per-packet L3PID
> information.
> 
> (Is there a draft for this?  I don't know.  If people really want to run
> multiple protocols in one tunnel, then such a draft would be useful so
> that different implementations can interoperate.)
> 
	NH=> We will also need to address this issue for an MPLS layer OAM
function (let alone a generic client layer layer identification).  I had a
discussion some time ago on the list on the need for a protocol ID field in
the MPLS LSP header based on this OAM requirement.  I would argue (and I
know several supported this) that the TTL field is overkill at 8 bits and we
could have made better use of this field...at least for OAM pkt
identification.  Further, because of the client/server relationship that
ought to be adhered to between layer networks, one should not be making any
assumption about server layer (in this TTL case) latent hop counts.  That
is, a link connection (ie 1-hop) in a LSP at level N (ie the client) is a
trail (= unknown number of hops from client perspective) in an LSP at level
N+1 (ie the server).  This relationship (ie server layer trails = client
layer links) can recurse several times, and it is a well-known/specifed
functional arch feature of transport networks (see G.805).

	The only consensus I could reach on the list for the OAM issue was
to create a new 'special label' (in addition to the 4 currently
specified/reserved in the encaps ID).  This is not a very elegant solution
and creates restrictions, eg normal forwarding label stack has to be
increased by 1 when an OAM pkt is sent (but this is not very often), and it
complicates any attempt to define a user-plane-based route-trace
capability....something we will now probably abandon in the OAM ID, at least
for the time being.

	So yes, a protocol ID field would have been jolly useful even for an
OAM requirement, but I guess its too late now.  I can at least find a
solution for (very basic) OAM, but this does not help you.
	Note - There is a key difference between OAM pkt identification and
client protocol identifications.  The former applies to all LSPs at any
level, whereas the latter is only relevant in the highest level of LSP, ie
below the top LSP, all subsequent lower LSP must have 'MPLS' as their client
layer protocol.  

	Neil

---

From: [email-masked]
Date: Fri, 13 Oct 2000 17:58:26 +0100

gja wrote:

> 	[..]
> AAL5 doesn't carry protocol muxing info per se, it requires additional
> overhead such as LLC/SNAP headers. Which (as you correctly allude)
> would solve the original poster's problem too.
> 
> cheers,
> gja
> 
	NH=> I agree Grenville that this is one way to deal with this.  But
the immediate observation is that this creates a new network layer somewhere
between the shim header and the payload, and so one is led to ask "if people
think this is really needed then why was this not part of the basic MPLS O/H
in the 1st place?"  I have my own views on this, and I am sure others
do....but from a slightly different angle, the fewer protocols that natively
interface with applications the better, eg VoXX, gives an O(n^2/2) gateway
problem across user/control/management planes....quite horrible when you
count up what XX could be.
	neil

---

From: Shen Gangxiang <[email-masked]>
Date: Sat, 14 Oct 2000 11:52:10 +0800

> single tunnel? If so, how do they carry protocol information
David worte:

As pointed out by the draft, "the identity of the network layer protocol
   must be inferable from the value of the label which is popped from
   the bottom of the stack, possibly along with the contents of the
   network layer header itself", so based on this, we may recognize
the upper layer protocols. As to how to generate the L2 header, I think
it is up to if the egress router can support such a kind of function.

Gangxiang