Network Working Group Albert J. Tian
Internet Draft Redback Networks
Expiration Date: Jan 2005 George Apostolopoulos
ICS-FORTH
July 2004
Source Routed MPLS LSP using Domain Wide Label
draft-tian-mpls-lsp-source-route-01.txt
1. Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
Tian & Apostolopoulos [Page 1]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
and requires domain wide LDP FEC to label bindings.
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).
Consider the following example where 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.
Tian & Apostolopoulos [Page 2]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
5. Source Routed LSP
DWL allows an efficient way to support source routing in an LDP
enabled 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-01.txt July 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-01.txt July 2004
5.3. Other Benefits of DWL
5.3.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.
5.3.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.
6. Strictly Source Routed Segments over High Cost Links
Using a stack of DWLs, one can construct a Loosely Source Routed
Path(LSRP), with each DWL representing a loose segment on the path.
In most LDP enabled networks, at direct link between two LSRs is the
shortest path between the two according to routing. In such a
network, a DWL for a directly connected neighbor will deliver packets
over one or more of the directly connect links to that neighbor. In
this case, strict segments in an explicit path can be implemented
using DWLs.
However, in some cases if all direct links between two adjacent LSRs
have been configured with higher link costs than the shortest
indirect paths, then these direct links will not be used by IP
routing except for packets whose destination address is the interface
address on the far end of the high cost link.
1-------------Z-------------1
| |
| |
| | 1.1.1.1/32 loopback label 100
X-------------3-------------Y
10.1.1.1/24 10.1.1.2/24 interface address label 10
Fig. 2
Tian & Apostolopoulos [Page 5]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
In the example given in Fig. 2, the costs of the links among three
LSRs X, Y and Z are marked on the links. Label 100 is a DWL for FEC
1.1.1.1/32 whose egress is a loopback interface address 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. The only traffic that will
be sent over the direct link between X and Y is traffic from X with
destination 10.1.1.2, and vise versa, due to the fact that most of
the implementations prefer directly connected interface route over
any other route types.
In order to guarantee a Strictly Source Routed Segment between X and
Y in this scenario, a new Longest Match Address FEC element (LM-
Address FEC element) is introduced that uses longest prefix match
instead of exact match to find its matching route. The LM-Address FEC
element is defined in as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LM-Address(4) | Address Family | Host Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Host Addr |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
Two octet quantity containing a value from ADDRESS FAMILY
NUMBERS in [RFC1700] that encodes the address family for the
address prefix in the Prefix field.
Host Addr Len
Length of the Host address in octets.
Host Addr
An address encoded according to the Address Family field.
The LM-Address FEC element is essentially the same as the Host
Address FEC element, except that it has a different FEC element type
0x04.
To solve the strict hop over high cost link problem, a DWL needs to
be allocated on Y and bound to LM-Address FEC element 10.1.1.2. When
the binding is advertised to X, X performs a longest prefix match in
its routing table and finds the route 10.1.1.0/24. A LSP will be
created with link X-Y as the outgoing interface.
Tian & Apostolopoulos [Page 6]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
To specify a strict hop over a high cost link in an explicit path,
the interface address 10.1.1.2/32 needs to be used.
7. LDP extensions for DWL
7.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.
Implementations MUST allow user to configure 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.
Since most existing implementations allocate local labels from near
the lower end of the label space, label ranges near the higher end of
the label space is usually more suitable for DWLs.
7.2. Allocating 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 propagated 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) algorithmically 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.3. Advertising and Detecting 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.
Tian & Apostolopoulos [Page 7]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
7.4. Extensions to Label Mapping Procedures
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 SHOULD be sent to the advertising router.
The value of the status code is TBD.
7.5. PHP
Since DWL label values need to be communicated to adjacent LSRs so
that they can be further propagated upstream, implicit-null label can
not be used to signal PHP operation. One solution is to infer PHP
from ADDRESS messages.
For FEC with /32 Prefix FEC elements, or Host Address FEC elements,
or LM-Address FEC elements, if all the addresses in the FEC are among
the addresses in the ADDRESS messages from the advertising LSR, and
the advertising LSR is not a targeted neighbor, then PHP is assumed
for the LSP unless otherwise instructed by local policy.
8. 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) For the IP prefix of the current node, find an FEC element that
exactly matches the IP prefix. Host Address FEC elements and
LM-Address FEC elements are considered of having prefix length
32. Then find the DWL that is bound to that FEC element. Push
the DWL onto the stack.
If such DWL can not be found, abort the algorithm with an error.
c) If the current node is the first node in the path, terminate the
algorithm.
Otherwise set the current node to its predecessor in the path
and goto step a).
Tian & Apostolopoulos [Page 8]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
The resulting label stack represents a source routed LSP, and can be
used to forward packets from the starting point to the last hop
following the desired path.
9. Other Considerations
9.1. Interface Label Space
A LSR support interface label space needs to reserve the same DWL
label range on all interfaces, and needs to allocate the same label
for an FEC out of the reserved DWL label range.
9.2. ATM and Frame Lable Encoding
For a network using ATM label TLV or Frame Relay Label TLV, a
seperate DWL label range must be defined for each different label
encodings. Still DWLs can be advertised using the same ATM Label TLV
or the Frame Relay Label TLV.
9.3. 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.
9.4. Compatibility Considerations
The solution proposed in this document is compatible with existing
LDP specification. LSRs that do not understand DWL will not get the
benefit of DWL, but basic LDP connectivity should remain intact.
9.5. 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 visits the same LSR twice by
including the same DWL twice in the stack, but no infinite 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.
Tian & Apostolopoulos [Page 9]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
10. Security Considerations
This document proposed a new and efficient way to implement source
routing. All known security concerns related to source routing may
also be concerns here.
Please note that an attacker can use a stack of labels to perform
source routing today if label bindings are known on all routers on
the path. With this proposal, if label bindings on one router is
known to the attacker, then source routing can be utilized by the
attacker.
The main security concerns related to source routing include the
following scenarios where source routing may be abused:
- to bypass administrative control
- to make a malicious packet appear as if it had come from a trusted
system
- to reach otherwise unreachable part of the network such as
private address space
- to collect information about a network
The concerns can be eliminated by not accepting DWLs from outside the
trusted domain. This can be achieved by doing the following:
1) Do not accept labeled packets from outside the trusted domain.
If labeled packets must be accepted from outside, then do not
accept DWLs from outside the trusted domain. Since the DWL range
is known, this policy can be achieved by label based filtering
at the entrance points of the trusted domain to block packets
with any DWLs in the label stack.
2) Do not accept labeled packets arriving from tunnels (such as GRE
or IP-in-IP, etc). This can be achieved by disabling protocol ID
MPLS at tunnel next protocol ID demux point.
If MPLS over tunnel must be supported, then do not accept
labeled packets from tunnels originated from outside the trusted
domain.
If labeled packet must be accepted from tunnels originated from
outside the trusted domain, then do not accept labeled packets
with DWLs from these tunnels.
One difference between MPLS source route and IP source route option
is that the IP source route option is designed to specify the path
for both the request in the forwarding direction and the response in
Tian & Apostolopoulos [Page 10]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
the reverse direction, while MPLS source route can only specify the
path in the forward direction. Therefore the security risk for MPLS
source route is lower than the IP source route option.
11. IANA Considerations
A new LM-Address FEC element TLV is defined in this document with FEC
element type 0x04. This LDP extension requires this FEC element type
to be allocated by IANA.
A new status code for LDP NOTIFICATION message to notify the
conflicts in DWLs needs to be defined and allcoated by IANA.
12. Acknowledgments
The authors would like to thank Naiming Shen, Enke Chen and Acee
Lindem for their comments.
13. 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-01.txt, work in progress.
[SHEN01] N. Shen and P. Pan, "Nexthop Fast ReRoute for IP and
MPLS", draft-shen-nhop-fastreroute-01.txt, work in progress.
14. Author Information
Albert Jining 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
Email: georgeap@ics.forth.gr
Tian & Apostolopoulos [Page 11]
Internet Draft draft-tian-mpls-lsp-source-route-01.txt July 2004
15. Full Copyright Statement
Copyright (C) The Internet Society (year). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Tian & Apostolopoulos [Page 12]