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]