Network Working Group Albert Tian
Internet Draft Redback Networks
Expiration Date: Nov 2004 George Apostolopoulos
ICS-FORTH
May 2004
Source Routed MPLS LSP using Domain Wide Label
draft-tian-mpls-lsp-source-route-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
One advantage that MPLS provides is that it allows traffic to be
directed through an explicit path that deviates from IP routing.
Such ability is widely used in traffic-engineering and fast-reroute.
Currently signaling protocols such as RSVP is needed to establish and
maintain such an explicit Label Switched Path. When there are a large
number of such signaled LSPs in the network, the aggregated signaling
and maintenance overhead can be significant.
In this paper, we propose a way to establish a source routed explicit
path with zero signaling overhead. The scheme uses a stack of labels
and requires domain wide LDP FEC to label bindings.
Tian & Apostolopoulos [Page 1]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
3. Introduction
On merging capable LSRs, LDP builds merging LSP trees rooted at the
egress of the FEC. LDP allocated labels usually are only of local
significance. In other words, an FEC can bind to different labels on
different links in a network. By doing so, each LSR can achieve
conflict free label allocation without any coordination.
But in some cases, a domain wide FEC to label binding may be
desirable. In a domain wide FEC to label binding, a given label is
always bound to the same FEC on all links in the network, if a
binding for the given label exists. We call such a label a Domain
Wide Label(DWL). For example: FEC-d corresponds to a loopback
interface address d on LSR-D.
In traditional FEC to label binding, FEC-d can bind to different
labels on different links:
label 30 label 20 label 10
FEC-d : A ------- B ------- C ------- D
In domain wide label binding, FEC-D binds to the same label 10 on all
links:
label 10 label 10 label 10
FEC-d : A ------- B ------- C ------- D
4. Terminologies
Domain Wide Label (DWL): A label is said to be a Domain Wide Label if
the FECs that map to that label are always the same on all links in a
MPLS domain.
Local Label: A label is said to be a local label if multiple
distinctive FECs can map to that label on different links in a MPLS
domain.
Direct Label: A label is said to be a Direct Label if the label
binding belongs to an one hop LSP whose egress is adjacent to its
ingress.
Domain Wide Direct Label (DWDL): A Domain Wide Label that is also a
Direct Label.
Tian & Apostolopoulos [Page 2]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
5. Source Routed LSP
DWL allows an efficient way to support source route in an LDP based
network using a stack of labels.
5.1. An example
For example, in the following network there are 6 LSRs A through F.
Each LSR has a loopback interface with a domain wide label allocated
for it. Assuming LDP is running on all the LSRs and LDP can be
enhanced to distribute such domain wide label bindings throughout the
MPLS domain. The domain wide labels still have the same semantics as
other LDP labels, just that the same label here always maps to the
same FEC on all LSRs in the MPLS domain. Later in this document, we
will give out the details on the LDP enhancements.
+-------> 60/30/P ---> 30/P -------->+
^ |
| D-----------E-----------F |
| | 40 50 60 | v
50/60/30/P | | P
| 10 20 30 |
A-----------B-----------C
Fig. 1
The domain wide label allocation on all LSRs are as follows:
LSR Label Loopback-Interface-prefix/FEC
A 10 a
B 20 b
C 30 c
D 40 d
E 50 e
F 60 f
In this example, all LSRs would use label 10 to deliver packets to
address a on LSR A, and use label 30 to deliver packets to address c
on LSR C, and so on and so forth.
Lets say that normally LSR A would use label 30 to deliver packets to
C along path A-B-C. So FEC c to label 30 mapping must be installed on
all LSRs on the path. Here we assume this can be achieved by the
enhanced LDP.
Now if LSR A wants to use an alternative path A-D-E-F-C to deliver
packets to C, it can push an additional label stack 40/50/60/30 on to
Tian & Apostolopoulos [Page 3]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
the packet and forward the packet according to label FIB. Here 40 is
the top (outer most) label. If PHP is enabled, the top label 40 will
be popped on LSR A and the packet will be forwarded to LSR D
according to the action associated with label 40. When the packet
arrives on LSR D, the top label 50 will determine the nexthop to be
LSR E with action pop. Similar procedures will happen on LSR E and F,
eventually deliver the payload P to LSR C.
If PHP is disabled on these LSRs, the labels will not be popped at
the penultimate hop resulting in one extra label on the label stack
in the packet.
Similarly, LSR A can use stack 50/30 to specify a Loosely Source
Routed Path A-E-C. In this case top label will deliver the packet to
LSR E, and the next label 30 will deliver the packet to LSR C.
5.2. Benefits of Source Routed LSP
There are several advantages of such source routed LSPs.
5.2.1. Zero signaling and maintenance overhead
Since these LSPs are source routed, there is no signaling overhead
and no maintenance overhead. Also only the headend of the LSP needs
to maintain the state related to the LSP, other LSRs on the LSP are
not even aware of the existence of such LSPs.
This makes source routed LSPs perfect for establishing bypass LSPs
for fast-reroute. In such applications, numerous bypass LSPs need to
be created and maintained yet only to be used very infrequently when
some link or node fails in a network.
5.2.2. Zero signaling delay
Also because the LSPs are source routed, they can be used immediately
after the stack of labels are determined. This allows LSPs to be
adjusted on the fly without any interruption. In other words, make-
before-break is inherit in the design.
Tian & Apostolopoulos [Page 4]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
5.3. Strictly Source Routed Path
Using a stack of DWLs, one can construct a Loosely Source Routed
Path(LSRP).
In most LDP enabled networks, an one hop LDP LSP exists on every LDP
enabled link in the network. This will be true if at least one direct
link between any two adjacent LSRs is preferred by IP routing. In
such networks, if an explicitly route path specifies every node in
the path, then the corresponding source routed LSP constructed using
a stack of DWLs will represent a Strictly Source Routed Path.
However, in some cases if all direct links between two adjacent LSRs
have been configured with higher link costs than alternative indirect
paths, then these direct links will not be used by IP routing.
Z
/ \
1 1
/ \
X---3---Y
100
Fig. 2
In the example given in Fig. 2, the link costs are marked on the
links among three LSRs X, Y and Z. Label 100 is an LDP label whose
egress is on LSR Y. Even when there is a direct link between X and Y,
MPLS packets arriving on X with top label 100 will still be forwarded
to LSR Z, since the path X-Z-Y has a better metric.
In order to guarantee a Strictly Source Routed Path between X and Y
in this scenario, one hop LSPs need to be created over the link
between X and Y even though the link is not preferred by IP routing.
If a DWL is used in such a one hop LSP, it is called a DWDL. Using a
stack of DWDLs, we can construct a Strictly Source Routed Path.
Tian & Apostolopoulos [Page 5]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
6. Other applications of DWL
6.1. DWL and LDP node protection
In applications such as LDP node protection as described in [SHEN00],
an LSR needs to learn labels allocated by the next-nexthop LSR for a
given FEC. Without DWL, protocol extensions as outlined in [SHEN00]
will be needed to propagate that information. In a DWL enabled LDP
network, the protocol extensions described in [SHEN00] will not be
needed since the next-nexthop label for a FEC will be the same as the
label allocated on the local box if that label is a DWL.
6.2. DWL can help in troubleshooting
DWL makes the network easier to troubleshoot. Since each FECs using
DWL bind to the same label on all the hops, packets with such a label
can be correlated to the FEC easily.
7. LDP extensions
Here we assume platform label space is used.
7.1. LDP extensions for DWL
7.1.1. Reserve a pool of labels for DWL
A pool of labels need to be set aside on all LSRs in the domain to be
used as DWLs. Local labels MUST not be allocated from this pool,
otherwise we can not guarantee that the same label always maps to the
same FEC. After the pool of labels are reserved, LSRs can then
allocate domain wide labels from the pool.
We propose to reserve labels in range 0xFF000 to 0xFFFF0 for DWL.
Implementations should allow user to change the DWL label range. All
LSRs in a domain MUST agree on the range of labels reserved for DWL
to avoid allocating local labels from the DWL pool.
Tian & Apostolopoulos [Page 6]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
7.1.2. Allocate DWL
In most cases, each LSR is allocated a unique DWL from the DWL pool
for its loopback interface address FEC. This FEC to DWL binding will
be propergated throughout the MPLS domain using LDP.
This allocation can be achieved in several ways:
a) manually allocate via configuration, or
b) automatically allocate through a centralized server, or
c) algorithmatically derived from something else.
Method a) is the most strait forward. In this case the operator needs
to make sure there are no conflicts in DWL allocations. Since each
LSR only needs one or in some cases two DWLs, this should not be a
big burden for operators.
7.1.3. Detecting and Advertising DWL
An LSR can determine if a label is a DWL by checking if it falls
within the DWL range. Hence DWL can be advertised using the existing
Generic Label TLV.
7.1.4. Extension to label mapping procedure
When a LABEL MAPPING message is received with a DWL in the label TLV,
the receiving LSR SHOULD try to allocate the same label for the FEC.
If the received DWL is already allocated to a different FEC, a local
label SHOULD be allocated for the FEC, and a NOTIFICATION message
with non-fatal status code **TBD** SHOULD be sent to the advertising
router.
7.1.5. PHP
Since DWL label values need to be communicated to adjacent LSRs to be
further propagated upstream, implicit-null label can not be used to
indicate PHP operation. There are two solutions to this problem.
7.1.5.1. Implicit PHP
PHP is implied for /32 prefix FEC or host FEC if the address in the
FEC is among the addresses advertised in ADDRESS messages from the
adjacent LSR, and the advertising LSR is not a targeted neighbor.
Tian & Apostolopoulos [Page 7]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
7.1.5.2. Explicit PHP
If PHP is not desired for a /32 prefix FEC or a host FEC, or if PHP
is desired for other FECs, the explicit PHP mechanism should be used.
The N-bit in the optional Label Attribute TLV can be used to
explicitly signal PHP for DWL. If the N-bit is set, then the
advertising router is signaling that PHP is desired; otherwise, PHP
is not desired.
For compatibility reasons, a Generic Label TLV and a Label Attribute
TLV may co-exist in a LABEL MAPPING message to advertise the same DWL
for a given FEC.
7.2. LDP extensions for DWDL
7.2.1. Label Attribute TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Label Attribute TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Value | Reserved |E|D|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags (0 to 4*n bytes, reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Value:
This is a 20-bit label value as specified in [RFC3032]
represented as a 20-bit number in a 4 octet field.
N-bit:
The Implicit Null bit. If set then the label should be
processed as if an Implicit Null Label(3) were received.
D-bit:
The Direct Label bit. If set then the label is a Direct Label.
E-bit:
The Egress bit. If set then the egress of the FEC that is
bound to the label is on the advertising router.
Flags:
Optional. Must be multiple of 4 bytes. Reserved.
Tian & Apostolopoulos [Page 8]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
7.2.2. DWDL Procedures
7.2.2.1. Egress LSR
The Egress LSR can allocate a DWDL for a FEC. The Egress LSR should
include a Label Attribute TLV in the LABEL MAPPING message for the
DWDL. The D-bit and the E-bit MUST be set. The N-bit can be set or
cleared depending on weather PHP is desired.
7.2.2.2. Neighbors of the Egress LSR
When a LABEL MAPPING message with Label Attribute TLV is received, if
both E-bit and D-bit are set, then a one hop LSP SHOULD be created
over the links between the receiving LSR and the advertising LSR, the
ingress of the LSP is the receiving LSR and the egress of the LSP is
the advertising LSR, the outgoing label is the DWDL, and the output
links are the direct links between the two LSRs.
The E-bit MUST be cleared when further propagating the Label
Attribute TLV upstream.
7.2.2.3. Other LSRs
When a LABEL MAPPING message with Label Attribute TLV is received, if
D-bit is set and E-bit is cleared, then the receiving LSR should
simply record the DWDL value and further propagate the Label
Attribute TLV upstream. No one hop LSP should be created for this
DWDL.
7.3. Construct Source Routed LSP using DWL
Assuming an explicitly routed path is specified by a list of IP
prefixes, each of which represents either a loose hop or a strict
hop. Given such a path, we can construct a Source Routed LSP using
the following algorithm:
a) Set the current node to be the last node in the path, and set the
label stack to be empty.
b) If the current node is a strict hop, find the DWDL that is bound
to the IP prefix, and push the DWDL on to the stack. If the
current node is a loose hop, or if the current node is a strict
hop but a DWDL is not found, find the DWL that is bound to the IP
prefix, and push the DWL on to the stack.
Tian & Apostolopoulos [Page 9]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
c) If the current node is the first node in the path, go to end.
Otherwise set the current node to its previous node in the path,
goto step a).
The resulting label stack represents a source routed LSP, and can be
used to forward packets from the first hop to the last hop following
the desired path.
8. Other Considerations
8.1. Typical Scenarios
8.1.1. DWL only with implied PHP
If in a network has LDP one hop LSPs on every link in the network,
then a stack of DWL can be used to construct either a strictly or
loosely source routed path. If LDP is advertising /32 loopback
interface FECs for all LSRs, then PHP can be implied. In this case,
DWLs can be allocated for each loopback FECs and can be implemented
without the Label Attribute TLV.
8.1.2. DWL with implied PHP on all nodes, DWDL on few nodes
If in a network, very few links have high cost configured therefore
do not have one hop LDP LSPs established over them, then DWDLs may be
allocated on LSRs adjacent to these links to create one hop LSPs over
them. The rest of the LSRs only need DWLs with implied PHP. Label
Attribute TLV will be needed to advertise the DWDLs.
8.1.3. Both Loose and Strict Source Routing -- DWL and DWDL
Operators may choose to use both DWL and DWDL in their networks for
maximum flexibility. One DWL and one DWDL will be allocated for each
LSR. Both the DWL and DWDL will be included in the LABEL MAPPING
messages, and Label Attribute TLV will be used.
8.2. Verification of Source Routed Paths
Standard tools such as MPLS ping and MPLS traceroute can be used to
verify a source routed path is functioning as expected.
Tian & Apostolopoulos [Page 10]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
8.3. Compatibility Considerations
The solution proposed in this document is compatible with existing
LDP specification. LSRs that do not understand DWL/DWDL will not get
the benefit of DWL, but basic LDP connectivity should remain intact.
8.4. Loop Prevention
One very nice attribute of the source routed LSP is that as long as
each hop is loop free, the path will also be loop free.
It is possible to construct a LSP that visit the same LSR twice by
including the same DWL twice in the stack, but no loop will be
created.
It is recommended for LSRs that support DWL to copy TTL values from
the outer label to inner label when a label is popped, to avoid
delayed TTL expiration.
9. Security Considerations
This document proposed a new and efficient way to implement source
route. All known security concerns related to source routing may also
be concerns here. The concerns can be reduced greatly by not
accepting LSPs from outside the MPLS domain.
10. Acknowledgments
The authors would like to thank Naiming Shen and Enke Chen for their
comments.
11. References
[RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[SHEN00] N. Shen, E. Chen, A. Tian, "Discovering LDP Next-Nexthop
Labels", draft-shen-mpls-ldp-nnhop-label-00.txt, work in progress.
[SHEN01] N. Shen and P. Pan, "Nexthop Fast ReRoute for IP and
MPLS", draft-shen-nhop-fastreroute-00.txt, work in progress.
Tian & Apostolopoulos [Page 11]
Internet Draft draft-tian-mpls-lsp-source-route-00.txt May 2004
12. Author Information
Albert Tian
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
Email: tian@redback.com
George Apostolopoulos
ICS-FORTH, Institue of Computer Science,
Foundation of Research and Technology Hellas
Tian & Apostolopoulos [Page 12]