idnits 2.17.00 (12 Aug 2021) /tmp/idnits56015/draft-zhang-banana-problem-statement-03.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 (October 31, 2016) is 2021 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2698' is mentioned on line 236, but not defined == Missing Reference: 'RFC3775' is mentioned on line 490, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC3963' is mentioned on line 490, but not defined == Missing Reference: 'RFC4908' is mentioned on line 492, but not defined == Missing Reference: 'RFC5648' is mentioned on line 496, but not defined == Missing Reference: 'RFC6275' is mentioned on line 496, but not defined == Unused Reference: 'RFC2689' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'MPTCP-tans' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 620, but no explicit reference was found in the text == Outdated reference: draft-zhang-gre-tunnel-bonding has been published as RFC 8157 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Cullen 3 Intended Status: Informational Painless Security 4 N. Leymann 5 C. Heidemann 6 Deutsche Telekom AG 7 M. Boucadair 8 France Telecom 9 H. Deng 10 China Mobile 11 M. Zhang 12 B. Sarikaya 13 Huawei 14 Expires: May 4, 2017 October 31, 2016 16 Problem Statement: Bandwidth Aggregation for Internet Access 17 draft-zhang-banana-problem-statement-03.txt 19 Abstract 21 Bandwidth aggregation capabilities for Internet access services can 22 significantly improve end user's Quality of Experience. Such 23 capabilities are especially attractive in environments where multi- 24 interfaced boxes become commonplace and can technically connect to 25 various access networks, both wired and wireless. 27 This document describes the problems with bandwidth aggregation for 28 Internet access. A set of requirements are derived from the said 29 problems. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that other 38 groups may also distribute working documents as 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) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 70 3. Generic Reference Model . . . . . . . . . . . . . . . . . . . . 4 71 4. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4.2. Traffic Classification . . . . . . . . . . . . . . . . . . 5 74 4.3. Traffic Distribution . . . . . . . . . . . . . . . . . . . 5 75 4.4. Traffic Recombination . . . . . . . . . . . . . . . . . . . 6 76 4.4.1. Reordering Buffer . . . . . . . . . . . . . . . . . . . 6 77 4.5. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.6. Measurement . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.7. Policy Control . . . . . . . . . . . . . . . . . . . . . . 8 80 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . . 10 82 6.1. GRE Tunnel Bonding . . . . . . . . . . . . . . . . . . . . 10 83 6.2. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 6.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6.4. Multipath TCP Proxy . . . . . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Appendix A. Additional Requirements . . . . . . . . . . . . . . . 14 93 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 Use cases of BANdwidth Aggregation for interNet Access (BANANA, 98 a.k.a., Hybrid Access) are described in the Technical Report [TR-348] 99 published by Broadband Forum: by providing Hybrid Access, Service 100 Providers can provide customers with increased access bandwidth and 101 higher access reliability; Service delivery may also be fostered to 102 access the Internet by means of providing a LTE (Long Term Evolution) 103 connection while the wired line is being constructed. 105 Although host-based Hybrid Access is possible, the scope of this 106 document is restricted to be network-based only. Host-based might be 107 standardized in other places, such as the MIF Working Group. 109 Design techniques that are being investigated, developed and 110 sometimes deployed to facilitate bandwidth aggregation and improve 111 the resiliency of access conditions raise several problems from 112 various standpoints: traffic routing and forwarding, congestion 113 control, security, etc. This document aims at presenting these 114 problems regardless of the nature of the design technique. It also 115 intends to derive requirements accordingly, and which should be 116 addressed by any bandwidth aggregation technique. Typically, this is 117 one of the inputs that are expected from the IETF community. 119 A common framework will be sketched, including required functional 120 modules and interactions. The various solution proposals (e.g., GRE, 121 LISP, MIP, MPTCP) can be viewed as applicability assessments of the 122 framework. To support BANANA, the problems to be addressed includes: 123 addressing, traffic classification, distribution and recombination, 124 bypassing, measurement and policy control. To address these problems, 125 we may work as a group to 127 - specify the encapsulation format; 128 - develop a common control plane; 129 - and define or suggest approaches to address BANANA problems 130 developed in this document. 132 2. Acronyms and Terminology 134 Hybrid Access: The coordinated and simultaneous use of two 135 heterogeneous access paths (e.g., DSL and LTE) [TR-348]. 137 CPE: Customer Premises Equipment. An equipment which is the property 138 of the network operator and located on the customer premises. 140 HG: Home Gateway. A CPE device that is enhanced to support the 141 simultaneous use of both fixed broadband and 3GPP access connections. 143 HAAP: Hybrid Access Aggregation Point. A logical function in 144 Operator's network, terminating bonded connections while offering 145 high speed Internet. 147 PDP: Packet Data Protocol. A packet transfer protocol used in 148 wireless GPRS (General Packet Radio Service)/HSDPA (High Speed 149 Downlink Packet Access) networks. 151 PPPoE: Point-to-Point Protocol over Ethernet is a network protocol 152 for encapsulating PPP frames inside Ethernet frames. 154 DHCP: Dynamic Host Configuration Protocol [RFC2131]. 156 DNS: Domain Name System [RFC1035]. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 3. Generic Reference Model 164 +--+ +----+ 165 | +----- bonding connection ----+ | 166 | | | | 167 | | | | 168 |HG|i/f --- sub-connection ---i/f|HAAP| 169 | | . . . | | 170 | |i/f --- sub-connection ---i/f| | 171 | | | | 172 +--+ +----+ 174 Figure 3.1: Reference model of the Hybrid Access 176 Customers access the Internet using the Hybrid Access which comprises 177 of several key component functions as shown in Figure 3.1: the Home 178 Gateway (HG) as one peer, the Hybrid Access Aggregation Point (HAAP) 179 as the other peer, the bonding connection between the two peers and 180 the sub-connections that logically make up the bonding connection. 182 4. Problem Areas 184 4.1. Addressing 186 At the HG side, interface addresses of sub-connections are locally 187 acquired upon the bootstrap of the system by means of certain 188 existing protocols such as Point-to-Point Protocol over Ethernet 189 (PPPoE) [RFC2516] and Packet Data Protocol (PDP). At the HAAP side, 190 interface addresses are usually pre-configured by operators. HG and 191 HAAP will rely on the control protocol that is to be developed to 192 exchange these addresses. Afterwards, sub-connections are de- 193 multiplexed by their interface addresses. Both IPv4 and IPv6 should 194 be supported. 196 End users behind the HG box will regard the bonding connection as a 197 traditional connection to the Internet. With the established sub- 198 connections, connectivity between the HG and HAAP has been built up, 199 therefore endpoint addresses for this bonding connection can be 200 obtained from existing protocols, e.g., DHCP and DNS. 202 4.2. Traffic Classification 204 Traffic classification occurs before the flows or packets are 205 distributed among the connections. HG and HAAP should support the 206 classification function that marks a flow or packets which are to be 207 further processed by the traffic distribution function or bypass the 208 Hybrid Access (See Section 4.5). Classification criteria include IP 209 addresses, port numbers, etc. Traffic classification policies can be 210 defined by end users and service providers and must be enforced by 211 the HG and HAAP equipments. 213 4.3. Traffic Distribution 215 For traffic that is to be distributed across multiple sub- 216 connections, equal load balancing generally applies, possibly 217 inferred by the bandwidth that is available in each link that 218 supports sub-connection. Unequal load balancing should be supported 219 as well. Traffic may be distributed across sub-connections as a 220 function of their available bandwidth. Traffic may also be split in 221 such a way that whenever one sub-connection is saturated, then 222 traffic is forwarded over a secondary sub-connection. 224 There are two kinds of traffic distribution methods for the Hybrid 225 Access: per-flow load balancing and per-packet load sharing. The per- 226 flow load balancing method is used to be widely adopted in core IP 227 networks. It is suitable for the scenario where there are a large 228 number of flows to be distributed. For end users, usually there are 229 few number of applications to be transmitted over the bonded sub- 230 connections. Per-flow load balance techniques might not be able to 231 achieve a fine grained load distribution, so that the per-packet load 232 sharing is necessary. 234 For the per-flow load balancing, the load can be distributed using 235 hashing methods. For the per-packet load splitting, the coloring 236 mechanism specified in [RFC2698] can be used to classify customer's 237 IP packets, both upstream and downstream, and packets will then be 238 forwarded over the appropriate sub-connections. For example, packets 239 colored as green are forwarded over one sub-connection and packets 240 colored as yellow are forwarded over another sub-connection. For 241 scenarios that rely upon more than two sub-connections, multiple 242 levels of coloring mechanism could be implemented. 244 4.4. Traffic Recombination 246 For the packet-based traffic distribution, the recombination function 247 at the receiver sides must reorder packets to preserve the integrity 248 of the communication. The sender needs to mark each packet with a 249 sequence number. The sequence number are set per the whole bonding 250 connection rather than per sub-connection so that all packets 251 forwarded over several sub-connections actually share the same 252 reordering buffer. 254 4.4.1. Reordering Buffer 256 Ingress| flying packets |Egress 257 | +---+ +---+---+ | 258 | | 99|...| 3| 1| | 259 | +---+ +---+---+ | 260 | | 261 | ------- LTE -----> | 262 | | 263 | | 264 | | +---+ +---+---+ 265 | | |100|...| 4| 2| 266 | ------- DSL -----> | +---+ +---+---+ 267 | |50 buffered packets 268 | | 270 Figure 4.1: Minimizing the reordering buffer 272 Deployment experiences show that a secondary sub-connection might 273 suffer from large latency, jitter and high packet loss rate. For 274 packet-based traffic distribution, packets are distributed onto those 275 sub-connections at the ingress and then recombined again in a buffer 276 at the egress. If the secondary sub-connection suffers, the entire 277 bonding connection will suffer as well due to the recombination 278 function. For example, assume packet 1,3,...,99 are distributed onto 279 the secondary sub-connection while packet 2,4,...,100 are distributed 280 onto the primary sub-connection. If packet 1 is delayed by 100 ms, 281 even packet 2 arrives at the recombination buffer at the first 282 millisecond, it has to remain in the buffer awaiting for packet 1 as 283 long as 99 ms. Packets distributed onto the primary sub-connection, 284 which arrive after packet 2, have to be buffered. This can easily 285 lead to the overflow of the reordering buffer and the user's TCP 286 throughput of the bonding connection might be greatly reduced. 288 Latency of each sub-connection will be monitored. For example, HG and 289 HAAP may calculate the Adaptive Acknowledgment Time-Out of each sub- 290 connection as specified in [RFC2637]; HG and HAAP may periodically 291 exchange control messages to detect the RTT of each sub-connection 292 [FLARE]; Packet loss rate of each sub-connection may be monitored as 293 well [BondL3]. If the difference of the monitored latency exceeds a 294 predefined threshold or the secondary sub-connection exhibits a too 295 high packet loss rate, attached HG and HAAP will stop distributing 296 traffic onto this sub-connection. 298 Even if the latency of the two sub-connections are comparable and the 299 packet loss rate of the secondary sub-connection is fine so that the 300 reordering buffer does not overflow, it's still worthy to design 301 solutions to minimize the usage of the reordering buffer. In order to 302 realize this goal, the traffic distribution at the ingress should be 303 manipulated. For example, the idea of [FLARE] might be borrowed: 304 basically, a traffic flow would be split into "flowlets" by the gaps 305 between the arriving packets. Packets of a specific flowlet is solely 306 distributed onto one sub-connection. In this way, reordering is 307 avoided or minimized. The load-balancing method of MPTCP [RFC6824] 308 could be used as well: packets are always distributed to the sub- 309 connection with the least congestion level and/or latency 310 [MPscheduler]. 312 4.5. Bypass 314 Service Providers may require some traffic to bypass the Hybrid 315 Access. For example, some delay sensitive applications such as live 316 TV broadcasting carried over a lossy sub-connection would impair 317 customers' Quality of Experience. Service providers could then make 318 sure that such traffic is forwarded over a set of wired sub- 319 connections only, thereby disregarding low-rate mobile connections, 320 for example. 322 There are two types of bypass: the bypassing traffic are transmitted 323 on a sub-connection out of all the sub-connections between HG and 324 HAAP; the bypassing traffic is still transmitted on a sub-connection 325 between HG and HAAP, just that the occupied bandwidth of the 326 bypassing traffic on this sub-connection can not used for bandwidth 327 aggregation. In either case, the bypassing traffic would not be under 328 control of the Hybrid Access scheme. 330 HG and HAAP needs to exchange information about bypassing through the 331 control protocol, such as the application types that need to bypass 332 the Hybrid Access and the bandwidth occupied by the bypassing traffic 333 (See also Section 4.6). 335 4.6. Measurement 337 HG and HAAP need to measure and exchange performance parameters of 338 the Hybrid Access, including performance parameters that pertain to 339 each sub-connection that belongs to the same connection. Such 340 parameters include (but are not necessarily limited to): 342 - Operating state: The operating state has to be measured by control 343 messages. When a sub-connection fails, this sub-connection has to 344 be removed from the bonding connection. 346 - Round Trip Time (RTT): The measurement of this parameter is used 347 by flow and congestion control algorithms for per-flow and per- 348 packet distribution purposes. The probing packet could be piggy- 349 backed by data packets or could be carried by control messages. 351 - Maximum sub-connection bandwidth: This parameter may be used to 352 determine the amount of traffic that can be distributed across all 353 or a subset of sub-connections. 355 - Bypassing bandwidth: This parameter has to be periodically 356 monitored. Usually, this is measured for the opposite end to 357 figure out the available sending bandwidth. For example, the HG 358 reports the downloading bypassing bandwidth used in a sub- 359 connection so that the HAAP can calculate the remaining 360 downloading bandwidth of this sub-connection. 362 4.7. Policy Control 364 Operators and customers may control the Hybrid Access with policies. 365 These policies will be instantiated into parameters or actions that 366 impact traffic classification, distribution, combination, measurement 367 and bypassing. Such policies may consist in: 369 - Defining traffic filter lists used by the traffic classification 370 function. 372 - Per-flow or per-packet forwarding policies. 374 - Operators may specify maximum value of the difference between two 375 measured one-way transit delays. Operators may also specify the 376 maximum allowed packet loss rate of a sub-connection. 378 - Operators may determine the maximum allowed size (See 379 MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering. 381 Operators may also define the maximum time (See OUTOFORDER_TIMER 382 in [RFC2890]) that a packet can stay in the buffer for reordering. 383 These parameters may pact traffic recombination. 385 - Operators and customers may specify the service types to bypass 386 the Hybrid Access. 388 - Operators may specify the frequency for detecting a sub-connection 389 and the detection retry times before a sub-connection can be 390 declared as "failed". 392 5. Requirements 394 Requirements for the Hybrid Access are described in this section. 395 Also, some additional requirements are listed for discussion in the 396 Appendix. 398 The solution MUST apply for both IPv4 and IPv6 traffic. 400 The solution MUST NOT require any new capability to support Hybrid 401 Access from the host. 403 In the Hybrid Access, forwarding traffic flows over various 404 interfaces may have a negative impact on customers' experience (e.g., 405 hazardous log outs, broken HTTPS associations, etc.). The solution 406 should be carefully designed, so that 408 - activating the solution MUST NOT impact the stability, 409 availability of the services delivered to the customer compared 410 to customers who access the same service whose traffic is 411 forwarded along a single path. 413 "Roles" (primary or backup) should be assigned to each supported 414 network interface type (e.g., fixed or mobile access). This role is 415 assigned by the network operator (e.g., fixed access can be set as 416 the "primary"). Note that there may be more than two sub-connections 417 to support primary and backup roles. A default setting can be 418 considered. 420 - Setting of the role of the sub-connections SHOULD NOT be changed 421 by the user. 423 The solution should provide Service Providers with means to enforce 424 policy control of the Hybrid Access. For example, 426 - the solution MUST allow to rate limit the traffic on a per- 427 interface basis. 429 - the solution MUST support means to enable/disable the activation 430 of multiple interfaces at the HG. 432 - the solution MUST support means to instruct the HG about the 433 logic for mounting interfaces. 435 - the solution MUST support means to bind a given traffic to a 436 subset of interfaces. 438 For the sake of policy enforcement or analytics at the network side, 440 - the solution MAY ease correlating flows, conveyed over multiple 441 access networks, and which belong to the same customer. 443 Some services such as VoIP may be available over all active 444 interfaces, but distinct logins and credentials may be used. 446 - The HG SHOULD be provided with clear instructions about which 447 account to use to place outgoing sessions. For the sake of 448 simplicity, it is RECOMMENDED to use the login/credentials that 449 are independent of the underlying access network used to access 450 the service. 452 6. Related IETF Work 454 Hybrid Access designs can rely upon several solutions. The following 455 subsections recap the work that has been or is being conducted by the 456 IETF in this area. Note that solutions are listed in an alphabetic 457 order. No preference order should be assumed by the reader. 459 6.1. GRE Tunnel Bonding 461 GRE Tunnel Bonding [GRE-HA] uses per-packet traffic distribution to 462 achieve a fine-grained load sharing among the sub-connections. Out- 463 of-sequence packets may be received at the egress so that reordering 464 function is provided. IP packets are encapsulated in the GRE header 465 which is in turn encapsulated in an outer IP header and forwarded 466 over the sub-connections. The Sequence Number field of the GRE header 467 is used to number the packets at the sender side, while the receiver 468 uses of this sequence number to reorder the packets. 470 A new control plane is defined. Control messages are transported in 471 the same GRE tunnels that are used to transport data packets. The 472 control messages and data packets are distinguished by the GRE 473 Protocol Type 0xB7EA. 475 GRE tunnel bonding has been deployed by Deutsche Telekom AG and 476 Austria Telekom. 478 6.2. LISP 480 LISP has the basic capability to support the Hybrid Access [LISP-HA] 481 [ILNP]. LISP can be used to enforce traffic engineering based upon 482 static load balancing that is not agnostic to link characteristics. 484 Packet-based traffic distribution has been considered in [LISP-HA] as 485 well. The detail specification of the reordering mechanism based on a 486 "Reorder" flag is left for future work. 488 6.3. Mobile IP 490 Mobile IP [RFC3775] and Network Mobility (NEMO; [RFC3963]) used to 491 handle multiple L3 connectivity to the Internet via multiple ISPs for 492 a multi-homed end user [RFC4908]. By treating Hybrid Access as a 493 special scenario, some existing capabilities of Mobile IP and NEMO 494 could be reused to realize Hybrid Access. Take [MIP-HA] as an 495 example, rely on the multiple Care-of Addresses (CoAs) capability 496 [RFC5648] [RFC6275], the "addressing" problem of BANANA could be 497 settled. Currently, per-flow traffic distribution has already been 498 supported by Mobile IP and NEMO ([RFC6088], [RFC6089]) while packet- 499 based traffic distribution is left for future work [MIP-HA]. 501 6.4. Multipath TCP Proxy 503 MPTCP provides the ability to establish a communication over multiple 504 paths, by means of sub-flow establishment and operation [RFC6824]. 505 However, the traditional MPTCP is a host-based technology therefore 506 it's out the scope of this document. What is considered as a 507 candidate technology to support the Hybrid Access is the MPTCP proxy 508 mechanism. There are some implementations and deployments. 510 The MPTCP proxy operates at the transport layer and locates in the 511 operator's network. A transparent MPTCP mode is proposed in [MPTCP- 512 trans]: a MPTCP proxy terminates a user's TCP flow and reinitiates 513 MPTCP sub-flows towards the other MPTCP proxy; The other MPTCP proxy 514 will terminate the MPTCP sub-flows and restore the user's TCP flow; 515 The MPTCP protocol suite provides features to manage the state of 516 sub-flows between the two proxies. [MPTCP-plain] discusses MPTCP 517 proxy (i.e., transparent MPTCP mode) deployment concerns and also 518 specifies an extension to transport UDP datagrams in MPTCP packets. 519 UDP traffic can therefore be forwarded over a MPTCP connection. 521 7. Security Considerations 523 Hybrid Access might introduce new threats to the network. For 524 example, traffic sent on unsecured sub-connections would be easily 525 intercepted by an attacker who performs man-in-the-middle attack. The 526 multi-path communication may be leveraged to perform Denial of 527 Service (DoS) attack or Distributed Denial of Service (DDoS) attack 528 (e.g., based upon flooding traffic) that may jeopardize the 529 aggregation gateway as well as the access equipment and end station 530 operation. 532 These kind of new security issues should be carefully considered in 533 designing solutions that aim to address the problems of Bandwidth 534 Aggregation for Internet Access. 536 8. IANA Considerations 538 No IANA action is required in this document. 540 9. Acknowledgements 542 Authors would like to thank the comments and suggestions from 543 Christian Jacquenet and Li Xue. 545 10. References 547 10.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, DOI 551 10.17487/RFC2119, March 1997, . 554 [TR-348] Broadband Forum, "Technical Report on Hybrid Access 555 Broadband Network Architecture", July, 2016, 556 . 559 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 560 DOI 10.17487/RFC2131, March 1997, . 563 [RFC1035] Mockapetris, P., "Domain names - implementation and 564 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 565 November 1987, . 567 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 568 and R. Wheeler, "A Method for Transmitting PPP Over 569 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 570 1999, . 572 [RFC2689] Bormann, C., "Providing Integrated Services over Low- 573 bitrate Links", RFC 2689, DOI 10.17487/RFC2689, September 574 1999, . 576 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 577 RFC 2890, DOI 10.17487/RFC2890, September 2000, 578 . 580 10.2. Informative References 582 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 583 and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", 584 RFC 2637, DOI 10.17487/RFC2637, July 1999, . 587 [BondL3] Maciej Bednarek, Guillermo Barrenetxea, Mirja Mirja 588 Kuehlewind and Brian Trammell, "Multipath bonding at Layer 589 3", Applied Networking Research Workshop, July 16, 2016, 590 Berlin, Germany 592 [FLARE] Srikanth Kandula, Dina Katabi, Shantanu Sinha, and Arthur 593 Berger, "Dynamic Load Balancing Without Packet Reordering", 594 ACM SIGCOMM Computer Communication Review, April 2007. 596 [MPscheduler] Hyunwoo Nam, Doru Calin and Henning Schulzrinne, 597 "Towards Dynamic MPTCP Path Control Using SDN", IEEE 598 NetSoft Conference and Workshops (NetSoft), June 2016. 600 [GRE-HA] N. Leymann, C. Heidemann, M. Zhang, et al, "GRE Tunnel 601 Bonding", draft-zhang-gre-tunnel-bonding, work in progress. 603 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP 604 Extensions for Multipath Operation with Multiple 605 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 606 . 608 [MPTCP-tans] B. Peirens, G. Detal, S. Barre and O. Bonaventure, "Link 609 bonding with transparent Multipath TCP", draft-peirens- 610 mptcp-transparent, work in progress. 612 [MPTCP-plain] M. Boucadair and C. Jacquenet, "An MPTCP Option for 613 Network-Assisted MPTCP Deployments: Plain Transport Mode", 614 draft-boucadair-mptcp-plain-mode, work in progress. 616 [MIP-HA] P. Seite, A. Yegin and S. Gundavelli, "Multihoming support 617 for Residential Gateways", draft-seite-dmm-rg-multihoming, 618 work in progress. 620 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, 621 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 622 10.17487/RFC5213, August 2008, . 625 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 626 "Traffic Selectors for Flow Bindings", RFC 6088, DOI 627 10.17487/RFC6088, January 2011, . 630 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and 631 K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network 632 Mobility (NEMO) Basic Support", RFC 6089, DOI 633 10.17487/RFC6089, January 2011, . 636 [802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area 637 Networks - Link Aggregation", 802.1AX-2014, 24 December 638 2014. 640 [LISP-HA] M. Menth, A. Stockmayer and M. Schmidt, "LISP Hybrid 641 Access", draft-menth-lisp-ha, work in progress. 643 [ILNP] "ILNP - Identifier-Locator Network Protocol", online 644 available: http://ilnp.cs.st-andrews.ac.uk/ 646 Appendix A. Additional Requirements 648 The following requirements are listed as record and may subject to 649 change. 651 - The solution MUST be valid for any kinds of interfaces that need 652 to be aggregated. No dependency to the underlying media should 653 be assumed. 655 - The solution MUST comply with servers policy regarding IP 656 addresses that are bound to (HTTP session) cookies. 658 - The solution MUST NOT break TLS associations. 660 - Activating the solution MUST NOT have negative impacts on the 661 service usability (including the HG management). 663 - Service degradation MUST NOT be observed when enabling the 664 solution. 666 - Enabling the solution MUST increase the serviceability of the 667 HG. In particular, the solution MUST allow for the HG to always 668 establish a network attachment when the primary connectivity is 669 out of service. 671 - The solution SHOULD NOT alter any mechanism, to aggregate 672 available resources or to ensure a service continuity among 673 multiple access points, that is supported by end-devices 674 connected to the HG. 676 - The HG MUST bind the DNS server(s) discovered during the network 677 attachment phase to the interface from which the information was 678 received. 680 - The HG MUST bind the service information (e.g., SIP Proxy 681 Server) discovered during the network attachment phase to the 682 interface from which the information was received. 684 - When sending the traffic via a given interface, the HG MUST use 685 as source address an address (or an address from a prefix) that 686 was assigned for that interface. 688 - For protocols such as RTP/RTCP, the same IP address MUST be used 689 for both RTP and RTCP sessions. 691 - Dedicated tools SHOULD be provided to the customer to assess the 692 aggregated capacity (instead of link-specific). This can be 693 included as part of the HG UI, a dedicated portal, etc. 695 Author's Addresses 697 Margaret Cullen 698 Painless Security 699 14 Summer St. Suite 202 700 Malden, MA 02148 USA 702 EMail: margaret@painless-security.com 704 Nicolai Leymann 705 Deutsche Telekom AG 706 Winterfeldtstrasse 21-27 707 Berlin 10781 708 Germany 710 Phone: +49-170-2275345 711 EMail: n.leymann@telekom.de 713 Cornelius Heidemann 714 Deutsche Telekom AG 715 Heinrich-Hertz-Strasse 3-7 716 Darmstadt 64295 717 Germany 719 Phone: +4961515812721 720 EMail: heidemannc@telekom.de 722 Mohamed Boucadair 723 France Telecom 724 Rennes 35000 725 France 727 EMail: mohamed.boucadair@orange.com 729 Hui Deng 730 China Mobile 731 53A,Xibianmennei Ave., 732 Xuanwu District, 733 Beijing 100053 734 China 736 EMail: denghui@chinamobile.com 737 Mingui Zhang 738 Huawei Technologies 739 No.156 Beiqing Rd. Haidian District, 740 Beijing 100095 P.R. China 742 EMail: zhangmingui@huawei.com 744 Behcet Sarikaya 745 Huawei USA 746 5340 Legacy Dr. Building 3 747 Plano, TX 75024 749 EMail: sarikaya@ieee.org