tewg/mpls S.Wright Internet Draft BellSouth Document: draft-wright-mpls-te-policy-00.txt F.Reichmeyer Category: Informational IP Highway R.Jaeger LTS, U. of Maryland M.Gibson Nortel June, 2000 Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document considers the application of policy based traffic engineering techniques to load-balancing in MPLS networks. The objective is not to mandate a specific policy, but to (a) provide an example of a policy based approach to a traffic engineering problem and (b) elucidate a range of potential policies related to load balancing as a traffic engineering objective as guidance for the development of a Policy Information Base (PIB) for MPLS networks. 2. Conventions used in this document 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 [2]. 3. Introduction Wright Informational - Expires December 2000 1 Policy-Based Load-Balancing in TE MPLS Networks June 2000 Traffic Engineering within IP networks is a broad subject outlined within the traffic engineering framework document [3]. This draft takes a considerably narrower approach in considering just one aspect of traffic engineering in order to scope the work. RFC 2702 [4] section 3.2 identifies three fundamental problems in traffic engineering over MPLS networks - mapping traffic to Forwarding Equivalence Classes (FECs), mapping FEC's to label Switched Paths (LSPs), and mapping LSPs to physical topology. This draft seeks to address aspects of the first two objectives only. Specifically, this draft focuses on: a) MPLS as an interesting subset of IP protocols b) load balancing as a traffic engineering objective c) Policy based approaches for describing the objectives and constraints of the traffic engineering optimization. The MPLS architecture draft identifies load balancing as a potential application of MPLS. The load balancing problem in MPLS networks concerns the allocation of traffic between two or more LSPs which all have the same origin and destination. The notion of policy-based MPLS networks is introduced in [5] and expanded in [6], in conformance with the generic policy work from the policy working group (see e.g.[7]) and the COPS material from the rap working group (see e.g. [8]). 3.1 Terminology Load Balancing vs Link Bundling In some cases a pair of LSRs may be connected by several (parallel) links. From the MPLS Traffic Engineering point of view, for the purpose of scalability, it may be desirable to treat all these links as a single IP link - an operation known as Link Bundling ( ref. [9]). With load balancing, the load to be balanced is spread across multiple LSPs that in general does not require physical topology adjacency for the LSRs. The techniques are complementary. Link bundling provides a local optimization that is particularly suited for aggregating low speed links. Load Balancing is targeted at larger scale network optimizations. While load balancing is perhaps commonly thought of as applying between edge LSRs, it could be applied at ANY LSR that provides the requisite multiple LSP tunnels with common endpoints. The Policy Enforcement Point is the LSR at the source end of the set of LSPs with common endpoints. The arriving traffic to be load balanced may be from non-MPLS interfaces or MPLS interfaces. In general, the source end of an LSP may act as a merge point for multiple input streams of traffic. 3.2. Assumptions / Scope Wright Informational - Expires December 2000 2 Policy-Based Load-Balancing in TE MPLS Networks June 2000 This document considers only policies related to load balancing objectives. While policy based approaches may be applicable to other traffic engineering objectives, the focus here is on load balancing. The set of LSPs over which the load is to be balanced is pre-defined and the relevant load balancing policies are then applied to these LSPs. Extension of this work to support the creation or deletion of LSPs in response to policies with load balancing objectives is for further study. This version of the document is primarily focused on MPLS networks without quantitative guarantees on LSP performance in order to reduce the effort involved. Future versions of the document may include increased support for the various QoS notions supported in MPLS networks. By removing the QoS elements from the discussion at this stage, we can concentrate on getting the fundamental operation correct, without debating the details of QoS or admission control algorithms. By not considering the QoS notions of MPLS, we simplify the policy and functions associated with load balancing. Since only best effort LSPs are considered, we simplify the admission control considerations in the load balancing process. If the LSPs were established with QoS constraints, it would be necessary to determine if the traffic flow sent over the LSP as a result of load balancing fit the profile of the constraints. This adds complexity to the load balancing policy as well as the processing of the LSR performing the load balancing. While load balancing on a best effort network can be viewed as a simple case, the basic methodologies have a wider applicability when applied to QoS-based LSP selection. Indeed the load balancing case for best effort only traffic has similar problems to that of load balancing a particular traffic class such as that with a particular DiffServ PHB. Bandwidth sharing among classes of service raises some more complex issues that also apply to the placement of traffic into ER-LSPs. As the available capacity for a particular traffic class to a particular destination exceeds the capacity of the (ER- )LSP for that traffic, some action must be taken to get more bandwidth or control access to the LSP. The PEP will have to perform some per traffic class action with the likely result that the best effort traffic on the network will become squeezed in favor of higher priority traffic. The lending of bandwidth between LSPs is a policy issue that must be addressed. The location of the network congestion will have a bearing on a solution. A policy server can initiate a new LSP and map certain flows to this to avoid the congestion point, thereby improving the performance of those flows and reducing the congestion problem. This would, however, require a congestion detection methodology and inter-PDP communication 4. Policy-based Traffic Engineering Wright Informational - Expires December 2000 3 Policy-Based Load-Balancing in TE MPLS Networks June 2000 A policy provides a rule of the form: IF <condition> THEN <action> Policy based networking is one of a number of mechanisms that could be used in achieving traffic engineering objectives. While traffic engineering may be considered an optimization problem, policy approaches provide considerable flexibility in the specification of the network optimization objectives and constraints. 4.1 Policy-based Traffic Engineering in the Context of the Traffic Engineering Framework Within the TE framework's taxonomy of traffic engineering systems, policies may be : dependent on time or network state ( either local or global state) based on algorithms executed offline or online stored centrally ( e.g. in a directory) or distributed to an engineerable number of policy decision points prescriptive or descriptive designed for open loop or closed loop network control We assume network feedback to be an important part of policy-based networking. While network configuration (provisioning) can be performed in an open-loop manner, in general, policy-based networking should imply a closed-loop mechanism. The distribution and performance of the policy system itself is beyond the scope of this draft - we assume that adequate resources can be provisioned to meet the required policy update frequency etc. The traffic engineering framework identifies process model components for : measurement Modeling, analysis and simulation optimization. Policies may be used to identify relevant measurements available through the network and trigger appropriate actions. The available traffic metrics for determining the policy trigger conditions are constrained e.g. by generic IP traffic metrics (see e.g. RFC 2679 [10] or RFC 2722 [11]). Policies provide an abstraction of network resources - a model that can be designed to achieve traffic engineering objectives. Policies can provide a degree of analysis by identifying network problem through correlation of various measurements of network state. A policy based network is not, however, a network simulation. A set of policies can be designed to achieve an optimization of network performance through appropriate network provisioning actions. Wright Informational - Expires December 2000 4 Policy-Based Load-Balancing in TE MPLS Networks June 2000 4.2 Policy Based Load Balancing Load Balancing, as a traffic engineering objective, is not described in great detail within the TE framework draft. There is some mention of it as an example of a relatively "simple" and "fast" computation that may be suitable for online traffic engineering in section 5.2.It is also identified as a traffic engineering objective within section 6.6 on content distribution (webserver) requirements. In general though, load balancing would seem to fit within section 6.3 of the TE framework draft as an example of traffic mapping. The relative simplicity of load balancing algorithms is what makes them attractive for the purposes of this draft in illustrating policy approaches to traffic engineering in the context of MPLS networks. While load balancing optimizations have been proposed for various routing protocols, such approaches complicate existing routing protocols and tend to optimize towards a fairly limited set of load balancing objectives. Extending these towards more flexible / dynamic load balancing objectives seems overly complicated. Hence this draft takes the approach of building on the policy-based networking architecture which provides mechanisms specifically designed to support flexible and dynamic administration. 5. Policy-Based MPLS Network Context for Load Balancing Figure 1 illustrates a generic policy based network architecture in the context of an MPLS network. In this example, we have two LSPs established : LSP #1 that follows the path(abd) LSP #2 that follows the path(acd). In this draft we do not consider the problems of establishing the LSPs. We assume that a variety of mechanisms may be used for either manual(e.g. LSPs provision explicit routes) or automated (e.g. LSPs based on topology driven or data driven shortest path routes) establishment of the LSPs. Future versions of this or another draft may address the issue of establishing LSPs via policy mechanisms (e.g. using COPS push. The load balancing operation is performed at the LSR containing the ingress of the LSPs to be load balanced. This LSR ((a) in Figure 1) is acting as the Policy Enforcement Point for load-balancing policies related to these LSPs. In this context the load-balancing problem concerns the selection of suitable policies to control the admission of flows to both LSPs. The admission decision for an LSP is reflected in the placement of that LSP as the Next Hop Forwarding Label Entry (NHFLE) within the appropriate routing tables within the LSR. Normally, there is only one NHLFE corresponding to each FEC, however there are some circumstances where multiple NHLFEs may exist for an FEC. Wright Informational - Expires December 2000 5 Policy-Based Load-Balancing in TE MPLS Networks June 2000 The conditions for the policies applying to the set of LSPs to be load balanced should be consistent. For example, if the condition used to allocate flows between LSPs is the source address range, then the set of policies applied to the set of LSPs should account for the disposition of the entire source address range. ++++++++++++++ + Policy + + Management + + Tool + ++++++++++++++ |\ |\ | | | | (E.g., JAVA, LDAP) | ++++++++++++++ | + Policy + | + Repository + | + + | ++++++++++++++ | |\ | | | | (e.g. LDAP) ++++++++++++++ + Policy + + Decision + + Point + ++++++++++++++ / / | \ / / | +-------+ / / | \ (e.g. COPS, SNMP) +++++++++++++++ | ++++++++++++++ +++++++++++++++ + ELSR(a) +----+ LSR (b) +---+ ELSR (d) + +++++++++++++++ | ++++++++++++++ +++++++++++++++ \ | / \ +--\ / \ ++++++++++++++ / \-+ LSR (c) +--/ ++++++++++++++ Figure 1 LSR as PEP For policy-based MPLS networks, traffic engineering policies would also be able to utilize for both conditions and actions the parameters available in the standard MPLS MIBs i.e. MPLS Traffic Engineering MIB [12], MPLS LSR MIB [13] MPLS Packet Classifier MIB [14] MIB elements for additional traffic metrics are for further study beyond the scope of this internet draft. Wright Informational - Expires December 2000 6 Policy-Based Load-Balancing in TE MPLS Networks June 2000 5.1 Load Balancing at Edge of MPLS Domain Flows admitted to an LSP at the edge of an MPLS domain are described by the set of Forwarding Equivalence Classes (FECs) that are mapped to the LSPs in the FEC to NHLFE (FTN) table. The load-balancing operation may be considered as redefining the FECs to send traffic along the appropriate path. Rather than sending all the traffic along a single LSP, the load balancing policy operation results in the creation of new FECs which effectively partition the traffic flow among the LSPs in order to achieve some load balance objective. Consider as an example, two simple point-to-point LSPs, (a) and (b), with the same source and destination, over which we are to load balance some aggregate FEC (z). The aggregate FEC (z) is the union of FEC (a) and FEC (b). The load balancing policy may adjust the FEC (a) and FEC (b) definitions such that the aggregate FEC (z) is preserved. 5.2 Load Balancing at interior of MPLS Domain Flows admitted to an LSP at the interior of an MPLS domain are described by the set of labels that are mapped to the LSPs in the Incoming label Map (ILM). A Point-to-Point LSP that simply transits an LSR at the interior of an MPLS domain does not have an LSP ingress at this transit LSR. Merge points of a Multipoint-to-Point LSP may be considered as ingress points for the next link of the LSP. A label stacking operation may be considered as an ingress point to a new LSP. The above conditions, which put multiple LSPs onto different LSPs, may require balancing at the interior node. The FEC of an incoming flow may be inferred from its label. Hence load-balancing policies may operate based on incoming labels to segregate traffic rather than requiring the ability to walk up the incoming label stack to the packet header in order to reclassify the packet. The result is a coarse load balancing of LSPs (not flows) onto one of a number of LSPs from the LSR to the egress LSR 5.3 Load Balancing with multiple NHLFEs The MPLS Architecture identifies that the NHLFE may have multiple entries for one FEC. Load balancing is suggested as an example rationale for this, but it is not the only interpretation of multiple NHLFE entries. Other interpretations may exist and the Wright Informational - Expires December 2000 7 Policy-Based Load-Balancing in TE MPLS Networks June 2000 potential interaction with load balancing should be considered. Multiple NHLFEs may be present to represent: (a) the Incoming FEC / label set is to be multicast (b) when route selection based on the EXP field in addition to the label is required. If both multicast and load balancing functions are required, it is necessary to disambiguate the scope of the operations. The way we have defined the load balancing operation, it partitions a set of input traffic (defined as FECs or Labels) across a set of output LSPs. One (or more) of the arriving FECs may be multicast to both the set of load balanced LSPs as well as other LSPs. This would imply that the packet replication (multicast) function occurs before the load balancing. When the route selection is based on the EXP field, this appears to simply be a special case of the policy based load-balancing approach. It is suggested replicating NHLFEs for this purpose be deprecated and the more generic policy based approach be used to specify an FEC/ label space partition based on the EXP field. In this draft, we take the perspective that the load balancing function is more properly considered as part of the classification function. This allows us to preserve a mapping of an FEC into one NHLFE for unicast. While classification of incoming flows into FECs is commonly thought of as an operation on some tuple of packet headers, this is not the only basis for classification - router state can also be used. For example, the source port of a flow may be a useful basis on which to discriminate flows. Equally, a "random number" generated within the router may be attractive as the basis for allocating flows for a load balancing objective. Some algorithm within the router, which may include some hash function on the packet headers, may generate the "random number". 6. MPLS Policies for Load Balancing MPLS load balancing partitions an incoming stream of traffic across multiple LSPs. The load balancing policy, as well as the ingress LSR where the policy is enforced, must be able to distinctly identify LSPs. We do not, in this draft, address the issue of how LSPs are established. It is assumed, however, that the PDP that installs the load balancing policy, has knowledge of the existing LSPs and is able to identify them in policy rules. One way to achieve this is through the binding of a label to an LSP. An example MPLS load-balancing policy may state, for the simple case of balancing across two LSPs, ôIf traffic matches classifier æCÆ, then forward on LSP æL1Æ, else forward on LSP æL2Æö. Classification can be done on a number of parameters, such as packet header fields, incoming labels, etc. The classification conditions of an MPLS load- balancing policy are thus effectively constrained to be able to Wright Informational - Expires December 2000 8 Policy-Based Load-Balancing in TE MPLS Networks June 2000 specify the FEC in terms that can be resolved into MPLS packet classification MIB parameters. Forwarding traffic on an LSP can be achieved by tagging the traffic with the appropriate label corresponding to the LSP. MPLS load- balancing policy actions typically result in the definition of a new aggregate FEC to be forwarded down a specific LSP. This would typically be achieved by appropriate provisioning of the FEC and routing tables (FTN and ILM). The basis for partitioning the traffic can be static or dynamic. Dynamic load balancing can be based on a dynamic administrative control (e.g. Time of Day), or it can form a closed control loop with some measured network parameter. Static Partitioning of the Load can be based on information carried within the packet header (e.g. source / destination addresses, Source / destination port numbers, packet size, protocol ID etc.). Static partitioning can also be based on other information available at the LSR (e.g. the arriving physical interface). However if load partition is truly static, or at least very slowly changing (say < 1 change / day ?) then the need for a policy based control of this provisioning information maybe debatable and a direct manipulation of the LSR MIB may suffice. A control-loop based load-balancing scheme seeks to balance the load close to some objective, subject to error in the measurements and delays in the feedback loop etc. The objective may be based on a fraction of the input traffic to be sent down a link (e.g. 20% down LSP (abd) and 80% down LSP (acd)) in which case some measurement of the input traffic is required. The objective may also be based on avoiding congestive loss in which case some loss metric is required. The metrics required for control loop load balancing may be derived from information available locally at the upstream LSR, or may be triggered by events distributed elsewhere in the network. In the latter case, the metrics must be delivered to the Policy Decision Point. Obviously, locally derived trigger conditions would be expected to avoid the propagation delays etc. associated with the general distributed case. Frequent notification of the state of these metrics increases network traffic which may be undesirable. This draft does not seek to provide guidance on the appropriate rate of notification for metric updates. Consider the case of a single large flow that must be load balanced across a set of links. In this case policies based solely on the packet headers may be inadequate and some other approach (e.g. based on a random number generated within the router) may be required. Note that sequence integrity of the aggregate FEC forwarded over a set of load balancing LSPs may not be preserved under such a regime. Wright Informational - Expires December 2000 9 Policy-Based Load-Balancing in TE MPLS Networks June 2000 7. Security Considerations The policy system and the MPLS system both have their inherent security issues, which this document does not attempt to resolve. The Policy system provides a mechanism to configure the LSPs within LSRs. Any thing that can be configured can also be incorrectly configured with potentially disastrous results. The policy system can help to secure the MPLS system by providing appropriate controls on the LSP life cycle. Conversely, if the security of the Policy system is compromised, then this may impact any MPLS systems controlled by that policy system. Use of the COPS protocol within the policy system between the PEP/PDP allows the use of message level security for authentication, replay protection and message integrity. Existing protocols such as IPSEC or TLS can also be used to authenticate and secure the channel. The COPS protocol also provides a reliable transport mechanism with a session keep-alive. The MPLS network is not expected to impact the security of the Policy system. Further security considerations of Policy-Enabled MPLS networks is for further study. 8. Conclusions / Further Work Policy-based networking approaches provide a flexible mechanism that can be utilized to support certain traffic engineering objectives. In this draft we have illustrated the potential role for traffic engineering policy approaches to load balancing in MPLS networks. In future drafts we expect to extend this work to cover more sophisticated notions of QoS in addition to "best effort" MPLS services, and into MPLS PIB proposals. The authors of this draft believe that portions of this material should be incorporated into working group drafts within the scope of the tewg, mpls and possibly other working groups. 9. References [1] Bradner,S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner,S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wright Informational - Expires December 2000 10 Policy-Based Load-Balancing in TE MPLS Networks June 2000 [3] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., Xiao, X., "A Framework for Internet Traffic Engineering", work-in-progress, draft-ietf-tewg-framewrk-01.txt, May 2000. [4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J., "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999. [5] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", work-in-progress, draft-ietf-mpls-arch- 06.txt, August 1999. [6] Wright,S., Herzog,S., Reichmeyer,F., Jaeger,R., "Requirements for Policy Enabled MPLS", work-in-progress, draft-wright-policy- mpls-00.txt, March 2000. [7] Moore, B., Elleson, E., Strassner, J., "Policy Framework Core Information Model -- Version 1 Specification" work-in-progress, draft-ietf-policy-core-info-model-06.txt [8] Yavatkar, R., Pendarakis, D., Guerin, R., " A Framework for Policy-based Admission Control" RFC2753, January 2000. [9] Kompella, K., Rekhter, Y., " Link Bundling in MPLS Traffic Engineering", work-in-progress, draft-kompella-mpls-bundle- 00.txt, February 2000. [10] Almes, G., Kalidindi, Zekauskas, M., "A One-way Delay Metric for IPPM", RFC 2769, September 1999. [11] Brownlee, N., Mills, C., Ruth, G., "Traffic Flow Measurement: Architecture", RFC 2722, October 1999. [12] Srinivasan, C., Viswanathan, A., Nadeau, T., "MPLS Traffic Engineering Management Information Base Using SMIv2", work-in- progress, draft-ietf-mpls-te-mib-03.txt, March 2000. [13] Srinivasan, C., Viswanathan,A., Nadeau,T.,"MPLS Label Switch Router Management Information Base Using SMIv2", work-in- progress, draft-ietf-mpls-lsr-mib-04.txt, April 2000. [14] Nadeau,T., Srinivasan, C., Viswanathan,A., "Multiprotocol label Switching Packet Classification Management Information Base Using SMIv2", work-in-progress, draft-nadeau-mpls-packet-classifier- mib-00.txt, March 2000. 10. Acknowledgments Indra Widjaja provided several comments on an earlier draft. Wright Informational - Expires December 2000 11 Policy-Based Load-Balancing in TE MPLS Networks June 2000 11. Author's Addresses Steven Wright Science & Technology BellSouth Telecommunications 41G70 BSC 675 West Peachtree St. NE. Atlanta, GA 30375 Phone +1 (404) 332-2194 Email: steven.wright@snt.bellsouth.com Francis Reichmeyer IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone +1 (201) 655-8714 Email: franr@iphighway.com Robert Jaeger Laboratory for Telecommunications Science, 2800 Powder Mill Road, Bldg 601, Room 131 Adelphi, MD 20783 Phone +1 (301) 688-1420 Email: rob@lts.ncsc.mil Mark Gibson Nortel Networks Harlow laboratories, London Rd., Harlow, Essex UK CM17 9NA Phone: +44(0)1279 402621 Email: mrg@nortelnetworks.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Wright Informational - Expires December 2000 12 Policy-Based Load-Balancing in TE MPLS Networks June 2000 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FORA PARTICULAR PURPOSE Wright Informational - Expires December 2000 13