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.
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.
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 cannot decrement TTL,
there is no protection against loops. If the ATM hardware is capable
of providing fair access to the buffer pool for incoming cells
carrying different VPI/VCI values, this looping may not have any
deleterious effect on other traffic. If the ATM hardware cannot
provide fair buffer access of this sort, however, then even transient
loops may cause severe degradation of the LSR's total performance.
Even if fair buffer access can be provided, it is still worthwhile to
have some means of detecting loops that last "longer than possible".
In addition, even where TTL and/or per-VC fair queuing provides a
means for surviving loops, it still may be desirable where practical
to avoid setting up LSPs which loop. All LSRs that may attach to
non-TTL LSP segments will therefore be required to support a common
technique for loop detection; however, use of the loop detection
technique is optional. The loop detection technique is specified in
[MPLS-ATM] and [MPLS-LDP].
3.25. Label Encodings
In order to transmit a label stack along with the packet whose label
stack it is, it is necessary to define a concrete encoding of the
label stack. The architecture supports several different encoding
techniques; the choice of encoding technique depends on the
particular kind of device being used to forward labeled packets.
3.25.1. MPLS-specific Hardware and/or Software
If one is using MPLS-specific hardware and/or software to forward
labeled packets, the most obvious way to encode the label stack is to
define a new protocol to be used as a "shim" between the data link
layer and network layer headers. This shim would really be just an
encapsulation of the network layer packet; it would be "protocol-
independent" such that it could be used to encapsulate any network
layer. Hence we will refer to it as the "generic MPLS
encapsulation".
The generic MPLS encapsulation would in turn be encapsulated in a
data link layer protocol.
The MPLS generic encapsulation is specified in [MPLS-SHIM].
3.25.2. ATM Switches as LSRs
It will be noted that MPLS forwarding procedures are similar to those
of legacy "label swapping" switches such as ATM switches. ATM
switches use the input port and the incoming VPI/VCI value as the
index into a "cross-connect" table, from which they obtain an output
port and an outgoing VPI/VCI value. Therefore if one or more labels
can be encoded directly into the fields which are accessed by these
legacy switches, then the legacy switches can, with suitable software
upgrades, be used as LSRs. We will refer to such devices as "ATM-
LSRs".
There are three obvious ways to encode labels in the ATM cell header
(presuming the use of AAL5):
1. SVC Encoding
Use the VPI/VCI field to encode the label which is at the top
of the label stack. This technique can be used in any network.
With this encoding technique, each LSP is realized as an ATM
SVC, and the label distribution protocol becomes the ATM
"signaling" protocol. With this encoding technique, the ATM-
LSRs cannot perform "push" or "pop" operations on the label
stack.
2. SVP Encoding
Use the VPI field to encode the label which is at the top of
the label stack, and the VCI field to encode the second label
on the stack, if one is present. This technique some
advantages over the previous one, in that it permits the use of
ATM "VP-switching". That is, the LSPs are realized as ATM
SVPs, with the label distribution protocol serving as the ATM
signaling protocol.
However, this technique cannot always be used. If the network
includes an ATM Virtual Path through a non-MPLS ATM network,
then the VPI field is not necessarily available for use by
MPLS.
When this encoding technique is used, the ATM-LSR at the egress
of the VP effectively does a "pop" operation.
3. SVP Multipoint Encoding
Use the VPI field to encode the label which is at the top of
the label stack, use part of the VCI field to encode the second
label on the stack, if one is present, and use the remainder of
the VCI field to identify the LSP ingress. If this technique
is used, conventional ATM VP-switching capabilities can be used
to provide multipoint-to-point VPs. Cells from different
packets will then carry different VCI values. As we shall see
in section 3.26, this enables us to do label merging, without
running into any cell interleaving problems, on ATM switches
which can provide multipoint-to-point VPs, but which do not
have the VC merge capability.
This technique depends on the existence of a capability for
assigning 16-bit VCI values to each ATM switch such that no
single VCI value is assigned to two different switches. (If an
adequate number of such values could be assigned to each
switch, it would be possible to also treat the VCI value as the
second label in the stack.)
If there are more labels on the stack than can be encoded in the ATM
header, the ATM encodings must be combined with the generic
encapsulation.
3.25.3. Interoperability among Encoding Techniques
If <R1, R2, R3> is a segment of a LSP, it is possible that R1 will
use one encoding of the label stack when transmitting packet P to R2,
but R2 will use a different encoding when transmitting a packet P to
R3. In general, the MPLS architecture supports LSPs with different
label stack encodings used on different hops. Therefore, when we
discuss the procedures for processing a labeled packet, we speak in
abstract terms of operating on the packet's label stack. When a
labeled packet is received, the LSR must decode it to determine the
current value of the label stack, then must operate on the label
stack to determine the new value of the stack, and then encode the
new value appropriately before transmitting the labeled packet to its
next hop.
Unfortunately, ATM switches have no capability for translating from
one encoding technique to another. The MPLS architecture therefore
requires that whenever it is possible for two ATM switches to be
successive LSRs along a level m LSP for some packet, that those two
ATM switches use the same encoding technique.
Naturally there will be MPLS networks which contain a combination of
ATM switches operating as LSRs, and other LSRs which operate using an
MPLS shim header. In such networks there may be some LSRs which have
ATM interfaces as well as "MPLS Shim" interfaces. This is one
example of an LSR with different label stack encodings on different
hops. Such an LSR may swap off an ATM encoded label stack on an
incoming interface and replace it with an MPLS shim header encoded
label stack on the outgoing interface.
3.26. Label Merging
Suppose that an LSR has bound multiple incoming labels to a
particular FEC. When forwarding packets in that FEC, one would like
to have a single outgoing label which is applied to all such packets.
The fact that two different packets in the FEC arrived with different
incoming labels is irrelevant; one would like to forward them with
the same outgoing label. The capability to do so is known as "label
merging".
Let us say that an LSR is capable of label merging if it can receive
two packets from different incoming interfaces, and/or with different
labels, and send both packets out the same outgoing interface with
the same label. Once the packets are transmitted, the information
that they arrived from different interfaces and/or with different
incoming labels is lost.
Let us say that an LSR is not capable of label merging if, for any
two packets which arrive from different interfaces, or with different
labels, the packets must either be transmitted out different
interfaces, or must have different labels. ATM-LSRs using the SVC or
SVP Encodings cannot perform label merging. This is discussed in
more detail in the next section.
If a particular LSR cannot perform label merging, then if two packets
in the same FEC arrive with different incoming labels, they must be
forwarded with different outgoing labels. With label merging, the
number of outgoing labels per FEC need only be 1; without label
merging, the number of outgoing labels per FEC could be as large as
the number of nodes in the network.
With label merging, the number of incoming labels per FEC that a
particular LSR needs is never be larger than the number of label
distribution adjacencies. Without label merging, the number of
incoming labels per FEC that a particular LSR needs is as large as
the number of upstream nodes which forward traffic in the FEC to the
LSR in question. In fact, it is difficult for an LSR to even
determine how many such incoming labels it must support for a
particular FEC.
The MPLS architecture accommodates both merging and non-merging LSRs,
but allows for the fact that there may be LSRs which do not support
label merging. This leads to the issue of ensuring correct
interoperation between merging LSRs and non-merging LSRs. The issue
is somewhat different in the case of datagram media versus the case
of ATM. The different media types will therefore be discussed
separately.
3.26.1. Non-merging LSRs
The MPLS forwarding procedures is very similar to the forwarding
procedures used by such technologies as ATM and Frame Relay. That
is, a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in
a "cross-connect table", on the basis of that lookup an output port
is chosen, and the label value is rewritten. In fact, it is possible
to use such technologies for MPLS forwarding; a label distribution
protocol can be used as the "signalling protocol" for setting up the
cross-connect tables.
Unfortunately, these technologies do not necessarily support the
label merging capability. In ATM, if one attempts to perform label
merging, the result may be the interleaving of cells from various
packets. If cells from different packets get interleaved, it is
impossible to reassemble the packets. Some Frame Relay switches use
cell switching on their backplanes. These switches may also be
incapable of supporting label merging, for the same reason -- cells
of different packets may get interleaved, and there is then no way to
reassemble the packets.
We propose to support two solutions to this problem. First, MPLS
will contain procedures which allow the use of non-merging LSRs.
Second, MPLS will support procedures which allow certain ATM switches
to function as merging LSRs.
Since MPLS supports both merging and non-merging LSRs, MPLS also
contains procedures to ensure correct interoperation between them.
3.26.2. Labels for Merging and Non-Merging LSRs
An upstream LSR which supports label merging needs to be sent only
one label per FEC. An upstream neighbor which does not support label
merging needs to be sent multiple labels per FEC. However, there is
no way of knowing a priori how many labels it needs. This will
depend on how many LSRs are upstream of it with respect to the FEC in
question.
In the MPLS architecture, if a particular upstream neighbor does not
support label merging, it is not sent any labels for a particular FEC
unless it explicitly asks for a label for that FEC. The upstream
neighbor may make multiple such requests, and is given a new label
each time. When a downstream neighbor receives such a request from
upstream, and the downstream neighbor does not itself support label
merging, then it must in turn ask its downstream neighbor for another
label for the FEC in question.
It is possible that there may be some nodes which support label
merging, but can only merge a limited number of incoming labels into
a single outgoing label. Suppose for example that due to some
hardware limitation a node is capable of merging four incoming labels
into a single outgoing label. Suppose however, that this particular
node has six incoming labels arriving at it for a particular FEC. In
this case, this node may merge these into two outgoing labels.
Whether label merging is applicable to explicitly routed LSPs is for
further study.
3.26.3. Merge over ATM
3.26.3.1. Methods of Eliminating Cell Interleave
There are several methods that can be used to eliminate the cell
interleaving problem in ATM, thereby allowing ATM switches to support
stream merge:
1. VP merge, using the SVP Multipoint Encoding
When VP merge is used, multiple virtual paths are merged into a
virtual path, but packets from different sources are
distinguished by using different VCIs within the VP.
2. VC merge
When VC merge is used, switches are required to buffer cells
from one packet until the entire packet is received (this may
be determined by looking for the AAL5 end of frame indicator).
VP merge has the advantage that it is compatible with a higher
percentage of existing ATM switch implementations. This makes it
more likely that VP merge can be used in existing networks. Unlike
VC merge, VP merge does not incur any delays at the merge points and
also does not impose any buffer requirements. However, it has the
disadvantage that it requires coordination of the VCI space within
each VP. There are a number of ways that this can be accomplished.
Selection of one or more methods is for further study.
This tradeoff between compatibility with existing equipment versus
protocol complexity and scalability implies that it is desirable for
the MPLS protocol to support both VP merge and VC merge. In order to
do so each ATM switch participating in MPLS needs to know whether its
immediate ATM neighbors perform VP merge, VC merge, or no merge.
3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge
The interoperation of the various forms of merging over ATM is most
easily described by first describing the interoperation of VC merge
with non-merge.
In the case where VC merge and non-merge nodes are interconnected the
forwarding of cells is based in all cases on a VC (i.e., the
concatenation of the VPI and VCI). For each node, if an upstream
neighbor is doing VC merge then that upstream neighbor requires only
a single VPI/VCI for a particular stream (this is analogous to the
requirement for a single label in the case of operation over frame
media). If the upstream neighbor is not doing merge, then the
neighbor will require a single VPI/VCI per stream for itself, plus
enough VPI/VCIs to pass to its upstream neighbors. The number
required will be determined by allowing the upstream nodes to request
additional VPI/VCIs from their downstream neighbors (this is again
analogous to the method used with frame merge).
A similar method is possible to support nodes which perform VP merge.
In this case the VP merge node, rather than requesting a single
VPI/VCI or a number of VPI/VCIs from its downstream neighbor, instead
may request a single VP (identified by a VPI) but several VCIs within
the VP. Furthermore, suppose that a non-merge node is downstream
from two different VP merge nodes. This node may need to request one
VPI/VCI (for traffic originating from itself) plus two VPs (one for
each upstream node), each associated with a specified set of VCIs (as
requested from the upstream node).
In order to support all of VP merge, VC merge, and non-merge, it is
therefore necessary to allow upstream nodes to request a combination
of zero or more VC identifiers (consisting of a VPI/VCI), plus zero
or more VPs (identified by VPIs) each containing a specified number
of VCs (identified by a set of VCIs which are significant within a
VP). VP merge nodes would therefore request one VP, with a contained
VCI for traffic that it originates (if appropriate) plus a VCI for
each VC requested from above (regardless of whether or not the VC is
part of a containing VP). VC merge node would request only a single
VPI/VCI (since they can merge all upstream traffic into a single VC).
Non-merge nodes would pass on any requests that they get from above,
plus request a VPI/VCI for traffic that they originate (if
appropriate).
3.27. Tunnels and Hierarchy
Sometimes a router Ru takes explicit action to cause a particular
packet to be delivered to another router Rd, even though Ru and Rd
are not consecutive routers on the Hop-by-hop path for that packet,
and Rd is not the packet's ultimate destination. For example, this
may be done by encapsulating the packet inside a network layer packet
whose destination address is the address of Rd itself. This creates
a "tunnel" from Ru to Rd. We refer to any packet so handled as a
"Tunneled Packet".
3.27.1. Hop-by-Hop Routed Tunnel
If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we
say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit
endpoint" is Ru and whose "receive endpoint" is Rd.
3.27.2. Explicitly Routed Tunnel
If a Tunneled Packet travels from Ru to Rd over a path other than the
Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel"
whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.
For example, we might send a packet through an Explicitly Routed
Tunnel by encapsulating it in a packet which is source routed.
3.27.3. LSP Tunnels
It is possible to implement a tunnel as a LSP, and use label
switching rather than network layer encapsulation to cause the packet
to travel through the tunnel. The tunnel would be a LSP <R1, ...,
Rn>, where R1 is the transmit endpoint of the tunnel, and Rn is the
receive endpoint of the tunnel. This is called a "LSP Tunnel".
The set of packets which are to be sent though the LSP tunnel
constitutes a FEC, and each LSR in the tunnel must assign a label to
that FEC (i.e., must assign a label to the tunnel). The criteria for
assigning a particular packet to an LSP tunnel is a local matter at
the tunnel's transmit endpoint. To put a packet into an LSP tunnel,
the transmit endpoint pushes a label for the tunnel onto the label
stack and sends the labeled packet to the next hop in the tunnel.
If it is not necessary for the tunnel's receive endpoint to be able
to determine which packets it receives through the tunnel, as
discussed earlier, the label stack may be popped at the penultimate
LSR in the tunnel.
A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as
an hop-by-hop routed LSP between the transmit endpoint and the
receive endpoint.
An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an
Explicitly Routed LSP.
3.27.4. Hierarchy: LSP Tunnels within LSPs
Consider a LSP <R1, R2, R3, R4>. Let us suppose that R1 receives
unlabeled packet P, and pushes on its label stack the label to cause
it to follow this path, and that this is in fact the Hop-by-hop path.
However, let us further suppose that R2 and R3 are not directly
connected, but are "neighbors" by virtue of being the endpoints of an
LSP tunnel. So the actual sequence of LSRs traversed by P is <R1,
R2, R21, R22, R23, R3, R4>.
When P travels from R1 to R2, it will have a label stack of depth 1.
R2, switching on the label, determines that P must enter the tunnel.
R2 first replaces the Incoming label with a label that is meaningful
to R3. Then it pushes on a new label. This level 2 label has a
value which is meaningful to R21. Switching is done on the level 2
label by R21, R22, R23. R23, which is the penultimate hop in the
R2-R3 tunnel, pops the label stack before forwarding the packet to
R3. When R3 sees packet P, P has only a level 1 label, having now
exited the tunnel. Since R3 is the penultimate hop in P's level 1
LSP, it pops the label stack, and R4 receives P unlabeled.
The label stack mechanism allows LSP tunneling to nest to any depth.
3.27.5. Label Distribution Peering and Hierarchy
Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>,
and when going from R2 to R3 travels along a Level 2 LSP <R2, R21,
R22, R3>. From the perspective of the Level 2 LSP, R2's label
distribution peer is R21. From the perspective of the Level 1 LSP,
R2's label distribution peers are R1 and R3. One can have label
distribution peers at each layer of hierarchy. We will see in
sections 4.6 and 4.7 some ways to make use of this hierarchy. Note
that in this example, R2 and R21 must be IGP neighbors, but R2 and R3
need not be.
When two LSRs are IGP neighbors, we will refer to them as "local
label distribution peers". When two LSRs may be label distribution
peers, but are not IGP neighbors, we will refer to them as "remote
label distribution peers". In the above example, R2 and R21 are
local label distribution peers, but R2 and R3 are remote label
distribution peers.
The MPLS architecture supports two ways to distribute labels at
different layers of the hierarchy: Explicit Peering and Implicit
Peering.
One performs label distribution with one's local label distribution
peer by sending label distribution protocol messages which are
addressed to the peer. One can perform label distribution with one's
remote label distribution peers in one of two ways:
1. Explicit Peering
In explicit peering, one distributes labels to a peer by
sending label distribution protocol messages which are
addressed to the peer, exactly as one would do for local label
distribution peers. This technique is most useful when the
number of remote label distribution peers is small, or the
number of higher level label bindings is large, or the remote
label distribution peers are in distinct routing areas or
domains. Of course, one needs to know which labels to
distribute to which peers; this is addressed in section 4.1.2.
Examples of the use of explicit peering is found in sections
4.2.1 and 4.6.
2. Implicit Peering
In Implicit Peering, one does not send label distribution
protocol messages which are addressed to one's peer. Rather,
to distribute higher level labels to ones remote label
distribution peers, one encodes a higher level label as an
attribute of a lower level label, and then distributes the
lower level label, along with this attribute, to one's local
label distribution peers. The local label distribution peers
then propagate the information to their local label
distribution peers. This process continues till the
information reaches the remote peer.
This technique is most useful when the number of remote label
distribution peers is large. Implicit peering does not require
an n-square peering mesh to distribute labels to the remote
label distribution peers because the information is piggybacked
through the local label distribution peering. However,
implicit peering requires the intermediate nodes to store
information that they might not be directly interested in.
An example of the use of implicit peering is found in section
4.3.
3.28. Label Distribution Protocol Transport
A label distribution protocol is used between nodes in an MPLS
network to establish and maintain the label bindings. In order for
MPLS to operate correctly, label distribution information needs to be
transmitted reliably, and the label distribution protocol messages
pertaining to a particular FEC need to be transmitted in sequence.
Flow control is also desirable, as is the capability to carry
multiple label messages in a single datagram.
One way to meet these goals is to use TCP as the underlying
transport, as is done in [MPLS-LDP] and [MPLS-BGP].
3.29. Why More than one Label Distribution Protocol?
This architecture does not establish hard and fast rules for choosing
which label distribution protocol to use in which circumstances.
However, it is possible to point out some of the considerations.
3.29.1. BGP and LDP
In many scenarios, it is desirable to bind labels to FECs which can
be identified with routes to address prefixes (see section 4.1). If
there is a standard, widely deployed routing algorithm which
distributes those routes, it can be argued that label distribution is
best achieved by piggybacking the label distribution on the
distribution of the routes themselves.
For example, BGP distributes such routes, and if a BGP speaker needs
to also distribute labels to its BGP peers, using BGP to do the label
distribution (see [MPLS-BGP]) has a number of advantages. In
particular, it permits BGP route reflectors to distribute labels,
thus providing a significant scalability advantage over using LDP to
distribute labels between BGP peers.
3.29.2. Labels for RSVP Flowspecs
When RSVP is used to set up resource reservations for particular
flows, it can be desirable to label the packets in those flows, so
that the RSVP filterspec does not need to be applied at each hop. It
can be argued that having RSVP distribute the labels as part of its
path/reservation setup process is the most efficient method of
distributing labels for this purpose.
3.29.3. Labels for Explicitly Routed LSPs
In some applications of MPLS, particularly those related to traffic
engineering, it is desirable to set up an explicitly routed path,
from ingress to egress. It is also desirable to apply resource
reservations along that path.
One can imagine two approaches to this:
- Start with an existing protocol that is used for setting up
resource reservations, and extend it to support explicit
routing and label distribution.
- Start with an existing protocol that is used for label
distribution, and extend it to support explicit routing and
resource reservations.
The first approach has given rise to the protocol specified in
[MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS-
CR-LDP].
3.30. Multicast
This section is for further study
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
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.
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
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
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
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:
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
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,