Network Working Group P. Dutta Internet-Draft M. Bocci Intended status: Standards Track Alcatel-Lucent Expires: June 14, 2013 L. Martini Cisco Systems December 11, 2012 Explicit Path Routing for Dynamic Multi-Segment Pseudowires draft-ietf-pwe3-mspw-er-02 Abstract Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit path may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in[RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 14, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Dutta, et al. Expires June 14, 2013 [Page 1] Internet-Draft MS-PW Explicit Routing December 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Explicit Path in MS-PW Signaling . . . . . . . . . . . . . . . 3 3.1. S-PE Addressing . . . . . . . . . . . . . . . . . . . . . 3 3.2. Explicit Route TLV (ER-TLV) . . . . . . . . . . . . . . . 4 3.3. Explicit Route Hop TLV (ER-Hop TLV) . . . . . . . . . . . 4 3.4. ER-Hop Semantics . . . . . . . . . . . . . . . . . . . . . 7 3.4.1. ER-Hop 1: IPv4 Prefix . . . . . . . . . . . . . . . . 7 3.4.2. ER-Hop 2: IPv6 Prefix . . . . . . . . . . . . . . . . 8 3.4.3. ER-Hop 3: L2 PW Address . . . . . . . . . . . . . . . 9 4. Explicit Route TLV Processing . . . . . . . . . . . . . . . . 10 4.1. Next-Hop Selection . . . . . . . . . . . . . . . . . . . . 10 4.2. Adding ER Hops to the Explicit Route TLV . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Dutta, et al. Expires June 14, 2013 [Page 2] Internet-Draft MS-PW Explicit Routing December 2012 1. Introduction Procedures for dynamically establishing multi-segment pseudowires (MS-PWs), where their paths are automatically determined using a dynamic routing protocol, are defined in [I-D.ietf-pwe3-dynamic-ms-pw]. For 1:1 protection of MS-PWs with primary and backup paths, MS-PWs SHOULD be established through a diverse set of S-PEs (Switching Provider-Edge) nodes to avoid any single points of failure at PW level. [I-D.ietf-pwe3-dynamic-ms-pw] allows this through BGP based mechanisms. This draft proposes an additional mechanism that allows the ST-PE (Source Terminating PEs) to explicitly choose the path that a PW would take through the intervening S-PEs. Explicit path routing of dynamic MS-PWs may also be required for controlled set-up of dynamic MS-PWs and network resource management. 2. Terminology This document uses the terminology defined in [I-D.ietf-pwe3-dynamic-ms-pw], [RFC4447]and [RFC5036]. The following additional terminology is used: Abstract Node: A group of nodes (S-PEs) representing an explicit hop along the path of an MS-PW. An abstract node is identified by an IPv4, IPv6 or S-PE address. 3. Explicit Path in MS-PW Signaling This section describes the LDP (Label Distribution Protocol) extensions required for signaling explicit paths in dynamic MS-PW set-up messages. 3.1. S-PE Addressing The T-PE MAY elect to select a known explicit path along a set of S-PEs for a specific PW. This requires that each S-PE be uniquely addressable in terms of pseudowires. For this purpose, at least one AII (Attachment Individual Indentifier) address of the format similar to AII type 2 [RFC5003] composed of the Global ID, and Prefix part, only, MUST be assigned to each S-PE. If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned with an S-PE address, then on receiving a Dynamic MS-PW label mapping message the S-PE MUST return a label release with the "Resources Unavailable" ( 0x38)" status code. Dutta, et al. Expires June 14, 2013 [Page 3] Internet-Draft MS-PW Explicit Routing December 2012 3.2. Explicit Route TLV (ER-TLV) The ER-TLV is an object that specifies the path to be taken by the MS-PW being established. Each hop along the path is represented by an abstract node, which is a group of one or more S-PEs, identified by an IPv4, and IPv6 or an S-PE address. The ER-TLV contains one or more Explicit Route Hop TLVs (ER-Hop TLVs) defined in Section 3.3. The ER-TLV format is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type = 0x0800 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node. Type A fourteen-bit field carrying the value of the ER-TLV Type = 0x0800. Length Specifies the length of the value field in bytes. ER-Hop TLVs One or more ER-Hop TLVs defined in Section 3.2. Explicit Route TLV 3.3. Explicit Route Hop TLV (ER-Hop TLV) The contents of an ER-TLV are a series of variable length ER-Hop TLVs. Each hop contains the identification of an "Abstract Node" that represents the hop to be traversed. Dutta, et al. Expires June 14, 2013 [Page 4] Internet-Draft MS-PW Explicit Routing December 2012 Each ER-Hop TLV has the form: Dutta, et al. Expires June 14, 2013 [Page 5] Internet-Draft MS-PW Explicit Routing December 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Content // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node. ER-Hop Type A fourteen-bit field carrying the type of the ER-Hop contents. Currently defined values are: Value Type ------ ------------------------ 0x0801 IPv4 prefix 0x0802 IPv6 prefix 0x0805 L2 PW address of PW Switching Point Length Specifies the length of the value field in bytes. L bit The L bit in the ER-Hop is a one-bit attribute. If the L bit is set, then the value of the attribute is "loose." Otherwise, the value of the attribute is "strict." For brevity, we say that if the value of the ER-Hop attribute is loose then it is a "loose ER-Hop." Otherwise, it's a "strict ER-Hop." Further, we say that the abstract node of a strict or loose ER-Hop is a strict or a loose node, respectively. Loose and strict nodes are always interpreted relative to their prior abstract nodes. The path between a strict node and its prior node MUST include only network nodes from the strict node and its prior abstract node. The path between a loose node and its prior node MAY include other network nodes, which are not part of the strict node or its prior abstract node. Contents A variable length field containing a node or abstract node which is one of the consecutive nodes that make up the explicitly routed PW. Dutta, et al. Expires June 14, 2013 [Page 6] Internet-Draft MS-PW Explicit Routing December 2012 ER-Hop TLV Details of ER Hop semantics are defined in section 2.4. 3.4. ER-Hop Semantics This section describes the various sementics associated with ER-HOP TLV. 3.4.1. ER-Hop 1: IPv4 Prefix The abstract node represented by this ER-Hop is the set of nodes, which have an IPv4 address, which lies within this prefix. Note that a prefix length of 32 indicates a single IPv4 node. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type = 0x0801 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Reserved | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node. Type A fourteen-bit field carrying the value of the ER-Hop 1, IPv4 Address, Type = 0x0801 Length Specifies the length of the value field in bytes = 8. L Bit Set to indicate Loose hop. Cleared to indicate a strict hop. Reserved Zero on transmission. Ignored on receipt. PreLen Prefix Length 1-32 IP Address A four-byte field indicating the IP Address. Dutta, et al. Expires June 14, 2013 [Page 7] Internet-Draft MS-PW Explicit Routing December 2012 ER-Hop with IPv4 Prefix 3.4.2. ER-Hop 2: IPv6 Prefix The abstract node represented by this ER-Hop is the set of nodes, which have an IPv6 address, which lies within this prefix. Note that a prefix length of 128 indicates a single IPv6 node. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0802 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Reserved | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node. Type A fourteen-bit field carrying the value of the ER-Hop 2, IPv6 Address, Type = 0x0802 Length Specifies the length of the value field in bytes = 20. L Bit Set to indicate Loose hop. Cleared to indicate a strict hop. Reserved Zero on transmission. Ignored on receipt. PreLen Prefix Length 1-128 IPv6 address A 128-bit unicast host addresses. Dutta, et al. Expires June 14, 2013 [Page 8] Internet-Draft MS-PW Explicit Routing December 2012 3.4.3. ER-Hop 3: L2 PW Address The L2 PW Address follows attachment circuit addressing which is derived from [RFC5003] AII type 2, as shown here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0802 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Reserved | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node. Type A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW Address, Type = 0x0805 Length Specifies the length of the value field in bytes = 18. L Bit Set to indicate Loose hop. Cleared to indicate a strict hop. Reserved Zero on transmission. Ignored on receipt. PreLen Prefix Length 1-96 L2 PW Address An AII Address as defined in [RFC5003]. Dutta, et al. Expires June 14, 2013 [Page 9] Internet-Draft MS-PW Explicit Routing December 2012 4. Explicit Route TLV Processing 4.1. Next-Hop Selection A PW Label Mapping Message containing an explicit route TLV MUST specify the next hop for a given MS-PW path. Selection of this next hop MAY involve a selection from a set of possible alternatives. The mechanism for making a selection from this set is implementation specific and is outside of the scope of this document. The mechanism used to select a particular path is also outside of the scope of this document, but each node MUST attempt to determine a loop-free path. Note that such mechanisms MAY be overridden by local policy. To determine the next hop for the MS-PW path, a node performs the following steps. Note that these procedures assume that a valid S-PE address has been assigned to the node, as per Section 3.1, above. 1. The node receiving the Label Mapping Message must evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop, it has received the message in error, and MUST reply with a Label Release Message with a "Bad Initial ER-Hop Error" (0x04000004) status code. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. If there is no first ER-Hop, the message is also in error and the node should return a "Bad Explicit Routing TLV Error" (0x04000001) status code in a Label Release Message sent to upstream node. 2. If there are no further ER-Hop TLVs following the first ER-Hop TLV, this indicates the end of the explicit route. The explicit route TLV MUST be removed from the Label Mapping Message. This node may or may not be the end of the PW. Processing continues as per Section 4.2, where a new explicit route TLV MAY be added to the Label Mapping Message. 3. If a second ER-Hop TV does exist, and the node is also a part of the abstract node described by the second ER-Hop, then the node deletes the first ER-Hop and continues processing with step 2, above. Note that this makes the second ER-Hop into the first ER- Hop for the iteration for the next PW segment. 4. The node determines if it is topologically adjacent to the abstract node described by the second ER-Hop. That is, it is directly connected to the next node by a PW control plane adjacency. If so, the node selects a particular next hop which is a member of the abstract node. The node then deletes the Dutta, et al. Expires June 14, 2013 [Page 10] Internet-Draft MS-PW Explicit Routing December 2012 first ER-Hop and continues processing as per Section 4.2, below. 5. Next, the node selects a next hop within the abstract node of the first ER-Hop that is along the path to the abstract node of the second ER-Hop. If no such path exists then there are two cases: A. If the second ER-Hop is a strict ER-Hop, then there is an error and the node MUST return a Label Release Message to upstream node with "Bad Strict Node Error" (0x04000002) status code. B. Otherwise, if the second ER-Hop is a loose ER-Hop, then the node selects any next hop that is along the path to the next abstract node. If no path exists within the MPLS domain, then there is an error, and the node MUST return a Label Release Message to upstream node with "Bad Loose Node Error" (0x04000002) status code. 6. Finally, the node replaces the first ER-Hop with any ER-Hop that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted. 7. Progress the Label Mapping Message to the next hop. 4.2. Adding ER Hops to the Explicit Route TLV After selecting a next hop, the node may alter the explicit route in the following ways. If, as part of executing the algorithm in Section 4.1, the explicit route TLV is removed, the node may add a new explicit route TLV. Otherwise, if the node is a member of the abstract node for the first ER-Hop, then a series of ER-Hops may be inserted before the First ER- Hop or may replace the first ER-Hop. Each ER-Hop in this series must denote an abstract node that is a subset of the current abstract node. Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary series of ER-Hops may be inserted prior to the first ER-Hop. 5. IANA Considerations RFC5036 [RFC5036] defines the LDP TLV name space which is maintained by IANA as "LDP TLV Registry". TLV types for the Explicit Route TLV, IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already Dutta, et al. Expires June 14, 2013 [Page 11] Internet-Draft MS-PW Explicit Routing December 2012 defined in the LDP TLV Registry. This draft proposes one new TLV type: TLV Type Suggested Value ------------------------------------ --------------- L2 PW Address of Switching point 0x0805 6. Security Considerations This document introduces no new security considerations over [RFC5036], [RFC4447] and [I-D.ietf-pwe3-dynamic-ms-pw]. 7. Acknowledgements The authors gratefully acknowledge the input of Lizhong Jin. 8. Normative References [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement of Multi Segment Pseudowires", draft-ietf-pwe3-dynamic-ms-pw-15 (work in progress), June 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. Dutta, et al. Expires June 14, 2013 [Page 12] Internet-Draft MS-PW Explicit Routing December 2012 Authors' Addresses Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road Mountain View, California 94043 USA Email: pranjal.dutta@alcatel-lucent.com Matthew Bocci Alcatel-Lucent Email: matthew.bocci@alcatel-lucent.com Luca Martini Cisco Systems Email: lmartini@cisco.com Dutta, et al. Expires June 14, 2013 [Page 13]