The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Sep> msg00001



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

MPLS over FR.

  • From: abhay <abhay@multitech.co.in>
  • Date: Sun, 02 Sep 2001 11:20:15 +0530
  • CC: "'mpls@uu.net'" <mpls@UU.NET>

Binita,
       With regards to the draft draft-ietf-mpls-label-encaps-08
       Read this:
       2.2. Determining the Network Layer Protocol

   When the last label is popped from a packet's label stack (resulting
   in the stack being emptied), further processing of the packet is
   based on the packet's network layer header.  The LSR which pops the
   last label off the stack must therefore be able to identify the
   packet's network layer protocol.  However, the label stack does not
   contain any field which explicitly identifies the network layer
   protocol.  This means that 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.

   Therefore, when the first label is pushed onto a network layer
   packet, either the label must be one which is used ONLY for packets
   of a particular network layer, or the label must be one which is used
   ONLY for a specified set of network layer protocols, where packets of
   the specified network layers can be distinguished by inspection of
   the network layer header.  Furthermore, whenever that label is
   replaced by another label value during a packet's transit, the new
   value must also be one which meets the same criteria.  If these
   conditions are not met, the LSR which pops the last label off a
   packet will not be able to identify the packet's network layer
   protocol.

   Adherence to these conditions does not necessarily enable
   intermediate nodes to identify a packet's network layer protocol.
   Under ordinary conditions, this is not necessary, but there are error
   conditions under which it is desirable.  For instance, if an
   intermediate LSR determines that a labeled packet is undeliverable,
   it may be desirable for that LSR to generate error messages which are
   specific to the packet's network layer.  The only means the
   intermediate LSR has for identifying the network layer is inspection
   of the top label and the network layer header.  So if intermediate
   nodes are to be able to generate protocol-specific error messages for
   labeled packets, all labels in the stack must meet the criteria
   specified above for labels which appear at the bottom of the stack.

   If a packet cannot be forwarded for some reason (e.g., it exceeds the
   data link MTU), and either its network layer protocol cannot be
   identified, or there are no specified protocol-dependent rules for
   handling the error condition, then the packet MUST be silently
   discarded.
   Hope this helps..
   Regards,
   Abhay


Binita Jha wrote:

I have a doubt regarding MPLS over FR.
1) RFC 3034 says that the top label (DLCI) carries implicitly information
about the network protocol type. but how does it indicate about if the shim
header is present or not?

2) Also if the shim header is present then how do we know abt what network
protocol is present?

Kindly send me the answer if anyone has.
Regards
Binita