Use Cases of Route Reflection based Traffic Steering
Author(s): Subin Wang, Yongqing Zhu, Mach Chen, Shunwan Zhuang
Route Reflection based Traffic Steering (RRTS) is an idea that leverages the BGP route reflection mechanism to realize traffic steering in the network, therefore the operators can conduct their traffic to transmit/receive through specific nodes, domains and/or planes...
Network Working Group M. Chen Internet-Draft S. Zhuang Intended status: Informational Huawei Technologies Expires: January 12, 2014 Y. Zhu S. Wang China Telecom Co.,Ltd July 11, 2013 Use Cases of Route Reflection based Traffic Steering draft-chen-idr-rr-based-traffic-steering-usecase-00 Abstract Route Reflection based Traffic Steering (RRTS) is an idea that leverages the BGP route reflection mechanism to realize traffic steering in the network, therefore the operators can conduct their traffic to transmit/receive through specific nodes, domains and/or planes as demand. This document introduces the requirements and use cases of RRTS. 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 RFC2119 [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 12, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires January 12, 2014 [Page 1] Internet-Draft RR based Traffic Steering July 2013 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 2. Use Cases and Requirements . . . . . . . . . . . . . . . . . 4 2.1. Multihoming Scenario . . . . . . . . . . . . . . . . . . 4 2.2. Multiple Planes Scenario . . . . . . . . . . . . . . . . 6 2.3. Multiple Entries/Exits Scenario . . . . . . . . . . . . . 7 2.4. Requirement Summary . . . . . . . . . . . . . . . . . . . 8 3. Route Refelection based Traffic Steering . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Problem Statement In an IP network, typically, both the Interior Gateway Protocol (IGP) and Border Gateway Protocol (BGP) are simultaneously deployed to forward traffic from one domain to other domains. The IGP is responsible for the internal routing and connectivity, the BGP is responsible for inter-domain routing. For the inter-domain traffic, it is forwarded based on the BGP routes. But when the traffic enters a specific domain, since the BGP routes depend the IGP routes to reach to the BGP nexthop router, the traffic actually follows the IGP routes to reach to the Autonomous System Border Routers (ASBRs) and then is forwarded to next domain. So, the IGP topology, link metric and related policies determine the traffic path within the domain. Setting and adjusting the IGP metrics is the major practice method to conduct the traffic. In order to fully use the network bandwidth, reduce the congestion on links and/or nodes, the operators have to carefully design and adjust the IGP metrics. Design IGP metrics for a greenfield network is relatively easy. But for a product network, with the increasing of network size, density and traffic volume, it's hard or even impossible to adjust the IGP metrics to smoothly conduct the traffic as needed. Setting or changing IGP metric just likes a teeterboard, it often happens that changing the metric of one link to Chen, et al. Expires January 12, 2014 [Page 2] Internet-Draft RR based Traffic Steering July 2013 solve one problem, and there will be another problem occurs. And even worse, bad metric design may result in route oscillation. ........................................ . +-----+ +-----+ . /--\ . | A |--------| B |--------|MAN2| . | |\ | | . \--/ . +-----+ \ +-----+ . . / \ \ / \ . . / \ \/ \ . . +-----+ \ / \ \ . /--\ . | E | \ / \ \ . |MAN1|---| |\ \ / \ +-----+. /--\ \--/ . +-----+ \ +------+ \| C |---|MAN3| . \ | D |--------| |. \--/ . \| | +-----+. . +------+ . . IP Core Network . ........................................ Figure 1: Paradoxical Metric Figure 1 shows a paradoxical metric scenario. Where router A, B, C, D and E belong to the IP core network, Router A, B, C and D connect each other with full mesh links, and each link have the same metric; router E multihoming connects to router A and D. The Metropolitan Area Network 1 (MAN1) connects to the IP core network through router E, MAN2 connects to the IP core network through router B, and MAN3 connects to the IP core network through router C. The requirement would like this: the traffic between MAN1 and MAN2 is required to follow the path: E-A-B; and the traffic between MAN1 and MAN3 is required to follow the path: E-D-C. To satisfy the former requirement, it requires that the metric of link E-A must be less than the metric of link E-D. But to satisfy the later requirement, it will require that the metric of link E-A must be larger than the metric of link E-D. It's impossible to satisfy the paradoxical metric requirements simultaneously. In addition, the existing BGP route decision is mainly based on the destination address, it does not consider the source address. From the source node point of view, the selected best route may not be the best route for the source node, especially in the network where Route Reflection is largely deployed. There are some proposed mechanisms (e.g., add-path[I-D.ietf-idr-add-paths], optimal route reflection [I-D.ietf-idr-bgp-optimal-route-reflection] ) that may solve or mitigate the issues. But they also bring some new challenges, they will require more memory to save huge extra routes, to keep more states and make the implementation more complicated. The most Chen, et al. Expires January 12, 2014 [Page 3] Internet-Draft RR based Traffic Steering July 2013 important one is that these solutions require to upgrade not just only one or two deployed devices, they may require to upgrade the whole or most the network devices. This makes it difficult to be deployed in a product network. Route Reflection based Traffic Steering (RRTS) is an idea that leverages the BGP route reflection mechanism to realize traffic steering in the network, therefore the operators can conduct their traffic to transmit/receive through specific nodes, domains and/or planes as demand. The essential of RRTS is that the concept of traffic engineering is introduced into BGP network. This document introduces some use cases and requirements of the RRTS. 2. Use Cases and Requirements 2.1. Multihoming Scenario Figure 2 is a multihoming scenario, where the MANs are connected by an IP core network. The routers in the core network run both IGP (ISIS or OSPF) and BGP, the IGP is used to achieve the internal routing and connectivity. There will be full mesh I-BGP sessions among the core routers or I-BGP sessions between the routers and the Route Reflector (RR). There will be E-BGP sessions between the core routers of the IP core network and the edge routers of the MANs. The BGP is used to distribute the Internet and the MAN routes. For each MAN, it multihoming connects to the IP core network through two or more core routers. Traffic between the MANs are typically forwarded through the IP core network. At the same time, there are some MANs that may have direct connected links between them. Chen, et al. Expires January 12, 2014 [Page 4] Internet-Draft RR based Traffic Steering July 2013 ---------- ///- -\\\ /// IP Core Network \\\ +-----+ / \ ------|MAN3 | +-----+ | +---+ +---+ | \ +-----+ |MAN1 |----| | A |--------------| B | | \ / | +-----+ / | +---+ +---+ | \/ | \/ | \ | | /\ | /\ | \ | | / \ | +-----+ \ | \ | | / +-----+ |MAN2 | ---- | +----+ +----+ | ------|MAN4 | +-----+ \ | C |----------| D | / +-----+ \+----+ +----+/ \\\- -/// ---------- Figure 2: Multihoming Scenarios For such a network, there will be requirements like this: If there are direct links between MANs, the traffic should be forwarded through the direct connected links; and if the direct connected links are used up, then some traffic should be forwarded though the IP core network; For two specific MANs (e.g., MAN1 and MAN3), the traffic between them should be forwarded though the required path, for example, MAN1-A-B-MAN3; the working and backup path should be disjoint as soon as possible. For two specific MANs (e.g., MAN2 and MAN4), part of the traffic is required to be forwarded through one path (e.g., MAN2-C-D-MAN4), and other traffic is required to be forwarded through other path (e.g., MAN2-A-B-MAN4); There may be more other requirements with the increasing of the network size, density, and more services transmitted over the network, more access networks connect to the network. As discussed in the previous section, the current metric-based traffic conducting mechanism cannot (at least does not easily) satisfy the above requirements. Chen, et al. Expires January 12, 2014 [Page 5] Internet-Draft RR based Traffic Steering July 2013 2.2. Multiple Planes Scenario With the increasing of network traffic, the bandwidth, device ports of the existing devices/network are not enough to support new accessed traffic and services. So, some operators choose to set up new parallel planes to enlarge the network capacity. Figure 3 is a multiple planes scenario, there are two planes in the IP core network. C11, C12, C13 and C14 belong to plane 1; C21, C22, C23 and C24 belong to plane 2. Plane 2 is the new built plane that normally has more bandwidth and is fine designed. So, the operators will move the high-cost services to the new plane, and keep the other services on the old plane, and try to fully use the network resource of the two planes and keep the traffic balanced according to the capacity of two planes. +-----+ +-----+ +-----+ |MAN1 | |MAN2 |...|MANn | MANs +-----+ +-----+ +-----+ /\ / \ /\ ......../..\../......\../..\............. . \/ \/ . . C11----------C21 . . | \ | \ . . | \ | \ . . | C12----------C22 . . Plane1 | | | | Plane2 . . C13--|-----C23 | . . \ | \ | . . \ | \ | . . IP Core C14----------C24 . . Network /\ /\ . ............\../..\....../..\../......... \/ \ / \/ +-----+ +-----+ +-----+ |MAN11| |MAN12|...|MAN1n| MANs +-----+ +-----+ +-----+ Figure 3: Multiple Planes Scenarios For the multiple planes network, here are some typical requirements: For any two specific MANs (e.g., MAN1 and MAN11), some service (e.g., Internet Data Center (IDC), Virtual Private Network (VPN), Private Line etc. services ) traffic is required to be forwarded through the new plane (plane 2), and the other traffic will still be forwarded though the old plane (plane 1); Chen, et al. Expires January 12, 2014 [Page 6] Internet-Draft RR based Traffic Steering July 2013 Traffic between some MANs is required to be forwarded though plane 1, and traffic between other MANs is required to be forwarded though plane 2; for example, traffic between MAN1 and MAN11 is required to be forwarded through plane 1, traffic between MAN3 and MAN33 is required to be forwarded through plane 2. For any two specific MANs (e.g., MAN2 and MAN22), it should be able to balance the traffic between the two MANs through the two planes based on the capacity/load of the two planes; According to different users, it should be able to choose different planes; According different SLA and QoS requirements, it should be able choose proper forwarding plane based on the SLA and QoS requirements and the fact of the planes; It should able to choose forwarding plane based on the different access locations; 2.3. Multiple Entries/Exits Scenario Figure 4 shows the multiple entries/exits scenario. For network 1, it has three entries/exits that respectively connect to transit network A, B and C. And between network 1 and each transit network, there is one or more links. Different link has different cost/price, bandwidth, delay/loss attributes. /---\ | A |--- / \---/ ----- / /// \\\ / | | / /---\ | Network 1 |----| B |--- | | \---/ | | \ \\\ /// \ ----- \ /---\ \| C |--- \---/ Figure 4: Multiple Entry/Exit (MEE) For this multiple extry/exit scenario, it has the following requirements: Chen, et al. Expires January 12, 2014 [Page 7] Internet-Draft RR based Traffic Steering July 2013 Choose the proper extry/exit based on link price and/or service type; Dynamically adjust the extry/exit based on link load and/or link price; 2.4. Requirement Summary According to the above use cases, the requirements can be summarized as follows: Be able to specify the forwarding path/plane based source and destination addresses; Be able to specify the forwarding path/plane based on service type; Be able to specify the forwarding path/plane based on users; Be able to specify the forwarding path/plane based on SLA and QoS requirements; Be able to change/adjust the forwarding path/plane of some traffic based on the network load and usable capacity; Be able to choose/adjust network entry/exit based on link price/ service type/link load; Looking through these requirements, they are actually the requirements of traffic engineering. In tradition IP network, traffic forwarding is a per-hop IP lookup and forwarding behavior. There is few mechanism defined for pure IP based traffic engineering. IP source routing is a way that can direct the traffic to transmit along specified path, but it is not widely implemented and deployed. That means, there is requirement to introduce the traffic engineering to pure IP network, but it is lack of readily available solutions. 3. Route Refelection based Traffic Steering For a product network, an acceptable solution should be able to smoothly and incrementally upgrade the network and should not affect the on-going services. Route Reflection is widely deployed in the field, a Route Reflector (RR) has the ability to "install"/distribute a route to its client with the nexthop that can be either the RR itself or any other different BGP speakers. Given this, for an IP network, if all routers run BGP and are connected by a centralized RR, and the RR has the topology, network capacity, network resource etc. information of the whole network. Then the RR can compute the Chen, et al. Expires January 12, 2014 [Page 8] Internet-Draft RR based Traffic Steering July 2013 routes for every router and install/distribute the routes to corresponding routers. ---- / \ | RR | \ / /-+-\ / | \ / | \ / +--+-+ \ +--+-+/| | B | +--+-+ Source 1---| A | | +----+ | C |--- Destination 1 \ /+----+ | +----+\ / * +---+----+-------+ * / \+--+-+ | +-+--+/ \ Source 2---| D | +--+-+ | F |--- Destination 2 +----+ | E | +----+ +----+ Figure 5: Route Reflection based Traffic Steering (RRTS) Figure 5 is a reference architecture of the Route Reflection based Traffic Steering (RRTS). The RR and its route reflection clients form a RRTS domain. The RR is a centralized controller that is responsible for the BGP route decision of the whole domain. All other routers in the domain are as route reflection clients of the RR, each router will establish an I-BGP session to the RR, and there is no direct BGP sessions among these routers. This looks no different from the current Route Reflector (RR) based architecture. For each client, it will still run as current, when received BGP routes from outside, it will transparently distribute the routes to the RR. For each route, the RR will make the decision for each relevant router and then install/distribute the route to each related router. For example, for a path from Source 1 (S1) to Destination 1 (D1), if the computed path is: S1-A-B-C-D1, then the RR will distribute a route (D1) to C with the nexthop set to D1; a route (D1) to B with the nexthop set to C, and a route (D1) to A with the nexthop set to B, and finally the route (D1) will be distributed to S1 by A. RRTS will not require the clients to make any changes. All the changes are made on the RR, the RR can apply any route or traffic engineering algorithms. Chen, et al. Expires January 12, 2014 [Page 9] Internet-Draft RR based Traffic Steering July 2013 4. IANA Considerations This document makes no request of IANA. 5. Acknowledgements The authors would like to thank Bai Tao, Fengqing Yu for their contribution to this document. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. 6.2. Informative References [I-D.ietf-idr-add-paths] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", draft-ietf-idr- add-paths-08 (work in progress), December 2012. [I-D.ietf-idr-bgp-optimal-route-reflection] Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S. Litkowski, "BGP Optimal Route Reflection (BGP-ORR)", draft-ietf-idr-bgp-optimal-route-reflection-05 (work in progress), June 2013. Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Email: email@example.com Shunwan Zhuang Huawei Technologies Email: firstname.lastname@example.org Chen, et al. Expires January 12, 2014 [Page 10] Internet-Draft RR based Traffic Steering July 2013 Yongqing Zhu China Telecom Co.,Ltd 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: email@example.com Subin Wang China Telecom Co.,Ltd 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: firstname.lastname@example.org Chen, et al. Expires January 12, 2014 [Page 11]