Network Working Group M. Chen Internet-Draft S. Hares Intended status: Informational Huawei Technologies Co., Ltd Expires: January 5, 2015 July 4, 2014 I2RS Traffic Steering Use Case draft-chen-i2rs-ts-use-case-01 Abstract Traffic steering (TS) mechanisms are designed to improve the overall utilization of network resources in terms of bandwidth and services, and to optimize traffic flow in terms of latency and jitter through the network. Most existing TS systems require human intervention to monitor and manage the assignment of specific paths to specific flows or traffic types, reducing the effectiveness of TS. I2RS, as a near real time programmatic interface to the routing system, provides the ability to manage TS systems in a more dynamic and iterative way. This document describes several TS use cases for I2RS. 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]. 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 January 5, 2015. Chen & Hares Expires January 5, 2015 [Page 1] Internet-Draft I2RS TS Use Case July 2014 Copyright Notice Copyright (c) 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. I2RS Requirements from the Traffic Steering Use Cases . . . . 3 3. Domain Exit Traffic Steering . . . . . . . . . . . . . . . . 4 4. End-to-end Traffic Steering . . . . . . . . . . . . . . . . . 5 4.1. MPLS-TE . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Interface to Routing System (I2RS) architecture [I-D.ietf-i2rs-architecture] defines a standard, programmatic interface to routing system. Through the I2RS interface, an entity external to the routing system can retrieve and program network states of the routing system, hence affecting packet forwarding behaviours. Well designed Traffic Steering (TS) can improve the usage of network bandwidth resource, reduce the network congestion and satisfy the requirements (e.g., loss and delay) of the applications. Policy Routing (PR), MPLS Traffic Engineering (MPLS-TE) [RFC3209] are useful tools for traffic steering deployed in the field. Segment Routing (SR) leverages the source routing paradigm for packet forwarding, reducing the per flow state in transit devices to provide a scalable TR solution [I-D.filsfils-rtgwg-segment-routing]. A BGP specific use Chen & Hares Expires January 5, 2015 [Page 2] Internet-Draft I2RS TS Use Case July 2014 case similar to the more general use cases considered here is described in section 3.4 of [I-D.keyupate-i2rs-bgp-usecases]. Most of the existing TS solutions need human intervention because they lack dynamic feedback which would facilitate programmatic adjustments to the policies impacting packet flows. This document describes use cases that leverage the I2RS interface to perform traffic steering dynamically and automatically. 2. I2RS Requirements from the Traffic Steering Use Cases This section contains the list of I2RS requirements found in this draft. Each of these requirements has been given an an ID number of TS-REQ-nn for ease of reference. The requirements from the Traffic Steering use cases described in this document are: TS-REQ01: The I2RS Client-Agent must be able to collect the topology (especially the exit links) and the traffic load of each link; TS-REQ02: The I2RS Client-Agent must be able to read the local rib of each DC/Metro gateway and the policies deployed on each gateway; TS-REQ03: The I2RS Client-Agent must be able to add or delete or modify the relevant rib items and relevant polices to steer the traffic as expected; and adjust traffic placement. TS-REQ-04: The I2RS Client-Agent must have the ability to collect the LSP information either from the PCE or directly from network devices; TS-REQ-05: The I2RS Client-Agent must have the ability to collect the traffic matrix of the network, this is used to help the I2RS client to determine how to adjust the traffic placement; TS-REQ-06: The I2RS Client-Agent must have the ability to read the rib information and relevant policies of each network node; TS-REQ-07:collect the topology and segment information needed to help the I2RS client to compute the end-to-end path; TS-REQ-08:read rib (especially the segment routing rib) information; Chen & Hares Expires January 5, 2015 [Page 3] Internet-Draft I2RS TS Use Case July 2014 TS-REQ-09: add/delete/modify the segment rib, this finally determines how the traffic is forwarded. Note: In each of these sections, the requirements match the technical specificaiton, but maybe listed of ascending numerical order. 3. Domain Exit Traffic Steering Data Center (DC) fabrics and metro area networks often have more than one exit point. By enforcing relevant policies, it is possible to share the outbound traffic load among these exit points, in turn preventing a single link from becoming overloaded, and thus improving the experience of customers using these facilities. The figure below illustrates a typical network design with multiple exits. +---+ +---+ +---+ | A | | B | | C | Interconnect +/--+ +-/-+ +-\-+ / \ /\ / \ ........./...\..../..\..../...\.................. / +-\-+/ \+-/-+ \ | 1 |------| 2 | Edge +-|-+ +-|-+ | | Figure 1: DC Exit Traffic Steering Router 1 and Router 2 represent the border leaf in a DC scenario, or the provider edge in a metro network. Routers A, B and C represent the fabric interconnect in a data center, or the network core in a metro network. Ideally, load would be shared between the outbound link at Router 1 and the outbound link at Router 2; equably if each link has the same capacity, or in proportion to the capacity of each link if they have different capacities. This requires that router 1 and router 2 know the load of each link so Routers A, B, and C, can dynamically steer traffic towards the correct exit point. Normally the load of each of these links is only available to Routers 1 and 2 locally; steering traffic to the correct exit requires manual monitoring and configuration on the part of the network operator. I2RS introduces the concept of a feedback loop; the I2RS client can dynamically learn the utilization of the links at Routers 1 and 2, as well as the state of the routing tables at Routers A, B, and C, the topology of the network, and other information. Based on this information, the I2RS client can compute the changes necessary in the network to evenly balance the load between the two exit points, and inject the right information into the appropriate RIBs to make the necessary changes. Chen & Hares Expires January 5, 2015 [Page 4] Internet-Draft I2RS TS Use Case July 2014 Achieving this requires the I2RS Client-Agent to have the following abilities: o TS-REQ01: be able to collect the topology (especially the exit links) and the traffic load of each link; o TS-REQ02: be able to read the local rib of each DC/Metro gateway and the policies deployed on each gateway; o TS-REQ03: be able add or delete or modify the relevant rib items and polices to steer the traffic as expected. 4. End-to-end Traffic Steering 4.1. MPLS-TE In MPLS-TE, traffic is placed into a Label Switched Path (LSP), guding that traffic through a specific set of nodes and edges to traverse the network. Each LSP represents a (potentially) different path through the network, allowing different streams to take a different path to reach the same destination device. In placing LSPs, the network operator effectively steers traffic through the network. LSP computation and optimization can be performed by Path Computation Element (PCE) [RFC4655], which uses the Path Computation Element Communication Protocol (PCEP) [RFC5440] as a southbound interface. Since the Path Computation Client (PCC) is embedded in the network devices, it can actively request path computation or just receive the path establishment direction from the stateful PCE [I-D.ietf-pce-stateful-pce] and then establish the path. PCE and I2RS architectures contain similar functionalities. In the end-to-end traffic steering scenario, these similar architectures provide complementary functions. Since the PCE is mainly for path computation, traffic placement and steering are out of the scope of PCE, and I2RS can be used in these aspects. In order to support traffic placement and steering, the I2RS (I2RS client-agent exchange) is required to support: o TS-REQ-04: The ability to collect the LSP information either from the PCE or directly from network devices; o TS-REQ-05: The ability to collect the traffic matrix of the network, this is used to help the I2RS client to determine how to adjust the traffic placement; Chen & Hares Expires January 5, 2015 [Page 5] Internet-Draft I2RS TS Use Case July 2014 o TS-REQ-06: The ability to read the rib information and relevant policies of each network node; o TS-REQ-03: The ability to add/delete/modify rib items and relevant policies hence to adjust traffic placement and steer as desired. 4.2. Segment Routing Segment Routing (SR) supports end-to-end traffic steering by directly encoding the path and forwarding instruction information into the packet header, steering packets through an explicit route without per-flow states maintained in the transit nodes. This provides a scalable way to perform Traffic Engineering (TE). In an SR capable network, there are two types of state. One is the segment information that is supplied to the path computation entity for path computation. It can be obtained either from the IGP based Segment advertisement [I-D.psenak-ospf-segment-routing-extensions] [I-D.previdi-isis-segment-routing-extensions], or through the unified BGP interface [draft-chen-idr-segment-distribution]. The other is the SR RIB information that is computed and installed by the path computation entity. The path computation entity can be either the control plane of the ingress node of a path or an external controller (e.g., PCE or SDN controller). Since this is an I2RS use case, this document mainly talks about the latter (Controller based SR). The controller can be an I2RS client or an application running on an I2RS client. In either case, the I2RS interface should have two capabilities. One is to collect the segment information, the other is able to read and write the SR RIB state. To support segment routing, the I2RS (client-agent exchange) is required to support the following abilities: o TS-REQ-07:collect the topology and segment information needed to help the I2RS client to compute the end-to-end path; o TS-REQ-05:collect the network traffic matrix needed to help the I2RS client to compute the optimized path; o TS-REQ-08:read rib (especially the segment routing rib) information; o TS-REQ-09: add/delete/modify the segment rib, this finally determines how the traffic is forwarded. Chen & Hares Expires January 5, 2015 [Page 6] Internet-Draft I2RS TS Use Case July 2014 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations This document does not introduce new security issues. 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.filsfils-rtgwg-segment-routing] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", draft-filsfils-rtgwg- segment-routing-01 (work in progress), October 2013. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-04 (work in progress), June 2014. [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- pce-09 (work in progress), June 2014. [I-D.keyupate-i2rs-bgp-usecases] Patel, K., Fernando, R., Gredler, H., Amante, S., White, R., and S. Hares, "Use Cases for an Interface to BGP Protocol", draft-keyupate-i2rs-bgp-usecases-01 (work in progress), February 2014. Chen & Hares Expires January 5, 2015 [Page 7] Internet-Draft I2RS TS Use Case July 2014 [I-D.previdi-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-previdi-isis-segment-routing- extensions-05 (work in progress), February 2014. [I-D.psenak-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-psenak-ospf- segment-routing-extensions-05 (work in progress), June 2014. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co., Ltd Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China Email: mach.chen@huawei.com Susan Hares Huawei Technologies Co., Ltd 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Chen & Hares Expires January 5, 2015 [Page 8]