rfc3032.txt

RFC 的详细文档！

   Section 2.4 and section 3 discuss situations in which it is desirable
   to generate ICMP messages for labeled IP packets.  In order for a
   particular LSR to be able to generate an ICMP packet and have that
   packet sent to the source of the IP packet, two conditions must hold:

      1. it must be possible for that LSR to determine that a particular
         labeled packet is an IP packet;

      2. it must be possible for that LSR to route to the packet's IP
         source address.



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


   Condition 1 is discussed in section 2.2.  The following two
   subsections discuss condition 2.  However, there will be some cases
   in which condition 2 does not hold at all, and in these cases it will
   not be possible to generate the ICMP message.

2.3.1. Tunneling through a Transit Routing Domain

   Suppose one is using MPLS to "tunnel" through a transit routing
   domain, where the external routes are not leaked into the domain's
   interior routers.  For example, the interior routers may be running
   OSPF, and may only know how to reach destinations within that OSPF
   domain.  The domain might contain several Autonomous System Border
   Routers (ASBRs), which talk BGP to each other.  However, in this
   example the routes from BGP are not distributed into OSPF, and the
   LSRs which are not ASBRs do not run BGP.

   In this example, only an ASBR will know how to route to the source of
   some arbitrary packet.  If an interior router needs to send an ICMP
   message to the source of an IP packet, it will not know how to route
   the ICMP message.

   One solution is to have one or more of the ASBRs inject "default"
   into the IGP.  (N.B.: this does NOT require that there be a "default"
   carried by BGP.)  This would then ensure that any unlabeled packet
   which must leave the domain (such as an ICMP packet) gets sent to a
   router which has full routing information.  The routers with full
   routing information will label the packets before sending them back
   through the transit domain, so the use of default routing within the
   transit domain does not cause any loops.

   This solution only works for packets which have globally unique
   addresses, and for networks in which all the ASBRs have complete
   routing information.  The next subsection describes a solution which
   works when these conditions do not hold.

2.3.2. Tunneling Private Addresses through a Public Backbone

   In some cases where MPLS is used to tunnel through a routing domain,
   it may not be possible to route to the source address of a fragmented
   packet at all.  This would be the case, for example, if the IP
   addresses carried in the packet were private (i.e., not globally
   unique) addresses, and MPLS were being used to tunnel those packets
   through a public backbone.  Default routing to an ASBR will not work
   in this environment.

   In this environment, in order to send an ICMP message to the source
   of a packet, one can copy the label stack from the original packet to
   the ICMP message, and then label switch the ICMP message.  This will



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


   cause the message to proceed in the direction of the original
   packet's destination, rather than its source.  Unless the message is
   label switched all the way to the destination host, it will end up,
   unlabeled, in a router which does know how to route to the source of
   original packet, at which point the message will be sent in the
   proper direction.

   This technique can be very useful if the ICMP message is a "Time
   Exceeded" message or a "Destination Unreachable because fragmentation
   needed and DF set" message.

   When copying the label stack from the original packet to the ICMP
   message, the label values must be copied exactly, but the TTL values
   in the label stack should be set to the TTL value that is placed in
   the IP header of the ICMP message.  This TTL value should be long
   enough to allow the circuitous route that the ICMP message will need
   to follow.

   Note that if a packet's TTL expiration is due to the presence of a
   routing loop, then if this technique is used, the ICMP message may
   loop as well.  Since an ICMP message is  never sent as a result of
   receiving an ICMP message, and since many implementations throttle
   the rate at which ICMP messages can be generated, this is not
   expected to pose a problem.

2.4. Processing the Time to Live Field

2.4.1. Definitions

   The "incoming TTL" of a labeled packet is defined to be the value of
   the TTL field of the top label stack entry when the packet is
   received.

   The "outgoing TTL" of a labeled packet is defined to be the larger
   of:

      a) one less than the incoming TTL,
      b) zero.

2.4.2. Protocol-independent rules

   If the outgoing TTL of a labeled packet is 0, then the labeled packet
   MUST NOT be further forwarded; nor may the label stack be stripped
   off and the packet forwarded as an unlabeled packet.  The packet's
   lifetime in the network is considered to have expired.






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


   Depending on the label value in the label stack entry, the packet MAY
   be simply discarded, or it may be passed to the appropriate
   "ordinary" network layer for error processing (e.g., for the
   generation of an ICMP error message, see section 2.3).

   When a labeled packet is forwarded, the TTL field of the label stack
   entry at the top of the label stack MUST be set to the outgoing TTL
   value.

   Note that the outgoing TTL value is a function solely of the incoming
   TTL value, and is independent of whether any labels are pushed or
   popped before forwarding.  There is no significance to the value of
   the TTL field in any label stack entry which is not at the top of the
   stack.

2.4.3. IP-dependent rules

   We define the "IP TTL" field to be the value of the IPv4 TTL field,
   or the value of the IPv6 Hop Limit field, whichever is applicable.

   When an IP packet is first labeled, the TTL field of the label stack
   entry MUST BE set to the value of the IP TTL field.  (If the IP TTL
   field needs to be decremented, as part of the IP processing, it is
   assumed that this has already been done.)

   When a label is popped, and the resulting label stack is empty, then
   the value of the IP TTL field SHOULD BE replaced with the outgoing
   TTL value, as defined above.  In IPv4 this also requires modification
   of the IP header checksum.

   It is recognized that there may be situations where a network
   administration prefers to decrement the IPv4 TTL by one as it
   traverses an MPLS domain, instead of decrementing the IPv4 TTL by the
   number of LSP hops within the domain.

2.4.4. Translating Between Different Encapsulations

   Sometimes an LSR may receive a labeled packet over, e.g., a label
   switching controlled ATM (LC-ATM) interface [9], and may need to send
   it out over a PPP or LAN link.  Then the incoming packet will not be
   received using the encapsulation specified in this document, but the
   outgoing packet will be sent using the encapsulation specified in
   this document.

   In this case, the value of the "incoming TTL" is determined by the
   procedures used for carrying labeled packets on, e.g., LC-ATM
   interfaces.  TTL processing then proceeds as described above.




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


   Sometimes an LSR may receive a labeled packet over a PPP or a LAN
   link, and may need to send it out, say, an LC-ATM interface.  Then
   the incoming packet will be received using the encapsulation
   specified in this document, but the outgoing packet will not be sent
   using the encapsulation specified in this document.  In this case,
   the procedure for carrying the value of the "outgoing TTL" is
   determined by the procedures used for carrying labeled packets on,
   e.g., LC-ATM interfaces.

3. Fragmentation and Path MTU Discovery

   Just as it is possible to receive an unlabeled IP datagram which is
   too large to be transmitted on its output link, it is possible to
   receive a labeled packet which is too large to be transmitted on its
   output link.

   It is also possible that a received packet (labeled or unlabeled)
   which was originally small enough to be transmitted on that link
   becomes too large by virtue of having one or more additional labels
   pushed onto its label stack.  In label switching, a packet may grow
   in size if additional labels get pushed on.  Thus if one receives a
   labeled packet with a 1500-byte frame payload, and pushes on an
   additional label, one needs to forward it as frame with a 1504-byte
   payload.

   This section specifies the rules for processing labeled packets which
   are "too large".  In particular, it provides rules which ensure that
   hosts implementing Path MTU Discovery [4], and hosts using IPv6
   [7,8], will be able to generate IP datagrams that do not need
   fragmentation, even if those datagrams get labeled as they traverse
   the network.

   In general, IPv4 hosts which do not implement Path MTU Discovery [4]
   send IP datagrams which contain no more than 576 bytes.  Since the
   MTUs in use on most data links today are 1500 bytes or more, the
   probability that such datagrams will need to get fragmented, even if
   they get labeled, is very small.

   Some hosts that do not implement Path MTU Discovery [4] will generate
   IP datagrams containing 1500 bytes, as long as the IP Source and
   Destination addresses are on the same subnet.  These datagrams will
   not pass through routers, and hence will not get fragmented.

   Unfortunately, some hosts will generate IP datagrams containing 1500
   bytes, as long the IP Source and Destination addresses have the same
   classful network number.  This is the one case in which there is any
   risk of fragmentation when such datagrams get labeled.  (Even so,




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


   fragmentation is not likely unless the packet must traverse an
   ethernet of some sort between the time it first gets labeled and the
   time it gets unlabeled.)

   This document specifies procedures which allow one to configure the
   network so that large datagrams from hosts which do not implement
   Path MTU Discovery get fragmented just once, when they are first
   labeled.  These procedures make it possible (assuming suitable
   configuration) to avoid any need to fragment packets which have
   already been labeled.

3.1. Terminology

   With respect to a particular data link, we can use the following
   terms:

      -  Frame Payload:

         The contents of a data link frame, excluding any data link
         layer headers or trailers (e.g., MAC headers, LLC headers,
         802.1Q headers, PPP header, frame check sequences, etc.).

         When a frame is carrying an unlabeled IP datagram, the Frame
         Payload is just the IP datagram itself.  When a frame is
         carrying a labeled IP datagram, the Frame Payload consists of
         the label stack entries and the IP datagram.

      -  Conventional Maximum Frame Payload Size:

         The maximum Frame Payload size allowed by data link standards.
         For example, the Conventional Maximum Frame Payload Size for
         ethernet is 1500 bytes.

      -  True Maximum Frame Payload Size:

         The maximum size frame payload which can be sent and received
         properly by the interface hardware attached to the data link.

         On ethernet and 802.3 networks, it is believed that the True
         Maximum Frame Payload Size is 4-8 bytes larger than the
         Conventional Maximum Frame Payload Size (as long as neither an
         802.1Q header nor an 802.1p header is present, and as long as
         neither can be added by a switch or bridge while a packet is in
         transit to its next hop).  For example, it is believed that
         most ethernet equipment could correctly send and receive
         packets carrying a payload of 1504 or perhaps even 1508 bytes,
         at least, as long as the ethernet header does not have an
         802.1Q or 802.1p field.



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


         On PPP links, the True Maximum Frame Payload Size may be
         virtually unbounded.

      -  Effective Maximum Frame Payload Size for Labeled Packets:

         This is either the Conventional Maximum Frame Payload Size or
         the True Maximum Frame Payload Size, depending on the
         capabilities of the equipment on the data link and the size of
         the data link header being used.

      -  Initially Labeled IP Datagram:

         Suppose that an unlabeled IP datagram is received at a
         particular LSR, and that the the LSR pushes on a label before
         forwarding the datagram.  Such a datagram will be called an
         Initially Labeled IP Datagram at that LSR.

      -  Previously Labeled IP Datagram:

         An IP datagram which had already been labeled before it was
         received by a particular LSR.

3.2. Maximum Initially Labeled IP Datagram Size