MPLS C. Villamizar, Ed. Internet-Draft Outer Cape Cod Network Intended status: Standards Track Consulting Expires: August 30, 2012 February 27, 2012 Multipath Extensions for MPLS Traffic Engineering draft-villamizar-mpls-tp-multipath-te-extn-01 Abstract Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of carrying LSP with strict packet ordering requirements over multipath and and carrying LSP with strict packet ordering requirements within LSP without violating requirements to maintain packet ordering. LSP with strict packet ordering requirements include MPLS-TP LSP. OSPF-TE and ISIS-TE extensions defined here indicate node and link capability regarding support for ordered aggregates of traffic, multipath traffic distribution, and abilities to support multipath load distribution differently per LSP. RSVP-TE extensions either identifies an LSP as requiring strict packet order, or identifies an LSP as carrying one or more LSP that requires strict packet order at a given depth in the label stack, or identifies an LSP as having no restrictions on packet ordering except the restriction to avoid reordering microflows. In addition an extension indicates whether the first nibble of payload will reliably indicate whether payload is IPv4, IPv6, or other type of payload, most notably pseudowire using a pseudowire control word. 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 August 30, 2012. Villamizar Expires August 30, 2012 [Page 1] Internet-Draft MPLS TE Multipath February 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Villamizar Expires August 30, 2012 [Page 2] Internet-Draft MPLS TE Multipath February 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Architecture Summary . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 2.1. Multipath Node Capability sub-TLV . . . . . . . . . . . . 6 2.2. Multipath Link Capability TLV . . . . . . . . . . . . . . 9 2.3. Contained Ordered Aggregate Attributes TLV . . . . . . . . 9 2.4. LSP Multipath Attributes TLV . . . . . . . . . . . . . . . 11 3. Multipath Extension Protocol Mechanisms . . . . . . . . . . . 12 3.1. OSPF-TE and ISIS-TE Advertisement . . . . . . . . . . . . 12 3.1.1. Node Capability Advertisement . . . . . . . . . . . . 12 3.1.2. Link Capability Advertisement . . . . . . . . . . . . 13 3.1.3. Setting Max Depth and IP Depth . . . . . . . . . . . . 13 3.1.4. Hierarchical LSP Link Advertisement . . . . . . . . . 13 3.2. RSVP-TE LSP Attributes . . . . . . . . . . . . . . . . . . 14 3.2.1. LSP Attributes for Ordered Aggregates . . . . . . . . 14 3.2.2. LSP Attributes for Ordered Aggregates . . . . . . . . 15 3.2.3. Attributes for LSP without Packet Ordering . . . . . . 15 3.3. Path Computation Constraints . . . . . . . . . . . . . . . 16 3.3.1. Link Multipath Capabilities and Path Computation . . . 16 3.3.1.1. Path Computation with Ordering Constraints . . . . 17 3.3.1.2. Path Computation with No Ordering Constraint . . . 17 3.3.1.3. Path Computation for MPLS containing MPLS-TP . . . 17 3.3.2. Link IP Capabilities and Path Computation . . . . . . 18 3.3.2.1. LSP without Packet Ordering Requirements . . . . . 18 3.3.2.2. LSP with Ordering Requirements . . . . . . . . . . 19 3.3.2.3. LSP containing LSP with Ordering Requirements . . 19 3.3.3. Link Depth Limitations and Path Computation . . . . . 19 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 20 4.1. Legacy Multipath Behavior . . . . . . . . . . . . . . . . 20 4.2. Networks without Multipath Extensions . . . . . . . . . . 21 4.2.1. Netowrks with MP Capability on all Multipath . . . . . 21 4.2.2. Netowrks with OA Capability on all Multipath . . . . . 22 4.2.3. Legacy Netowrks with Mixed MP and OA Links . . . . . . 22 4.3. Transition to Multipath Extension Support . . . . . . . . 22 4.3.1. Simple Transitions . . . . . . . . . . . . . . . . . . 23 4.3.2. More Challenging Transitions . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Villamizar Expires August 30, 2012 [Page 3] Internet-Draft MPLS TE Multipath February 2012 1. Introduction Today the requirement to handle large aggregations of traffic, can be handled by a number of techniques which we will collectively call multipath. Multipath is very similar to composite link as defined in [ITU-T.G.800], except multipath specifically excludes inverse multiplexing. Some types of LSP, including but potentially not limited to MPLS-TP LSP, require strict packet ordering. Requirements to carry MPLS-TP LSP over multipath and a framework giving a number of methods to do so are defined in [I-D.villamizar-mpls-tp-multipath]. This document defines protocol extensions which provide a means of supporting MPLS as a server layer for MPLS-TP, or to carry MPLS-TP directly over a network which makes use of multipath. 1.1. Architecture Summary Advertisements in a link state routing protocol, such as OSPF or ISIS, support a topology map known as a link state database (LSDB). When traffic engineering information is included in the LSDB the topology map is known as a TE-LSDB or traffic engineering database (TED). A common MPLS LSP path computation is known as a constrained shortest path first computation (CSPF) (see [RFC3945]). Other algorithms may be used for path computation. Constraint-based routing was first introduced in [RFC2702]). OSPF-TE or ISIS-TE extensions are defined in Section 2.1 and Section 2.2. OSPF-TE or ISIS-TE advertisements serve to populate the TE-LSDB and provide the basis for constraint-based routing path computation. Section 3.1 describes the use of OSPF-TE or ISIS-TE multipath extensions in routing advertisements. RSVP-TE extensions are defined in Section 2.3 and Section 2.4. Section 3.2 describes the use of RSVP-TE extensions in setting up LSP including signaling constraints on LSP which contain other LSP which specify RSVP-TE extensions. Section 3.3 describes the constraints on LSP path computation imposed by the advertised ordered aggregate and multipath capabilities of links. Section 3.3.2 describes the constraints on LSP path computation imposed by link advertisements regarding use of IP headers in multipath traffic distribution. Section 3.3.3 describes the impact of label stack depth limitations. Villamizar Expires August 30, 2012 [Page 4] Internet-Draft MPLS TE Multipath February 2012 1.2. 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 RFC 2119 [RFC2119]. 1.3. Definitions Please refer to [I-D.villamizar-mpls-tp-multipath]. Ordered Aggregate (OA) An ordered aggregate (OA) requires that packets be delivered in the order in which they were received. Please refer to [RFC3260]. Microflow A microflow is a single instance of an application-to- application flow. Please refer to [RFC2475]. Reordering packets within a microflow can cause service disruption. Please refer to [RFC2991]. Multipath Traffic Distribution Multipath traffic distribution refers to the mechanism which distributes traffic among a set of component links or component lower layer paths which together comprise a multipath. No assumptions are made about the algorithms used in multipath traffic distribution. This document only discusses constraints of the type of information which can be used as the basis for multipath traffic distribution in specific circumstances. The phrase "strict packet ordering requirements" refers to the requirement to deliver all packet in the order that they were received. The absence of strict packet ordering requirements does not imply total absence of packet ordering requirements. The requirement to avoid reordering traffic within any given microflow, as described in [RFC2991] applies to all traffic aggregates including all MPLS LSP. 2. Protocol Extensions This section defined protocol extensions to OSPF-TE, ISIS-TE, and RSVP-TE to address requirements described in [I-D.villamizar-mpls-tp-multipath]. Two capability sub-TLV are added to two TLV that are used in both OSPF-TE and ISIS-TE. The Multipath Node Capability sub-TLV is added to the Node Attribute TLV (Section 2.1) The Multipath Link Capability TLV is added to the Interface_ID (Section 2.2). Villamizar Expires August 30, 2012 [Page 5] Internet-Draft MPLS TE Multipath February 2012 Two TLV are added to the LSP_ATTRIBUTES object defined in [RFC5420]. 2.1. Multipath Node Capability sub-TLV The Node Attribute TLV is defined in [RFC5786]. A new sub-TLV, the Multipath Node Capability sub-TLV, is defined for inclusion in the Node 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Min Depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Depth | IP Depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Multipath Capability Sub-TLV The fields in the Multipath Capability sub-TLV are defined as follows. Type The Type field is assigned a value of IANA-TBD-1. The Type field is a two octet value. Length The Length field indicates the length of the sub-TLV in octets, excluding the Type and Length fields. The Length field is a two octet value. Flags The Flags field is a two octet (16 bit) value. The following single bit fields are assigned within this value, starting at the most significant bit, which is the bit transmitted first. 0x8000 Ordered Aggregate Enabled Setting the Ordered Aggregate Enabled bit indicates that an LSP can be carried as an Ordered Aggregate Enabled on one or more links. 0x4000 Multipath Enabled Setting the Multipath Enabled bit indicates that an LSP can be spread across component links at one or more multipath links. Villamizar Expires August 30, 2012 [Page 6] Internet-Draft MPLS TE Multipath February 2012 0x2000 IPv4 Enabled Multipath Setting the IPv4 Enabled Multipath bit indicates that the IPv4 header information can be used in multipath load balance. The Multipath Enabled bit must be set if the IPv4 Enabled Multipath bit is set. 0x1000 IPv6 Enabled Multipath Setting the IP bit indicates that the IPv6 header information can be used in multipath load balance. The Multipath Enabled bit must be set if the IPv6 Enabled Multipath bit is set. 0x0800 UDPIPv4 Multipath Setting the UDPIPv4 Multipath bit indicates that the UDP port numbers carried in UDP over IPv4 can be used in multipath load balance. The IPv4 Enabled Multipath bit must be set if UDPIPv4 Multipath is set. If the IPv4 Enabled Multipath bit is set and the UDPIPv4 Multipath bit is clear, then only source and destination IP addresses are used. 0x0400 UDP/IPv6 Multipath Setting the UDP/IPv6 Multipath bit indicates that the UDP port numbers carried in UDP over IPv6 can be used in multipath load balance. The IPv6 Enabled Multipath bit must be set if UDP/ IPv6 Multipath is set. The IPv4 Enabled Multipath bit must be set if UDPIPv4 Multipath is set. If the IPv6 Enabled Multipath bit is set and the UDP/IPv6 Multipath bit is clear, then only source and destination IP addresses are used. 0x0200 TDPIPv4 Multipath Setting the TDPIPv4 Multipath bit indicates that the TCP port numbers carried in TCP over IPv4 can be used in multipath load balance. The IPv4 Enabled Multipath bit must be set if TDPIPv4 Multipath is set. If the IPv4 Enabled Multipath bit is set and the TDPIPv4 Multipath bit is clear, then only source and destination IP addresses are used. 0x0100 TCP/IPv6 Multipath Setting the TCP/IPv6 Multipath bit indicates that the TCP port numbers carried in TCP over IPv6 can be used in multipath load balance. The IPv6 Enabled Multipath bit must be set if TCP/ IPv6 Multipath is set. The IPv4 Enabled Multipath bit must be set if TDPIPv4 Multipath is set. If the IPv6 Enabled Multipath bit is set and the TCP/IPv6 Multipath bit is clear, then only source and destination IP addresses are used. Villamizar Expires August 30, 2012 [Page 7] Internet-Draft MPLS TE Multipath February 2012 0x0080 Default to Multipath Setting the Default to Multipath bit indicates that for an LSP which does not signal a desired behavior the traffic for that LSP will be spread across component links at one or more multipath links. If the Default to Multipath bit is not set, then an LSP which does not signal otherwise will be treated as an ordered aggregate. 0x0040 Default to IP/MPLS Multipath Setting the Default to IP/MPLS Multipath indicates that for an LSP which does not signal a desired behavior, the IP header information will be used in the multipath load distribution. If the Default to IP/MPLS Multipath is clear it indicates that the the IP header information will not be used by default. 0x0020 Variable Depth Multipath Setting the Variable Depth Multipath bit indicates that when multipath is enabled for a given LSP, the stack depth beyond which multipath will not extract information for use in the multipath load distribution can be set on a per LSP basis. 0x0010 IP Optional Multipath Setting the IP Optional Multipath bit indicates that when multipath is enabled for a given LSP, whether the IP header information is used in the multipath load distribution can be set on a per LSP basis. The remaining bits in the Flags field are reserved. Reserved The Reserved field MUST be set to zero and MUST be ignored unless implementing an extension. Min Depth The Min Depth field indicates the minimum stack depth which can be supported in the multipath traffic distribution. For links which are not PSC LSP, the Min Depth field is set to zero. For FA advertised for PSC LSP, this field will be set to one or more. See Section 3.1.4 for further details. Max Depth The Max Depth field is a one octet field indicating the maximum label stack depth beyond which the multipath load distribution cannot make use of further label stack entries. Villamizar Expires August 30, 2012 [Page 8] Internet-Draft MPLS TE Multipath February 2012 IP Depth The IP Depth field is a one octet field indicating the maximum label stack depth beyond which the multipath load distribution cannot make use of IP information. The reserved bits in the Flags field and the Reserved field MUST be set to zero and MUST be ignored unless implementing an extension which redefines one or more of the reserved bits. Any further extension which redefines one or more reserved Flags bit should maintain backwards compatibility with prior implementations. 2.2. Multipath Link Capability TLV The Interface_ID is defined in [RFC3471]. The Interface_ID is updated in [RFC4201] to support a form of multipath known as Link Bundling. A new TLV, the Multipath Link Capability TLV, is defined here. The Multipath Link Capability TLV is optionally included in the Interface_ID. The format of the Multipath Link Capability TLV is identical to the Multipath Node Capability sub-TLV defined in Section 2.1, with one exception. In the Multipath Link Capability TLV the Type field value is IANA-TBD-2. If a Multipath Link Capability TLV is advertised for any link, then a Multipath Node Capability sub-TLV MUST be advertised for the node. 2.3. Contained Ordered Aggregate Attributes TLV The LSP_ATTRIBUTES object is defined in [RFC5420]. A new Contained Ordered Aggregate Attributes TLV is defined for the LSP_ATTRIBUTES object. The TLV Type is IANA_TBD_3. The format is described below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | OA Depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Contained Ordered Aggregate Attributes TLV The fields in the Contained Ordered Aggregate Attributes TLV are defined as follows. Villamizar Expires August 30, 2012 [Page 9] Internet-Draft MPLS TE Multipath February 2012 Type The Type field is assigned a value of IANA-TBD-3. The Type field is a two octet value. Length The Length field indicates the length of the sub-TLV in octets, excluding the Type and Length fields. The Length field is a two octet value. Flags The Flags field is a three octet (24 bit) value. The following single bit fields are assigned within this value, starting at the most significant bit, which is the bit transmitted first. 0x80 IP Multipath Allowed Setting the IP Multipath Allowed bit indicates that it is safe to enable the use of a potential IP payload in the multipath traffic distribution. 0x40 May Contain IPv4 Setting the May Contain IPv4 bit indicates that IPv4 traffic may be contained within this LSP. 0x40 May Contain IPv6 Setting the May Contain IPv6 bit indicates that IPv6 traffic may be contained within this LSP. The remaining bits in the Flags field are reserved. OA Depth The OA Depth field is set as follows 0 An OA Depth value of zero indicates that no ordered aggregates are carried within the LSP. 1 An OA Depth value of one indicates that the LSP is an ordered aggregate of traffic (the LSP requires strict ordering of packets). >1 An OA Depth value greater than one indicates that the LSP does not have strict packet ordering requirements but contains ordered aggregates at the label stack depth indicated. The reserved bits in the Flags field MUST be set to zero and MUST be ignored unless implementing an extension which redefines one or more of the reserved bits. Any further extension which redefines one or more reserved Flags bit should maintain backwards compatibility with prior implementations. Villamizar Expires August 30, 2012 [Page 10] Internet-Draft MPLS TE Multipath February 2012 2.4. LSP Multipath Attributes TLV The LSP_ATTRIBUTES object is defined in [RFC5420]. A new LSP Multipath Attributes TLV is defined for the LSP_ATTRIBUTES object. The TLV Type is IANA_TBD_4. The format is described below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MP Depth | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Largest Microflow Capacities | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LSP Multipath Attributes TLV The fields in the LSP Multipath Attributes TLV are defined as follows. Type The Type field is assigned a value of IANA-TBD-4. The Type field is a two octet value. Length The Length field indicates the length of the sub-TLV in octets, excluding the Type and Length fields. The Length field is a two octet value. MP Depth The MP Depth field indicates the depth at which the Largest Microflow Capacities parameters are applicable. Largest Microflow Capacities The Largest Microflow Capacities field contains, one, two, or three IEEE 32 bit floating point values. Each value is a capacity expressed in bytes per second. Largest LSE Microflow The first value, the Largest LSE Microflow, is the capacity of the largest microflow if only the label stack entries are used in multipath traffic distribution. If a Largest LSE Microflow is not included, the LSP bandwidth request MUST be used. Villamizar Expires August 30, 2012 [Page 11] Internet-Draft MPLS TE Multipath February 2012 Largest IP Microflow The second value, the Largest IP Microflow, if present, is the capacity of the largest microflow if the label stack entries and any potential IP source and destination address are used in multipath traffic distribution. If the Largest IP Microflow is not included, the value of the Largest LSE Microflow MUST be used. Largest L4 Microflow The third, the Largest L4 Microflow, if present, is the capacity of the largest microflow if the label stack entries and any potential IP addresses and TCP or UDP port numbers are used in multipath traffic distribution. If a Largest L4 Microflow is not included, the value of the Largest IP Microflow MUST be used. The Reserved field MUST be set to zero and MUST be ignored unless implementing an extension which redefines all or part of this field. Any further extension which redefines all or part of this field should maintain backwards compatibility with prior implementations. If one or more LSP Multipath Attributes TLV is present, a Contained Ordered Aggregate Attributes TLV MUST be present. There SHOULD be no more than one LSP Multipath Attributes TLV for any value of the MP Depth field in any given LSP_ATTRIBUTES object. If additional LSP Multipath Attributes TLV are encountered they MUST be ignored. The value of the MP Depth field must be greater than zero and less than the value of the OA Depth field in the Contained Ordered Aggregate Attributes TLV, unless the OA Depth field is set to zero. 3. Multipath Extension Protocol Mechanisms 3.1. OSPF-TE and ISIS-TE Advertisement Every node MUST advertise exactly one Multipath Node Capability sub- TLV and may advertise zero of more Multipath Link Capability sub-TLV as needed. 3.1.1. Node Capability Advertisement Every LSR which is adjacent to one or more multipath link MUST advertise a Multipath Node Capability sub-TLV (see Section 2.1). The capabilities advertised for the node SHOULD reflect the capabilities of the majority of multipath links adjacent to the node. Villamizar Expires August 30, 2012 [Page 12] Internet-Draft MPLS TE Multipath February 2012 3.1.2. Link Capability Advertisement For all of the links whose capability does not exactly match the Multipath Node Capability sub-TLV advertised by that same LSR, the LSR MUST advertise a Multipath Link Capability sub-TLV (see Section 2.2). For all of the links whose capability does exactly match the Multipath Node Capability sub-TLV advertised by that same LSR, the LSR SHOULD NOT advertise a Multipath Link Capability sub-TLV (see Section 2.2). In this case the Multipath Link Capability TLV is redundant, but harmless. 3.1.3. Setting Max Depth and IP Depth The Max Depth and IP Depth field are intended to capture architectural limits. Most forwarding hardware will only use a limited number of labels in the multipath traffic distribution. This limit is reflected in the Max Depth field. Most forwarding hardware will limit the number of labels that it will look past before looking for an IP header to be used in the multipath traffic distribution. This limit is reflected in the IP Depth field. 3.1.4. Hierarchical LSP Link Advertisement A PSC LSP, as defined in [RFC4206] and updated in [RFC6107], may carry other LSP. When signaling a PSC LSP that is expected to carry MPLS-TP LSP or other LSP with strict packet reordering requirements at some label depth, the minimum label stack depth at which an LSP with strict packet reordering requirements can be carried must be signaled. A tradeoff must be considered. If allowed to look deep into the label stack, multipath traffic distribution is able to distribute traffic more evenly. It is impractical to carry LSP very deep in the stack solely for this purpose. When carrying LSP that has strict packet order requirements, the depth at which these LSP will be carried is a network design tradeoff. For example, if an MPLS-TP LSP is signaled as a PSC LSP, the the depth needs to be limited to one. To directly carry an LSP that requires strict packet ordering, the depth needs to be limited to two, where the two label stack entries are for the MPLS LSP with no packet order requirements other than for microflows and the contained LSP with strict packet order requirements. When the Forwarding Adjacency (FA) is advertised, the depth at which the label stack will inspected indicated in signaling at setup time Villamizar Expires August 30, 2012 [Page 13] Internet-Draft MPLS TE Multipath February 2012 is expressed in the Min Depth field of the Multipath Link Capability TLV. The advertised Max Depth and IP Depth of a PSC LSP must be one less that the minimum of the Max Depth and IP Depth of any link that the PSC LSP traverses. The Max Depth and IP Depth are considered independently of each other. 3.2. RSVP-TE LSP Attributes All LSP SHOULD advertise a Contained Ordered Aggregate Attributes TLV. LSP with strict packet order requirements MUST set the OA Depth field to one to indicate that the LSP MUST be treated as ordered aggregate. LSP which do not have strict packet order requirements MUST only carry LSP whose requirements are reflected in the containing LSP Contained Ordered Aggregate Attributes TLV and LSP Multipath Attributes TLVs or the containing LSP MUST either resignal appropriate TLVs using make-before-break semantics, or the contained LSP signaling must be rejected with a PathErr message. Three cases are described in the following subsections. 3.2.1. LSP Attributes for Ordered Aggregates The Flags field in the Contained Ordered Aggregate Attributes TLV MUST be set as follows. 1. If the LSP may directly contain IPv4 traffic, then the May Contain IPv4 bit in the Flags field MUST be set. 2. If the LSP may directly contain IPv6 traffic, then the May Contain IPv6 bit in the Flags field MUST be set. 3. If the LSP contains an LSP which has the May Contain IPv4 bit in the Flags field then the May Contain IPv4 bit in the Flags field MUST be set. 4. If the LSP contains an LSP which has the May Contain IPv6 bit in the Flags field then the May Contain IPv6 bit in the Flags field MUST be set. 5. If the LSP may contain pseudowires that do not use a pseudowire control word, or may contain IPv4 or IPv6 traffic, then the IP Multipath Allowed bit in the Flags field MUST be cleared. 6. If the LSP is known not to contain pseudowires that do not use a pseudowire control word, and is known not to contain IPv4 or IPv6 traffic, then the IP Multipath Allowed bit in the Flags field SHOULD be set unless disallowed due to a contained LSP. Villamizar Expires August 30, 2012 [Page 14] Internet-Draft MPLS TE Multipath February 2012 7. If the LSP is known not to contain pseudowires that do not use a pseudowire control word, and does not have strict packet ordering requirements, then the IP Multipath Allowed bit in the Flags field SHOULD be set unless disallowed due to a contained LSP. 8. If the IP Multipath Allowed bit in the Flags is set and the LSP has strict packet order requirements, the May Contain IPv4 and May Contain IPv6 MUST be clear. 9. If the LSP contains any LSP with the IP Multipath Allowed bit in the Flags field clear, then the IP Multipath Allowed bit in the Flags field MUST be clear. 10. If the LSP contains any LSP with either the May Contain IPv4 bit or the May Contain IPv6 bit in the Flags field set, and the containing LSP has strict packet ordering requirements, then the IP Multipath Allowed bit in the Flags field MUST be clear. If the LSP does not contain other LSP, then it can only contain pseudowire that terminate on that LSR. If the LSP does not contain other LSP, then it should be known whether the LSP is used in an IP LER capacity. Therefore, when a LSP does not contain other LSP, it should always be possible to accurately set the Flags field in the Contained Ordered Aggregate Attributes TLV. See Section 4 for guidelines for handling LSP which contain LSP that do not have a Contained Ordered Aggregate Attributes TLV. The most conservative approach in this case is to clear the IP Multipath Allowed bit and set the May Contain IPv4 bit and the May Contain IPv6 bit, however this may not always be necessary. 3.2.2. LSP Attributes for Ordered Aggregates An LSP with strict packet order requirements SHOULD always include a Contained Ordered Aggregate Attributes TLV. The OA Depth field MUST be set to one. The LSP SHOULD NOT include any LSP Multipath Attributes TLV. 3.2.3. Attributes for LSP without Packet Ordering If an LSP does not have strict packet order constraints, then the LSR_ATTRIBUTE object SHOULD always include a Contained Ordered Aggregate Attributes TLV. The OA Depth MUST be either set to zero or set to a configured value that is greater than one. If the OA Depth is set to a configured value, then any setup attempt for a contained LSP with a depth greater than or equal to that value Villamizar Expires August 30, 2012 [Page 15] Internet-Draft MPLS TE Multipath February 2012 SHOULD be rejected and a PathErr message sent. Otherwise, if a setup attempt for a contained LSP with a depth greater that the current value included in the containing LSP OA Depth field, then the containing LSP MUST be rerouted with a OA Depth field value greater than any of the contained OA Depth field values. The values in the LSP Multipath Attributes TLV may be constrained to upper limits by configuration. If an attempt to setup a contained LSP would result in exceeding one of these limits, then the LSR SHOULD reject the signaling attempt and send a PathErr message. If an LSP does not have strict packet order constraints, then the LSR_ATTRIBUTE object MAY contain one or more LSP Multipath Attributes TLV. If the LSP does not contain any other LSP, then one LSP Multipath Attributes TLV MAY be contained, with the MP Depth field set to one. In this case, the Largest LSE Microflow in the Largest Microflow Capacities field MUST be set to the requested bandwidth of the LSP. The optional Largest IP Microflow and Largest L4 Microflow MAY be included and set to configured values. If an LSP that does not have strict packet order constraints contains other LSP, then the LSP Multipath Attributes TLV advertised by the set of contained LSP MUST be used to set the LSP Multipath Attributes TLV Largest Microflow Capacities values for LSP Multipath Attributes TLV. The value of Largest LSE Microflow, Largest IP Microflow, and Largest L4 Microflow in the LSP Multipath Attributes TLV of the containing LSP with an MP Depth of N cannot be less than the maximum effective value of the same parameter for any contained LSP Multipath Attributes TLV with an MP Depth value of N-1. 3.3. Path Computation Constraints The RSVP-TE extensions provides a set of requirements to be met by the links which the LSP is to traverse. This set of requirements also serves as the basis for path computation constraints and for admission control constraints. 3.3.1. Link Multipath Capabilities and Path Computation Three cases are considered. An LSP may have strict ordering constraints. An MPLS-TP LSP is an example of an LSP with strict ordering constraints. This first type of LSP is covered in Section 3.3.1.1. An LSP may have no ordering constraints at all other than the constraint that microflows cannot be reordered. This second case is covered in Section 3.3.1.2. The remaining case is where an LSP has no ordering constraints but carries traffic for other LSP which do have ordering constraints. This third case is covered in Section 3.3.1.3. Villamizar Expires August 30, 2012 [Page 16] Internet-Draft MPLS TE Multipath February 2012 3.3.1.1. Path Computation with Ordering Constraints For an MPLS-TP LSP or other LSP with a strict packet ordering constraint, any link for which the Ordered Aggregate Enabled bit is not set must be excluded from the path computation. If the Default to Multipath bit is set on a link, then extensions to RSVP-TE to indicate a requirement to maintain packet order must be used in signaling to override the default. 3.3.1.2. Path Computation with No Ordering Constraint For an MPLS LSP which has no constraint on packet ordering except that microflows must remain in order and does not contain other LSP with ordering constraints, any link for which the Multipath Enabled bit is set SHOULD use an available bandwidth taken from the "Unreserved Bandwidth" rather than the "Maximum LSP Bandwidth" (see [RFC4201]). For most LSP, the bandwidth requirement of the largest microflow is not known but an upper bound is known. For example if the LSP aggregates PW or other LSP of no more than some maximum capacity or LSP which have signaled a microflow upper bound, then an upper bound on the largest microflow is known. If this upper bound exceeds the "Maximum LSP Bandwidth" of a given link, then that link SHOULD be excluded from the path computation. 3.3.1.3. Path Computation for MPLS containing MPLS-TP To carry LSP which have strict packet ordering requirements within LSP that do not have strict packet ordering requirements, the label stack depth at which multipath traffic distribution is allowed to take information must be limited. To set up such an LSP, the minimum label stack depth at which an MPLS-TP LSP or other LSP with strict ordering constraints will be carried must be known. For links which have the Variable Depth Multipath bit clear, the MPLS LSP MUST be treated as if the containing LSP has ordering constraints, unless the Max Depth for the link is equal to the minimum label stack depth at which an MPLS-TP LSP or other LSP with strict ordering constraints will be carried. If the LSP is treated as if the containing LSP has ordering constraints, bandwidth constraints MUST be applied as described in Section 3.3.1.1. Failing to do so would violate the ordering constraints of contained LSP. For links which have the Variable Depth Multipath bit set, constraints may be applied to links in the path computation as described in Section 3.3.1.2. The minimum label stack depth at which an MPLS-TP LSP or other LSP with strict ordering constraints is Villamizar Expires August 30, 2012 [Page 17] Internet-Draft MPLS TE Multipath February 2012 carried MUST be signaled when the LSP is set up. The minimum label stack depth at which an MPLS-TP LSP or other LSP with strict ordering constraints is carried limits the multipath load balance and therefore requires an additional constraint. For LSP that cannot be further subdivided using information in IP headers below the MPLS stack, those LSP are effectively equivalent to microflows from a multipath load distribution standpoint. If the largest bandwidth requirement for any such LSP carried at that depth is known, then any link for which the "Maximum LSP Bandwidth" is less than that bandwidth requirement SHOULD be excluded from the path computation. 3.3.2. Link IP Capabilities and Path Computation An MPLS-TP LSP cannot be reordered. There may be other types of LSP with strict packet ordering requirements. If LSP with strict packet ordering requirements carry IP, using IP headers in the multipath load distribution would violate the packet ordering requirements. Some LSP cannot be reordered but do not carry IP, and do not carry payloads which could be mistaken as IP. For example, any LSP carrying only pseudowire traffic, where all pseudowires are using a control word carries no payloads which could be mistaken as IP. These type of LSP can be carried within MPLS LSP that allow use of IP header information in multipath load distribution. 3.3.2.1. LSP without Packet Ordering Requirements Many LSP carry only IP or predominantly IP, use no hierarchy or have little diversity in the MPLS label stack, and carry far more traffic than can be carried over a single component link in a multipath. Many LSP due to their high capacity, must traverse only multipath which will use IP header information in the multipath traffic distribution. For these LSP, links must be excluded from the path computation which do not have the IPv4 Enabled Multipath and IPv6 Enabled Multipath bit set (if carrying both IPv4 and IPv6) and do not have either the Default to IP/MPLS Multipath bit set or the IP Optional Multipath bit set. Hierarchical PSC LSP which require the use IP header information in the multipath traffic distribution MUST NOT set the Ordered Aggregate Enabled bit, MUST set the Default to IP/MPLS Multipath bit, and MUST NOT set the VARIP bit in the FA advertisement. Villamizar Expires August 30, 2012 [Page 18] Internet-Draft MPLS TE Multipath February 2012 3.3.2.2. LSP with Ordering Requirements In some cases an MPLS-TP may carry no IP traffic directly under the label stack. For example, if only pseudowire service ([RFC3985]) is being supported by an LSP, and all pseudowires are using a control word, and all control and management information is carried in a generic associated channel ([RFC5586]), then no IP traffic is carried directly under the label stack. In this case, it is highly desirable to signal the MPLS-TP LSP to allow IP header information to be used in the multipath load distribution. Doing so will allow any MPLS LSP containing this MPLS-TP LSP to allow the use of IP header information in the multipath load distribution. Where MPLS-TP LSP are carrying IP, for any link for which the use of IP header information is not disabled or cannot be disabled on a per LSP basis, that link must be excluded from the path computation. Links which do not have to be excluded include link with the IPv4 Enabled Multipath and IPv6 Enabled Multipath bits clear, links with the Default to IP/MPLS Multipath clear, and links with the IP Optional Multipath bit set. For those links with the IP Optional Multipath set, MPLS-TP LSP which carry IP MUST explicitly disable the use of IP in the multipath load distribution in signaling if the Default to IP/MPLS Multipath is set and SHOULD explicitly disable the use o\ f IP in the multipath load distribution in signaling if the Default to IP/MPLS Multipath is clear. 3.3.2.3. LSP containing LSP with Ordering Requirements The largest effective microflow with respect to a given multipath link can depend on whether the link can use IP header information in the multipath traffic distribution. If a PSC LSP will need to carry traffic which cannot use IP header information in the multipath traffic distribution, then all links for which this capability is supported and enabled and cannot be disabled, must be excluded from the LSP path computation. Links which can be included in the LSP path computation include those with the IPv4 Enabled Multipath and IPv6 Enabled Multipath bits clear, those with the Default to IP/MPLS Multipath clear, or those with the VARIP set. For links with the IPv4 Enabled Multipath or IPv6 Enabled Multipath bit set, the Default to IP/MPLS Multipath bit set, and the VAR IP bit set, the requirement to disable use of IP in the multipath traffic distribution must be indicated in signaling. 3.3.3. Link Depth Limitations and Path Computation For any LSP which does not have strict packet ordering constraints, LSP configuration SHOULD include the following parameters. Villamizar Expires August 30, 2012 [Page 19] Internet-Draft MPLS TE Multipath February 2012 LSP Min Depth a minimal acceptable number of label used in multipath traffic distribution, LSP IP Depth a minimal label stack depth where the IP header can be used in multipath traffic distribution For example, if a PSC LSP will carry LSP which in turn carry very high capacity pseudowires using the pseudowire flow label (see [I-D.ietf-pwe3-fat-pw]), the flow label is four labels deep. In this case, LSP Min Depth should be configured at four or higher. For example, if the same PSC LSP will carry LSP which carry IP traffic with no additional labels, then the IP header is two labels deep. In this case, LSP IP Depth should be configured at two or higher. For an LSP with LSP Min Depth configured, all links with Max Depth set to a value below LSP Min Depth MUST be excluded from the LSP Path Computation. For an LSP with LSP IP Depth configured, all links with IP Depth set to a value below LSP IP Depth MUST be excluded from the LSP Path Computation. 4. Backwards Compatibility Networks today use three forms of multipath. 1. IP ECMP, including IP ECMP at LER using more than one LSP. 2. Ethernet Link Aggregation [IEEE-802.1AX]. 3. MPLS Link Bundling [RFC4201]. 4.1. Legacy Multipath Behavior IP ECMP and Ethernet Link Aggregation always distribute traffic over the entire multipath either using information in the MPLS label stack, or using information in a potential IP header, or using both types of information. One of two behaviors is assumed for link bundles. Either the link bundles place each LSP in its entirety on a single link bundle component link for all LSP, or link bundles distribute traffic over the entire link bundle using the same techniques used for ECMP and Villamizar Expires August 30, 2012 [Page 20] Internet-Draft MPLS TE Multipath February 2012 Ethernet Link Aggregation. This second behavior is known as the "all ones" component link (see [RFC4201]). 4.2. Networks without Multipath Extensions Networks exist that are comprised entirely of LSR which do not support these multipath extensions. In these networks there is no way of telling how multipath links will behave. Since an Ethernet Link Aggregation Goup (LAG) is advertised as an ordinary link, there is no way to tell that it is a form of multipath. 4.2.1. Netowrks with MP Capability on all Multipath Most large core network today rely heavily on the use of multipath. Ethernet Link Aggregation and configure LSR to use the "all ones" component link for all LSP. The "all ones" component link is the default for many Link Bundling implementations used in core networks. This is equivalent to the following setting in the Multipath Node Capabilities sub-TLV or Multipath Link Capabilities sub-TLV. Clear the Ordered Aggregate Enabled bit, set the Multipath Enabled bit, set the Default to Multipath bit, and clearing the Variable Depth Multipath bit. If the label stack is used in the multipath traffic distribution, set Max Depth to the number of label stack entries supported, otherwise set it to one. If an IP packet under the label stack can be used in the multipath traffic distribution, set IPv4 Enabled Multipath, set IPv6 Enabled Multipath, set Default to IP/MPLS Multipath, and set IP Depth to the maximum number of label stack entries which can be skipped over before finding the IP stack. Otherwise clear IPv4 Enabled Multipath, clear IPv6 Enabled Multipath and clear Default to IP/ MPLS Multipath. These networks can support very large LSP but cannot support LSP which require strict packet ordering with other labels below such an LSP, such as pseudowire labels. They may also misroute OAM packet which use GAL (see [RFC5586]). Generally the Link Bundle advertisements indicate a "Maximum LSP Bandwidth" that is equal to the "Unreserved Bandwidth". Villamizar Expires August 30, 2012 [Page 21] Internet-Draft MPLS TE Multipath February 2012 4.2.2. Netowrks with OA Capability on all Multipath Some networks, particularly edge networks which tend to be lower capacity, do not use Link Aggregation, and if they use Link Bundling at all, configure each LSR to place each LSP in its entirety on a single link bundle component link for all LSP. Some edge equipment only supports this link bundle behavior. This is equivalent to the following setting in the Multipath Node Capabilities sub-TLV or Multipath Link Capabilities sub-TLV. Clear the Ordered Aggregate Enabled bit, Clear the Multipath Enabled bit. All remaining bits in the Flags field should be clear. The Min Depth, Max Depth, and IP Depth should be set to zero. These networks can support LSP which require strict packet ordering, but cannot support very large LSP. 4.2.3. Legacy Netowrks with Mixed MP and OA Links Some network may support Ethernet Link Aggregation and all or a subset of LSR which place each LSP in its entirety on a single link bundle component link for all LSP. If the "Maximum LSP Bandwidth" is set as described in Section 4.2.1, then very large LSP can be supported. Very large LSP cannot be supported on LSR which place each LSP in its entirety on a single link bundle component link for all LSP, but these are clearly indicated in signaling, In these mixed networks it is not possible to reliably support LSP which require strict packet ordering. It is not possible to know where Ethernet Link Aggregation is used and it is not possible to accurately determine Link Bundling behavior on link bundles where "Maximum LSP Bandwidth" is equal to "Unreserved Bandwidth". 4.3. Transition to Multipath Extension Support If a Multipath Node Capability sub-TLV is not advertised (see Section 2.1), then the LSR does not support these multipath extensions, or is not adjacent to any multipath. This allows detection of such nodes and if necessary application of defaults to cover Ethernet Link Aggregation Behavior. Villamizar Expires August 30, 2012 [Page 22] Internet-Draft MPLS TE Multipath February 2012 4.3.1. Simple Transitions For networks with LSR that do not support for multipath extensions, transition is easiest if all legacy LSR support and are configured with a common link bundling behavior. If Ethernet Link Aggregation is not used, a single configured default is needed to cover LSR that do not advertise a Multipath Node Capability sub-TLV. If Ethernet Link Aggregation had been previously used on Legacy LSR, if possible LAG should be disabled and the members of the former LAG configured and advertised as a link bundle which uses the equivalent "all ones" behavior. The transition network in this case lacks the ability to determine the largest microflow that can pass through legacy nodes, but this was the case prior to transition for the entire network prior to transition. 4.3.2. More Challenging Transitions Transition is made more difficult if legacy LSR in a network support Ethernet Link Aggregation but do not support Link Bundle. This situation is most easily handled if a small upgrade to such an LSR can advertise a fixed Multipath Node Capability sub-TLV giving the characteristics of the Ethernet Link Aggregation on implementation on that node. Absent of such cooperation, the problem can be solved by configuration on newer LSR which allows association of a Multipath Node Capability sub-TLV with a specific legacy router ID and possibly a legacy router ID and link. LSR supporting Multipath Extensions assign default values assigned by configuration to these legacy LSR running Ethernet Link Aggregation. These default values serve to allow LSP which require strict packet ordering to avoid these legacy LSR. LSR which do not support [RFC4201] may be sufficiently rare that the ability to assign default values per legacy LSR may not be needed in practice. 5. IANA Considerations [ ... to be completed ... ] The symbolic constants IANA-TBD-1 through IANA-TBD-4 need to be replaced. Complete instructions, including identification of the number space for each of these will be added to a later version of this internet-draft. Villamizar Expires August 30, 2012 [Page 23] Internet-Draft MPLS TE Multipath February 2012 6. Security Considerations The combination of MPLS, MPLS-TP, and multipath does not introduce any new security threats. The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework]. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-mpls-tp-security-framework] Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Security Framework", draft-ietf-mpls-tp-security-framework-01 (work in progress), May 2011. [I-D.ietf-pwe3-fat-pw] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network", draft-ietf-pwe3-fat-pw-06 (work in progress), May 2011. [I-D.villamizar-mpls-tp-multipath] Villamizar, C., "Use of Multipath with MPLS-TP and MPLS", draft-villamizar-mpls-tp-multipath-01 (work in progress), March 2011. [IEEE-802.1AX] IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", 2006, . [ITU-T.G.800] ITU-T, "Unified functional architecture of transport networks", 2007, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Villamizar Expires August 30, 2012 [Page 24] Internet-Draft MPLS TE Multipath February 2012 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, March 2010. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011. Villamizar Expires August 30, 2012 [Page 25] Internet-Draft MPLS TE Multipath February 2012 Author's Address Curtis Villamizar (editor) Outer Cape Cod Network Consulting Email: curtis@occnc.com Villamizar Expires August 30, 2012 [Page 26]