rfc3031.txt

RFC 的详细文档！

   rapidly so as to ensure that each datagram is correctly delivered.




Rosen, et al.               Standards Track                    [Page 20]

RFC 3031                   MPLS Architecture                January 2001


   In Ordered LSP Control, an LSR only binds a label to a particular FEC
   if it is the egress LSR for that FEC, or if it has already received a
   label binding for that FEC from its next hop for that FEC.

   If one wants to ensure that traffic in a particular FEC follows a
   path with some specified set of properties (e.g., that the traffic
   does not traverse any node twice, that a specified amount of
   resources are available to the traffic, that the traffic follows an
   explicitly specified path, etc.)  ordered control must be used.  With
   independent control, some LSRs may begin label switching a traffic in
   the FEC before the LSP is completely set up, and thus some traffic in
   the FEC may follow a path which does not have the specified set of
   properties.  Ordered control also needs to be used if the recognition
   of the FEC is a consequence of the setting up of the corresponding
   LSP.

   Ordered LSP setup may be initiated either by the ingress or the
   egress.

   Ordered control and independent control are fully interoperable.
   However, unless all LSRs in an LSP are using ordered control, the
   overall effect on network behavior is largely that of independent
   control, since one cannot be sure that an LSP is not used until it is
   fully set up.

   This architecture allows the choice between independent control and
   ordered control to be a local matter.  Since the two methods
   interwork, a given LSR need support only one or the other.  Generally
   speaking, the choice of independent versus ordered control does not
   appear to have any effect on the label distribution mechanisms which
   need to be defined.

3.20. Aggregation

   One way of partitioning traffic into FECs is to create a separate FEC
   for each address prefix which appears in the routing table.  However,
   within a particular MPLS domain, this may result in a set of FECs
   such that all traffic in all those FECs follows the same route.  For
   example, a set of distinct address prefixes might all have the same
   egress node, and label swapping might be used only to get the the
   traffic to the egress node.  In this case, within the MPLS domain,
   the union of those FECs is itself a FEC.  This creates a choice:
   should a distinct label be bound to each component FEC, or should a
   single label be bound to the union, and that label applied to all
   traffic in the union?

   The procedure of binding a single label to a union of FECs which is
   itself a FEC (within some domain), and of applying that label to all



Rosen, et al.               Standards Track                    [Page 21]

RFC 3031                   MPLS Architecture                January 2001


   traffic in the union, is known as "aggregation".  The MPLS
   architecture allows aggregation.  Aggregation may reduce the number
   of labels which are needed to handle a particular set of packets, and
   may also reduce the amount of label distribution control traffic
   needed.

   Given a set of FECs which are "aggregatable" into a single FEC, it is
   possible to (a) aggregate them into a single FEC, (b) aggregate them
   into a set of FECs, or (c) not aggregate them at all.  Thus we can
   speak of the "granularity" of aggregation, with (a) being the
   "coarsest granularity", and (c) being the "finest granularity".

   When order control is used, each LSR should adopt, for a given set of
   FECs, the granularity used by its next hop for those FECs.

   When independent control is used, it is possible that there will be
   two adjacent LSRs, Ru and Rd, which aggregate some set of FECs
   differently.

   If Ru has finer granularity than Rd, this does not cause a problem.
   Ru distributes more labels for that set of FECs than Rd does.  This
   means that when Ru needs to forward labeled packets in those FECs to
   Rd, it may need to map n labels into m labels, where n > m.  As an
   option, Ru may withdraw the set of n labels that it has distributed,
   and then distribute a set of m labels, corresponding to Rd's level of
   granularity.  This is not necessary to ensure correct operation, but
   it does result in a reduction of the number of labels distributed by
   Ru, and Ru is not gaining any particular advantage by distributing
   the larger number of labels.  The decision whether to do this or not
   is a local matter.

   If Ru has coarser granularity than Rd (i.e., Rd has distributed n
   labels for the set of FECs, while Ru has distributed m, where n > m),
   it has two choices:

      -  It may adopt Rd's finer level of granularity.  This would
         require it to withdraw the m labels it has distributed, and
         distribute n labels.  This is the preferred option.

      -  It may simply map its m labels into a subset of Rd's n labels,
         if it can determine that this will produce the same routing.
         For example, suppose that Ru applies a single label to all
         traffic that needs to pass through a certain egress LSR,
         whereas Rd binds a number of different labels to such traffic,
         depending on the individual destination addresses of the
         packets.  If Ru knows the address of the egress router, and if
         Rd has bound a label to the FEC which is identified by that
         address, then Ru can simply apply that label.



Rosen, et al.               Standards Track                    [Page 22]

RFC 3031                   MPLS Architecture                January 2001


   In any event, every LSR needs to know (by configuration) what
   granularity to use for labels that it assigns.  Where ordered control
   is used, this requires each node to know the granularity only for
   FECs which leave the MPLS network at that node.  For independent
   control, best results may be obtained by ensuring that all LSRs are
   consistently configured to know the granularity for each FEC.
   However, in many cases this may be done by using a single level of
   granularity which applies to all FECs (such as "one label per IP
   prefix in the forwarding table", or "one label per egress node").

3.21. Route Selection

   Route selection refers to the method used for selecting the LSP for a
   particular FEC.  The proposed MPLS protocol architecture supports two
   options for Route Selection: (1) hop by hop routing, and (2) explicit
   routing.

   Hop by hop routing allows each node to independently choose the next
   hop for each FEC.  This is the usual mode today in existing IP
   networks.  A "hop by hop routed LSP" is an LSP whose route is
   selected using hop by hop routing.

   In an explicitly routed LSP, each LSR does not independently choose
   the next hop; rather, a single LSR, generally the LSP ingress or the
   LSP egress, specifies several (or all) of the LSRs in the LSP.  If a
   single LSR specifies the entire LSP, the LSP is "strictly" explicitly
   routed.  If a single LSR specifies only some of the LSP, the LSP is
   "loosely" explicitly routed.

   The sequence of LSRs followed by an explicitly routed LSP may be
   chosen by configuration, or may be selected dynamically by a single
   node (for example, the egress node may make use of the topological
   information learned from a link state database in order to compute
   the entire path for the tree ending at that egress node).

   Explicit routing may be useful for a number of purposes, such as
   policy routing or traffic engineering.  In MPLS, the explicit route
   needs to be specified at the time that labels are assigned, but the
   explicit route does not have to be specified with each IP packet.
   This makes MPLS explicit routing much more efficient than the
   alternative of IP source routing.

   The procedures for making use of explicit routes, either strict or
   loose, are beyond the scope of this document.







Rosen, et al.               Standards Track                    [Page 23]

RFC 3031                   MPLS Architecture                January 2001


3.22. Lack of Outgoing Label

   When a labeled packet is traveling along an LSP, it may occasionally
   happen that it reaches an LSR at which the ILM does not map the
   packet's incoming label into an NHLFE, even though the incoming label
   is itself valid.  This can happen due to transient conditions, or due
   to an error at the LSR which should be the packet's next hop.

   It is tempting in such cases to strip off the label stack and attempt
   to forward the packet further via conventional forwarding, based on
   its network layer header.  However, in general this is not a safe
   procedure:

      -  If the packet has been following an explicitly routed LSP, this
         could result in a loop.

      -  The packet's network header may not contain enough information
         to enable this particular LSR to forward it correctly.

   Unless it can be determined (through some means outside the scope of
   this document) that neither of these situations obtains, the only
   safe procedure is to discard the packet.

3.23. Time-to-Live (TTL)

   In conventional IP forwarding, each packet carries a "Time To Live"
   (TTL) value in its header.  Whenever a packet passes through a
   router, its TTL gets decremented by 1; if the TTL reaches 0 before
   the packet has reached its destination, the packet gets discarded.

   This provides some level of protection against forwarding loops that
   may exist due to misconfigurations, or due to failure or slow
   convergence of the routing algorithm.  TTL is sometimes used for
   other functions as well, such as multicast scoping, and supporting
   the "traceroute" command.  This implies that there are two TTL-
   related issues that MPLS needs to deal with: (i) TTL as a way to
   suppress loops; (ii) TTL as a way to accomplish other functions, such
   as limiting the scope of a packet.

   When a packet travels along an LSP, it SHOULD emerge with the same
   TTL value that it would have had if it had traversed the same
   sequence of routers without having been label switched.  If the
   packet travels along a hierarchy of LSPs, the total number of LSR-
   hops traversed SHOULD be reflected in its TTL value when it emerges
   from the hierarchy of LSPs.






Rosen, et al.               Standards Track                    [Page 24]

RFC 3031                   MPLS Architecture                January 2001


   The way that TTL is handled may vary depending upon whether the MPLS
   label values are carried in an MPLS-specific "shim" header [MPLS-
   SHIM], or if the MPLS labels are carried in an L2 header, such as an
   ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY].

   If the label values are encoded in a "shim" that sits between the
   data link and network layer headers, then this shim MUST have a TTL
   field that SHOULD be initially loaded from the network layer header
   TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be
   copied into the network layer header TTL field when the packet
   emerges from its LSP.

   If the label values are encoded in a data link layer header (e.g.,
   the VPI/VCI field in ATM's AAL5 header), and the labeled packets are
   forwarded by an L2 switch (e.g., an ATM switch), and the data link
   layer (like ATM) does not itself have a TTL field, then it will not
   be possible to decrement a packet's TTL at each LSR-hop.  An LSP
   segment which consists of a sequence of LSRs that cannot decrement a
   packet's TTL will be called a "non-TTL LSP segment".

   When a packet emerges from a non-TTL LSP segment, it SHOULD however
   be given a TTL that reflects the number of LSR-hops it traversed.  In
   the unicast case, this can be achieved by propagating a meaningful
   LSP length to ingress nodes, enabling the ingress to decrement the
   TTL value before forwarding packets into a non-TTL LSP segment.

   Sometimes it can be determined, upon ingress to a non-TTL LSP
   segment, that a particular packet's TTL will expire before the packet
   reaches the egress of that non-TTL LSP segment.  In this case, the
   LSR at the ingress to the non-TTL LSP segment must not label switch
   the packet.  This means that special procedures must be developed to
   support traceroute functionality, for example, traceroute packets may
   be forwarded using conventional hop by hop forwarding.

3.24. Loop Control

   On a non-TTL LSP segment, by definition, TTL cannot be used to
   protect against forwarding loops.  The importance of loop control may
   depend on the particular hardware being used to provide the LSR
   functions along the non-TTL LSP segment.

   Suppose, for instance, that ATM switching hardware is being used to
   provide MPLS switching functions, with the label being carried in the
   VPI/VCI field.  Since ATM switching hardware cann