Network Working Group Y. Luo Internet-Draft L. Ou Intended status: Informational China Telcom Co., Ltd. Expires: December 31, 2016 S. Lu Tencent S. Zhuang N. Wu Huawei June 29, 2016 Use-cases for Traffic Steering in Operator Networks draft-luo-grow-ts-use-cases-01 Abstract Due to the dramatically increased network traffic and the desire of differentiated services, it is essential for operators to provide the traffic steering service under limited network resources and maximize their benefits at the same time. This document lists some typical use cases for traffic steering services. This document does not attempt to enumerate all kinds of scenarios, but rather it describes several key features of these scenarios from which solutions may be constructed. 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 December 31, 2016. Luo, et al. Expires December 31, 2016 [Page 1] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 Copyright Notice Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases and Requirements . . . . . . . . . . . . . . . . . 3 3.1. Business-oriented Steering . . . . . . . . . . . . . . . 3 3.1.1. An Example of Preferential Users . . . . . . . . . . 3 3.1.2. An Example of Preferential Services . . . . . . . . . 4 3.1.3. Derived Requirements . . . . . . . . . . . . . . . . 5 3.2. Traffic Congestion Mitigation . . . . . . . . . . . . . . 6 3.2.1. An Example of Congestion Mitigation in Core . . . . . 6 3.2.2. An Example of Congestion Mitigation among ISPs . . . 7 3.2.3. An Example of Congestion Mitigation at International Edge . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.4. Derived Requirements . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Transporting data to their users through operators' networks is a fundamental service that can benefit both providers and consumers. Since data/information transport is playing a key role nowadays, operators have to face this increasing challenge through satisfying services with differentiated criterias, such as latency, throughput, reliability and even user-defined constraints. Moreover, the internet traffic changes rapidly and is hard to be predicted, so Luo, et al. Expires December 31, 2016 [Page 2] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 there is chance that operators' networks will be congested. However, the network capacity expansion takes time and could not meet the differentiated service requirement or solve the congestion problem in time. As a result, it's nessesary to introduce traffic steering techniques into operators' networks. This document lists some typical use cases for traffic steering in ISP networks and OTT networks. It does not attempt to enumerate all kinds of scenarios, but rather it describes several key features of these scenarios from which solutions may be constructed. 2. Terminology o QoS: Quality of Service o ISP: Internet Service Provider o MAN: Metropolitan Area Network o OTTSP: Over the Top Service Provider, or Content Operator o AR: Access Router 3. Use cases and Requirements 3.1. Business-oriented Steering It is a reasonable commercial way to provide multiple paths to the same destination with differentiated experiences to preferential users/services. This is an efficient approach to maximize providers' network resources as well as their profit and offer more choices to network users. 3.1.1. An Example of Preferential Users Luo, et al. Expires December 31, 2016 [Page 3] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 +----------+ | HongKong | --+----------+-- --- | --- --- | --- -- | -- +----------+ | +----------+ |Singapore | | | LA | +----------+ | +----------+ -- |Path1 -- --- | --- Path2 --- | --- Path3 --+----------+-- | Sydney | +----------+ | | +-----------+-----------+ | | | +-------+ +-------+ +-------+ |Silver | |Gold | |Bronze | |Users | |Users | |Users | +-------+ +-------+ +-------+ Figure 1 Differentiated Path Selection for Different User In the above ISP network, there are three kinds of users in Sydney, saying Gold, Silver and Bronze, and they wish to visit website located in HongKong. The ISP provides three different paths with different experiences according to users' priority. The Gold Users may use Path1 with less latency and loss. The Silver Users may use the Path2 through Singapore with less latency but maybe some congestion there. The Bronze Users may use Path3 through LA with some latency and loss. 3.1.2. An Example of Preferential Services Luo, et al. Expires December 31, 2016 [Page 4] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 * * City A * City B * City C * * * +-----+ * * |Users| * * +-----+ * * | * +-----------+-----------+ | * | * | +-----+ * +-----+ * +-----+ | R11 |-----| R12 |-----| R13 | +-----+ * +-----+ * +-----+ ISP | * | * | *****|***********|***********|********* | * | * | | * | * | OTT +-----+ * +-----+ * +-----+ | R21 |-----| R22 |-----| R23 | +-----+ * +-----+ * +-----+ | * | * | +-----------+-----------+ * | * * +-----+ * +-------+ * | AR |--------|Content| * +-----+ * |Server | +-------+ Figure 2 Differentiated Path Selection for Different Services As depicted above, the OTTSP has 3 exits with one ISP, which are located in City A, City B and City C. The content is obtained from Content Server and send to the exits through AR. an OTTSP may make its steering strategy based on different services. For example, the OTTSP in the graph above may choose exit R21 for video service and exit R22 for web service, which REQUIREs a mechanism/system exists to identify different services from traffic flow. 3.1.3. Derived Requirements o REQ01: A classification mechanism/system is REQUIRED to identify users' priority from user traffic or to identify different services from traffic flow. o REQ02: A decision procedure/mechanism for path selection is REQUIRED to exist to decide traffic forwarding strategy based on the input from a classification mechanism. Luo, et al. Expires December 31, 2016 [Page 5] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 3.2. Traffic Congestion Mitigation It is a persistent goal for providers to increase the utilization ratio of their current network resources, and to mitigate the traffic congestion. Traffic congestion is possible to happen anywhere in the ISP network(MAN, IDC, core and the links between them), because internet traffic is hard to predict. For example, there might be some local online events that the network operators didn't know beforehead, or some sudden attack just happened. Even for the big events that can be predicted, such as annual online discount of e-commerce company, or IOS update of Apple Inc, we could not guarantee there is no congestion. What is more, the network capacity expansion is usually an annual operation, which could be delayed by any links of the engineering. As a result, the temporary traffic steering is always needed. The same thing happens to the OTT networks as well. It should be noted that, the traffic steering is absolutely not a global behavior. It just acts on part of the network, and it's temporary. 3.2.1. An Example of Congestion Mitigation in Core Core +----------+ | Core A | +------+ --+----------+-- +------+ |MAN C1|-+ --- --- +-|MAN D1| +------+ | --- --- | +------+ | -- -- | | +----------+ +----------+ | +-| Core C | | Core D |-+ | +----------+ +----------+ | | -- -- | +------+ | --- --- | +------+ |MAN C2|-+ --- --- +-|MAN D2| +------+ --+----------+-- +------+ | Core B | +----------+ Figure 3 An Example of Congestion Mitigation in Core As depicted above, traffic from MAN C1 to MAN D2 follows the path Core C->Core B->Core D as the primary path, but somehow the load ratio becomes too much. It is reasonable to transfer some traffic load to less utilized path Core C->Core A->Core D when the primary path has congestion. Luo, et al. Expires December 31, 2016 [Page 6] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 3.2.2. An Example of Congestion Mitigation among ISPs * * City A * City B * City C * * +-------+ * +-------+ * +-------+ |IXP A1 |----|IXP B1|---|IXP C1 | +-------+ * +-------+ * +-------+ ISP 1 | * | * | | *******|*************|*********|**|********** | +----------|---------+ | | | * | * | ISP 2 | | * | * | +------+ * +------+ * +------+ |IXP A2|----|IXP B2|----|IXP C2| +------+ * +------+ * +------+ | * | * | | * | * | +-------+ * +-------+ * +-------+ |Core A |----|Core B |---|Core C | +-------+ * +-------+ * +-------+ Figure 4 An Example of Congestion Mitigation among ISPs As depicted above, ISP1 and ISP2 are interconnect by 3 exits which are located in 3 cities respectively. The links between ISP1 and ISP2 in the same city are called local links, and the rest are long distance links. Traffic from IXP C1 to Core A in ISP 2 usually passes through link IXP C1->IXP A2->Core A. This is a long distant route, directly connecting city C and city A. Part of traffic could be transferred to link IXP C1->IXP B1->IXP A1->IXP A2->Core A when the primary route congest. 3.2.3. An Example of Congestion Mitigation at International Edge An ISP usually interconnects with more than 2 transit networks at the international edge, so it is quite common that multiple paths may exist for the same foreign destination. Usually those paths with better QoS properties such as latency, loss, jitter and etc are often preferred. Since these properties keep changing from time to time, the decision of path selection has to be made dynamically. Luo, et al. Expires December 31, 2016 [Page 7] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 ******************************** * * * AS C1 * * * AS Y1 * * * +---+ +---+ * +-----------+ * /| B |---------| C |-----| Transit A | AS Z1 * / +---+\ +---+ * +-----------+-- * / | \\ // | * -- +-------------+ *+---+/ | \\// | * --| | *| A | | //\ | * |Destination H| *+---+\ | // \\ | * --| | * \ | / \ | * -- +-------------+ * \ +---+ +---+ * +-----------+-- * \| D |---------| E |-----| Transit B | * +---+ +---+ * +-----------+ * * * IP Core * AS X1 * * ******************************** Figure 5 An Example of Congestion Mitigation at International Edge As depicted above, the traffic to the foreign destination H from IP core network (AS C1) has two choices on transit network, saying Transit A and Transit B. Under normal conditions, Transit B is the primary choice, but Transit A will be preferred when the QoS of Transit B gets worse. As a result, the same traffic will go through Transit A instead. 3.2.4. Derived Requirements o REQ03: A resource monitoring mechanism/system is REQUIRED to exist for dynamically report the resource usage of target parts of network. o REQ04: A decision procedure/mechanism for path selection is REQUIRED to exist to decide traffic forwarding strategy based on the input from a resource monitoring mechanism. o REQ05: A QoS monitoring mechanism/system is REQUIRED to exist for dynamically report the QoS conditions of links between transit networks and local network. o REQ06: A decision procedure/mechanism for path selection is REQUIRED to exist to decide traffic forwarding strategy based on the input from a QoS monitoring mechanism. Luo, et al. Expires December 31, 2016 [Page 8] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 o REQ07: A decision distribution mechanism/system is REQUIRED to exist to populate the adjustment behavior accordingly. o REQ08: The seven mechanisms above are RECOMMENDED to be automatic ones. 4. IANA Considerations This document has no request to IANA. 5. Security Considerations This document has no security issue introduced. 6. Acknowledgements TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [I-D.chen-i2rs-ts-use-case] Chen, M. and S. Hares, "I2RS Traffic Steering Use Case", draft-chen-i2rs-ts-use-case-01 (work in progress), July 2014. [I-D.chen-idr-rr-based-traffic-steering-usecase] Chen, M., Zhuang, S., Zhu, Y., and S. Wang, "Use Cases of Route Reflection based Traffic Steering", draft-chen-idr- rr-based-traffic-steering-usecase-00 (work in progress), July 2013. [I-D.li-idr-flowspec-rpd] Li, Z., Ou, L., Luo, Y., Lu, S., Zhuang, S., and N. Wu, "BGP FlowSpec Extensions for Routing Policy Distribution (RPD)", draft-li-idr-flowspec-rpd-02 (work in progress), June 2016. Luo, et al. Expires December 31, 2016 [Page 9] Internet-DrafTraffic Steering Use Case in Operator Networks June 2016 Authors' Addresses Yujia Luo China Telcom Co., Ltd. 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: luoyuj@gsta.com Liang Ou China Telcom Co., Ltd. 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: oul@gsta.com Sujian Lu Tencent Tengyun Building,Tower A ,No. 397 Tianlin Road Shanghai, Xuhui District 200233 China Email: jasonlu@tencent.com Shunwan Zhuang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Nan Wu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: eric.wu@huawei.com Luo, et al. Expires December 31, 2016 [Page 10]