idnits 2.17.1 draft-amend-tsvwg-multipath-framework-mpdccp-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 : ---------------------------------------------------------------------------- ** 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.) ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Tbd' is mentioned on line 266, but not defined == Unused Reference: 'I-D.ietf-quic-http' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'I-D.lhwxz-hybrid-access-network-architecture' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'I-D.muley-network-based-bonding-hybrid-access' is defined on line 283, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-18 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Amend 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational A. Brunstrom 5 Expires: September 12, 2019 A. Kassler 6 Karlstad University 7 V. Rakocevic 8 City University of London 9 March 11, 2019 11 IP compatible multipath framework for heterogeneous access networks 12 draft-amend-tsvwg-multipath-framework-mpdccp-00 14 Abstract 16 More and more of today's devices are multi-homing capable, in 17 particular 3GPP user equipment like smartphones. In the current 18 standardization of the next upcoming mobile network generation 5G 19 Rel. 16, this is especially targeted in the study group Access 20 Traffic Steering Switching Splitting [3GPP, TR 23.793]. ATSSS 21 describes the flexible selection or combination of 3GPP untrusted 22 access like Wi-Fi and cellular access, overcoming the single-access 23 limitation of today's devices and services. Another multi- 24 connectivity scenario is the Hybrid Access [draft-lhwxz-hybrid- 25 access-network-architecture, draft-muley-network-based-bonding- 26 hybrid-access], providing multiple access for CPEs, which extends the 27 traditional way of single access connectivity at home to dual- 28 connectivity over 3GPP and fixed access. A missing piece in the 29 ATSSS and Hybrid Access is the access and path measurement for 30 efficient and beneficial traffic steering decisions. This becomes 31 particularly important in heterogeneous access networks with a 32 multitude of volatile access paths. MP-TCP can be employed in such 33 scenarios and concerning the ATSSS, it is the agreed protocol for the 34 traffic splitting mode. A decision for MP-TCP though leaves the 35 increasing share of UDP in today's traffic mix (https://arxiv.org/ 36 abs/1801.05168) unconsidered. In this document, a network 37 architecture leveraging the MP-DCCP network protocol is proposed, 38 which enables above scenarios and address the formulated issues 39 either independent or complementary to MP-TCP. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 12, 2019. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 76 2. IP compatible multipath framework based on MP-DCCP . . . . . 3 77 3. Application and placement . . . . . . . . . . . . . . . . . . 5 78 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 81 7. Informative References . . . . . . . . . . . . . . . . . . . 6 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 Multi-connectivity access networks are evolving. Ongoing 87 standardization at 3GPP for 5G mobile networks [3GPP, TR 23.793] or 88 the so called Hybrid Access networks [draft-lhwxz-hybrid-access- 89 network-architecture, draft-muley-network-based-bonding-hybrid- 90 access] already provides or will provide in the near future the 91 ability for multi-connectivity to a broad mass. A superior 92 resilience against network outages, higher capacities and network 93 cost optimizations are only some of the reasons why it make sense to 94 introduce multi-connectivity. Since the multi-connectivity 95 architectures are almost mature, it requires network protocols 96 providing the technology to exploit multi-connectivity. In the 97 simplest case, multi-connectivity means load-balancing, distributing 98 individual flows over multiple paths to distribute the load. 99 However, this has no effect on resilience or capacity gain on those 100 load balanced individual flows. More complex are those scenarios 101 where an individual flow can be seamlessly shifted between multiple 102 paths or can even aggregate those paths for leveraging the sum 103 capacities. Like [3GPP, TR 23.793] this document refers to the three 104 distribution schemes Steering (load balancing), Switching (seamless 105 handover) and Splitting (capacity aggregation). 107 MP-TCP [RFC6824] is a protocol, which can be applied in the above 108 mentioned use cases and covers load-balancing, seamless communication 109 handover and also capacity aggregation. Further, it deals with 110 heterogeneous and volatile access networks, since it profits from the 111 TCP inherent congestion control. By design, MP-TCP is limited to TCP 112 services and excludes any other network protocol, in particular UDP. 113 For future multi-connectivity systems, it is not sufficient anymore 114 to rely on supporting only TCP. The increasing share of UPD traffic, 115 mainly impacted by the QUIC introduction, may significantly reduce 116 the share from TCP. It might be expected that with HTTP/3 carried 117 over QUIC [draft-ietf-quic-http], the previous strong dominance of 118 TCP will be challenged by UDP. 120 2. IP compatible multipath framework based on MP-DCCP 122 A new approach, which overcomes MP-TCP's restriction to TCP services 123 and providing IP compatibility, is depicted in Fig. 1. The 124 architecture employs MP-DCCP [draft mp-dccp] in combination with an 125 encapsulation scheme. For simplification, Fig. 1 assumes a traffic 126 direction from the left (sender) to the right (receiver) and requires 127 application in each direction for bi-directional transmission. The 128 architecture in Fig. 1 can replace or complement MP-TCP to reach IP 129 compatibility. 131 Service |<- MP-DCCP ->| Service 132 or Device or Device 133 +---------+ ___ +------+ DCCP Flow 1 +-------+ +---------+ 134 | | _ |Seq|| Path |--------------| Re- | _ | | 135 | Sender |___| \___˅__| | : | order |____/ |___|Receiver | 136 | | IP|_/ | Sched| : | | \_|IP | | 137 | | VNIF_in | uler |--------------| engine| VNIF_out | | 138 +---------+ +------+ DCCP Flow n +-------+ +---------+ 140 Figure 1: IP compatible multipath framework based on MP-DCCP 142 PDUs generated from the sender and travelling through the 143 architecture in Fig. 1 passes the components in the following order: 145 1. Sender: Generates any PDU based on the IP protocol. 147 2. VNIF_in: IP based Virtual Network Interface as entry point to the 148 MP-DCCP framework. A simple routing logic in front (between (1) 149 and (2)) can act as gatekeeper and decides upon redirecting 150 traffic through the VNIF or bypassing it. The VNIF adds an extra 151 IP layer to reach the multi-connectivity termination point. 153 3. Seq: Sequencing of in (2) passed PDUs depending on the incoming 154 order. Adds an incrementing number, which is later added to the 155 DCCP encapsulation in (4). 157 4. Path Scheduler: Decision logic for scheduling sequenced PDUs over 158 the individual connected DCCP flows for multipath transmission. 159 The path scheduler can use the information from the DCCP flows 160 (see (5)) inherent congestion control information like CWND, 161 packet loss, RTT, Jitter. After selection of a DCCP flow, the 162 PDU is encapsulated into the individual flow. Further 163 information, at least the sequencing, is added on top as DCCP 164 option. 166 5. DCCP Flow(s): Responsible to transmit the encapsulated PDUs to 167 the MP-DCCP exit point. 169 6. Reorder engine: Depending on the sequencing information of (3), a 170 re-assembly of the PDU stream can be applied. The strictness of 171 re-ordering shall be configurable up to no re-ordering. 173 7. VNIF_out: Releases PDUs that have passed the re-ordering engine 174 and strips the DCCP specific overhead. Again routing is 175 responsible to deliver the PDUs to the receiver based on the 176 destination information in the PDU. 178 8. Receiver: Receive the PDU as generated in (1). 180 The simple enclosing of the MP-DCCP with Virtual Network Interface 181 (VNIF) provides the IP compatibility. However, a service or protocol 182 classifier between sender and VNIF can reduce the scope to particular 183 traffic, e.g. UDP, by simple routing decisions. The MP-DCCP takes 184 over responsibility for the multi-path transfer of the traffic, which 185 is directed through the VNIF_in. For possible re-assembly operations 186 the IP packets are stamped with a continuously incremented stamped 187 sequence number. This is not a mandatory operation, but assumed 188 required in most seamless handover and capacity aggregation use 189 cases. The path scheduler decides for each IP packet which DCCP flow 190 is appropriate, based on a configurable decision logic and supported 191 by the congestion control information of the DCCP flows available for 192 transmission. A DCCP flow selection for a PDU leads to its 193 encapsulation into the respective DCCP flow and adding extra 194 information required for the multipath transmission, e.g. the 195 sequence number. Encapsulation also means, that to the original PDU 196 a DCCP and IP header is added to reach the multi-connectivity end- 197 point. When the encapsulated PDUs arrive at the multi-path 198 termination point, they are re-ordered depending on the carried 199 sequence number and a configurable logic. The re-ordering engine may 200 also include a logic in which packets are just forwarded (no re- 201 ordering). Re-ordering needs to be considered carefully since any 202 active intervention changes the latency responsiveness. The multi- 203 path termination is finally completed when the DCCP overhead is 204 stripped and the PDU leaves VNIF_out. Further routing depends again 205 on the IP layer of the original PDU. 207 3. Application and placement 209 The framework of Fig. 1 gives most flexibility in applying multipath 210 support in different architectures and allows MP-DCCP to be applied 211 at any place between sender and receiver. Fig2. to Fig. 5 gives an 212 impression about the universality which covers any imaginable 213 architecture. 215 Device Middlebox 1 Middlebox 2 Device 216 +------+ +-------------+ +------------+ +--------+ 217 |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver| 218 +------+ +-------------+ +------------+ +--------+ 220 Figure 2: Sender and receiver independent MP-DCCP 222 Device Middlebox Device 223 +----------------------+ +------------+ +--------+ 224 |Sender + MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver| 225 +----------------------+ +------------+ +--------+ 227 Figure 3: Sender integrated but receiver independent MP-DCCP 229 Device Middlebox Device 230 +------+ +-------------+ +-----------------------+ 231 |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit + Receiver| 232 +------+ +-------------+ +-----------------------+ 234 Figure 4: Sender independent and receiver integrated MP-DCCP 235 Device Device 236 +----------------------+ +-----------------------+ 237 |Sender + MP-DCCP entry| -> |MP-DCCP exit + Receiver| 238 +----------------------+ +-----------------------+ 240 Figure 5: Sender and receiver integrated MP-DCCP 242 4. Conclusion 244 The specified IP compatible multipath framework based on MP-DCCP in 245 this document comprises several benefits: 247 o Pure routing 249 o Inherent path estimation and measurement 251 o Imposes no reliability or in-order delivery 253 o Modular re-ordering 255 o Modular scheduling 257 o IP compatible 259 o Based on the standardized DCCP. 261 Middle-box traversing, when the framework is applied in uncontrolled 262 environments, is addressed in [RFC6733] and [draft u-dccp]. 264 5. Security Considerations 266 [Tbd] 268 6. Acknowledgments 270 7. Informative References 272 [I-D.ietf-quic-http] 273 Bishop, M., "Hypertext Transfer Protocol Version 3 274 (HTTP/3)", draft-ietf-quic-http-18 (work in progress), 275 January 2019. 277 [I-D.lhwxz-hybrid-access-network-architecture] 278 Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. 279 Zhang, "Hybrid Access Network Architecture", draft-lhwxz- 280 hybrid-access-network-architecture-02 (work in progress), 281 January 2015. 283 [I-D.muley-network-based-bonding-hybrid-access] 284 Muley, P., Henderickx, W., Geng, L., Liu, H., Cardullo, 285 L., Newton, J., Seo, S., Draznin, S., and B. Patil, 286 "Network based Bonding solution for Hybrid Access", draft- 287 muley-network-based-bonding-hybrid-access-03 (work in 288 progress), October 2018. 290 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 291 Ed., "Diameter Base Protocol", RFC 6733, 292 DOI 10.17487/RFC6733, October 2012, 293 . 295 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 296 "TCP Extensions for Multipath Operation with Multiple 297 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 298 . 300 Authors' Addresses 302 Markus Amend 303 Deutsche Telekom 304 T-Online-Allee 1 305 Darmstadt 306 Germany 308 Email: Markus.Amend@telekom.de 310 Anna Brunstrom 311 Karlstad University 312 Universitetsgatan 2 313 651 88 Karlstad 314 Sweden 316 Email: anna.brunstrom@kau.se 318 Andreas Kassler 319 Karlstad University 320 Universitetsgatan 2 321 651 88 Karlstad 322 Sweden 324 Email: andreas.kassler@kau.se 325 Veselin Rakocevic 326 City University of London 327 Northampton Square 328 London 329 United Kingdom 331 Email: veselin.rakocevic.1@city.ac.uk