idnits 2.17.1 draft-zuo-banana-mptcp-integration-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 date (June 8, 2017) is 2507 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '802Type' is defined on line 487, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2697 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BANANA N. Leymann 3 Internet Draft C. Heidemann 4 Intended Category: Standard Track Deutsche Telekom AG 5 G. Liang 6 China Mobile 7 J. Zuo 8 L. Zheng 9 Huawei 10 Expires: December 9, 2017 June 8, 2017 12 Integration of Bonding Tunnels and MPTCP 13 draft-zuo-banana-mptcp-integration-00.txt 15 Abstract 17 BANdwidth Aggregation for interNet Access (BANANA) based on tunnel 18 bonding protocols and Multipath TCP (MPTCP) are two different 19 technology suites that offer subscribers with higher bandwidth and 20 reliability. MPTCP excels at conducting TCP traffic since its 21 flow/congestion control scheme has been well developed while tunnel 22 bonding protocols support not only TCP traffic but also UDP traffic. 23 The integration of the two kinds of technologies can be considered to 24 make use of advantages of both. Moreover, extensions made to the 25 tunnel bonding protocols can simplify the MPTCP stack and keep it 26 intact. This document specifies the extensions for tunnel bonding 27 protocols to realize integrative deployment of tunnel bonding 28 solutions and MPTCP. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 Copyright and License Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 70 3. Integration of Tunnel Bonding and MPTCP . . . . . . . . . . . . 4 71 3.1. Collocated Scenarios . . . . . . . . . . . . . . . . . . . 4 72 3.1.1 BANANA Endpoints Collocate with MPTCP Endpoints . . . . 4 73 3.1.2 HG/HAAP Collocate with MPTCP Proxy/Endpoint . . . . . . 4 74 3.1.3 HG and HAAP Collocate with Two MPTCP Proxies . . . . . . 5 75 3.2. MPTCP Traffic Recognition . . . . . . . . . . . . . . . . . 6 76 3.3. Bypassing and Pre-coloring . . . . . . . . . . . . . . . . 6 77 3.4. The Anycast Mechanism . . . . . . . . . . . . . . . . . . . 7 78 4. Message Types . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Tunnel Characteristics . . . . . . . . . . . . . . . . . . 7 80 4.2. Connection Mapping . . . . . . . . . . . . . . . . . . . . 9 81 5. MPTCP Path Selection using Bonding Tunnels . . . . . . . . . . 9 82 5.1 Subflow Policy . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.2. Address Knowledge Exchange (Path Management) . . . . . . . 10 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 89 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 BANdwidth Aggregation for interNet Access (BANANA) offers subscribers 94 with higher bandwidth and resilience than they can get from a single 95 access. MPTCP proxy based solutions and tunnel based solutions have 96 been developed to realize BANANA. 98 Multipath TCP (MPTCP) enables a transport connection to operate 99 across multiple paths simultaneously [RFC6824]. A flow/congestion 100 control scheme has been developed by MPTCP to let subscribers with 101 MPTCP endpoints efficiently utilize the bandwidth of the multiple 102 paths. Recently, MPTCP WG proposed the network-based MPTCP proxy 103 solution [PlainProxy] so that TCP endpoints can utilize the 104 aggregated bandwidth between the two MPTCP proxies while they need 105 not be upgraded to MPTCP endpoints. 107 As enabling technologies of BANANA, tunnel bonding solutions have 108 been deployed by multiple Service Providers. In a tunnel bonding 109 system, one tunnel is established per-connection between the two 110 tunnel bonding boxes. These tunnels are bonded together as if there 111 is a single IP link provided between the two boxes for the subscriber 112 who buys the tunnel bonding box. Different from MPTCP which is a 113 transport layer technology, tunnel bonding protocols operate under 114 the transport layer and support both TCP and UDP. 116 MPTCP and a tunnel bonding protocol may coexist in one network. There 117 are two types of such coexistence. For the first type, the tunnel 118 endpoint and the MPTCP stack can either be collocated in a host, in a 119 network device or on a site. For the second type, subscribers' 120 endpoints support MPTCP. These MPTCP endpoints are distributing MPTCP 121 traffic among the tunnels according to the MPTCP stack. The MPTCP 122 traffic should be recognized and avoid being re-distributed by the 123 BANANA box's load balancer. This document specifies how a tunnel 124 bonding solution and MPTCP can be integrated in a single system in 125 order to make use of advantages of both technologies. 127 In this document, message types of the bonding tunnel protocol are 128 specified to deliver characteristics of tunnels to the MPTCP stack. 129 MPTCP stack uses these tunnels that are setup in advance as its 130 network paths. In this way, the time on the discovery of these 131 network paths and the time on learning those characteristics can be 132 saved. Hence, this kind of integration will help to accelerate the 133 deployment of MPTCP. 135 2. Acronyms and Terminology 137 BANANA: BANdwidth Aggregation for interNet Access 139 HG: Home Gateway. A CPE device that is enhanced to support the 140 simultaneous use of multiple access connections. Also used as BANANA 141 local box. 143 HAAP: Hybrid Access Aggregation Point. A logical function in the 144 network, terminating bonded connections while offering high speed 145 Internet. Also used as BANANA remote box. 147 CIR: Committed Information Rate [RFC2697] 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 3. Integration of Tunnel Bonding and MPTCP 155 Tunnel bonding and MPTCP can be integrated as follows. MPTCP stack 156 and the tunnel bonding protocol endpoints can collocate in one host, 157 one network device or one site. MPTCP stack uses the bonding tunnels 158 as its multiple paths so that the time on path discovery can be 159 saved. Meanwhile, the bonding tunnels do not need consider the 160 flow/congestion control and reliability issues for the TCP traffic. 162 In either ways, the tunnel bonding protocol notifies the MPTCP stack 163 about the characteristics of the tunnels, such as the priority, the 164 available bandwidth and the Round-Trip Time (RTT). The MPTCP stack 165 sorts the paths according to their priorities and allocates subflows 166 according to their bandwidth demands and the available bandwidth of 167 the tunnels or even RTT. 169 3.1. Collocated Scenarios 171 The following three scenarios explains how a tunnel bonding protocol 172 and MPTCP are collocated in one host or one network device. 174 3.1.1 BANANA Endpoints Collocate with MPTCP Endpoints 176 +-----+ +-----+ 177 | | subflow1 | | 178 | IP1---------IP2 | 179 | | | | 180 | | | | 181 | | subflow2 | | 182 | IP3---------IP4 | 183 | | | | 184 +-----+ +-----+ 185 MPTCP endpoint1 MPTCP endpoint2 186 /HG /HAAP 188 Figure 3.1: BANANA endpoints collocate with MPTCP endpoints 190 As shown in Figure 3.1, BANANA endpoints HG and HAAP collocate with 191 the two MPTCP endpoints respectively. The two endpoints act as tunnel 192 endpoints which used to be done by network based devices. 194 3.1.2 HG/HAAP Collocate with MPTCP Proxy/Endpoint 195 +-----+ +-----+ +-----+ 196 | | subflow1 | | | | 197 | IP1---------IP2 | | | 198 | | | | TCP | | 199 | | | IPe-----IPf | 200 | | subflow2 | | | | 201 | IP3---------IP4 | | | 202 | | | | | | 203 +-----+ +-----+ +-----+ 204 MPTCP endpoint1 MPTCP proxy2 TCP 205 /HG /HAAP endpoint2 207 Figure 3.2: HAAP collocates with one-end MPTCP proxy 208 HG collocates with the MPTCP endpoint 210 As shown in Figure 3.2, HAAP acts as the proxy of TCP endpoint2 and 211 speaks MPTCP with MPTCP endpoint1. MPTCP proxy2 SHOULD use IPe as the 212 source IP address for the TCP session between itself and the TCP 213 endpoint2. MPTCP proxy2 locally maintains the mapping between the 214 subflows and the normal TCP session. 216 3.1.3 HG and HAAP Collocate with Two MPTCP Proxies 218 +-----+ +-----+ +-----+ +-----+ 219 | | | | subflow1 | | | | 220 | | | IP1---------IP2 | | | 221 | | TCP | | | | TCP | | 222 | IPe------IPf | | IPe-----IPf | 223 | | | | subflow2 | | | | 224 | | | IP3---------IP4 | | | 225 | | | | | | | | 226 +-----+ +-----+ +-----+ +-----+ 227 TCP MPTCP proxy1 MPTCP proxy2 TCP 228 endpoint1 /HG /HAAP endpoint2 230 Figure 3.3: HG and HAAP collocate with two MPTCP proxies 232 As shown in Figure 3.3, HG and HAAP act as MPTCP proxies of TCP 233 endpoint1 and TCP endpoint2 respectively. HG and HAAP need to learn 234 the source and destination IP address being used by the normal TCP 235 session and act as MPTCP proxies of the TCP endpoint1 and TCP 236 endpoint2 from each end respectively. 238 The two MPTCP proxies need to exchange the mapping between the TCP 239 connection and the MPTCP connection to ensure that a specific TCP 240 connection is mapped to the same MPTCP connection on both proxies. 241 This mapping is exchanged using the TLV as specified in Section 4.2. 243 3.2. MPTCP Traffic Recognition 245 +-----+ +-----+ +-----+ +-----+ 246 | | | | subflow1 | | | | 247 | | | |-----------| | | | 248 | |subflow1| | | |subflow1| | 249 | IPe========| | | |========IPf | 250 | |subflow2| | subflow2 | |subflow2| | 251 | | | |-----------| | | | 252 | | | | | | | | 253 +-----+ +-----+ +-----+ +-----+ 254 MPTCP MPTCP 255 endpoint1 HG HAAP endpoint2 257 Figure 3.4: Bonding tunnels discriminate the MPTCP traffic 259 Suppose endpoints support the MPTCP stack. The MPTCP traffic (e.g., 260 subflows) will be recognized by the HG/HAAP boxes and locally 261 bypassed by the traffic distribution method of the bonding tunnel 262 protocol. For this scenario, HG and HAAP need not to deliver the 263 tunnel characteristics or connection mapping information of the two 264 tunnels to the two MPTCP endpoints. 266 3.3. Bypassing and Pre-coloring 268 The bypass feature of bonding tunnels allows operators to configure 269 traffic types not to be carried through the bonding tunnels. That is 270 an "outer" bypass. This memo additionally enables an "inner" (inside 271 the bonding tunnels) bypass of MPTCP traffic. 273 Suppose a packet of size B bytes arrives at time t. 275 o If the packet is of the traffic type that is configured to bypass 276 the bonding tunnels, it is pre-colored as green; the Single Rate 277 Three Color Marker (srTCM) of [RFC2697] MUST operate in the 278 Color-Aware mode with a minor change: pre-colored green packet 279 will remain in green than be re-colored as yellow; else 281 o if the packet is an MPTCP packet, this packet will be pre-colored 282 depends on the load balancer of the MPTCP stack: it is pre- 283 colored as green if it is to be delivered through the first 284 tunnel or yellow if it is to be delivered through the second 285 tunnel; the packet size B is incremented by the size of the 286 tunnel header; the srTCM MUST operate in the Color-Aware mode 287 with a minor change: pre-colored green packet will remain in 288 green than be re-colored as yellow; else 290 o the packet size B is incremented by the size of the tunnel header 291 and the srTCM MUST operate in the Color-Blind mode. 293 Green packets of the traffic types that are configured to bypass the 294 bonding tunnels are carried using the first raw connection of the HG. 295 Within the bonding tunnels, green packets are carried using the first 296 tunnel while yellow or red packets are carried using the second 297 tunnel. 299 3.4. The Anycast Mechanism 301 When a MPTCP proxy box and a BANANA box are collocated in a site 302 rather than one host or one network device (Scenario 2 and Scenario 303 3), a box can be put in front of them to achieve anycast. Service 304 discovery of BANANA will be handled by the front box while the tunnel 305 endpoints will be either the BANANA box or the MPTCP proxy. Hence, 306 two pairs of tunnels will be set up. One pair of them are terminated 307 by the BANANA box while the other pair of tunnels are terminated by 308 the MPTCP proxy box. Hence, MPTCP and non-MPTCP traffic is delivered 309 in different tunnels. 311 The two pairs of tunnels share the same pair of paths. Different from 312 the scenarios where BANANA box and MPTCP proxy are in the same 313 network device, traffic for the MPTCP proxy and the BANANA box is 314 distributed onto the paths separately. Bonding tunnels will still 315 conduct MPTCP traffic as bypass traffic. BANANA boxes need to measure 316 the amount of the bypass traffic periodically in order to subtract 317 this amount from the Committed Information Rate (CIR) for the 318 coloring mechanism [RFC2697]. 320 4. Message Types 322 Two TLVs are defined by the tunnel bonding protocol to facilitate the 323 MPTCP stack. 325 4.1. Tunnel Characteristics 327 The follow TLV carries tunnel characteristics and IP addresses of a 328 tunnel which will be used as paths by MPTCP stack for its subflows. 330 +-+-+-+-+-+-+-+-+ 331 | Type | (1 byte) 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Length | (2 bytes) 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Priority | (1 byte) 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 337 | Available Downstream Bandwidth (4 bytes) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 339 | Available Upstream Bandwidth (4 bytes) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 341 | RTT (4 bytes) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 343 | Source IP address (4 or 16 bytes)| 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 345 | Destination IP address (4 or 16 bytes)| 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 348 Type 349 Tunnel Characteristics (TBD), the characteristics of the tunnel. 351 Length 352 Set to 17 or 41. Source IP address and destination IP address MUST 353 be either IPv4 or IPv6. 355 Priority 356 An unsigned integer. The bonding tunnels will determine the 357 priority of paths for MPTCP and deliver this information through 358 the tunnel priority. The path manager of MPTCP stack will order 359 the paths with highest numerical priority being highest priority. 361 Available Downstream Bandwidth 362 An unsigned integer measured in kbps. The HAAP calculates the 363 available Bandwidth by subtracting the measured bypass traffic 364 rate, where the bypass traffic rate can be calculated by 365 periodically counting the received packets at the HG. The HG 366 notify the Available Downstream Bandwidth and the measured bypass 367 traffic rate to the HAAP. 369 Available Upstream Bandwidth 370 An unsigned integer measured in kbps. There is no bypass traffic 371 rate to be substracted from the Committed Upstream Bandwidth. The 372 HAAP notify the Available Upstream Bandwidth to the HG. 374 RTT 375 An unsigned integer measured in ms. 377 Source IP address 378 Set to a pre-configured IPv4/IPv6 address which is used as the 379 source endpoint IP address of a tunnel between the two MPTCP 380 proxies. 382 Destination IP address 383 Set to a pre-configured IPv4/IPv6 address which is used as the 384 destination endpoint IP address of a tunnel between the two MPTCP 385 proxies. 387 4.2. Connection Mapping 389 The following Connection Mapping TLV is specified by the tunnel 390 bonding protocol for the purpose of exchanging between the pair of 391 MPTCP proxies about the mapping between MPTCP connection and TCP 392 connection. 394 +-+-+-+-+-+-+-+-+ 395 | Type | (1 byte) 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Length | (2 bytes) 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 399 | MPTCP Connection ID (4 bytes) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 401 | Source IP address of TCP (4 or 16 bytes)| 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 403 | Destination IP address of TCP (4 or 16 bytes)| 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 406 Type 407 Connection Mapping (TBD), the mapping between MPTCP connection and 408 TCP connection. 410 MPTCP Connection ID 411 An unique identifier given to a multipath connection by the MPTCP 412 proxy, which is the Token defined in [RFC6824]. 414 Source IP address of TCP 415 The source IPv4/IPv6 address of the TCP connection. 417 Destination IP address of TCP 418 The destination IPv4/IPv6 address of the TCP connection. 420 5. MPTCP Path Selection using Bonding Tunnels 422 Based on the tunnel characteristics like bandwidth, latency, etc., of 423 the bonding tunnels, MPTCP may select the set of paths for providing 424 higher throughput or resilience against path failures. 426 5.1 Subflow Policy 428 As mentioned in [RFC6824], the MPTCP endpoint may use any local 429 policy to decide how to send the traffic over the available paths. 430 the MPTCP endpoint requires the knowledge of the path 'cost' to make 431 effective choices, where the path 'cost' may be obtained from the TLV 432 carried by the Tunnel Characteristics TLV. Moreover, in the event 433 that the available set of paths changes, the MPTCP endpoint may wish 434 to signal a change in priority of subflows to the other MPTCP 435 endpoint, where the subflow has the same meaning of physical path. 436 Therefore, the priority information may also be obtained from the 437 TLV. If the multiple subflows are differentiated from port numbers 438 while with the same IP addresses, the priority of subflows are deemed 439 to be the same, as obtained from the TLV of the same physical path. 441 5.2. Address Knowledge Exchange (Path Management) 443 As mentioned in [RFC6824], the "path management" is responsible for 444 the exchange of additional addresses between the two MPTCP endpoints, 445 where the Add Address (ADD_ADDR) MPTCP option is used to inform the 446 other MPTCP endpoint of the IP addresses. If the previously informed 447 address becomes invalid, a Remove Address (REMOVE_ADDR) option is 448 used to announce the peer to remove the subflows related to this 449 address. The ADD_ADDR and REMOVE_ADDR options are carried in the 450 duplicate ACK packets and to be sent periodically. However, with the 451 help of the IP addresses carried in Connection Mapping TLV, the MPTCP 452 stack does not need extra signal to manage the paths. 454 6. Security Considerations 456 TBD. 458 7. IANA Considerations 460 Codepoints of the TLV defined in Section 5 need to be registered by a 461 specific tunnel bonding protocol. 463 8. References 465 8.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, DOI 469 10.17487/RFC2119, March 1997, . 472 [RFC2697] Heinanen, J. and Guerin R., "A Single Rate Three Color 473 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 474 . 476 [RFC6824] Ford, A., Raiciu, C., Handley, M., and Bonaventure, O., 477 "TCP Extensions for Multipath Operation with Multiple 478 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 479 . 481 [PlainProxy] Boucadair, M., Jacquenet, C., et al, "Extensions for 482 Network-Assisted MPTCP Deployment Models", draft-boucadair- 483 mptcp-plain-mode, work in progress. 485 8.2. Informative References 487 [802Type] IANA, "IEEE 802 Numbers", 488 . 490 Author's Addresses 492 Nicolai Leymann 493 Deutsche Telekom AG 494 Winterfeldtstrasse 21-27 495 Berlin 10781 496 Germany 498 Phone: +49-170-2275345 499 EMail: n.leymann@telekom.de 501 Cornelius Heidemann 502 Deutsche Telekom AG 503 Heinrich-Hertz-Strasse 3-7 504 Darmstadt 64295 505 Germany 507 Phone: +4961515812721 508 EMail: heidemannc@telekom.de 510 Geng Liang 511 China Mobile 512 32 Xuanwumen West Street, 513 Xicheng District, Beijing, 100053, 514 China 516 EMail: gengliang@chinamobile.com 518 Jing Zuo 519 Huawei Technologies 520 Bantian, Longgang District, 521 Shenzhen 518129 P.R. China 522 EMail: jing.zuo@huawei.com 524 Lianshu Zheng 525 Huawei Technologies 526 No.156 Beiqing Rd. Haidian District, 527 Beijing 100095 P.R. China 529 EMail: vero.zheng@huawei.com