rfc3032.txt

最新的RFC

   Every LSR which is capable of

      a) receiving an unlabeled IP datagram,
      b) adding a label stack to the datagram, and
      c) forwarding the resulting labeled packet,

   SHOULD support a configuration parameter known as the "Maximum
   Initially Labeled IP Datagram Size", which can be set to a non-
   negative value.

   If this configuration parameter is set to zero, it has no effect.

   If it is set to a positive value, it is used in the following way.
   If:

      a) an unlabeled IP datagram is received, and
      b) that datagram does not have the DF bit set in its IP header,
         and
      c) that datagram needs to be labeled before being forwarded, and
      d) the size of the datagram (before labeling) exceeds the value of
         the parameter,
   then
      a) the datagram must be broken into fragments, each of whose size
         is no greater than the value of the parameter, and



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


      b) each fragment must be labeled and then forwarded.

   For example, if this configuration parameter is set to a value of
   1488, then any unlabeled IP datagram containing more than 1488 bytes
   will be fragmented before being labeled.  Each fragment will be
   capable of being carried on a 1500-byte data link, without further
   fragmentation, even if as many as three labels are pushed onto its
   label stack.

   In other words, setting this parameter to a non-zero value allows one
   to eliminate all fragmentation of Previously Labeled IP Datagrams,
   but it may cause some unnecessary fragmentation of Initially Labeled
   IP Datagrams.

   Note that the setting of this parameter does not affect the
   processing of IP datagrams that have the DF bit set; hence the result
   of Path MTU discovery is unaffected by the setting of this parameter.

3.3. When are Labeled IP Datagrams Too Big?

   A labeled IP datagram whose size exceeds the Conventional Maximum
   Frame Payload Size of the data link over which it is to be forwarded
   MAY be considered to be "too big".

   A labeled IP datagram whose size exceeds the True Maximum Frame
   Payload Size of the data link over which it is to be forwarded MUST
   be considered to be "too big".

   A labeled IP datagram which is not "too big" MUST be transmitted
   without fragmentation.

3.4. Processing Labeled IPv4 Datagrams which are Too Big

   If a labeled IPv4 datagram is "too big", and the DF bit is not set in
   its IP header, then the LSR MAY silently discard the datagram.

   Note that discarding such datagrams is a sensible procedure only if
   the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero
   value in every LSR in the network which is capable of adding a label
   stack to an unlabeled IP datagram.

   If the LSR chooses not to discard a labeled IPv4 datagram which is
   too big, or if the DF bit is set in that datagram, then it MUST
   execute the following algorithm:

      1. Strip off the label stack entries to obtain the IP datagram.





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


      2. Let N be the number of bytes in the label stack (i.e, 4 times
         the number of label stack entries).

      3. If the IP datagram does NOT have the "Don't Fragment" bit set
         in its IP header:

         a. convert it into fragments, each of which MUST be at least N
            bytes less than the Effective Maximum Frame Payload Size.

         b. Prepend each fragment with the same label header that would
            have been on the original datagram had fragmentation not
            been necessary.

         c. Forward the fragments

      4. If the IP datagram has the "Don't Fragment" bit set in its IP
         header:

         a. the datagram MUST NOT be forwarded

         b. Create an ICMP Destination Unreachable Message:

             i. set its Code field [3] to "Fragmentation Required and DF
                Set",

            ii. set its Next-Hop MTU field [4] to the difference between
                the Effective Maximum Frame Payload Size and the value
                of N

         c. If possible, transmit the ICMP Destination Unreachable
            Message to the source of the of the discarded datagram.

3.5. Processing Labeled IPv6 Datagrams which are Too Big

   To process a labeled IPv6 datagram which is too big, an LSR MUST
   execute the following algorithm:

      1. Strip off the label stack entries to obtain the IP datagram.

      2. Let N be the number of bytes in the label stack (i.e., 4 times
         the number of label stack entries).

      3. If the IP datagram contains more than 1280 bytes (not counting
         the label stack entries), or if it does not contain a fragment
         header, then:






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


         a. Create an ICMP Packet Too Big Message, and set its Next-Hop
            MTU field to the difference between the Effective Maximum
            Frame Payload Size and the value of N

         b. If possible, transmit the ICMP Packet Too Big Message to the
            source of the datagram.

         c. discard the labeled IPv6 datagram.

      4. If the IP datagram is not larger than 1280 octets, and it
         contains a fragment header, then

         a. Convert it into fragments, each of which MUST be at least N
            bytes less than the Effective Maximum Frame Payload Size.

         b. Prepend each fragment with the same label header that would
            have been on the original datagram had fragmentation not
            been necessary.

         c. Forward the fragments.

         Reassembly of the fragments will be done at the destination
         host.

3.6. Implications with respect to Path MTU Discovery

   The procedures described above for handling datagrams which have the
   DF bit set, but which are "too large", have an impact on the Path MTU
   Discovery procedures of RFC 1191 [4].  Hosts which implement these
   procedures will discover an MTU which is small enough to allow n
   labels to be pushed on the datagrams, without need for fragmentation,
   where n is the number of labels that actually get pushed on along the
   path currently in use.

   In other words, datagrams from hosts that use Path MTU Discovery will
   never need to be fragmented due to the need to put on a label header,
   or to add new labels to an existing label header.  (Also, datagrams
   from hosts that use Path MTU Discovery generally have the DF bit set,
   and so will never get fragmented anyway.)

   Note that Path MTU Discovery will only work properly if, at the point
   where a labeled IP Datagram's fragmentation needs to occur, it is
   possible to cause an ICMP Destination Unreachable message to be
   routed to the packet's source address.  See section 2.3.







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


   If it is not possible to forward an ICMP message from within an MPLS
   "tunnel" to a packet's source address, but the network configuration
   makes it possible for the LSR at the transmitting end of the tunnel
   to receive packets that must go through the tunnel, but are too large
   to pass through the tunnel unfragmented, then:

      -  The LSR at the transmitting end of the tunnel MUST be able to
         determine the MTU of the tunnel as a whole.  It MAY do this by
         sending packets through the tunnel to the tunnel's receiving
         endpoint, and performing Path MTU Discovery with those packets.

      -  Any time the transmitting endpoint of the tunnel needs to send
         a packet into the tunnel, and that packet has the DF bit set,
         and it exceeds the tunnel MTU, the transmitting endpoint of the
         tunnel MUST send the ICMP Destination Unreachable message to
         the source, with code "Fragmentation Required and DF Set", and
         the Next-Hop MTU Field set as described above.

4. Transporting Labeled Packets over PPP

   The Point-to-Point Protocol (PPP) [6] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   defines an extensible Link Control Protocol, and proposes a family of
   Network Control Protocols for establishing and configuring different
   network-layer protocols.

   This section defines the Network Control Protocol for establishing
   and configuring label Switching over PPP.

4.1. Introduction

   PPP has three main components:

      1. A method for encapsulating multi-protocol datagrams.

      2. A Link Control Protocol (LCP) for establishing, configuring,
         and testing the data-link connection.

      3. A family of Network Control Protocols for establishing and
         configuring different network-layer protocols.

   In order to establish communications over a point-to-point link, each
   end of the PPP link must first send LCP packets to configure and test
   the data link.  After the link has been established and optional
   facilities have been negotiated as needed by the LCP, PPP must send
   "MPLS Control Protocol" packets to enable the transmission of labeled
   packets.  Once the "MPLS Control Protocol" has reached the Opened
   state, labeled packets can be sent over the link.



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


   The link will remain configured for communications until explicit LCP
   or MPLS Control Protocol packets close the link down, or until some
   external event occurs (an inactivity timer expires or network
   administrator intervention).

4.2. A PPP Network Control Protocol for MPLS

   The MPLS Control Protocol (MPLSCP) is responsible for enabling and
   disabling the use of label switching on a PPP link.  It uses the same
   packet exchange mechanism as the Link Control Protocol (LCP).  MPLSCP
   packets may not be exchanged until PPP has reached the Network-Layer
   Protocol phase.  MPLSCP packets received before this phase is reached
   should be silently discarded.

   The MPLS Control Protocol is exactly the same as the Link Control
   Protocol [6] with the following exceptions:

      1. Frame Modifications

         The packet may utilize any modifications to the basic frame
         format which have been negotiated during the Link Establishment
         phase.

      2. Data Link Layer Protocol Field

         Exactly one MPLSCP packet is encapsulated in the PPP
         Information field, where the PPP Protocol field indicates type
         hex 8281 (MPLS).

      3. Code field

         Only Codes 1 through 7 (Configure-Request, Configure-Ack,
         Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
         Ack and Code-Reject) are used.  Other Codes should be treated
         as unrecognized and should result in Code-Rejects.

      4. Timeouts

         MPLSCP packets may not be exchanged until PPP has reached the
         Network-Layer Protocol phase.  An implementation should be
         prepared to wait for Authentication and Link Quality
         Determination to finish before timing out waiting for a
         Configure-Ack or other response.  It is suggested that an
         implementation give up only after user intervention or a
         configurable amount of time.






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


      5. Configuration Option Types

         None.

4.3. Sending Labeled Packets

   Before any labeled packets may be communicated, PPP must reach the
   Network-Layer Protocol phase, and the MPLS Control Protocol must
   reach the Opened state.

   Exactly one labeled packet is encapsulated in the PPP Information