IETF Internet Draft Jim Boyle, PDNETS Expires: December, 2003 Document: draft-boyle-tewg-interarea-reqts-00.txt June 2003 Requirements for support of Inter-Area and Inter-AS MPLS Traffic Engineering Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract: Traffic engineering using MPLS within a single IGP area has become quite prevalent in networks today. This gives a network operator several advantages, including better traffic measurement capabilities, faster restoration times, and of course the ability to better manage congestion points within their network. However, the current uses have been limited to one IGP area. OSPF based networks usually do traffic engineering only in their backbone area, and many ISIS networks still operate at a single level. It would be useful to be able to extend these capabilities across hierarchical areas within a single IGP, as well as to be able to extend across AS boundaries if it is so-found to be useful and possible. This document first breaks down some of the current applications of MPLS TE, and then it addresses how these might be used (or precluded) across IGP areas or AS boundaries. Please direct comments on this document to te-wg@ops.ietf.org Boyle 1 Requirements for Inter-Area TE June 2003 Table of Contents 1.... Current uses of MPLS TE 1.1.. Fundamental TE functionalities 1.1.1 MPLS LSPs used for Tunneling 1.2.. MPLS TE and routing 1.3.. Intra-area Protection 1.4.. Diffserv and TE 2.... General Requirements 3.... Inter-area requirements 3.1.. Inter-Area Path Selection 3.2.. Inter-area MPLS TE and routing 3.3.. Inter-area MPLS TE and Protection 3.4.. Diffserv and Inter-area MPLS TE 4.... Inter-domain 4.1.. Inter-AS Path Selection 4.2.. Inter-AS TE and routing 4.3.. Inter-area MPLS TE and Protection 5.... Security Considerations 6.... References 7.... Author's Address 1. Current uses of MPLS TE 1.1 Fundamental TE functionalities There are a number of primitives that are specified [RSVP-LSP] [RSVP-OSPF] and useful in MPLS TE. They are itemized here and revisited when discussing how they might be needed or useful for inter-area and inter-as MPLS TE. a) bandwidth specification - allows the sender to specify how much bandwidth is required for an MPLS LSP. b) priorities - allows prioritization of access to link bandwidth. c) ERO - This allows the source to specify the route an LSP should take. The specification is often a strict route determined by the source during path selection, however the protocol allows for loose hops that an LSP should be routed toward hop-by-hop. Hops today are usually IPv4 or IPv6 addresses, however the specification also allows for AS hops. d) RRO - A sender can request that the route an LSP takes is confirmed during the reservation process by inserting a record route object. The semantics of this are the same as the ERO. e) protection requested - Different protection techniques are possible, and are the ability to use these is controlled by the source of the LSP [PROTECTION]. Boyle 2 Requirements for Inter-Area TE June 2003 f) resource affinities - Links can be assigned to administrative groups and these can be taken into account when selection of a path. The administrative constraints of an LSP are also signaled in the session object of the LSP. Also, different reservation styles can be used, including shared-explicit which allows for make-before-break functionality during bandwidth and path changes on an LSP. The source is able to specify that shared-explicit is requested in the session object of the LSP. The fact that all traffic for the LSP is consolidated into one tunnel makes measurement of macroscopic flows much easier than with traditional IP routing. This is also something that most network operators like when using MPLS TE. 1.1.1 MPLS LSPs used for Tunneling In addition to the carriage of plain, globally routable IPv4 traffic, MPLS is often used to carry VPN traffic between ports of a network. This may be a customer's IPv4, ATM, Frame Relay or Ethernet. The two endpoints agree on what is in the tunnel via configuration or additional signaling [RFC2547][MARTINI]. This is one of the strongest drivers today for new deployments of MPLS. It is also one of the strongest drivers for the need to push MPLS TE across area and AS boundaries. 1.2 MPLS TE and routing At it's simplest, MPLS TE allows for the connection between two routers and the tunneling of traffic between them. This might be done for the purposes of measurement, carriage of VPN traffic, or to provide a quicker restoration of traffic flow during different failure scenarios. In this mode, the only traffic introduced onto the tunnel is traffic for the destination. For instance, in the following topology if there is an LSP from M1-to-N2, only traffic going through M1 with N2 as its final destination would end up on the LSP. M3--M1--------------N1 \/ | / \ /\ | / \ M4--M2----------N2-----N3 Alternate approaches modify the IGPs shortest path selection algorithm. In this case, if the IGPs shortest paths from M1 are as follows: M3--M1--------------N1 / | \ / | \ M4 M2----------N2 N3 Boyle 3 Requirements for Inter-Area TE June 2003 Then an LSP from M1-to-N2 might create a shortcut such that the path M1-to-N2 plus the cost of the link from N2 to N3 might be better than M1-N1-N3 path, so traffic hitting M1 and going to N3 would end up the LSP M1-to-N2. Another implementation would only use the LSP for IGP destinations that naturally fall beyond the LSP destination on the shortest path tree. In the above example, M1-to-N2 would not be used for N3, however an LSP from M1-to-N1 would include traffic to N3. Another common approach is to treat these LSPs as forwarding adjacencies which are included in the LSP source's IGP advertisement [FA-LSP]. In this case, traffic from other nodes can be drawn toward a node with an LSP. For example, if the IGP shortest path tree from M4's perspective is the following: M3--M1--------------N1 / / M4--M2----------N2-----N3 If the LSP M1-to-N2 is advertised back into the IGP with the right cost, this might modify M4's tree to be as follows: M3--M1--------------N1 / \________ / \ M4--M2 N2-----N3 These are all useful ways to incorporate MPLS into routing with intra-area LSPs. In summary, MPLS LSPs are used in intra-area TE in the following ways. 1) When traffic goes through the source and is to the destination of the LSP 2) When traffic goes through the source and is to the destination of the LSP or somewhere beyond this destination on from an IGP SPF perspective. 3) The LSPs is introduced into the IGP to become part of the path consideration for all nodes with visibility into the advertisement. 1.3 Intra-area Protection MPLS allows for a variety of approaches to speed up traffic restoration when there is a failure within a network (especially link-based failures). Common approaches include having two LSPs (a working and protect) on separate paths, as well as using MPLS signaling to setup more advanced protection schemes. [PROTECTION] Boyle 4 Requirements for Inter-Area TE June 2003 outlines that LSPs may be protected in several approaches. For each LSP, a detour LSP may be routed toward the destination but avoiding the next node (and link). These detours may merge back into the main LSP. Alternatively, an LSP can be established for a given link and if there is a failure of that link, all LSPs that were active on the failed link are switched into the backup LSP. These are both useful approaches that have found use in today's MPLS networks. 1.4 Diffserv and TE The MPLS label allows for a CoS value to be used within the "Exp" bits, and this can be used to affect the proper queuing for the packet. This is termed a label-inferred diffserv LSP (L-LSP) in [DIFFSERV-LSP]. An explicit object can also be used to specify the diffserv class of traffic that the LSP is limited to, and that can be used to treat the LSP accordingly. Other approaches are being developed to allow more intimacy with diffserv and route selection, this is termed Diffserv TE, and is specified in [DIFF-TE]. One thing to note about Diffserv TE, besides its pre-emergent state at this time, is that many of the semantics are abstract and inferred by configuration. For instance, Class-Type 0, 1 and 2 are often correlated to Best Effort, Assured Forwarding and Expedited Forwarding, however that is only from convention and the protocol allows much more flexibility to achieve the requirements of the network operator. 2. General Requirements As outlined in section 1, there are many uses of MPLS TE today, though it is mostly constrained to a single IGP area. Some of the information available in the routing domain of a single area is so condensed when an AS or area boundary is crossed that some of the functionality could be sharply curtailed. It might still be useful however, especially for transporting of VPN traffic from edge to edge of a network (for inter-area), or to another network (for inter-as within one provider) or even to another provider (truly inter-as). Other current TE uses may be more difficult to achieve inter-area and inter-as due to the lack of ability to integrate an MPLS LSP into an inter-area or inter-as routing scheme (outside of tunneling of traffic from source to destination). For instance, interconnection of a hosting center to a significant peering router in another area may be useful for traffic quantification, explicit route usage, or interaction with EBGP purposes. It might be possible to achieve limited results and this document attempts to specify some constraints that might be useful guidelines. There are several reasons that network operators choose to break up their network into different areas (or even multiple AS). These often include scalability and containment of routing information. Boyle 5 Requirements for Inter-Area TE June 2003 The latter can help isolate most of a network from receiving and processing updates that are of no consequence to its routing decisions. In fact, whole routers can be taken down in an area without any router outside of that area being aware. These general qualities should not be overly adapted to allow inter-area or inter-as MPLS TE. In fact, to the extent possible, information propagation for path-selection should continue to be localized for inter-area and inter-as MPLS TE. Additionally, The base specification of MPLS TE can be said to be architecturally structured and relatively devoid of excessive state propagation in terms of routing or signaling. Its strength in extensibility can also be seen as an Achilles heel, as there is really no limit to what is possible with extensions. It is paramount to maintain architectural vision and discretion when adapting it for use for inter-area and inter-as TE. Additional information carried within an area, or propagated outside of an area (via routing or signaling) should neither be excessive, patchwork, nor non-relevant. 3. Inter-area requirements All of the features outlined in section 1 can be assumed to have the same meaning and semantics in different areas of a multi-area IGP. For instance, an affinity of "international" (0x1) in one area can be assumed to be "international" in a different area. Most of the primitives used for intra-area path selection are propagated in the session object of an RSVP LSP. Therefore, all of the functionalities outlined in section 1.1 are possible and necessary for support in inter-area MPLS TE. 3.1 Inter-Area Path Selection Obviously some functions such as a full route selection for an ERO will not be possible across area boundaries (or inter-as boundaries below). For this reason, and since the most necessary primitives for route selection are propagated within an LSPs Path message, an approach of ERO route expansion is suggested as the best approach for inter-area LSP establishment. An alternate approach of propagation of sufficient topology information to make a complete path determination is not recommended due to the additional information required as well as the incongruence of this approach with the overall containment provided by the network hierarchy. The alignment of these is mentioned as a goal in section 2. Boyle 6 Requirements for Inter-Area TE June 2003 Area M| Area 0 | Area N M3--M1--------------N1 \/ | / \ /\ | / \ M4--M2----------N2-----N3 Area M| Area 0 | Area N Figure to be used for later clarification A source should specify a strict ERO to an egress point of its area with the next hop being at a minimum the destination for the LSP. The area border router will expand this ERO to the destination (or it's border router if the destination is more than one area away from the source). When insufficient topology exist at a route expansion at a border router, a Path Error message will be sent to the source, who may attempt to establish the LSP through another border router. Similarly, when the source is more than one area away from the destination, the destination's border router may send back a Path Error. Ideally, the source's border router would try another border router into the destination's area, however with current protocol, the Path Error will propagate to the source. The source now needs to know if it should try again at the border router of the source's area. This is the crux of complexity of inter-area TE LSP establishment A solution is needed which elegantly and efficiently allows for the best pair of border routers to be routed through by the LSP. As these may change over time, there is a need to show how border-router optimization is handled. Additionally, more optimal routes may become available within an area. To the extent possible, optimization of the LSP onto these routes should be possible. The source of the LSP should have some control on the candidacy of an LSP for optimization in a remote area. 3.2 Inter-area MPLS TE and routing Clearly an inter-area LSP can be used to carry traffic that is destined for the destination of the LSP. (item (1) at the end of section 1.2). Much information may also be present which allows other traffic to be included in the LSP. Area border routers propagate information for more than their directly attached interfaces. In OSPF, network summary LSAs are sent throughout the network by ABRs (and external networks are propagated by ASBRs). This information allows the LSP also to be used to reach networks beyond an LSP to a border router or an ASBR (item (2) at the end of section 1.2). Boyle 7 Requirements for Inter-Area TE June 2003 However, it may be difficult to allow the existence of an LSP (or two from source to destination and vice-versa) to attract traffic to an LSP's source. The only way that might work would be to mirror existing network summary and external advertisements. However since these can flood throughout a network, they could have a negative impact on IGP database size. Incorporation of LSPs back into routing across areas is not currently required and is not recommended outside of experimental investigation. (item 3 at the end of section 1.2) 3.3 Inter-area MPLS TE and Protection Facility protection of a single link is necessarily intra-area and not applicable to inter-area discussions. Per-path protection is necessary and can hopefully use the same path establishment mechanisms (along with necessary REROUTE and DETOUR objects) to achieve the same restoration levels as are achieved within an area. 3.4 Diffserv and Inter-area MPLS TE Just as session specific parameters such as affinities are assumed to be consistent within one IGP, the same can be said for diffserv support on an LSP. COS mappings on L-LSPs are expected to be consistent, and E-LSPs are explicitly interpreted by definition. Diffserv TE should be directly translatable at border-routers, as the class-type of an LSP is explicit for class-types greater than 0 and not-existent in the path message for class-type 0. 4. Inter-domain All of the features outlined in section 1 can NOT be assumed to have the same meaning and semantics in different AS of a multi-AS LSP. For instance, an affinity of "international" (0x1) in one AS can NOT be assumed to be "international" in a different AS. Most of the primitives used for intra-area path selection are propagated in the session object of an RSVP LSP, but most of them are not necessarily of any use across AS boundaries. Therefore, it is necessary to be able to mask or over-write the following at AS boundaries: i) priorities ii) resource affinities - Links can be assigned to administrative groups and these can be taken into account when selection of a path. The administrative constraints of an LSP are also signaled in the session object of the LSP. Boyle 8 Requirements for Inter-Area TE June 2003 iii) Diffserv E-LSP and Class-Type object objects may need to be removed. However some of the functionalities outlined in section 1.1 are necessary and useful for support in inter-AS MPLS TE. These especially include bandwidth specified and fast-restoration capabilities. 4.1 Inter-AS Path Selection Inter-AS path selection is analogous to inter-area path selection discussed in section 3.1. It is especially obvious in inter-AS path selection that routing information must be localized and kept in line with AS boundaries, and therefore an approach of sending an ERO which is locally explicit then loose to the destination is also suggested. A twist with inter-AS is that the protocol supports the concept of an AS hop. It might be very useful to constrain the path of an LSP to certain AS. These might be deduced through the BGP path database, or through configuration. However they could be helpful in keeping an LSP from going through an unexpected AS. Other policy mechanisms for keeping an LSP within certain AS should also be discussed. 4.2 Inter-AS TE and routing As in 3.2, it is clear that an inter-AS LSP can be used to route traffic to the destination of the LSP, however this is likely only useful for VPN traffic. It could also be possible to use the LSP for all traffic to this AS, or other AS for which the AS of the destination may be used by the source AS. For instance, if an LSP is sourced in AS65001, and transits AS65002 to a destination in AS65003, the source may use it to get traffic to AS65004 if an AS path of [65001 65003 65004] is valid (and acceptable to AS65003). It is likely that an EBGP session would be required to better control this type of behavior. If an EBGP session is in place, it would be a natural result that the LSP could create paths in BGP of AS that appear adjacent but are connected over an inter-AS LSP tunnel. This could affect routing decisions globally. 4.3 Inter-area MPLS TE and Protection Facility protection of a single link and per-path protection is necessary and can hopefully use the same path establishment mechanisms (along with necessary REROUTE and DETOUR objects) to achieve the same restoration levels as are achieved within an area. Boyle 9 Requirements for Inter-Area TE June 2003 5. Security Considerations None. 6. References [RSVP-LSP] RFC3209 [RSVP-OSPF] draft-katz-yeung-ospf-traffic-10.txt [RFC2547] RFC2547 [MARTINI} draft-martini-l2circuit-trans-mpls-11.txt [DIFFSERV-LSP] RFC3270 [FA-LSP] draft-ietf-mpls-lsp-hierarchy-08.txt [PROTECTION] draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt [DIFF-TE] draft-ietf-tewg-diff-te-proto-04.txt 7. Author's Address Jim Boyle Email: jboyle@pdnets.com Expires: December, 2003