idnits 2.17.1 draft-zhu-intarea-mams-user-protocol-08.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 : ---------------------------------------------------------------------------- ** There are 73 instances of too long lines in the document, the longest one being 52 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 304 has weird spacing: '...the convergen...' == Line 326 has weird spacing: '...ergence proto...' == Line 327 has weird spacing: '...ocesses the ...' == Line 1067 has weird spacing: '...the convergen...' == Line 1089 has weird spacing: '...ergence proto...' == (41 more instances...) -- The document date (October 1, 2019) is 1667 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'GRE2890' is defined on line 9365, but no explicit reference was found in the text == Unused Reference: 'LWIPEP' is defined on line 9372, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 9376, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTAREA J. Zhu 2 Internet Draft Intel 3 Intended status: Standards Track S. Seo 4 Expires: April 1,2020 Korea Telecom 5 S. Kanugovi 6 Nokia 7 S. Peng 8 Huawei 9 October 1, 2019 11 User-Plane Protocols for Multiple Access Management Service 12 draft-zhu-intarea-mams-user-protocol-08 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 1,2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 Today, a device can be simultaneously connected to multiple 55 communication networks based on different technology implementations 56 and network architectures like WiFi, LTE, and DSL. In such multi- 57 connectivity scenario, it is desirable to combine multiple access 58 networks or select the best one to improve quality of experience for 59 a user and improve overall network utilization and efficiency. This 60 document presents the u-plane protocols for a multi access 61 management services (MAMS) framework that can be used to flexibly 62 select the combination of uplink and downlink access and core 63 network paths having the optimal performance, and user plane 64 treatment for improving network utilization and efficiency and 65 enhanced quality of experience for user applications. 67 Table of Contents 69 1. Introduction...................................................3 70 2. Terminologies..................................................3 71 3. Conventions used in this document..............................3 72 4 MAMS User-Plane Protocols......................................4 73 4.1 MX Adaptation Sublayer...................................4 74 4.2 GMA-based MX Convergence Sublayer........................5 75 4.3 MPTCP-based MX Convergence Sublayer......................6 76 4.4 GRE as MX Convergence Sublayer...........................6 77 4.4.1 Transmitter Procedures.............................7 78 4.4.2 Receiver Procedures................................8 79 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 80 8 81 5. MX Convergence Control Message.................................8 82 5.1 Keep-Alive Message.......................................9 83 5.2 Probe Message............................................9 84 5.3 Packet Loss Report (PLR) Message........................10 85 5.4 First Sequence Number (FSN) Message.....................11 86 5.5 Coded MX SDU (CMS) Message..............................12 87 5.6 Traffic Splitting Update (TSU) Message..................13 88 5.7 Acknowledgement Message.................................14 89 6 Security Considerations.......................................14 90 7 IANA Considerations...........................................15 91 8 Contributing Authors..........................................15 92 9 References....................................................15 93 9.1 Normative References....................................15 94 9.2 Informative References..................................15 96 1. Introduction 98 Multi Access Management Service (MAMS) [MAMS] is a programmable 99 framework to select and configure network paths, as well as adapt to 100 dynamic network conditions, when multiple network connections can 101 serve a client device. It is based on principles of user plane 102 interworking that enables the solution to be deployed as an overlay 103 without impacting the underlying networks. 105 This document presents the u-plane protocols for enabling the MAMS 106 framework. It co-exists and complements the existing protocols by 107 providing a way to negotiate and configure the protocols based on 108 client and network capabilities. Further it allows exchange of 109 network state information and leveraging network intelligence to 110 optimize the performance of such protocols. An important goal for 111 MAMS is to ensure that there is minimal or no dependency on the 112 actual access technology of the participating links. This allows the 113 scheme to be scalable for addition of newer access technologies and 114 for independent evolution of the existing access technologies. 116 2. Terminologies 118 Anchor Connection: refers to the network path from the N-MADP to the 119 Application Server that corresponds to a specific IP anchor that has 120 assigned an IP address to the client. 122 Delivery Connection: refers to the network path from the N-MADP to 123 the C-MADP. 125 "Network Connection Manager" (NCM), "Client Connection Manager" 126 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 127 Access Data Proxy" (C-MADP) in this document are to be interpreted 128 as described in [MAMS]. 130 3. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 The terminologies "Network Connection Manager" (NCM), "Client 137 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 138 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 139 document are to be interpreted as described in [MAMS]. 141 4 MAMS User-Plane Protocols 143 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 144 +-----------------------------------------------------+ 145 | User Payload (e.g. IP PDU) | 146 |-----------------------------------------------------| 147 +--|-----------------------------------------------------|--+ 148 | |-----------------------------------------------------| | 149 | | Multi-Access (MX) Convergence Sublayer | | 150 | |-----------------------------------------------------| | 151 | |-----------------------------------------------------| | 152 | | MX Adaptation | MX Adaptation | MX Adaptation | | 153 | | Sublayer | Sublayer | Sublayer | | 154 | | (optional) | (optional) | (optional) | | 155 | |-----------------------------------------------------| | 156 | | Access #1 IP | Access #2 IP | Access #3 IP | | 157 | +-----------------------------------------------------+ | 158 +-----------------------------------------------------------+ 159 Figure 1: MAMS U-plane Protocol Stack 160 It consists of the following two Sublayers: 162 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 163 access specific tasks, e.g., access (path) selection, multi-link 164 (path) aggregation, splitting/reordering, lossless switching, 165 fragmentation, concatenation, keep-alive, and probing etc. 166 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 167 to handle tunneling, network layer security, and NAT. 169 The MX convergence sublayer operates on top of the MX adaptation 170 sublayer in the protocol stack. From the Transmitter perspective, a 171 User Payload (e.g. IP PDU) is processed by the convergence sublayer 172 first, and then by the adaptation sublayer before being transported 173 over a delivery access connection; from the Receiver perspective, an IP 174 packet received over a delivery connection is processed by the MX 175 adaptation sublayer first, and then by the MX convergence sublayer. 177 4.1 MX Adaptation Sublayer 179 The MX adaptation sublayer supports the following mechanisms and 180 protocols while transmitting user plane packets on the network path: 182 o UDP Tunneling: The user plane packets of the anchor connection can be 183 encapsulated in a UDP tunnel of a delivery connection between the N- 184 MADP and C-MADP. 186 o IPsec Tunneling: The user plane packets of the anchor connection are 187 sent through an IPsec tunnel of a delivery connection. 188 o Client Net Address Translation (NAT): The Client IP address of user 189 plane packet of the anchor connection is changed, and sent over a 190 delivery connection. 191 o Pass Through: The user plane packets are passing through without any 192 change over the anchor connection. 194 The MX adaptation sublayer also supports the following mechanisms and 195 protocols to ensure security of user plane packets over the network 196 path. 198 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 199 N-MADP and C-MADP on the network path that is considered untrusted. 200 o DTLS: If UDP tunneling is used on the network path that is considered 201 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 202 be used. 204 The Client NAT method is the most efficient due to no tunneling 205 overhead. It SHOULD be used if a delivery connection is "trusted" and 206 without NAT function on the path. 208 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 209 connection has a NAT function placed on the path. 211 4.2 GMA-based MX Convergence Sublayer 213 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 214 encapsulation [GMA]. Multiple access networks are combined into a 215 single IP connection. If NCM determines that N-MADP is to be 216 instantiated with GMA as the MX Convergence Protocol, it exchanges the 217 support of GMA convergence capability in the discovery and capability 218 exchange procedures [MAMS]. 220 +-----------------------------------------------------+ 221 | IP PDU | 222 |-----------------------------------------------------| 223 | GMA Convergence Sublayer | 224 |-----------------------------------------------------| 225 | MX Adaptation | MX Adaptation | MX Adaptation | 226 | Sublayer | Sublayer | Sublayer | 227 | (optional) | (optional) | (optional) | 228 |-----------------------------------------------------| 229 | Access #1 IP | Access #2 IP | Access #3 IP | 230 +-----------------------------------------------------+ 231 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 233 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 234 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 235 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 236 message [MAMS] is true, the "IP length" and "IP checksum" header fields 237 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 238 updated after adding or removing the GMA trailer in the convergence 239 sublayer. 241 +------------------------------------------------------+ 242 | IP hdr | IP payload | GMA Trailer | 243 +------------------------------------------------------+ 244 Figure 3: GMA PDU Format 246 4.3 MPTCP-based MX Convergence Sublayer 248 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 249 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 250 access networks are combined into a single MPTCP connection. Hence, no 251 new u-plane protocol or PDU format is needed in this case. 253 |-----------------------------------------------------| 254 | MPTCP | 255 |-----------------------------------------------------| 256 | TCP | TCP | TCP | 257 |-----------------------------------------------------| 258 | MX Adaptation | MX Adaptation | MX Adaptation | 259 | Sublayer | Sublayer | Sublayer | 260 | (optional) | (optional) | (optional) | 261 |-----------------------------------------------------| 262 | Access #1 IP | Access #2 IP | Access #3 IP | 263 +-----------------------------------------------------+ 264 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 265 Layer 267 If NCM determines that N-MADP is to be instantiated with MPTCP as the 268 MX Convergence Protocol, it exchanges the support of MPTCP capability 269 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 270 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 271 and aggregation over multiple delivery connections. 273 4.4 GRE as MX Convergence Sublayer 275 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 276 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 277 Convergence sub-layer" protocol. Multiple access networks are combined 278 into a single GRE connection. Hence, no new u-plane protocol or PDU 279 format is needed in this case. 281 +-----------------------------------------------------+ 282 | User Payload (e.g. IP PDU) | 283 |-----------------------------------------------------| 284 | GRE as MX Convergence Sublayer | 285 |-----------------------------------------------------| 286 | GRE Delivery Protocol (e.g. IP) | 287 |-----------------------------------------------------| 288 | MX Adaptation | MX Adaptation | MX Adaptation | 289 | Sublayer | Sublayer | Sublayer | 290 | (optional) | (optional) | (optional) | 291 |-----------------------------------------------------| 292 | Access #1 IP | Access #2 IP | Access #3 IP | 293 +-----------------------------------------------------+ 294 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 295 Layer 297 If NCM determines that N-MADP is to be instantiated with GRE as the MX 298 Convergence Protocol, it exchanges the support of GRE capability in the 299 discovery and capability exchange procedures [MAMS]. 301 4.4.1 Transmitter Procedures 303 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 304 the convergence protocol that transmits the GRE packets. The 305 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 306 with a GRE header and Delivery Protocol (e.g. IP) header to generate 307 the GRE Convergence PDU. 309 When IP is used as the GRE delivery protocol, the IP header information 310 (e.g. IP address) can be created using the IP header of the user 311 payload or a virtual IP address. The "Protocol Type" field of the 312 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 314 The GRE header fields are set as specified below, 316 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 317 to the value of Connection ID for the Anchor Connection associated 318 with the user payload or sets to 0xFFFF if no Anchor Connection ID 319 needs to be specified. 320 - All other fields in the GRE header including the remaining bits in 321 the key fields are set as per [GRE_2784][GRE_2890]. 323 4.4.2 Receiver Procedures 325 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 326 convergence protocol that receives the GRE packets. The receiver 327 processes the received packets per the GRE procedures [GRE_2784, 328 GRE_2890] and retrieves the GRE header. 330 - If the Receiver is an N-MADP instance, 331 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 332 interpreted as the Connection ID of Anchor Connection for the 333 user payload. This is used to identify the network path over 334 which the User Payload (GRE Payload) is to be transmitted. 335 - All other fields in the GRE header, including the remaining bits 336 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 338 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 339 present) before delivery over one of the network paths. 341 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 343 MAMS u-plane protocols support multiple combinations and instances of 344 user plane protocols to be used in the MX Adaptation and the 345 Convergence sublayers. 347 For example, one instance of the MX Convergence Layer can be MPTCP 348 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 349 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 350 set up for network paths considered as untrusted by the operator, to 351 protect the TCP subflow between client and MPTCP proxy traversing that 352 network path. 354 Each of the instances of MAMS user plane, i.e. combination of MX 355 Convergence and MX Adaptation layer protocols, can coexist 356 simultaneously and independently handle different traffic types. 358 5. MX Convergence Control Message 360 A UDP connection may be configured between C-MADP and N-MADP to 361 exchange control messages for keep-alive or path quality estimation. 362 The N-MADP end-point IP address and UDP port number of the UDP 363 connection is used to identify MX control PDU. Figure 6 shows the MX 364 control PDU format with the following fields: 366 o Type (1 Byte): the type of the MX control message 367 o CID (1 Byte): an unsigned integer to identify the anchor and 368 delivery connection of the MX control message 369 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 370 identify the anchor connection 371 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 372 identify the delivery connection 373 o MX Control Message (variable): the payload of the MX control 374 message 376 Figure 7 shows the MX convergence control protocol stack, and MX 377 control PDU goes through the MX adaptation sublayer the same way as MX 378 data PDU. 380 <----MX Control PDU Payload ---------------> 381 +------------------------------------------------------------------+ 382 | IP header | UDP Header| Type | CID | MX Control Message | 383 +------------------------------------------------------------------+ 384 Figure 6: MX Control PDU Format 386 |-----------------------------------------------------| 387 | MX Convergence Control Messages | 388 |-----------------------------------------------------| 389 | UDP/IP | 390 |-----------------------------------------------------| 391 | MX Adaptation | MX Adaptation | MX Adaptation | 392 | Sublayer | Sublayer | Sublayer | 393 | (optional) | (optional) | (optional) | 394 |-----------------------------------------------------| 395 | Access #1 IP | Access #2 IP | Access #3 IP | 396 +-----------------------------------------------------+ 397 Figure 7: MX Convergence Control Protocol Stack 399 5.1 Keep-Alive Message 401 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 402 out Keep-Alive message periodically over one or multiple delivery 403 connections, especially if UDP tunneling is used as the adaptation 404 method for the delivery connection with a NAT function on the path. 406 A Keep-Alive message is 6 Bytes long, and consists of the following 407 fields: 409 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 410 keep-alive message 411 o Timestamp (4 Bytes): the current value of the timestamp clock of 412 the sender in the unit of 100 microseconds. 414 5.2 Probe Message 416 The "Type" field is set to "1" for Probe messages. 418 N-MADP may send out the Probe message for path quality estimation. In 419 response, C-MADP may send back the ACK message. 421 A Probe message consists of the following fields: 423 o Probing Sequence Number (2 Bytes): the sequence number of the 424 Probe REQ message 425 o Probing Flag (1 Byte): 426 + Bit #0: a ACK flag to indicate if the ACK message is expected 427 (1) or not (0); 428 + Bit #1: a Probe Type flag to indicate if the Probe message is 429 sent during the initialization phase (0) when the network 430 path is not included for transmission of user data or the 431 active phase (1) when the network path is included for 432 transmission of user data; 433 + Bit #2: a bit flag to indicate the presence of the Reverse 434 Connection ID (R-CID) field. 435 + Bit #3~7: reserved 436 o Reverse Connection ID (1 Byte): the connection ID of the delivery 437 connection for sending out the ACK message on the reverse path 438 o Timestamp (4 Bytes): the current value of the timestamp clock of 439 the sender in the unit of 100 microseconds. 440 o Padding (variable) 442 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 443 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 444 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 445 ACK message is not expected. 447 If the "R-CID" field is not present but the Bit #0 of the "Probing 448 Flag" field is set to "1", the ACK message SHOULD be sent over the same 449 delivery connection as the Probe message. 451 The "Padding" field is used to control the length of Probe message. 453 5.3 Packet Loss Report (PLR) Message 455 The "Type" field is set to "2" for PLR messages. 457 C-MADP may send out the PLR messages to report lost MX SDU for example 458 during handover. In response, C-MADP may retransmit the lost MX SDU 459 accordingly. 461 A PLR message consists of the following fields: 463 o Connection ID (1 Byte): an unsigned integer to identify the anchor 464 connection which the ACK message is for; 466 o Traffic Class ID (1 Byte): an unsigned integer to identify the 467 traffic class of the anchor connection which the ACK message is 468 for; 469 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 470 that the sender of the PLR message is expecting 471 o Number of Loss Bursts (1 Byte) 472 For each loss burst, include the following 473 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 474 + Number of consecutive lost MX SDUs in the burst (1 Byte) 476 C-MADP N-MADP 477 | | 478 |<------------------ MX SDU (data packets)--------| 479 | | 480 +---------------------------------+ | 481 |Packet Loss detected | | 482 +---------------------------------+ | 483 | | 484 |----- PLR Message ------------------------------>| 485 |<-------------retransmit(lost)MX SDUs -----------| 487 Figure 8: MAMS Retransmission Procedure 489 Figure 8 shows the MAMS retransmission procedure in an example where 490 the lost packet is found and retransmitted. 492 5.4 First Sequence Number (FSN) Message 494 The "Type" field is set to "3" for FSN messages. 496 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 497 its buffer if a lost MX SDU is not found in the buffer after receiving 498 the PLR message from C-MADP. In response, C-MADP SHALL only report 499 packet loss with SN not smaller than FSN. 501 A FSN message consists of the following fields: 503 o Connection ID (1 Byte): an unsigned integer to identify the anchor 504 connection which the FSN message is for; 505 o Traffic Class ID (1 Byte): an unsigned integer to identify the 506 traffic class of the anchor connection which the FSN message is 507 for; 508 o First Sequence Number (4 Bytes): the sequence number (SN) of the 509 oldest MX SDU in the (retransmission) buffer of the sender of the 510 FSN message. 512 Figure 9 shows the MAMS retransmission procedure in an example where 513 the lost packet is not found. 515 C-MADP N-MADP 516 | | 517 |<------------------ MX SDU (data packets)--------| 518 | | 519 +---------------------------------+ | 520 |Packet Loss detected | | 521 +---------------------------------+ | 522 | | 523 |----- PLR Message ------------------------------>| 524 | +---------------------+ 525 | |Lost packet not found| 526 | +---------------------+ 527 |<-------------FSN message -----------------------| 529 Figure 9: MAMS Retransmission Procedure with FSN 531 5.5 Coded MX SDU (CMS) Message 533 The "Type" field is set to "4" for CMS messages. 535 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 536 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 537 [RLNC]. A coded MX SDU is generated by applying a network coding 538 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 539 fast recovery without retransmission if any of the MX SDUs is lost. 541 A Coded MX SDU message consists of the following fields: 543 o Connection ID (1 Byte): an unsigned integer to identify the anchor 544 connection of the coded MX SDU; 545 o Traffic Class ID (1 Byte): an unsigned integer to identify the 546 traffic class of the coded MX; 547 o Sequence Number (4 Bytes): the sequence number of the first 548 (uncoded) MX SDU used to generate the coded MX SDU. 549 o Fragmentation Control (FC) (1 Byte): to provide necessary 550 information for re-assembly, only needed if the coded MX SDU is 551 too long to transport in a single MX control PDU. 552 o N (1 Byte): the number of consecutive MX SDUs used to generate the 553 coded MX SDU 554 o K (1 Byte): the length (in terms of bits) of the coding 555 coefficient field 556 o Coding Coefficient ( N x K / 8 Bytes) 557 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 558 + padding 559 o Coded MX SDU (variable): the coded MX SDU 561 If K = 0, the simple XOR method is used to generate the Coded MX SDU 562 from N consecutive uncoded MX SDUs, and the a(i) fields are not 563 included in the message. 565 If the coded MX SDU is too long, it can be fragmented, and transported 566 by multiple MX control PDUs. The N, K, and a(i) fields are only 567 included in the MX PDU carrying the first fragment of the coded MX SDU. 569 C-MADP N-MADP 570 | | 571 |<------------------ MX SDU #1 -------------------| 572 | lost<-------- MX SDU #2 -------------------| 573 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 574 +----------------------+ | 575 | MX SDU #2 recovered | | 576 +----------------------+ | 577 | | 579 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 581 5.6 Traffic Splitting Update (TSU) Message 583 The "Type" field is set to "5" for TSU messages. 585 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 586 traffic splitting configuration has changed. 588 A TSU message consists of the following fields: 590 o Connection ID (1 Byte): an unsigned integer to identify the anchor 591 connection; 592 o Traffic Class ID (1 Byte): an unsigned integer to identify the 593 traffic class; 594 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 595 message. 596 o Flags (1 Byte) 597 + Bit #0: a Reverse Path bit flag to indicate if the traffic 598 splitting configuration is for the reverse path (1) or not 599 (0); 600 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 601 used in traffic splitting 602 + Others: reserved. 603 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 605 + StartSN (4 Bytes): the sequence number of the first MX SDU 606 using the traffic splitting configuration provided by the TSU 607 message 608 + L (1 Byte): the traffic splitting burst size 609 + K(i): the traffic splitting threshold of the i-th delivery 610 connection, where connections are ordered according to their 611 Connection ID. 613 Let's use f(x) to denote the traffic splitting function, which maps a 614 MX SDU Sequence Number "x" to the i-th delivery connection. 616 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 618 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 620 N is the total number of connections for delivering a data flow, 621 identified by (anchor) Connection ID and Traffic Class ID. 623 When the bit-reversal bit is set to 1, the burst size L MUST be a power 624 of 2, and the traffic splitting function is 626 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 628 Wherein F(.) is the bit reversal function [BITR] of the input variable. 630 5.7 Acknowledgement Message 632 The "Type" field is set to "6" for ACK messages. 634 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 635 successful reception of a PLR, FSN, or TSU message. 637 C-MADP SHOULD send out the ACK message in response to a Probe message 638 with the ACK flag set to "1". 640 The ACK message consists of the following fields: 642 o Acknowledgment Number (2 Bytes): the sequence number of the 643 received message. 644 o Timestamp (4 Bytes): the current value of the timestamp clock of 645 the sender in the unit of 100 microseconds. 647 6 Security Considerations 649 User data in MAMS framework rely on the security of the underlying 650 network transport paths. When this cannot be assumed, NCM configures 651 use of appropriate protocols for security, e.g. IPsec [RFC4301] 652 [RFC3948], DTLS [RFC6347]. 654 7 IANA Considerations 656 This draft makes no requests of IANA. 658 8 Contributing Authors 660 The editors gratefully acknowledge the following additional 661 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 662 Pentakota/Nokia. 664 9 References 666 9.1 Normative References 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, March 1997. 671 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 672 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 673 December 2005, . 675 9.2 Informative References 677 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 678 Security Version 1.2", RFC 6347, January 2012, 679 . 681 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 682 Kivinen, "Internet Key Exchange Protocol Version 2 683 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 684 2014, . 686 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 687 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 688 3948, DOI 10.17487/RFC3948, January 2005, . 691 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 692 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 693 mechanism-02 695 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 696 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 697 plain-mode-09.txt 699 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 700 Access Management Protocol", 701 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 702 protocol-03 704 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 705 Multi-Access Convergence", 706 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 708 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 709 (GRE)", RFC 2784 March 2000, . 712 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 713 RFC 2890 September 2000, . 716 [IANA] https://www.iana.org/assignments/protocol- 717 numbers/protocol-numbers.xhtml 719 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 720 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 721 Tunnel (LWIP) encapsulation; Protocol specification" 723 [RFC791] Internet Protocol, September 1981 725 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 726 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 727 IEEE Access, 2017 729 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 730 arXiv:1212.2291, 2012 732 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 733 Symbol Representation, https://www.ietf.org/id/draft- 734 heide-nwcrg-rlnc-00.txt 736 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 737 38 (1): 1-26, 1996. 739 Authors' Addresses 741 Jing Zhu 743 Intel 745 Email: jing.z.zhu@intel.com 746 SungHoon Seo 748 Korea Telecom 750 Email: sh.seo@kt.com 752 Satish Kanugovi 754 Nokia 756 Email: satish.k@nokia.com 758 Shuping Peng 760 Huawei 762 Email: pengshuping@huawei.com 764 INTAREA J. Zhu 765 Internet Draft Intel 766 Intended status: Standards Track S. Seo 767 Expires: April 1,2020 Korea Telecom 768 S. Kanugovi 769 Nokia 770 S. Peng 771 Huawei 772 October 1, 2019 774 User-Plane Protocols for Multiple Access Management Service 775 draft-zhu-intarea-mams-user-protocol-07 777 Status of this Memo 779 This Internet-Draft is submitted in full conformance with the 780 provisions of BCP 78 and BCP 79. 782 Internet-Drafts are working documents of the Internet Engineering 783 Task Force (IETF), its areas, and its working groups. Note that 784 other groups may also distribute working documents as Internet- 785 Drafts. 787 Internet-Drafts are draft documents valid for a maximum of six 788 months and may be updated, replaced, or obsoleted by other documents 789 at any time. It is inappropriate to use Internet-Drafts as 790 reference material or to cite them other than as "work in progress." 792 The list of current Internet-Drafts can be accessed at 793 http://www.ietf.org/ietf/1id-abstracts.txt 795 The list of Internet-Draft Shadow Directories can be accessed at 796 http://www.ietf.org/shadow.html 798 This Internet-Draft will expire on April 1,2020. 800 Copyright Notice 802 Copyright (c) 2019 IETF Trust and the persons identified as the 803 document authors. All rights reserved. 805 This document is subject to BCP 78 and the IETF Trust's Legal 806 Provisions Relating to IETF Documents 807 (http://trustee.ietf.org/license-info) in effect on the date of 808 publication of this document. Please review these documents 809 carefully, as they describe your rights and restrictions with 810 respect to this document. Code Components extracted from this 811 document must include Simplified BSD License text as described in 812 Section 4.e of the Trust Legal Provisions and are provided without 813 warranty as described in the Simplified BSD License. 815 Abstract 817 Today, a device can be simultaneously connected to multiple 818 communication networks based on different technology implementations 819 and network architectures like WiFi, LTE, and DSL. In such multi- 820 connectivity scenario, it is desirable to combine multiple access 821 networks or select the best one to improve quality of experience for 822 a user and improve overall network utilization and efficiency. This 823 document presents the u-plane protocols for a multi access 824 management services (MAMS) framework that can be used to flexibly 825 select the combination of uplink and downlink access and core 826 network paths having the optimal performance, and user plane 827 treatment for improving network utilization and efficiency and 828 enhanced quality of experience for user applications. 830 Table of Contents 832 1. Introduction...................................................3 833 2. Terminologies.................................................34 834 3. Conventions used in this document.............................34 835 4 MAMS User-Plane Protocols......................................4 836 4.1 MX Adaptation Sublayer..................................45 837 4.2 GMA-based MX Convergence Sublayer.......................56 838 4.3 MPTCP-based MX Convergence Sublayer......................6 839 4.4 GRE as MX Convergence Sublayer..........................67 840 4.4.1 Transmitter Procedures............................78 841 4.4.2 Receiver Procedures................................8 842 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 843 8 844 5. MX Convergence Control Message................................89 845 5.1 Keep-Alive Message.....................................910 846 5.2 Probe Message..........................................910 847 5.3 Packet Loss Report (PLR) Message......................1011 848 5.4 First Sequence Number (FSN) Message...................1112 849 5.5 Coded MX SDU (CMS) Message..............................12 850 5.6 Traffic Splitting Update (TSU) Message................1314 851 5.7 Acknowledgement Message...............................1415 852 6 Security Considerations.....................................1415 853 7 IANA Considerations...........................................15 854 8 Contributing Authors..........................................15 855 9 References....................................................15 856 9.1 Normative References....................................15 857 9.2 Informative References................................1516 859 1. Introduction 861 Multi Access Management Service (MAMS) [MAMS] is a programmable 862 framework to select and configure network paths, as well as adapt to 863 dynamic network conditions, when multiple network connections can 864 serve a client device. It is based on principles of user plane 865 interworking that enables the solution to be deployed as an overlay 866 without impacting the underlying networks. 868 This document presents the u-plane protocols for enabling the MAMS 869 framework. It co-exists and complements the existing protocols by 870 providing a way to negotiate and configure the protocols based on 871 client and network capabilities. Further it allows exchange of 872 network state information and leveraging network intelligence to 873 optimize the performance of such protocols. An important goal for 874 MAMS is to ensure that there is minimal or no dependency on the 875 actual access technology of the participating links. This allows the 876 scheme to be scalable for addition of newer access technologies and 877 for independent evolution of the existing access technologies. 879 2. Terminologies 881 Anchor Connection: refers to the network path from the N-MADP to the 882 Application Server that corresponds to a specific IP anchor that has 883 assigned an IP address to the client. 885 Delivery Connection: refers to the network path from the N-MADP to 886 the C-MADP. 888 "Network Connection Manager" (NCM), "Client Connection Manager" 889 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 890 Access Data Proxy" (C-MADP) in this document are to be interpreted 891 as described in [MAMS]. 893 3. Conventions used in this document 895 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 896 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 897 document are to be interpreted as described in [RFC2119]. 899 The terminologies "Network Connection Manager" (NCM), "Client 900 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 901 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 902 document are to be interpreted as described in [MAMS]. 904 4 MAMS User-Plane Protocols 906 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 907 +-----------------------------------------------------+ 908 | User Payload (e.g. IP PDU) | 909 |-----------------------------------------------------| 910 +--|-----------------------------------------------------|--+ 911 | |-----------------------------------------------------| | 912 | | Multi-Access (MX) Convergence Sublayer | | 913 | |-----------------------------------------------------| | 914 | |-----------------------------------------------------| | 915 | | MX Adaptation | MX Adaptation | MX Adaptation | | 916 | | Sublayer | Sublayer | Sublayer | | 917 | | (optional) | (optional) | (optional) | | 918 | |-----------------------------------------------------| | 919 | | Access #1 IP | Access #2 IP | Access #3 IP | | 920 | +-----------------------------------------------------+ | 921 +-----------------------------------------------------------+ 922 Figure 1: MAMS U-plane Protocol Stack 923 It consists of the following two Sublayers: 925 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 926 access specific tasks, e.g., access (path) selection, multi-link 927 (path) aggregation, splitting/reordering, lossless switching, 928 fragmentation, concatenation, keep-alive, and probing etc. 929 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 930 to handle tunneling, network layer security, and NAT. 932 The MX convergence sublayer operates on top of the MX adaptation 933 sublayer in the protocol stack. From the Transmitter perspective, a 934 User Payload (e.g. IP PDU) is processed by the convergence sublayer 935 first, and then by the adaptation sublayer before being transported 936 over a delivery access connection; from the Receiver perspective, an IP 937 packet received over a delivery connection is processed by the MX 938 adaptation sublayer first, and then by the MX convergence sublayer. 940 4.1 MX Adaptation Sublayer 942 The MX adaptation sublayer supports the following mechanisms and 943 protocols while transmitting user plane packets on the network path: 945 o UDP Tunneling: The user plane packets of the anchor connection can be 946 encapsulated in a UDP tunnel of a delivery connection between the N- 947 MADP and C-MADP. 949 o IPsec Tunneling: The user plane packets of the anchor connection are 950 sent through an IPsec tunnel of a delivery connection. 951 o Client Net Address Translation (NAT): The Client IP address of user 952 plane packet of the anchor connection is changed, and sent over a 953 delivery connection. 954 o Pass Through: The user plane packets are passing through without any 955 change over the anchor connection. 957 The MX adaptation sublayer also supports the following mechanisms and 958 protocols to ensure security of user plane packets over the network 959 path. 961 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 962 N-MADP and C-MADP on the network path that is considered untrusted. 963 o DTLS: If UDP tunneling is used on the network path that is considered 964 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 965 be used. 967 The Client NAT method is the most efficient due to no tunneling 968 overhead. It SHOULD be used if a delivery connection is "trusted" and 969 without NAT function on the path. 971 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 972 connection has a NAT function placed on the path. 974 4.2 GMA-based MX Convergence Sublayer 976 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 977 encapsulation [GMA]. Multiple access networks are combined into a 978 single IP connection. If NCM determines that N-MADP is to be 979 instantiated with GMA as the MX Convergence Protocol, it exchanges the 980 support of GMA convergence capability in the discovery and capability 981 exchange procedures [MAMS]. 983 +-----------------------------------------------------+ 984 | IP PDU | 985 |-----------------------------------------------------| 986 | GMA Convergence Sublayer | 987 |-----------------------------------------------------| 988 | MX Adaptation | MX Adaptation | MX Adaptation | 989 | Sublayer | Sublayer | Sublayer | 990 | (optional) | (optional) | (optional) | 991 |-----------------------------------------------------| 992 | Access #1 IP | Access #2 IP | Access #3 IP | 993 +-----------------------------------------------------+ 994 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 996 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 997 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 998 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 999 message [MAMS] is true, the "IP length" and "IP checksum" header fields 1000 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 1001 updated after adding or removing the GMA trailer in the convergence 1002 sublayer. 1004 +------------------------------------------------------+ 1005 | IP hdr | IP payload | GMA Trailer | 1006 +------------------------------------------------------+ 1007 Figure 3: GMA PDU Format 1009 4.3 MPTCP-based MX Convergence Sublayer 1011 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 1012 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 1013 access networks are combined into a single MPTCP connection. Hence, no 1014 new u-plane protocol or PDU format is needed in this case. 1016 |-----------------------------------------------------| 1017 | MPTCP | 1018 |-----------------------------------------------------| 1019 | TCP | TCP | TCP | 1020 |-----------------------------------------------------| 1021 | MX Adaptation | MX Adaptation | MX Adaptation | 1022 | Sublayer | Sublayer | Sublayer | 1023 | (optional) | (optional) | (optional) | 1024 |-----------------------------------------------------| 1025 | Access #1 IP | Access #2 IP | Access #3 IP | 1026 +-----------------------------------------------------+ 1027 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 1028 Layer 1030 If NCM determines that N-MADP is to be instantiated with MPTCP as the 1031 MX Convergence Protocol, it exchanges the support of MPTCP capability 1032 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 1033 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 1034 and aggregation over multiple delivery connections. 1036 4.4 GRE as MX Convergence Sublayer 1038 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 1039 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 1040 Convergence sub-layer" protocol. Multiple access networks are combined 1041 into a single GRE connection. Hence, no new u-plane protocol or PDU 1042 format is needed in this case. 1044 +-----------------------------------------------------+ 1045 | User Payload (e.g. IP PDU) | 1046 |-----------------------------------------------------| 1047 | GRE as MX Convergence Sublayer | 1048 |-----------------------------------------------------| 1049 | GRE Delivery Protocol (e.g. IP) | 1050 |-----------------------------------------------------| 1051 | MX Adaptation | MX Adaptation | MX Adaptation | 1052 | Sublayer | Sublayer | Sublayer | 1053 | (optional) | (optional) | (optional) | 1054 |-----------------------------------------------------| 1055 | Access #1 IP | Access #2 IP | Access #3 IP | 1056 +-----------------------------------------------------+ 1057 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 1058 Layer 1060 If NCM determines that N-MADP is to be instantiated with GRE as the MX 1061 Convergence Protocol, it exchanges the support of GRE capability in the 1062 discovery and capability exchange procedures [MAMS]. 1064 4.4.1 Transmitter Procedures 1066 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 1067 the convergence protocol that transmits the GRE packets. The 1068 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 1069 with a GRE header and Delivery Protocol (e.g. IP) header to generate 1070 the GRE Convergence PDU. 1072 When IP is used as the GRE delivery protocol, the IP header information 1073 (e.g. IP address) can be created using the IP header of the user 1074 payload or a virtual IP address. The "Protocol Type" field of the 1075 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 1077 The GRE header fields are set as specified below, 1079 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 1080 to the value of Connection ID for the Anchor Connection associated 1081 with the user payload or sets to 0xFFFF if no Anchor Connection ID 1082 needs to be specified. 1083 - All other fields in the GRE header including the remaining bits in 1084 the key fields are set as per [GRE_2784][GRE_2890]. 1086 4.4.2 Receiver Procedures 1088 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 1089 convergence protocol that receives the GRE packets. The receiver 1090 processes the received packets per the GRE procedures [GRE_2784, 1091 GRE_2890] and retrieves the GRE header. 1093 - If the Receiver is an N-MADP instance, 1094 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 1095 interpreted as the Connection ID of Anchor Connection for the 1096 user payload. This is used to identify the network path over 1097 which the User Payload (GRE Payload) is to be transmitted. 1098 - All other fields in the GRE header, including the remaining bits 1099 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 1101 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 1102 present) before delivery over one of the network paths. 1104 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 1106 MAMS u-plane protocols support multiple combinations and instances of 1107 user plane protocols to be used in the MX Adaptation and the 1108 Convergence sublayers. 1110 For example, one instance of the MX Convergence Layer can be MPTCP 1111 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 1112 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 1113 set up for network paths considered as untrusted by the operator, to 1114 protect the TCP subflow between client and MPTCP proxy traversing that 1115 network path. 1117 Each of the instances of MAMS user plane, i.e. combination of MX 1118 Convergence and MX Adaptation layer protocols, can coexist 1119 simultaneously and independently handle different traffic types. 1121 5. MX Convergence Control Message 1123 A UDP connection may be configured between C-MADP and N-MADP to 1124 exchange control messages for keep-alive or path quality estimation. 1125 The N-MADP end-point IP address and UDP port number of the UDP 1126 connection is used to identify MX control PDU. Figure 6 shows the MX 1127 control PDU format with the following fields: 1129 o Type (1 Byte): the type of the MX control message 1130 o CID (1 Byte): an unsigned integer to identify the anchor and 1131 delivery connection of the MX control message 1132 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 1133 identify the anchor connection 1134 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 1135 identify the delivery connection 1136 o MX Control Message (variable): the payload of the MX control 1137 message 1139 Figure 7 shows the MX convergence control protocol stack, and MX 1140 control PDU goes through the MX adaptation sublayer the same way as MX 1141 data PDU. 1143 <----MX Control PDU Payload ---------------> 1144 +------------------------------------------------------------------+ 1145 | IP header | UDP Header| Type | CID | MX Control Message | 1146 +------------------------------------------------------------------+ 1147 Figure 6: MX Control PDU Format 1149 |-----------------------------------------------------| 1150 | MX Convergence Control Messages | 1151 |-----------------------------------------------------| 1152 | UDP/IP | 1153 |-----------------------------------------------------| 1154 | MX Adaptation | MX Adaptation | MX Adaptation | 1155 | Sublayer | Sublayer | Sublayer | 1156 | (optional) | (optional) | (optional) | 1157 |-----------------------------------------------------| 1158 | Access #1 IP | Access #2 IP | Access #3 IP | 1159 +-----------------------------------------------------+ 1160 Figure 7: MX Convergence Control Protocol Stack 1162 5.1 Keep-Alive Message 1164 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 1165 out Keep-Alive message periodically over one or multiple delivery 1166 connections, especially if UDP tunneling is used as the adaptation 1167 method for the delivery connection with a NAT function on the path. 1169 A Keep-Alive message is 6 Bytes long, and consists of the following 1170 fields: 1172 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 1173 keep-alive message 1174 o Timestamp (4 Bytes): the current value of the timestamp clock of 1175 the sender in the unit of 100 microseconds. 1177 5.2 Probe Message 1179 The "Type" field is set to "1" for Probe messages. 1181 N-MADP may send out the Probe message for path quality estimation. In 1182 response, C-MADP may send back the ACK message. 1184 A Probe message consists of the following fields: 1186 o Probing Sequence Number (2 Bytes): the sequence number of the 1187 Probe REQ message 1188 o Probing Flag (1 Byte): 1189 + Bit #0: a ACK flag to indicate if the ACK message is expected 1190 (1) or not (0); 1191 + Bit #1: a Probe Type flag to indicate if the Probe message is 1192 sent during the initialization phase (0) when the network 1193 path is not included for transmission of user data or the 1194 active phase (1) when the network path is included for 1195 transmission of user data; 1196 + Bit #2: a bit flag to indicate the presence of the Reverse 1197 Connection ID (R-CID) field. 1198 + Bit #3~7: reserved 1199 o Reverse Connection ID (1 Byte): the connection ID of the delivery 1200 connection for sending out the ACK message on the reverse path 1201 o Timestamp (4 Bytes): the current value of the timestamp clock of 1202 the sender in the unit of 100 microseconds. 1203 o Padding (variable) 1205 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 1206 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 1207 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 1208 ACK message is not expected. 1210 If the "R-CID" field is not present but the Bit #0 of the "Probing 1211 Flag" field is set to "1", the ACK message SHOULD be sent over the same 1212 delivery connection as the Probe message. 1214 The "Padding" field is used to control the length of Probe message. 1216 5.3 Packet Loss Report (PLR) Message 1218 The "Type" field is set to "2" for PLR messages. 1220 C-MADP may send out the PLR messages to report lost MX SDU for example 1221 during handover. In response, C-MADP may retransmit the lost MX SDU 1222 accordingly. 1224 A PLR message consists of the following fields: 1226 o Connection ID (1 Byte): an unsigned integer to identify the anchor 1227 connection which the ACK message is for; 1229 o Traffic Class ID (1 Byte): an unsigned integer to identify the 1230 traffic class of the anchor connection which the ACK message is 1231 for; 1232 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 1233 that the sender of the PLR message is expecting 1234 o Number of Loss Bursts (1 Byte) 1235 For each loss burst, include the following 1236 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 1237 + Number of consecutive lost MX SDUs in the burst (1 Byte) 1239 C-MADP N-MADP 1240 | | 1241 |<------------------ MX SDU (data packets)--------| 1242 | | 1243 +---------------------------------+ | 1244 |Packet Loss detected | | 1245 +---------------------------------+ | 1246 | | 1247 |----- PLR Message ------------------------------>| 1248 |<-------------retransmit(lost)MX SDUs -----------| 1250 Figure 8: MAMS Retransmission Procedure 1252 Figure 8 shows the MAMS retransmission procedure in an example where 1253 the lost packet is found and retransmitted. 1255 5.4 First Sequence Number (FSN) Message 1257 The "Type" field is set to "3" for FSN messages. 1259 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 1260 its buffer if a lost MX SDU is not found in the buffer after receiving 1261 the PLR message from C-MADP. In response, C-MADP SHALL only report 1262 packet loss with SN not smaller than FSN. 1264 A FSN message consists of the following fields: 1266 o Connection ID (1 Byte): an unsigned integer to identify the anchor 1267 connection which the FSN message is for; 1268 o Traffic Class ID (1 Byte): an unsigned integer to identify the 1269 traffic class of the anchor connection which the FSN message is 1270 for; 1271 o First Sequence Number (4 Bytes): the sequence number (SN) of the 1272 oldest MX SDU in the (retransmission) buffer of the sender of the 1273 FSN message. 1275 Figure 9 shows the MAMS retransmission procedure in an example where 1276 the lost packet is not found. 1278 C-MADP N-MADP 1279 | | 1280 |<------------------ MX SDU (data packets)--------| 1281 | | 1282 +---------------------------------+ | 1283 |Packet Loss detected | | 1284 +---------------------------------+ | 1285 | | 1286 |----- PLR Message ------------------------------>| 1287 | +---------------------+ 1288 | |Lost packet not found| 1289 | +---------------------+ 1290 |<-------------FSN message -----------------------| 1292 Figure 9: MAMS Retransmission Procedure with FSN 1294 5.5 Coded MX SDU (CMS) Message 1296 The "Type" field is set to "4" for CMS messages. 1298 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 1299 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 1300 [RLNC]. A coded MX SDU is generated by applying a network coding 1301 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 1302 fast recovery without retransmission if any of the MX SDUs is lost. 1304 A Coded MX SDU message consists of the following fields: 1306 o Connection ID (1 Byte): an unsigned integer to identify the anchor 1307 connection of the coded MX SDU; 1308 o Traffic Class ID (1 Byte): an unsigned integer to identify the 1309 traffic class of the coded MX; 1310 o Sequence Number (4 Bytes): the sequence number of the first 1311 (uncoded) MX SDU used to generate the coded MX SDU. 1312 o Fragmentation Control (FC) (1 Byte): to provide necessary 1313 information for re-assembly, only needed if the coded MX SDU is 1314 too long to transport in a single MX control PDU. 1315 o N (1 Byte): the number of consecutive MX SDUs used to generate the 1316 coded MX SDU 1317 o K (1 Byte): the length (in terms of bits) of the coding 1318 coefficient field 1319 o Coding Coefficient ( N x K / 8 Bytes) 1320 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 1321 + padding 1322 o Coded MX SDU (variable): the coded MX SDU 1324 If K = 0, the simple XOR method is used to generate the Coded MX SDU 1325 from N consecutive uncoded MX SDUs, and the a(i) fields are not 1326 included in the message. 1328 If the coded MX SDU is too long, it can be fragmented, and transported 1329 by multiple MX control PDUs. The N, K, and a(i) fields are only 1330 included in the MX PDU carrying the first fragment of the coded MX SDU. 1332 C-MADP N-MADP 1333 | | 1334 |<------------------ MX SDU #1 -------------------| 1335 | lost<-------- MX SDU #2 -------------------| 1336 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 1337 +----------------------+ | 1338 | MX SDU #2 recovered | | 1339 +----------------------+ | 1340 | | 1342 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 1344 5.6 Traffic Splitting Update (TSU) Message 1346 The "Type" field is set to "5" for TSU messages. 1348 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 1349 traffic splitting configuration has changed. 1351 A TSU message consists of the following fields: 1353 o Connection ID (1 Byte): an unsigned integer to identify the anchor 1354 connection; 1355 o Traffic Class ID (1 Byte): an unsigned integer to identify the 1356 traffic class; 1357 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 1358 message. 1359 o Flags (1 Byte) 1360 + Bit #0: a Reverse Path bit flag to indicate if the traffic 1361 splitting configuration is for the reverse path (1) or not 1362 (0); 1363 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 1364 used in traffic splitting 1365 + Others: reserved. 1366 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 1368 + StartSN (4 Bytes): the sequence number of the first MX SDU 1369 using the traffic splitting configuration provided by the TSU 1370 message 1371 + L (1 Byte): the traffic splitting burst size 1372 + K(i): the traffic splitting threshold of the i-th delivery 1373 connection, where connections are ordered according to their 1374 Connection ID. 1376 Let's use f(x) to denote the traffic splitting function, which maps a 1377 MX SDU Sequence Number "x" to the i-th delivery connection. 1379 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 1381 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 1383 N is the total number of connections for delivering a data flow, 1384 identified by (anchor) Connection ID and Traffic Class ID. 1386 When the bit-reversal bit is set to 1, the burst size L MUST be a power 1387 of 2, and the traffic splitting function is 1389 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 1391 Wherein F(.) is the bit reversal function [BITR] of the input variable. 1393 5.7 Acknowledgement Message 1395 The "Type" field is set to "6" for ACK messages. 1397 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 1398 successful reception of a PLR, FSN, or TSU message. 1400 C-MADP SHOULD send out the ACK message in response to a Probe message 1401 with the ACK flag set to "1". 1403 The ACK message consists of the following fields: 1405 o Acknowledgment Number (2 Bytes): the sequence number of the 1406 received message. 1407 o Timestamp (4 Bytes): the current value of the timestamp clock of 1408 the sender in the unit of 100 microseconds. 1410 6 Security Considerations 1412 User data in MAMS framework rely on the security of the underlying 1413 network transport paths. When this cannot be assumed, NCM configures 1414 use of appropriate protocols for security, e.g. IPsec [RFC4301] 1415 [RFC3948], DTLS [RFC6347]. 1417 7 IANA Considerations 1419 This draft makes no requests of IANA. 1421 8 Contributing Authors 1423 The editors gratefully acknowledge the following additional 1424 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 1425 Pentakota/Nokia. 1427 9 References 1429 9.1 Normative References 1431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1432 Requirement Levels", BCP 14, RFC 2119, March 1997. 1434 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1435 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 1436 December 2005, . 1438 9.2 Informative References 1440 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1441 Security Version 1.2", RFC 6347, January 2012, 1442 . 1444 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1445 Kivinen, "Internet Key Exchange Protocol Version 2 1446 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1447 2014, . 1449 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1450 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 1451 3948, DOI 10.17487/RFC3948, January 2005, . 1454 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 1455 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 1456 mechanism-02 1458 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 1459 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 1460 plain-mode-09.txt 1462 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 1463 Access Management Protocol", 1464 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 1465 protocol-03 1467 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 1468 Multi-Access Convergence", 1469 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 1471 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 1472 (GRE)", RFC 2784 March 2000, . 1475 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 1476 RFC 2890 September 2000, . 1479 [IANA] https://www.iana.org/assignments/protocol- 1480 numbers/protocol-numbers.xhtml 1482 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 1483 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 1484 Tunnel (LWIP) encapsulation; Protocol specification" 1486 [RFC791] Internet Protocol, September 1981 1488 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 1489 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 1490 IEEE Access, 2017 1492 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 1493 arXiv:1212.2291, 2012 1495 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 1496 Symbol Representation, https://www.ietf.org/id/draft- 1497 heide-nwcrg-rlnc-00.txt 1499 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 1500 38 (1): 1-26, 1996. 1502 Authors' Addresses 1504 Jing Zhu 1506 Intel 1508 Email: jing.z.zhu@intel.com 1509 SungHoon Seo 1511 Korea Telecom 1513 Email: sh.seo@kt.com 1515 Satish Kanugovi 1517 Nokia 1519 Email: satish.k@nokia.com 1521 Shuping Peng 1523 Huawei 1525 Email: pengshuping@huawei.com 1527 INTAREA J. Zhu 1528 Internet Draft Intel 1529 Intended status: Standards Track S. Seo 1530 Expires: April 1,2020 Korea Telecom 1531 S. Kanugovi 1532 Nokia 1533 S. Peng 1534 Huawei 1535 October 1, 2019 1537 User-Plane Protocols for Multiple Access Management 1538 Service draft-zhu-intarea-mams-user-protocol-07 1540 Status of this Memo 1542 This Internet-Draft is submitted in full conformance with 1543 the provisions of BCP 78 and BCP 79. 1545 Internet-Drafts are working documents of the Internet 1546 Engineering Task Force (IETF), its areas, and its working 1547 groups. Note that other groups may also distribute 1548 working documents as Internet-Drafts. 1550 Internet-Drafts are draft documents valid for a maximum of 1551 six months and may be updated, replaced, or obsoleted by 1552 other documents at any time. It is inappropriate to use 1553 Internet-Drafts as reference material or to cite them 1554 other than as "work in progress." 1556 The list of current Internet-Drafts can be accessed at 1557 http://www.ietf.org/ietf/1id-abstracts.txt 1559 The list of Internet-Draft Shadow Directories can be 1560 accessed at http://www.ietf.org/shadow.html 1562 This Internet-Draft will expire on April 1,2020. 1564 Copyright Notice 1566 Copyright (c) 2019 IETF Trust and the persons identified 1567 as the document authors. All rights reserved. 1569 This document is subject to BCP 78 and the IETF Trust's 1570 Legal Provisions Relating to IETF Documents 1571 (http://trustee.ietf.org/license-info) in effect on the 1572 date of publication of this document. Please review these 1573 documents carefully, as they describe your rights and 1574 restrictions with respect to this document. Code 1575 Components extracted from this document must include 1576 Simplified BSD License text as described in Section 4.e of 1577 the Trust Legal Provisions and are provided without 1578 warranty as described in the Simplified BSD License. 1580 Abstract 1582 Today, a device can be simultaneously connected to 1583 multiple communication networks based on different 1584 technology implementations and network architectures like 1585 WiFi, LTE, and DSL. In such multi-connectivity scenario, 1586 it is desirable to combine multiple access networks or 1587 select the best one to improve quality of experience for a 1588 user and improve overall network utilization and 1589 efficiency. This document presents the u-plane protocols 1590 for a multi access management services (MAMS) framework 1591 that can be used to flexibly select the combination of 1592 uplink and downlink access and core network paths having 1593 the optimal performance, and user plane treatment for 1594 improving network utilization and efficiency and enhanced 1595 quality of experience for user applications. 1597 Table of Contents 1599 1. Introduction .......................................... 3 1600 2. Terminologies ......................................... 3 1601 3. Conventions used in this document ..................... 3 1602 4 MAMS User-Plane Protocols ............................. 4 1603 4.1 MX Adaptation Sublayer .......................... 5 1604 4.2 GMA-based MX Convergence Sublayer ............... 6 1605 4.3 MPTCP-based MX Convergence Sublayer ............. 7 1606 4.4 GRE as MX Convergence Sublayer .................. 8 1607 4.4.1 Transmitter Procedures .................... 8 1608 4.4.2 Receiver Procedures ....................... 9 1609 4.5 Co-existence of MX Adaptation and MX Convergence 1610 Sublayers ............................................. 9 1611 5. MX Convergence Control Message ....................... 10 1612 5.1 Keep-Alive Message ............................. 11 1613 5.2 Probe Message .................................. 11 1614 5.3 Packet Loss Report (PLR) Message ............... 12 1615 5.4 First Sequence Number (FSN) Message ............ 13 1616 5.5 Coded MX SDU (CMS) Message ..................... 14 1617 5.6 Traffic Splitting Update (TSU) Message ......... 16 1618 5.7 Acknowledgement Message ........................ 17 1619 6 Security Considerations .............................. 17 1620 7 IANA Considerations .................................. 17 1621 8 Contributing Authors ................................. 17 1622 9 References ........................................... 18 1623 9.1 Normative References ........................... 18 1624 9.2 Informative References ......................... 18 1626 1. Introduction 1628 Multi Access Management Service (MAMS) [MAMS] is a 1629 programmable framework to select and configure network 1630 paths, as well as adapt to dynamic network conditions, 1631 when multiple network connections can serve a client 1632 device. It is based on principles of user plane 1633 interworking that enables the solution to be deployed as 1634 an overlay without impacting the underlying networks. 1636 This document presents the u-plane protocols for enabling 1637 the MAMS framework. It co-exists and complements the 1638 existing protocols by providing a way to negotiate and 1639 configure the protocols based on client and network 1640 capabilities. Further it allows exchange of network state 1641 information and leveraging network intelligence to 1642 optimize the performance of such protocols. An important 1643 goal for MAMS is to ensure that there is minimal or no 1644 dependency on the actual access technology of the 1645 participating links. This allows the scheme to be scalable 1646 for addition of newer access technologies and for 1647 independent evolution of the existing access technologies. 1649 2. Terminologies 1651 Anchor Connection: refers to the network path from the N- 1652 MADP to the Application Server that corresponds to a 1653 specific IP anchor that has assigned an IP address to the 1654 client. 1656 Delivery Connection: refers to the network path from the 1657 N-MADP to the C-MADP. 1659 "Network Connection Manager" (NCM), "Client Connection 1660 Manager" (CCM), "Network Multi Access Data Proxy" (N- 1661 MADP), and "Client Multi Access Data Proxy" (C-MADP) in 1662 this document are to be interpreted as described in 1663 [MAMS]. 1665 3. Conventions used in this document 1667 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 1668 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 1669 and "OPTIONAL" in this document are to be interpreted as 1670 described in [RFC2119]. 1672 The terminologies "Network Connection Manager" (NCM), 1673 "Client Connection Manager" (CCM), "Network Multi Access 1674 Data Proxy" (N-MADP), and "Client Multi Access Data Proxy" 1675 (C-MADP) in this document are to be interpreted as 1676 described in [MAMS]. 1678 4 MAMS User-Plane Protocols 1680 Figure 1 shows the MAMS u-plane protocol stack as specified 1681 in [MAMS]. 1682 +----------------------------------------------- 1683 ------+ 1684 | User Payload (e.g. IP PDU) 1685 | 1686 |----------------------------------------------- 1687 ------| 1688 +--|----------------------------------------------- 1689 ------|--+ 1690 | |----------------------------------------------- 1691 ------| | 1692 | | Multi-Access (MX) Convergence Sublayer 1693 | | 1694 | |----------------------------------------------- 1695 ------| | 1696 | |----------------------------------------------- 1697 ------| | 1698 | | MX Adaptation | MX Adaptation | MX Adaptation 1699 | | 1700 | | Sublayer | Sublayer | Sublayer 1701 | | 1702 | | (optional) | (optional) | (optional) 1703 | | 1704 | |----------------------------------------------- 1705 ------| | 1706 | | Access #1 IP | Access #2 IP | Access #3 IP 1707 | | 1708 | +----------------------------------------------- 1709 ------+ | 1710 +-------------------------------------------------- 1711 ---------+ 1712 Figure 1: MAMS U-plane Protocol Stack 1713 It consists of the following two Sublayers: 1715 o Multi-Access (MX) Convergence Sublayer: This layer performs 1716 multi-access specific tasks, e.g., access (path) selection, 1717 multi-link (path) aggregation, splitting/reordering, 1718 lossless switching, fragmentation, concatenation, keep- 1719 alive, and probing etc. 1720 o Multi-Access (MX) Adaptation Sublayer: This layer performs 1721 functions to handle tunneling, network layer security, and 1722 NAT. 1724 The MX convergence sublayer operates on top of the MX 1725 adaptation sublayer in the protocol stack. From the 1726 Transmitter perspective, a User Payload (e.g. IP PDU) is 1727 processed by the convergence sublayer first, and then by the 1728 adaptation sublayer before being transported over a delivery 1729 access connection; from the Receiver perspective, an IP 1730 packet received over a delivery connection is processed by 1731 the MX adaptation sublayer first, and then by the MX 1732 convergence sublayer. 1734 4.1 MX Adaptation Sublayer 1736 The MX adaptation sublayer supports the following mechanisms 1737 and protocols while transmitting user plane packets on the 1738 network path: 1740 o UDP Tunneling: The user plane packets of the anchor 1741 connection can be encapsulated in a UDP tunnel of a 1742 delivery connection between the N-MADP and C-MADP. 1743 o IPsec Tunneling: The user plane packets of the anchor 1744 connection are sent through an IPsec tunnel of a delivery 1745 connection. 1746 o Client Net Address Translation (NAT): The Client IP address 1747 of user plane packet of the anchor connection is changed, 1748 and sent over a delivery connection. 1749 o Pass Through: The user plane packets are passing through 1750 without any change over the anchor connection. 1752 The MX adaptation sublayer also supports the following 1753 mechanisms and protocols to ensure security of user plane 1754 packets over the network path. 1756 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established 1757 between the N-MADP and C-MADP on the network path that is 1758 considered untrusted. 1760 o DTLS: If UDP tunneling is used on the network path that is 1761 considered "untrusted", DTLS (Datagram Transport Layer 1762 Security) [RFC6347] can be used. 1764 The Client NAT method is the most efficient due to no 1765 tunneling overhead. It SHOULD be used if a delivery 1766 connection is "trusted" and without NAT function on the path. 1768 The UDP or IPsec Tunnelling method SHOULD be used if a 1769 delivery connection has a NAT function placed on the path. 1771 4.2 GMA-based MX Convergence Sublayer 1773 Figure 2 shows the MAMS u-plane protocol stack based on 1774 trailer-based encapsulation [GMA]. Multiple access networks 1775 are combined into a single IP connection. If NCM determines 1776 that N-MADP is to be instantiated with GMA as the MX 1777 Convergence Protocol, it exchanges the support of GMA 1778 convergence capability in the discovery and capability 1779 exchange procedures [MAMS]. 1781 +-------------------------------------------------- 1782 ---+ 1783 | IP PDU 1784 | 1785 |-------------------------------------------------- 1786 ---| 1787 | GMA Convergence Sublayer 1788 | 1789 |-------------------------------------------------- 1790 ---| 1791 | MX Adaptation | MX Adaptation | MX Adaptation 1792 | 1793 | Sublayer | Sublayer | Sublayer 1794 | 1795 | (optional) | (optional) | (optional) 1796 | 1797 |-------------------------------------------------- 1798 ---| 1799 | Access #1 IP | Access #2 IP | Access #3 IP 1800 | 1801 +-------------------------------------------------- 1802 ---+ 1803 Figure 2: MAMS U-plane Protocol Stack with GMA as MX 1804 Convergence Layer 1806 Figure 3 shows the trailer-based Multi-Access (MX) PDU 1807 (Protocol Data Unit) format [GMA]. If the MX adaptation 1808 method is UDP tunneling and "MX header optimization" in the 1809 "MX_UP_Setup_Configuration_Request" message [MAMS] is true, 1810 the "IP length" and "IP checksum" header fields of the MX PDU 1811 SHOULD remain unchanged. Otherwise, they should be updated 1812 after adding or removing the GMA trailer in the convergence 1813 sublayer. 1815 +-------------------------------------------------- 1816 ----+ 1817 | IP hdr | IP payload | GMA 1818 Trailer | +--------------------- 1819 ---------------------------------+ 1820 Figure 3: GMA PDU Format 1822 4.3 MPTCP-based MX Convergence Sublayer 1824 Figure 4 shows the MAMS u-plane protocol stack based on 1825 MPTCP. Here, MPTCP is reused as the "MX Convergence Sublayer" 1826 protocol. Multiple access networks are combined into a single 1827 MPTCP connection. Hence, no new u-plane protocol or PDU 1828 format is needed in this case. 1830 |-----------------------------------------------------| 1831 | MPTCP | 1832 |-----------------------------------------------------| 1833 | TCP | TCP | TCP | 1834 |-----------------------------------------------------| 1835 | MX Adaptation | MX Adaptation | MX Adaptation | 1836 | Sublayer | Sublayer | Sublayer | 1837 | (optional) | (optional) | (optional) | 1838 |-----------------------------------------------------| 1839 | Access #1 IP | Access #2 IP | Access #3 IP | 1840 +-----------------------------------------------------+ 1841 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX 1842 Convergence Layer 1844 If NCM determines that N-MADP is to be instantiated with 1845 MPTCP as the MX Convergence Protocol, it exchanges the 1846 support of MPTCP capability in the discovery and capability 1847 exchange procedures [MAMS]. MPTCP proxy protocols 1848 [MPProxy][MPPlain] SHOULD be used to manage traffic steering 1849 and aggregation over multiple delivery connections. 1851 4.4 GRE as MX Convergence Sublayer 1853 Figure 5 shows the MAMS u-plane protocol stack based on GRE 1854 (Generic Routing Encapsulation) [GRE2784]. Here, GRE is 1855 reused as the "MX Convergence sub-layer" protocol. Multiple 1856 access networks are combined into a single GRE connection. 1857 Hence, no new u-plane protocol or PDU format is needed in 1858 this case. 1860 +-----------------------------------------------------+ 1861 | User Payload (e.g. IP PDU) | 1862 |-----------------------------------------------------| 1863 | GRE as MX Convergence Sublayer | 1864 |-----------------------------------------------------| 1865 | GRE Delivery Protocol (e.g. IP) 1866 | 1867 |-----------------------------------------------------| 1868 | MX Adaptation | MX Adaptation | MX Adaptation | 1869 | Sublayer | Sublayer | Sublayer | 1870 | (optional) | (optional) | (optional) | 1871 |-----------------------------------------------------| 1872 | Access #1 IP | Access #2 IP | Access #3 IP 1873 | 1874 +-----------------------------------------------------+ 1875 Figure 5: MAMS U-plane Protocol Stack with GRE as MX 1876 Convergence Layer 1878 If NCM determines that N-MADP is to be instantiated with GRE 1879 as the MX Convergence Protocol, it exchanges the support of 1880 GRE capability in the discovery and capability exchange 1881 procedures [MAMS]. 1883 4.4.1 Transmitter Procedures 1885 Transmitter is the N-MADP or C-MADP instance, instantiated 1886 with GRE as the convergence protocol that transmits the GRE 1887 packets. The Transmitter receives the User Payload (e.g. IP 1888 PDU), encapsulates it with a GRE header and Delivery Protocol 1889 (e.g. IP) header to generate the GRE Convergence PDU. 1891 When IP is used as the GRE delivery protocol, the IP header 1892 information (e.g. IP address) can be created using the IP 1893 header of the user payload or a virtual IP address. The 1894 "Protocol Type" field of the delivery header is set to 47 (or 1895 0X2F, i.e. GRE)[IANA]. 1897 The GRE header fields are set as specified below, 1898 - If the transmitter is a C-MADP instance, then sets the 1899 LSB 16 bits to the value of Connection ID for the Anchor 1900 Connection associated with the user payload or sets to 1901 0xFFFF if no Anchor Connection ID needs to be specified. 1902 - All other fields in the GRE header including the 1903 remaining bits in the key fields are set as per 1904 [GRE_2784][GRE_2890]. 1906 4.4.2 Receiver Procedures 1908 Receiver is the N-MADP or C-MADP instance, instantiated with 1909 GRE as the convergence protocol that receives the GRE 1910 packets. The receiver processes the received packets per the 1911 GRE procedures [GRE_2784, GRE_2890] and retrieves the GRE 1912 header. 1914 - If the Receiver is an N-MADP instance, 1915 o Unless the LSB 16 Bits of the Key field are 0xFFFF, 1916 they are interpreted as the Connection ID of Anchor 1917 Connection for the user payload. This is used to 1918 identify the network path over which the User 1919 Payload (GRE Payload) is to be transmitted. 1920 - All other fields in the GRE header, including the 1921 remaining bits in the Key fields, are processed as per 1922 [GRE_2784][GRE_2890]. 1924 The GRE Convergence PDU is passed onto the MX Adaptation 1925 Layer (if present) before delivery over one of the network 1926 paths. 1928 4.5 Co-existence of MX Adaptation and MX Convergence 1929 Sublayers 1931 MAMS u-plane protocols support multiple combinations and 1932 instances of user plane protocols to be used in the MX 1933 Adaptation and the Convergence sublayers. 1935 For example, one instance of the MX Convergence Layer can be 1936 MPTCP Proxy [MPProxy][MPPlain] and another instance can be 1937 Trailer-based. The MX Adaptation for each can be either UDP 1938 tunnel or IPsec. IPsec may be set up for network paths 1939 considered as untrusted by the operator, to protect the TCP 1940 subflow between client and MPTCP proxy traversing that 1941 network path. 1943 Each of the instances of MAMS user plane, i.e. combination of 1944 MX Convergence and MX Adaptation layer protocols, can coexist 1945 simultaneously and independently handle different traffic 1946 types. 1948 5. MX Convergence Control Message 1950 A UDP connection may be configured between C-MADP and N-MADP 1951 to exchange control messages for keep-alive or path quality 1952 estimation. The N-MADP end-point IP address and UDP port 1953 number of the UDP connection is used to identify MX control 1954 PDU. Figure 6 shows the MX control PDU format with the 1955 following fields: 1957 o Type (1 Byte): the type of the MX control message 1958 o CID (1 Byte): an unsigned integer to identify the anchor 1959 and delivery connection of the MX control message 1960 + Anchor Connection ID (MSB 4 Bits): an unsigned 1961 integer to identify the anchor connection 1962 + Delivery Connection ID (LSB 4 Bits): an unsigned 1963 integer to identify the delivery connection 1964 o MX Control Message (variable): the payload of the MX 1965 control message 1967 Figure 7 shows the MX convergence control protocol stack, and 1968 MX control PDU goes through the MX adaptation sublayer the 1969 same way as MX data PDU. 1971 <----MX Control PDU Payload --------- 1972 ------> 1973 +------------------------------------------------------------ 1974 ------+ 1975 | IP header | UDP Header| Type | CID | MX Control 1976 Message | +---------------------------- 1977 --------------------------------------+ 1978 Figure 6: MX Control PDU Format 1980 |-----------------------------------------------------| 1981 | MX Convergence Control Messages | 1982 |-----------------------------------------------------| 1983 | UDP/IP 1984 | 1985 |-----------------------------------------------------| 1986 | MX Adaptation | MX Adaptation | MX Adaptation | 1987 | Sublayer | Sublayer | Sublayer | 1988 | (optional) | (optional) | (optional) | 1989 |-----------------------------------------------------| 1990 | Access #1 IP | Access #2 IP | Access #3 IP 1991 | 1992 +-----------------------------------------------------+ 1993 Figure 7: MX Convergence Control Protocol Stack 1995 5.1 Keep-Alive Message 1997 The "Type" field is set to "0" for Keep-Alive messages. C- 1998 MADP may send out Keep-Alive message periodically over one or 1999 multiple delivery connections, especially if UDP tunneling is 2000 used as the adaptation method for the delivery connection 2001 with a NAT function on the path. 2003 A Keep-Alive message is 6 Bytes long, and consists of the 2004 following fields: 2006 o Keep-Alive Sequence Number (2 Bytes): the sequence 2007 number of the keep-alive message 2008 o Timestamp (4 Bytes): the current value of the timestamp 2009 clock of the sender in the unit of 100 microseconds. 2011 5.2 Probe Message 2013 The "Type" field is set to "1" for Probe messages. 2015 N-MADP may send out the Probe message for path quality 2016 estimation. In response, C-MADP may send back the ACK 2017 message. 2019 A Probe message consists of the following fields: 2021 o Probing Sequence Number (2 Bytes): the sequence number 2022 of the Probe REQ message 2023 o Probing Flag (1 Byte): 2024 + Bit #0: a ACK flag to indicate if the ACK message is 2025 expected (1) or not (0); 2026 + Bit #1: a Probe Type flag to indicate if the Probe 2027 message is sent during the initialization phase (0) 2028 when the network path is not included for 2029 transmission of user data or the active phase (1) 2030 when the network path is included for transmission 2031 of user data; 2032 + Bit #2: a bit flag to indicate the presence of the 2033 Reverse Connection ID (R-CID) field. 2034 + Bit #3~7: reserved 2035 o Reverse Connection ID (1 Byte): the connection ID of the 2036 delivery connection for sending out the ACK message on 2037 the reverse path 2039 o Timestamp (4 Bytes): the current value of the timestamp 2040 clock of the sender in the unit of 100 microseconds. 2041 o Padding (variable) 2043 The "R-CID" field is only present if both Bit #0 and Bit #2 2044 of the "Probing Flag" field are set to "1". Moreover, Bit #2 2045 of the "Probing Flag" field SHOULD be set to "0" if the Bit 2046 #0 is "0", indicating the ACK message is not expected. 2048 If the "R-CID" field is not present but the Bit #0 of the 2049 "Probing Flag" field is set to "1", the ACK message SHOULD be 2050 sent over the same delivery connection as the Probe message. 2052 The "Padding" field is used to control the length of Probe 2053 message. 2055 5.3 Packet Loss Report (PLR) Message 2057 The "Type" field is set to "2" for PLR messages. 2059 C-MADP may send out the PLR messages to report lost MX SDU 2060 for example during handover. In response, C-MADP may 2061 retransmit the lost MX SDU accordingly. 2063 A PLR message consists of the following fields: 2065 o Connection ID (1 Byte): an unsigned integer to identify 2066 the anchor connection which the ACK message is for; 2067 o Traffic Class ID (1 Byte): an unsigned integer to 2068 identify the traffic class of the anchor connection 2069 which the ACK message is for; 2070 o ACK number (4 Bytes): the next (in-order) sequence 2071 number (SN) that the sender of the PLR message is 2072 expecting 2073 o Number of Loss Bursts (1 Byte) 2074 For each loss burst, include the following 2075 + Sequence Number of the first lost MX SDU in a burst 2076 (4 Bytes) 2077 + Number of consecutive lost MX SDUs in the burst (1 2078 Byte) 2080 C-MADP 2081 N-MADP 2082 | 2083 | 2084 |<------------------ MX SDU (data packets)----- 2085 ---| 2086 | 2087 | 2088 +---------------------------------+ 2089 | 2090 |Packet Loss detected | 2091 | 2092 +---------------------------------+ 2093 | 2094 | 2095 | 2096 |----- PLR Message ---------------------------- 2097 -->| 2098 |<-------------retransmit(lost)MX SDUs -------- 2099 ---| 2101 Figure 8: MAMS Retransmission Procedure 2103 Figure 8 shows the MAMS retransmission procedure in an 2104 example where the lost packet is found and retransmitted. 2106 5.4 First Sequence Number (FSN) Message 2108 The "Type" field is set to "3" for FSN messages. 2110 N-MADP may send out the FSN messages to indicate the oldest 2111 MX SDU in its buffer if a lost MX SDU is not found in the 2112 buffer after receiving the PLR message from C-MADP. In 2113 response, C-MADP SHALL only report packet loss with SN not 2114 smaller than FSN. 2116 A FSN message consists of the following fields: 2118 o Connection ID (1 Byte): an unsigned integer to identify 2119 the anchor connection which the FSN message is for; 2120 o Traffic Class ID (1 Byte): an unsigned integer to 2121 identify the traffic class of the anchor connection 2122 which the FSN message is for; 2123 o First Sequence Number (4 Bytes): the sequence number 2124 (SN) of the oldest MX SDU in the (retransmission) buffer 2125 of the sender of the FSN message. 2127 Figure 9 shows the MAMS retransmission procedure in an 2128 example where the lost packet is not found. 2130 C-MADP 2131 N-MADP 2132 | 2133 | 2134 |<------------------ MX SDU (data packets)----- 2135 ---| 2136 | 2137 | 2138 +---------------------------------+ 2139 | 2140 |Packet Loss detected | 2141 | 2142 +---------------------------------+ 2143 | 2144 | 2145 | 2146 |----- PLR Message ---------------------------- 2147 -->| 2148 | +--------------- 2149 ------+ 2150 | |Lost packet not 2151 found| 2152 | +--------------- 2153 ------+ 2154 |<-------------FSN message -------------------- 2155 ---| 2157 Figure 9: MAMS Retransmission Procedure with FSN 2159 5.5 Coded MX SDU (CMS) Message 2161 The "Type" field is set to "4" for CMS messages. 2163 N-MADP (or C-MADP) may send out the CMS message to support 2164 downlink (or uplink) packet loss recovery through coding, 2165 e.g. [CRLNC], [CTCP], [RLNC]. A coded MX SDU is generated by 2166 applying a network coding algorithm to multiple consecutive 2167 (uncoded) MX SDUs, and it is used for fast recovery without 2168 retransmission if any of the MX SDUs is lost. 2170 A Coded MX SDU message consists of the following fields: 2172 o Connection ID (1 Byte): an unsigned integer to identify 2173 the anchor connection of the coded MX SDU; 2175 o Traffic Class ID (1 Byte): an unsigned integer to 2176 identify the traffic class of the coded MX; 2177 o Sequence Number (4 Bytes): the sequence number of the 2178 first (uncoded) MX SDU used to generate the coded MX 2179 SDU. 2180 o Fragmentation Control (FC) (1 Byte): to provide 2181 necessary information for re-assembly, only needed if 2182 the coded MX SDU is too long to transport in a single MX 2183 control PDU. 2184 o N (1 Byte): the number of consecutive MX SDUs used to 2185 generate the coded MX SDU 2186 o K (1 Byte): the length (in terms of bits) of the coding 2187 coefficient field 2188 o Coding Coefficient ( N x K / 8 Bytes) 2189 + a(i): the coding coefficient of the i-th (uncoded) 2190 MX SDU 2191 + padding 2192 o Coded MX SDU (variable): the coded MX SDU 2194 If K = 0, the simple XOR method is used to generate the Coded 2195 MX SDU from N consecutive uncoded MX SDUs, and the a(i) 2196 fields are not included in the message. 2198 If the coded MX SDU is too long, it can be fragmented, and 2199 transported by multiple MX control PDUs. The N, K, and a(i) 2200 fields are only included in the MX PDU carrying the first 2201 fragment of the coded MX SDU. 2203 C-MADP 2204 N-MADP 2205 | 2206 | 2207 |<------------------ MX SDU #1 ---------------- 2208 ---| 2209 | lost<-------- MX SDU #2 ---------------- 2210 ---| 2211 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)--- 2212 ---| 2213 +----------------------+ 2214 | 2215 | MX SDU #2 recovered | 2216 | 2217 +----------------------+ 2218 | 2219 | 2220 | 2222 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 2224 5.6 Traffic Splitting Update (TSU) Message 2226 The "Type" field is set to "5" for TSU messages. 2228 N-MADP (or C-MADP) may send out a TSU message if downlink (or 2229 uplink) traffic splitting configuration has changed. 2231 A TSU message consists of the following fields: 2233 o Connection ID (1 Byte): an unsigned integer to identify 2234 the anchor connection; 2235 o Traffic Class ID (1 Byte): an unsigned integer to 2236 identify the traffic class; 2237 o Sequence Number (2 Bytes): an unsigned integer to 2238 identify the TSU message. 2239 o Flags (1 Byte) 2240 + Bit #0: a Reverse Path bit flag to indicate if the 2241 traffic splitting configuration is for the reverse 2242 path (1) or not (0); 2243 + Bit #1: a Bit-Reversal bit flag to indicate if bit- 2244 reversal is used in traffic splitting 2245 + Others: reserved. 2246 o Traffic Splitting Configuration Parameters ( 5 + (N -1) 2247 Bytes): 2248 + StartSN (4 Bytes): the sequence number of the first 2249 MX SDU using the traffic splitting configuration 2250 provided by the TSU message 2251 + L (1 Byte): the traffic splitting burst size 2252 + K(i): the traffic splitting threshold of the i-th 2253 delivery connection, where connections are ordered 2254 according to their Connection ID. 2256 Let's use f(x) to denote the traffic splitting function, 2257 which maps a MX SDU Sequence Number "x" to the i-th delivery 2258 connection. 2260 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 2262 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 2264 N is the total number of connections for delivering a data 2265 flow, identified by (anchor) Connection ID and Traffic Class 2266 ID. 2268 When the bit-reversal bit is set to 1, the burst size L MUST 2269 be a power of 2, and the traffic splitting function is 2271 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < 2272 K[i] 2274 Wherein F(.) is the bit reversal function [BITR] of the input 2275 variable. 2277 5.7 Acknowledgement Message 2279 The "Type" field is set to "6" for ACK messages. 2281 C-MADP (or N-MADP) SHOULD send out the ACK message in 2282 response to the successful reception of a PLR, FSN, or TSU 2283 message. 2285 C-MADP SHOULD send out the ACK message in response to a Probe 2286 message with the ACK flag set to "1". 2288 The ACK message consists of the following fields: 2290 o Acknowledgment Number (2 Bytes): the sequence number of 2291 the received message. 2292 o Timestamp (4 Bytes): the current value of the timestamp 2293 clock of the sender in the unit of 100 microseconds. 2295 6 Security Considerations 2297 User data in MAMS framework rely on the security of the 2298 underlying network transport paths. When this cannot be 2299 assumed, NCM configures use of appropriate protocols for 2300 security, e.g. IPsec [RFC4301] [RFC3948], DTLS [RFC6347]. 2302 7 IANA Considerations 2304 This draft makes no requests of IANA. 2306 8 Contributing Authors 2308 The editors gratefully acknowledge the following additional 2309 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 2310 Pentakota/Nokia. 2312 9 References 2314 9.1 Normative References 2316 [RFC2119] Bradner, S., "Key words for use in RFCs to 2317 Indicate Requirement Levels", BCP 14, RFC 2119, 2318 March 1997. 2320 [RFC4301] Kent, S. and K. Seo, "Security Architecture for 2321 the Internet Protocol", RFC 4301, 2322 DOI10.17487/RFC4301, December 2005, 2323 . 2325 9.2 Informative References 2327 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram 2328 Transport Layer Security Version 1.2", RFC 6347, 2329 January 2012, . 2332 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., 2333 and T. Kivinen, "Internet Key Exchange Protocol 2334 Version 2 (IKEv2)", STD 79, RFC 7296, DOI 2335 10.17487/RFC7296, October 2014, . 2338 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, 2339 L., and M. Stenberg, "UDP Encapsulation of IPsec 2340 ESP Packets", RFC 3948, DOI 10.17487/RFC3948, 2341 January 2005, . 2344 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy 2345 mechanisms", https://tools.ietf.org/html/draft- 2346 wei-mptcp-proxy-mechanism-02 2348 [MPPlain] M. Boucadair et al, "An MPTCP Option for 2349 Network-Assisted MPTCP", 2350 https://www.ietf.org/id/draft-boucadair-mptcp- 2351 plain-mode-09.txt 2353 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, 2354 "Multiple Access Management Protocol", 2355 https://tools.ietf.org/html/draft-kanugovi- 2356 intarea-mams-protocol-03 2358 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for 2359 Generic Multi-Access Convergence", 2360 https://tools.ietf.org/html/draft-zhu-intarea- 2361 gma-01 2363 [GRE2784] D. Farinacci, et al., "Generic Routing 2364 Encapsulation (GRE)", RFC 2784 March 2000, 2365 . 2367 [GRE2890] G. Dommety, "Key and Sequence Number Extensions 2368 to GRE", RFC 2890 September 2000, 2369 . 2371 [IANA] https://www.iana.org/assignments/protocol- 2372 numbers/protocol-numbers.xhtml 2374 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial 2375 Radio Access (E-UTRA); LTE-WLAN Radio Level 2376 Integration Using Ipsec Tunnel (LWIP) 2377 encapsulation; Protocol specification" 2379 [RFC791] Internet Protocol, September 1981 2381 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. 2382 Caterpillar RLNC (CRLNC): A Practical Finite 2383 Sliding Window RLNC Approach, IEEE Access, 2017 2385 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 2386 arXiv:1212.2291, 2012 2388 [RLNC] J. Heide, et al. Random Linear Network Coding 2389 (RLNC)-Based Symbol Representation, 2390 https://www.ietf.org/id/draft-heide-nwcrg-rlnc- 2391 00.txt 2393 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM 2394 Review, 38 (1): 1-26, 1996. 2396 Authors' Addresses 2398 Jing Zhu 2400 Intel 2402 Email: jing.z.zhu@intel.com 2404 SungHoon Seo 2405 Korea Telecom 2407 Email: sh.seo@kt.com 2409 Satish Kanugovi 2411 Nokia 2413 Email: satish.k@nokia.com 2415 Shuping Peng 2417 Huawei 2419 Email: pengshuping@huawei.com 2421 INTAREA J. Zhu 2422 Internet Draft Intel 2423 Intended status: Standards Track S. Seo 2424 Expires: April 1,2020 Korea Telecom 2425 S. Kanugovi 2426 Nokia 2427 S. Peng 2428 Huawei 2429 October 1, 2019 2431 User-Plane Protocols for Multiple Access Management 2432 Service draft-zhu-intarea-mams-user-protocol-07 2434 Status of this Memo 2436 This Internet-Draft is submitted in full conformance with 2437 the provisions of BCP 78 and BCP 79. 2439 Internet-Drafts are working documents of the Internet 2440 Engineering Task Force (IETF), its areas, and its working 2441 groups. Note that other groups may also distribute 2442 working documents as Internet-Drafts. 2444 Internet-Drafts are draft documents valid for a maximum of 2445 six months and may be updated, replaced, or obsoleted by 2446 other documents at any time. It is inappropriate to use 2447 Internet-Drafts as reference material or to cite them 2448 other than as "work in progress." 2450 The list of current Internet-Drafts can be accessed at 2451 http://www.ietf.org/ietf/1id-abstracts.txt 2453 The list of Internet-Draft Shadow Directories can be 2454 accessed at http://www.ietf.org/shadow.html 2456 This Internet-Draft will expire on April 1,2020. 2458 Copyright Notice 2460 Copyright (c) 2019 IETF Trust and the persons identified 2461 as the document authors. All rights reserved. 2463 This document is subject to BCP 78 and the IETF Trust's 2464 Legal Provisions Relating to IETF Documents 2465 (http://trustee.ietf.org/license-info) in effect on the 2466 date of publication of this document. Please review these 2467 documents carefully, as they describe your rights and 2468 restrictions with respect to this document. Code 2469 Components extracted from this document must include 2470 Simplified BSD License text as described in Section 4.e of 2471 the Trust Legal Provisions and are provided without 2472 warranty as described in the Simplified BSD License. 2474 Abstract 2476 Today, a device can be simultaneously connected to 2477 multiple communication networks based on different 2478 technology implementations and network architectures like 2479 WiFi, LTE, and DSL. In such multi-connectivity scenario, 2480 it is desirable to combine multiple access networks or 2481 select the best one to improve quality of experience for a 2482 user and improve overall network utilization and 2483 efficiency. This document presents the u-plane protocols 2484 for a multi access management services (MAMS) framework 2485 that can be used to flexibly select the combination of 2486 uplink and downlink access and core network paths having 2487 the optimal performance, and user plane treatment for 2488 improving network utilization and efficiency and enhanced 2489 quality of experience for user applications. 2491 Table of Contents 2493 1. Introduction .......................................... 3 2494 2. Terminologies ......................................... 3 2495 3. Conventions used in this document ..................... 3 2496 4 MAMS User-Plane Protocols ............................. 4 2497 4.1 MX Adaptation Sublayer .......................... 5 2498 4.2 GMA-based MX Convergence Sublayer ............... 6 2499 4.3 MPTCP-based MX Convergence Sublayer ............. 7 2500 4.4 GRE as MX Convergence Sublayer .................. 8 2501 4.4.1 Transmitter Procedures .................... 8 2502 4.4.2 Receiver Procedures ....................... 9 2503 4.5 Co-existence of MX Adaptation and MX Convergence 2504 Sublayers ............................................. 9 2505 5. MX Convergence Control Message ....................... 10 2506 5.1 Keep-Alive Message ............................. 11 2507 5.2 Probe Message .................................. 11 2508 5.3 Packet Loss Report (PLR) Message ............... 12 2509 5.4 First Sequence Number (FSN) Message ............ 13 2510 5.5 Coded MX SDU (CMS) Message ..................... 14 2511 5.6 Traffic Splitting Update (TSU) Message ......... 16 2512 5.7 Acknowledgement Message ........................ 17 2513 6 Security Considerations .............................. 17 2514 7 IANA Considerations .................................. 17 2515 8 Contributing Authors ................................. 17 2516 9 References ........................................... 18 2517 9.1 Normative References ........................... 18 2518 9.2 Informative References ......................... 18 2520 1. Introduction 2522 Multi Access Management Service (MAMS) [MAMS] is a 2523 programmable framework to select and configure network 2524 paths, as well as adapt to dynamic network conditions, 2525 when multiple network connections can serve a client 2526 device. It is based on principles of user plane 2527 interworking that enables the solution to be deployed as 2528 an overlay without impacting the underlying networks. 2530 This document presents the u-plane protocols for enabling 2531 the MAMS framework. It co-exists and complements the 2532 existing protocols by providing a way to negotiate and 2533 configure the protocols based on client and network 2534 capabilities. Further it allows exchange of network state 2535 information and leveraging network intelligence to 2536 optimize the performance of such protocols. An important 2537 goal for MAMS is to ensure that there is minimal or no 2538 dependency on the actual access technology of the 2539 participating links. This allows the scheme to be scalable 2540 for addition of newer access technologies and for 2541 independent evolution of the existing access technologies. 2543 2. Terminologies 2545 Anchor Connection: refers to the network path from the N- 2546 MADP to the Application Server that corresponds to a 2547 specific IP anchor that has assigned an IP address to the 2548 client. 2550 Delivery Connection: refers to the network path from the 2551 N-MADP to the C-MADP. 2553 "Network Connection Manager" (NCM), "Client Connection 2554 Manager" (CCM), "Network Multi Access Data Proxy" (N- 2555 MADP), and "Client Multi Access Data Proxy" (C-MADP) in 2556 this document are to be interpreted as described in 2557 [MAMS]. 2559 3. Conventions used in this document 2561 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 2562 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 2563 and "OPTIONAL" in this document are to be interpreted as 2564 described in [RFC2119]. 2566 The terminologies "Network Connection Manager" (NCM), 2567 "Client Connection Manager" (CCM), "Network Multi Access 2568 Data Proxy" (N-MADP), and "Client Multi Access Data Proxy" 2569 (C-MADP) in this document are to be interpreted as 2570 described in [MAMS]. 2572 4 MAMS User-Plane Protocols 2574 Figure 1 shows the MAMS u-plane protocol stack as specified 2575 in [MAMS]. 2576 +----------------------------------------------- 2577 ------+ 2578 | User Payload (e.g. IP PDU) 2579 | 2580 |----------------------------------------------- 2581 ------| 2582 +--|----------------------------------------------- 2583 ------|--+ 2584 | |----------------------------------------------- 2585 ------| | 2586 | | Multi-Access (MX) Convergence Sublayer 2587 | | 2588 | |----------------------------------------------- 2589 ------| | 2590 | |----------------------------------------------- 2591 ------| | 2592 | | MX Adaptation | MX Adaptation | MX Adaptation 2593 | | 2594 | | Sublayer | Sublayer | Sublayer 2595 | | 2596 | | (optional) | (optional) | (optional) 2597 | | 2598 | |----------------------------------------------- 2599 ------| | 2600 | | Access #1 IP | Access #2 IP | Access #3 IP 2601 | | 2602 | +----------------------------------------------- 2603 ------+ | 2604 +-------------------------------------------------- 2605 ---------+ 2606 Figure 1: MAMS U-plane Protocol Stack 2607 It consists of the following two Sublayers: 2609 o Multi-Access (MX) Convergence Sublayer: This layer performs 2610 multi-access specific tasks, e.g., access (path) selection, 2611 multi-link (path) aggregation, splitting/reordering, 2612 lossless switching, fragmentation, concatenation, keep- 2613 alive, and probing etc. 2614 o Multi-Access (MX) Adaptation Sublayer: This layer performs 2615 functions to handle tunneling, network layer security, and 2616 NAT. 2618 The MX convergence sublayer operates on top of the MX 2619 adaptation sublayer in the protocol stack. From the 2620 Transmitter perspective, a User Payload (e.g. IP PDU) is 2621 processed by the convergence sublayer first, and then by the 2622 adaptation sublayer before being transported over a delivery 2623 access connection; from the Receiver perspective, an IP 2624 packet received over a delivery connection is processed by 2625 the MX adaptation sublayer first, and then by the MX 2626 convergence sublayer. 2628 4.1 MX Adaptation Sublayer 2630 The MX adaptation sublayer supports the following mechanisms 2631 and protocols while transmitting user plane packets on the 2632 network path: 2634 o UDP Tunneling: The user plane packets of the anchor 2635 connection can be encapsulated in a UDP tunnel of a 2636 delivery connection between the N-MADP and C-MADP. 2637 o IPsec Tunneling: The user plane packets of the anchor 2638 connection are sent through an IPsec tunnel of a delivery 2639 connection. 2640 o Client Net Address Translation (NAT): The Client IP address 2641 of user plane packet of the anchor connection is changed, 2642 and sent over a delivery connection. 2643 o Pass Through: The user plane packets are passing through 2644 without any change over the anchor connection. 2646 The MX adaptation sublayer also supports the following 2647 mechanisms and protocols to ensure security of user plane 2648 packets over the network path. 2650 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established 2651 between the N-MADP and C-MADP on the network path that is 2652 considered untrusted. 2654 o DTLS: If UDP tunneling is used on the network path that is 2655 considered "untrusted", DTLS (Datagram Transport Layer 2656 Security) [RFC6347] can be used. 2658 The Client NAT method is the most efficient due to no 2659 tunneling overhead. It SHOULD be used if a delivery 2660 connection is "trusted" and without NAT function on the path. 2662 The UDP or IPsec Tunnelling method SHOULD be used if a 2663 delivery connection has a NAT function placed on the path. 2665 4.2 GMA-based MX Convergence Sublayer 2667 Figure 2 shows the MAMS u-plane protocol stack based on 2668 trailer-based encapsulation [GMA]. Multiple access networks 2669 are combined into a single IP connection. If NCM determines 2670 that N-MADP is to be instantiated with GMA as the MX 2671 Convergence Protocol, it exchanges the support of GMA 2672 convergence capability in the discovery and capability 2673 exchange procedures [MAMS]. 2675 +-------------------------------------------------- 2676 ---+ 2677 | IP PDU 2678 | 2679 |-------------------------------------------------- 2680 ---| 2681 | GMA Convergence Sublayer 2682 | 2683 |-------------------------------------------------- 2684 ---| 2685 | MX Adaptation | MX Adaptation | MX Adaptation 2686 | 2687 | Sublayer | Sublayer | Sublayer 2688 | 2689 | (optional) | (optional) | (optional) 2690 | 2691 |-------------------------------------------------- 2692 ---| 2693 | Access #1 IP | Access #2 IP | Access #3 IP 2694 | 2695 +-------------------------------------------------- 2696 ---+ 2697 Figure 2: MAMS U-plane Protocol Stack with GMA as MX 2698 Convergence Layer 2700 Figure 3 shows the trailer-based Multi-Access (MX) PDU 2701 (Protocol Data Unit) format [GMA]. If the MX adaptation 2702 method is UDP tunneling and "MX header optimization" in the 2703 "MX_UP_Setup_Configuration_Request" message [MAMS] is true, 2704 the "IP length" and "IP checksum" header fields of the MX PDU 2705 SHOULD remain unchanged. Otherwise, they should be updated 2706 after adding or removing the GMA trailer in the convergence 2707 sublayer. 2709 +-------------------------------------------------- 2710 ----+ 2711 | IP hdr | IP payload | GMA 2712 Trailer | +--------------------- 2713 ---------------------------------+ 2714 Figure 3: GMA PDU Format 2716 4.3 MPTCP-based MX Convergence Sublayer 2718 Figure 4 shows the MAMS u-plane protocol stack based on 2719 MPTCP. Here, MPTCP is reused as the "MX Convergence Sublayer" 2720 protocol. Multiple access networks are combined into a single 2721 MPTCP connection. Hence, no new u-plane protocol or PDU 2722 format is needed in this case. 2724 |-----------------------------------------------------| 2725 | MPTCP | 2726 |-----------------------------------------------------| 2727 | TCP | TCP | TCP | 2728 |-----------------------------------------------------| 2729 | MX Adaptation | MX Adaptation | MX Adaptation | 2730 | Sublayer | Sublayer | Sublayer | 2731 | (optional) | (optional) | (optional) | 2732 |-----------------------------------------------------| 2733 | Access #1 IP | Access #2 IP | Access #3 IP | 2734 +-----------------------------------------------------+ 2735 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX 2736 Convergence Layer 2738 If NCM determines that N-MADP is to be instantiated with 2739 MPTCP as the MX Convergence Protocol, it exchanges the 2740 support of MPTCP capability in the discovery and capability 2741 exchange procedures [MAMS]. MPTCP proxy protocols 2742 [MPProxy][MPPlain] SHOULD be used to manage traffic steering 2743 and aggregation over multiple delivery connections. 2745 4.4 GRE as MX Convergence Sublayer 2747 Figure 5 shows the MAMS u-plane protocol stack based on GRE 2748 (Generic Routing Encapsulation) [GRE2784]. Here, GRE is 2749 reused as the "MX Convergence sub-layer" protocol. Multiple 2750 access networks are combined into a single GRE connection. 2751 Hence, no new u-plane protocol or PDU format is needed in 2752 this case. 2754 +-----------------------------------------------------+ 2755 | User Payload (e.g. IP PDU) | 2756 |-----------------------------------------------------| 2757 | GRE as MX Convergence Sublayer | 2758 |-----------------------------------------------------| 2759 | GRE Delivery Protocol (e.g. IP) 2760 | 2761 |-----------------------------------------------------| 2762 | MX Adaptation | MX Adaptation | MX Adaptation | 2763 | Sublayer | Sublayer | Sublayer | 2764 | (optional) | (optional) | (optional) | 2765 |-----------------------------------------------------| 2766 | Access #1 IP | Access #2 IP | Access #3 IP 2767 | 2768 +-----------------------------------------------------+ 2769 Figure 5: MAMS U-plane Protocol Stack with GRE as MX 2770 Convergence Layer 2772 If NCM determines that N-MADP is to be instantiated with GRE 2773 as the MX Convergence Protocol, it exchanges the support of 2774 GRE capability in the discovery and capability exchange 2775 procedures [MAMS]. 2777 4.4.1 Transmitter Procedures 2779 Transmitter is the N-MADP or C-MADP instance, instantiated 2780 with GRE as the convergence protocol that transmits the GRE 2781 packets. The Transmitter receives the User Payload (e.g. IP 2782 PDU), encapsulates it with a GRE header and Delivery Protocol 2783 (e.g. IP) header to generate the GRE Convergence PDU. 2785 When IP is used as the GRE delivery protocol, the IP header 2786 information (e.g. IP address) can be created using the IP 2787 header of the user payload or a virtual IP address. The 2788 "Protocol Type" field of the delivery header is set to 47 (or 2789 0X2F, i.e. GRE)[IANA]. 2791 The GRE header fields are set as specified below, 2792 - If the transmitter is a C-MADP instance, then sets the 2793 LSB 16 bits to the value of Connection ID for the Anchor 2794 Connection associated with the user payload or sets to 2795 0xFFFF if no Anchor Connection ID needs to be specified. 2796 - All other fields in the GRE header including the 2797 remaining bits in the key fields are set as per 2798 [GRE_2784][GRE_2890]. 2800 4.4.2 Receiver Procedures 2802 Receiver is the N-MADP or C-MADP instance, instantiated with 2803 GRE as the convergence protocol that receives the GRE 2804 packets. The receiver processes the received packets per the 2805 GRE procedures [GRE_2784, GRE_2890] and retrieves the GRE 2806 header. 2808 - If the Receiver is an N-MADP instance, 2809 o Unless the LSB 16 Bits of the Key field are 0xFFFF, 2810 they are interpreted as the Connection ID of Anchor 2811 Connection for the user payload. This is used to 2812 identify the network path over which the User 2813 Payload (GRE Payload) is to be transmitted. 2814 - All other fields in the GRE header, including the 2815 remaining bits in the Key fields, are processed as per 2816 [GRE_2784][GRE_2890]. 2818 The GRE Convergence PDU is passed onto the MX Adaptation 2819 Layer (if present) before delivery over one of the network 2820 paths. 2822 4.5 Co-existence of MX Adaptation and MX Convergence 2823 Sublayers 2825 MAMS u-plane protocols support multiple combinations and 2826 instances of user plane protocols to be used in the MX 2827 Adaptation and the Convergence sublayers. 2829 For example, one instance of the MX Convergence Layer can be 2830 MPTCP Proxy [MPProxy][MPPlain] and another instance can be 2831 Trailer-based. The MX Adaptation for each can be either UDP 2832 tunnel or IPsec. IPsec may be set up for network paths 2833 considered as untrusted by the operator, to protect the TCP 2834 subflow between client and MPTCP proxy traversing that 2835 network path. 2837 Each of the instances of MAMS user plane, i.e. combination of 2838 MX Convergence and MX Adaptation layer protocols, can coexist 2839 simultaneously and independently handle different traffic 2840 types. 2842 5. MX Convergence Control Message 2844 A UDP connection may be configured between C-MADP and N-MADP 2845 to exchange control messages for keep-alive or path quality 2846 estimation. The N-MADP end-point IP address and UDP port 2847 number of the UDP connection is used to identify MX control 2848 PDU. Figure 6 shows the MX control PDU format with the 2849 following fields: 2851 o Type (1 Byte): the type of the MX control message 2852 o CID (1 Byte): an unsigned integer to identify the anchor 2853 and delivery connection of the MX control message 2854 + Anchor Connection ID (MSB 4 Bits): an unsigned 2855 integer to identify the anchor connection 2856 + Delivery Connection ID (LSB 4 Bits): an unsigned 2857 integer to identify the delivery connection 2858 o MX Control Message (variable): the payload of the MX 2859 control message 2861 Figure 7 shows the MX convergence control protocol stack, and 2862 MX control PDU goes through the MX adaptation sublayer the 2863 same way as MX data PDU. 2865 <----MX Control PDU Payload --------- 2866 ------> 2867 +------------------------------------------------------------ 2868 ------+ 2869 | IP header | UDP Header| Type | CID | MX Control 2870 Message | +---------------------------- 2871 --------------------------------------+ 2872 Figure 6: MX Control PDU Format 2874 |-----------------------------------------------------| 2875 | MX Convergence Control Messages | 2876 |-----------------------------------------------------| 2877 | UDP/IP 2878 | 2879 |-----------------------------------------------------| 2880 | MX Adaptation | MX Adaptation | MX Adaptation | 2881 | Sublayer | Sublayer | Sublayer | 2882 | (optional) | (optional) | (optional) | 2883 |-----------------------------------------------------| 2884 | Access #1 IP | Access #2 IP | Access #3 IP 2885 | 2886 +-----------------------------------------------------+ 2887 Figure 7: MX Convergence Control Protocol Stack 2889 5.1 Keep-Alive Message 2891 The "Type" field is set to "0" for Keep-Alive messages. C- 2892 MADP may send out Keep-Alive message periodically over one or 2893 multiple delivery connections, especially if UDP tunneling is 2894 used as the adaptation method for the delivery connection 2895 with a NAT function on the path. 2897 A Keep-Alive message is 6 Bytes long, and consists of the 2898 following fields: 2900 o Keep-Alive Sequence Number (2 Bytes): the sequence 2901 number of the keep-alive message 2902 o Timestamp (4 Bytes): the current value of the timestamp 2903 clock of the sender in the unit of 100 microseconds. 2905 5.2 Probe Message 2907 The "Type" field is set to "1" for Probe messages. 2909 N-MADP may send out the Probe message for path quality 2910 estimation. In response, C-MADP may send back the ACK 2911 message. 2913 A Probe message consists of the following fields: 2915 o Probing Sequence Number (2 Bytes): the sequence number 2916 of the Probe REQ message 2917 o Probing Flag (1 Byte): 2918 + Bit #0: a ACK flag to indicate if the ACK message is 2919 expected (1) or not (0); 2920 + Bit #1: a Probe Type flag to indicate if the Probe 2921 message is sent during the initialization phase (0) 2922 when the network path is not included for 2923 transmission of user data or the active phase (1) 2924 when the network path is included for transmission 2925 of user data; 2926 + Bit #2: a bit flag to indicate the presence of the 2927 Reverse Connection ID (R-CID) field. 2928 + Bit #3~7: reserved 2929 o Reverse Connection ID (1 Byte): the connection ID of the 2930 delivery connection for sending out the ACK message on 2931 the reverse path 2933 o Timestamp (4 Bytes): the current value of the timestamp 2934 clock of the sender in the unit of 100 microseconds. 2935 o Padding (variable) 2937 The "R-CID" field is only present if both Bit #0 and Bit #2 2938 of the "Probing Flag" field are set to "1". Moreover, Bit #2 2939 of the "Probing Flag" field SHOULD be set to "0" if the Bit 2940 #0 is "0", indicating the ACK message is not expected. 2942 If the "R-CID" field is not present but the Bit #0 of the 2943 "Probing Flag" field is set to "1", the ACK message SHOULD be 2944 sent over the same delivery connection as the Probe message. 2946 The "Padding" field is used to control the length of Probe 2947 message. 2949 5.3 Packet Loss Report (PLR) Message 2951 The "Type" field is set to "2" for PLR messages. 2953 C-MADP may send out the PLR messages to report lost MX SDU 2954 for example during handover. In response, C-MADP may 2955 retransmit the lost MX SDU accordingly. 2957 A PLR message consists of the following fields: 2959 o Connection ID (1 Byte): an unsigned integer to identify 2960 the anchor connection which the ACK message is for; 2961 o Traffic Class ID (1 Byte): an unsigned integer to 2962 identify the traffic class of the anchor connection 2963 which the ACK message is for; 2964 o ACK number (4 Bytes): the next (in-order) sequence 2965 number (SN) that the sender of the PLR message is 2966 expecting 2967 o Number of Loss Bursts (1 Byte) 2968 For each loss burst, include the following 2969 + Sequence Number of the first lost MX SDU in a burst 2970 (4 Bytes) 2971 + Number of consecutive lost MX SDUs in the burst (1 2972 Byte) 2974 C-MADP 2975 N-MADP 2976 | 2977 | 2978 |<------------------ MX SDU (data packets)----- 2979 ---| 2980 | 2981 | 2982 +---------------------------------+ 2983 | 2984 |Packet Loss detected | 2985 | 2986 +---------------------------------+ 2987 | 2988 | 2989 | 2990 |----- PLR Message ---------------------------- 2991 -->| 2992 |<-------------retransmit(lost)MX SDUs -------- 2993 ---| 2995 Figure 8: MAMS Retransmission Procedure 2997 Figure 8 shows the MAMS retransmission procedure in an 2998 example where the lost packet is found and retransmitted. 3000 5.4 First Sequence Number (FSN) Message 3002 The "Type" field is set to "3" for FSN messages. 3004 N-MADP may send out the FSN messages to indicate the oldest 3005 MX SDU in its buffer if a lost MX SDU is not found in the 3006 buffer after receiving the PLR message from C-MADP. In 3007 response, C-MADP SHALL only report packet loss with SN not 3008 smaller than FSN. 3010 A FSN message consists of the following fields: 3012 o Connection ID (1 Byte): an unsigned integer to identify 3013 the anchor connection which the FSN message is for; 3014 o Traffic Class ID (1 Byte): an unsigned integer to 3015 identify the traffic class of the anchor connection 3016 which the FSN message is for; 3017 o First Sequence Number (4 Bytes): the sequence number 3018 (SN) of the oldest MX SDU in the (retransmission) buffer 3019 of the sender of the FSN message. 3021 Figure 9 shows the MAMS retransmission procedure in an 3022 example where the lost packet is not found. 3024 C-MADP 3025 N-MADP 3026 | 3027 | 3028 |<------------------ MX SDU (data packets)----- 3029 ---| 3030 | 3031 | 3032 +---------------------------------+ 3033 | 3034 |Packet Loss detected | 3035 | 3036 +---------------------------------+ 3037 | 3038 | 3039 | 3040 |----- PLR Message ---------------------------- 3041 -->| 3042 | +--------------- 3043 ------+ 3044 | |Lost packet not 3045 found| 3046 | +--------------- 3047 ------+ 3048 |<-------------FSN message -------------------- 3049 ---| 3051 Figure 9: MAMS Retransmission Procedure with FSN 3053 5.5 Coded MX SDU (CMS) Message 3055 The "Type" field is set to "4" for CMS messages. 3057 N-MADP (or C-MADP) may send out the CMS message to support 3058 downlink (or uplink) packet loss recovery through coding, 3059 e.g. [CRLNC], [CTCP], [RLNC]. A coded MX SDU is generated by 3060 applying a network coding algorithm to multiple consecutive 3061 (uncoded) MX SDUs, and it is used for fast recovery without 3062 retransmission if any of the MX SDUs is lost. 3064 A Coded MX SDU message consists of the following fields: 3066 o Connection ID (1 Byte): an unsigned integer to identify 3067 the anchor connection of the coded MX SDU; 3069 o Traffic Class ID (1 Byte): an unsigned integer to 3070 identify the traffic class of the coded MX; 3071 o Sequence Number (4 Bytes): the sequence number of the 3072 first (uncoded) MX SDU used to generate the coded MX 3073 SDU. 3074 o Fragmentation Control (FC) (1 Byte): to provide 3075 necessary information for re-assembly, only needed if 3076 the coded MX SDU is too long to transport in a single MX 3077 control PDU. 3078 o N (1 Byte): the number of consecutive MX SDUs used to 3079 generate the coded MX SDU 3080 o K (1 Byte): the length (in terms of bits) of the coding 3081 coefficient field 3082 o Coding Coefficient ( N x K / 8 Bytes) 3083 + a(i): the coding coefficient of the i-th (uncoded) 3084 MX SDU 3085 + padding 3086 o Coded MX SDU (variable): the coded MX SDU 3088 If K = 0, the simple XOR method is used to generate the Coded 3089 MX SDU from N consecutive uncoded MX SDUs, and the a(i) 3090 fields are not included in the message. 3092 If the coded MX SDU is too long, it can be fragmented, and 3093 transported by multiple MX control PDUs. The N, K, and a(i) 3094 fields are only included in the MX PDU carrying the first 3095 fragment of the coded MX SDU. 3097 C-MADP 3098 N-MADP 3099 | 3100 | 3101 |<------------------ MX SDU #1 ---------------- 3102 ---| 3103 | lost<-------- MX SDU #2 ---------------- 3104 ---| 3105 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)--- 3106 ---| 3107 +----------------------+ 3108 | 3109 | MX SDU #2 recovered | 3110 | 3111 +----------------------+ 3112 | 3113 | 3114 | 3116 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 3118 5.6 Traffic Splitting Update (TSU) Message 3120 The "Type" field is set to "5" for TSU messages. 3122 N-MADP (or C-MADP) may send out a TSU message if downlink (or 3123 uplink) traffic splitting configuration has changed. 3125 A TSU message consists of the following fields: 3127 o Connection ID (1 Byte): an unsigned integer to identify 3128 the anchor connection; 3129 o Traffic Class ID (1 Byte): an unsigned integer to 3130 identify the traffic class; 3131 o Sequence Number (2 Bytes): an unsigned integer to 3132 identify the TSU message. 3133 o Flags (1 Byte) 3134 + Bit #0: a Reverse Path bit flag to indicate if the 3135 traffic splitting configuration is for the reverse 3136 path (1) or not (0); 3137 + Bit #1: a Bit-Reversal bit flag to indicate if bit- 3138 reversal is used in traffic splitting 3139 + Others: reserved. 3140 o Traffic Splitting Configuration Parameters ( 5 + (N -1) 3141 Bytes): 3142 + StartSN (4 Bytes): the sequence number of the first 3143 MX SDU using the traffic splitting configuration 3144 provided by the TSU message 3145 + L (1 Byte): the traffic splitting burst size 3146 + K(i): the traffic splitting threshold of the i-th 3147 delivery connection, where connections are ordered 3148 according to their Connection ID. 3150 Let's use f(x) to denote the traffic splitting function, 3151 which maps a MX SDU Sequence Number "x" to the i-th delivery 3152 connection. 3154 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 3156 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 3158 N is the total number of connections for delivering a data 3159 flow, identified by (anchor) Connection ID and Traffic Class 3160 ID. 3162 When the bit-reversal bit is set to 1, the burst size L MUST 3163 be a power of 2, and the traffic splitting function is 3165 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < 3166 K[i] 3168 Wherein F(.) is the bit reversal function [BITR] of the input 3169 variable. 3171 5.7 Acknowledgement Message 3173 The "Type" field is set to "6" for ACK messages. 3175 C-MADP (or N-MADP) SHOULD send out the ACK message in 3176 response to the successful reception of a PLR, FSN, or TSU 3177 message. 3179 C-MADP SHOULD send out the ACK message in response to a Probe 3180 message with the ACK flag set to "1". 3182 The ACK message consists of the following fields: 3184 o Acknowledgment Number (2 Bytes): the sequence number of 3185 the received message. 3186 o Timestamp (4 Bytes): the current value of the timestamp 3187 clock of the sender in the unit of 100 microseconds. 3189 6 Security Considerations 3191 User data in MAMS framework rely on the security of the 3192 underlying network transport paths. When this cannot be 3193 assumed, NCM configures use of appropriate protocols for 3194 security, e.g. IPsec [RFC4301] [RFC3948], DTLS [RFC6347]. 3196 7 IANA Considerations 3198 This draft makes no requests of IANA. 3200 8 Contributing Authors 3202 The editors gratefully acknowledge the following additional 3203 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 3204 Pentakota/Nokia. 3206 9 References 3208 9.1 Normative References 3210 [RFC2119] Bradner, S., "Key words for use in RFCs to 3211 Indicate Requirement Levels", BCP 14, RFC 2119, 3212 March 1997. 3214 [RFC4301] Kent, S. and K. Seo, "Security Architecture for 3215 the Internet Protocol", RFC 4301, 3216 DOI10.17487/RFC4301, December 2005, 3217 . 3219 9.2 Informative References 3221 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram 3222 Transport Layer Security Version 1.2", RFC 6347, 3223 January 2012, . 3226 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., 3227 and T. Kivinen, "Internet Key Exchange Protocol 3228 Version 2 (IKEv2)", STD 79, RFC 7296, DOI 3229 10.17487/RFC7296, October 2014, . 3232 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, 3233 L., and M. Stenberg, "UDP Encapsulation of IPsec 3234 ESP Packets", RFC 3948, DOI 10.17487/RFC3948, 3235 January 2005, . 3238 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy 3239 mechanisms", https://tools.ietf.org/html/draft- 3240 wei-mptcp-proxy-mechanism-02 3242 [MPPlain] M. Boucadair et al, "An MPTCP Option for 3243 Network-Assisted MPTCP", 3244 https://www.ietf.org/id/draft-boucadair-mptcp- 3245 plain-mode-09.txt 3247 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, 3248 "Multiple Access Management Protocol", 3249 https://tools.ietf.org/html/draft-kanugovi- 3250 intarea-mams-protocol-03 3252 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for 3253 Generic Multi-Access Convergence", 3254 https://tools.ietf.org/html/draft-zhu-intarea- 3255 gma-01 3257 [GRE2784] D. Farinacci, et al., "Generic Routing 3258 Encapsulation (GRE)", RFC 2784 March 2000, 3259 . 3261 [GRE2890] G. Dommety, "Key and Sequence Number Extensions 3262 to GRE", RFC 2890 September 2000, 3263 . 3265 [IANA] https://www.iana.org/assignments/protocol- 3266 numbers/protocol-numbers.xhtml 3268 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial 3269 Radio Access (E-UTRA); LTE-WLAN Radio Level 3270 Integration Using Ipsec Tunnel (LWIP) 3271 encapsulation; Protocol specification" 3273 [RFC791] Internet Protocol, September 1981 3275 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. 3276 Caterpillar RLNC (CRLNC): A Practical Finite 3277 Sliding Window RLNC Approach, IEEE Access, 2017 3279 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 3280 arXiv:1212.2291, 2012 3282 [RLNC] J. Heide, et al. Random Linear Network Coding 3283 (RLNC)-Based Symbol Representation, 3284 https://www.ietf.org/id/draft-heide-nwcrg-rlnc- 3285 00.txt 3287 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM 3288 Review, 38 (1): 1-26, 1996. 3290 Authors' Addresses 3292 Jing Zhu 3294 Intel 3296 Email: jing.z.zhu@intel.com 3298 SungHoon Seo 3299 Korea Telecom 3301 Email: sh.seo@kt.com 3303 Satish Kanugovi 3305 Nokia 3307 Email: satish.k@nokia.com 3309 Shuping Peng 3311 Huawei 3313 Email: pengshuping@huawei.com 3315 INTAREA J. Zhu 3316 Internet Draft Intel 3317 Intended status: Standards Track S. Seo 3318 Expires: April 1,2020 Korea Telecom 3319 S. Kanugovi 3320 Nokia 3321 S. Peng 3322 Huawei 3323 October 1, 2019 3325 User-Plane Protocols for Multiple Access Management Service 3326 draft-zhu-intarea-mams-user-protocol-07 3328 Status of this Memo 3330 This Internet-Draft is submitted in full conformance with the 3331 provisions of BCP 78 and BCP 79. 3333 Internet-Drafts are working documents of the Internet Engineering 3334 Task Force (IETF), its areas, and its working groups. Note that 3335 other groups may also distribute working documents as Internet- 3336 Drafts. 3338 Internet-Drafts are draft documents valid for a maximum of six 3339 months and may be updated, replaced, or obsoleted by other documents 3340 at any time. It is inappropriate to use Internet-Drafts as 3341 reference material or to cite them other than as "work in progress." 3343 The list of current Internet-Drafts can be accessed at 3344 http://www.ietf.org/ietf/1id-abstracts.txt 3346 The list of Internet-Draft Shadow Directories can be accessed at 3347 http://www.ietf.org/shadow.html 3349 This Internet-Draft will expire on April 1,2020. 3351 Copyright Notice 3353 Copyright (c) 2019 IETF Trust and the persons identified as the 3354 document authors. All rights reserved. 3356 This document is subject to BCP 78 and the IETF Trust's Legal 3357 Provisions Relating to IETF Documents 3358 (http://trustee.ietf.org/license-info) in effect on the date of 3359 publication of this document. Please review these documents 3360 carefully, as they describe your rights and restrictions with 3361 respect to this document. Code Components extracted from this 3362 document must include Simplified BSD License text as described in 3363 Section 4.e of the Trust Legal Provisions and are provided without 3364 warranty as described in the Simplified BSD License. 3366 Abstract 3368 Today, a device can be simultaneously connected to multiple 3369 communication networks based on different technology implementations 3370 and network architectures like WiFi, LTE, and DSL. In such multi- 3371 connectivity scenario, it is desirable to combine multiple access 3372 networks or select the best one to improve quality of experience for 3373 a user and improve overall network utilization and efficiency. This 3374 document presents the u-plane protocols for a multi access 3375 management services (MAMS) framework that can be used to flexibly 3376 select the combination of uplink and downlink access and core 3377 network paths having the optimal performance, and user plane 3378 treatment for improving network utilization and efficiency and 3379 enhanced quality of experience for user applications. 3381 Table of Contents 3383 1. Introduction...................................................3 3384 2. Terminologies..................................................3 3385 3. Conventions used in this document..............................3 3386 4 MAMS User-Plane Protocols......................................4 3387 4.1 MX Adaptation Sublayer...................................4 3388 4.2 GMA-based MX Convergence Sublayer........................5 3389 4.3 MPTCP-based MX Convergence Sublayer......................6 3390 4.4 GRE as MX Convergence Sublayer...........................6 3391 4.4.1 Transmitter Procedures.............................7 3392 4.4.2 Receiver Procedures................................8 3393 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 3394 8 3395 5. MX Convergence Control Message.................................8 3396 5.1 Keep-Alive Message.......................................9 3397 5.2 Probe Message............................................9 3398 5.3 Packet Loss Report (PLR) Message........................10 3399 5.4 First Sequence Number (FSN) Message.....................11 3400 5.5 Coded MX SDU (CMS) Message..............................12 3401 5.6 Traffic Splitting Update (TSU) Message..................13 3402 5.7 Acknowledgement Message.................................14 3403 6 Security Considerations.......................................14 3404 7 IANA Considerations...........................................15 3405 8 Contributing Authors..........................................15 3406 9 References....................................................15 3407 9.1 Normative References....................................15 3408 9.2 Informative References..................................15 3410 1. Introduction 3412 Multi Access Management Service (MAMS) [MAMS] is a programmable 3413 framework to select and configure network paths, as well as adapt to 3414 dynamic network conditions, when multiple network connections can 3415 serve a client device. It is based on principles of user plane 3416 interworking that enables the solution to be deployed as an overlay 3417 without impacting the underlying networks. 3419 This document presents the u-plane protocols for enabling the MAMS 3420 framework. It co-exists and complements the existing protocols by 3421 providing a way to negotiate and configure the protocols based on 3422 client and network capabilities. Further it allows exchange of 3423 network state information and leveraging network intelligence to 3424 optimize the performance of such protocols. An important goal for 3425 MAMS is to ensure that there is minimal or no dependency on the 3426 actual access technology of the participating links. This allows the 3427 scheme to be scalable for addition of newer access technologies and 3428 for independent evolution of the existing access technologies. 3430 2. Terminologies 3432 Anchor Connection: refers to the network path from the N-MADP to the 3433 Application Server that corresponds to a specific IP anchor that has 3434 assigned an IP address to the client. 3436 Delivery Connection: refers to the network path from the N-MADP to 3437 the C-MADP. 3439 "Network Connection Manager" (NCM), "Client Connection Manager" 3440 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 3441 Access Data Proxy" (C-MADP) in this document are to be interpreted 3442 as described in [MAMS]. 3444 3. Conventions used in this document 3446 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3447 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 3448 document are to be interpreted as described in [RFC2119]. 3450 The terminologies "Network Connection Manager" (NCM), "Client 3451 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 3452 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 3453 document are to be interpreted as described in [MAMS]. 3455 4 MAMS User-Plane Protocols 3457 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 3458 +-----------------------------------------------------+ 3459 | User Payload (e.g. IP PDU) | 3460 |-----------------------------------------------------| 3461 +--|-----------------------------------------------------|--+ 3462 | |-----------------------------------------------------| | 3463 | | Multi-Access (MX) Convergence Sublayer | | 3464 | |-----------------------------------------------------| | 3465 | |-----------------------------------------------------| | 3466 | | MX Adaptation | MX Adaptation | MX Adaptation | | 3467 | | Sublayer | Sublayer | Sublayer | | 3468 | | (optional) | (optional) | (optional) | | 3469 | |-----------------------------------------------------| | 3470 | | Access #1 IP | Access #2 IP | Access #3 IP | | 3471 | +-----------------------------------------------------+ | 3472 +-----------------------------------------------------------+ 3473 Figure 1: MAMS U-plane Protocol Stack 3474 It consists of the following two Sublayers: 3476 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 3477 access specific tasks, e.g., access (path) selection, multi-link 3478 (path) aggregation, splitting/reordering, lossless switching, 3479 fragmentation, concatenation, keep-alive, and probing etc. 3480 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 3481 to handle tunneling, network layer security, and NAT. 3483 The MX convergence sublayer operates on top of the MX adaptation 3484 sublayer in the protocol stack. From the Transmitter perspective, a 3485 User Payload (e.g. IP PDU) is processed by the convergence sublayer 3486 first, and then by the adaptation sublayer before being transported 3487 over a delivery access connection; from the Receiver perspective, an IP 3488 packet received over a delivery connection is processed by the MX 3489 adaptation sublayer first, and then by the MX convergence sublayer. 3491 4.1 MX Adaptation Sublayer 3493 The MX adaptation sublayer supports the following mechanisms and 3494 protocols while transmitting user plane packets on the network path: 3496 o UDP Tunneling: The user plane packets of the anchor connection can be 3497 encapsulated in a UDP tunnel of a delivery connection between the N- 3498 MADP and C-MADP. 3500 o IPsec Tunneling: The user plane packets of the anchor connection are 3501 sent through an IPsec tunnel of a delivery connection. 3502 o Client Net Address Translation (NAT): The Client IP address of user 3503 plane packet of the anchor connection is changed, and sent over a 3504 delivery connection. 3505 o Pass Through: The user plane packets are passing through without any 3506 change over the anchor connection. 3508 The MX adaptation sublayer also supports the following mechanisms and 3509 protocols to ensure security of user plane packets over the network 3510 path. 3512 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 3513 N-MADP and C-MADP on the network path that is considered untrusted. 3514 o DTLS: If UDP tunneling is used on the network path that is considered 3515 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 3516 be used. 3518 The Client NAT method is the most efficient due to no tunneling 3519 overhead. It SHOULD be used if a delivery connection is "trusted" and 3520 without NAT function on the path. 3522 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 3523 connection has a NAT function placed on the path. 3525 4.2 GMA-based MX Convergence Sublayer 3527 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 3528 encapsulation [GMA]. Multiple access networks are combined into a 3529 single IP connection. If NCM determines that N-MADP is to be 3530 instantiated with GMA as the MX Convergence Protocol, it exchanges the 3531 support of GMA convergence capability in the discovery and capability 3532 exchange procedures [MAMS]. 3534 +-----------------------------------------------------+ 3535 | IP PDU | 3536 |-----------------------------------------------------| 3537 | GMA Convergence Sublayer | 3538 |-----------------------------------------------------| 3539 | MX Adaptation | MX Adaptation | MX Adaptation | 3540 | Sublayer | Sublayer | Sublayer | 3541 | (optional) | (optional) | (optional) | 3542 |-----------------------------------------------------| 3543 | Access #1 IP | Access #2 IP | Access #3 IP | 3544 +-----------------------------------------------------+ 3545 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 3547 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 3548 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 3549 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 3550 message [MAMS] is true, the "IP length" and "IP checksum" header fields 3551 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 3552 updated after adding or removing the GMA trailer in the convergence 3553 sublayer. 3555 +------------------------------------------------------+ 3556 | IP hdr | IP payload | GMA Trailer | 3557 +------------------------------------------------------+ 3558 Figure 3: GMA PDU Format 3560 4.3 MPTCP-based MX Convergence Sublayer 3562 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 3563 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 3564 access networks are combined into a single MPTCP connection. Hence, no 3565 new u-plane protocol or PDU format is needed in this case. 3567 |-----------------------------------------------------| 3568 | MPTCP | 3569 |-----------------------------------------------------| 3570 | TCP | TCP | TCP | 3571 |-----------------------------------------------------| 3572 | MX Adaptation | MX Adaptation | MX Adaptation | 3573 | Sublayer | Sublayer | Sublayer | 3574 | (optional) | (optional) | (optional) | 3575 |-----------------------------------------------------| 3576 | Access #1 IP | Access #2 IP | Access #3 IP | 3577 +-----------------------------------------------------+ 3578 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 3579 Layer 3581 If NCM determines that N-MADP is to be instantiated with MPTCP as the 3582 MX Convergence Protocol, it exchanges the support of MPTCP capability 3583 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 3584 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 3585 and aggregation over multiple delivery connections. 3587 4.4 GRE as MX Convergence Sublayer 3589 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 3590 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 3591 Convergence sub-layer" protocol. Multiple access networks are combined 3592 into a single GRE connection. Hence, no new u-plane protocol or PDU 3593 format is needed in this case. 3595 +-----------------------------------------------------+ 3596 | User Payload (e.g. IP PDU) | 3597 |-----------------------------------------------------| 3598 | GRE as MX Convergence Sublayer | 3599 |-----------------------------------------------------| 3600 | GRE Delivery Protocol (e.g. IP) | 3601 |-----------------------------------------------------| 3602 | MX Adaptation | MX Adaptation | MX Adaptation | 3603 | Sublayer | Sublayer | Sublayer | 3604 | (optional) | (optional) | (optional) | 3605 |-----------------------------------------------------| 3606 | Access #1 IP | Access #2 IP | Access #3 IP | 3607 +-----------------------------------------------------+ 3608 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 3609 Layer 3611 If NCM determines that N-MADP is to be instantiated with GRE as the MX 3612 Convergence Protocol, it exchanges the support of GRE capability in the 3613 discovery and capability exchange procedures [MAMS]. 3615 4.4.1 Transmitter Procedures 3617 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 3618 the convergence protocol that transmits the GRE packets. The 3619 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 3620 with a GRE header and Delivery Protocol (e.g. IP) header to generate 3621 the GRE Convergence PDU. 3623 When IP is used as the GRE delivery protocol, the IP header information 3624 (e.g. IP address) can be created using the IP header of the user 3625 payload or a virtual IP address. The "Protocol Type" field of the 3626 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 3628 The GRE header fields are set as specified below, 3630 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 3631 to the value of Connection ID for the Anchor Connection associated 3632 with the user payload or sets to 0xFFFF if no Anchor Connection ID 3633 needs to be specified. 3634 - All other fields in the GRE header including the remaining bits in 3635 the key fields are set as per [GRE_2784][GRE_2890]. 3637 4.4.2 Receiver Procedures 3639 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 3640 convergence protocol that receives the GRE packets. The receiver 3641 processes the received packets per the GRE procedures [GRE_2784, 3642 GRE_2890] and retrieves the GRE header. 3644 - If the Receiver is an N-MADP instance, 3645 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 3646 interpreted as the Connection ID of Anchor Connection for the 3647 user payload. This is used to identify the network path over 3648 which the User Payload (GRE Payload) is to be transmitted. 3649 - All other fields in the GRE header, including the remaining bits 3650 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 3652 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 3653 present) before delivery over one of the network paths. 3655 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 3657 MAMS u-plane protocols support multiple combinations and instances of 3658 user plane protocols to be used in the MX Adaptation and the 3659 Convergence sublayers. 3661 For example, one instance of the MX Convergence Layer can be MPTCP 3662 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 3663 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 3664 set up for network paths considered as untrusted by the operator, to 3665 protect the TCP subflow between client and MPTCP proxy traversing that 3666 network path. 3668 Each of the instances of MAMS user plane, i.e. combination of MX 3669 Convergence and MX Adaptation layer protocols, can coexist 3670 simultaneously and independently handle different traffic types. 3672 5. MX Convergence Control Message 3674 A UDP connection may be configured between C-MADP and N-MADP to 3675 exchange control messages for keep-alive or path quality estimation. 3676 The N-MADP end-point IP address and UDP port number of the UDP 3677 connection is used to identify MX control PDU. Figure 6 shows the MX 3678 control PDU format with the following fields: 3680 o Type (1 Byte): the type of the MX control message 3681 o CID (1 Byte): an unsigned integer to identify the anchor and 3682 delivery connection of the MX control message 3683 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 3684 identify the anchor connection 3685 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 3686 identify the delivery connection 3687 o MX Control Message (variable): the payload of the MX control 3688 message 3690 Figure 7 shows the MX convergence control protocol stack, and MX 3691 control PDU goes through the MX adaptation sublayer the same way as MX 3692 data PDU. 3694 <----MX Control PDU Payload ---------------> 3695 +------------------------------------------------------------------+ 3696 | IP header | UDP Header| Type | CID | MX Control Message | 3697 +------------------------------------------------------------------+ 3698 Figure 6: MX Control PDU Format 3700 |-----------------------------------------------------| 3701 | MX Convergence Control Messages | 3702 |-----------------------------------------------------| 3703 | UDP/IP | 3704 |-----------------------------------------------------| 3705 | MX Adaptation | MX Adaptation | MX Adaptation | 3706 | Sublayer | Sublayer | Sublayer | 3707 | (optional) | (optional) | (optional) | 3708 |-----------------------------------------------------| 3709 | Access #1 IP | Access #2 IP | Access #3 IP | 3710 +-----------------------------------------------------+ 3711 Figure 7: MX Convergence Control Protocol Stack 3713 5.1 Keep-Alive Message 3715 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 3716 out Keep-Alive message periodically over one or multiple delivery 3717 connections, especially if UDP tunneling is used as the adaptation 3718 method for the delivery connection with a NAT function on the path. 3720 A Keep-Alive message is 6 Bytes long, and consists of the following 3721 fields: 3723 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 3724 keep-alive message 3725 o Timestamp (4 Bytes): the current value of the timestamp clock of 3726 the sender in the unit of 100 microseconds. 3728 5.2 Probe Message 3730 The "Type" field is set to "1" for Probe messages. 3732 N-MADP may send out the Probe message for path quality estimation. In 3733 response, C-MADP may send back the ACK message. 3735 A Probe message consists of the following fields: 3737 o Probing Sequence Number (2 Bytes): the sequence number of the 3738 Probe REQ message 3739 o Probing Flag (1 Byte): 3740 + Bit #0: a ACK flag to indicate if the ACK message is expected 3741 (1) or not (0); 3742 + Bit #1: a Probe Type flag to indicate if the Probe message is 3743 sent during the initialization phase (0) when the network 3744 path is not included for transmission of user data or the 3745 active phase (1) when the network path is included for 3746 transmission of user data; 3747 + Bit #2: a bit flag to indicate the presence of the Reverse 3748 Connection ID (R-CID) field. 3749 + Bit #3~7: reserved 3750 o Reverse Connection ID (1 Byte): the connection ID of the delivery 3751 connection for sending out the ACK message on the reverse path 3752 o Timestamp (4 Bytes): the current value of the timestamp clock of 3753 the sender in the unit of 100 microseconds. 3754 o Padding (variable) 3756 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 3757 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 3758 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 3759 ACK message is not expected. 3761 If the "R-CID" field is not present but the Bit #0 of the "Probing 3762 Flag" field is set to "1", the ACK message SHOULD be sent over the same 3763 delivery connection as the Probe message. 3765 The "Padding" field is used to control the length of Probe message. 3767 5.3 Packet Loss Report (PLR) Message 3769 The "Type" field is set to "2" for PLR messages. 3771 C-MADP may send out the PLR messages to report lost MX SDU for example 3772 during handover. In response, C-MADP may retransmit the lost MX SDU 3773 accordingly. 3775 A PLR message consists of the following fields: 3777 o Connection ID (1 Byte): an unsigned integer to identify the anchor 3778 connection which the ACK message is for; 3780 o Traffic Class ID (1 Byte): an unsigned integer to identify the 3781 traffic class of the anchor connection which the ACK message is 3782 for; 3783 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 3784 that the sender of the PLR message is expecting 3785 o Number of Loss Bursts (1 Byte) 3786 For each loss burst, include the following 3787 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 3788 + Number of consecutive lost MX SDUs in the burst (1 Byte) 3790 C-MADP N-MADP 3791 | | 3792 |<------------------ MX SDU (data packets)--------| 3793 | | 3794 +---------------------------------+ | 3795 |Packet Loss detected | | 3796 +---------------------------------+ | 3797 | | 3798 |----- PLR Message ------------------------------>| 3799 |<-------------retransmit(lost)MX SDUs -----------| 3801 Figure 8: MAMS Retransmission Procedure 3803 Figure 8 shows the MAMS retransmission procedure in an example where 3804 the lost packet is found and retransmitted. 3806 5.4 First Sequence Number (FSN) Message 3808 The "Type" field is set to "3" for FSN messages. 3810 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 3811 its buffer if a lost MX SDU is not found in the buffer after receiving 3812 the PLR message from C-MADP. In response, C-MADP SHALL only report 3813 packet loss with SN not smaller than FSN. 3815 A FSN message consists of the following fields: 3817 o Connection ID (1 Byte): an unsigned integer to identify the anchor 3818 connection which the FSN message is for; 3819 o Traffic Class ID (1 Byte): an unsigned integer to identify the 3820 traffic class of the anchor connection which the FSN message is 3821 for; 3822 o First Sequence Number (4 Bytes): the sequence number (SN) of the 3823 oldest MX SDU in the (retransmission) buffer of the sender of the 3824 FSN message. 3826 Figure 9 shows the MAMS retransmission procedure in an example where 3827 the lost packet is not found. 3829 C-MADP N-MADP 3830 | | 3831 |<------------------ MX SDU (data packets)--------| 3832 | | 3833 +---------------------------------+ | 3834 |Packet Loss detected | | 3835 +---------------------------------+ | 3836 | | 3837 |----- PLR Message ------------------------------>| 3838 | +---------------------+ 3839 | |Lost packet not found| 3840 | +---------------------+ 3841 |<-------------FSN message -----------------------| 3843 Figure 9: MAMS Retransmission Procedure with FSN 3845 5.5 Coded MX SDU (CMS) Message 3847 The "Type" field is set to "4" for CMS messages. 3849 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 3850 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 3851 [RLNC]. A coded MX SDU is generated by applying a network coding 3852 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 3853 fast recovery without retransmission if any of the MX SDUs is lost. 3855 A Coded MX SDU message consists of the following fields: 3857 o Connection ID (1 Byte): an unsigned integer to identify the anchor 3858 connection of the coded MX SDU; 3859 o Traffic Class ID (1 Byte): an unsigned integer to identify the 3860 traffic class of the coded MX; 3861 o Sequence Number (4 Bytes): the sequence number of the first 3862 (uncoded) MX SDU used to generate the coded MX SDU. 3863 o Fragmentation Control (FC) (1 Byte): to provide necessary 3864 information for re-assembly, only needed if the coded MX SDU is 3865 too long to transport in a single MX control PDU. 3866 o N (1 Byte): the number of consecutive MX SDUs used to generate the 3867 coded MX SDU 3868 o K (1 Byte): the length (in terms of bits) of the coding 3869 coefficient field 3870 o Coding Coefficient ( N x K / 8 Bytes) 3871 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 3872 + padding 3873 o Coded MX SDU (variable): the coded MX SDU 3875 If K = 0, the simple XOR method is used to generate the Coded MX SDU 3876 from N consecutive uncoded MX SDUs, and the a(i) fields are not 3877 included in the message. 3879 If the coded MX SDU is too long, it can be fragmented, and transported 3880 by multiple MX control PDUs. The N, K, and a(i) fields are only 3881 included in the MX PDU carrying the first fragment of the coded MX SDU. 3883 C-MADP N-MADP 3884 | | 3885 |<------------------ MX SDU #1 -------------------| 3886 | lost<-------- MX SDU #2 -------------------| 3887 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 3888 +----------------------+ | 3889 | MX SDU #2 recovered | | 3890 +----------------------+ | 3891 | | 3893 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 3895 5.6 Traffic Splitting Update (TSU) Message 3897 The "Type" field is set to "5" for TSU messages. 3899 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 3900 traffic splitting configuration has changed. 3902 A TSU message consists of the following fields: 3904 o Connection ID (1 Byte): an unsigned integer to identify the anchor 3905 connection; 3906 o Traffic Class ID (1 Byte): an unsigned integer to identify the 3907 traffic class; 3908 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 3909 message. 3910 o Flags (1 Byte) 3911 + Bit #0: a Reverse Path bit flag to indicate if the traffic 3912 splitting configuration is for the reverse path (1) or not 3913 (0); 3914 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 3915 used in traffic splitting 3916 + Others: reserved. 3917 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 3919 + StartSN (4 Bytes): the sequence number of the first MX SDU 3920 using the traffic splitting configuration provided by the TSU 3921 message 3922 + L (1 Byte): the traffic splitting burst size 3923 + K(i): the traffic splitting threshold of the i-th delivery 3924 connection, where connections are ordered according to their 3925 Connection ID. 3927 Let's use f(x) to denote the traffic splitting function, which maps a 3928 MX SDU Sequence Number "x" to the i-th delivery connection. 3930 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 3932 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 3934 N is the total number of connections for delivering a data flow, 3935 identified by (anchor) Connection ID and Traffic Class ID. 3937 When the bit-reversal bit is set to 1, the burst size L MUST be a power 3938 of 2, and the traffic splitting function is 3940 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 3942 Wherein F(.) is the bit reversal function [BITR] of the input variable. 3944 5.7 Acknowledgement Message 3946 The "Type" field is set to "6" for ACK messages. 3948 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 3949 successful reception of a PLR, FSN, or TSU message. 3951 C-MADP SHOULD send out the ACK message in response to a Probe message 3952 with the ACK flag set to "1". 3954 The ACK message consists of the following fields: 3956 o Acknowledgment Number (2 Bytes): the sequence number of the 3957 received message. 3958 o Timestamp (4 Bytes): the current value of the timestamp clock of 3959 the sender in the unit of 100 microseconds. 3961 6 Security Considerations 3963 User data in MAMS framework rely on the security of the underlying 3964 network transport paths. When this cannot be assumed, NCM configures 3965 use of appropriate protocols for security, e.g. IPsec [RFC4301] 3966 [RFC3948], DTLS [RFC6347]. 3968 7 IANA Considerations 3970 This draft makes no requests of IANA. 3972 8 Contributing Authors 3974 The editors gratefully acknowledge the following additional 3975 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 3976 Pentakota/Nokia. 3978 9 References 3980 9.1 Normative References 3982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3983 Requirement Levels", BCP 14, RFC 2119, March 1997. 3985 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3986 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 3987 December 2005, . 3989 9.2 Informative References 3991 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3992 Security Version 1.2", RFC 6347, January 2012, 3993 . 3995 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 3996 Kivinen, "Internet Key Exchange Protocol Version 2 3997 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 3998 2014, . 4000 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 4001 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 4002 3948, DOI 10.17487/RFC3948, January 2005, . 4005 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 4006 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 4007 mechanism-02 4009 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 4010 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 4011 plain-mode-09.txt 4013 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 4014 Access Management Protocol", 4015 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 4016 protocol-03 4018 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 4019 Multi-Access Convergence", 4020 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 4022 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 4023 (GRE)", RFC 2784 March 2000, . 4026 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 4027 RFC 2890 September 2000, . 4030 [IANA] https://www.iana.org/assignments/protocol- 4031 numbers/protocol-numbers.xhtml 4033 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 4034 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 4035 Tunnel (LWIP) encapsulation; Protocol specification" 4037 [RFC791] Internet Protocol, September 1981 4039 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 4040 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 4041 IEEE Access, 2017 4043 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 4044 arXiv:1212.2291, 2012 4046 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 4047 Symbol Representation, https://www.ietf.org/id/draft- 4048 heide-nwcrg-rlnc-00.txt 4050 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 4051 38 (1): 1-26, 1996. 4053 Authors' Addresses 4055 Jing Zhu 4057 Intel 4059 Email: jing.z.zhu@intel.com 4060 SungHoon Seo 4062 Korea Telecom 4064 Email: sh.seo@kt.com 4066 Satish Kanugovi 4068 Nokia 4070 Email: satish.k@nokia.com 4072 Shuping Peng 4074 Huawei 4076 Email: pengshuping@huawei.com 4078 INTAREA J. Zhu 4079 Internet Draft Intel 4080 Intended status: Standards Track S. Seo 4081 Expires: April 1,2020 Korea Telecom 4082 S. Kanugovi 4083 Nokia 4084 S. Peng 4085 Huawei 4086 October 1, 2019 4088 User-Plane Protocols for Multiple Access Management Service 4089 draft-zhu-intarea-mams-user-protocol-07 4091 Status of this Memo 4093 This Internet-Draft is submitted in full conformance with the 4094 provisions of BCP 78 and BCP 79. 4096 Internet-Drafts are working documents of the Internet Engineering 4097 Task Force (IETF), its areas, and its working groups. Note that 4098 other groups may also distribute working documents as Internet- 4099 Drafts. 4101 Internet-Drafts are draft documents valid for a maximum of six 4102 months and may be updated, replaced, or obsoleted by other documents 4103 at any time. It is inappropriate to use Internet-Drafts as 4104 reference material or to cite them other than as "work in progress." 4106 The list of current Internet-Drafts can be accessed at 4107 http://www.ietf.org/ietf/1id-abstracts.txt 4109 The list of Internet-Draft Shadow Directories can be accessed at 4110 http://www.ietf.org/shadow.html 4112 This Internet-Draft will expire on April 1,2020. 4114 Copyright Notice 4116 Copyright (c) 2019 IETF Trust and the persons identified as the 4117 document authors. All rights reserved. 4119 This document is subject to BCP 78 and the IETF Trust's Legal 4120 Provisions Relating to IETF Documents 4121 (http://trustee.ietf.org/license-info) in effect on the date of 4122 publication of this document. Please review these documents 4123 carefully, as they describe your rights and restrictions with 4124 respect to this document. Code Components extracted from this 4125 document must include Simplified BSD License text as described in 4126 Section 4.e of the Trust Legal Provisions and are provided without 4127 warranty as described in the Simplified BSD License. 4129 Abstract 4131 Today, a device can be simultaneously connected to multiple 4132 communication networks based on different technology implementations 4133 and network architectures like WiFi, LTE, and DSL. In such multi- 4134 connectivity scenario, it is desirable to combine multiple access 4135 networks or select the best one to improve quality of experience for 4136 a user and improve overall network utilization and efficiency. This 4137 document presents the u-plane protocols for a multi access 4138 management services (MAMS) framework that can be used to flexibly 4139 select the combination of uplink and downlink access and core 4140 network paths having the optimal performance, and user plane 4141 treatment for improving network utilization and efficiency and 4142 enhanced quality of experience for user applications. 4144 Table of Contents 4146 1. Introduction...................................................3 4147 2. Terminologies..................................................3 4148 3. Conventions used in this document..............................3 4149 4 MAMS User-Plane Protocols......................................4 4150 4.1 MX Adaptation Sublayer...................................4 4151 4.2 GMA-based MX Convergence Sublayer........................5 4152 4.3 MPTCP-based MX Convergence Sublayer......................6 4153 4.4 GRE as MX Convergence Sublayer...........................6 4154 4.4.1 Transmitter Procedures.............................7 4155 4.4.2 Receiver Procedures................................8 4156 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 4157 8 4158 5. MX Convergence Control Message.................................8 4159 5.1 Keep-Alive Message.......................................9 4160 5.2 Probe Message............................................9 4161 5.3 Packet Loss Report (PLR) Message........................10 4162 5.4 First Sequence Number (FSN) Message.....................11 4163 5.5 Coded MX SDU (CMS) Message..............................12 4164 5.6 Traffic Splitting Update (TSU) Message..................13 4165 5.7 Acknowledgement Message.................................14 4166 6 Security Considerations.......................................14 4167 7 IANA Considerations...........................................15 4168 8 Contributing Authors..........................................15 4169 9 References....................................................15 4170 9.1 Normative References....................................15 4171 9.2 Informative References..................................15 4173 1. Introduction 4175 Multi Access Management Service (MAMS) [MAMS] is a programmable 4176 framework to select and configure network paths, as well as adapt to 4177 dynamic network conditions, when multiple network connections can 4178 serve a client device. It is based on principles of user plane 4179 interworking that enables the solution to be deployed as an overlay 4180 without impacting the underlying networks. 4182 This document presents the u-plane protocols for enabling the MAMS 4183 framework. It co-exists and complements the existing protocols by 4184 providing a way to negotiate and configure the protocols based on 4185 client and network capabilities. Further it allows exchange of 4186 network state information and leveraging network intelligence to 4187 optimize the performance of such protocols. An important goal for 4188 MAMS is to ensure that there is minimal or no dependency on the 4189 actual access technology of the participating links. This allows the 4190 scheme to be scalable for addition of newer access technologies and 4191 for independent evolution of the existing access technologies. 4193 2. Terminologies 4195 Anchor Connection: refers to the network path from the N-MADP to the 4196 Application Server that corresponds to a specific IP anchor that has 4197 assigned an IP address to the client. 4199 Delivery Connection: refers to the network path from the N-MADP to 4200 the C-MADP. 4202 "Network Connection Manager" (NCM), "Client Connection Manager" 4203 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 4204 Access Data Proxy" (C-MADP) in this document are to be interpreted 4205 as described in [MAMS]. 4207 3. Conventions used in this document 4209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 4210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 4211 document are to be interpreted as described in [RFC2119]. 4213 The terminologies "Network Connection Manager" (NCM), "Client 4214 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 4215 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 4216 document are to be interpreted as described in [MAMS]. 4218 4 MAMS User-Plane Protocols 4220 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 4221 +-----------------------------------------------------+ 4222 | User Payload (e.g. IP PDU) | 4223 |-----------------------------------------------------| 4224 +--|-----------------------------------------------------|--+ 4225 | |-----------------------------------------------------| | 4226 | | Multi-Access (MX) Convergence Sublayer | | 4227 | |-----------------------------------------------------| | 4228 | |-----------------------------------------------------| | 4229 | | MX Adaptation | MX Adaptation | MX Adaptation | | 4230 | | Sublayer | Sublayer | Sublayer | | 4231 | | (optional) | (optional) | (optional) | | 4232 | |-----------------------------------------------------| | 4233 | | Access #1 IP | Access #2 IP | Access #3 IP | | 4234 | +-----------------------------------------------------+ | 4235 +-----------------------------------------------------------+ 4236 Figure 1: MAMS U-plane Protocol Stack 4237 It consists of the following two Sublayers: 4239 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 4240 access specific tasks, e.g., access (path) selection, multi-link 4241 (path) aggregation, splitting/reordering, lossless switching, 4242 fragmentation, concatenation, keep-alive, and probing etc. 4243 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 4244 to handle tunneling, network layer security, and NAT. 4246 The MX convergence sublayer operates on top of the MX adaptation 4247 sublayer in the protocol stack. From the Transmitter perspective, a 4248 User Payload (e.g. IP PDU) is processed by the convergence sublayer 4249 first, and then by the adaptation sublayer before being transported 4250 over a delivery access connection; from the Receiver perspective, an IP 4251 packet received over a delivery connection is processed by the MX 4252 adaptation sublayer first, and then by the MX convergence sublayer. 4254 4.1 MX Adaptation Sublayer 4256 The MX adaptation sublayer supports the following mechanisms and 4257 protocols while transmitting user plane packets on the network path: 4259 o UDP Tunneling: The user plane packets of the anchor connection can be 4260 encapsulated in a UDP tunnel of a delivery connection between the N- 4261 MADP and C-MADP. 4263 o IPsec Tunneling: The user plane packets of the anchor connection are 4264 sent through an IPsec tunnel of a delivery connection. 4265 o Client Net Address Translation (NAT): The Client IP address of user 4266 plane packet of the anchor connection is changed, and sent over a 4267 delivery connection. 4268 o Pass Through: The user plane packets are passing through without any 4269 change over the anchor connection. 4271 The MX adaptation sublayer also supports the following mechanisms and 4272 protocols to ensure security of user plane packets over the network 4273 path. 4275 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 4276 N-MADP and C-MADP on the network path that is considered untrusted. 4277 o DTLS: If UDP tunneling is used on the network path that is considered 4278 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 4279 be used. 4281 The Client NAT method is the most efficient due to no tunneling 4282 overhead. It SHOULD be used if a delivery connection is "trusted" and 4283 without NAT function on the path. 4285 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 4286 connection has a NAT function placed on the path. 4288 4.2 GMA-based MX Convergence Sublayer 4290 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 4291 encapsulation [GMA]. Multiple access networks are combined into a 4292 single IP connection. If NCM determines that N-MADP is to be 4293 instantiated with GMA as the MX Convergence Protocol, it exchanges the 4294 support of GMA convergence capability in the discovery and capability 4295 exchange procedures [MAMS]. 4297 +-----------------------------------------------------+ 4298 | IP PDU | 4299 |-----------------------------------------------------| 4300 | GMA Convergence Sublayer | 4301 |-----------------------------------------------------| 4302 | MX Adaptation | MX Adaptation | MX Adaptation | 4303 | Sublayer | Sublayer | Sublayer | 4304 | (optional) | (optional) | (optional) | 4305 |-----------------------------------------------------| 4306 | Access #1 IP | Access #2 IP | Access #3 IP | 4307 +-----------------------------------------------------+ 4308 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 4310 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 4311 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 4312 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 4313 message [MAMS] is true, the "IP length" and "IP checksum" header fields 4314 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 4315 updated after adding or removing the GMA trailer in the convergence 4316 sublayer. 4318 +------------------------------------------------------+ 4319 | IP hdr | IP payload | GMA Trailer | 4320 +------------------------------------------------------+ 4321 Figure 3: GMA PDU Format 4323 4.3 MPTCP-based MX Convergence Sublayer 4325 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 4326 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 4327 access networks are combined into a single MPTCP connection. Hence, no 4328 new u-plane protocol or PDU format is needed in this case. 4330 |-----------------------------------------------------| 4331 | MPTCP | 4332 |-----------------------------------------------------| 4333 | TCP | TCP | TCP | 4334 |-----------------------------------------------------| 4335 | MX Adaptation | MX Adaptation | MX Adaptation | 4336 | Sublayer | Sublayer | Sublayer | 4337 | (optional) | (optional) | (optional) | 4338 |-----------------------------------------------------| 4339 | Access #1 IP | Access #2 IP | Access #3 IP | 4340 +-----------------------------------------------------+ 4341 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 4342 Layer 4344 If NCM determines that N-MADP is to be instantiated with MPTCP as the 4345 MX Convergence Protocol, it exchanges the support of MPTCP capability 4346 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 4347 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 4348 and aggregation over multiple delivery connections. 4350 4.4 GRE as MX Convergence Sublayer 4352 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 4353 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 4354 Convergence sub-layer" protocol. Multiple access networks are combined 4355 into a single GRE connection. Hence, no new u-plane protocol or PDU 4356 format is needed in this case. 4358 +-----------------------------------------------------+ 4359 | User Payload (e.g. IP PDU) | 4360 |-----------------------------------------------------| 4361 | GRE as MX Convergence Sublayer | 4362 |-----------------------------------------------------| 4363 | GRE Delivery Protocol (e.g. IP) | 4364 |-----------------------------------------------------| 4365 | MX Adaptation | MX Adaptation | MX Adaptation | 4366 | Sublayer | Sublayer | Sublayer | 4367 | (optional) | (optional) | (optional) | 4368 |-----------------------------------------------------| 4369 | Access #1 IP | Access #2 IP | Access #3 IP | 4370 +-----------------------------------------------------+ 4371 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 4372 Layer 4374 If NCM determines that N-MADP is to be instantiated with GRE as the MX 4375 Convergence Protocol, it exchanges the support of GRE capability in the 4376 discovery and capability exchange procedures [MAMS]. 4378 4.4.1 Transmitter Procedures 4380 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 4381 the convergence protocol that transmits the GRE packets. The 4382 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 4383 with a GRE header and Delivery Protocol (e.g. IP) header to generate 4384 the GRE Convergence PDU. 4386 When IP is used as the GRE delivery protocol, the IP header information 4387 (e.g. IP address) can be created using the IP header of the user 4388 payload or a virtual IP address. The "Protocol Type" field of the 4389 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 4391 The GRE header fields are set as specified below, 4393 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 4394 to the value of Connection ID for the Anchor Connection associated 4395 with the user payload or sets to 0xFFFF if no Anchor Connection ID 4396 needs to be specified. 4397 - All other fields in the GRE header including the remaining bits in 4398 the key fields are set as per [GRE_2784][GRE_2890]. 4400 4.4.2 Receiver Procedures 4402 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 4403 convergence protocol that receives the GRE packets. The receiver 4404 processes the received packets per the GRE procedures [GRE_2784, 4405 GRE_2890] and retrieves the GRE header. 4407 - If the Receiver is an N-MADP instance, 4408 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 4409 interpreted as the Connection ID of Anchor Connection for the 4410 user payload. This is used to identify the network path over 4411 which the User Payload (GRE Payload) is to be transmitted. 4412 - All other fields in the GRE header, including the remaining bits 4413 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 4415 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 4416 present) before delivery over one of the network paths. 4418 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 4420 MAMS u-plane protocols support multiple combinations and instances of 4421 user plane protocols to be used in the MX Adaptation and the 4422 Convergence sublayers. 4424 For example, one instance of the MX Convergence Layer can be MPTCP 4425 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 4426 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 4427 set up for network paths considered as untrusted by the operator, to 4428 protect the TCP subflow between client and MPTCP proxy traversing that 4429 network path. 4431 Each of the instances of MAMS user plane, i.e. combination of MX 4432 Convergence and MX Adaptation layer protocols, can coexist 4433 simultaneously and independently handle different traffic types. 4435 5. MX Convergence Control Message 4437 A UDP connection may be configured between C-MADP and N-MADP to 4438 exchange control messages for keep-alive or path quality estimation. 4439 The N-MADP end-point IP address and UDP port number of the UDP 4440 connection is used to identify MX control PDU. Figure 6 shows the MX 4441 control PDU format with the following fields: 4443 o Type (1 Byte): the type of the MX control message 4444 o CID (1 Byte): an unsigned integer to identify the anchor and 4445 delivery connection of the MX control message 4446 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 4447 identify the anchor connection 4448 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 4449 identify the delivery connection 4450 o MX Control Message (variable): the payload of the MX control 4451 message 4453 Figure 7 shows the MX convergence control protocol stack, and MX 4454 control PDU goes through the MX adaptation sublayer the same way as MX 4455 data PDU. 4457 <----MX Control PDU Payload ---------------> 4458 +------------------------------------------------------------------+ 4459 | IP header | UDP Header| Type | CID | MX Control Message | 4460 +------------------------------------------------------------------+ 4461 Figure 6: MX Control PDU Format 4463 |-----------------------------------------------------| 4464 | MX Convergence Control Messages | 4465 |-----------------------------------------------------| 4466 | UDP/IP | 4467 |-----------------------------------------------------| 4468 | MX Adaptation | MX Adaptation | MX Adaptation | 4469 | Sublayer | Sublayer | Sublayer | 4470 | (optional) | (optional) | (optional) | 4471 |-----------------------------------------------------| 4472 | Access #1 IP | Access #2 IP | Access #3 IP | 4473 +-----------------------------------------------------+ 4474 Figure 7: MX Convergence Control Protocol Stack 4476 5.1 Keep-Alive Message 4478 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 4479 out Keep-Alive message periodically over one or multiple delivery 4480 connections, especially if UDP tunneling is used as the adaptation 4481 method for the delivery connection with a NAT function on the path. 4483 A Keep-Alive message is 6 Bytes long, and consists of the following 4484 fields: 4486 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 4487 keep-alive message 4488 o Timestamp (4 Bytes): the current value of the timestamp clock of 4489 the sender in the unit of 100 microseconds. 4491 5.2 Probe Message 4493 The "Type" field is set to "1" for Probe messages. 4495 N-MADP may send out the Probe message for path quality estimation. In 4496 response, C-MADP may send back the ACK message. 4498 A Probe message consists of the following fields: 4500 o Probing Sequence Number (2 Bytes): the sequence number of the 4501 Probe REQ message 4502 o Probing Flag (1 Byte): 4503 + Bit #0: a ACK flag to indicate if the ACK message is expected 4504 (1) or not (0); 4505 + Bit #1: a Probe Type flag to indicate if the Probe message is 4506 sent during the initialization phase (0) when the network 4507 path is not included for transmission of user data or the 4508 active phase (1) when the network path is included for 4509 transmission of user data; 4510 + Bit #2: a bit flag to indicate the presence of the Reverse 4511 Connection ID (R-CID) field. 4512 + Bit #3~7: reserved 4513 o Reverse Connection ID (1 Byte): the connection ID of the delivery 4514 connection for sending out the ACK message on the reverse path 4515 o Timestamp (4 Bytes): the current value of the timestamp clock of 4516 the sender in the unit of 100 microseconds. 4517 o Padding (variable) 4519 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 4520 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 4521 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 4522 ACK message is not expected. 4524 If the "R-CID" field is not present but the Bit #0 of the "Probing 4525 Flag" field is set to "1", the ACK message SHOULD be sent over the same 4526 delivery connection as the Probe message. 4528 The "Padding" field is used to control the length of Probe message. 4530 5.3 Packet Loss Report (PLR) Message 4532 The "Type" field is set to "2" for PLR messages. 4534 C-MADP may send out the PLR messages to report lost MX SDU for example 4535 during handover. In response, C-MADP may retransmit the lost MX SDU 4536 accordingly. 4538 A PLR message consists of the following fields: 4540 o Connection ID (1 Byte): an unsigned integer to identify the anchor 4541 connection which the ACK message is for; 4543 o Traffic Class ID (1 Byte): an unsigned integer to identify the 4544 traffic class of the anchor connection which the ACK message is 4545 for; 4546 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 4547 that the sender of the PLR message is expecting 4548 o Number of Loss Bursts (1 Byte) 4549 For each loss burst, include the following 4550 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 4551 + Number of consecutive lost MX SDUs in the burst (1 Byte) 4553 C-MADP N-MADP 4554 | | 4555 |<------------------ MX SDU (data packets)--------| 4556 | | 4557 +---------------------------------+ | 4558 |Packet Loss detected | | 4559 +---------------------------------+ | 4560 | | 4561 |----- PLR Message ------------------------------>| 4562 |<-------------retransmit(lost)MX SDUs -----------| 4564 Figure 8: MAMS Retransmission Procedure 4566 Figure 8 shows the MAMS retransmission procedure in an example where 4567 the lost packet is found and retransmitted. 4569 5.4 First Sequence Number (FSN) Message 4571 The "Type" field is set to "3" for FSN messages. 4573 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 4574 its buffer if a lost MX SDU is not found in the buffer after receiving 4575 the PLR message from C-MADP. In response, C-MADP SHALL only report 4576 packet loss with SN not smaller than FSN. 4578 A FSN message consists of the following fields: 4580 o Connection ID (1 Byte): an unsigned integer to identify the anchor 4581 connection which the FSN message is for; 4582 o Traffic Class ID (1 Byte): an unsigned integer to identify the 4583 traffic class of the anchor connection which the FSN message is 4584 for; 4585 o First Sequence Number (4 Bytes): the sequence number (SN) of the 4586 oldest MX SDU in the (retransmission) buffer of the sender of the 4587 FSN message. 4589 Figure 9 shows the MAMS retransmission procedure in an example where 4590 the lost packet is not found. 4592 C-MADP N-MADP 4593 | | 4594 |<------------------ MX SDU (data packets)--------| 4595 | | 4596 +---------------------------------+ | 4597 |Packet Loss detected | | 4598 +---------------------------------+ | 4599 | | 4600 |----- PLR Message ------------------------------>| 4601 | +---------------------+ 4602 | |Lost packet not found| 4603 | +---------------------+ 4604 |<-------------FSN message -----------------------| 4606 Figure 9: MAMS Retransmission Procedure with FSN 4608 5.5 Coded MX SDU (CMS) Message 4610 The "Type" field is set to "4" for CMS messages. 4612 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 4613 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 4614 [RLNC]. A coded MX SDU is generated by applying a network coding 4615 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 4616 fast recovery without retransmission if any of the MX SDUs is lost. 4618 A Coded MX SDU message consists of the following fields: 4620 o Connection ID (1 Byte): an unsigned integer to identify the anchor 4621 connection of the coded MX SDU; 4622 o Traffic Class ID (1 Byte): an unsigned integer to identify the 4623 traffic class of the coded MX; 4624 o Sequence Number (4 Bytes): the sequence number of the first 4625 (uncoded) MX SDU used to generate the coded MX SDU. 4626 o Fragmentation Control (FC) (1 Byte): to provide necessary 4627 information for re-assembly, only needed if the coded MX SDU is 4628 too long to transport in a single MX control PDU. 4629 o N (1 Byte): the number of consecutive MX SDUs used to generate the 4630 coded MX SDU 4631 o K (1 Byte): the length (in terms of bits) of the coding 4632 coefficient field 4633 o Coding Coefficient ( N x K / 8 Bytes) 4634 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 4635 + padding 4636 o Coded MX SDU (variable): the coded MX SDU 4638 If K = 0, the simple XOR method is used to generate the Coded MX SDU 4639 from N consecutive uncoded MX SDUs, and the a(i) fields are not 4640 included in the message. 4642 If the coded MX SDU is too long, it can be fragmented, and transported 4643 by multiple MX control PDUs. The N, K, and a(i) fields are only 4644 included in the MX PDU carrying the first fragment of the coded MX SDU. 4646 C-MADP N-MADP 4647 | | 4648 |<------------------ MX SDU #1 -------------------| 4649 | lost<-------- MX SDU #2 -------------------| 4650 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 4651 +----------------------+ | 4652 | MX SDU #2 recovered | | 4653 +----------------------+ | 4654 | | 4656 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 4658 5.6 Traffic Splitting Update (TSU) Message 4660 The "Type" field is set to "5" for TSU messages. 4662 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 4663 traffic splitting configuration has changed. 4665 A TSU message consists of the following fields: 4667 o Connection ID (1 Byte): an unsigned integer to identify the anchor 4668 connection; 4669 o Traffic Class ID (1 Byte): an unsigned integer to identify the 4670 traffic class; 4671 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 4672 message. 4673 o Flags (1 Byte) 4674 + Bit #0: a Reverse Path bit flag to indicate if the traffic 4675 splitting configuration is for the reverse path (1) or not 4676 (0); 4677 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 4678 used in traffic splitting 4679 + Others: reserved. 4680 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 4682 + StartSN (4 Bytes): the sequence number of the first MX SDU 4683 using the traffic splitting configuration provided by the TSU 4684 message 4685 + L (1 Byte): the traffic splitting burst size 4686 + K(i): the traffic splitting threshold of the i-th delivery 4687 connection, where connections are ordered according to their 4688 Connection ID. 4690 Let's use f(x) to denote the traffic splitting function, which maps a 4691 MX SDU Sequence Number "x" to the i-th delivery connection. 4693 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 4695 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 4697 N is the total number of connections for delivering a data flow, 4698 identified by (anchor) Connection ID and Traffic Class ID. 4700 When the bit-reversal bit is set to 1, the burst size L MUST be a power 4701 of 2, and the traffic splitting function is 4703 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 4705 Wherein F(.) is the bit reversal function [BITR] of the input variable. 4707 5.7 Acknowledgement Message 4709 The "Type" field is set to "6" for ACK messages. 4711 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 4712 successful reception of a PLR, FSN, or TSU message. 4714 C-MADP SHOULD send out the ACK message in response to a Probe message 4715 with the ACK flag set to "1". 4717 The ACK message consists of the following fields: 4719 o Acknowledgment Number (2 Bytes): the sequence number of the 4720 received message. 4721 o Timestamp (4 Bytes): the current value of the timestamp clock of 4722 the sender in the unit of 100 microseconds. 4724 6 Security Considerations 4726 User data in MAMS framework rely on the security of the underlying 4727 network transport paths. When this cannot be assumed, NCM configures 4728 use of appropriate protocols for security, e.g. IPsec [RFC4301] 4729 [RFC3948], DTLS [RFC6347]. 4731 7 IANA Considerations 4733 This draft makes no requests of IANA. 4735 8 Contributing Authors 4737 The editors gratefully acknowledge the following additional 4738 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 4739 Pentakota/Nokia. 4741 9 References 4743 9.1 Normative References 4745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4746 Requirement Levels", BCP 14, RFC 2119, March 1997. 4748 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 4749 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 4750 December 2005, . 4752 9.2 Informative References 4754 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4755 Security Version 1.2", RFC 6347, January 2012, 4756 . 4758 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 4759 Kivinen, "Internet Key Exchange Protocol Version 2 4760 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 4761 2014, . 4763 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 4764 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 4765 3948, DOI 10.17487/RFC3948, January 2005, . 4768 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 4769 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 4770 mechanism-02 4772 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 4773 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 4774 plain-mode-09.txt 4776 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 4777 Access Management Protocol", 4778 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 4779 protocol-03 4781 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 4782 Multi-Access Convergence", 4783 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 4785 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 4786 (GRE)", RFC 2784 March 2000, . 4789 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 4790 RFC 2890 September 2000, . 4793 [IANA] https://www.iana.org/assignments/protocol- 4794 numbers/protocol-numbers.xhtml 4796 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 4797 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 4798 Tunnel (LWIP) encapsulation; Protocol specification" 4800 [RFC791] Internet Protocol, September 1981 4802 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 4803 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 4804 IEEE Access, 2017 4806 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 4807 arXiv:1212.2291, 2012 4809 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 4810 Symbol Representation, https://www.ietf.org/id/draft- 4811 heide-nwcrg-rlnc-00.txt 4813 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 4814 38 (1): 1-26, 1996. 4816 Authors' Addresses 4818 Jing Zhu 4820 Intel 4822 Email: jing.z.zhu@intel.com 4823 SungHoon Seo 4825 Korea Telecom 4827 Email: sh.seo@kt.com 4829 Satish Kanugovi 4831 Nokia 4833 Email: satish.k@nokia.com 4835 Shuping Peng 4837 Huawei 4839 Email: pengshuping@huawei.com 4841 INTAREA J. Zhu 4842 Internet Draft Intel 4843 Intended status: Standards Track S. Seo 4844 Expires: April 1,2020 Korea Telecom 4845 S. Kanugovi 4846 Nokia 4847 S. Peng 4848 Huawei 4849 October 1, 2019 4851 User-Plane Protocols for Multiple Access Management Service 4852 draft-zhu-intarea-mams-user-protocol-07 4854 Status of this Memo 4856 This Internet-Draft is submitted in full conformance with the 4857 provisions of BCP 78 and BCP 79. 4859 Internet-Drafts are working documents of the Internet Engineering 4860 Task Force (IETF), its areas, and its working groups. Note that 4861 other groups may also distribute working documents as Internet- 4862 Drafts. 4864 Internet-Drafts are draft documents valid for a maximum of six 4865 months and may be updated, replaced, or obsoleted by other documents 4866 at any time. It is inappropriate to use Internet-Drafts as 4867 reference material or to cite them other than as "work in progress." 4869 The list of current Internet-Drafts can be accessed at 4870 http://www.ietf.org/ietf/1id-abstracts.txt 4872 The list of Internet-Draft Shadow Directories can be accessed at 4873 http://www.ietf.org/shadow.html 4875 This Internet-Draft will expire on April 1,2020. 4877 Copyright Notice 4879 Copyright (c) 2019 IETF Trust and the persons identified as the 4880 document authors. All rights reserved. 4882 This document is subject to BCP 78 and the IETF Trust's Legal 4883 Provisions Relating to IETF Documents 4884 (http://trustee.ietf.org/license-info) in effect on the date of 4885 publication of this document. Please review these documents 4886 carefully, as they describe your rights and restrictions with 4887 respect to this document. Code Components extracted from this 4888 document must include Simplified BSD License text as described in 4889 Section 4.e of the Trust Legal Provisions and are provided without 4890 warranty as described in the Simplified BSD License. 4892 Abstract 4894 Today, a device can be simultaneously connected to multiple 4895 communication networks based on different technology implementations 4896 and network architectures like WiFi, LTE, and DSL. In such multi- 4897 connectivity scenario, it is desirable to combine multiple access 4898 networks or select the best one to improve quality of experience for 4899 a user and improve overall network utilization and efficiency. This 4900 document presents the u-plane protocols for a multi access 4901 management services (MAMS) framework that can be used to flexibly 4902 select the combination of uplink and downlink access and core 4903 network paths having the optimal performance, and user plane 4904 treatment for improving network utilization and efficiency and 4905 enhanced quality of experience for user applications. 4907 Table of Contents 4909 1. Introduction...................................................3 4910 2. Terminologies..................................................3 4911 3. Conventions used in this document..............................3 4912 4 MAMS User-Plane Protocols......................................4 4913 4.1 MX Adaptation Sublayer...................................4 4914 4.2 GMA-based MX Convergence Sublayer........................5 4915 4.3 MPTCP-based MX Convergence Sublayer......................6 4916 4.4 GRE as MX Convergence Sublayer...........................6 4917 4.4.1 Transmitter Procedures.............................7 4918 4.4.2 Receiver Procedures................................8 4919 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 4920 8 4921 5. MX Convergence Control Message.................................8 4922 5.1 Keep-Alive Message.......................................9 4923 5.2 Probe Message............................................9 4924 5.3 Packet Loss Report (PLR) Message........................10 4925 5.4 First Sequence Number (FSN) Message.....................11 4926 5.5 Coded MX SDU (CMS) Message..............................12 4927 5.6 Traffic Splitting Update (TSU) Message..................13 4928 5.7 Acknowledgement Message.................................14 4929 6 Security Considerations.......................................14 4930 7 IANA Considerations...........................................15 4931 8 Contributing Authors..........................................15 4932 9 References....................................................15 4933 9.1 Normative References....................................15 4934 9.2 Informative References..................................15 4936 1. Introduction 4938 Multi Access Management Service (MAMS) [MAMS] is a programmable 4939 framework to select and configure network paths, as well as adapt to 4940 dynamic network conditions, when multiple network connections can 4941 serve a client device. It is based on principles of user plane 4942 interworking that enables the solution to be deployed as an overlay 4943 without impacting the underlying networks. 4945 This document presents the u-plane protocols for enabling the MAMS 4946 framework. It co-exists and complements the existing protocols by 4947 providing a way to negotiate and configure the protocols based on 4948 client and network capabilities. Further it allows exchange of 4949 network state information and leveraging network intelligence to 4950 optimize the performance of such protocols. An important goal for 4951 MAMS is to ensure that there is minimal or no dependency on the 4952 actual access technology of the participating links. This allows the 4953 scheme to be scalable for addition of newer access technologies and 4954 for independent evolution of the existing access technologies. 4956 2. Terminologies 4958 Anchor Connection: refers to the network path from the N-MADP to the 4959 Application Server that corresponds to a specific IP anchor that has 4960 assigned an IP address to the client. 4962 Delivery Connection: refers to the network path from the N-MADP to 4963 the C-MADP. 4965 "Network Connection Manager" (NCM), "Client Connection Manager" 4966 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 4967 Access Data Proxy" (C-MADP) in this document are to be interpreted 4968 as described in [MAMS]. 4970 3. Conventions used in this document 4972 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 4973 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 4974 document are to be interpreted as described in [RFC2119]. 4976 The terminologies "Network Connection Manager" (NCM), "Client 4977 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 4978 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 4979 document are to be interpreted as described in [MAMS]. 4981 4 MAMS User-Plane Protocols 4983 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 4984 +-----------------------------------------------------+ 4985 | User Payload (e.g. IP PDU) | 4986 |-----------------------------------------------------| 4987 +--|-----------------------------------------------------|--+ 4988 | |-----------------------------------------------------| | 4989 | | Multi-Access (MX) Convergence Sublayer | | 4990 | |-----------------------------------------------------| | 4991 | |-----------------------------------------------------| | 4992 | | MX Adaptation | MX Adaptation | MX Adaptation | | 4993 | | Sublayer | Sublayer | Sublayer | | 4994 | | (optional) | (optional) | (optional) | | 4995 | |-----------------------------------------------------| | 4996 | | Access #1 IP | Access #2 IP | Access #3 IP | | 4997 | +-----------------------------------------------------+ | 4998 +-----------------------------------------------------------+ 4999 Figure 1: MAMS U-plane Protocol Stack 5000 It consists of the following two Sublayers: 5002 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 5003 access specific tasks, e.g., access (path) selection, multi-link 5004 (path) aggregation, splitting/reordering, lossless switching, 5005 fragmentation, concatenation, keep-alive, and probing etc. 5006 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 5007 to handle tunneling, network layer security, and NAT. 5009 The MX convergence sublayer operates on top of the MX adaptation 5010 sublayer in the protocol stack. From the Transmitter perspective, a 5011 User Payload (e.g. IP PDU) is processed by the convergence sublayer 5012 first, and then by the adaptation sublayer before being transported 5013 over a delivery access connection; from the Receiver perspective, an IP 5014 packet received over a delivery connection is processed by the MX 5015 adaptation sublayer first, and then by the MX convergence sublayer. 5017 4.1 MX Adaptation Sublayer 5019 The MX adaptation sublayer supports the following mechanisms and 5020 protocols while transmitting user plane packets on the network path: 5022 o UDP Tunneling: The user plane packets of the anchor connection can be 5023 encapsulated in a UDP tunnel of a delivery connection between the N- 5024 MADP and C-MADP. 5026 o IPsec Tunneling: The user plane packets of the anchor connection are 5027 sent through an IPsec tunnel of a delivery connection. 5028 o Client Net Address Translation (NAT): The Client IP address of user 5029 plane packet of the anchor connection is changed, and sent over a 5030 delivery connection. 5031 o Pass Through: The user plane packets are passing through without any 5032 change over the anchor connection. 5034 The MX adaptation sublayer also supports the following mechanisms and 5035 protocols to ensure security of user plane packets over the network 5036 path. 5038 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 5039 N-MADP and C-MADP on the network path that is considered untrusted. 5040 o DTLS: If UDP tunneling is used on the network path that is considered 5041 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 5042 be used. 5044 The Client NAT method is the most efficient due to no tunneling 5045 overhead. It SHOULD be used if a delivery connection is "trusted" and 5046 without NAT function on the path. 5048 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 5049 connection has a NAT function placed on the path. 5051 4.2 GMA-based MX Convergence Sublayer 5053 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 5054 encapsulation [GMA]. Multiple access networks are combined into a 5055 single IP connection. If NCM determines that N-MADP is to be 5056 instantiated with GMA as the MX Convergence Protocol, it exchanges the 5057 support of GMA convergence capability in the discovery and capability 5058 exchange procedures [MAMS]. 5060 +-----------------------------------------------------+ 5061 | IP PDU | 5062 |-----------------------------------------------------| 5063 | GMA Convergence Sublayer | 5064 |-----------------------------------------------------| 5065 | MX Adaptation | MX Adaptation | MX Adaptation | 5066 | Sublayer | Sublayer | Sublayer | 5067 | (optional) | (optional) | (optional) | 5068 |-----------------------------------------------------| 5069 | Access #1 IP | Access #2 IP | Access #3 IP | 5070 +-----------------------------------------------------+ 5071 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 5073 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 5074 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 5075 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 5076 message [MAMS] is true, the "IP length" and "IP checksum" header fields 5077 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 5078 updated after adding or removing the GMA trailer in the convergence 5079 sublayer. 5081 +------------------------------------------------------+ 5082 | IP hdr | IP payload | GMA Trailer | 5083 +------------------------------------------------------+ 5084 Figure 3: GMA PDU Format 5086 4.3 MPTCP-based MX Convergence Sublayer 5088 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 5089 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 5090 access networks are combined into a single MPTCP connection. Hence, no 5091 new u-plane protocol or PDU format is needed in this case. 5093 |-----------------------------------------------------| 5094 | MPTCP | 5095 |-----------------------------------------------------| 5096 | TCP | TCP | TCP | 5097 |-----------------------------------------------------| 5098 | MX Adaptation | MX Adaptation | MX Adaptation | 5099 | Sublayer | Sublayer | Sublayer | 5100 | (optional) | (optional) | (optional) | 5101 |-----------------------------------------------------| 5102 | Access #1 IP | Access #2 IP | Access #3 IP | 5103 +-----------------------------------------------------+ 5104 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 5105 Layer 5107 If NCM determines that N-MADP is to be instantiated with MPTCP as the 5108 MX Convergence Protocol, it exchanges the support of MPTCP capability 5109 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 5110 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 5111 and aggregation over multiple delivery connections. 5113 4.4 GRE as MX Convergence Sublayer 5115 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 5116 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 5117 Convergence sub-layer" protocol. Multiple access networks are combined 5118 into a single GRE connection. Hence, no new u-plane protocol or PDU 5119 format is needed in this case. 5121 +-----------------------------------------------------+ 5122 | User Payload (e.g. IP PDU) | 5123 |-----------------------------------------------------| 5124 | GRE as MX Convergence Sublayer | 5125 |-----------------------------------------------------| 5126 | GRE Delivery Protocol (e.g. IP) | 5127 |-----------------------------------------------------| 5128 | MX Adaptation | MX Adaptation | MX Adaptation | 5129 | Sublayer | Sublayer | Sublayer | 5130 | (optional) | (optional) | (optional) | 5131 |-----------------------------------------------------| 5132 | Access #1 IP | Access #2 IP | Access #3 IP | 5133 +-----------------------------------------------------+ 5134 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 5135 Layer 5137 If NCM determines that N-MADP is to be instantiated with GRE as the MX 5138 Convergence Protocol, it exchanges the support of GRE capability in the 5139 discovery and capability exchange procedures [MAMS]. 5141 4.4.1 Transmitter Procedures 5143 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 5144 the convergence protocol that transmits the GRE packets. The 5145 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 5146 with a GRE header and Delivery Protocol (e.g. IP) header to generate 5147 the GRE Convergence PDU. 5149 When IP is used as the GRE delivery protocol, the IP header information 5150 (e.g. IP address) can be created using the IP header of the user 5151 payload or a virtual IP address. The "Protocol Type" field of the 5152 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 5154 The GRE header fields are set as specified below, 5156 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 5157 to the value of Connection ID for the Anchor Connection associated 5158 with the user payload or sets to 0xFFFF if no Anchor Connection ID 5159 needs to be specified. 5160 - All other fields in the GRE header including the remaining bits in 5161 the key fields are set as per [GRE_2784][GRE_2890]. 5163 4.4.2 Receiver Procedures 5165 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 5166 convergence protocol that receives the GRE packets. The receiver 5167 processes the received packets per the GRE procedures [GRE_2784, 5168 GRE_2890] and retrieves the GRE header. 5170 - If the Receiver is an N-MADP instance, 5171 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 5172 interpreted as the Connection ID of Anchor Connection for the 5173 user payload. This is used to identify the network path over 5174 which the User Payload (GRE Payload) is to be transmitted. 5175 - All other fields in the GRE header, including the remaining bits 5176 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 5178 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 5179 present) before delivery over one of the network paths. 5181 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 5183 MAMS u-plane protocols support multiple combinations and instances of 5184 user plane protocols to be used in the MX Adaptation and the 5185 Convergence sublayers. 5187 For example, one instance of the MX Convergence Layer can be MPTCP 5188 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 5189 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 5190 set up for network paths considered as untrusted by the operator, to 5191 protect the TCP subflow between client and MPTCP proxy traversing that 5192 network path. 5194 Each of the instances of MAMS user plane, i.e. combination of MX 5195 Convergence and MX Adaptation layer protocols, can coexist 5196 simultaneously and independently handle different traffic types. 5198 5. MX Convergence Control Message 5200 A UDP connection may be configured between C-MADP and N-MADP to 5201 exchange control messages for keep-alive or path quality estimation. 5202 The N-MADP end-point IP address and UDP port number of the UDP 5203 connection is used to identify MX control PDU. Figure 6 shows the MX 5204 control PDU format with the following fields: 5206 o Type (1 Byte): the type of the MX control message 5207 o CID (1 Byte): an unsigned integer to identify the anchor and 5208 delivery connection of the MX control message 5209 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 5210 identify the anchor connection 5211 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 5212 identify the delivery connection 5213 o MX Control Message (variable): the payload of the MX control 5214 message 5216 Figure 7 shows the MX convergence control protocol stack, and MX 5217 control PDU goes through the MX adaptation sublayer the same way as MX 5218 data PDU. 5220 <----MX Control PDU Payload ---------------> 5221 +------------------------------------------------------------------+ 5222 | IP header | UDP Header| Type | CID | MX Control Message | 5223 +------------------------------------------------------------------+ 5224 Figure 6: MX Control PDU Format 5226 |-----------------------------------------------------| 5227 | MX Convergence Control Messages | 5228 |-----------------------------------------------------| 5229 | UDP/IP | 5230 |-----------------------------------------------------| 5231 | MX Adaptation | MX Adaptation | MX Adaptation | 5232 | Sublayer | Sublayer | Sublayer | 5233 | (optional) | (optional) | (optional) | 5234 |-----------------------------------------------------| 5235 | Access #1 IP | Access #2 IP | Access #3 IP | 5236 +-----------------------------------------------------+ 5237 Figure 7: MX Convergence Control Protocol Stack 5239 5.1 Keep-Alive Message 5241 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 5242 out Keep-Alive message periodically over one or multiple delivery 5243 connections, especially if UDP tunneling is used as the adaptation 5244 method for the delivery connection with a NAT function on the path. 5246 A Keep-Alive message is 6 Bytes long, and consists of the following 5247 fields: 5249 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 5250 keep-alive message 5251 o Timestamp (4 Bytes): the current value of the timestamp clock of 5252 the sender in the unit of 100 microseconds. 5254 5.2 Probe Message 5256 The "Type" field is set to "1" for Probe messages. 5258 N-MADP may send out the Probe message for path quality estimation. In 5259 response, C-MADP may send back the ACK message. 5261 A Probe message consists of the following fields: 5263 o Probing Sequence Number (2 Bytes): the sequence number of the 5264 Probe REQ message 5265 o Probing Flag (1 Byte): 5266 + Bit #0: a ACK flag to indicate if the ACK message is expected 5267 (1) or not (0); 5268 + Bit #1: a Probe Type flag to indicate if the Probe message is 5269 sent during the initialization phase (0) when the network 5270 path is not included for transmission of user data or the 5271 active phase (1) when the network path is included for 5272 transmission of user data; 5273 + Bit #2: a bit flag to indicate the presence of the Reverse 5274 Connection ID (R-CID) field. 5275 + Bit #3~7: reserved 5276 o Reverse Connection ID (1 Byte): the connection ID of the delivery 5277 connection for sending out the ACK message on the reverse path 5278 o Timestamp (4 Bytes): the current value of the timestamp clock of 5279 the sender in the unit of 100 microseconds. 5280 o Padding (variable) 5282 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 5283 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 5284 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 5285 ACK message is not expected. 5287 If the "R-CID" field is not present but the Bit #0 of the "Probing 5288 Flag" field is set to "1", the ACK message SHOULD be sent over the same 5289 delivery connection as the Probe message. 5291 The "Padding" field is used to control the length of Probe message. 5293 5.3 Packet Loss Report (PLR) Message 5295 The "Type" field is set to "2" for PLR messages. 5297 C-MADP may send out the PLR messages to report lost MX SDU for example 5298 during handover. In response, C-MADP may retransmit the lost MX SDU 5299 accordingly. 5301 A PLR message consists of the following fields: 5303 o Connection ID (1 Byte): an unsigned integer to identify the anchor 5304 connection which the ACK message is for; 5306 o Traffic Class ID (1 Byte): an unsigned integer to identify the 5307 traffic class of the anchor connection which the ACK message is 5308 for; 5309 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 5310 that the sender of the PLR message is expecting 5311 o Number of Loss Bursts (1 Byte) 5312 For each loss burst, include the following 5313 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 5314 + Number of consecutive lost MX SDUs in the burst (1 Byte) 5316 C-MADP N-MADP 5317 | | 5318 |<------------------ MX SDU (data packets)--------| 5319 | | 5320 +---------------------------------+ | 5321 |Packet Loss detected | | 5322 +---------------------------------+ | 5323 | | 5324 |----- PLR Message ------------------------------>| 5325 |<-------------retransmit(lost)MX SDUs -----------| 5327 Figure 8: MAMS Retransmission Procedure 5329 Figure 8 shows the MAMS retransmission procedure in an example where 5330 the lost packet is found and retransmitted. 5332 5.4 First Sequence Number (FSN) Message 5334 The "Type" field is set to "3" for FSN messages. 5336 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 5337 its buffer if a lost MX SDU is not found in the buffer after receiving 5338 the PLR message from C-MADP. In response, C-MADP SHALL only report 5339 packet loss with SN not smaller than FSN. 5341 A FSN message consists of the following fields: 5343 o Connection ID (1 Byte): an unsigned integer to identify the anchor 5344 connection which the FSN message is for; 5345 o Traffic Class ID (1 Byte): an unsigned integer to identify the 5346 traffic class of the anchor connection which the FSN message is 5347 for; 5348 o First Sequence Number (4 Bytes): the sequence number (SN) of the 5349 oldest MX SDU in the (retransmission) buffer of the sender of the 5350 FSN message. 5352 Figure 9 shows the MAMS retransmission procedure in an example where 5353 the lost packet is not found. 5355 C-MADP N-MADP 5356 | | 5357 |<------------------ MX SDU (data packets)--------| 5358 | | 5359 +---------------------------------+ | 5360 |Packet Loss detected | | 5361 +---------------------------------+ | 5362 | | 5363 |----- PLR Message ------------------------------>| 5364 | +---------------------+ 5365 | |Lost packet not found| 5366 | +---------------------+ 5367 |<-------------FSN message -----------------------| 5369 Figure 9: MAMS Retransmission Procedure with FSN 5371 5.5 Coded MX SDU (CMS) Message 5373 The "Type" field is set to "4" for CMS messages. 5375 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 5376 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 5377 [RLNC]. A coded MX SDU is generated by applying a network coding 5378 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 5379 fast recovery without retransmission if any of the MX SDUs is lost. 5381 A Coded MX SDU message consists of the following fields: 5383 o Connection ID (1 Byte): an unsigned integer to identify the anchor 5384 connection of the coded MX SDU; 5385 o Traffic Class ID (1 Byte): an unsigned integer to identify the 5386 traffic class of the coded MX; 5387 o Sequence Number (4 Bytes): the sequence number of the first 5388 (uncoded) MX SDU used to generate the coded MX SDU. 5389 o Fragmentation Control (FC) (1 Byte): to provide necessary 5390 information for re-assembly, only needed if the coded MX SDU is 5391 too long to transport in a single MX control PDU. 5392 o N (1 Byte): the number of consecutive MX SDUs used to generate the 5393 coded MX SDU 5394 o K (1 Byte): the length (in terms of bits) of the coding 5395 coefficient field 5396 o Coding Coefficient ( N x K / 8 Bytes) 5397 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 5398 + padding 5399 o Coded MX SDU (variable): the coded MX SDU 5401 If K = 0, the simple XOR method is used to generate the Coded MX SDU 5402 from N consecutive uncoded MX SDUs, and the a(i) fields are not 5403 included in the message. 5405 If the coded MX SDU is too long, it can be fragmented, and transported 5406 by multiple MX control PDUs. The N, K, and a(i) fields are only 5407 included in the MX PDU carrying the first fragment of the coded MX SDU. 5409 C-MADP N-MADP 5410 | | 5411 |<------------------ MX SDU #1 -------------------| 5412 | lost<-------- MX SDU #2 -------------------| 5413 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 5414 +----------------------+ | 5415 | MX SDU #2 recovered | | 5416 +----------------------+ | 5417 | | 5419 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 5421 5.6 Traffic Splitting Update (TSU) Message 5423 The "Type" field is set to "5" for TSU messages. 5425 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 5426 traffic splitting configuration has changed. 5428 A TSU message consists of the following fields: 5430 o Connection ID (1 Byte): an unsigned integer to identify the anchor 5431 connection; 5432 o Traffic Class ID (1 Byte): an unsigned integer to identify the 5433 traffic class; 5434 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 5435 message. 5436 o Flags (1 Byte) 5437 + Bit #0: a Reverse Path bit flag to indicate if the traffic 5438 splitting configuration is for the reverse path (1) or not 5439 (0); 5440 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 5441 used in traffic splitting 5442 + Others: reserved. 5443 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 5445 + StartSN (4 Bytes): the sequence number of the first MX SDU 5446 using the traffic splitting configuration provided by the TSU 5447 message 5448 + L (1 Byte): the traffic splitting burst size 5449 + K(i): the traffic splitting threshold of the i-th delivery 5450 connection, where connections are ordered according to their 5451 Connection ID. 5453 Let's use f(x) to denote the traffic splitting function, which maps a 5454 MX SDU Sequence Number "x" to the i-th delivery connection. 5456 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 5458 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 5460 N is the total number of connections for delivering a data flow, 5461 identified by (anchor) Connection ID and Traffic Class ID. 5463 When the bit-reversal bit is set to 1, the burst size L MUST be a power 5464 of 2, and the traffic splitting function is 5466 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 5468 Wherein F(.) is the bit reversal function [BITR] of the input variable. 5470 5.7 Acknowledgement Message 5472 The "Type" field is set to "6" for ACK messages. 5474 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 5475 successful reception of a PLR, FSN, or TSU message. 5477 C-MADP SHOULD send out the ACK message in response to a Probe message 5478 with the ACK flag set to "1". 5480 The ACK message consists of the following fields: 5482 o Acknowledgment Number (2 Bytes): the sequence number of the 5483 received message. 5484 o Timestamp (4 Bytes): the current value of the timestamp clock of 5485 the sender in the unit of 100 microseconds. 5487 6 Security Considerations 5489 User data in MAMS framework rely on the security of the underlying 5490 network transport paths. When this cannot be assumed, NCM configures 5491 use of appropriate protocols for security, e.g. IPsec [RFC4301] 5492 [RFC3948], DTLS [RFC6347]. 5494 7 IANA Considerations 5496 This draft makes no requests of IANA. 5498 8 Contributing Authors 5500 The editors gratefully acknowledge the following additional 5501 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 5502 Pentakota/Nokia. 5504 9 References 5506 9.1 Normative References 5508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5509 Requirement Levels", BCP 14, RFC 2119, March 1997. 5511 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5512 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 5513 December 2005, . 5515 9.2 Informative References 5517 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5518 Security Version 1.2", RFC 6347, January 2012, 5519 . 5521 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 5522 Kivinen, "Internet Key Exchange Protocol Version 2 5523 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 5524 2014, . 5526 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5527 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 5528 3948, DOI 10.17487/RFC3948, January 2005, . 5531 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 5532 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 5533 mechanism-02 5535 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 5536 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 5537 plain-mode-09.txt 5539 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 5540 Access Management Protocol", 5541 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 5542 protocol-03 5544 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 5545 Multi-Access Convergence", 5546 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 5548 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 5549 (GRE)", RFC 2784 March 2000, . 5552 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 5553 RFC 2890 September 2000, . 5556 [IANA] https://www.iana.org/assignments/protocol- 5557 numbers/protocol-numbers.xhtml 5559 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 5560 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 5561 Tunnel (LWIP) encapsulation; Protocol specification" 5563 [RFC791] Internet Protocol, September 1981 5565 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 5566 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 5567 IEEE Access, 2017 5569 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 5570 arXiv:1212.2291, 2012 5572 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 5573 Symbol Representation, https://www.ietf.org/id/draft- 5574 heide-nwcrg-rlnc-00.txt 5576 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 5577 38 (1): 1-26, 1996. 5579 Authors' Addresses 5581 Jing Zhu 5583 Intel 5585 Email: jing.z.zhu@intel.com 5586 SungHoon Seo 5588 Korea Telecom 5590 Email: sh.seo@kt.com 5592 Satish Kanugovi 5594 Nokia 5596 Email: satish.k@nokia.com 5598 Shuping Peng 5600 Huawei 5602 Email: pengshuping@huawei.com 5604 INTAREA J. Zhu 5605 Internet Draft Intel 5606 Intended status: Standards Track S. Seo 5607 Expires: April 1,2020 Korea Telecom 5608 S. Kanugovi 5609 Nokia 5610 S. Peng 5611 Huawei 5612 October 1, 2019 5614 User-Plane Protocols for Multiple Access Management Service 5615 draft-zhu-intarea-mams-user-protocol-07 5617 Status of this Memo 5619 This Internet-Draft is submitted in full conformance with the 5620 provisions of BCP 78 and BCP 79. 5622 Internet-Drafts are working documents of the Internet Engineering 5623 Task Force (IETF), its areas, and its working groups. Note that 5624 other groups may also distribute working documents as Internet- 5625 Drafts. 5627 Internet-Drafts are draft documents valid for a maximum of six 5628 months and may be updated, replaced, or obsoleted by other documents 5629 at any time. It is inappropriate to use Internet-Drafts as 5630 reference material or to cite them other than as "work in progress." 5632 The list of current Internet-Drafts can be accessed at 5633 http://www.ietf.org/ietf/1id-abstracts.txt 5635 The list of Internet-Draft Shadow Directories can be accessed at 5636 http://www.ietf.org/shadow.html 5638 This Internet-Draft will expire on April 1,2020. 5640 Copyright Notice 5642 Copyright (c) 2019 IETF Trust and the persons identified as the 5643 document authors. All rights reserved. 5645 This document is subject to BCP 78 and the IETF Trust's Legal 5646 Provisions Relating to IETF Documents 5647 (http://trustee.ietf.org/license-info) in effect on the date of 5648 publication of this document. Please review these documents 5649 carefully, as they describe your rights and restrictions with 5650 respect to this document. Code Components extracted from this 5651 document must include Simplified BSD License text as described in 5652 Section 4.e of the Trust Legal Provisions and are provided without 5653 warranty as described in the Simplified BSD License. 5655 Abstract 5657 Today, a device can be simultaneously connected to multiple 5658 communication networks based on different technology implementations 5659 and network architectures like WiFi, LTE, and DSL. In such multi- 5660 connectivity scenario, it is desirable to combine multiple access 5661 networks or select the best one to improve quality of experience for 5662 a user and improve overall network utilization and efficiency. This 5663 document presents the u-plane protocols for a multi access 5664 management services (MAMS) framework that can be used to flexibly 5665 select the combination of uplink and downlink access and core 5666 network paths having the optimal performance, and user plane 5667 treatment for improving network utilization and efficiency and 5668 enhanced quality of experience for user applications. 5670 Table of Contents 5672 1. Introduction...................................................3 5673 2. Terminologies..................................................3 5674 3. Conventions used in this document..............................3 5675 4 MAMS User-Plane Protocols......................................4 5676 4.1 MX Adaptation Sublayer...................................4 5677 4.2 GMA-based MX Convergence Sublayer........................5 5678 4.3 MPTCP-based MX Convergence Sublayer......................6 5679 4.4 GRE as MX Convergence Sublayer...........................6 5680 4.4.1 Transmitter Procedures.............................7 5681 4.4.2 Receiver Procedures................................8 5682 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 5683 8 5684 5. MX Convergence Control Message.................................8 5685 5.1 Keep-Alive Message.......................................9 5686 5.2 Probe Message............................................9 5687 5.3 Packet Loss Report (PLR) Message........................10 5688 5.4 First Sequence Number (FSN) Message.....................11 5689 5.5 Coded MX SDU (CMS) Message..............................12 5690 5.6 Traffic Splitting Update (TSU) Message..................13 5691 5.7 Acknowledgement Message.................................14 5692 6 Security Considerations.......................................14 5693 7 IANA Considerations...........................................15 5694 8 Contributing Authors..........................................15 5695 9 References....................................................15 5696 9.1 Normative References....................................15 5697 9.2 Informative References..................................15 5699 1. Introduction 5701 Multi Access Management Service (MAMS) [MAMS] is a programmable 5702 framework to select and configure network paths, as well as adapt to 5703 dynamic network conditions, when multiple network connections can 5704 serve a client device. It is based on principles of user plane 5705 interworking that enables the solution to be deployed as an overlay 5706 without impacting the underlying networks. 5708 This document presents the u-plane protocols for enabling the MAMS 5709 framework. It co-exists and complements the existing protocols by 5710 providing a way to negotiate and configure the protocols based on 5711 client and network capabilities. Further it allows exchange of 5712 network state information and leveraging network intelligence to 5713 optimize the performance of such protocols. An important goal for 5714 MAMS is to ensure that there is minimal or no dependency on the 5715 actual access technology of the participating links. This allows the 5716 scheme to be scalable for addition of newer access technologies and 5717 for independent evolution of the existing access technologies. 5719 2. Terminologies 5721 Anchor Connection: refers to the network path from the N-MADP to the 5722 Application Server that corresponds to a specific IP anchor that has 5723 assigned an IP address to the client. 5725 Delivery Connection: refers to the network path from the N-MADP to 5726 the C-MADP. 5728 "Network Connection Manager" (NCM), "Client Connection Manager" 5729 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 5730 Access Data Proxy" (C-MADP) in this document are to be interpreted 5731 as described in [MAMS]. 5733 3. Conventions used in this document 5735 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 5736 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 5737 document are to be interpreted as described in [RFC2119]. 5739 The terminologies "Network Connection Manager" (NCM), "Client 5740 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 5741 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 5742 document are to be interpreted as described in [MAMS]. 5744 4 MAMS User-Plane Protocols 5746 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 5747 +-----------------------------------------------------+ 5748 | User Payload (e.g. IP PDU) | 5749 |-----------------------------------------------------| 5750 +--|-----------------------------------------------------|--+ 5751 | |-----------------------------------------------------| | 5752 | | Multi-Access (MX) Convergence Sublayer | | 5753 | |-----------------------------------------------------| | 5754 | |-----------------------------------------------------| | 5755 | | MX Adaptation | MX Adaptation | MX Adaptation | | 5756 | | Sublayer | Sublayer | Sublayer | | 5757 | | (optional) | (optional) | (optional) | | 5758 | |-----------------------------------------------------| | 5759 | | Access #1 IP | Access #2 IP | Access #3 IP | | 5760 | +-----------------------------------------------------+ | 5761 +-----------------------------------------------------------+ 5762 Figure 1: MAMS U-plane Protocol Stack 5763 It consists of the following two Sublayers: 5765 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 5766 access specific tasks, e.g., access (path) selection, multi-link 5767 (path) aggregation, splitting/reordering, lossless switching, 5768 fragmentation, concatenation, keep-alive, and probing etc. 5769 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 5770 to handle tunneling, network layer security, and NAT. 5772 The MX convergence sublayer operates on top of the MX adaptation 5773 sublayer in the protocol stack. From the Transmitter perspective, a 5774 User Payload (e.g. IP PDU) is processed by the convergence sublayer 5775 first, and then by the adaptation sublayer before being transported 5776 over a delivery access connection; from the Receiver perspective, an IP 5777 packet received over a delivery connection is processed by the MX 5778 adaptation sublayer first, and then by the MX convergence sublayer. 5780 4.1 MX Adaptation Sublayer 5782 The MX adaptation sublayer supports the following mechanisms and 5783 protocols while transmitting user plane packets on the network path: 5785 o UDP Tunneling: The user plane packets of the anchor connection can be 5786 encapsulated in a UDP tunnel of a delivery connection between the N- 5787 MADP and C-MADP. 5789 o IPsec Tunneling: The user plane packets of the anchor connection are 5790 sent through an IPsec tunnel of a delivery connection. 5791 o Client Net Address Translation (NAT): The Client IP address of user 5792 plane packet of the anchor connection is changed, and sent over a 5793 delivery connection. 5794 o Pass Through: The user plane packets are passing through without any 5795 change over the anchor connection. 5797 The MX adaptation sublayer also supports the following mechanisms and 5798 protocols to ensure security of user plane packets over the network 5799 path. 5801 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 5802 N-MADP and C-MADP on the network path that is considered untrusted. 5803 o DTLS: If UDP tunneling is used on the network path that is considered 5804 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 5805 be used. 5807 The Client NAT method is the most efficient due to no tunneling 5808 overhead. It SHOULD be used if a delivery connection is "trusted" and 5809 without NAT function on the path. 5811 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 5812 connection has a NAT function placed on the path. 5814 4.2 GMA-based MX Convergence Sublayer 5816 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 5817 encapsulation [GMA]. Multiple access networks are combined into a 5818 single IP connection. If NCM determines that N-MADP is to be 5819 instantiated with GMA as the MX Convergence Protocol, it exchanges the 5820 support of GMA convergence capability in the discovery and capability 5821 exchange procedures [MAMS]. 5823 +-----------------------------------------------------+ 5824 | IP PDU | 5825 |-----------------------------------------------------| 5826 | GMA Convergence Sublayer | 5827 |-----------------------------------------------------| 5828 | MX Adaptation | MX Adaptation | MX Adaptation | 5829 | Sublayer | Sublayer | Sublayer | 5830 | (optional) | (optional) | (optional) | 5831 |-----------------------------------------------------| 5832 | Access #1 IP | Access #2 IP | Access #3 IP | 5833 +-----------------------------------------------------+ 5834 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 5836 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 5837 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 5838 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 5839 message [MAMS] is true, the "IP length" and "IP checksum" header fields 5840 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 5841 updated after adding or removing the GMA trailer in the convergence 5842 sublayer. 5844 +------------------------------------------------------+ 5845 | IP hdr | IP payload | GMA Trailer | 5846 +------------------------------------------------------+ 5847 Figure 3: GMA PDU Format 5849 4.3 MPTCP-based MX Convergence Sublayer 5851 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 5852 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 5853 access networks are combined into a single MPTCP connection. Hence, no 5854 new u-plane protocol or PDU format is needed in this case. 5856 |-----------------------------------------------------| 5857 | MPTCP | 5858 |-----------------------------------------------------| 5859 | TCP | TCP | TCP | 5860 |-----------------------------------------------------| 5861 | MX Adaptation | MX Adaptation | MX Adaptation | 5862 | Sublayer | Sublayer | Sublayer | 5863 | (optional) | (optional) | (optional) | 5864 |-----------------------------------------------------| 5865 | Access #1 IP | Access #2 IP | Access #3 IP | 5866 +-----------------------------------------------------+ 5867 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 5868 Layer 5870 If NCM determines that N-MADP is to be instantiated with MPTCP as the 5871 MX Convergence Protocol, it exchanges the support of MPTCP capability 5872 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 5873 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 5874 and aggregation over multiple delivery connections. 5876 4.4 GRE as MX Convergence Sublayer 5878 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 5879 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 5880 Convergence sub-layer" protocol. Multiple access networks are combined 5881 into a single GRE connection. Hence, no new u-plane protocol or PDU 5882 format is needed in this case. 5884 +-----------------------------------------------------+ 5885 | User Payload (e.g. IP PDU) | 5886 |-----------------------------------------------------| 5887 | GRE as MX Convergence Sublayer | 5888 |-----------------------------------------------------| 5889 | GRE Delivery Protocol (e.g. IP) | 5890 |-----------------------------------------------------| 5891 | MX Adaptation | MX Adaptation | MX Adaptation | 5892 | Sublayer | Sublayer | Sublayer | 5893 | (optional) | (optional) | (optional) | 5894 |-----------------------------------------------------| 5895 | Access #1 IP | Access #2 IP | Access #3 IP | 5896 +-----------------------------------------------------+ 5897 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 5898 Layer 5900 If NCM determines that N-MADP is to be instantiated with GRE as the MX 5901 Convergence Protocol, it exchanges the support of GRE capability in the 5902 discovery and capability exchange procedures [MAMS]. 5904 4.4.1 Transmitter Procedures 5906 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 5907 the convergence protocol that transmits the GRE packets. The 5908 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 5909 with a GRE header and Delivery Protocol (e.g. IP) header to generate 5910 the GRE Convergence PDU. 5912 When IP is used as the GRE delivery protocol, the IP header information 5913 (e.g. IP address) can be created using the IP header of the user 5914 payload or a virtual IP address. The "Protocol Type" field of the 5915 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 5917 The GRE header fields are set as specified below, 5919 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 5920 to the value of Connection ID for the Anchor Connection associated 5921 with the user payload or sets to 0xFFFF if no Anchor Connection ID 5922 needs to be specified. 5923 - All other fields in the GRE header including the remaining bits in 5924 the key fields are set as per [GRE_2784][GRE_2890]. 5926 4.4.2 Receiver Procedures 5928 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 5929 convergence protocol that receives the GRE packets. The receiver 5930 processes the received packets per the GRE procedures [GRE_2784, 5931 GRE_2890] and retrieves the GRE header. 5933 - If the Receiver is an N-MADP instance, 5934 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 5935 interpreted as the Connection ID of Anchor Connection for the 5936 user payload. This is used to identify the network path over 5937 which the User Payload (GRE Payload) is to be transmitted. 5938 - All other fields in the GRE header, including the remaining bits 5939 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 5941 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 5942 present) before delivery over one of the network paths. 5944 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 5946 MAMS u-plane protocols support multiple combinations and instances of 5947 user plane protocols to be used in the MX Adaptation and the 5948 Convergence sublayers. 5950 For example, one instance of the MX Convergence Layer can be MPTCP 5951 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 5952 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 5953 set up for network paths considered as untrusted by the operator, to 5954 protect the TCP subflow between client and MPTCP proxy traversing that 5955 network path. 5957 Each of the instances of MAMS user plane, i.e. combination of MX 5958 Convergence and MX Adaptation layer protocols, can coexist 5959 simultaneously and independently handle different traffic types. 5961 5. MX Convergence Control Message 5963 A UDP connection may be configured between C-MADP and N-MADP to 5964 exchange control messages for keep-alive or path quality estimation. 5965 The N-MADP end-point IP address and UDP port number of the UDP 5966 connection is used to identify MX control PDU. Figure 6 shows the MX 5967 control PDU format with the following fields: 5969 o Type (1 Byte): the type of the MX control message 5970 o CID (1 Byte): an unsigned integer to identify the anchor and 5971 delivery connection of the MX control message 5972 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 5973 identify the anchor connection 5974 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 5975 identify the delivery connection 5976 o MX Control Message (variable): the payload of the MX control 5977 message 5979 Figure 7 shows the MX convergence control protocol stack, and MX 5980 control PDU goes through the MX adaptation sublayer the same way as MX 5981 data PDU. 5983 <----MX Control PDU Payload ---------------> 5984 +------------------------------------------------------------------+ 5985 | IP header | UDP Header| Type | CID | MX Control Message | 5986 +------------------------------------------------------------------+ 5987 Figure 6: MX Control PDU Format 5989 |-----------------------------------------------------| 5990 | MX Convergence Control Messages | 5991 |-----------------------------------------------------| 5992 | UDP/IP | 5993 |-----------------------------------------------------| 5994 | MX Adaptation | MX Adaptation | MX Adaptation | 5995 | Sublayer | Sublayer | Sublayer | 5996 | (optional) | (optional) | (optional) | 5997 |-----------------------------------------------------| 5998 | Access #1 IP | Access #2 IP | Access #3 IP | 5999 +-----------------------------------------------------+ 6000 Figure 7: MX Convergence Control Protocol Stack 6002 5.1 Keep-Alive Message 6004 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 6005 out Keep-Alive message periodically over one or multiple delivery 6006 connections, especially if UDP tunneling is used as the adaptation 6007 method for the delivery connection with a NAT function on the path. 6009 A Keep-Alive message is 6 Bytes long, and consists of the following 6010 fields: 6012 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 6013 keep-alive message 6014 o Timestamp (4 Bytes): the current value of the timestamp clock of 6015 the sender in the unit of 100 microseconds. 6017 5.2 Probe Message 6019 The "Type" field is set to "1" for Probe messages. 6021 N-MADP may send out the Probe message for path quality estimation. In 6022 response, C-MADP may send back the ACK message. 6024 A Probe message consists of the following fields: 6026 o Probing Sequence Number (2 Bytes): the sequence number of the 6027 Probe REQ message 6028 o Probing Flag (1 Byte): 6029 + Bit #0: a ACK flag to indicate if the ACK message is expected 6030 (1) or not (0); 6031 + Bit #1: a Probe Type flag to indicate if the Probe message is 6032 sent during the initialization phase (0) when the network 6033 path is not included for transmission of user data or the 6034 active phase (1) when the network path is included for 6035 transmission of user data; 6036 + Bit #2: a bit flag to indicate the presence of the Reverse 6037 Connection ID (R-CID) field. 6038 + Bit #3~7: reserved 6039 o Reverse Connection ID (1 Byte): the connection ID of the delivery 6040 connection for sending out the ACK message on the reverse path 6041 o Timestamp (4 Bytes): the current value of the timestamp clock of 6042 the sender in the unit of 100 microseconds. 6043 o Padding (variable) 6045 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 6046 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 6047 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 6048 ACK message is not expected. 6050 If the "R-CID" field is not present but the Bit #0 of the "Probing 6051 Flag" field is set to "1", the ACK message SHOULD be sent over the same 6052 delivery connection as the Probe message. 6054 The "Padding" field is used to control the length of Probe message. 6056 5.3 Packet Loss Report (PLR) Message 6058 The "Type" field is set to "2" for PLR messages. 6060 C-MADP may send out the PLR messages to report lost MX SDU for example 6061 during handover. In response, C-MADP may retransmit the lost MX SDU 6062 accordingly. 6064 A PLR message consists of the following fields: 6066 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6067 connection which the ACK message is for; 6069 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6070 traffic class of the anchor connection which the ACK message is 6071 for; 6072 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 6073 that the sender of the PLR message is expecting 6074 o Number of Loss Bursts (1 Byte) 6075 For each loss burst, include the following 6076 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 6077 + Number of consecutive lost MX SDUs in the burst (1 Byte) 6079 C-MADP N-MADP 6080 | | 6081 |<------------------ MX SDU (data packets)--------| 6082 | | 6083 +---------------------------------+ | 6084 |Packet Loss detected | | 6085 +---------------------------------+ | 6086 | | 6087 |----- PLR Message ------------------------------>| 6088 |<-------------retransmit(lost)MX SDUs -----------| 6090 Figure 8: MAMS Retransmission Procedure 6092 Figure 8 shows the MAMS retransmission procedure in an example where 6093 the lost packet is found and retransmitted. 6095 5.4 First Sequence Number (FSN) Message 6097 The "Type" field is set to "3" for FSN messages. 6099 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 6100 its buffer if a lost MX SDU is not found in the buffer after receiving 6101 the PLR message from C-MADP. In response, C-MADP SHALL only report 6102 packet loss with SN not smaller than FSN. 6104 A FSN message consists of the following fields: 6106 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6107 connection which the FSN message is for; 6108 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6109 traffic class of the anchor connection which the FSN message is 6110 for; 6111 o First Sequence Number (4 Bytes): the sequence number (SN) of the 6112 oldest MX SDU in the (retransmission) buffer of the sender of the 6113 FSN message. 6115 Figure 9 shows the MAMS retransmission procedure in an example where 6116 the lost packet is not found. 6118 C-MADP N-MADP 6119 | | 6120 |<------------------ MX SDU (data packets)--------| 6121 | | 6122 +---------------------------------+ | 6123 |Packet Loss detected | | 6124 +---------------------------------+ | 6125 | | 6126 |----- PLR Message ------------------------------>| 6127 | +---------------------+ 6128 | |Lost packet not found| 6129 | +---------------------+ 6130 |<-------------FSN message -----------------------| 6132 Figure 9: MAMS Retransmission Procedure with FSN 6134 5.5 Coded MX SDU (CMS) Message 6136 The "Type" field is set to "4" for CMS messages. 6138 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 6139 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 6140 [RLNC]. A coded MX SDU is generated by applying a network coding 6141 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 6142 fast recovery without retransmission if any of the MX SDUs is lost. 6144 A Coded MX SDU message consists of the following fields: 6146 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6147 connection of the coded MX SDU; 6148 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6149 traffic class of the coded MX; 6150 o Sequence Number (4 Bytes): the sequence number of the first 6151 (uncoded) MX SDU used to generate the coded MX SDU. 6152 o Fragmentation Control (FC) (1 Byte): to provide necessary 6153 information for re-assembly, only needed if the coded MX SDU is 6154 too long to transport in a single MX control PDU. 6155 o N (1 Byte): the number of consecutive MX SDUs used to generate the 6156 coded MX SDU 6157 o K (1 Byte): the length (in terms of bits) of the coding 6158 coefficient field 6159 o Coding Coefficient ( N x K / 8 Bytes) 6160 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 6161 + padding 6162 o Coded MX SDU (variable): the coded MX SDU 6164 If K = 0, the simple XOR method is used to generate the Coded MX SDU 6165 from N consecutive uncoded MX SDUs, and the a(i) fields are not 6166 included in the message. 6168 If the coded MX SDU is too long, it can be fragmented, and transported 6169 by multiple MX control PDUs. The N, K, and a(i) fields are only 6170 included in the MX PDU carrying the first fragment of the coded MX SDU. 6172 C-MADP N-MADP 6173 | | 6174 |<------------------ MX SDU #1 -------------------| 6175 | lost<-------- MX SDU #2 -------------------| 6176 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 6177 +----------------------+ | 6178 | MX SDU #2 recovered | | 6179 +----------------------+ | 6180 | | 6182 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 6184 5.6 Traffic Splitting Update (TSU) Message 6186 The "Type" field is set to "5" for TSU messages. 6188 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 6189 traffic splitting configuration has changed. 6191 A TSU message consists of the following fields: 6193 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6194 connection; 6195 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6196 traffic class; 6197 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 6198 message. 6199 o Flags (1 Byte) 6200 + Bit #0: a Reverse Path bit flag to indicate if the traffic 6201 splitting configuration is for the reverse path (1) or not 6202 (0); 6203 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 6204 used in traffic splitting 6205 + Others: reserved. 6206 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 6208 + StartSN (4 Bytes): the sequence number of the first MX SDU 6209 using the traffic splitting configuration provided by the TSU 6210 message 6211 + L (1 Byte): the traffic splitting burst size 6212 + K(i): the traffic splitting threshold of the i-th delivery 6213 connection, where connections are ordered according to their 6214 Connection ID. 6216 Let's use f(x) to denote the traffic splitting function, which maps a 6217 MX SDU Sequence Number "x" to the i-th delivery connection. 6219 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 6221 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 6223 N is the total number of connections for delivering a data flow, 6224 identified by (anchor) Connection ID and Traffic Class ID. 6226 When the bit-reversal bit is set to 1, the burst size L MUST be a power 6227 of 2, and the traffic splitting function is 6229 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 6231 Wherein F(.) is the bit reversal function [BITR] of the input variable. 6233 5.7 Acknowledgement Message 6235 The "Type" field is set to "6" for ACK messages. 6237 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 6238 successful reception of a PLR, FSN, or TSU message. 6240 C-MADP SHOULD send out the ACK message in response to a Probe message 6241 with the ACK flag set to "1". 6243 The ACK message consists of the following fields: 6245 o Acknowledgment Number (2 Bytes): the sequence number of the 6246 received message. 6247 o Timestamp (4 Bytes): the current value of the timestamp clock of 6248 the sender in the unit of 100 microseconds. 6250 6 Security Considerations 6252 User data in MAMS framework rely on the security of the underlying 6253 network transport paths. When this cannot be assumed, NCM configures 6254 use of appropriate protocols for security, e.g. IPsec [RFC4301] 6255 [RFC3948], DTLS [RFC6347]. 6257 7 IANA Considerations 6259 This draft makes no requests of IANA. 6261 8 Contributing Authors 6263 The editors gratefully acknowledge the following additional 6264 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 6265 Pentakota/Nokia. 6267 9 References 6269 9.1 Normative References 6271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6272 Requirement Levels", BCP 14, RFC 2119, March 1997. 6274 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6275 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 6276 December 2005, . 6278 9.2 Informative References 6280 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6281 Security Version 1.2", RFC 6347, January 2012, 6282 . 6284 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 6285 Kivinen, "Internet Key Exchange Protocol Version 2 6286 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 6287 2014, . 6289 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 6290 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 6291 3948, DOI 10.17487/RFC3948, January 2005, . 6294 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 6295 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 6296 mechanism-02 6298 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 6299 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 6300 plain-mode-09.txt 6302 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 6303 Access Management Protocol", 6304 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 6305 protocol-03 6307 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 6308 Multi-Access Convergence", 6309 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 6311 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 6312 (GRE)", RFC 2784 March 2000, . 6315 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 6316 RFC 2890 September 2000, . 6319 [IANA] https://www.iana.org/assignments/protocol- 6320 numbers/protocol-numbers.xhtml 6322 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 6323 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 6324 Tunnel (LWIP) encapsulation; Protocol specification" 6326 [RFC791] Internet Protocol, September 1981 6328 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 6329 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 6330 IEEE Access, 2017 6332 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 6333 arXiv:1212.2291, 2012 6335 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 6336 Symbol Representation, https://www.ietf.org/id/draft- 6337 heide-nwcrg-rlnc-00.txt 6339 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 6340 38 (1): 1-26, 1996. 6342 Authors' Addresses 6344 Jing Zhu 6346 Intel 6348 Email: jing.z.zhu@intel.com 6349 SungHoon Seo 6351 Korea Telecom 6353 Email: sh.seo@kt.com 6355 Satish Kanugovi 6357 Nokia 6359 Email: satish.k@nokia.com 6361 Shuping Peng 6363 Huawei 6365 Email: pengshuping@huawei.com 6367 INTAREA J. Zhu 6368 Internet Draft Intel 6369 Intended status: Standards Track S. Seo 6370 Expires: April 1,2020 Korea Telecom 6371 S. Kanugovi 6372 Nokia 6373 S. Peng 6374 Huawei 6375 October 1, 2019 6377 User-Plane Protocols for Multiple Access Management Service 6378 draft-zhu-intarea-mams-user-protocol-07 6380 Status of this Memo 6382 This Internet-Draft is submitted in full conformance with the 6383 provisions of BCP 78 and BCP 79. 6385 Internet-Drafts are working documents of the Internet Engineering 6386 Task Force (IETF), its areas, and its working groups. Note that 6387 other groups may also distribute working documents as Internet- 6388 Drafts. 6390 Internet-Drafts are draft documents valid for a maximum of six 6391 months and may be updated, replaced, or obsoleted by other documents 6392 at any time. It is inappropriate to use Internet-Drafts as 6393 reference material or to cite them other than as "work in progress." 6395 The list of current Internet-Drafts can be accessed at 6396 http://www.ietf.org/ietf/1id-abstracts.txt 6398 The list of Internet-Draft Shadow Directories can be accessed at 6399 http://www.ietf.org/shadow.html 6401 This Internet-Draft will expire on April 1,2020. 6403 Copyright Notice 6405 Copyright (c) 2019 IETF Trust and the persons identified as the 6406 document authors. All rights reserved. 6408 This document is subject to BCP 78 and the IETF Trust's Legal 6409 Provisions Relating to IETF Documents 6410 (http://trustee.ietf.org/license-info) in effect on the date of 6411 publication of this document. Please review these documents 6412 carefully, as they describe your rights and restrictions with 6413 respect to this document. Code Components extracted from this 6414 document must include Simplified BSD License text as described in 6415 Section 4.e of the Trust Legal Provisions and are provided without 6416 warranty as described in the Simplified BSD License. 6418 Abstract 6420 Today, a device can be simultaneously connected to multiple 6421 communication networks based on different technology implementations 6422 and network architectures like WiFi, LTE, and DSL. In such multi- 6423 connectivity scenario, it is desirable to combine multiple access 6424 networks or select the best one to improve quality of experience for 6425 a user and improve overall network utilization and efficiency. This 6426 document presents the u-plane protocols for a multi access 6427 management services (MAMS) framework that can be used to flexibly 6428 select the combination of uplink and downlink access and core 6429 network paths having the optimal performance, and user plane 6430 treatment for improving network utilization and efficiency and 6431 enhanced quality of experience for user applications. 6433 Table of Contents 6435 1. Introduction...................................................3 6436 2. Terminologies..................................................3 6437 3. Conventions used in this document..............................3 6438 4 MAMS User-Plane Protocols......................................4 6439 4.1 MX Adaptation Sublayer...................................4 6440 4.2 GMA-based MX Convergence Sublayer........................5 6441 4.3 MPTCP-based MX Convergence Sublayer......................6 6442 4.4 GRE as MX Convergence Sublayer...........................6 6443 4.4.1 Transmitter Procedures.............................7 6444 4.4.2 Receiver Procedures................................8 6445 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 6446 8 6447 5. MX Convergence Control Message.................................8 6448 5.1 Keep-Alive Message.......................................9 6449 5.2 Probe Message............................................9 6450 5.3 Packet Loss Report (PLR) Message........................10 6451 5.4 First Sequence Number (FSN) Message.....................11 6452 5.5 Coded MX SDU (CMS) Message..............................12 6453 5.6 Traffic Splitting Update (TSU) Message..................13 6454 5.7 Acknowledgement Message.................................14 6455 6 Security Considerations.......................................14 6456 7 IANA Considerations...........................................15 6457 8 Contributing Authors..........................................15 6458 9 References....................................................15 6459 9.1 Normative References....................................15 6460 9.2 Informative References..................................15 6462 1. Introduction 6464 Multi Access Management Service (MAMS) [MAMS] is a programmable 6465 framework to select and configure network paths, as well as adapt to 6466 dynamic network conditions, when multiple network connections can 6467 serve a client device. It is based on principles of user plane 6468 interworking that enables the solution to be deployed as an overlay 6469 without impacting the underlying networks. 6471 This document presents the u-plane protocols for enabling the MAMS 6472 framework. It co-exists and complements the existing protocols by 6473 providing a way to negotiate and configure the protocols based on 6474 client and network capabilities. Further it allows exchange of 6475 network state information and leveraging network intelligence to 6476 optimize the performance of such protocols. An important goal for 6477 MAMS is to ensure that there is minimal or no dependency on the 6478 actual access technology of the participating links. This allows the 6479 scheme to be scalable for addition of newer access technologies and 6480 for independent evolution of the existing access technologies. 6482 2. Terminologies 6484 Anchor Connection: refers to the network path from the N-MADP to the 6485 Application Server that corresponds to a specific IP anchor that has 6486 assigned an IP address to the client. 6488 Delivery Connection: refers to the network path from the N-MADP to 6489 the C-MADP. 6491 "Network Connection Manager" (NCM), "Client Connection Manager" 6492 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 6493 Access Data Proxy" (C-MADP) in this document are to be interpreted 6494 as described in [MAMS]. 6496 3. Conventions used in this document 6498 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 6499 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 6500 document are to be interpreted as described in [RFC2119]. 6502 The terminologies "Network Connection Manager" (NCM), "Client 6503 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 6504 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 6505 document are to be interpreted as described in [MAMS]. 6507 4 MAMS User-Plane Protocols 6509 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 6510 +-----------------------------------------------------+ 6511 | User Payload (e.g. IP PDU) | 6512 |-----------------------------------------------------| 6513 +--|-----------------------------------------------------|--+ 6514 | |-----------------------------------------------------| | 6515 | | Multi-Access (MX) Convergence Sublayer | | 6516 | |-----------------------------------------------------| | 6517 | |-----------------------------------------------------| | 6518 | | MX Adaptation | MX Adaptation | MX Adaptation | | 6519 | | Sublayer | Sublayer | Sublayer | | 6520 | | (optional) | (optional) | (optional) | | 6521 | |-----------------------------------------------------| | 6522 | | Access #1 IP | Access #2 IP | Access #3 IP | | 6523 | +-----------------------------------------------------+ | 6524 +-----------------------------------------------------------+ 6525 Figure 1: MAMS U-plane Protocol Stack 6526 It consists of the following two Sublayers: 6528 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 6529 access specific tasks, e.g., access (path) selection, multi-link 6530 (path) aggregation, splitting/reordering, lossless switching, 6531 fragmentation, concatenation, keep-alive, and probing etc. 6532 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 6533 to handle tunneling, network layer security, and NAT. 6535 The MX convergence sublayer operates on top of the MX adaptation 6536 sublayer in the protocol stack. From the Transmitter perspective, a 6537 User Payload (e.g. IP PDU) is processed by the convergence sublayer 6538 first, and then by the adaptation sublayer before being transported 6539 over a delivery access connection; from the Receiver perspective, an IP 6540 packet received over a delivery connection is processed by the MX 6541 adaptation sublayer first, and then by the MX convergence sublayer. 6543 4.1 MX Adaptation Sublayer 6545 The MX adaptation sublayer supports the following mechanisms and 6546 protocols while transmitting user plane packets on the network path: 6548 o UDP Tunneling: The user plane packets of the anchor connection can be 6549 encapsulated in a UDP tunnel of a delivery connection between the N- 6550 MADP and C-MADP. 6552 o IPsec Tunneling: The user plane packets of the anchor connection are 6553 sent through an IPsec tunnel of a delivery connection. 6554 o Client Net Address Translation (NAT): The Client IP address of user 6555 plane packet of the anchor connection is changed, and sent over a 6556 delivery connection. 6557 o Pass Through: The user plane packets are passing through without any 6558 change over the anchor connection. 6560 The MX adaptation sublayer also supports the following mechanisms and 6561 protocols to ensure security of user plane packets over the network 6562 path. 6564 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 6565 N-MADP and C-MADP on the network path that is considered untrusted. 6566 o DTLS: If UDP tunneling is used on the network path that is considered 6567 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 6568 be used. 6570 The Client NAT method is the most efficient due to no tunneling 6571 overhead. It SHOULD be used if a delivery connection is "trusted" and 6572 without NAT function on the path. 6574 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 6575 connection has a NAT function placed on the path. 6577 4.2 GMA-based MX Convergence Sublayer 6579 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 6580 encapsulation [GMA]. Multiple access networks are combined into a 6581 single IP connection. If NCM determines that N-MADP is to be 6582 instantiated with GMA as the MX Convergence Protocol, it exchanges the 6583 support of GMA convergence capability in the discovery and capability 6584 exchange procedures [MAMS]. 6586 +-----------------------------------------------------+ 6587 | IP PDU | 6588 |-----------------------------------------------------| 6589 | GMA Convergence Sublayer | 6590 |-----------------------------------------------------| 6591 | MX Adaptation | MX Adaptation | MX Adaptation | 6592 | Sublayer | Sublayer | Sublayer | 6593 | (optional) | (optional) | (optional) | 6594 |-----------------------------------------------------| 6595 | Access #1 IP | Access #2 IP | Access #3 IP | 6596 +-----------------------------------------------------+ 6597 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 6599 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 6600 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 6601 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 6602 message [MAMS] is true, the "IP length" and "IP checksum" header fields 6603 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 6604 updated after adding or removing the GMA trailer in the convergence 6605 sublayer. 6607 +------------------------------------------------------+ 6608 | IP hdr | IP payload | GMA Trailer | 6609 +------------------------------------------------------+ 6610 Figure 3: GMA PDU Format 6612 4.3 MPTCP-based MX Convergence Sublayer 6614 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 6615 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 6616 access networks are combined into a single MPTCP connection. Hence, no 6617 new u-plane protocol or PDU format is needed in this case. 6619 |-----------------------------------------------------| 6620 | MPTCP | 6621 |-----------------------------------------------------| 6622 | TCP | TCP | TCP | 6623 |-----------------------------------------------------| 6624 | MX Adaptation | MX Adaptation | MX Adaptation | 6625 | Sublayer | Sublayer | Sublayer | 6626 | (optional) | (optional) | (optional) | 6627 |-----------------------------------------------------| 6628 | Access #1 IP | Access #2 IP | Access #3 IP | 6629 +-----------------------------------------------------+ 6630 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 6631 Layer 6633 If NCM determines that N-MADP is to be instantiated with MPTCP as the 6634 MX Convergence Protocol, it exchanges the support of MPTCP capability 6635 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 6636 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 6637 and aggregation over multiple delivery connections. 6639 4.4 GRE as MX Convergence Sublayer 6641 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 6642 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 6643 Convergence sub-layer" protocol. Multiple access networks are combined 6644 into a single GRE connection. Hence, no new u-plane protocol or PDU 6645 format is needed in this case. 6647 +-----------------------------------------------------+ 6648 | User Payload (e.g. IP PDU) | 6649 |-----------------------------------------------------| 6650 | GRE as MX Convergence Sublayer | 6651 |-----------------------------------------------------| 6652 | GRE Delivery Protocol (e.g. IP) | 6653 |-----------------------------------------------------| 6654 | MX Adaptation | MX Adaptation | MX Adaptation | 6655 | Sublayer | Sublayer | Sublayer | 6656 | (optional) | (optional) | (optional) | 6657 |-----------------------------------------------------| 6658 | Access #1 IP | Access #2 IP | Access #3 IP | 6659 +-----------------------------------------------------+ 6660 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 6661 Layer 6663 If NCM determines that N-MADP is to be instantiated with GRE as the MX 6664 Convergence Protocol, it exchanges the support of GRE capability in the 6665 discovery and capability exchange procedures [MAMS]. 6667 4.4.1 Transmitter Procedures 6669 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 6670 the convergence protocol that transmits the GRE packets. The 6671 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 6672 with a GRE header and Delivery Protocol (e.g. IP) header to generate 6673 the GRE Convergence PDU. 6675 When IP is used as the GRE delivery protocol, the IP header information 6676 (e.g. IP address) can be created using the IP header of the user 6677 payload or a virtual IP address. The "Protocol Type" field of the 6678 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 6680 The GRE header fields are set as specified below, 6682 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 6683 to the value of Connection ID for the Anchor Connection associated 6684 with the user payload or sets to 0xFFFF if no Anchor Connection ID 6685 needs to be specified. 6686 - All other fields in the GRE header including the remaining bits in 6687 the key fields are set as per [GRE_2784][GRE_2890]. 6689 4.4.2 Receiver Procedures 6691 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 6692 convergence protocol that receives the GRE packets. The receiver 6693 processes the received packets per the GRE procedures [GRE_2784, 6694 GRE_2890] and retrieves the GRE header. 6696 - If the Receiver is an N-MADP instance, 6697 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 6698 interpreted as the Connection ID of Anchor Connection for the 6699 user payload. This is used to identify the network path over 6700 which the User Payload (GRE Payload) is to be transmitted. 6701 - All other fields in the GRE header, including the remaining bits 6702 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 6704 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 6705 present) before delivery over one of the network paths. 6707 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 6709 MAMS u-plane protocols support multiple combinations and instances of 6710 user plane protocols to be used in the MX Adaptation and the 6711 Convergence sublayers. 6713 For example, one instance of the MX Convergence Layer can be MPTCP 6714 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 6715 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 6716 set up for network paths considered as untrusted by the operator, to 6717 protect the TCP subflow between client and MPTCP proxy traversing that 6718 network path. 6720 Each of the instances of MAMS user plane, i.e. combination of MX 6721 Convergence and MX Adaptation layer protocols, can coexist 6722 simultaneously and independently handle different traffic types. 6724 5. MX Convergence Control Message 6726 A UDP connection may be configured between C-MADP and N-MADP to 6727 exchange control messages for keep-alive or path quality estimation. 6728 The N-MADP end-point IP address and UDP port number of the UDP 6729 connection is used to identify MX control PDU. Figure 6 shows the MX 6730 control PDU format with the following fields: 6732 o Type (1 Byte): the type of the MX control message 6733 o CID (1 Byte): an unsigned integer to identify the anchor and 6734 delivery connection of the MX control message 6735 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 6736 identify the anchor connection 6737 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 6738 identify the delivery connection 6739 o MX Control Message (variable): the payload of the MX control 6740 message 6742 Figure 7 shows the MX convergence control protocol stack, and MX 6743 control PDU goes through the MX adaptation sublayer the same way as MX 6744 data PDU. 6746 <----MX Control PDU Payload ---------------> 6747 +------------------------------------------------------------------+ 6748 | IP header | UDP Header| Type | CID | MX Control Message | 6749 +------------------------------------------------------------------+ 6750 Figure 6: MX Control PDU Format 6752 |-----------------------------------------------------| 6753 | MX Convergence Control Messages | 6754 |-----------------------------------------------------| 6755 | UDP/IP | 6756 |-----------------------------------------------------| 6757 | MX Adaptation | MX Adaptation | MX Adaptation | 6758 | Sublayer | Sublayer | Sublayer | 6759 | (optional) | (optional) | (optional) | 6760 |-----------------------------------------------------| 6761 | Access #1 IP | Access #2 IP | Access #3 IP | 6762 +-----------------------------------------------------+ 6763 Figure 7: MX Convergence Control Protocol Stack 6765 5.1 Keep-Alive Message 6767 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 6768 out Keep-Alive message periodically over one or multiple delivery 6769 connections, especially if UDP tunneling is used as the adaptation 6770 method for the delivery connection with a NAT function on the path. 6772 A Keep-Alive message is 6 Bytes long, and consists of the following 6773 fields: 6775 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 6776 keep-alive message 6777 o Timestamp (4 Bytes): the current value of the timestamp clock of 6778 the sender in the unit of 100 microseconds. 6780 5.2 Probe Message 6782 The "Type" field is set to "1" for Probe messages. 6784 N-MADP may send out the Probe message for path quality estimation. In 6785 response, C-MADP may send back the ACK message. 6787 A Probe message consists of the following fields: 6789 o Probing Sequence Number (2 Bytes): the sequence number of the 6790 Probe REQ message 6791 o Probing Flag (1 Byte): 6792 + Bit #0: a ACK flag to indicate if the ACK message is expected 6793 (1) or not (0); 6794 + Bit #1: a Probe Type flag to indicate if the Probe message is 6795 sent during the initialization phase (0) when the network 6796 path is not included for transmission of user data or the 6797 active phase (1) when the network path is included for 6798 transmission of user data; 6799 + Bit #2: a bit flag to indicate the presence of the Reverse 6800 Connection ID (R-CID) field. 6801 + Bit #3~7: reserved 6802 o Reverse Connection ID (1 Byte): the connection ID of the delivery 6803 connection for sending out the ACK message on the reverse path 6804 o Timestamp (4 Bytes): the current value of the timestamp clock of 6805 the sender in the unit of 100 microseconds. 6806 o Padding (variable) 6808 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 6809 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 6810 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 6811 ACK message is not expected. 6813 If the "R-CID" field is not present but the Bit #0 of the "Probing 6814 Flag" field is set to "1", the ACK message SHOULD be sent over the same 6815 delivery connection as the Probe message. 6817 The "Padding" field is used to control the length of Probe message. 6819 5.3 Packet Loss Report (PLR) Message 6821 The "Type" field is set to "2" for PLR messages. 6823 C-MADP may send out the PLR messages to report lost MX SDU for example 6824 during handover. In response, C-MADP may retransmit the lost MX SDU 6825 accordingly. 6827 A PLR message consists of the following fields: 6829 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6830 connection which the ACK message is for; 6832 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6833 traffic class of the anchor connection which the ACK message is 6834 for; 6835 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 6836 that the sender of the PLR message is expecting 6837 o Number of Loss Bursts (1 Byte) 6838 For each loss burst, include the following 6839 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 6840 + Number of consecutive lost MX SDUs in the burst (1 Byte) 6842 C-MADP N-MADP 6843 | | 6844 |<------------------ MX SDU (data packets)--------| 6845 | | 6846 +---------------------------------+ | 6847 |Packet Loss detected | | 6848 +---------------------------------+ | 6849 | | 6850 |----- PLR Message ------------------------------>| 6851 |<-------------retransmit(lost)MX SDUs -----------| 6853 Figure 8: MAMS Retransmission Procedure 6855 Figure 8 shows the MAMS retransmission procedure in an example where 6856 the lost packet is found and retransmitted. 6858 5.4 First Sequence Number (FSN) Message 6860 The "Type" field is set to "3" for FSN messages. 6862 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 6863 its buffer if a lost MX SDU is not found in the buffer after receiving 6864 the PLR message from C-MADP. In response, C-MADP SHALL only report 6865 packet loss with SN not smaller than FSN. 6867 A FSN message consists of the following fields: 6869 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6870 connection which the FSN message is for; 6871 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6872 traffic class of the anchor connection which the FSN message is 6873 for; 6874 o First Sequence Number (4 Bytes): the sequence number (SN) of the 6875 oldest MX SDU in the (retransmission) buffer of the sender of the 6876 FSN message. 6878 Figure 9 shows the MAMS retransmission procedure in an example where 6879 the lost packet is not found. 6881 C-MADP N-MADP 6882 | | 6883 |<------------------ MX SDU (data packets)--------| 6884 | | 6885 +---------------------------------+ | 6886 |Packet Loss detected | | 6887 +---------------------------------+ | 6888 | | 6889 |----- PLR Message ------------------------------>| 6890 | +---------------------+ 6891 | |Lost packet not found| 6892 | +---------------------+ 6893 |<-------------FSN message -----------------------| 6895 Figure 9: MAMS Retransmission Procedure with FSN 6897 5.5 Coded MX SDU (CMS) Message 6899 The "Type" field is set to "4" for CMS messages. 6901 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 6902 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 6903 [RLNC]. A coded MX SDU is generated by applying a network coding 6904 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 6905 fast recovery without retransmission if any of the MX SDUs is lost. 6907 A Coded MX SDU message consists of the following fields: 6909 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6910 connection of the coded MX SDU; 6911 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6912 traffic class of the coded MX; 6913 o Sequence Number (4 Bytes): the sequence number of the first 6914 (uncoded) MX SDU used to generate the coded MX SDU. 6915 o Fragmentation Control (FC) (1 Byte): to provide necessary 6916 information for re-assembly, only needed if the coded MX SDU is 6917 too long to transport in a single MX control PDU. 6918 o N (1 Byte): the number of consecutive MX SDUs used to generate the 6919 coded MX SDU 6920 o K (1 Byte): the length (in terms of bits) of the coding 6921 coefficient field 6922 o Coding Coefficient ( N x K / 8 Bytes) 6923 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 6924 + padding 6925 o Coded MX SDU (variable): the coded MX SDU 6927 If K = 0, the simple XOR method is used to generate the Coded MX SDU 6928 from N consecutive uncoded MX SDUs, and the a(i) fields are not 6929 included in the message. 6931 If the coded MX SDU is too long, it can be fragmented, and transported 6932 by multiple MX control PDUs. The N, K, and a(i) fields are only 6933 included in the MX PDU carrying the first fragment of the coded MX SDU. 6935 C-MADP N-MADP 6936 | | 6937 |<------------------ MX SDU #1 -------------------| 6938 | lost<-------- MX SDU #2 -------------------| 6939 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 6940 +----------------------+ | 6941 | MX SDU #2 recovered | | 6942 +----------------------+ | 6943 | | 6945 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 6947 5.6 Traffic Splitting Update (TSU) Message 6949 The "Type" field is set to "5" for TSU messages. 6951 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 6952 traffic splitting configuration has changed. 6954 A TSU message consists of the following fields: 6956 o Connection ID (1 Byte): an unsigned integer to identify the anchor 6957 connection; 6958 o Traffic Class ID (1 Byte): an unsigned integer to identify the 6959 traffic class; 6960 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 6961 message. 6962 o Flags (1 Byte) 6963 + Bit #0: a Reverse Path bit flag to indicate if the traffic 6964 splitting configuration is for the reverse path (1) or not 6965 (0); 6966 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 6967 used in traffic splitting 6968 + Others: reserved. 6969 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 6971 + StartSN (4 Bytes): the sequence number of the first MX SDU 6972 using the traffic splitting configuration provided by the TSU 6973 message 6974 + L (1 Byte): the traffic splitting burst size 6975 + K(i): the traffic splitting threshold of the i-th delivery 6976 connection, where connections are ordered according to their 6977 Connection ID. 6979 Let's use f(x) to denote the traffic splitting function, which maps a 6980 MX SDU Sequence Number "x" to the i-th delivery connection. 6982 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 6984 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 6986 N is the total number of connections for delivering a data flow, 6987 identified by (anchor) Connection ID and Traffic Class ID. 6989 When the bit-reversal bit is set to 1, the burst size L MUST be a power 6990 of 2, and the traffic splitting function is 6992 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 6994 Wherein F(.) is the bit reversal function [BITR] of the input variable. 6996 5.7 Acknowledgement Message 6998 The "Type" field is set to "6" for ACK messages. 7000 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 7001 successful reception of a PLR, FSN, or TSU message. 7003 C-MADP SHOULD send out the ACK message in response to a Probe message 7004 with the ACK flag set to "1". 7006 The ACK message consists of the following fields: 7008 o Acknowledgment Number (2 Bytes): the sequence number of the 7009 received message. 7010 o Timestamp (4 Bytes): the current value of the timestamp clock of 7011 the sender in the unit of 100 microseconds. 7013 6 Security Considerations 7015 User data in MAMS framework rely on the security of the underlying 7016 network transport paths. When this cannot be assumed, NCM configures 7017 use of appropriate protocols for security, e.g. IPsec [RFC4301] 7018 [RFC3948], DTLS [RFC6347]. 7020 7 IANA Considerations 7022 This draft makes no requests of IANA. 7024 8 Contributing Authors 7026 The editors gratefully acknowledge the following additional 7027 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 7028 Pentakota/Nokia. 7030 9 References 7032 9.1 Normative References 7034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7035 Requirement Levels", BCP 14, RFC 2119, March 1997. 7037 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 7038 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 7039 December 2005, . 7041 9.2 Informative References 7043 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 7044 Security Version 1.2", RFC 6347, January 2012, 7045 . 7047 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 7048 Kivinen, "Internet Key Exchange Protocol Version 2 7049 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 7050 2014, . 7052 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 7053 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 7054 3948, DOI 10.17487/RFC3948, January 2005, . 7057 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 7058 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 7059 mechanism-02 7061 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 7062 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 7063 plain-mode-09.txt 7065 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 7066 Access Management Protocol", 7067 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 7068 protocol-03 7070 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 7071 Multi-Access Convergence", 7072 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 7074 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 7075 (GRE)", RFC 2784 March 2000, . 7078 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 7079 RFC 2890 September 2000, . 7082 [IANA] https://www.iana.org/assignments/protocol- 7083 numbers/protocol-numbers.xhtml 7085 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 7086 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 7087 Tunnel (LWIP) encapsulation; Protocol specification" 7089 [RFC791] Internet Protocol, September 1981 7091 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 7092 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 7093 IEEE Access, 2017 7095 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 7096 arXiv:1212.2291, 2012 7098 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 7099 Symbol Representation, https://www.ietf.org/id/draft- 7100 heide-nwcrg-rlnc-00.txt 7102 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 7103 38 (1): 1-26, 1996. 7105 Authors' Addresses 7107 Jing Zhu 7109 Intel 7111 Email: jing.z.zhu@intel.com 7112 SungHoon Seo 7114 Korea Telecom 7116 Email: sh.seo@kt.com 7118 Satish Kanugovi 7120 Nokia 7122 Email: satish.k@nokia.com 7124 Shuping Peng 7126 Huawei 7128 Email: pengshuping@huawei.com 7130 INTAREA J. Zhu 7131 Internet Draft Intel 7132 Intended status: Standards Track S. Seo 7133 Expires: April 1,2020 Korea Telecom 7134 S. Kanugovi 7135 Nokia 7136 S. Peng 7137 Huawei 7138 October 1, 2019 7140 User-Plane Protocols for Multiple Access Management Service 7141 draft-zhu-intarea-mams-user-protocol-07 7143 Status of this Memo 7145 This Internet-Draft is submitted in full conformance with the 7146 provisions of BCP 78 and BCP 79. 7148 Internet-Drafts are working documents of the Internet Engineering 7149 Task Force (IETF), its areas, and its working groups. Note that 7150 other groups may also distribute working documents as Internet- 7151 Drafts. 7153 Internet-Drafts are draft documents valid for a maximum of six 7154 months and may be updated, replaced, or obsoleted by other documents 7155 at any time. It is inappropriate to use Internet-Drafts as 7156 reference material or to cite them other than as "work in progress." 7158 The list of current Internet-Drafts can be accessed at 7159 http://www.ietf.org/ietf/1id-abstracts.txt 7161 The list of Internet-Draft Shadow Directories can be accessed at 7162 http://www.ietf.org/shadow.html 7164 This Internet-Draft will expire on April 1,2020. 7166 Copyright Notice 7168 Copyright (c) 2019 IETF Trust and the persons identified as the 7169 document authors. All rights reserved. 7171 This document is subject to BCP 78 and the IETF Trust's Legal 7172 Provisions Relating to IETF Documents 7173 (http://trustee.ietf.org/license-info) in effect on the date of 7174 publication of this document. Please review these documents 7175 carefully, as they describe your rights and restrictions with 7176 respect to this document. Code Components extracted from this 7177 document must include Simplified BSD License text as described in 7178 Section 4.e of the Trust Legal Provisions and are provided without 7179 warranty as described in the Simplified BSD License. 7181 Abstract 7183 Today, a device can be simultaneously connected to multiple 7184 communication networks based on different technology implementations 7185 and network architectures like WiFi, LTE, and DSL. In such multi- 7186 connectivity scenario, it is desirable to combine multiple access 7187 networks or select the best one to improve quality of experience for 7188 a user and improve overall network utilization and efficiency. This 7189 document presents the u-plane protocols for a multi access 7190 management services (MAMS) framework that can be used to flexibly 7191 select the combination of uplink and downlink access and core 7192 network paths having the optimal performance, and user plane 7193 treatment for improving network utilization and efficiency and 7194 enhanced quality of experience for user applications. 7196 Table of Contents 7198 1. Introduction...................................................3 7199 2. Terminologies..................................................3 7200 3. Conventions used in this document..............................3 7201 4 MAMS User-Plane Protocols......................................4 7202 4.1 MX Adaptation Sublayer...................................4 7203 4.2 GMA-based MX Convergence Sublayer........................5 7204 4.3 MPTCP-based MX Convergence Sublayer......................6 7205 4.4 GRE as MX Convergence Sublayer...........................6 7206 4.4.1 Transmitter Procedures.............................7 7207 4.4.2 Receiver Procedures................................8 7208 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 7209 8 7210 5. MX Convergence Control Message.................................8 7211 5.1 Keep-Alive Message.......................................9 7212 5.2 Probe Message............................................9 7213 5.3 Packet Loss Report (PLR) Message........................10 7214 5.4 First Sequence Number (FSN) Message.....................11 7215 5.5 Coded MX SDU (CMS) Message..............................12 7216 5.6 Traffic Splitting Update (TSU) Message..................13 7217 5.7 Acknowledgement Message.................................14 7218 6 Security Considerations.......................................14 7219 7 IANA Considerations...........................................15 7220 8 Contributing Authors..........................................15 7221 9 References....................................................15 7222 9.1 Normative References....................................15 7223 9.2 Informative References..................................15 7225 1. Introduction 7227 Multi Access Management Service (MAMS) [MAMS] is a programmable 7228 framework to select and configure network paths, as well as adapt to 7229 dynamic network conditions, when multiple network connections can 7230 serve a client device. It is based on principles of user plane 7231 interworking that enables the solution to be deployed as an overlay 7232 without impacting the underlying networks. 7234 This document presents the u-plane protocols for enabling the MAMS 7235 framework. It co-exists and complements the existing protocols by 7236 providing a way to negotiate and configure the protocols based on 7237 client and network capabilities. Further it allows exchange of 7238 network state information and leveraging network intelligence to 7239 optimize the performance of such protocols. An important goal for 7240 MAMS is to ensure that there is minimal or no dependency on the 7241 actual access technology of the participating links. This allows the 7242 scheme to be scalable for addition of newer access technologies and 7243 for independent evolution of the existing access technologies. 7245 2. Terminologies 7247 Anchor Connection: refers to the network path from the N-MADP to the 7248 Application Server that corresponds to a specific IP anchor that has 7249 assigned an IP address to the client. 7251 Delivery Connection: refers to the network path from the N-MADP to 7252 the C-MADP. 7254 "Network Connection Manager" (NCM), "Client Connection Manager" 7255 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 7256 Access Data Proxy" (C-MADP) in this document are to be interpreted 7257 as described in [MAMS]. 7259 3. Conventions used in this document 7261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 7262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 7263 document are to be interpreted as described in [RFC2119]. 7265 The terminologies "Network Connection Manager" (NCM), "Client 7266 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 7267 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 7268 document are to be interpreted as described in [MAMS]. 7270 4 MAMS User-Plane Protocols 7272 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 7273 +-----------------------------------------------------+ 7274 | User Payload (e.g. IP PDU) | 7275 |-----------------------------------------------------| 7276 +--|-----------------------------------------------------|--+ 7277 | |-----------------------------------------------------| | 7278 | | Multi-Access (MX) Convergence Sublayer | | 7279 | |-----------------------------------------------------| | 7280 | |-----------------------------------------------------| | 7281 | | MX Adaptation | MX Adaptation | MX Adaptation | | 7282 | | Sublayer | Sublayer | Sublayer | | 7283 | | (optional) | (optional) | (optional) | | 7284 | |-----------------------------------------------------| | 7285 | | Access #1 IP | Access #2 IP | Access #3 IP | | 7286 | +-----------------------------------------------------+ | 7287 +-----------------------------------------------------------+ 7288 Figure 1: MAMS U-plane Protocol Stack 7289 It consists of the following two Sublayers: 7291 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 7292 access specific tasks, e.g., access (path) selection, multi-link 7293 (path) aggregation, splitting/reordering, lossless switching, 7294 fragmentation, concatenation, keep-alive, and probing etc. 7295 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 7296 to handle tunneling, network layer security, and NAT. 7298 The MX convergence sublayer operates on top of the MX adaptation 7299 sublayer in the protocol stack. From the Transmitter perspective, a 7300 User Payload (e.g. IP PDU) is processed by the convergence sublayer 7301 first, and then by the adaptation sublayer before being transported 7302 over a delivery access connection; from the Receiver perspective, an IP 7303 packet received over a delivery connection is processed by the MX 7304 adaptation sublayer first, and then by the MX convergence sublayer. 7306 4.1 MX Adaptation Sublayer 7308 The MX adaptation sublayer supports the following mechanisms and 7309 protocols while transmitting user plane packets on the network path: 7311 o UDP Tunneling: The user plane packets of the anchor connection can be 7312 encapsulated in a UDP tunnel of a delivery connection between the N- 7313 MADP and C-MADP. 7315 o IPsec Tunneling: The user plane packets of the anchor connection are 7316 sent through an IPsec tunnel of a delivery connection. 7317 o Client Net Address Translation (NAT): The Client IP address of user 7318 plane packet of the anchor connection is changed, and sent over a 7319 delivery connection. 7320 o Pass Through: The user plane packets are passing through without any 7321 change over the anchor connection. 7323 The MX adaptation sublayer also supports the following mechanisms and 7324 protocols to ensure security of user plane packets over the network 7325 path. 7327 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 7328 N-MADP and C-MADP on the network path that is considered untrusted. 7329 o DTLS: If UDP tunneling is used on the network path that is considered 7330 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 7331 be used. 7333 The Client NAT method is the most efficient due to no tunneling 7334 overhead. It SHOULD be used if a delivery connection is "trusted" and 7335 without NAT function on the path. 7337 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 7338 connection has a NAT function placed on the path. 7340 4.2 GMA-based MX Convergence Sublayer 7342 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 7343 encapsulation [GMA]. Multiple access networks are combined into a 7344 single IP connection. If NCM determines that N-MADP is to be 7345 instantiated with GMA as the MX Convergence Protocol, it exchanges the 7346 support of GMA convergence capability in the discovery and capability 7347 exchange procedures [MAMS]. 7349 +-----------------------------------------------------+ 7350 | IP PDU | 7351 |-----------------------------------------------------| 7352 | GMA Convergence Sublayer | 7353 |-----------------------------------------------------| 7354 | MX Adaptation | MX Adaptation | MX Adaptation | 7355 | Sublayer | Sublayer | Sublayer | 7356 | (optional) | (optional) | (optional) | 7357 |-----------------------------------------------------| 7358 | Access #1 IP | Access #2 IP | Access #3 IP | 7359 +-----------------------------------------------------+ 7360 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 7362 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 7363 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 7364 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 7365 message [MAMS] is true, the "IP length" and "IP checksum" header fields 7366 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 7367 updated after adding or removing the GMA trailer in the convergence 7368 sublayer. 7370 +------------------------------------------------------+ 7371 | IP hdr | IP payload | GMA Trailer | 7372 +------------------------------------------------------+ 7373 Figure 3: GMA PDU Format 7375 4.3 MPTCP-based MX Convergence Sublayer 7377 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 7378 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 7379 access networks are combined into a single MPTCP connection. Hence, no 7380 new u-plane protocol or PDU format is needed in this case. 7382 |-----------------------------------------------------| 7383 | MPTCP | 7384 |-----------------------------------------------------| 7385 | TCP | TCP | TCP | 7386 |-----------------------------------------------------| 7387 | MX Adaptation | MX Adaptation | MX Adaptation | 7388 | Sublayer | Sublayer | Sublayer | 7389 | (optional) | (optional) | (optional) | 7390 |-----------------------------------------------------| 7391 | Access #1 IP | Access #2 IP | Access #3 IP | 7392 +-----------------------------------------------------+ 7393 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 7394 Layer 7396 If NCM determines that N-MADP is to be instantiated with MPTCP as the 7397 MX Convergence Protocol, it exchanges the support of MPTCP capability 7398 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 7399 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 7400 and aggregation over multiple delivery connections. 7402 4.4 GRE as MX Convergence Sublayer 7404 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 7405 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 7406 Convergence sub-layer" protocol. Multiple access networks are combined 7407 into a single GRE connection. Hence, no new u-plane protocol or PDU 7408 format is needed in this case. 7410 +-----------------------------------------------------+ 7411 | User Payload (e.g. IP PDU) | 7412 |-----------------------------------------------------| 7413 | GRE as MX Convergence Sublayer | 7414 |-----------------------------------------------------| 7415 | GRE Delivery Protocol (e.g. IP) | 7416 |-----------------------------------------------------| 7417 | MX Adaptation | MX Adaptation | MX Adaptation | 7418 | Sublayer | Sublayer | Sublayer | 7419 | (optional) | (optional) | (optional) | 7420 |-----------------------------------------------------| 7421 | Access #1 IP | Access #2 IP | Access #3 IP | 7422 +-----------------------------------------------------+ 7423 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 7424 Layer 7426 If NCM determines that N-MADP is to be instantiated with GRE as the MX 7427 Convergence Protocol, it exchanges the support of GRE capability in the 7428 discovery and capability exchange procedures [MAMS]. 7430 4.4.1 Transmitter Procedures 7432 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 7433 the convergence protocol that transmits the GRE packets. The 7434 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 7435 with a GRE header and Delivery Protocol (e.g. IP) header to generate 7436 the GRE Convergence PDU. 7438 When IP is used as the GRE delivery protocol, the IP header information 7439 (e.g. IP address) can be created using the IP header of the user 7440 payload or a virtual IP address. The "Protocol Type" field of the 7441 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 7443 The GRE header fields are set as specified below, 7445 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 7446 to the value of Connection ID for the Anchor Connection associated 7447 with the user payload or sets to 0xFFFF if no Anchor Connection ID 7448 needs to be specified. 7449 - All other fields in the GRE header including the remaining bits in 7450 the key fields are set as per [GRE_2784][GRE_2890]. 7452 4.4.2 Receiver Procedures 7454 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 7455 convergence protocol that receives the GRE packets. The receiver 7456 processes the received packets per the GRE procedures [GRE_2784, 7457 GRE_2890] and retrieves the GRE header. 7459 - If the Receiver is an N-MADP instance, 7460 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 7461 interpreted as the Connection ID of Anchor Connection for the 7462 user payload. This is used to identify the network path over 7463 which the User Payload (GRE Payload) is to be transmitted. 7464 - All other fields in the GRE header, including the remaining bits 7465 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 7467 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 7468 present) before delivery over one of the network paths. 7470 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 7472 MAMS u-plane protocols support multiple combinations and instances of 7473 user plane protocols to be used in the MX Adaptation and the 7474 Convergence sublayers. 7476 For example, one instance of the MX Convergence Layer can be MPTCP 7477 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 7478 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 7479 set up for network paths considered as untrusted by the operator, to 7480 protect the TCP subflow between client and MPTCP proxy traversing that 7481 network path. 7483 Each of the instances of MAMS user plane, i.e. combination of MX 7484 Convergence and MX Adaptation layer protocols, can coexist 7485 simultaneously and independently handle different traffic types. 7487 5. MX Convergence Control Message 7489 A UDP connection may be configured between C-MADP and N-MADP to 7490 exchange control messages for keep-alive or path quality estimation. 7491 The N-MADP end-point IP address and UDP port number of the UDP 7492 connection is used to identify MX control PDU. Figure 6 shows the MX 7493 control PDU format with the following fields: 7495 o Type (1 Byte): the type of the MX control message 7496 o CID (1 Byte): an unsigned integer to identify the anchor and 7497 delivery connection of the MX control message 7498 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 7499 identify the anchor connection 7500 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 7501 identify the delivery connection 7502 o MX Control Message (variable): the payload of the MX control 7503 message 7505 Figure 7 shows the MX convergence control protocol stack, and MX 7506 control PDU goes through the MX adaptation sublayer the same way as MX 7507 data PDU. 7509 <----MX Control PDU Payload ---------------> 7510 +------------------------------------------------------------------+ 7511 | IP header | UDP Header| Type | CID | MX Control Message | 7512 +------------------------------------------------------------------+ 7513 Figure 6: MX Control PDU Format 7515 |-----------------------------------------------------| 7516 | MX Convergence Control Messages | 7517 |-----------------------------------------------------| 7518 | UDP/IP | 7519 |-----------------------------------------------------| 7520 | MX Adaptation | MX Adaptation | MX Adaptation | 7521 | Sublayer | Sublayer | Sublayer | 7522 | (optional) | (optional) | (optional) | 7523 |-----------------------------------------------------| 7524 | Access #1 IP | Access #2 IP | Access #3 IP | 7525 +-----------------------------------------------------+ 7526 Figure 7: MX Convergence Control Protocol Stack 7528 5.1 Keep-Alive Message 7530 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 7531 out Keep-Alive message periodically over one or multiple delivery 7532 connections, especially if UDP tunneling is used as the adaptation 7533 method for the delivery connection with a NAT function on the path. 7535 A Keep-Alive message is 6 Bytes long, and consists of the following 7536 fields: 7538 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 7539 keep-alive message 7540 o Timestamp (4 Bytes): the current value of the timestamp clock of 7541 the sender in the unit of 100 microseconds. 7543 5.2 Probe Message 7545 The "Type" field is set to "1" for Probe messages. 7547 N-MADP may send out the Probe message for path quality estimation. In 7548 response, C-MADP may send back the ACK message. 7550 A Probe message consists of the following fields: 7552 o Probing Sequence Number (2 Bytes): the sequence number of the 7553 Probe REQ message 7554 o Probing Flag (1 Byte): 7555 + Bit #0: a ACK flag to indicate if the ACK message is expected 7556 (1) or not (0); 7557 + Bit #1: a Probe Type flag to indicate if the Probe message is 7558 sent during the initialization phase (0) when the network 7559 path is not included for transmission of user data or the 7560 active phase (1) when the network path is included for 7561 transmission of user data; 7562 + Bit #2: a bit flag to indicate the presence of the Reverse 7563 Connection ID (R-CID) field. 7564 + Bit #3~7: reserved 7565 o Reverse Connection ID (1 Byte): the connection ID of the delivery 7566 connection for sending out the ACK message on the reverse path 7567 o Timestamp (4 Bytes): the current value of the timestamp clock of 7568 the sender in the unit of 100 microseconds. 7569 o Padding (variable) 7571 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 7572 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 7573 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 7574 ACK message is not expected. 7576 If the "R-CID" field is not present but the Bit #0 of the "Probing 7577 Flag" field is set to "1", the ACK message SHOULD be sent over the same 7578 delivery connection as the Probe message. 7580 The "Padding" field is used to control the length of Probe message. 7582 5.3 Packet Loss Report (PLR) Message 7584 The "Type" field is set to "2" for PLR messages. 7586 C-MADP may send out the PLR messages to report lost MX SDU for example 7587 during handover. In response, C-MADP may retransmit the lost MX SDU 7588 accordingly. 7590 A PLR message consists of the following fields: 7592 o Connection ID (1 Byte): an unsigned integer to identify the anchor 7593 connection which the ACK message is for; 7595 o Traffic Class ID (1 Byte): an unsigned integer to identify the 7596 traffic class of the anchor connection which the ACK message is 7597 for; 7598 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 7599 that the sender of the PLR message is expecting 7600 o Number of Loss Bursts (1 Byte) 7601 For each loss burst, include the following 7602 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 7603 + Number of consecutive lost MX SDUs in the burst (1 Byte) 7605 C-MADP N-MADP 7606 | | 7607 |<------------------ MX SDU (data packets)--------| 7608 | | 7609 +---------------------------------+ | 7610 |Packet Loss detected | | 7611 +---------------------------------+ | 7612 | | 7613 |----- PLR Message ------------------------------>| 7614 |<-------------retransmit(lost)MX SDUs -----------| 7616 Figure 8: MAMS Retransmission Procedure 7618 Figure 8 shows the MAMS retransmission procedure in an example where 7619 the lost packet is found and retransmitted. 7621 5.4 First Sequence Number (FSN) Message 7623 The "Type" field is set to "3" for FSN messages. 7625 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 7626 its buffer if a lost MX SDU is not found in the buffer after receiving 7627 the PLR message from C-MADP. In response, C-MADP SHALL only report 7628 packet loss with SN not smaller than FSN. 7630 A FSN message consists of the following fields: 7632 o Connection ID (1 Byte): an unsigned integer to identify the anchor 7633 connection which the FSN message is for; 7634 o Traffic Class ID (1 Byte): an unsigned integer to identify the 7635 traffic class of the anchor connection which the FSN message is 7636 for; 7637 o First Sequence Number (4 Bytes): the sequence number (SN) of the 7638 oldest MX SDU in the (retransmission) buffer of the sender of the 7639 FSN message. 7641 Figure 9 shows the MAMS retransmission procedure in an example where 7642 the lost packet is not found. 7644 C-MADP N-MADP 7645 | | 7646 |<------------------ MX SDU (data packets)--------| 7647 | | 7648 +---------------------------------+ | 7649 |Packet Loss detected | | 7650 +---------------------------------+ | 7651 | | 7652 |----- PLR Message ------------------------------>| 7653 | +---------------------+ 7654 | |Lost packet not found| 7655 | +---------------------+ 7656 |<-------------FSN message -----------------------| 7658 Figure 9: MAMS Retransmission Procedure with FSN 7660 5.5 Coded MX SDU (CMS) Message 7662 The "Type" field is set to "4" for CMS messages. 7664 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 7665 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 7666 [RLNC]. A coded MX SDU is generated by applying a network coding 7667 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 7668 fast recovery without retransmission if any of the MX SDUs is lost. 7670 A Coded MX SDU message consists of the following fields: 7672 o Connection ID (1 Byte): an unsigned integer to identify the anchor 7673 connection of the coded MX SDU; 7674 o Traffic Class ID (1 Byte): an unsigned integer to identify the 7675 traffic class of the coded MX; 7676 o Sequence Number (4 Bytes): the sequence number of the first 7677 (uncoded) MX SDU used to generate the coded MX SDU. 7678 o Fragmentation Control (FC) (1 Byte): to provide necessary 7679 information for re-assembly, only needed if the coded MX SDU is 7680 too long to transport in a single MX control PDU. 7681 o N (1 Byte): the number of consecutive MX SDUs used to generate the 7682 coded MX SDU 7683 o K (1 Byte): the length (in terms of bits) of the coding 7684 coefficient field 7685 o Coding Coefficient ( N x K / 8 Bytes) 7686 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 7687 + padding 7688 o Coded MX SDU (variable): the coded MX SDU 7690 If K = 0, the simple XOR method is used to generate the Coded MX SDU 7691 from N consecutive uncoded MX SDUs, and the a(i) fields are not 7692 included in the message. 7694 If the coded MX SDU is too long, it can be fragmented, and transported 7695 by multiple MX control PDUs. The N, K, and a(i) fields are only 7696 included in the MX PDU carrying the first fragment of the coded MX SDU. 7698 C-MADP N-MADP 7699 | | 7700 |<------------------ MX SDU #1 -------------------| 7701 | lost<-------- MX SDU #2 -------------------| 7702 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 7703 +----------------------+ | 7704 | MX SDU #2 recovered | | 7705 +----------------------+ | 7706 | | 7708 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 7710 5.6 Traffic Splitting Update (TSU) Message 7712 The "Type" field is set to "5" for TSU messages. 7714 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 7715 traffic splitting configuration has changed. 7717 A TSU message consists of the following fields: 7719 o Connection ID (1 Byte): an unsigned integer to identify the anchor 7720 connection; 7721 o Traffic Class ID (1 Byte): an unsigned integer to identify the 7722 traffic class; 7723 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 7724 message. 7725 o Flags (1 Byte) 7726 + Bit #0: a Reverse Path bit flag to indicate if the traffic 7727 splitting configuration is for the reverse path (1) or not 7728 (0); 7729 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 7730 used in traffic splitting 7731 + Others: reserved. 7732 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 7734 + StartSN (4 Bytes): the sequence number of the first MX SDU 7735 using the traffic splitting configuration provided by the TSU 7736 message 7737 + L (1 Byte): the traffic splitting burst size 7738 + K(i): the traffic splitting threshold of the i-th delivery 7739 connection, where connections are ordered according to their 7740 Connection ID. 7742 Let's use f(x) to denote the traffic splitting function, which maps a 7743 MX SDU Sequence Number "x" to the i-th delivery connection. 7745 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 7747 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 7749 N is the total number of connections for delivering a data flow, 7750 identified by (anchor) Connection ID and Traffic Class ID. 7752 When the bit-reversal bit is set to 1, the burst size L MUST be a power 7753 of 2, and the traffic splitting function is 7755 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 7757 Wherein F(.) is the bit reversal function [BITR] of the input variable. 7759 5.7 Acknowledgement Message 7761 The "Type" field is set to "6" for ACK messages. 7763 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 7764 successful reception of a PLR, FSN, or TSU message. 7766 C-MADP SHOULD send out the ACK message in response to a Probe message 7767 with the ACK flag set to "1". 7769 The ACK message consists of the following fields: 7771 o Acknowledgment Number (2 Bytes): the sequence number of the 7772 received message. 7773 o Timestamp (4 Bytes): the current value of the timestamp clock of 7774 the sender in the unit of 100 microseconds. 7776 6 Security Considerations 7778 User data in MAMS framework rely on the security of the underlying 7779 network transport paths. When this cannot be assumed, NCM configures 7780 use of appropriate protocols for security, e.g. IPsec [RFC4301] 7781 [RFC3948], DTLS [RFC6347]. 7783 7 IANA Considerations 7785 This draft makes no requests of IANA. 7787 8 Contributing Authors 7789 The editors gratefully acknowledge the following additional 7790 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 7791 Pentakota/Nokia. 7793 9 References 7795 9.1 Normative References 7797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7798 Requirement Levels", BCP 14, RFC 2119, March 1997. 7800 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 7801 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 7802 December 2005, . 7804 9.2 Informative References 7806 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 7807 Security Version 1.2", RFC 6347, January 2012, 7808 . 7810 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 7811 Kivinen, "Internet Key Exchange Protocol Version 2 7812 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 7813 2014, . 7815 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 7816 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 7817 3948, DOI 10.17487/RFC3948, January 2005, . 7820 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 7821 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 7822 mechanism-02 7824 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 7825 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 7826 plain-mode-09.txt 7828 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 7829 Access Management Protocol", 7830 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 7831 protocol-03 7833 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 7834 Multi-Access Convergence", 7835 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 7837 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 7838 (GRE)", RFC 2784 March 2000, . 7841 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 7842 RFC 2890 September 2000, . 7845 [IANA] https://www.iana.org/assignments/protocol- 7846 numbers/protocol-numbers.xhtml 7848 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 7849 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 7850 Tunnel (LWIP) encapsulation; Protocol specification" 7852 [RFC791] Internet Protocol, September 1981 7854 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 7855 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 7856 IEEE Access, 2017 7858 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 7859 arXiv:1212.2291, 2012 7861 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 7862 Symbol Representation, https://www.ietf.org/id/draft- 7863 heide-nwcrg-rlnc-00.txt 7865 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 7866 38 (1): 1-26, 1996. 7868 Authors' Addresses 7870 Jing Zhu 7872 Intel 7874 Email: jing.z.zhu@intel.com 7875 SungHoon Seo 7877 Korea Telecom 7879 Email: sh.seo@kt.com 7881 Satish Kanugovi 7883 Nokia 7885 Email: satish.k@nokia.com 7887 Shuping Peng 7889 Huawei 7891 Email: pengshuping@huawei.com 7893 INTAREA J. Zhu 7894 Internet Draft Intel 7895 Intended status: Standards Track S. Seo 7896 Expires: April 1,2020 Korea Telecom 7897 S. Kanugovi 7898 Nokia 7899 S. Peng 7900 Huawei 7901 October 1, 2019 7903 User-Plane Protocols for Multiple Access Management Service 7904 draft-zhu-intarea-mams-user-protocol-07 7906 Status of this Memo 7908 This Internet-Draft is submitted in full conformance with the 7909 provisions of BCP 78 and BCP 79. 7911 Internet-Drafts are working documents of the Internet Engineering 7912 Task Force (IETF), its areas, and its working groups. Note that 7913 other groups may also distribute working documents as Internet- 7914 Drafts. 7916 Internet-Drafts are draft documents valid for a maximum of six 7917 months and may be updated, replaced, or obsoleted by other documents 7918 at any time. It is inappropriate to use Internet-Drafts as 7919 reference material or to cite them other than as "work in progress." 7921 The list of current Internet-Drafts can be accessed at 7922 http://www.ietf.org/ietf/1id-abstracts.txt 7924 The list of Internet-Draft Shadow Directories can be accessed at 7925 http://www.ietf.org/shadow.html 7927 This Internet-Draft will expire on April 1,2020. 7929 Copyright Notice 7931 Copyright (c) 2019 IETF Trust and the persons identified as the 7932 document authors. All rights reserved. 7934 This document is subject to BCP 78 and the IETF Trust's Legal 7935 Provisions Relating to IETF Documents 7936 (http://trustee.ietf.org/license-info) in effect on the date of 7937 publication of this document. Please review these documents 7938 carefully, as they describe your rights and restrictions with 7939 respect to this document. Code Components extracted from this 7940 document must include Simplified BSD License text as described in 7941 Section 4.e of the Trust Legal Provisions and are provided without 7942 warranty as described in the Simplified BSD License. 7944 Abstract 7946 Today, a device can be simultaneously connected to multiple 7947 communication networks based on different technology implementations 7948 and network architectures like WiFi, LTE, and DSL. In such multi- 7949 connectivity scenario, it is desirable to combine multiple access 7950 networks or select the best one to improve quality of experience for 7951 a user and improve overall network utilization and efficiency. This 7952 document presents the u-plane protocols for a multi access 7953 management services (MAMS) framework that can be used to flexibly 7954 select the combination of uplink and downlink access and core 7955 network paths having the optimal performance, and user plane 7956 treatment for improving network utilization and efficiency and 7957 enhanced quality of experience for user applications. 7959 Table of Contents 7961 1. Introduction..................................................... 3 7962 2. Terminologies.................................................... 3 7963 3. Conventions used in this document................................ 3 7964 4 MAMS User-Plane Protocols........................................ 4 7965 4.1 MX Adaptation Sublayer..................................... 4 7966 4.2 GMA-based MX Convergence Sublayer.......................... 5 7967 4.3 MPTCP-based MX Convergence Sublayer........................ 6 7968 4.4 GRE as MX Convergence Sublayer............................. 6 7969 4.4.1 Transmitter Procedures.............................7 7970 4.4.2 Receiver Procedures................................8 7971 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers. 8 7972 5. MX Convergence Control Message................................... 8 7973 5.1 Keep-Alive Message......................................... 9 7974 5.2 Probe Message.............................................. 9 7975 5.3 Packet Loss Report (PLR) Message.......................... 10 7976 5.4 First Sequence Number (FSN) Message....................... 11 7977 5.5 Coded MX SDU (CMS) Message................................ 12 7978 5.6 Traffic Splitting Update (TSU) Message.................... 13 7979 5.7 Acknowledgement Message................................... 14 7980 6 Security Considerations......................................... 14 7981 7 IANA Considerations............................................. 15 7982 8 Contributing Authors............................................ 15 7983 9 References...................................................... 15 7984 9.1 Normative References...................................... 15 7985 9.2 Informative References.................................... 15 7987 1. Introduction 7989 Multi Access Management Service (MAMS) [MAMS] is a programmable 7990 framework to select and configure network paths, as well as adapt to 7991 dynamic network conditions, when multiple network connections can 7992 serve a client device. It is based on principles of user plane 7993 interworking that enables the solution to be deployed as an overlay 7994 without impacting the underlying networks. 7996 This document presents the u-plane protocols for enabling the MAMS 7997 framework. It co-exists and complements the existing protocols by 7998 providing a way to negotiate and configure the protocols based on 7999 client and network capabilities. Further it allows exchange of 8000 network state information and leveraging network intelligence to 8001 optimize the performance of such protocols. An important goal for 8002 MAMS is to ensure that there is minimal or no dependency on the 8003 actual access technology of the participating links. This allows the 8004 scheme to be scalable for addition of newer access technologies and 8005 for independent evolution of the existing access technologies. 8007 2. Terminologies 8009 Anchor Connection: refers to the network path from the N-MADP to the 8010 Application Server that corresponds to a specific IP anchor that has 8011 assigned an IP address to the client. 8013 Delivery Connection: refers to the network path from the N-MADP to 8014 the C-MADP. 8016 "Network Connection Manager" (NCM), "Client Connection Manager" 8017 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 8018 Access Data Proxy" (C-MADP) in this document are to be interpreted 8019 as described in [MAMS]. 8021 3. Conventions used in this document 8023 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 8024 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 8025 document are to be interpreted as described in [RFC2119]. 8027 The terminologies "Network Connection Manager" (NCM), "Client 8028 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 8029 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 8030 document are to be interpreted as described in [MAMS]. 8032 4 MAMS User-Plane Protocols 8034 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 8035 +-----------------------------------------------------+ 8036 | User Payload (e.g. IP PDU) | 8037 |-----------------------------------------------------| 8038 +--|-----------------------------------------------------|--+ 8039 | |-----------------------------------------------------| | 8040 | | Multi-Access (MX) Convergence Sublayer | | 8041 | |-----------------------------------------------------| | 8042 | |-----------------------------------------------------| | 8043 | | MX Adaptation | MX Adaptation | MX Adaptation | | 8044 | | Sublayer | Sublayer | Sublayer | | 8045 | | (optional) | (optional) | (optional) | | 8046 | |-----------------------------------------------------| | 8047 | | Access #1 IP | Access #2 IP | Access #3 IP | | 8048 | +-----------------------------------------------------+ | 8049 +-----------------------------------------------------------+ 8050 Figure 1: MAMS U-plane Protocol Stack 8051 It consists of the following two Sublayers: 8053 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 8054 access specific tasks, e.g., access (path) selection, multi-link 8055 (path) aggregation, splitting/reordering, lossless switching, 8056 fragmentation, concatenation, keep-alive, and probing etc. 8057 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 8058 to handle tunneling, network layer security, and NAT. 8060 The MX convergence sublayer operates on top of the MX adaptation 8061 sublayer in the protocol stack. From the Transmitter perspective, a 8062 User Payload (e.g. IP PDU) is processed by the convergence sublayer 8063 first, and then by the adaptation sublayer before being transported 8064 over a delivery access connection; from the Receiver perspective, an IP 8065 packet received over a delivery connection is processed by the MX 8066 adaptation sublayer first, and then by the MX convergence sublayer. 8068 4.1 MX Adaptation Sublayer 8070 The MX adaptation sublayer supports the following mechanisms and 8071 protocols while transmitting user plane packets on the network path: 8073 o UDP Tunneling: The user plane packets of the anchor connection can be 8074 encapsulated in a UDP tunnel of a delivery connection between the N- 8075 MADP and C-MADP. 8077 o IPsec Tunneling: The user plane packets of the anchor connection are 8078 sent through an IPsec tunnel of a delivery connection. 8079 o Client Net Address Translation (NAT): The Client IP address of user 8080 plane packet of the anchor connection is changed, and sent over a 8081 delivery connection. 8082 o Pass Through: The user plane packets are passing through without any 8083 change over the anchor connection. 8085 The MX adaptation sublayer also supports the following mechanisms and 8086 protocols to ensure security of user plane packets over the network 8087 path. 8089 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 8090 N-MADP and C-MADP on the network path that is considered untrusted. 8091 o DTLS: If UDP tunneling is used on the network path that is considered 8092 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 8093 be used. 8095 The Client NAT method is the most efficient due to no tunneling 8096 overhead. It SHOULD be used if a delivery connection is "trusted" and 8097 without NAT function on the path. 8099 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 8100 connection has a NAT function placed on the path. 8102 4.2 GMA-based MX Convergence Sublayer 8104 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 8105 encapsulation [GMA]. Multiple access networks are combined into a 8106 single IP connection. If NCM determines that N-MADP is to be 8107 instantiated with GMA as the MX Convergence Protocol, it exchanges the 8108 support of GMA convergence capability in the discovery and capability 8109 exchange procedures [MAMS]. 8111 +-----------------------------------------------------+ 8112 | IP PDU | 8113 |-----------------------------------------------------| 8114 | GMA Convergence Sublayer | 8115 |-----------------------------------------------------| 8116 | MX Adaptation | MX Adaptation | MX Adaptation | 8117 | Sublayer | Sublayer | Sublayer | 8118 | (optional) | (optional) | (optional) | 8119 |-----------------------------------------------------| 8120 | Access #1 IP | Access #2 IP | Access #3 IP | 8121 +-----------------------------------------------------+ 8122 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 8124 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 8125 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 8126 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 8127 message [MAMS] is true, the "IP length" and "IP checksum" header fields 8128 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 8129 updated after adding or removing the GMA trailer in the convergence 8130 sublayer. 8132 +------------------------------------------------------+ 8133 | IP hdr | IP payload | GMA Trailer | 8134 +------------------------------------------------------+ 8135 Figure 3: GMA PDU Format 8137 4.3 MPTCP-based MX Convergence Sublayer 8139 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 8140 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 8141 access networks are combined into a single MPTCP connection. Hence, no 8142 new u-plane protocol or PDU format is needed in this case. 8144 |-----------------------------------------------------| 8145 | MPTCP | 8146 |-----------------------------------------------------| 8147 | TCP | TCP | TCP | 8148 |-----------------------------------------------------| 8149 | MX Adaptation | MX Adaptation | MX Adaptation | 8150 | Sublayer | Sublayer | Sublayer | 8151 | (optional) | (optional) | (optional) | 8152 |-----------------------------------------------------| 8153 | Access #1 IP | Access #2 IP | Access #3 IP | 8154 +-----------------------------------------------------+ 8155 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 8156 Layer 8158 If NCM determines that N-MADP is to be instantiated with MPTCP as the 8159 MX Convergence Protocol, it exchanges the support of MPTCP capability 8160 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 8161 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 8162 and aggregation over multiple delivery connections. 8164 4.4 GRE as MX Convergence Sublayer 8166 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 8167 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 8168 Convergence sub-layer" protocol. Multiple access networks are combined 8169 into a single GRE connection. Hence, no new u-plane protocol or PDU 8170 format is needed in this case. 8172 +-----------------------------------------------------+ 8173 | User Payload (e.g. IP PDU) | 8174 |-----------------------------------------------------| 8175 | GRE as MX Convergence Sublayer | 8176 |-----------------------------------------------------| 8177 | GRE Delivery Protocol (e.g. IP) | 8178 |-----------------------------------------------------| 8179 | MX Adaptation | MX Adaptation | MX Adaptation | 8180 | Sublayer | Sublayer | Sublayer | 8181 | (optional) | (optional) | (optional) | 8182 |-----------------------------------------------------| 8183 | Access #1 IP | Access #2 IP | Access #3 IP | 8184 +-----------------------------------------------------+ 8185 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 8186 Layer 8188 If NCM determines that N-MADP is to be instantiated with GRE as the MX 8189 Convergence Protocol, it exchanges the support of GRE capability in the 8190 discovery and capability exchange procedures [MAMS]. 8192 4.4.1 Transmitter Procedures 8194 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 8195 the convergence protocol that transmits the GRE packets. The 8196 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 8197 with a GRE header and Delivery Protocol (e.g. IP) header to generate 8198 the GRE Convergence PDU. 8200 When IP is used as the GRE delivery protocol, the IP header information 8201 (e.g. IP address) can be created using the IP header of the user 8202 payload or a virtual IP address. The "Protocol Type" field of the 8203 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 8205 The GRE header fields are set as specified below, 8207 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 8208 to the value of Connection ID for the Anchor Connection associated 8209 with the user payload or sets to 0xFFFF if no Anchor Connection ID 8210 needs to be specified. 8211 - All other fields in the GRE header including the remaining bits in 8212 the key fields are set as per [GRE_2784][GRE_2890]. 8214 4.4.2 Receiver Procedures 8216 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 8217 convergence protocol that receives the GRE packets. The receiver 8218 processes the received packets per the GRE procedures [GRE_2784, 8219 GRE_2890] and retrieves the GRE header. 8221 - If the Receiver is an N-MADP instance, 8222 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 8223 interpreted as the Connection ID of Anchor Connection for the 8224 user payload. This is used to identify the network path over 8225 which the User Payload (GRE Payload) is to be transmitted. 8226 - All other fields in the GRE header, including the remaining bits 8227 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 8229 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 8230 present) before delivery over one of the network paths. 8232 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 8234 MAMS u-plane protocols support multiple combinations and instances of 8235 user plane protocols to be used in the MX Adaptation and the 8236 Convergence sublayers. 8238 For example, one instance of the MX Convergence Layer can be MPTCP 8239 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 8240 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 8241 set up for network paths considered as untrusted by the operator, to 8242 protect the TCP subflow between client and MPTCP proxy traversing that 8243 network path. 8245 Each of the instances of MAMS user plane, i.e. combination of MX 8246 Convergence and MX Adaptation layer protocols, can coexist 8247 simultaneously and independently handle different traffic types. 8249 5. MX Convergence Control Message 8251 A UDP connection may be configured between C-MADP and N-MADP to 8252 exchange control messages for keep-alive or path quality estimation. 8253 The N-MADP end-point IP address and UDP port number of the UDP 8254 connection is used to identify MX control PDU. Figure 6 shows the MX 8255 control PDU format with the following fields: 8257 o Type (1 Byte): the type of the MX control message 8258 o CID (1 Byte): an unsigned integer to identify the anchor and 8259 delivery connection of the MX control message 8260 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 8261 identify the anchor connection 8262 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 8263 identify the delivery connection 8264 o MX Control Message (variable): the payload of the MX control 8265 message 8267 Figure 7 shows the MX convergence control protocol stack, and MX 8268 control PDU goes through the MX adaptation sublayer the same way as MX 8269 data PDU. 8271 <----MX Control PDU Payload ---------------> 8272 +------------------------------------------------------------------+ 8273 | IP header | UDP Header| Type | CID | MX Control Message | 8274 +------------------------------------------------------------------+ 8275 Figure 6: MX Control PDU Format 8277 |-----------------------------------------------------| 8278 | MX Convergence Control Messages | 8279 |-----------------------------------------------------| 8280 | UDP/IP | 8281 |-----------------------------------------------------| 8282 | MX Adaptation | MX Adaptation | MX Adaptation | 8283 | Sublayer | Sublayer | Sublayer | 8284 | (optional) | (optional) | (optional) | 8285 |-----------------------------------------------------| 8286 | Access #1 IP | Access #2 IP | Access #3 IP | 8287 +-----------------------------------------------------+ 8288 Figure 7: MX Convergence Control Protocol Stack 8290 5.1 Keep-Alive Message 8292 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 8293 out Keep-Alive message periodically over one or multiple delivery 8294 connections, especially if UDP tunneling is used as the adaptation 8295 method for the delivery connection with a NAT function on the path. 8297 A Keep-Alive message is 6 Bytes long, and consists of the following 8298 fields: 8300 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 8301 keep-alive message 8302 o Timestamp (4 Bytes): the current value of the timestamp clock of 8303 the sender in the unit of 100 microseconds. 8305 5.2 Probe Message 8307 The "Type" field is set to "1" for Probe messages. 8309 N-MADP may send out the Probe message for path quality estimation. In 8310 response, C-MADP may send back the ACK message. 8312 A Probe message consists of the following fields: 8314 o Probing Sequence Number (2 Bytes): the sequence number of the 8315 Probe REQ message 8316 o Probing Flag (1 Byte): 8317 + Bit #0: a ACK flag to indicate if the ACK message is expected 8318 (1) or not (0); 8319 + Bit #1: a Probe Type flag to indicate if the Probe message is 8320 sent during the initialization phase (0) when the network 8321 path is not included for transmission of user data or the 8322 active phase (1) when the network path is included for 8323 transmission of user data; 8324 + Bit #2: a bit flag to indicate the presence of the Reverse 8325 Connection ID (R-CID) field. 8326 + Bit #3~7: reserved 8327 o Reverse Connection ID (1 Byte): the connection ID of the delivery 8328 connection for sending out the ACK message on the reverse path 8329 o Timestamp (4 Bytes): the current value of the timestamp clock of 8330 the sender in the unit of 100 microseconds. 8331 o Padding (variable) 8333 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 8334 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 8335 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 8336 ACK message is not expected. 8338 If the "R-CID" field is not present but the Bit #0 of the "Probing 8339 Flag" field is set to "1", the ACK message SHOULD be sent over the same 8340 delivery connection as the Probe message. 8342 The "Padding" field is used to control the length of Probe message. 8344 5.3 Packet Loss Report (PLR) Message 8346 The "Type" field is set to "2" for PLR messages. 8348 C-MADP may send out the PLR messages to report lost MX SDU for example 8349 during handover. In response, C-MADP may retransmit the lost MX SDU 8350 accordingly. 8352 A PLR message consists of the following fields: 8354 o Connection ID (1 Byte): an unsigned integer to identify the anchor 8355 connection which the ACK message is for; 8357 o Traffic Class ID (1 Byte): an unsigned integer to identify the 8358 traffic class of the anchor connection which the ACK message is 8359 for; 8360 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 8361 that the sender of the PLR message is expecting 8362 o Number of Loss Bursts (1 Byte) 8363 For each loss burst, include the following 8364 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 8365 + Number of consecutive lost MX SDUs in the burst (1 Byte) 8367 C-MADP N-MADP 8368 | | 8369 |<------------------ MX SDU (data packets)--------| 8370 | | 8371 +---------------------------------+ | 8372 |Packet Loss detected | | 8373 +---------------------------------+ | 8374 | | 8375 |----- PLR Message ------------------------------>| 8376 |<-------------retransmit(lost)MX SDUs -----------| 8378 Figure 8: MAMS Retransmission Procedure 8380 Figure 8 shows the MAMS retransmission procedure in an example where 8381 the lost packet is found and retransmitted. 8383 5.4 First Sequence Number (FSN) Message 8385 The "Type" field is set to "3" for FSN messages. 8387 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 8388 its buffer if a lost MX SDU is not found in the buffer after receiving 8389 the PLR message from C-MADP. In response, C-MADP SHALL only report 8390 packet loss with SN not smaller than FSN. 8392 A FSN message consists of the following fields: 8394 o Connection ID (1 Byte): an unsigned integer to identify the anchor 8395 connection which the FSN message is for; 8396 o Traffic Class ID (1 Byte): an unsigned integer to identify the 8397 traffic class of the anchor connection which the FSN message is 8398 for; 8399 o First Sequence Number (4 Bytes): the sequence number (SN) of the 8400 oldest MX SDU in the (retransmission) buffer of the sender of the 8401 FSN message. 8403 Figure 9 shows the MAMS retransmission procedure in an example where 8404 the lost packet is not found. 8406 C-MADP N-MADP 8407 | | 8408 |<------------------ MX SDU (data packets)--------| 8409 | | 8410 +---------------------------------+ | 8411 |Packet Loss detected | | 8412 +---------------------------------+ | 8413 | | 8414 |----- PLR Message ------------------------------>| 8415 | +---------------------+ 8416 | |Lost packet not found| 8417 | +---------------------+ 8418 |<-------------FSN message -----------------------| 8420 Figure 9: MAMS Retransmission Procedure with FSN 8422 5.5 Coded MX SDU (CMS) Message 8424 The "Type" field is set to "4" for CMS messages. 8426 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 8427 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 8428 [RLNC]. A coded MX SDU is generated by applying a network coding 8429 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 8430 fast recovery without retransmission if any of the MX SDUs is lost. 8432 A Coded MX SDU message consists of the following fields: 8434 o Connection ID (1 Byte): an unsigned integer to identify the anchor 8435 connection of the coded MX SDU; 8436 o Traffic Class ID (1 Byte): an unsigned integer to identify the 8437 traffic class of the coded MX; 8438 o Sequence Number (4 Bytes): the sequence number of the first 8439 (uncoded) MX SDU used to generate the coded MX SDU. 8440 o Fragmentation Control (FC) (1 Byte): to provide necessary 8441 information for re-assembly, only needed if the coded MX SDU is 8442 too long to transport in a single MX control PDU. 8443 o N (1 Byte): the number of consecutive MX SDUs used to generate the 8444 coded MX SDU 8445 o K (1 Byte): the length (in terms of bits) of the coding 8446 coefficient field 8447 o Coding Coefficient ( N x K / 8 Bytes) 8448 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 8449 + padding 8450 o Coded MX SDU (variable): the coded MX SDU 8452 If K = 0, the simple XOR method is used to generate the Coded MX SDU 8453 from N consecutive uncoded MX SDUs, and the a(i) fields are not 8454 included in the message. 8456 If the coded MX SDU is too long, it can be fragmented, and transported 8457 by multiple MX control PDUs. The N, K, and a(i) fields are only 8458 included in the MX PDU carrying the first fragment of the coded MX SDU. 8460 C-MADP N-MADP 8461 | | 8462 |<------------------ MX SDU #1 -------------------| 8463 | lost<-------- MX SDU #2 -------------------| 8464 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 8465 +----------------------+ | 8466 | MX SDU #2 recovered | | 8467 +----------------------+ | 8468 | | 8470 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 8472 5.6 Traffic Splitting Update (TSU) Message 8474 The "Type" field is set to "5" for TSU messages. 8476 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 8477 traffic splitting configuration has changed. 8479 A TSU message consists of the following fields: 8481 o Connection ID (1 Byte): an unsigned integer to identify the anchor 8482 connection; 8483 o Traffic Class ID (1 Byte): an unsigned integer to identify the 8484 traffic class; 8485 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 8486 message. 8487 o Flags (1 Byte) 8488 + Bit #0: a Reverse Path bit flag to indicate if the traffic 8489 splitting configuration is for the reverse path (1) or not 8490 (0); 8491 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 8492 used in traffic splitting 8493 + Others: reserved. 8494 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 8496 + StartSN (4 Bytes): the sequence number of the first MX SDU 8497 using the traffic splitting configuration provided by the TSU 8498 message 8499 + L (1 Byte): the traffic splitting burst size 8500 + K(i): the traffic splitting threshold of the i-th delivery 8501 connection, where connections are ordered according to their 8502 Connection ID. 8504 Let's use f(x) to denote the traffic splitting function, which maps a 8505 MX SDU Sequence Number "x" to the i-th delivery connection. 8507 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 8509 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 8511 N is the total number of connections for delivering a data flow, 8512 identified by (anchor) Connection ID and Traffic Class ID. 8514 When the bit-reversal bit is set to 1, the burst size L MUST be a power 8515 of 2, and the traffic splitting function is 8517 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 8519 Wherein F(.) is the bit reversal function [BITR] of the input variable. 8521 5.7 Acknowledgement Message 8523 The "Type" field is set to "6" for ACK messages. 8525 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 8526 successful reception of a PLR, FSN, or TSU message. 8528 C-MADP SHOULD send out the ACK message in response to a Probe message 8529 with the ACK flag set to "1". 8531 The ACK message consists of the following fields: 8533 o Acknowledgment Number (2 Bytes): the sequence number of the 8534 received message. 8535 o Timestamp (4 Bytes): the current value of the timestamp clock of 8536 the sender in the unit of 100 microseconds. 8538 6 Security Considerations 8540 User data in MAMS framework rely on the security of the underlying 8541 network transport paths. When this cannot be assumed, NCM configures 8542 use of appropriate protocols for security, e.g. IPsec [RFC4301] 8543 [RFC3948], DTLS [RFC6347]. 8545 7 IANA Considerations 8547 This draft makes no requests of IANA. 8549 8 Contributing Authors 8551 The editors gratefully acknowledge the following additional 8552 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 8553 Pentakota/Nokia. 8555 9 References 8557 9.1 Normative References 8559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 8560 Requirement Levels", BCP 14, RFC 2119, March 1997. 8562 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 8563 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 8564 December 2005, . 8566 9.2 Informative References 8568 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 8569 Security Version 1.2", RFC 6347, January 2012, 8570 . 8572 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 8573 Kivinen, "Internet Key Exchange Protocol Version 2 8574 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 8575 2014, . 8577 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 8578 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 8579 3948, DOI 10.17487/RFC3948, January 2005, . 8582 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 8583 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 8584 mechanism-02 8586 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 8587 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 8588 plain-mode-09.txt 8590 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 8591 Access Management Protocol", 8592 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 8593 protocol-03 8595 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 8596 Multi-Access Convergence", 8597 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 8599 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 8600 (GRE)", RFC 2784 March 2000, . 8603 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 8604 RFC 2890 September 2000, . 8607 [IANA] https://www.iana.org/assignments/protocol- 8608 numbers/protocol-numbers.xhtml 8610 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 8611 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 8612 Tunnel (LWIP) encapsulation; Protocol specification" 8614 [RFC791] Internet Protocol, September 1981 8616 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 8617 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 8618 IEEE Access, 2017 8620 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 8621 arXiv:1212.2291, 2012 8623 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 8624 Symbol Representation, https://www.ietf.org/id/draft- 8625 heide-nwcrg-rlnc-00.txt 8627 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 8628 38 (1): 1-26, 1996. 8630 Authors' Addresses 8632 Jing Zhu 8634 Intel 8636 Email: jing.z.zhu@intel.com 8637 SungHoon Seo 8639 Korea Telecom 8641 Email: sh.seo@kt.com 8643 Satish Kanugovi 8645 Nokia 8647 Email: satish.k@nokia.com 8649 Shuping Peng 8651 Huawei 8653 Email: pengshuping@huawei.com 8655 INTAREA J. Zhu 8656 Internet Draft Intel 8657 Intended status: Standards Track S. Seo 8658 Expires: April 1,2020 Korea Telecom 8659 S. Kanugovi 8660 Nokia 8661 S. Peng 8662 Huawei 8663 October 1, 2019 8665 User-Plane Protocols for Multiple Access Management Service 8666 draft-zhu-intarea-mams-user-protocol-07 8668 Status of this Memo 8670 This Internet-Draft is submitted in full conformance with the 8671 provisions of BCP 78 and BCP 79. 8673 Internet-Drafts are working documents of the Internet Engineering 8674 Task Force (IETF), its areas, and its working groups. Note that 8675 other groups may also distribute working documents as Internet- 8676 Drafts. 8678 Internet-Drafts are draft documents valid for a maximum of six 8679 months and may be updated, replaced, or obsoleted by other documents 8680 at any time. It is inappropriate to use Internet-Drafts as 8681 reference material or to cite them other than as "work in progress." 8683 The list of current Internet-Drafts can be accessed at 8684 http://www.ietf.org/ietf/1id-abstracts.txt 8686 The list of Internet-Draft Shadow Directories can be accessed at 8687 http://www.ietf.org/shadow.html 8689 This Internet-Draft will expire on April 1,2020. 8691 Copyright Notice 8693 Copyright (c) 2019 IETF Trust and the persons identified as the 8694 document authors. All rights reserved. 8696 This document is subject to BCP 78 and the IETF Trust's Legal 8697 Provisions Relating to IETF Documents 8698 (http://trustee.ietf.org/license-info) in effect on the date of 8699 publication of this document. Please review these documents 8700 carefully, as they describe your rights and restrictions with 8701 respect to this document. Code Components extracted from this 8702 document must include Simplified BSD License text as described in 8703 Section 4.e of the Trust Legal Provisions and are provided without 8704 warranty as described in the Simplified BSD License. 8706 Abstract 8708 Today, a device can be simultaneously connected to multiple 8709 communication networks based on different technology implementations 8710 and network architectures like WiFi, LTE, and DSL. In such multi- 8711 connectivity scenario, it is desirable to combine multiple access 8712 networks or select the best one to improve quality of experience for 8713 a user and improve overall network utilization and efficiency. This 8714 document presents the u-plane protocols for a multi access 8715 management services (MAMS) framework that can be used to flexibly 8716 select the combination of uplink and downlink access and core 8717 network paths having the optimal performance, and user plane 8718 treatment for improving network utilization and efficiency and 8719 enhanced quality of experience for user applications. 8721 Table of Contents 8723 1. Introduction................................................... 3 8724 2. Terminologies.................................................. 3 8725 3. Conventions used in this document.............................. 3 8726 4 MAMS User-Plane Protocols...................................... 4 8727 4.1 MX Adaptation Sublayer................................... 4 8728 4.2 GMA-based MX Convergence Sublayer........................ 5 8729 4.3 MPTCP-based MX Convergence Sublayer...................... 6 8730 4.4 GRE as MX Convergence Sublayer........................... 6 8731 4.4.1 Transmitter Procedures.............................7 8732 4.4.2 Receiver Procedures................................8 8733 4.5 MX Adaptation and Convergence Co-existence............... 8 8734 5. MX Convergence Control Message................................. 8 8735 5.1 Keep-Alive Message....................................... 9 8736 5.2 Probe Message............................................ 9 8737 5.3 Packet Loss Report (PLR) Message........................ 10 8738 5.4 First Sequence Number (FSN) Message..................... 11 8739 5.5 Coded MX SDU (CMS) Message.............................. 12 8740 5.6 Traffic Splitting Update (TSU) Message.................. 13 8741 5.7 Acknowledgement Message................................. 14 8742 6 Security Considerations....................................... 14 8743 7 IANA Considerations........................................... 15 8744 8 Contributing Authors.......................................... 15 8745 9 References.................................................... 15 8746 9.1 Normative References.................................... 15 8747 9.2 Informative References.................................. 15 8749 1. Introduction 8751 Multi Access Management Service (MAMS) [MAMS] is a programmable 8752 framework to select and configure network paths, as well as adapt to 8753 dynamic network conditions, when multiple network connections can 8754 serve a client device. It is based on principles of user plane 8755 interworking that enables the solution to be deployed as an overlay 8756 without impacting the underlying networks. 8758 This document presents the u-plane protocols for enabling the MAMS 8759 framework. It co-exists and complements the existing protocols by 8760 providing a way to negotiate and configure the protocols based on 8761 client and network capabilities. Further it allows exchange of 8762 network state information and leveraging network intelligence to 8763 optimize the performance of such protocols. An important goal for 8764 MAMS is to ensure that there is minimal or no dependency on the 8765 actual access technology of the participating links. This allows the 8766 scheme to be scalable for addition of newer access technologies and 8767 for independent evolution of the existing access technologies. 8769 2. Terminologies 8771 Anchor Connection: refers to the network path from the N-MADP to the 8772 Application Server that corresponds to a specific IP anchor that has 8773 assigned an IP address to the client. 8775 Delivery Connection: refers to the network path from the N-MADP to 8776 the C-MADP. 8778 "Network Connection Manager" (NCM), "Client Connection Manager" 8779 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 8780 Access Data Proxy" (C-MADP) in this document are to be interpreted 8781 as described in [MAMS]. 8783 3. Conventions used in this document 8785 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 8786 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 8787 document are to be interpreted as described in [RFC2119]. 8789 The terminologies "Network Connection Manager" (NCM), "Client 8790 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 8791 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 8792 document are to be interpreted as described in [MAMS]. 8794 4 MAMS User-Plane Protocols 8796 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 8797 +-----------------------------------------------------+ 8798 | User Payload (e.g. IP PDU) | 8799 |-----------------------------------------------------| 8800 +--|-----------------------------------------------------|--+ 8801 | |-----------------------------------------------------| | 8802 | | Multi-Access (MX) Convergence Sublayer | | 8803 | |-----------------------------------------------------| | 8804 | |-----------------------------------------------------| | 8805 | | MX Adaptation | MX Adaptation | MX Adaptation | | 8806 | | Sublayer | Sublayer | Sublayer | | 8807 | | (optional) | (optional) | (optional) | | 8808 | |-----------------------------------------------------| | 8809 | | Access #1 IP | Access #2 IP | Access #3 IP | | 8810 | +-----------------------------------------------------+ | 8811 +-----------------------------------------------------------+ 8812 Figure 1: MAMS U-plane Protocol Stack 8813 It consists of the following two Sublayers: 8815 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 8816 access specific tasks, e.g., access (path) selection, multi-link 8817 (path) aggregation, splitting/reordering, lossless switching, 8818 fragmentation, concatenation, keep-alive, and probing etc. 8819 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 8820 to handle tunneling, network layer security, and NAT. 8822 The MX convergence sublayer operates on top of the MX adaptation 8823 sublayer in the protocol stack. From the Transmitter perspective, a 8824 User Payload (e.g. IP PDU) is processed by the convergence sublayer 8825 first, and then by the adaptation sublayer before being transported 8826 over a delivery access connection; from the Receiver perspective, an IP 8827 packet received over a delivery connection is processed by the MX 8828 adaptation sublayer first, and then by the MX convergence sublayer. 8830 4.1 MX Adaptation Sublayer 8832 The MX adaptation sublayer supports the following mechanisms and 8833 protocols while transmitting user plane packets on the network path: 8835 o UDP Tunneling: The user plane packets of the anchor connection can be 8836 encapsulated in a UDP tunnel of a delivery connection between the N- 8837 MADP and C-MADP. 8839 o IPsec Tunneling: The user plane packets of the anchor connection are 8840 sent through an IPsec tunnel of a delivery connection. 8841 o Client Net Address Translation (NAT): The Client IP address of user 8842 plane packet of the anchor connection is changed, and sent over a 8843 delivery connection. 8844 o Pass Through: The user plane packets are passing through without any 8845 change over the anchor connection. 8847 The MX adaptation sublayer also supports the following mechanisms and 8848 protocols to ensure security of user plane packets over the network 8849 path. 8851 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 8852 N-MADP and C-MADP on the network path that is considered untrusted. 8853 o DTLS: If UDP tunneling is used on the network path that is considered 8854 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 8855 be used. 8857 The Client NAT method is the most efficient due to no tunneling 8858 overhead. It SHOULD be used if a delivery connection is "trusted" and 8859 without NAT function on the path. 8861 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 8862 connection has a NAT function placed on the path. 8864 4.2 GMA-based MX Convergence Sublayer 8866 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 8867 encapsulation [GMA]. Multiple access networks are combined into a 8868 single IP connection. If NCM determines that N-MADP is to be 8869 instantiated with GMA as the MX Convergence Protocol, it exchanges the 8870 support of GMA convergence capability in the discovery and capability 8871 exchange procedures [MAMS]. 8873 +-----------------------------------------------------+ 8874 | IP PDU | 8875 |-----------------------------------------------------| 8876 | GMA Convergence Sublayer | 8877 |-----------------------------------------------------| 8878 | MX Adaptation | MX Adaptation | MX Adaptation | 8879 | Sublayer | Sublayer | Sublayer | 8880 | (optional) | (optional) | (optional) | 8881 |-----------------------------------------------------| 8882 | Access #1 IP | Access #2 IP | Access #3 IP | 8883 +-----------------------------------------------------+ 8884 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 8886 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 8887 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 8888 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 8889 message [MAMS] is true, the "IP length" and "IP checksum" header fields 8890 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 8891 updated after adding or removing the GMA trailer in the convergence 8892 sublayer. 8894 +------------------------------------------------------+ 8895 | IP hdr | IP payload | GMA Trailer | 8896 +------------------------------------------------------+ 8897 Figure 3: GMA PDU Format 8899 4.3 MPTCP-based MX Convergence Sublayer 8901 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 8902 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 8903 access networks are combined into a single MPTCP connection. Hence, no 8904 new u-plane protocol or PDU format is needed in this case. 8906 |-----------------------------------------------------| 8907 | MPTCP | 8908 |-----------------------------------------------------| 8909 | TCP | TCP | TCP | 8910 |-----------------------------------------------------| 8911 | MX Adaptation | MX Adaptation | MX Adaptation | 8912 | Sublayer | Sublayer | Sublayer | 8913 | (optional) | (optional) | (optional) | 8914 |-----------------------------------------------------| 8915 | Access #1 IP | Access #2 IP | Access #3 IP | 8916 +-----------------------------------------------------+ 8917 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 8918 Layer 8920 If NCM determines that N-MADP is to be instantiated with MPTCP as the 8921 MX Convergence Protocol, it exchanges the support of MPTCP capability 8922 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 8923 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 8924 and aggregation over multiple delivery connections. 8926 4.4 GRE as MX Convergence Sublayer 8928 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 8929 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 8930 Convergence sub-layer" protocol. Multiple access networks are combined 8931 into a single GRE connection. Hence, no new u-plane protocol or PDU 8932 format is needed in this case. 8934 +-----------------------------------------------------+ 8935 | User Payload (e.g. IP PDU) | 8936 |-----------------------------------------------------| 8937 | GRE as MX Convergence Sublayer | 8938 |-----------------------------------------------------| 8939 | GRE Delivery Protocol (e.g. IP) | 8940 |-----------------------------------------------------| 8941 | MX Adaptation | MX Adaptation | MX Adaptation | 8942 | Sublayer | Sublayer | Sublayer | 8943 | (optional) | (optional) | (optional) | 8944 |-----------------------------------------------------| 8945 | Access #1 IP | Access #2 IP | Access #3 IP | 8946 +-----------------------------------------------------+ 8947 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 8948 Layer 8950 If NCM determines that N-MADP is to be instantiated with GRE as the MX 8951 Convergence Protocol, it exchanges the support of GRE capability in the 8952 discovery and capability exchange procedures [MAMS]. 8954 4.4.1 Transmitter Procedures 8956 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 8957 the convergence protocol that transmits the GRE packets. The 8958 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 8959 with a GRE header and Delivery Protocol (e.g. IP) header to generate 8960 the GRE Convergence PDU. 8962 When IP is used as the GRE delivery protocol, the IP header information 8963 (e.g. IP address) can be created using the IP header of the user 8964 payload or a virtual IP address. The "Protocol Type" field of the 8965 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 8967 The GRE header fields are set as specified below, 8969 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 8970 to the value of Connection ID for the Anchor Connection associated 8971 with the user payload or sets to 0xFFFF if no Anchor Connection ID 8972 needs to be specified. 8973 - All other fields in the GRE header including the remaining bits in 8974 the key fields are set as per [GRE_2784][GRE_2890]. 8976 4.4.2 Receiver Procedures 8978 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 8979 convergence protocol that receives the GRE packets. The receiver 8980 processes the received packets per the GRE procedures [GRE_2784, 8981 GRE_2890] and retrieves the GRE header. 8983 - If the Receiver is an N-MADP instance, 8984 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 8985 interpreted as the Connection ID of Anchor Connection for the 8986 user payload. This is used to identify the network path over 8987 which the User Payload (GRE Payload) is to be transmitted. 8988 - All other fields in the GRE header, including the remaining bits 8989 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 8991 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 8992 present) before delivery over one of the network paths. 8994 4.5 MX Adaptation and Convergence Co-existence 8996 MAMS u-plane protocols support multiple combinations and instances of 8997 user plane protocols to be used in the MX Adaptation and the 8998 Convergence sublayers. 9000 For example, one instance of the MX Convergence Layer can be MPTCP 9001 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 9002 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 9003 set up for network paths considered as untrusted by the operator, to 9004 protect the TCP subflow between client and MPTCP proxy traversing that 9005 network path. 9007 Each of the instances of MAMS user plane, i.e. combination of MX 9008 Convergence and MX Adaptation layer protocols, can coexist 9009 simultaneously and independently handle different traffic types. 9011 5. MX Convergence Control Message 9013 A UDP connection may be configured between C-MADP and N-MADP to 9014 exchange control messages for keep-alive or path quality estimation. 9015 The N-MADP end-point IP address and UDP port number of the UDP 9016 connection is used to identify MX control PDU. Figure 6 shows the MX 9017 control PDU format with the following fields: 9019 o Type (1 Byte): the type of the MX control message 9020 o CID (1 Byte): an unsigned integer to identify the anchor and 9021 delivery connection of the MX control message 9022 + Anchor Connection ID (MSB 4 Bits): an unsigned integer to 9023 identify the anchor connection 9024 + Delivery Connection ID (LSB 4 Bits): an unsigned integer to 9025 identify the delivery connection 9026 o MX Control Message (variable): the payload of the MX control 9027 message 9029 Figure 7 shows the MX convergence control protocol stack, and MX 9030 control PDU goes through the MX adaptation sublayer the same way as MX 9031 data PDU. 9033 <----MX Control PDU Payload ---------------> 9034 +------------------------------------------------------------------+ 9035 | IP header | UDP Header| Type | CID | MX Control Message | 9036 +------------------------------------------------------------------+ 9037 Figure 6: MX Control PDU Format 9039 |-----------------------------------------------------| 9040 | MX Convergence Control Messages | 9041 |-----------------------------------------------------| 9042 | UDP/IP | 9043 |-----------------------------------------------------| 9044 | MX Adaptation | MX Adaptation | MX Adaptation | 9045 | Sublayer | Sublayer | Sublayer | 9046 | (optional) | (optional) | (optional) | 9047 |-----------------------------------------------------| 9048 | Access #1 IP | Access #2 IP | Access #3 IP | 9049 +-----------------------------------------------------+ 9050 Figure 7: MX Convergence Control Protocol Stack 9052 5.1 Keep-Alive Message 9054 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 9055 out Keep-Alive message periodically over one or multiple delivery 9056 connections, especially if UDP tunneling is used as the adaptation 9057 method for the delivery connection with a NAT function on the path. 9059 A Keep-Alive message is 6 Bytes long, and consists of the following 9060 fields: 9062 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 9063 keep-alive message 9064 o Timestamp (4 Bytes): the current value of the timestamp clock of 9065 the sender in the unit of 100 microseconds. 9067 5.2 Probe Message 9069 The "Type" field is set to "1" for Probe messages. 9071 N-MADP may send out the Probe message for path quality estimation. In 9072 response, C-MADP may send back the ACK message. 9074 A Probe message consists of the following fields: 9076 o Probing Sequence Number (2 Bytes): the sequence number of the 9077 Probe REQ message 9078 o Probing Flag (1 Byte): 9079 + Bit #0: a ACK flag to indicate if the ACK message is expected 9080 (1) or not (0); 9081 + Bit #1: a Probe Type flag to indicate if the Probe message is 9082 sent during the initialization phase (0) when the network 9083 path is not included for transmission of user data or the 9084 active phase (1) when the network path is included for 9085 transmission of user data; 9086 + Bit #2: a bit flag to indicate the presence of the Reverse 9087 Connection ID (R-CID) field. 9088 + Bit #3~7: reserved 9089 o Reverse Connection ID (1 Byte): the connection ID of the delivery 9090 connection for sending out the ACK message on the reverse path 9091 o Timestamp (4 Bytes): the current value of the timestamp clock of 9092 the sender in the unit of 100 microseconds. 9093 o Padding (variable) 9095 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 9096 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 9097 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 9098 ACK message is not expected. 9100 If the "R-CID" field is not present but the Bit #0 of the "Probing 9101 Flag" field is set to "1", the ACK message SHOULD be sent over the same 9102 delivery connection as the Probe message. 9104 The "Padding" field is used to control the length of Probe message. 9106 5.3 Packet Loss Report (PLR) Message 9108 The "Type" field is set to "2" for PLR messages. 9110 C-MADP may send out the PLR messages to report lost MX SDU for example 9111 during handover. In response, C-MADP may retransmit the lost MX SDU 9112 accordingly. 9114 A PLR message consists of the following fields: 9116 o Connection ID (1 Byte): an unsigned integer to identify the anchor 9117 connection which the ACK message is for; 9119 o Traffic Class ID (1 Byte): an unsigned integer to identify the 9120 traffic class of the anchor connection which the ACK message is 9121 for; 9122 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 9123 that the sender of the PLR message is expecting 9124 o Number of Loss Bursts (1 Byte) 9125 For each loss burst, include the following 9126 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 9127 + Number of consecutive lost MX SDUs in the burst (1 Byte) 9129 C-MADP N-MADP 9130 | | 9131 |<------------------ MX SDU (data packets)--------| 9132 | | 9133 +---------------------------------+ | 9134 |Packet Loss detected | | 9135 +---------------------------------+ | 9136 | | 9137 |----- PLR Message ------------------------------>| 9138 |<-------------retransmit(lost)MX SDUs -----------| 9140 Figure 8: MAMS Retransmission Procedure 9142 Figure 8 shows the MAMS retransmission procedure in an example where 9143 the lost packet is found and retransmitted. 9145 5.4 First Sequence Number (FSN) Message 9147 The "Type" field is set to "3" for FSN messages. 9149 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 9150 its buffer if a lost MX SDU is not found in the buffer after receiving 9151 the PLR message from C-MADP. In response, C-MADP SHALL only report 9152 packet loss with SN not smaller than FSN. 9154 A FSN message consists of the following fields: 9156 o Connection ID (1 Byte): an unsigned integer to identify the anchor 9157 connection which the FSN message is for; 9158 o Traffic Class ID (1 Byte): an unsigned integer to identify the 9159 traffic class of the anchor connection which the FSN message is 9160 for; 9161 o First Sequence Number (4 Bytes): the sequence number (SN) of the 9162 oldest MX SDU in the (retransmission) buffer of the sender of the 9163 FSN message. 9165 Figure 9 shows the MAMS retransmission procedure in an example where 9166 the lost packet is not found. 9168 C-MADP N-MADP 9169 | | 9170 |<------------------ MX SDU (data packets)--------| 9171 | | 9172 +---------------------------------+ | 9173 |Packet Loss detected | | 9174 +---------------------------------+ | 9175 | | 9176 |----- PLR Message ------------------------------>| 9177 | +---------------------+ 9178 | |Lost packet not found| 9179 | +---------------------+ 9180 |<-------------FSN message -----------------------| 9182 Figure 9: MAMS Retransmission Procedure with FSN 9184 5.5 Coded MX SDU (CMS) Message 9186 The "Type" field is set to "4" for CMS messages. 9188 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 9189 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 9190 [RLNC]. A coded MX SDU is generated by applying a network coding 9191 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 9192 fast recovery without retransmission if any of the MX SDUs is lost. 9194 A Coded MX SDU message consists of the following fields: 9196 o Connection ID (1 Byte): an unsigned integer to identify the anchor 9197 connection of the coded MX SDU; 9198 o Traffic Class ID (1 Byte): an unsigned integer to identify the 9199 traffic class of the coded MX; 9200 o Sequence Number (4 Bytes): the sequence number of the first 9201 (uncoded) MX SDU used to generate the coded MX SDU. 9202 o Fragmentation Control (FC) (1 Byte): to provide necessary 9203 information for re-assembly, only needed if the coded MX SDU is 9204 too long to transport in a single MX control PDU. 9205 o N (1 Byte): the number of consecutive MX SDUs used to generate the 9206 coded MX SDU 9207 o K (1 Byte): the length (in terms of bits) of the coding 9208 coefficient field 9209 o Coding Coefficient ( N x K / 8 Bytes) 9210 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 9211 + padding 9212 o Coded MX SDU (variable): the coded MX SDU 9214 If K = 0, the simple XOR method is used to generate the Coded MX SDU 9215 from N consecutive uncoded MX SDUs, and the a(i) fields are not 9216 included in the message. 9218 If the coded MX SDU is too long, it can be fragmented, and transported 9219 by multiple MX control PDUs. The N, K, and a(i) fields are only 9220 included in the MX PDU carrying the first fragment of the coded MX SDU. 9222 C-MADP N-MADP 9223 | | 9224 |<------------------ MX SDU #1 -------------------| 9225 | lost<-------- MX SDU #2 -------------------| 9226 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 9227 +----------------------+ | 9228 | MX SDU #2 recovered | | 9229 +----------------------+ | 9230 | | 9232 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 9234 5.6 Traffic Splitting Update (TSU) Message 9236 The "Type" field is set to "5" for TSU messages. 9238 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 9239 traffic splitting configuration has changed. 9241 A TSU message consists of the following fields: 9243 o Connection ID (1 Byte): an unsigned integer to identify the anchor 9244 connection; 9245 o Traffic Class ID (1 Byte): an unsigned integer to identify the 9246 traffic class; 9247 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 9248 message. 9249 o Flags (1 Byte) 9250 + Bit #0: a Reverse Path bit flag to indicate if the traffic 9251 splitting configuration is for the reverse path (1) or not 9252 (0); 9253 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 9254 used in traffic splitting 9255 + Others: reserved. 9256 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 9258 + StartSN (4 Bytes): the sequence number of the first MX SDU 9259 using the traffic splitting configuration provided by the TSU 9260 message 9261 + L (1 Byte): the traffic splitting burst size 9262 + K(i): the traffic splitting threshold of the i-th delivery 9263 connection, where connections are ordered according to their 9264 Connection ID. 9266 Let's use f(x) to denote the traffic splitting function, which maps a 9267 MX SDU Sequence Number "x" to the i-th delivery connection. 9269 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 9271 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 9273 N is the total number of connections for delivering a data flow, 9274 identified by (anchor) Connection ID and Traffic Class ID. 9276 When the bit-reversal bit is set to 1, the burst size L MUST be a power 9277 of 2, and the traffic splitting function is 9279 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 9281 Wherein F(.) is the bit reversal function [BITR] of the input variable. 9283 5.7 Acknowledgement Message 9285 The "Type" field is set to "6" for ACK messages. 9287 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 9288 successful reception of a PLR, FSN, or TSU message. 9290 C-MADP SHOULD send out the ACK message in response to a Probe message 9291 with the ACK flag set to "1". 9293 The ACK message consists of the following fields: 9295 o Acknowledgment Number (2 Bytes): the sequence number of the 9296 received message. 9297 o Timestamp (4 Bytes): the current value of the timestamp clock of 9298 the sender in the unit of 100 microseconds. 9300 6 Security Considerations 9302 User data in MAMS framework rely on the security of the underlying 9303 network transport paths. When this cannot be assumed, NCM configures 9304 use of appropriate protocols for security, e.g. IPsec [RFC4301] 9305 [RFC3948], DTLS [RFC6347]. 9307 7 IANA Considerations 9309 This draft makes no requests of IANA. 9311 8 Contributing Authors 9313 The editors gratefully acknowledge the following additional 9314 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 9315 Pentakota/Nokia. 9317 9 References 9319 9.1 Normative References 9321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9322 Requirement Levels", BCP 14, RFC 2119, March 1997. 9324 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 9325 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 9326 December 2005, . 9328 9.2 Informative References 9330 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 9331 Security Version 1.2", RFC 6347, January 2012, 9332 . 9334 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 9335 Kivinen, "Internet Key Exchange Protocol Version 2 9336 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 9337 2014, . 9339 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 9340 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 9341 3948, DOI 10.17487/RFC3948, January 2005, . 9344 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 9345 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 9346 mechanism-02 9348 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 9349 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 9350 plain-mode-09.txt 9352 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 9353 Access Management Protocol", 9354 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 9355 protocol-03 9357 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 9358 Multi-Access Convergence", 9359 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 9361 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 9362 (GRE)", RFC 2784 March 2000, . 9365 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 9366 RFC 2890 September 2000, . 9369 [IANA] https://www.iana.org/assignments/protocol- 9370 numbers/protocol-numbers.xhtml 9372 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 9373 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 9374 Tunnel (LWIP) encapsulation; Protocol specification" 9376 [RFC791] Internet Protocol, September 1981 9378 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 9379 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 9380 IEEE Access, 2017 9382 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 9383 arXiv:1212.2291, 2012 9385 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 9386 Symbol Representation, https://www.ietf.org/id/draft- 9387 heide-nwcrg-rlnc-00.txt 9389 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 9390 38 (1): 1-26, 1996. 9392 Authors' Addresses 9394 Jing Zhu 9396 Intel 9398 Email: jing.z.zhu@intel.com 9399 SungHoon Seo 9401 Korea Telecom 9403 Email: sh.seo@kt.com 9405 Satish Kanugovi 9407 Nokia 9409 Email: satish.k@nokia.com 9411 Shuping Peng 9413 Huawei 9415 Email: pengshuping@huawei.com