The MPLS-OPS Archive

["Alexander Marhold" <alexander@marhold.at>]

Hello !

Some thoughts and hopeful explanations to your very valid question

1) normal MPLS behaviour on frame based platforms
the egress for a certain destination (or FEC) typically using LDP/TDP sends
a label binding to the penultimate node and thus expects to get exactly that
label, when packets will be sent to that destination.
As he as the last node normally has to do a L3-lookup he will use a special
label IMPLICIT-NULL which telles the penultimate to send the packet but
having the outermost ( or in this case last) label removed. So he will get
an ulabelled normal L3-packet
2) MPLS/VPN
the egress will assign a label  for any destination within a VPN, or for
aggregates of destinations within a VPN and this label will be sent to
ingress nodes using Multiprotocol BGP.
The ingress will sned data in that way, that it will use typically 2 labels,
one for the hop-by-hop transport to the egress and the inner one is the
label received by the egress for that certain destination.
By looking into the label the egress has all the information he needs to
forward the packet.
3) L2 transport over MPLS/VPN
By creating 2 tunnels between ingress and egress and exchanging labels via
LDP/TDP between the non-adjacent head and tail-nodes of the tunnel, the
correspondence between packettype/destination and label is given. ( this is
true for any L2 over MPLS)

But why there some discussion about exactly that "missing" protocol field in
the labelheader ?

The reason for that is that any intermediate hop has no labelinformation
about innerlabels and thus no knowledge about the packettype and protocol.
But this is necessary if you want to send back errormessages.
One important aspect is signalling back the path-MTU size when packets are
bigger than that size, or even deciding if any fragmentation is
allowed/supported by the protocol.

Hope that helps

with best regards
Alexander

__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
     __/
    __/   Dipl.Ing. Alexander Marhold MBA
   __/   CCIE #3324, CCNP, CCDP, CCSI #20642
  __/   Core & IP Services <Senior Consultant>
 __/   Mobile: ++43-(0)664-16 28 234
__/    PRO IN http://www.proin.com



-----Original Message-----
From: Vikas D [mailto:vikdw@yahoo.com]
Sent: Saturday, June 30, 2001 12:19 AM
To: mpls-ops@mplsrc.com
Subject: RFC 3032 : Determining the L3 header at egress.



Greetings everyone!

At the egress LSR, while processing the packet based upon
L3 header, how is the L3 protocol determined?  The drafts
talk of various ways, including lavel values reserved for
may be for different sets of protocol families.

What approach do "today's" equipments follow?

RSVP-TE has provision of exchanging id of the layer 3 protocol
that the LSP shall serve.  Can this information be used for
determining the MPLS encapsulated protocol?  If that is the
case, should this protocol ID form a part of the FTN/ILM entries?

Thanks
- VD


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml