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]