rfc3031.txt

最新的RFC

   exists specifically for this purpose.  In other cases, the label may
   reside in an existing data link or network layer header, as long as
   there is a field which is available for that purpose.  The particular
   encoding technique to be used must be agreed to by both the entity
   which encodes the label and the entity which decodes the label.

3.4. Label Assignment and Distribution

   In the MPLS architecture, the decision to bind a particular label L
   to a particular FEC F is made by the LSR which is DOWNSTREAM with
   respect to that binding.  The downstream LSR then informs the
   upstream LSR of the binding.  Thus labels are "downstream-assigned",
   and label bindings are distributed in the "downstream to upstream"
   direction.

   If an LSR has been designed so that it can only look up labels that
   fall into a certain numeric range, then it merely needs to ensure
   that it only binds labels that are in that range.

3.5. Attributes of a Label Binding

   A particular binding of label L to FEC F, distributed by Rd to Ru,
   may have associated "attributes".  If Ru, acting as a downstream LSR,
   also distributes a binding of a label to FEC F, then under certain
   conditions, it may be required to also distribute the corresponding
   attribute that it received from Rd.

3.6. Label Distribution Protocols

   A label distribution protocol is a set of procedures by which one LSR
   informs another of the label/FEC bindings it has made.  Two LSRs
   which use a label distribution protocol to exchange label/FEC binding
   information are known as "label distribution peers" with respect to
   the binding information they exchange.  If two LSRs are label
   distribution peers, we will speak of there being a "label
   distribution adjacency" between them.

   (N.B.: two LSRs may be label distribution peers with respect to some
   set of bindings, but not with respect to some other set of bindings.)

   The label distribution protocol also encompasses any negotiations in
   which two label distribution peers need to engage in order to learn
   of each other's MPLS capabilities.




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


   THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
   DISTRIBUTION PROTOCOL.  In fact, a number of different label
   distribution protocols are being standardized.  Existing protocols
   have been extended so that label distribution can be piggybacked on
   them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]).  New protocols
   have also been defined for the explicit purpose of distributing
   labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].

   In this document, we try to use the acronym "LDP" to refer
   specifically to the protocol defined in [MPLS-LDP]; when speaking of
   label distribution protocols in general, we try to avoid the acronym.

3.7. Unsolicited Downstream vs. Downstream-on-Demand

   The MPLS architecture allows an LSR to explicitly request, from its
   next hop for a particular FEC, a label binding for that FEC.  This is
   known as "downstream-on-demand" label distribution.

   The MPLS architecture also allows an LSR to distribute bindings to
   LSRs that have not explicitly requested them.  This is known as
   "unsolicited downstream" label distribution.

   It is expected that some MPLS implementations will provide only
   downstream-on-demand label distribution, and some will provide only
   unsolicited downstream label distribution, and some will provide
   both.  Which is provided may depend on the characteristics of the
   interfaces which are supported by a particular implementation.
   However, both of these label distribution techniques may be used in
   the same network at the same time.  On any given label distribution
   adjacency, the upstream LSR and the downstream LSR must agree on
   which technique is to be used.

3.8. Label Retention Mode

   An LSR Ru may receive (or have received) a label binding for a
   particular FEC from an LSR Rd, even though Rd is not Ru's next hop
   (or is no longer Ru's next hop) for that FEC.

   Ru then has the choice of whether to keep track of such bindings, or
   whether to discard such bindings.  If Ru keeps track of such
   bindings, then it may immediately begin using the binding again if Rd
   eventually becomes its next hop for the FEC in question.  If Ru
   discards such bindings, then if Rd later becomes the next hop, the
   binding will have to be reacquired.







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


   If an LSR supports "Liberal Label Retention Mode", it maintains the
   bindings between a label and a FEC which are received from LSRs which
   are not its next hop for that  FEC.  If an LSR supports "Conservative
   Label Retention Mode", it discards such bindings.

   Liberal label retention mode allows for quicker adaptation to routing
   changes, but conservative label retention mode though requires an LSR
   to maintain many fewer labels.

3.9. The Label Stack

   So far, we have spoken as if a labeled packet carries only a single
   label.  As we shall see, it is useful to have a more general model in
   which a labeled packet carries a number of labels, organized as a
   last-in, first-out stack.  We refer to this as a "label stack".

   Although, as we shall see, MPLS supports a hierarchy, the processing
   of a labeled packet is completely independent of the level of
   hierarchy.  The processing is always based on the top label, without
   regard for the possibility that some number of other labels may have
   been "above it" in the past, or that some number of other labels may
   be below it at present.

   An unlabeled packet can be thought of as a packet whose label stack
   is empty (i.e., whose label stack has depth 0).

   If a packet's label stack is of depth m, we refer to the label at the
   bottom of the stack as the level 1 label, to the label above it (if
   such exists) as the level 2 label, and to the label at the top of the
   stack as the level m label.

   The utility of the label stack will become clear when we introduce
   the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27).

3.10. The Next Hop Label Forwarding Entry (NHLFE)

   The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
   a labeled packet.  It contains the following information:

   1. the packet's next hop

   2. the operation to perform on the packet's label stack; this is one
      of the following operations:

      a) replace the label at the top of the label stack with a
         specified new label

      b) pop the label stack



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


      c) replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack.

   It may also contain:

      d) the data link encapsulation to use when transmitting the packet

      e) the way to encode the label stack when transmitting the packet

      f) any other information needed in order to properly dispose of
         the packet.

   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.

   If the packet's "next hop" is the current LSR, then the label stack
   operation MUST be to "pop the stack".

3.11. Incoming Label Map (ILM)

   The "Incoming Label Map" (ILM) maps each incoming label to a set of
   NHLFEs.  It is used when forwarding packets that arrive as labeled
   packets.

   If the ILM maps a particular label to a set of NHLFEs that contains
   more than one element, exactly one element of the set must be chosen
   before the packet is forwarded.  The procedures for choosing an
   element from the set are beyond the scope of this document.  Having
   the ILM map a label to a set containing more than one NHLFE may be
   useful if, e.g., it is desired to do load balancing over multiple
   equal-cost paths.

3.12. FEC-to-NHLFE Map (FTN)

   The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs.  It is
   used when forwarding packets that arrive unlabeled, but which are to
   be labeled before being forwarded.






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


   If the FTN maps a particular label to a set of NHLFEs that contains
   more than one element, exactly one element of the set must be chosen
   before the packet is forwarded.  The procedures for choosing an
   element from the set are beyond the scope of this document.  Having
   the FTN map a label to a set containing more than one NHLFE may be
   useful if, e.g., it is desired to do load balancing over multiple
   equal-cost paths.

3.13. Label Swapping

   Label swapping is the use of the following procedures to forward a
   packet.

   In order to forward a labeled packet, a LSR examines the label at the
   top of the label stack.  It uses the ILM to map this label to an
   NHLFE.  Using the information in the NHLFE, it determines where to
   forward the packet, and performs an operation on the packet's label
   stack.  It then encodes the new label stack into the packet, and
   forwards the result.

   In order to forward an unlabeled packet, a LSR analyzes the network
   layer header, to determine the packet's FEC.  It then uses the FTN to
   map this to an NHLFE.  Using the information in the NHLFE, it
   determines where to forward the packet, and performs an operation on
   the packet's label stack.  (Popping the label stack would, of course,
   be illegal in this case.)  It then encodes the new label stack into
   the packet, and forwards the result.

   IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT
   HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE
   DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE.

3.14. Scope and Uniqueness of Labels

   A given LSR Rd may bind label L1 to FEC F, and distribute that
   binding to label distribution peer Ru1.  Rd may also bind label L2 to
   FEC F, and distribute that binding to label distribution peer Ru2.
   Whether or not L1 == L2 is not determined by the architecture; this
   is a local matter.

   A given LSR Rd may bind label L to FEC F1, and distribute that
   binding to label distribution peer Ru1.  Rd may also bind label L to
   FEC F2, and distribute that binding to label distribution peer Ru2.
   IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP
   LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN
   THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2.  In such cases, we
   may say that Rd is using a different "label space" for the labels it
   distributes to Ru1 than for the labels it distributes to Ru2.



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


   In general, Rd can only tell whether it was Ru1 or Ru2 that put the
   particular label value L at the top of the label stack if the
   following conditions hold:

      -  Ru1 and Ru2 are the only label distribution peers to which Rd
         distributed a binding of label value L, and

      -  Ru1 and Ru2 are each directly connected to Rd via a point-to-
         point interface.