idnits 2.17.1 draft-lhwxz-hybrid-access-network-architecture-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 14, 2015) is 3391 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Leymann 3 Internet-Draft C. Heidemann 4 Intended status: Informational Deutsche Telekom AG 5 Expires: July 18, 2015 M. Wesserman 6 Painless Security 7 L. Xue 8 M. Zhang 9 Huawei 10 January 14, 2015 12 Hybrid Access Network Architecture 13 draft-lhwxz-hybrid-access-network-architecture-02 15 Abstract 17 Residential and Enterprise customers require continuously increasing 18 bandwidth, however it may be difficult for operators to update or 19 rebuild existing fixed access networks, especially when they are 20 deployed in certain areas. This document discusses a general way to 21 address this problem by bundling together multiple heterogeneous 22 access networks according to certain management policies. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119] 30 Status of This Memo 32 This Internet-Draft is submitted 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). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 27, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Customer Scenarios . . . . . . . . . . . . . . . . . . . . . 3 67 4. Traffic Distribution Schemes . . . . . . . . . . . . . . . . 5 68 5. Hybrid Access Architecture . . . . . . . . . . . . . . . . . 8 69 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 13 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 73 10. Normative References . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 Residential and Enterprise customers require continuously increasing 79 bandwidth, however it may be difficult for operators to update or 80 rebuild existing fixed access networks, especially when they are 81 deployed in certain locations (e.g., old downtown areas). Fiber to 82 the Home (FTTH) is an option to solve this issue, however, it may be 83 not deployable in some geographical circumstances (e.g., rural 84 areas). This document discusses a general way to address this 85 problem by bundling together multiple heterogeneous access networks 86 (e.g., LTE, DSL, etc.) in a flexible manner. 88 This document calls HYbrid access (HYA) a generic mechanism for 89 bundling together multiple heterogeneous access networks. In this 90 mechanism the Customer Premise Equipment (CPE) is enhanced to support 91 the multiple heterogeneous access networks simultaneously. The HYA 92 mechanism needs to provide flexibility in deciding the paths over 93 which to forward data traffic. This document proposes a generic 94 architectural design for the HYA mechanism and identifies potential 95 issues and requirements. 97 The remainder of this document is organized as follows. Section 2 98 lists the key terms used in this document. Section 3 introduces 99 customer scenarios and the associated requirements for bundling 100 heterogeneous access networks. Section 4 discusses the traffic 101 distribution schemes among the multiple heterogeneous access 102 networks, flow-based forwarding and packet-based forwarding. 103 Section 6 discusses the technology issues and requirements to be 104 addressed in IETF. 106 2. Terminology 108 Customer Premise Equipment (CPE): A device that connects multiple 109 hosts to provide connectivity to a service provider network. 111 HYbrid Access (HYA): The bundling of two or more access lines based 112 on heterogeneous technologies (e.g., DSL and LTE) to provide to an 113 residential or enterprise customer an higher bandwidth Internet 114 connection. 116 Bundling Gateway (BGW): The service point that implements the 117 bundling mechanism and provides a higher bandwidth Internet 118 connection to the CPE from two or more heterogeneous access 119 networks. The BGW is a logical function. It should support 120 packets reordering, if needed. 122 Path: A sequence of links between the CPE and the BGW. 124 3. Customer Scenarios 126 Figure 1 illustrates a significant customer scenario. In this 127 scenario a customer site (either home or enterprise) is connected to 128 the Internet through a CPE providing both wired and wireless 129 connectivity through a fixed access network. The customer site is 130 also covered by 3G/4G cellular signal, able to provide Internet 131 connectivity as well. 133 Hosts in the customer site may connect to the Internet through the 134 CPE, the 3G/4G network, or both. In most cases the majority of the 135 hosts connects to the Internet through the CPE only and will 136 experience slow Internet access when the bandwidth provided by the 137 fixed access network is fully utilized (e.g., the traffic over the 138 fixed access network reached its maximum capacity or a pre-specified 139 threshold set by the operator). In this case, the problem could be 140 addressed if the CPE is able to access the 3G/4G network and provide 141 additional bandwidth to these hosts without requiring an upgrade of 142 the fixed access network as shown in Figure 2. Upgrading a fixed 143 access network may be costly and slow, especially in the areas with 144 limited accessibility. Having a CPE able to take advantage of the 145 bandwidth resources of the 3G/4G cellular network and of the fixed 146 access network concurrently is very desirable for an operator, 147 especially if the 3G/4G cellular backhaul network is not used at its 148 fullest capacity. 150 +----+ 151 |HOST%LTE only ------ 152 +----+ / \ 153 %======+ Wireless +===+ 154 +----+ | 3G/4G | \ ***** 155 | %LTE \ / ** ** 156 |HOST*WiFi ------ * * 157 +----+ +-----+ * Internet * 158 WiFi* | ------ * * 159 +----+ | | / \ ** ** 160 |HOST+-----+ CPE +---+ | / ***** 161 +----+Wired| | | Fixed +---/ 162 | | \ / 163 +----+ +-----+ ------ 164 |HOST*WiFi only 165 +----+ 167 Figure 1: Existing Home Network Scenario 169 Additionally, the hosts without 3G/4G cellular interface will suffer 170 from service interruption when the fixed access network fails. If 171 the CPE is able to access the 3G/4G network as shown in Figure 2, the 172 reliability for the customer service connection is enhanced. 174 As illustrated in Figure 2, in order to make use of both the fixed 175 access network and the 3G/4G cellular network, the CPE of the 176 customer should be connected to both networks. The customer traffic 177 may be routed over both these access networks simultaneously. The 178 network architecture proposed in Figure 2 is flexible and may be 179 extended to cover multiple access network combinations. To ensure 180 that existing services are not influenced by this architecture, 181 certain traffic (e.g., VoIP) must not be split over more than one 182 path to guarantee required performance. This traffic may be kept in 183 the fixed access network. 185 +----+ ------ 186 | | / \ 187 |HOST| +-----+ | Wireless +---\ 188 | * * | +-+ 3G/4G | \ ***** 189 +----+ WiFi| +-+ \ / ** ** 190 | | ------ * * 191 +----+ | CPE | * Internet * 192 | | | | ------ * * 193 |HOST+-----+ +-+ / \ ** ** 194 | |Wired| | +-+ | / ***** 195 +----+ +-----+ | Fixed +---/ 196 \ / 197 ------ 199 Figure 2: High Level Hybrid Access Scenario 201 4. Traffic Distribution Schemes 203 Two forwarding schemes can be applied to the hybrid access scenario 204 depicted in Figure 2, flow-based forwarding and packet-based 205 forwarding. 207 In flow-based forwarding, forwarding policies are specified at the 208 flow level. The customer traffic is classified in flows and each 209 flow is associated to a single forwarding path. Packets belonging to 210 a certain flow may be identified by their destination IP address, 211 source IP address, IP protocol type, destination port, and source 212 port (i.e., the 5-tuple), or by any other means. Upon receiving a 213 packet from a host, the CPE identifies the flow that the packet 214 belongs to and forwards the packet according to the policies 215 specified for such a flow (e.g., flow A is forwarded into the 3G/4G 216 network and flow B is forwarded into the fixed network, see 217 Figure 3). When one of the multiple heterogeneous access network 218 fails, the CPE MAY select to forward the host packets into other 219 available access networks. 221 It is easy for a CPE to forward the upstream traffic (from hosts to 222 the Internet) to pre-defined paths according to the flow based rules. 223 However, the CPE itself cannot decide the paths over which the 224 downstream traffic will be routed, as shown in Figure 7. Deploying a 225 Bundling Gateway (see Figure 8) at the Internet side will resolve 226 this problem. The BGW may apply the same flows classification rules 227 of the CPE and forward the downstream traffic to the proper access 228 network (see Figure 5). In addition, tunneling or NAT technologies 229 in the CPE (e.g., NAT66 on the CPE, or NAT deployed after the CPE in 230 the 3G/4G network or in the fixed network, see Figure 4) may help to 231 solve this problem. 233 ------ 234 / \ 235 +-----+ | Wireless +---\ 236 | +---+ 3G/4G | \ ***** 237 +----+ | =======================>** ** 238 | ============= \ ------ / * * 239 |HOST+-----+ CPE | * Internet * 240 | ............. / ------ \ * * 241 +----+ | .......................>** ** 242 | +---+ | / ***** 243 +-----+ | Fixed +---/ 244 \ / 245 ------ 247 Figure 3: Flow-Based Forwarding-Upstream 249 Public IPv6 Prx1 250 / ------ 251 / / \ 252 +-----+/ | Wireless +---\ 253 Local IPv6 Prx1| *---+ 3G/4G | \ ***** 254 +----+| | ========================** ** 255 | <*=========== \ ------ / * * 256 |HOST+-----+ CPE | * Internet * 257 | <*........... / ------ \ * * 258 +----+ \ | ........................** ** 259 Local IPv6 Prx2|NAT66*---+ | / ***** 260 +-----+\ | Fixed +---/ 261 \ \ / 262 \ ------ 263 Public IPv6 Prx2 265 Figure 4: Flow-Based Forwarding-Downstream Case 1 266 ------ 267 / \ 268 +-----+ | Wireless +---\ +-----+ 269 | +---+ 3G/4G | \| | ***** 270 +----+ | =======================| | ** ** 271 | <============ \ ------ / | | * * 272 |HOST+-----+ CPE | | BGW <=.=.= Internet * 273 | <............ / ------ \ | | * * 274 +----+ | .......................| | ** ** 275 | +---+ | /| | ***** 276 +-----+ | Fixed +---/ +-----+ 277 \ / 278 ------ 280 Figure 5: Flow-Based Forwarding-Downstream Case 2 282 In packet-based forwarding, forwarding policies are specified at the 283 packet level. Packets belonging to the same flow may be forwarded 284 over different paths (see Figure 6). 286 The packet-based forwarding enables a CPE to control the packet 287 distribution over different paths in a more flexible and more fine- 288 grained way. However, with the packet-based forwarding the packets 289 belonging to a same flow may reach their destination out of order. A 290 device (see the BGW in Figure 6) able to perform packets reordering 291 at the remote side may be required. In flow-based forwarding, the 292 out-of-order packet issue does not occur. 294 ------ 295 / \ 296 +-----+ | Wireless +----+ 297 | CPE +---+ 3G/4G | |BGW | ***** 298 +----+ | ......................... | ** ** 299 | | | . \ ------ / | . | * * 300 |HOST+-----+ . | . +--* Internet * 301 | <...........* / ------ \ | *.....>* * 302 +----+ | ......................... | ** ** 303 | +---+ | | | ***** 304 +-----+ | Fixed +---/+----+ 305 \ / 306 ------ 308 Figure 6: Packet-Based Forwarding 310 Flow-based forwarding is very similar to load balancing technologies, 311 and it is easy for operators to deploy. On the other side, the 312 static association of flows to specific paths is disadvantageous, 313 because the bandwidth consumption of each flow may change over time 314 and may be difficult to predict. Thus, it is difficult to guarantee 315 the traffic balance among the different paths over time. In 316 addition, in certain scenarios without a BGW, it may be difficult to 317 guarantee that the upstream and downstream packets within the same 318 flow are forwarded over the same path. Then it is difficult to 319 guarantee the service performance. 321 Packet-based forwarding leverages the smallest granularity in current 322 packet networks, so it provides the most flexible and fine-grained 323 way to use the available bandwidth. However, the reordering and 324 buffering issues may lead to scalability limits. It may cost more 325 for operators. 327 In this document, we do not conclude which one is the best. Both 328 distribution schemes can meet specific service requirements and be 329 relevant depending on the situation. The operators may evaluate the 330 cost and efficiency aspects of both schemes in order to choose the 331 best solution for their network. 333 5. Hybrid Access Architecture 335 Two high level hybrid access architectures (see Figure 2) enable a 336 CPE to use all available access networks simultaneously (i.e., 337 through flow-based distribution or/and packet-based distribution): 339 o CPE-only, without Bundling Gateway, as shown in Figure 7. In this 340 architecture, the CPE is the only entity performing traffic 341 distribution, based on pre-configured policies or on dynamic 342 configurations. This architecture cannot guarantee that the 343 downstream traffic is routed on the same path of the upstream 344 traffic and therefore it is useful mostly for redundancy only (see 345 Figure 3 and Figure 4). 347 This architecture is currently outside the scope of this document. 349 +----+ ------ 350 | | / \ 351 |HOST| +-----+ | Wireless +---\ 352 | * * | +-+ 3G/4G | \ ***** 353 +----+ WiFi| +-+ \ / ** ** 354 | | ------ * * 355 +----+ | CPE | * Internet * 356 | | | | ------ * * 357 |HOST+-----+ +-+ / \ ** ** 358 | |Wired| | +-+ | / ***** 359 +----+ +-----+ | Fixed +---/ 360 \ / 361 ------ 363 Figure 7: Hybrid Access Architecture without BGW 365 o CPE with Bundling Gateway, as shown in Figure 8. In this 366 architecture, a BGW function is deployed at the remote side of a 367 CPE, to ensure that the downstream traffic is routed on the same 368 path of the upstream traffic. An in-band control plane protocol 369 between the CPE and the BGW may be used to negotiate distribution 370 policies, such as flow-based distribution among policy different 371 interfaces, packets reordering for the packet-based distribution 372 scenario (see Figure 6), etc. This architecture is what we need 373 to consider in IETF. 375 Referring to Figure 3, a distribution policy for the CPE may specify 376 to forward upstream packets belonging to a certain flow over the 377 3G/4G network when the load of the fixed network reaches a pre- 378 specified threshold. If later enough bandwidth of the fixed network 379 becomes available, the CPE may switch back upstream packets to the 380 fixed network. The distribution policy should be defined by the 381 operators. Referring to Figure 6, the CPE and BGW can have 382 independent packet-based behavior. If operators desire only a subset 383 of flows to be distributed over multiple paths, the CPE and BGW will 384 use the in-band control plane protocol for negotiation. More 385 management policies should be negotiated, such as how to use the 386 access networks metrics (capability, state, etc.) to enable dynamic 387 traffic distribution policy adjustments, etc. 389 +----+ ------ 390 | | / \ 391 |HOST| +-----+ | Wireless +-----\+-----+ 392 | * * | +-+ 3G/4G | | | ***** 393 +----+ WiFi| +-+ \ / | | ** ** 394 | | ------ | | * * 395 +----+ | CPE | | BGW +---* Internet * 396 | | | | ------ | | * * 397 |HOST+-----+ +-+ / \ | | ** ** 398 | |Wired| | +-+ | | | ***** 399 +----+ +-----+ | Fixed +-----/+-----+ 400 \ / 401 ------ 403 Figure 8: Hybrid Access Architecture with BGW 405 In order to achieve the architecture shown in Figure 8, the data 406 plane should provide bundling functions. There could be two options, 407 one is the overlay solution via tunnels, where the hosts are agnostic 408 about access networks aggregation. The CPE and BGW rely on tunneling 409 to set-up the path via different access networks, as shown in 410 Figure 9. CPE should be able to distribute the traffic to the proper 411 tunnel based on the traffic distribution policy. Additionally, if 412 BGW function is located at the edge router of the access network 413 (e.g., P-GW in EPC or BNG), as shown in Figure 10, the CPE can set up 414 a tunnel in order to overlay one access network to another, and rely 415 on regular routing on the other side. 417 Tunnel 418 |==============================================| 419 | <............ LTE path ..................> | 420 <--->| <............ DSL path ..................> |<---> 421 |==============================================| ----- 422 +--+---+ Internet Connection +---+---+ / \ 423 | | | | |Internet| 424 | CPE | | BGW +--+ | 425 +-+--+-+ +---+---+ \ / 426 | | 4G Network | ----- 427 | | *......................... * | 428 | | < +------+ +------+ > | 429 | +--------+ +-------+ +-------------+ 430 | < |eNodeB| | EPC | > | 431 | < +------+ +------+ > | 432 | *..........................* | 433 | *......................... * | 434 | ( +------+ +------+ ) | 435 +-----------+ +-------+ +-------------+ 436 ( | AN | | SN | ) 437 ( +------+ +------+ ) 438 *..........................* 439 Fixed Network 440 Legend: 441 AN Access Node 442 SN Service Node 443 EPC Evolved Packet Core 445 Figure 9: Overlay 447 Tunnel for LTE Access 448 |==============================================| 449 | <............ LTE path ..................> | 450 --->|==============================================|<--- 451 | <------------------------------------------->| 452 | Fixed Routing | 453 | 4G Network | 454 | *......................... * | 455 +----+-+ < +------+ +------+ > | 456 | +-------+ +-------+ +------------+ | 457 | | < |eNodeB| | PGW | > | | ----- 458 | | < +------+ +------+ > ........|.|...* / \ 459 | CPE | *..........................* . +----+-+--+) 460 | | *............................. | |) | | 461 | | ( +------+ +------+ | BGW/ |) 462 | +-------+ +-------+ +-------| |--+ Internet| 463 | | ( | AN | | SN | | BNG |) 464 +------+ ( +------+ +------+ | |) \ / 465 *............................. +---- ----+) ----- 466 Fixed Network ..............* 468 Figure 10: Interworking 470 6. Requirements 472 On the client side, the CPE implements the bundling mechanism and 473 forwards the customer traffic among the available access networks on 474 a pre-selected granularity (i.e., per-flow or per-packet). On the 475 network side, a logical function BGW cooperates with the CPE. This 476 logical function can be co-located with the exiting service gateway, 477 such as PGW and BNG. 479 The HYA mechanism should meet the following requirements: 481 1. Bundling of Multiple Heterogeneous Access Networks: The CPE and 482 BGW should support the tunnel technologies on data plane to 483 support the proper traffic distribution scheme, per-flow or per- 484 packet. 486 2. In-band Control Plane between the RG and BGW: A control plane 487 between the RG and the BGW is needed for the negotiation about 488 the traffic distribution policy. For example, in the flow-based 489 distribution scenario, the BGW should configure the WTP with the 490 distribution policy for the identified flow. The access 491 connection metrics (capacity, state, etc.) can be obtained by the 492 in-band control plane and used as input to enable dynamic traffic 493 distribution policy adjustments. In the packet-based 494 distribution scenario, the measurement about the access metrics 495 may be used as input to calculate the buffering which decides the 496 subsequent actions. 498 3. Traffic Distribution Path Adjust Dynamically: In order to 499 guarantee that the cheapest path is used first, the CPE must use 500 the downstream and upstream fixed bandwidth first, periodically 501 check the free bandwidth, and notify the results to the BGW. 502 Based on the negotiation, BGW can adjust the threshold of the 503 fixed path and adapt the traffic forwarding path decision 504 dynamically. Additionally, Load-balance is use both accesses all 505 the time, balancing the traffic evenly or unevenly based on the 506 proportion of two access bandwidth, or balancing based on the 507 defined traffic policy. 509 4. Path Management: After successful authentication, the CPE needs 510 to negotiate with the BGW how to setup and manage the tunnels 511 dynamically through the available access network paths. 512 Additionally, the available paths may have different 513 characteristics in terms of bandwidth, delay, MTU, etc. A path 514 management function is therefore needed. 516 5. Backward Compatibility: In order to ensure that existing services 517 are not influenced by the HYA architecture, certain traffic types 518 must not be routed through the bundling heterogeneous access 519 networks, but directly over a specific interface. The 520 negotiation between CPE and BGW for this policy routing must be 521 defined. 523 6. Support both IPv4 and IPv6: IPv4 and IPv6 must be considered both 524 for customer traffic and transport infrastructure. 526 7. Gap Analysis 528 There are various technologies (e.g., MPTCP[RFC6182] and 529 MLPPP[RFC1990]) which enable simultaneous use of multiple data paths. 531 In MPTCP, the primary use case is supporting the simultaneous use of 532 multiple path between multihomed hosts or between hosts and server. 533 It needs to be analyzed to determine how it is impacted by non 534 transparent routing devices (i.e., middle boxes). MPTCP only support 535 TCP traffic. MPTCP does not support packet-based forwarding among 536 multiple paths. Moreover, only fair-share forwarding is supported by 537 MPTCP, therefore it does not support the traffic overflow function 538 specified in Section 6. For backward compatibility, MPTCP does not 539 recognize the IP layer information and consequently has issues in 540 supporting existing traffic unimpaired. 542 In MLPPP, the link-layer protocol (PPP[RFC1990]) is extended to 543 combine multiple PPP links. Its primary use scenario is to enable 544 fragmented protocol data units (PDU) on the link layer to be 545 transferred over multiple links. MLPPP can be used over L2TP for 546 data plane. In the control plane, there are still gaps. L2TP 547 control plane can not support the bundling action right now, for 548 example, traffic distribution configuration, tunnel management etc. 549 The control plane defined by IETF should satisfy the requirements 550 listed in Section 6. 552 8. Security Considerations 554 In this architecture, CPE and BGW can redirect the traffic while end 555 nodes (server and terminal) are not aware about the redirection. This 556 may result in man-in-the-middle attacks. So the system must have 557 strong authentication mechanisms (i.e., a CPE must be able to 558 authenticate the BGW, and vice versa). 560 9. Acknowledgements 562 The authors would like to thank Dennis Kusidlo and Pierrick Seite, 563 who gave valuable comments for this draft. 565 10. Normative References 567 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 568 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 569 August 1996. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 575 Iyengar, "Architectural Guidelines for Multipath TCP 576 Development", RFC 6182, March 2011. 578 Authors' Addresses 580 Nicolai Leymann 581 Deutsche Telekom AG 582 Winterfeldtstrasse 21-27 583 Berlin 10781 584 Germany 586 Phone: +49-170-2275345 587 Email: n.leymann@telekom.de 588 Cornelius Heidemann 589 Deutsche Telekom AG 590 Heinrich-Hertz-Strasse 3-7 591 Darmstadt 64295 592 Germany 594 Phone: +4961515812721 595 Email: heidemannc@telekom.de 597 Margaret Wesserman 598 Painless Security 600 Email: mrw@painless-security.com 602 Li Xue 603 Huawei 604 No. 156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan 605 Beijing, Haidian District 100095 606 China 608 Email: xueli@huawei.com 610 Mingui Zhang 611 Huawei 612 No. 156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan 613 Beijing, Haidian District 100095 614 China 616 Email: zhangmingui@huawei.com