rfc3031.txt

RFC 的详细文档！

   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.

   When these conditions hold, an LSR may use labels that have "per
   interface" scope, i.e., which are only unique per interface.  We may
   say that the LSR is using a "per-interface label space".  When these
   conditions do not hold, the labels must be unique over the LSR which
   has assigned them, and we may say that the LSR is using a "per-
   platform label space."

   If a particular LSR Rd is attached to a particular LSR Ru over two
   point-to-point interfaces, then Rd may distribute to Ru a binding of
   label L to FEC F1, as well as a binding of label L to FEC F2, F1 !=
   F2, if and only if each binding is valid only for packets which Ru
   sends to Rd over a particular one of the interfaces.  In all other
   cases, Rd MUST NOT distribute to Ru bindings of the same label value
   to two different FECs.

   This prohibition holds even if the bindings are regarded as being at
   different "levels of hierarchy".  In MPLS, there is no notion of
   having a different label space for different levels of the hierarchy;
   when interpreting a label, the level of the label is irrelevant.

   The question arises as to whether it is possible for an LSR to use
   multiple per-platform label spaces, or to use multiple per-interface
   label spaces for the same interface.  This is not prohibited by the
   architecture.  However, in such cases the LSR must have some means,
   not specified by the architecture, of determining, for a particular
   incoming label, which label space that label belongs to.  For
   example, [MPLS-SHIM] specifies that a different label space is used
   for unicast packets than for multicast packets, and uses a data link
   layer codepoint to distinguish the two label spaces.

3.15. Label Switched Path (LSP), LSP Ingress, LSP Egress

   A "Label Switched Path (LSP) of level m" for a particular packet P is
   a sequence of routers,

                               <R1, ..., Rn>

   with the following properties:



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


      1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's
         label stack, resulting in a label stack of depth m;

      2. For all i, 1<i<n, P has a label stack of depth m when received
         by LSR Ri;

      3. At no time during P's transit from R1 to R[n-1] does its label
         stack ever have a depth of less than m;

      4. For all i, 1<i<n: Ri transmits P to R[i+1] by means of MPLS,
         i.e., by using the label at the top of the label stack (the
         level m label) as an index into an ILM;

      5. For all i, 1<i<n: if a system S receives and forwards P after P
         is transmitted by Ri but before P is received by R[i+1] (e.g.,
         Ri and R[i+1] might be connected via a switched data link
         subnetwork, and S might be one of the data link switches), then
         S's forwarding decision is not based on the level m label, or
         on the network layer header.  This may be because:

         a) the decision is not based on the label stack or the network
            layer header at all;

         b) the decision is based on a label stack on which additional
            labels have been pushed (i.e., on a level m+k label, where
            k>0).

   In other words, we can speak of the level m LSP for Packet P as the
   sequence of routers:

      1. which begins with an LSR (an "LSP Ingress") that pushes on a
         level m label,

      2. all of whose intermediate LSRs make their forwarding decision
         by label Switching on a level m label,

      3. which ends (at an "LSP Egress") when a forwarding decision is
         made by label Switching on a level m-k label, where k>0, or
         when a forwarding decision is made by "ordinary", non-MPLS
         forwarding procedures.

   A consequence (or perhaps a presupposition) of this is that whenever
   an LSR pushes a label onto an already labeled packet, it needs to
   make sure that the new label corresponds to a FEC whose LSP Egress is
   the LSR that assigned the label which is now second in the stack.






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


   We will call a sequence of LSRs the "LSP for a particular FEC F" if
   it is an LSP of level m for a particular packet P when P's level m
   label is a label corresponding to FEC F.

   Consider the set of nodes which may be LSP ingress nodes for FEC F.
   Then there is an LSP for FEC F which begins with each of those nodes.
   If a number of those LSPs have the same LSP egress, then one can
   consider the set of such LSPs to be a tree, whose root is the LSP
   egress.  (Since data travels along this tree towards the root, this
   may be called a multipoint-to-point tree.)  We can thus speak of the
   "LSP tree" for a particular FEC F.

3.16. Penultimate Hop Popping

   Note that according to the definitions of section 3.15, if <R1, ...,
   Rn> is a level m LSP for packet P, P may be transmitted from R[n-1]
   to Rn with a label stack of depth m-1.  That is, the label stack may
   be popped at the penultimate LSR of the LSP, rather than at the LSP
   Egress.

   From an architectural perspective, this is perfectly appropriate.
   The purpose of the level m label is to get the packet to Rn.  Once
   R[n-1] has decided to send the packet to Rn, the label no longer has
   any function, and need no longer be carried.

   There is also a practical advantage to doing penultimate hop popping.
   If one does not do this, then when the LSP egress receives a packet,
   it first looks up the top label, and determines as a result of that
   lookup that it is indeed the LSP egress.  Then it must pop the stack,
   and examine what remains of the packet.  If there is another label on
   the stack, the egress will look this up and forward the packet based
   on this lookup.  (In this case, the egress for the packet's level m
   LSP is also an intermediate node for its level m-1 LSP.)  If there is
   no other label on the stack, then the packet is forwarded according
   to its network layer destination address.  Note that this would
   require the egress to do TWO lookups, either two label lookups or a
   label lookup followed by an address lookup.

   If, on the other hand, penultimate hop popping is used, then when the
   penultimate hop looks up the label, it determines:

      -  that it is the penultimate hop, and

      -  who the next hop is.

   The penultimate node then pops the stack, and forwards the packet
   based on the information gained by looking up the label that was
   previously at the top of the stack.  When the LSP egress receives the



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


   packet, the label which is now at the top of the stack will be the
   label which it needs to look up in order to make its own forwarding
   decision.  Or, if the packet was only carrying a single label, the
   LSP egress will simply see the network layer packet, which is just
   what it needs to see in order to make its forwarding decision.

   This technique allows the egress to do a single lookup, and also
   requires only a single lookup by the penultimate node.

   The creation of the forwarding "fastpath" in a label switching
   product may be greatly aided if it is known that only a single lookup
   is ever required:

      -  the code may be simplified if it can assume that only a single
         lookup is ever needed

      -  the code can be based on a "time budget" that assumes that only
         a single lookup is ever needed.

   In fact, when penultimate hop popping is done, the LSP Egress need
   not even be an LSR.

   However, some hardware switching engines may not be able to pop the
   label stack, so this cannot be universally required.  There may also
   be some situations in which penultimate hop popping is not desirable.
   Therefore the penultimate node pops the label stack only if this is
   specifically requested by the egress node, OR if the next node in the
   LSP does not support MPLS.  (If the next node in the LSP does support
   MPLS, but does not make such a request, the penultimate node has no
   way of knowing that it in fact is the penultimate node.)

   An LSR which is capable of popping the label stack at all MUST do
   penultimate hop popping when so requested by its downstream label
   distribution peer.

   Initial label distribution protocol negotiations MUST allow each LSR
   to determine whether its neighboring LSRS are capable of popping the
   label stack.  A LSR MUST NOT request a label distribution peer to pop
   the label stack unless it is capable of doing so.

   It may be asked whether the egress node can always interpret the top
   label of a received packet properly if penultimate hop popping is
   used.  As long as the uniqueness and scoping rules of section 3.14
   are obeyed, it is always possible to interpret the top label of a
   received packet unambiguously.






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


3.17. LSP Next Hop

   The LSP Next Hop for a particular labeled packet in a particular LSR
   is the LSR which is the next hop, as selected by the NHLFE entry used
   for forwarding that packet.

   The LSP Next Hop for a particular FEC is the next hop as selected by
   the NHLFE entry indexed by a label which corresponds to that FEC.

   Note that the LSP Next Hop may differ from the next hop which would
   be chosen by the network layer routing algorithm.  We will use the
   term "L3 next hop" when we refer to the latter.

3.18. Invalid Incoming Labels

   What should an LSR do if it receives a labeled packet with a
   particular incoming label, but has no binding for that label?  It is
   tempting to think that the labels can just be removed, and the packet
   forwarded as an unlabeled IP packet.  However, in some cases, doing
   so could cause a loop.  If the upstream LSR thinks the label is bound
   to an explicit route, and the downstream LSR doesn't think the label
   is bound to anything, and if the hop by hop routing of the unlabeled
   IP packet brings the packet back to the upstream LSR, then a loop is
   formed.

   It is also possible that the label was intended to represent a route
   which cannot be inferred from the IP header.

   Therefore, when a labeled packet is received with an invalid incoming
   label, it MUST be discarded, UNLESS it is determined by some means
   (not within the scope of the current document) that forwarding it
   unlabeled cannot cause any harm.

3.19. LSP Control: Ordered versus Independent

   Some FECs correspond to address prefixes which are distributed via a
   dynamic routing algorithm.  The setup of the LSPs for these FECs can
   be done in one of two ways: Independent LSP Control or Ordered LSP
   Control.

   In Independent LSP Control, each LSR, upon noting that it recognizes
   a particular FEC, makes an independent decision to bind a label to
   that FEC and to distribute that binding to its label distribution
   peers.  This corresponds to the way that conventional IP datagram
   routing works; each node makes an independent decision as to how to
   treat each packet, and relies on the routing algorithm to converge