rfc3032.txt

最新的RFC

Network Working Group                                           E. Rosen
Request for Comments: 3032                                     D. Tappan
Category: Standards Track                                    G. Fedorkow
                                                     Cisco Systems, Inc.
                                                              Y. Rekhter
                                                        Juniper Networks
                                                            D. Farinacci
                                                                   T. Li
                                                  Procket Networks, Inc.
                                                                A. Conta
                                                  TranSwitch Corporation
                                                            January 2001


                       MPLS Label Stack Encoding

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   "Multi-Protocol Label Switching (MPLS)" [1] requires a set of
   procedures for augmenting network layer packets with "label stacks",
   thereby turning them into "labeled packets".  Routers which support
   MPLS are known as "Label Switching Routers", or "LSRs".  In order to
   transmit a labeled packet on a particular data link, an LSR must
   support an encoding technique which, given a label stack and a
   network layer packet, produces a labeled packet.  This document
   specifies the encoding to be used by an LSR in order to transmit
   labeled packets on Point-to-Point Protocol (PPP) data links, on LAN
   data links, and possibly on other data links as well.  On some data
   links, the label at the top of the stack may be encoded in a
   different manner, but the techniques described here MUST be used to
   encode the remainder of the label stack.  This document also
   specifies rules and procedures for processing the various fields of
   the label stack encoding.






Rosen, et al.               Standards Track                     [Page 1]

RFC 3032               MPLS Label Stack Encoding            January 2001


Table of Contents

    1      Introduction  ...........................................  2
    1.1    Specification of Requirements  ..........................  3
    2      The Label Stack  ........................................  3
    2.1    Encoding the Label Stack  ...............................  3
    2.2    Determining the Network Layer Protocol  .................  5
    2.3    Generating ICMP Messages for Labeled IP Packets  ........  6
    2.3.1  Tunneling through a Transit Routing Domain  .............  7
    2.3.2  Tunneling Private Addresses through a Public Backbone  ..  7
    2.4    Processing the Time to Live Field  ......................  8
    2.4.1  Definitions  ............................................  8
    2.4.2  Protocol-independent rules  .............................  8
    2.4.3  IP-dependent rules  .....................................  9
    2.4.4  Translating Between Different Encapsulations  ...........  9
    3      Fragmentation and Path MTU Discovery  ................... 10
    3.1    Terminology  ............................................ 11
    3.2    Maximum Initially Labeled IP Datagram Size  ............. 12
    3.3    When are Labeled IP Datagrams Too Big?  ................. 13
    3.4    Processing Labeled IPv4 Datagrams which are Too Big  .... 13
    3.5    Processing Labeled IPv6 Datagrams which are Too Big  .... 14
    3.6    Implications with respect to Path MTU Discovery  ........ 15
    4      Transporting Labeled Packets over PPP  .................. 16
    4.1    Introduction  ........................................... 16
    4.2    A PPP Network Control Protocol for MPLS  ................ 17
    4.3    Sending Labeled Packets  ................................ 18
    4.4    Label Switching Control Protocol Configuration Options  . 18
    5      Transporting Labeled Packets over LAN Media  ............ 18
    6      IANA Considerations  .................................... 19
    7      Security Considerations  ................................ 19
    8      Intellectual Property  .................................. 19
    9      Authors' Addresses  ..................................... 20
   10      References  ............................................. 22
   11      Full Copyright Statement  ............................... 23

1. Introduction

   "Multi-Protocol Label Switching (MPLS)" [1] requires a set of
   procedures for augmenting network layer packets with "label stacks",
   thereby turning them into "labeled packets".  Routers which support
   MPLS are known as "Label Switching Routers", or "LSRs".  In order to
   transmit a labeled packet on a particular data link, an LSR must
   support an encoding technique which, given a label stack and a
   network layer packet, produces a labeled packet.







Rosen, et al.               Standards Track                     [Page 2]

RFC 3032               MPLS Label Stack Encoding            January 2001


   This document specifies the encoding to be used by an LSR in order to
   transmit labeled packets on PPP data links and on LAN data links.
   The specified encoding may also be useful for other data links as
   well.

   This document also specifies rules and procedures for processing the
   various fields of the label stack encoding.  Since MPLS is
   independent of any particular network layer protocol, the majority of
   such procedures are also protocol-independent.  A few, however, do
   differ for different protocols.  In this document, we specify the
   protocol-independent procedures, and we specify the protocol-
   dependent procedures for IPv4 and IPv6.

   LSRs that are implemented on certain switching devices (such as ATM
   switches) may use different encoding techniques for encoding the top
   one or two entries of the label stack.  When the label stack has
   additional entries, however, the encoding technique described in this
   document MUST be used for the additional label stack entries.

1.1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

2. The Label Stack

2.1. Encoding the Label Stack

   The label stack is represented as a sequence of "label stack
   entries".  Each label stack entry is represented by 4 octets.  This
   is shown in Figure 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                    Label:  Label Value, 20 bits
                    Exp:    Experimental Use, 3 bits
                    S:      Bottom of Stack, 1 bit
                    TTL:    Time to Live, 8 bits

                              Figure 1






Rosen, et al.               Standards Track                     [Page 3]

RFC 3032               MPLS Label Stack Encoding            January 2001


   The label stack entries appear AFTER the data link layer headers, but
   BEFORE any network layer headers.  The top of the label stack appears
   earliest in the packet, and the bottom appears latest.  The network
   layer packet immediately follows the label stack entry which has the
   S bit set.

   Each label stack entry is broken down into the following fields:

      1. Bottom of Stack (S)

         This bit is set to one for the last entry in the label stack
         (i.e., for the bottom of the stack), and zero for all other
         label stack entries.

      2. Time to Live (TTL)

         This eight-bit field is used to encode a time-to-live value.
         The processing of this field is described in section 2.4.

      3. Experimental Use

         This three-bit field is reserved for experimental use.

      4. Label Value

         This 20-bit field carries the actual value of the Label.

         When a labeled packet is received, the label value at the top
         of the stack is looked up.  As a result of a successful lookup
         one learns:

         a) the next hop to which the packet is to be forwarded;

         b) the operation to be performed on the label stack before
            forwarding; this operation may be to replace the top label
            stack entry with another, or to pop an entry off the label
            stack, or to replace the top label stack entry and then to
            push one or more additional entries on the label stack.

         In addition to learning the next hop and the label stack
         operation, one may also learn the outgoing data link
         encapsulation, and possibly other information which is needed
         in order to properly forward the packet.








Rosen, et al.               Standards Track                     [Page 4]

RFC 3032               MPLS Label Stack Encoding            January 2001


         There are several reserved label values:

           i. A value of 0 represents the "IPv4 Explicit NULL Label".
              This label value is only legal at the bottom of the label
              stack.  It indicates that the label stack must be popped,
              and the forwarding of the packet must then be based on the
              IPv4 header.

          ii. A value of 1 represents the "Router Alert Label".  This
              label value is legal anywhere in the label stack except at
              the bottom.  When a received packet contains this label
              value at the top of the label stack, it is delivered to a
              local software module for processing.  The actual
              forwarding of the packet is determined by the label
              beneath it in the stack.  However, if the packet is
              forwarded further, the Router Alert Label should be pushed
              back onto the label stack before forwarding.  The use of
              this label is analogous to the use of the "Router Alert
              Option" in IP packets [5].  Since this label cannot occur
              at the bottom of the stack, it is not associated with a
              particular network layer protocol.

         iii. A value of 2 represents the "IPv6 Explicit NULL Label".
              This label value is only legal at the bottom of the label
              stack.  It indicates that the label stack must be popped,
              and the forwarding of the packet must then be based on the
              IPv6 header.

          iv. A value of 3 represents the "Implicit NULL Label".  This
              is a label that an LSR may assign and distribute, but
              which never actually appears in the encapsulation.  When
              an LSR would otherwise replace the label at the top of the
              stack with a new label, but the new label is "Implicit
              NULL", the LSR will pop the stack instead of doing the
              replacement.  Although this value may never appear in the
              encapsulation, it needs to be specified in the Label
              Distribution Protocol, so a value is reserved.

           v. Values 4-15 are reserved.

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



Rosen, et al.               Standards Track                     [Page 5]

RFC 3032               MPLS Label Stack Encoding            January 2001


   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.

2.3. Generating ICMP Messages for Labeled IP Packets