tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3031

 
 
 

Multiprotocol Label Switching Architecture

Part 3 of 3, p. 37 to 61
Prev RFC Part

 


prevText      Top      Up      ToC       Page 37 
4. Some Applications of MPLS

4.1. MPLS and Hop by Hop Routed Traffic

   A number of uses of MPLS require that packets with a certain label be
   forwarded along the same hop-by-hop routed path that would be used
   for forwarding a packet with a specified address in its network layer
   destination address field.

4.1.1. Labels for Address Prefixes

   In general, router R determines the next hop for packet P by finding
   the address prefix X in its routing table which is the longest match
   for P's destination address.  That is, the packets in a given FEC are
   just those packets which match a given address prefix in R's routing
   table.  In this case, a FEC can be identified with an address prefix.

   Note that a packet P may be assigned to FEC F, and FEC F may be
   identified with address prefix X, even if P's destination address
   does not match X.

4.1.2. Distributing Labels for Address Prefixes

4.1.2.1. Label Distribution Peers for an Address Prefix

   LSRs R1 and R2 are considered to be label distribution peers for
   address prefix X if and only if one of the following conditions
   holds:

      1. R1's route to X is a route which it learned about via a
         particular instance of a particular IGP, and R2 is a neighbor
         of R1 in that instance of that IGP

      2. R1's route to X is a route which it learned about by some
         instance of routing algorithm A1, and that route is
         redistributed into an instance of routing algorithm A2, and R2
         is a neighbor of R1 in that instance of A2

Top      Up      ToC       Page 38 
      3. R1 is the receive endpoint of an LSP Tunnel that is within
         another LSP, and R2 is a transmit endpoint of that tunnel, and
         R1 and R2 are participants in a common instance of an IGP, and
         are in the same IGP area (if the IGP in question has areas),
         and R1's route to X was learned via that IGP instance, or is
         redistributed by R1 into that IGP instance

      4. R1's route to X is a route which it learned about via BGP, and
         R2 is a BGP peer of R1

   In general, these rules ensure that if the route to a particular
   address prefix is distributed via an IGP, the label distribution
   peers for that address prefix are the IGP neighbors.  If the route to
   a particular address prefix is distributed via BGP, the label
   distribution peers for that address prefix are the BGP peers.  In
   other cases of LSP tunneling, the tunnel endpoints are label
   distribution peers.

4.1.2.2. Distributing Labels

   In order to use MPLS for the forwarding of packets according to the
   hop-by-hop route corresponding to any address prefix, each LSR MUST:

      1. bind one or more labels to each address prefix that appears in
         its routing table;

      2. for each such address prefix X, use a label distribution
         protocol to distribute the binding of a label to X to each of
         its label distribution peers for X.

   There is also one circumstance in which an LSR must distribute a
   label binding for an address prefix, even if it is not the LSR which
   bound that label to that address prefix:

      3. If R1 uses BGP to distribute a route to X, naming some other
         LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has
         assigned label L to X, then R1 must distribute the binding
         between L and X to any BGP peer to which it distributes that
         route.

   These rules ensure that labels corresponding to address prefixes
   which correspond to BGP routes are distributed to IGP neighbors if
   and only if the BGP routes are distributed into the IGP.  Otherwise,
   the labels bound to BGP routes are distributed only to the other BGP
   speakers.

   These rules are intended only to indicate which label bindings must
   be distributed by a given LSR to which other LSRs.

Top      Up      ToC       Page 39 
4.1.3. Using the Hop by Hop path as the LSP

   If the hop-by-hop path that packet P needs to follow is <R1, ...,
   Rn>, then <R1, ..., Rn> can be an LSP as long as:

      1. there is a single address prefix X, such that, for all i,
         1<=i<n, X is the longest match in Ri's routing table for P's
         destination address;

      2. for all i, 1<i<n, Ri has assigned a label to X and distributed
         that label to R[i-1].

   Note that a packet's LSP can extend only until it encounters a router
   whose forwarding tables have a longer best match address prefix for
   the packet's destination address.  At that point, the LSP must end
   and the best match algorithm must be performed again.

   Suppose, for example, that packet P, with destination address
   10.2.153.178 needs to go from R1 to R2 to R3.  Suppose also that R2
   advertises address prefix 10.2/16 to R1, but R3 advertises
   10.2.153/23, 10.2.154/23, and 10.2/16 to R2.  That is, R2 is
   advertising an "aggregated route" to R1.  In this situation, packet P
   can be label Switched until it reaches R2, but since R2 has performed
   route aggregation, it must execute the best match algorithm to find
   P's FEC.

4.1.4. LSP Egress and LSP Proxy Egress

   An LSR R is considered to be an "LSP Egress" LSR for address prefix X
   if and only if one of the following conditions holds:

      1. R has an address Y, such that X is the address prefix in R's
         routing table which is the longest match for Y, or

      2. R contains in its routing tables one or more address prefixes Y
         such that X is a proper initial substring of Y, but R's "LSP
         previous hops" for X do not contain any such address prefixes
         Y; that is, R is a "deaggregation point" for address prefix X.

   An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address
   prefix X if and only if:

      1. R1's next hop for X is R2, and R1 and R2 are not label
         distribution peers with respect to X (perhaps because R2 does
         not support MPLS), or

      2. R1 has been configured to act as an LSP Proxy Egress for X

Top      Up      ToC       Page 40 
   The definition of LSP allows for the LSP Egress to be a node which
   does not support MPLS; in this case the penultimate node in the LSP
   is the Proxy Egress.

4.1.5. The Implicit NULL Label

   The Implicit NULL label is a label with special semantics which an
   LSR can bind to an address prefix.  If LSR Ru, by consulting its ILM,
   sees that labeled packet P must be forwarded next to Rd, but that Rd
   has distributed a binding of Implicit NULL to the corresponding
   address prefix, then instead of replacing the value of the label on
   top of the label stack, Ru pops the label stack, and then forwards
   the resulting packet to Rd.

   LSR Rd distributes a binding between Implicit NULL and an address
   prefix X to LSR Ru if and only if:

      1. the rules of Section 4.1.2 indicate that Rd distributes to Ru a
         label binding for X, and

      2. Rd knows that Ru can support the Implicit NULL label (i.e.,
         that it can pop the label stack), and

      3. Rd is an LSP Egress (not proxy egress) for X.

   This causes the penultimate LSR on a LSP to pop the label stack.
   This is quite appropriate; if the LSP Egress is an MPLS Egress for X,
   then if the penultimate LSR does not pop the label stack, the LSP
   Egress will need to look up the label, pop the label stack, and then
   look up the next label (or look up the L3 address, if no more labels
   are present).  By having the penultimate LSR pop the label stack, the
   LSP Egress is saved the work of having to look up two labels in order
   to make its forwarding decision.

   However, if the penultimate LSR is an ATM switch, it may not have the
   capability to pop the label stack.  Hence a binding of Implicit NULL
   may be distributed only to LSRs which can support that function.

   If the penultimate LSR in an LSP for address prefix X is an LSP Proxy
   Egress, it acts just as if the LSP Egress had distributed a binding
   of Implicit NULL for X.

4.1.6. Option: Egress-Targeted Label Assignment

   There are situations in which an LSP Ingress, Ri, knows that packets
   of several different FECs must all follow the same LSP, terminating
   at, say, LSP Egress Re.  In this case, proper routing can be achieved

Top      Up      ToC       Page 41 
   by using a single label for all such FECs; it is not necessary to
   have a distinct label for each FEC.  If (and only if) the following
   conditions hold:

      1. the address of LSR Re is itself in the routing table as a "host
         route", and

      2. there is some way for Ri to determine that Re is the LSP egress
         for all packets in a particular set of FECs

   Then Ri may bind a single label to all FECS in the set.  This is
   known as "Egress-Targeted Label Assignment."

   How can LSR Ri determine that an LSR Re is the LSP Egress for all
   packets in a particular FEC?  There are a number of possible ways:

      -  If the network is running a link state routing algorithm, and
         all nodes in the area support MPLS, then the routing algorithm
         provides Ri with enough information to determine the routers
         through which packets in that FEC must leave the routing domain
         or area.

      -  If the network is running BGP, Ri may be able to determine that
         the packets in a particular FEC must leave the network via some
         particular router which is the "BGP Next Hop" for that FEC.

      -  It is possible to use the label distribution protocol to pass
         information about which address prefixes are "attached" to
         which egress LSRs.  This method has the advantage of not
         depending on the presence of link state routing.

   If egress-targeted label assignment is used, the number of labels
   that need to be supported throughout the network may be greatly
   reduced.  This may be significant if one is using legacy switching
   hardware to do MPLS, and the switching hardware can support only a
   limited number of labels.

   One possible approach would be to configure the network to use
   egress-targeted label assignment by default, but to configure
   particular LSRs to NOT use egress-targeted label assignment for one
   or more of the address prefixes for which it is an LSP egress.  We
   impose the following rule:

      -  If a particular LSR is NOT an LSP Egress for some set of
         address prefixes, then it should assign labels to the address
         prefixes in the same way as is done by its LSP next hop for
         those address prefixes.  That is, suppose Rd is Ru's LSP next

Top      Up      ToC       Page 42 
         hop for address prefixes X1 and X2.  If Rd assigns the same
         label to X1 and X2, Ru should as well.  If Rd assigns different
         labels to X1 and X2, then Ru should as well.

   For example, suppose one wants to make egress-targeted label
   assignment the default, but to assign distinct labels to those
   address prefixes for which there are multiple possible LSP egresses
   (i.e., for those address prefixes which are multi-homed.)  One can
   configure all LSRs to use egress-targeted label assignment, and then
   configure a handful of LSRs to assign distinct labels to those
   address prefixes which are multi-homed.  For a particular multi-homed
   address prefix X, one would only need to configure this in LSRs which
   are either LSP Egresses or LSP Proxy Egresses for X.

   It is important to note that if Ru and Rd are adjacent LSRs in an LSP
   for X1 and X2, forwarding will still be done correctly if Ru assigns
   distinct labels to X1 and X2 while Rd assigns just one label to the
   both of them.  This just means that R1 will map different incoming
   labels to the same outgoing label, an ordinary occurrence.

   Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns
   to them both the label corresponding to the address of their LSP
   Egress or Proxy Egress, forwarding will still be done correctly.  Ru
   will just map the incoming label to the label which Rd has assigned
   to the address of that LSP Egress.

4.2. MPLS and Explicitly Routed LSPs

   There are a number of reasons why it may be desirable to use explicit
   routing instead of hop by hop routing.  For example, this allows
   routes to be based on administrative policies, and allows the routes
   that LSPs take to be carefully designed to allow traffic engineering
   [MPLS-TRFENG].

4.2.1. Explicitly Routed LSP Tunnels

   In some situations, the network administrators may desire to forward
   certain classes of traffic along certain pre-specified paths, where
   these paths differ from the Hop-by-hop path that the traffic would
   ordinarily follow.  This can be done in support of policy routing, or
   in support of traffic engineering.  The explicit route may be a
   configured one, or it may be determined dynamically by some means,
   e.g., by constraint-based routing.

   MPLS allows this to be easily done by means of Explicitly Routed LSP
   Tunnels.  All that is needed is:

Top      Up      ToC       Page 43 
      1. A means of selecting the packets that are to be sent into the
         Explicitly Routed LSP Tunnel;

      2. A means of setting up the Explicitly Routed LSP Tunnel;

      3. A means of ensuring that packets sent into the Tunnel will not
         loop from the receive endpoint back to the transmit endpoint.

   If the transmit endpoint of the tunnel wishes to put a labeled packet
   into the tunnel, it must first replace the label value at the top of
   the stack with a label value that was distributed to it by the
   tunnel's receive endpoint.  Then it must push on the label which
   corresponds to the tunnel itself, as distributed to it by the next
   hop along the tunnel.  To allow this, the tunnel endpoints should be
   explicit label distribution peers.  The label bindings they need to
   exchange are of no interest to the LSRs along the tunnel.

4.3. Label Stacks and Implicit Peering

   Suppose a particular LSR Re is an LSP proxy egress for 10 address
   prefixes, and it reaches each address prefix through a distinct
   interface.

   One could assign a single label to all 10 address prefixes.  Then Re
   is an LSP egress for all 10 address prefixes.  This ensures that
   packets for all 10 address prefixes get delivered to Re.  However, Re
   would then have to look up the network layer address of each such
   packet in order to choose the proper interface to send the packet on.

   Alternatively, one could assign a distinct label to each interface.
   Then Re is an LSP proxy egress for the 10 address prefixes.  This
   eliminates the need for Re to look up the network layer addresses in
   order to forward the packets.  However, it can result in the use of a
   large number of labels.

   An alternative would be to bind all 10 address prefixes to the same
   level 1 label (which is also bound to the address of the LSR itself),
   and then to bind each address prefix to a distinct level 2 label.
   The level 2 label would be treated as an attribute of the level 1
   label binding, which we call the "Stack Attribute".  We impose the
   following rules:

      -  When LSR Ru initially labels a hitherto unlabeled packet, if
         the longest match for the packet's destination address is X,
         and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru
         a binding of label L1 to X, along with a stack attribute of L2,
         then

Top      Up      ToC       Page 44 
         1. Ru must push L2 and then L1 onto the packet's label stack,
            and then forward the packet to Rd;

         2. When Ru distributes label bindings for X to its label
            distribution peers, it must include L2 as the stack
            attribute.

         3. Whenever the stack attribute changes (possibly as a result
            of a change in Ru's LSP next hop for X), Ru must distribute
            the new stack attribute.

   Note that although the label value bound to X may be different at
   each hop along the LSP, the stack attribute value is passed
   unchanged, and is set by the LSP proxy egress.

   Thus the LSP proxy egress for X becomes an "implicit peer" with each
   other LSR in the routing area or domain.  In this case, explicit
   peering would be too unwieldy, because the number of peers would
   become too large.

4.4. MPLS and Multi-Path Routing

   If an LSR supports multiple routes for a particular stream, then it
   may assign multiple labels to the stream, one for each route.  Thus
   the reception of a second label binding from a particular neighbor
   for a particular address prefix should be taken as meaning that
   either label can be used to represent that address prefix.

   If multiple label bindings for a particular address prefix are
   specified, they may have distinct attributes.

4.5. LSP Trees as Multipoint-to-Point Entities

   Consider the case of packets P1 and P2, each of which has a
   destination address whose longest match, throughout a particular
   routing domain, is address prefix X.  Suppose that the Hop-by-hop
   path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4,
   R2, R3>.   Let's suppose that R3 binds label L3 to X, and distributes
   this binding to R2.  R2 binds label L2 to X, and distributes this
   binding to both R1 and R4.  When R2 receives packet P1, its incoming
   label will be L2.  R2 will overwrite L2 with L3, and send P1 to R3.
   When R2 receives packet P2, its incoming label will also be L2.  R2
   again overwrites L2 with L3, and send P2 on to R3.

   Note then that when P1 and P2 are traveling from R2 to R3, they carry
   the same label, and as far as MPLS is concerned, they cannot be
   distinguished.  Thus instead of talking about two distinct LSPs, <R1,

Top      Up      ToC       Page 45 
   R2, R3> and <R4, R2, R3>, we might talk of a single "Multipoint-to-
   Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>.

   This creates a difficulty when we attempt to use conventional ATM
   switches as LSRs.  Since conventional ATM switches do not support
   multipoint-to-point connections, there must be procedures to ensure
   that each LSP is realized as a point-to-point VC.  However, if ATM
   switches which do support multipoint-to-point VCs are in use, then
   the LSPs can be most efficiently realized as multipoint-to-point VCs.
   Alternatively, if the SVP Multipoint Encoding (section 3.25.2) can be
   used, the LSPs can be realized as multipoint-to-point SVPs.

4.6. LSP Tunneling between BGP Border Routers

   Consider the case of an Autonomous System, A, which carries transit
   traffic between other Autonomous Systems.  Autonomous System A will
   have a number of BGP Border Routers, and a mesh of BGP connections
   among them, over which BGP routes are distributed.  In many such
   cases, it is desirable to avoid distributing the BGP routes to
   routers which are not BGP Border Routers.  If this can be avoided,
   the "route distribution load" on those routers is significantly
   reduced.  However, there must be some means of ensuring that the
   transit traffic will be delivered from Border Router to Border Router
   by the interior routers.

   This can easily be done by means of LSP Tunnels.  Suppose that BGP
   routes are distributed only to BGP Border Routers, and not to the
   interior routers that lie along the Hop-by-hop path from Border
   Router to Border Router.  LSP Tunnels can then be used as follows:

      1. Each BGP Border Router distributes, to every other BGP Border
         Router in the same Autonomous System, a label for each address
         prefix that it distributes to that router via BGP.

      2. The IGP for the Autonomous System maintains a host route for
         each BGP Border Router.  Each interior router distributes its
         labels for these host routes to each of its IGP neighbors.

      3. Suppose that:

         a) BGP Border Router B1 receives an unlabeled packet P,

         b) address prefix X in B1's routing table is the longest match
            for the destination address of P,

         c) the route to X is a BGP route,

         d) the BGP Next Hop for X is B2,

Top      Up      ToC       Page 46 
         e) B2 has bound label L1 to X, and has distributed this binding
            to B1,

         f) the IGP next hop for the address of B2 is I1,

         g) the address of B2 is in B1's and I1's IGP routing tables as
            a host route, and

         h) I1 has bound label L2 to the address of B2, and distributed
            this binding to B1.

         Then before sending packet P to I1, B1 must create a label
         stack for P, then push on label L1, and then push on label L2.

      4. Suppose that BGP Border Router B1 receives a labeled Packet P,
         where the label on the top of the label stack corresponds to an
         address prefix, X, to which the route is a BGP route, and that
         conditions 3b, 3c, 3d, and 3e all hold.  Then before sending
         packet P to I1, B1 must replace the label at the top of the
         label stack with L1, and then push on label L2.

   With these procedures, a given packet P follows a level 1 LSP all of
   whose members are BGP Border Routers, and between each pair of BGP
   Border Routers in the level 1 LSP, it follows a level 2 LSP.

   These procedures effectively create a Hop-by-Hop Routed LSP Tunnel
   between the BGP Border Routers.

   Since the BGP border routers are exchanging label bindings for
   address prefixes that are not even known to the IGP routing, the BGP
   routers should become explicit label distribution peers with each
   other.

   It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels
   between two BGP Border Routers, even if they are not in the same
   Autonomous System.  Suppose, for example, that B1 and B2 are in AS 1.
   Suppose that B3 is an EBGP neighbor of B2, and is in AS2.  Finally,
   suppose that B2 and B3 are on some network which is common to both
   Autonomous Systems (a "Demilitarized Zone").  In this case, an LSP
   tunnel can be set up directly between B1 and B3 as follows:

      -  B3 distributes routes to B2 (using EBGP), optionally assigning
         labels to address prefixes;

      -  B2 redistributes those routes to B1 (using IBGP), indicating
         that the BGP next hop for each such route is B3.  If B3 has
         assigned labels to address prefixes, B2 passes these labels
         along, unchanged, to B1.

Top      Up      ToC       Page 47 
      -  The IGP of AS1 has a host route for B3.

4.7. Other Uses of Hop-by-Hop Routed LSP Tunnels

   The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels
   between BGP Next Hops.  Any situation in which one might otherwise
   have used an encapsulation tunnel is one in which it is appropriate
   to use a Hop-by-Hop Routed LSP Tunnel.  Instead of encapsulating the
   packet with a new header whose destination address is the address of
   the tunnel's receive endpoint, the label corresponding to the address
   prefix which is the longest match for the address of the tunnel's
   receive endpoint is pushed on the packet's label stack.  The packet
   which is sent into the tunnel may or may not already be labeled.

   If the transmit endpoint of the tunnel wishes to put a labeled packet
   into the tunnel, it must first replace the label value at the top of
   the stack with a label value that was distributed to it by the
   tunnel's receive endpoint.  Then it must push on the label which
   corresponds to the tunnel itself, as distributed to it by the next
   hop along the tunnel.  To allow this, the tunnel endpoints should be
   explicit label distribution peers.  The label bindings they need to
   exchange are of no interest to the LSRs along the tunnel.

4.8. MPLS and Multicast

   Multicast routing proceeds by constructing multicast trees.  The tree
   along which a particular multicast packet must get forwarded depends
   in general on the packet's source address and its destination
   address.  Whenever a particular LSR is a node in a particular
   multicast tree, it binds a label to that tree.  It then distributes
   that binding to its parent on the multicast tree.  (If the node in
   question is on a LAN, and has siblings on that LAN, it must also
   distribute the binding to its siblings.  This allows the parent to
   use a single label value when multicasting to all children on the
   LAN.)

   When a multicast labeled packet arrives, the NHLFE corresponding to
   the label indicates the set of output interfaces for that packet, as
   well as the outgoing label.  If the same label encoding technique is
   used on all the outgoing interfaces, the very same packet can be sent
   to all the children.

5. Label Distribution Procedures (Hop-by-Hop)

   In this section, we consider only label bindings that are used for
   traffic to be label switched along its hop-by-hop routed path.  In
   these cases, the label in question will correspond to an address
   prefix in the routing table.

Top      Up      ToC       Page 48 
5.1. The Procedures for Advertising and Using labels

   There are a number of different procedures that may be used to
   distribute label bindings.  Some are executed by the downstream LSR,
   and some by the upstream LSR.

   The downstream LSR must perform:

      -  The Distribution Procedure, and

      -  the Withdrawal Procedure.

   The upstream LSR must perform:

      -  The Request Procedure, and

      -  the NotAvailable Procedure, and

      -  the Release Procedure, and

      -  the labelUse Procedure.

   The MPLS architecture supports several variants of each procedure.

   However, the MPLS architecture does not support all possible
   combinations of all possible variants.  The set of supported
   combinations will be described in section 5.2, where the
   interoperability between different combinations will also be
   discussed.

5.1.1. Downstream LSR: Distribution Procedure

   The Distribution Procedure is used by a downstream LSR to determine
   when it should distribute a label binding for a particular address
   prefix to its label distribution peers.  The architecture supports
   four different distribution procedures.

   Irrespective of the particular procedure that is used, if a label
   binding for a particular address prefix has been distributed by a
   downstream LSR Rd to an upstream LSR Ru, and if at any time the
   attributes (as defined above) of that binding change, then Rd must
   inform Ru of the new attributes.

   If an LSR is maintaining multiple routes to a particular address
   prefix, it is a local matter as to whether that LSR binds multiple
   labels to the address prefix (one per route), and hence distributes
   multiple bindings.

Top      Up      ToC       Page 49 
5.1.1.1. PushUnconditional

   Let Rd be an LSR.  Suppose that:

      1. X is an address prefix in Rd's routing table

      2. Ru is a label distribution peer of Rd with respect to X

   Whenever these conditions hold, Rd must bind a label to X and
   distribute that binding to Ru.  It is the responsibility of Rd to
   keep track of the bindings which it has distributed to Ru, and to
   make sure that Ru always has these bindings.

   This procedure would be used by LSRs which are performing unsolicited
   downstream label assignment in the Independent LSP Control Mode.

5.1.1.2. PushConditional

   Let Rd be an LSR.  Suppose that:

      1. X is an address prefix in Rd's routing table

      2. Ru is a label distribution peer of Rd with respect to X

      3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
         Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
         Rn has bound a label to X and distributed that binding to Rd.

   Then as soon as these conditions all hold, Rd should bind a label to
   X and distribute that binding to Ru.

   Whereas PushUnconditional causes the distribution of label bindings
   for all address prefixes in the routing table, PushConditional causes
   the distribution of label bindings only for those address prefixes
   for which one has received label bindings from one's LSP next hop, or
   for which one does not have an MPLS-capable L3 next hop.

   This procedure would be used by LSRs which are performing unsolicited
   downstream label assignment in the Ordered LSP Control Mode.

5.1.1.3. PulledUnconditional

   Let Rd be an LSR.  Suppose that:

      1. X is an address prefix in Rd's routing table

      2. Ru is a label distribution peer of Rd with respect to X

Top      Up      ToC       Page 50 
      3. Ru has explicitly requested that Rd bind a label to X and
         distribute the binding to Ru

   Then Rd should bind a label to X and distribute that binding to Ru.
   Note that if X is not in Rd's routing table, or if Rd is not a label
   distribution peer of Ru with respect to X, then Rd must inform Ru
   that it cannot provide a binding at this time.

   If Rd has already distributed a binding for address prefix X to Ru,
   and it receives a new request from Ru for a binding for address
   prefix X, it will bind a second label, and distribute the new binding
   to Ru.  The first label binding remains in effect.

   This procedure would be used by LSRs performing downstream-on-demand
   label distribution using the Independent LSP Control Mode.

5.1.1.4. PulledConditional

   Let Rd be an LSR.  Suppose that:

      1. X is an address prefix in Rd's routing table

      2. Ru is a label distribution peer of Rd with respect to X

      3. Ru has explicitly requested that Rd bind a label to X and
         distribute the binding to Ru

      4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
         Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
         Rn has bound a label to X and distributed that binding to Rd

   Then as soon as these conditions all hold, Rd should bind a label to
   X and distribute that binding to Ru.  Note that if X is not in Rd's
   routing table and a binding for X is not obtainable via Rd's next hop
   for X, or if Rd is not a label distribution peer of Ru with respect
   to X, then Rd must inform Ru that it cannot provide a binding at this
   time.

   However, if the only condition that fails to hold is that Rn has not
   yet provided a label to Rd, then Rd must defer any response to Ru
   until such time as it has receiving a binding from Rn.

   If Rd has distributed a label binding for address prefix X to Ru, and
   at some later time, any attribute of the label binding changes, then
   Rd must redistribute the label binding to Ru, with the new attribute.
   It must do this even though Ru does not issue a new Request.

Top      Up      ToC       Page 51 
   This procedure would be used by LSRs that are performing downstream-
   on-demand label allocation in the Ordered LSP Control Mode.

   In section 5.2, we  will discuss how to choose the particular
   procedure to be used at any given time, and how to ensure
   interoperability among LSRs that choose different procedures.

5.1.2. Upstream LSR: Request Procedure

   The Request Procedure is used by the upstream LSR for an address
   prefix to determine when to explicitly request that the downstream
   LSR bind a label to that prefix and distribute the binding.  There
   are three possible procedures that can be used.

5.1.2.1. RequestNever

   Never make a request.  This is useful if the downstream LSR uses the
   PushConditional procedure or the PushUnconditional procedure, but is
   not useful if the downstream LSR uses the PulledUnconditional
   procedure or the the PulledConditional procedures.

   This procedure would be used by an LSR when unsolicited downstream
   label distribution and Liberal Label Retention Mode are being used.

5.1.2.2. RequestWhenNeeded

   Make a request whenever the L3 next hop to the address prefix
   changes, or when a new address prefix is learned, and one doesn't
   already have a label binding from that next hop for the given address
   prefix.

   This procedure would be used by an LSR whenever Conservative Label
   Retention Mode is being used.

5.1.2.3. RequestOnRequest

   Issue a request whenever a request is received, in addition to
   issuing a request when needed (as described in section 5.1.2.2).  If
   Ru is not capable of being an LSP ingress, it may issue a request
   only when it receives a request from upstream.

   If Rd receives such a request from Ru, for an address prefix for
   which Rd has already distributed Ru a label, Rd shall assign a new
   (distinct) label, bind it to X, and distribute that binding.
   (Whether Rd can distribute this binding to Ru immediately or not
   depends on the Distribution Procedure being used.)

Top      Up      ToC       Page 52 
   This procedure would be used by an LSR which is doing downstream-on-
   demand label distribution, but is not doing label merging, e.g., an
   ATM-LSR which is not capable of VC merge.

5.1.3. Upstream LSR: NotAvailable Procedure

   If Ru and Rd are respectively upstream and downstream label
   distribution peers for address prefix X, and Rd is Ru's L3 next hop
   for X, and Ru requests a binding for X from Rd, but Rd replies that
   it cannot provide a binding at this time, because it has no next hop
   for X, then the NotAvailable procedure determines how Ru responds.
   There are two possible procedures governing Ru's behavior:

5.1.3.1. RequestRetry

   Ru should issue the request again at a later time.  That is, the
   requester is responsible for trying again later to obtain the needed
   binding.  This procedure would be used when downstream-on-demand
   label distribution is used.

5.1.3.2. RequestNoRetry

   Ru should never reissue the request, instead assuming that Rd will
   provide the binding automatically when it is available.  This is
   useful if Rd uses the PushUnconditional procedure or the
   PushConditional procedure, i.e., if unsolicited downstream label
   distribution is used.

   Note that if Rd replies that it cannot provide a binding to Ru,
   because of some error condition, rather than because Rd has no next
   hop, the behavior of Ru will be governed by the error recovery
   conditions of the label distribution protocol, rather than by the
   NotAvailable procedure.

5.1.4. Upstream LSR: Release Procedure

   Suppose that Rd is an LSR which has bound a label to address prefix
   X, and has distributed that binding to LSR Ru.  If Rd does not happen
   to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's
   L3 next hop for address prefix X, then Ru will not be using the
   label.  The Release Procedure determines how Ru acts in this case.
   There are two possible procedures governing Ru's behavior:

5.1.4.1. ReleaseOnChange

   Ru should release the binding, and inform Rd that it has done so.
   This procedure would be used to implement Conservative Label
   Retention Mode.

Top      Up      ToC       Page 53 
5.1.4.2. NoReleaseOnChange

   Ru should maintain the binding, so that it can use it again
   immediately if Rd later  becomes Ru's L3 next hop for X.  This
   procedure would be used to implement Liberal Label Retention Mode.

5.1.5. Upstream LSR: labelUse Procedure

   Suppose Ru is an LSR which has received label binding L for address
   prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and
   in fact Rd is Ru's L3 next hop for X.

   Ru will make use of the binding if Rd is Ru's L3 next hop for X.  If,
   at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop
   for X, Ru does not make any use of the binding at that time.  Ru may
   however start using the binding at some later time, if Rd becomes
   Ru's L3 next hop for X.

   The labelUse Procedure determines just how Ru makes use of Rd's
   binding.

   There are two procedures which Ru may use:

5.1.5.1. UseImmediate

   Ru may put the binding into use immediately.  At any time when Ru has
   a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will
   also be Ru's LSP next hop for X.  This procedure is used when loop
   detection is not in use.

5.1.5.2. UseIfLoopNotDetected

   This procedure is the same as UseImmediate, unless Ru has detected a
   loop in the LSP.  If a loop has been detected, Ru will discontinue
   the use of label L for forwarding packets to Rd.

   This procedure is used when loop detection is in use.

   This will continue until the next hop for X changes, or until the
   loop is no longer detected.

5.1.6. Downstream LSR: Withdraw Procedure

   In this case, there is only a single procedure.

   When LSR Rd decides to break the binding between label L and address
   prefix X, then this unbinding must be distributed to all LSRs to
   which the binding was distributed.

Top      Up      ToC       Page 54 
   It is required that the unbinding of L from X be distributed by Rd to
   a LSR Ru before Rd distributes to Ru any new binding of L to any
   other address prefix Y, where X != Y.  If Ru were to learn of the new
   binding of L to Y before it learned of the unbinding of L from X, and
   if packets matching both X and Y were forwarded by Ru to Rd, then for
   a period of time, Ru would label both packets matching X and packets
   matching Y with label L.

   The distribution and withdrawal of label bindings is done via a label
   distribution protocol.  All label distribution protocols require that
   a label distribution adjacency be established between two label
   distribution peers (except implicit peers).  If LSR R1 has a label
   distribution adjacency to LSR R2, and has received label bindings
   from LSR R2 via that adjacency, then if adjacency is brought down by
   either peer (whether as a result of failure or as a matter of normal
   operation), all bindings received over that adjacency must be
   considered to have been withdrawn.

   As long as the relevant label distribution adjacency remains in
   place, label bindings that are withdrawn must always be withdrawn
   explicitly.  If a second label is bound to an address prefix, the
   result is not to implicitly withdraw the first label, but to bind
   both labels; this is needed to support multi-path routing.  If a
   second address prefix is bound to a label, the result is not to
   implicitly withdraw the binding of that label to the first address
   prefix, but to use that label for both address prefixes.

5.2. MPLS Schemes: Supported Combinations of Procedures

   Consider two LSRs, Ru and Rd, which are label distribution peers with
   respect to some set of address prefixes, where Ru is the upstream
   peer and Rd is the downstream peer.

   The MPLS scheme which governs the interaction of Ru and Rd can be
   described as a quintuple of procedures: <Distribution Procedure,
   Request Procedure, NotAvailable Procedure, Release Procedure,
   labelUse Procedure>.  (Since there is only one Withdraw Procedure, it
   need not be mentioned.)  A "*" appearing in one of the positions is a
   wild-card, meaning that any procedure in that category may be
   present; an "N/A" appearing in a particular position indicates that
   no procedure in that category is needed.

   Only the MPLS schemes which are specified below are supported by the
   MPLS Architecture.  Other schemes may be added in the future, if a
   need for them is shown.

Top      Up      ToC       Page 55 
5.2.1. Schemes for LSRs that Support Label Merging

   If Ru and Rd are label distribution peers, and both support label
   merging, one of the following schemes must be used:

      1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
         UseImmediate>

         This is unsolicited downstream label distribution with
         independent control, liberal label retention mode, and no loop
         detection.

      2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
         UseIfLoopNotDetected>

         This is unsolicited downstream label distribution with
         independent control, liberal label retention, and loop
         detection.

      3. <PushConditional, RequestWhenNeeded, RequestNoRetry,
         ReleaseOnChange, *>

         This is unsolicited downstream label distribution with ordered
         control (from the egress) and conservative label retention
         mode.  Loop detection is optional.

      4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>

         This is unsolicited downstream label distribution with ordered
         control (from the egress) and liberal label retention mode.
         Loop detection is optional.

      5. <PulledConditional, RequestWhenNeeded, RequestRetry,
         ReleaseOnChange, *>

         This is downstream-on-demand label distribution with ordered
         control (initiated by the ingress), conservative label
         retention mode, and optional loop detection.

      6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
         UseImmediate>

         This is downstream-on-demand label distribution with
         independent control and conservative label retention mode,
         without loop detection.

Top      Up      ToC       Page 56 
      7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
         UseIfLoopNotDetected>

         This is downstream-on-demand label distribution with
         independent control and conservative label retention mode, with
         loop detection.

5.2.2. Schemes for LSRs that do not Support Label Merging

   Suppose that R1, R2, R3, and R4 are ATM switches which do not support
   label merging, but are being used as LSRs.  Suppose further that the
   L3 hop-by-hop path for address prefix X is <R1, R2, R3, R4>, and that
   packets destined for X can enter the network at any of these LSRs.
   Since there is no multipoint-to-point capability, the LSPs must be
   realized as point-to-point VCs, which means that there needs to be
   three such VCs for address prefix X: <R1, R2, R3, R4>, <R2, R3, R4>,
   and <R3, R4>.

   Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is
   implemented using conventional ATM switching hardware (i.e., no cell
   interleave suppression), or is otherwise incapable of performing
   label merging, the MPLS scheme in use between R1 and R2 must be one
   of the following:

      1. <PulledConditional, RequestOnRequest, RequestRetry,
         ReleaseOnChange, *>

         This is downstream-on-demand label distribution with ordered
         control (initiated by the ingress), conservative label
         retention mode, and optional loop detection.

         The use of the RequestOnRequest procedure will cause R4 to
         distribute three labels for X to R3; R3 will distribute 2
         labels for X to R2, and R2 will distribute one label for X to
         R1.

      2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange,
         UseImmediate>

         This is downstream-on-demand label distribution with
         independent control and conservative label retention mode,
         without loop detection.

Top      Up      ToC       Page 57 
      3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange,
         UseIfLoopNotDetected>

         This is downstream-on-demand label distribution with
         independent control and conservative label retention mode, with
         loop detection.

5.2.3. Interoperability Considerations

   It is easy to see that certain quintuples do NOT yield viable MPLS
   schemes.  For example:

      -  <PulledUnconditional, RequestNever, *, *, *>
         <PulledConditional, RequestNever, *, *, *>

         In these MPLS schemes, the downstream LSR Rd distributes label
         bindings to upstream LSR Ru only upon request from Ru, but Ru
         never makes any such requests.  Obviously, these schemes are
         not viable, since they will not result in the proper
         distribution of label bindings.

         -  <*, RequestNever, *, *, ReleaseOnChange>

         In these MPLS schemes, Rd releases bindings when it isn't using
         them, but it never asks for them again, even if it later has a
         need for them.  These schemes thus do not ensure that label
         bindings get properly distributed.

   In this section, we specify rules to prevent a pair of label
   distribution peers from adopting procedures which lead to infeasible
   MPLS Schemes.  These rules require either the exchange of information
   between label distribution peers during the initialization of the
   label distribution adjacency, or a priori knowledge of the
   information (obtained through a means outside the scope of this
   document).

      1. Each must state whether it supports label merging.

      2. If Rd does not support label merging, Rd must choose either the
         PulledUnconditional procedure or the PulledConditional
         procedure.  If Rd chooses PulledConditional, Ru is forced to
         use the RequestRetry procedure.

         That is, if the downstream LSR does not support label merging,
         its preferences take priority when the MPLS scheme is chosen.

Top      Up      ToC       Page 58 
      3. If Ru does not support label merging, but Rd does, Ru must
         choose either the RequestRetry or RequestNoRetry procedure.
         This forces Rd to use the PulledConditional or
         PulledUnConditional procedure respectively.

         That is, if only one of the LSRs doesn't support label merging,
         its preferences take priority when the MPLS scheme is chosen.

      4. If both Ru and Rd both support label merging, then the choice
         between liberal and conservative label retention mode belongs
         to Ru.  That is, Ru gets to choose either to use
         RequestWhenNeeded/ReleaseOnChange (conservative) , or to use
         RequestNever/NoReleaseOnChange (liberal).  However, the choice
         of "push" vs. "pull" and "conditional" vs. "unconditional"
         belongs to Rd.  If Ru chooses liberal label retention mode, Rd
         can choose either PushUnconditional or PushConditional.  If Ru
         chooses conservative label retention mode, Rd can choose
         PushConditional, PulledConditional, or PulledUnconditional.

         These choices together determine the MPLS scheme in use.

6. Security Considerations

   Some routers may implement security procedures which depend on the
   network layer header being in a fixed place relative to the data link
   layer header.  The MPLS generic encapsulation inserts a shim between
   the data link layer header and the network layer header.  This may
   cause any such security procedures to fail.

   An MPLS label has its meaning by virtue of an agreement between the
   LSR that puts the label in the label stack (the "label writer"), and
   the LSR that interprets that label (the "label reader").  If labeled
   packets are accepted from untrusted sources, or if a particular
   incoming label is accepted from an LSR to which that label has not
   been distributed, then packets may be routed in an illegitimate
   manner.

7. Intellectual Property

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

Top      Up      ToC       Page 59 
8. Authors' Addresses

   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: erosen@cisco.com


   Arun Viswanathan
   Force10 Networks, Inc.
   1440 McCarthy Blvd.
   Milpitas, CA 95035-7438

   EMail: arun@force10networks.com


   Ross Callon
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA

   EMail: rcallon@juniper.net

9. References

   [MPLS-ATM]          Davie, B., Lawrence, J., McCloghrie, K., Rekhter,
                       Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS
                       using LDP and ATM VC Switching", RFC 3035,
                       January 2001.

   [MPLS-BGP]          "Carrying Label Information in BGP-4", Rekhter,
                       Rosen, Work in Progress.

   [MPLS-CR-LDP]       "Constraint-Based LSP Setup using LDP", Jamoussi,
                       Editor, Work in Progress.

   [MPLS-FRMRLY]       Conta, A., Doolan, P. and A. Malis, "Use of Label
                       Switching on Frame Relay Networks Specification",
                       RFC 3034, January 2001.

   [MPLS-LDP]          Andersson, L., Doolan, P., Feldman, N., Fredette,
                       A. and B. Thomas, "LDP Specification", RFC 3036,
                       January 2001.

Top      Up      ToC       Page 60 
   [MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche,
                       Berger, Gan, Li, Swallow, Srinvasan, Work in
                       Progress.

   [MPLS-SHIM]         Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G.,
                       Farinacci, D. and A. Conta, "MPLS Label Stack
                       Encoding", RFC 3032, January 2001.

   [MPLS-TRFENG]       Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M.
                       and J. McManus, "Requirements for Traffic
                       Engineering Over MPLS", RFC 2702, September 1999.

Top      Up      ToC       Page 61 
10. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.