idnits 2.17.1 draft-luo-grow-bgp-controller-based-ts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2018) is 2236 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.li-idr-flowspec-rpd' is defined on line 419, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-14 == Outdated reference: A later version (-05) exists of draft-li-idr-flowspec-rpd-02 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Luo 3 Internet-Draft L. Ou 4 Intended status: Informational China Telcom Co., Ltd. 5 Expires: September 6, 2018 X. Huang 6 Tencent 7 S. Zhuang 8 Z. Li 9 Huawei 10 March 5, 2018 12 Traffic Steering Based on BGP Controller 13 draft-luo-grow-bgp-controller-based-ts-00 15 Abstract 17 Due to the dramatically increased network traffic and the desire of 18 differentiated services, it is essential for operators to provide the 19 traffic steering service under limited network resources and maximize 20 their benefits at the same time. The traditional method for traffic 21 steering depends on static configuration which is time consuming and 22 error-prone. As development of SDN, the controller is introduced for 23 traffic steering with the global view of network topology and route 24 information. This document describes typical use cases for traffic 25 steering services and proposes the traffic steering solution based on 26 BGP controller. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 6, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Network Topology Collection . . . . . . . . . . . . . . . 4 71 3.2. Route Information Collection . . . . . . . . . . . . . . 4 72 3.3. Route Control . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.1. Business-oriented Steering . . . . . . . . . . . . . . . 5 75 4.1.1. An Example of Preferential Users . . . . . . . . . . 5 76 4.1.2. An Example of Preferential Services . . . . . . . . . 6 77 4.2. Traffic Congestion Mitigation . . . . . . . . . . . . . . 6 78 4.2.1. An Example of Congestion Mitigation in Core . . . . . 7 79 4.2.2. An Example of Congestion Mitigation among ISPs . . . 7 80 4.2.3. An Example of Congestion Mitigation at International 81 Edge . . . . . . . . . . . . . . . . . . . . . . . . 8 82 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 9.2. Informative References . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 Transporting data to their users through the network is a fundamental 94 service that can benefit both providers and consumers. Since data/ 95 information transport is playing a key role nowadays, operators have 96 to face this increasing challenge through satisfying services with 97 differentiated criterias, such as latency, throughput, reliability 98 and even user-defined constraints. Moreover, the internet traffic 99 changes rapidly and is hard to be predicted, so there is chance that 100 the network will be congested. However, the network capacity 101 expansion takes time and could not meet the differentiated service 102 requirement or solve the congestion problem in time. As a result it 103 is nessesary to introduce traffic steering techniques into the 104 network. The traditional method for traffic steering depends on 105 static configuration which is time consuming and error-prone. As 106 development of SDN, the controller is introduced for traffic steering 107 with the global view of network topology and route information. This 108 document describes typical use cases for traffic steering services 109 and proposes the traffic steering solution based on BGP controller. 111 2. Terminology 113 o QoS: Quality of Service 115 o ISP: Internet Service Provider 117 o MAN: Metropolitan Area Network 119 o OTT: Over the Top 121 o OTTSP: Over the Top Service Provider, or Content Operator 123 o AR: Access Router 125 3. Architecture 127 The following figure shows the solution of traffic steering through 128 BGP controller. 130 +-------------------+ 131 | | 132 | BGP | 133 |----------| Controller |--------| 134 | | | | 135 | +-------------------+ | 136 | ^ | ^ | 137 Route Control / | \ Route Control 138 | / | \ | 139 | Topo/Route | Topo/Route | 140 | Info Collection | Info Collection | 141 | / | \ | 142 \|/ / | \ \|/ 143 +--------+ +--------+ +--------+ 144 | CLIENT | | CLIENT | | CLIENT | 145 | | ...... | | ...... | | 146 | (PE) | | (P) | | (PE) | 147 | | | | | | 148 +--------+ +--------+ +--------+ 150 Figure 6 Traffic Steering through BGP Controller 152 3.1. Network Topology Collection 154 In order for traffic steering the BGP Controller must get the 155 topology of the whole network. [RFC7752] can be used to collect the 156 topology information of the network domain and 157 [I-D.ietf-idr-bgpls-segment-routing-epe] can be used to collect the 158 inter-domain topology information. 160 3.2. Route Information Collection 162 In order to steering traffic in and/or out the network, the BGP 163 controller must learn the existing BGP route information in the 164 network. There are several ways to learn the BGP route information 165 from the network: 167 1. The BGP controller can work as the route reflector so that it can 168 directly learn the BGP route from the client. 170 2. The BGP controller can also learn the BGP route through BGP 171 Mornitoring Protocol [RFC7854]. 173 3.3. Route Control 175 Based on the servie requirement BGP controller can calculate the 176 traffice steering policy for the specific BGP route. The traffice 177 steering policy should be advertised from the BGP controller along 178 with the route information to the clients in the network to take 179 effect. BGP, PCE and Netconf can be used for the advertisement. 181 4. Use Cases 183 4.1. Business-oriented Steering 185 It is a reasonable commercial way to provide multiple paths to the 186 same destination with differentiated experiences to preferential 187 users/services. This is an efficient approach to maximize providers' 188 network resources as well as their profit and offer more choices to 189 network users. 191 4.1.1. An Example of Preferential Users 193 +----------+ 194 | HongKong | 195 --+----------+-- 196 --- | --- 197 --- | --- 198 -- | -- 199 +----------+ | +----------+ 200 |Singapore | | | LA | 201 +----------+ | +----------+ 202 -- |Path1 -- 203 --- | --- 204 Path2 --- | --- Path3 205 --+----------+-- 206 | Sydney | 207 +----------+ 208 | 209 | 210 +-----------+-----------+ 211 | | | 212 +-------+ +-------+ +-------+ 213 |Silver | |Gold | |Bronze | 214 |Users | |Users | |Users | 215 +-------+ +-------+ +-------+ 216 Figure 1 Differentiated Path Selection for Different User 218 In the above ISP network, there are three kinds of users in Sydney, 219 saying Gold, Silver and Bronze, and they wish to visit website 220 located in HongKong. The ISP provides three different paths with 221 different experiences according to users' priority. The Gold Users 222 may use Path1 with less latency and loss. The Silver Users may use 223 the Path2 through Singapore with less latency but maybe some 224 congestion there. The Bronze Users may use Path3 through LA with 225 some latency and loss. 227 4.1.2. An Example of Preferential Services 229 * * 230 City A * City B * City C 231 * * 232 * +-----+ * 233 * |Users| * 234 * +-----+ * 235 * | * 236 +-----------+-----------+ 237 | * | * | 238 +-----+ * +-----+ * +-----+ 239 | R11 |-----| R12 |-----| R13 | 240 +-----+ * +-----+ * +-----+ ISP 241 | * | * | 242 *****|***********|***********|********* 243 | * | * | 244 | * | * | OTT 245 +-----+ * +-----+ * +-----+ 246 | R21 |-----| R22 |-----| R23 | 247 +-----+ * +-----+ * +-----+ 248 | * | * | 249 +-----------+-----------+ 250 * | * 251 * +-----+ * +-------+ 252 * | AR |--------|Content| 253 * +-----+ * |Server | 254 +-------+ 255 Figure 2 Differentiated Path Selection for Different Services 257 As depicted above, the OTTSP has 3 exits with one ISP, which are 258 located in City A, City B and City C. The content is obtained from 259 Content Server and send to the exits through AR. an OTTSP may make 260 its steering strategy based on different services. For example, the 261 OTTSP in the graph above may choose exit R21 for video service and 262 exit R22 for web service, which REQUIREs a mechanism/system exists to 263 identify different services from traffic flow. 265 4.2. Traffic Congestion Mitigation 267 It is a persistent goal for providers to increase the utilization 268 ratio of their current network resources, and to mitigate the traffic 269 congestion. Traffic congestion is possible to happen anywhere in the 270 ISP network(MAN, IDC, core and the links between them), because 271 internet traffic is hard to predict. For example, there might be 272 some local online events that the network operators didn't know 273 beforehead, or some sudden attack just happened. Even for the big 274 events that can be predicted, such as annual online discount of 275 e-commerce company, or IOS update of Apple Inc, we could not 276 guarantee there is no congestion. Since the network capacity 277 expansion is usually an annual operation, there could be delay on any 278 links of the engineering. As a result, the temporary traffic 279 steering is always needed. The same thing happens to the OTT 280 networks as well. 282 It should be noted that, the traffic steering is absolutely not a 283 global behavior. It just acts on part of the network, and it's 284 temporary. 286 4.2.1. An Example of Congestion Mitigation in Core 288 Core 290 +----------+ 291 | Core A | 292 +------+ --+----------+-- +------+ 293 |MAN C1|-+ --- --- +-|MAN D1| 294 +------+ | --- --- | +------+ 295 | -- -- | 296 | +----------+ +----------+ | 297 +-| Core C | | Core D |-+ 298 | +----------+ +----------+ | 299 | -- -- | 300 +------+ | --- --- | +------+ 301 |MAN C2|-+ --- --- +-|MAN D2| 302 +------+ --+----------+-- +------+ 303 | Core B | 304 +----------+ 306 Figure 3 An Example of Congestion Mitigation in Core 308 As depicted above, traffic from MAN C1 to MAN D2 follows the path 309 Core C->Core B->Core D as the primary path, but somehow the load 310 ratio becomes too much. It is reasonable to transfer some traffic 311 load to less utilized path Core C->Core A->Core D when the primary 312 path has congestion. 314 4.2.2. An Example of Congestion Mitigation among ISPs 315 * * 316 City A * City B * City C 317 * * 318 +-------+ * +-------+ * +-------+ 319 |IXP A1 |----|IXP B1|---|IXP C1 | 320 +-------+ * +-------+ * +-------+ ISP 1 321 | * | * | | 322 *******|*************|*********|**|********** 323 | +----------|---------+ | 324 | | * | * | ISP 2 325 | | * | * | 326 +------+ * +------+ * +------+ 327 |IXP A2|----|IXP B2|----|IXP C2| 328 +------+ * +------+ * +------+ 329 | * | * | 330 | * | * | 331 +-------+ * +-------+ * +-------+ 332 |Core A |----|Core B |---|Core C | 333 +-------+ * +-------+ * +-------+ 335 Figure 4 An Example of Congestion Mitigation among ISPs 337 As depicted above, ISP1 and ISP2 are interconnect by 3 exits which 338 are located in 3 cities respectively. The links between ISP1 and 339 ISP2 in the same city are called local links, and the rest are long 340 distance links. Traffic from IXP C1 to Core A in ISP 2 usually 341 passes through link IXP C1->IXP A2->Core A. This is a long distant 342 route, directly connecting city C and city A. Part of traffic could 343 be transferred to link IXP C1->IXP B1->IXP A1->IXP A2->Core A when 344 the primary route congest. 346 4.2.3. An Example of Congestion Mitigation at International Edge 348 An ISP usually interconnects with more than 2 transit networks at the 349 international edge, so it is quite common that multiple paths may 350 exist for the same foreign destination. Usually those paths with 351 better QoS properties such as latency, loss, jitter and etc are often 352 preferred. Since these properties keep changing from time to time, 353 the decision of path selection has to be made dynamically. 355 ******************************** 356 * * 357 * AS C1 * 358 * * AS Y1 359 * * 360 * +---+ +---+ * +-----------+ 361 * /| B |---------| C |-----| Transit A | AS Z1 362 * / +---+\ +---+ * +-----------+-- 363 * / | \\ // | * -- +-------------+ 364 *+---+/ | \\// | * --| | 365 *| A | | //\ | * |Destination H| 366 *+---+\ | // \\ | * --| | 367 * \ | / \ | * -- +-------------+ 368 * \ +---+ +---+ * +-----------+-- 369 * \| D |---------| E |-----| Transit B | 370 * +---+ +---+ * +-----------+ 371 * * 372 * IP Core * AS X1 373 * * 374 ******************************** 375 Figure 5 An Example of Congestion Mitigation at International Edge 377 As depicted above, the traffic to the foreign destination H from IP 378 core network (AS C1) has two choices on transit network, saying 379 Transit A and Transit B. Under normal conditions, Transit B is the 380 primary choice, but Transit A will be preferred when the QoS of 381 Transit B gets worse. As a result, the same traffic will go through 382 Transit A instead. 384 5. Contributors 386 Nan Wu 387 Huawei 388 Email: eric.wu@huawei.com 390 6. IANA Considerations 392 This document has no request to IANA. 394 7. Security Considerations 396 This document has no security issue introduced. 398 8. Acknowledgements 400 TBD. 402 9. References 404 9.1. Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 9.2. Informative References 413 [I-D.ietf-idr-bgpls-segment-routing-epe] 414 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 415 Dong, "BGP-LS extensions for Segment Routing BGP Egress 416 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 417 epe-14 (work in progress), December 2017. 419 [I-D.li-idr-flowspec-rpd] 420 Li, Z., Ou, L., Luo, Y., Lu, S., Zhuang, S., and N. Wu, 421 "BGP FlowSpec Extensions for Routing Policy Distribution 422 (RPD)", draft-li-idr-flowspec-rpd-02 (work in progress), 423 June 2016. 425 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 426 S. Ray, "North-Bound Distribution of Link-State and 427 Traffic Engineering (TE) Information Using BGP", RFC 7752, 428 DOI 10.17487/RFC7752, March 2016, 429 . 431 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 432 Monitoring Protocol (BMP)", RFC 7854, 433 DOI 10.17487/RFC7854, June 2016, 434 . 436 Authors' Addresses 438 Yujia Luo 439 China Telcom Co., Ltd. 440 109 West Zhongshan Ave,Tianhe District 441 Guangzhou 510630 442 China 444 Email: luoyuj@gsta.com 445 Liang Ou 446 China Telcom Co., Ltd. 447 109 West Zhongshan Ave,Tianhe District 448 Guangzhou 510630 449 China 451 Email: oul@gsta.com 453 Xiang Huang 454 Tencent 456 Email: terranhuang@tencent.com 458 Shunwan Zhuang 459 Huawei 460 Huawei Bld., No.156 Beiqing Rd. 461 Beijing 100095 462 China 464 Email: zhuangshunwan@huawei.com 466 Zhenbin Li 467 Huawei 468 Huawei Bld., No.156 Beiqing Rd. 469 Beijing 100095 470 China 472 Email: lizhenbin@huawei.com