idnits 2.17.1 draft-zhu-intarea-mams-user-protocol-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 305 has weird spacing: '...the convergen...' == Line 327 has weird spacing: '...ergence proto...' == Line 328 has weird spacing: '...ocesses the ...' -- The document date (April 3, 2019) is 1843 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'GRE2890' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'LWIPEP' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 717, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: October 3,2019 5 Korea Telecom 6 S. Kanugovi 7 Nokia 8 S. Peng 9 Huawei 10 April 3, 2019 12 User-Plane Protocols for Multiple Access Management Service 13 draft-zhu-intarea-mams-user-protocol-07 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on September 3, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 Today, a device can be simultaneously connected to multiple 56 communication networks based on different technology implementations 57 and network architectures like WiFi, LTE, and DSL. In such multi- 58 connectivity scenario, it is desirable to combine multiple access 59 networks or select the best one to improve quality of experience for 60 a user and improve overall network utilization and efficiency. This 61 document presents the u-plane protocols for a multi access 62 management services (MAMS) framework that can be used to flexibly 63 select the combination of uplink and downlink access and core 64 network paths having the optimal performance, and user plane 65 treatment for improving network utilization and efficiency and 66 enhanced quality of experience for user applications. 68 Table of Contents 70 1. Introduction...................................................3 71 2. Terminologies..................................................3 72 3. Conventions used in this document..............................3 73 4 MAMS User-Plane Protocols......................................4 74 4.1 MX Adaptation Sublayer...................................4 75 4.2 GMA-based MX Convergence Sublayer........................5 76 4.3 MPTCP-based MX Convergence Sublayer......................6 77 4.4 GRE as MX Convergence Sublayer...........................6 78 4.4.1 Transmitter Procedures.............................7 79 4.4.2 Receiver Procedures................................8 80 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 81 8 82 5. MX Convergence Control Message.................................8 83 5.1 Keep-Alive Message.......................................9 84 5.2 Probe Message............................................9 85 5.3 Packet Loss Report (PLR) Message........................10 86 5.4 First Sequence Number (FSN) Message.....................11 87 5.5 Coded MX SDU (CMS) Message..............................12 88 5.6 Traffic Splitting Update (TSU) Message..................13 89 5.7 Acknowledgement Message.................................14 90 6 Security Considerations.......................................14 91 7 IANA Considerations...........................................15 92 8 Contributing Authors..........................................15 93 9 References....................................................15 94 9.1 Normative References....................................15 95 9.2 Informative References..................................15 97 1. Introduction 99 Multi Access Management Service (MAMS) [MAMS] is a programmable 100 framework to select and configure network paths, as well as adapt to 101 dynamic network conditions, when multiple network connections can 102 serve a client device. It is based on principles of user plane 103 interworking that enables the solution to be deployed as an overlay 104 without impacting the underlying networks. 106 This document presents the u-plane protocols for enabling the MAMS 107 framework. It co-exists and complements the existing protocols by 108 providing a way to negotiate and configure the protocols based on 109 client and network capabilities. Further it allows exchange of 110 network state information and leveraging network intelligence to 111 optimize the performance of such protocols. An important goal for 112 MAMS is to ensure that there is minimal or no dependency on the 113 actual access technology of the participating links. This allows the 114 scheme to be scalable for addition of newer access technologies and 115 for independent evolution of the existing access technologies. 117 2. Terminologies 119 Anchor Connection: refers to the network path from the N-MADP to the 120 Application Server that corresponds to a specific IP anchor that has 121 assigned an IP address to the client. 123 Delivery Connection: refers to the network path from the N-MADP to 124 the C-MADP. 126 "Network Connection Manager" (NCM), "Client Connection Manager" 127 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 128 Access Data Proxy" (C-MADP) in this document are to be interpreted 129 as described in [MAMS]. 131 3. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The terminologies "Network Connection Manager" (NCM), "Client 138 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 139 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 140 document are to be interpreted as described in [MAMS]. 142 4 MAMS User-Plane Protocols 144 Figure 1 shows the MAMS u-plane protocol stack as specified in [MAMS]. 145 +-----------------------------------------------------+ 146 | User Payload (e.g. IP PDU) | 147 |-----------------------------------------------------| 148 +--|-----------------------------------------------------|--+ 149 | |-----------------------------------------------------| | 150 | | Multi-Access (MX) Convergence Sublayer | | 151 | |-----------------------------------------------------| | 152 | |-----------------------------------------------------| | 153 | | MX Adaptation | MX Adaptation | MX Adaptation | | 154 | | Sublayer | Sublayer | Sublayer | | 155 | | (optional) | (optional) | (optional) | | 156 | |-----------------------------------------------------| | 157 | | Access #1 IP | Access #2 IP | Access #3 IP | | 158 | +-----------------------------------------------------+ | 159 +-----------------------------------------------------------+ 160 Figure 1: MAMS U-plane Protocol Stack 161 It consists of the following two Sublayers: 163 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 164 access specific tasks, e.g., access (path) selection, multi-link 165 (path) aggregation, splitting/reordering, lossless switching, 166 fragmentation, concatenation, keep-alive, and probing etc. 167 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 168 to handle tunneling, network layer security, and NAT. 170 The MX convergence sublayer operates on top of the MX adaptation 171 sublayer in the protocol stack. From the Transmitter perspective, a 172 User Payload (e.g. IP PDU) is processed by the convergence sublayer 173 first, and then by the adaptation sublayer before being transported 174 over a delivery access connection; from the Receiver perspective, an IP 175 packet received over a delivery connection is processed by the MX 176 adaptation sublayer first, and then by the MX convergence sublayer. 178 4.1 MX Adaptation Sublayer 180 The MX adaptation sublayer supports the following mechanisms and 181 protocols while transmitting user plane packets on the network path: 183 o UDP Tunneling: The user plane packets of the anchor connection can be 184 encapsulated in a UDP tunnel of a delivery connection between the N- 185 MADP and C-MADP. 187 o IPsec Tunneling: The user plane packets of the anchor connection are 188 sent through an IPsec tunnel of a delivery connection. 189 o Client Net Address Translation (NAT): The Client IP address of user 190 plane packet of the anchor connection is changed, and sent over a 191 delivery connection. 192 o Pass Through: The user plane packets are passing through without any 193 change over the anchor connection. 195 The MX adaptation sublayer also supports the following mechanisms and 196 protocols to ensure security of user plane packets over the network 197 path. 199 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 200 N-MADP and C-MADP on the network path that is considered untrusted. 201 o DTLS: If UDP tunneling is used on the network path that is considered 202 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 203 be used. 205 The Client NAT method is the most efficient due to no tunneling 206 overhead. It SHOULD be used if a delivery connection is "trusted" and 207 without NAT function on the path. 209 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 210 connection has a NAT function placed on the path. 212 4.2 GMA-based MX Convergence Sublayer 214 Figure 2 shows the MAMS u-plane protocol stack based on trailer-based 215 encapsulation [GMA]. Multiple access networks are combined into a 216 single IP connection. If NCM determines that N-MADP is to be 217 instantiated with GMA as the MX Convergence Protocol, it exchanges the 218 support of GMA trailer-based convergence capability in the discovery 219 and capability exchange procedures [MAMS]. 221 +-----------------------------------------------------+ 222 | IP PDU | 223 |-----------------------------------------------------| 224 | Trailer-based GMA Convergence Sublayer | 225 |-----------------------------------------------------| 226 | MX Adaptation | MX Adaptation | MX Adaptation | 227 | Sublayer | Sublayer | Sublayer | 228 | (optional) | (optional) | (optional) | 229 |-----------------------------------------------------| 230 | Access #1 IP | Access #2 IP | Access #3 IP | 231 +-----------------------------------------------------+ 232 Figure 2: MAMS U-plane Protocol Stack with GMA as MX Convergence Layer 234 Figure 3 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 235 Unit) format [GMA]. If the MX adaptation method is UDP tunneling and 236 "MX header optimization" in the "MX_UP_Setup_Configuration_Request" 237 message [MAMS] is true, the "IP length" and "IP checksum" header fields 238 of the MX PDU SHOULD remain unchanged. Otherwise, they should be 239 updated after adding or removing the GMA trailer in the convergence 240 sublayer. 242 +------------------------------------------------------+ 243 | IP hdr | IP payload | GMA Trailer | 244 +------------------------------------------------------+ 245 Figure 3: GMA PDU Format 247 4.3 MPTCP-based MX Convergence Sublayer 249 Figure 4 shows the MAMS u-plane protocol stack based on MPTCP. Here, 250 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 251 access networks are combined into a single MPTCP connection. Hence, no 252 new u-plane protocol or PDU format is needed in this case. 254 |-----------------------------------------------------| 255 | MPTCP | 256 |-----------------------------------------------------| 257 | TCP | TCP | TCP | 258 |-----------------------------------------------------| 259 | MX Adaptation | MX Adaptation | MX Adaptation | 260 | Sublayer | Sublayer | Sublayer | 261 | (optional) | (optional) | (optional) | 262 |-----------------------------------------------------| 263 | Access #1 IP | Access #2 IP | Access #3 IP | 264 +-----------------------------------------------------+ 265 Figure 4: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 266 Layer 268 If NCM determines that N-MADP is to be instantiated with MPTCP as the 269 MX Convergence Protocol, it exchanges the support of MPTCP capability 270 in the discovery and capability exchange procedures [MAMS]. MPTCP proxy 271 protocols [MPProxy][MPPlain] SHOULD be used to manage traffic steering 272 and aggregation over multiple delivery connections. 274 4.4 GRE as MX Convergence Sublayer 276 Figure 5 shows the MAMS u-plane protocol stack based on GRE (Generic 277 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 278 Convergence sub-layer" protocol. Multiple access networks are combined 279 into a single GRE connection. Hence, no new u-plane protocol or PDU 280 format is needed in this case. 282 +-----------------------------------------------------+ 283 | User Payload (e.g. IP PDU) | 284 |-----------------------------------------------------| 285 | GRE as MX Convergence Sublayer | 286 |-----------------------------------------------------| 287 | GRE Delivery Protocol (e.g. IP) | 288 |-----------------------------------------------------| 289 | MX Adaptation | MX Adaptation | MX Adaptation | 290 | Sublayer | Sublayer | Sublayer | 291 | (optional) | (optional) | (optional) | 292 |-----------------------------------------------------| 293 | Access #1 IP | Access #2 IP | Access #3 IP | 294 +-----------------------------------------------------+ 295 Figure 5: MAMS U-plane Protocol Stack with GRE as MX Convergence 296 Layer 298 If NCM determines that N-MADP is to be instantiated with GRE as the MX 299 Convergence Protocol, it exchanges the support of GRE capability in the 300 discovery and capability exchange procedures [MAMS]. 302 4.4.1 Transmitter Procedures 304 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 305 the convergence protocol that transmits the GRE packets. The 306 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 307 with a GRE header and Delivery Protocol (e.g. IP) header to generate 308 the GRE Convergence PDU. 310 When IP is used as the GRE delivery protocol, the IP header information 311 (e.g. IP address) can be created using the IP header of the user 312 payload or a virtual IP address. The "Protocol Type" field of the 313 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 315 The GRE header fields are set as specified below, 317 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 318 to the value of Connection ID for the Anchor Connection associated 319 with the user payload or sets to 0xFFFF if no Anchor Connection ID 320 needs to be specified. 321 - All other fields in the GRE header including the remaining bits in 322 the key fields are set as per [GRE_2784][GRE_2890]. 324 4.4.2 Receiver Procedures 326 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 327 convergence protocol that receives the GRE packets. The receiver 328 processes the received packets per the GRE procedures [GRE_2784, 329 GRE_2890] and retrieves the GRE header. 331 - If the Receiver is an N-MADP instance, 332 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 333 interpreted as the Connection ID of Anchor Connection for the 334 user payload. This is used to identify the network path over 335 which the User Payload (GRE Payload) is to be transmitted. 336 - All other fields in the GRE header, including the remaining bits 337 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 339 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 340 present) before delivery over one of the network paths. 342 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 344 MAMS u-plane protocols support multiple combinations and instances of 345 user plane protocols to be used in the MX Adaptation and the 346 Convergence sublayers. 348 For example, one instance of the MX Convergence Layer can be MPTCP 349 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 350 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 351 set up for network paths considered as untrusted by the operator, to 352 protect the TCP subflow between client and MPTCP proxy traversing that 353 network path. 355 Each of the instances of MAMS user plane, i.e. combination of MX 356 Convergence and MX Adaptation layer protocols, can coexist 357 simultaneously and independently handle different traffic types. 359 5. MX Convergence Control Message 361 A UDP connection may be configured between C-MADP and N-MADP to 362 exchange control messages for keep-alive or path quality estimation. 363 The N-MADP end-point IP address and UDP port number of the UDP 364 connection is used to identify MX control PDU. Figure 6 shows the MX 365 control PDU format with the following fields: 367 o Type (1 Byte): the type of the MX control message 368 o CID (1 Byte): the connection ID of the delivery connection for 369 sending out the MX control message 370 o MX Control Message (variable): the payload of the MX control message 371 Figure 7 shows the MX convergence control protocol stack, and MX 372 control PDU goes through the MX adaptation sublayer the same way as MX 373 data PDU. 375 <----MX Control PDU Payload ---------------> 376 +------------------------------------------------------------------+ 377 | IP header | UDP Header| Type | CID | MX Control Message | 378 +------------------------------------------------------------------+ 379 Figure 6: MX Control PDU Format 381 |-----------------------------------------------------| 382 | MX Convergence Control Messages | 383 |-----------------------------------------------------| 384 | UDP/IP | 385 |-----------------------------------------------------| 386 | MX Adaptation | MX Adaptation | MX Adaptation | 387 | Sublayer | Sublayer | Sublayer | 388 | (optional) | (optional) | (optional) | 389 |-----------------------------------------------------| 390 | Access #1 IP | Access #2 IP | Access #3 IP | 391 +-----------------------------------------------------+ 392 Figure 7: MX Convergence Control Protocol Stack 394 5.1 Keep-Alive Message 396 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 397 out Keep-Alive message periodically over one or multiple delivery 398 connections, especially if UDP tunneling is used as the adaptation 399 method for the delivery connection with a NAT function on the path. 401 A Keep-Alive message is 6 Bytes long, and consists of the following 402 fields: 404 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 405 keep-alive message 406 o Timestamp (4 Bytes): the current value of the timestamp clock of 407 the sender in the unit of milliseconds. 409 5.2 Probe Message 411 The "Type" field is set to "1" for Probe messages. 413 N-MADP may send out the Probe message for path quality estimation. In 414 response, C-MADP may send back the ACK message. 416 A Probe message consists of the following fields: 418 o Probing Sequence Number (2 Bytes): the sequence number of the 419 Probe REQ message 420 o Probing Flag (1 Byte): 421 + Bit #0: a ACK flag to indicate if the ACK message is expected 422 (1) or not (0); 423 + Bit #1: a Probe Type flag to indicate if the Probe message is 424 sent during the initialization phase (0) when the network 425 path is not included for transmission of user data or the 426 active phase (1) when the network path is included for 427 transmission of user data; 428 + Bit #2: a bit flag to indicate the presence of the Reverse 429 Connection ID (R-CID) field. 430 + Bit #3~7: reserved 431 o Reverse Connection ID (1 Byte): the connection ID of the delivery 432 connection for sending out the ACK message on the reverse path 433 o Timestamp (4 Bytes): the current value of the timestamp clock of 434 the sender in the unit of milliseconds. 435 o Padding (variable) 437 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 438 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 439 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 440 ACK message is not expected. 442 If the "R-CID" field is not present but the Bit #0 of the "Probing 443 Flag" field is set to "1", the ACK message SHOULD be sent over the same 444 delivery connection as the Probe message. 446 The "Padding" field is used to control the length of Probe message. 448 5.3 Packet Loss Report (PLR) Message 450 The "Type" field is set to "2" for PLR messages. 452 C-MADP may send out the PLR messages to report lost MX SDU for example 453 during handover. In response, C-MADP may retransmit the lost MX SDU 454 accordingly. 456 A PLR message consists of the following fields: 458 o Connection ID (1 Byte): an unsigned integer to identify the anchor 459 connection which the ACK message is for; 460 o Traffic Class ID (1 Byte): an unsigned integer to identify the 461 traffic class of the anchor connection which the ACK message is 462 for; 463 o ACK number (4 Bytes): the next (in-order) sequence number (SN) 464 that the sender of the PLR message is expecting 465 o Number of Loss Bursts (1 Byte) 466 For each loss burst, include the following 467 + Sequence Number of the first lost MX SDU in a burst (4 Bytes) 468 + Number of consecutive lost MX SDUs in the burst (1 Byte) 470 C-MADP N-MADP 471 | | 472 |<------------------ MX SDU (data packets)--------| 473 | | 474 +---------------------------------+ | 475 |Packet Loss detected | | 476 +---------------------------------+ | 477 | | 478 |----- PLR Message ------------------------------>| 479 |<-------------retransmit(lost)MX SDUs -----------| 481 Figure 8: MAMS Retransmission Procedure 483 Figure 8 shows the MAMS retransmission procedure in an example where 484 the lost packet is found and retransmitted. 486 5.4 First Sequence Number (FSN) Message 488 The "Type" field is set to "3" for FSN messages. 490 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 491 its buffer if a lost MX SDU is not found in the buffer after receiving 492 the PLR message from C-MADP. In response, C-MADP SHALL only report 493 packet loss with SN not smaller than FSN. 495 A FSN message consists of the following fields: 497 o Connection ID (1 Byte): an unsigned integer to identify the anchor 498 connection which the FSN message is for; 499 o Traffic Class ID (1 Byte): an unsigned integer to identify the 500 traffic class of the anchor connection which the FSN message is 501 for; 502 o First Sequence Number (4 Bytes): the sequence number (SN) of the 503 oldest MX SDU in the (retransmission) buffer of the sender of the 504 FSN message. 506 Figure 9 shows the MAMS retransmission procedure in an example where 507 the lost packet is not found. 509 C-MADP N-MADP 510 | | 511 |<------------------ MX SDU (data packets)--------| 512 | | 513 +---------------------------------+ | 514 |Packet Loss detected | | 515 +---------------------------------+ | 516 | | 517 |----- PLR Message ------------------------------>| 518 | +---------------------+ 519 | |Lost packet not found| 520 | +---------------------+ 521 |<-------------FSN message -----------------------| 523 Figure 9: MAMS Retransmission Procedure with FSN 525 5.5 Coded MX SDU (CMS) Message 527 The "Type" field is set to "4" for CMS messages. 529 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 530 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 531 [RLNC]. A coded MX SDU is generated by applying a network coding 532 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 533 fast recovery without retransmission if any of the MX SDUs is lost. 535 A Coded MX SDU message consists of the following fields: 537 o Connection ID (1 Byte): an unsigned integer to identify the anchor 538 connection of the coded MX SDU; 539 o Traffic Class ID (1 Byte): an unsigned integer to identify the 540 traffic class of the coded MX; 541 o Sequence Number (4 Bytes): the sequence number of the first 542 (uncoded) MX SDU used to generate the coded MX SDU. 543 o Fragmentation Control (FC) (1 Byte): to provide necessary 544 information for re-assembly, only needed if the coded MX SDU is 545 too long to transport in a single MX control PDU. 546 o N (1 Byte): the number of consecutive MX SDUs used to generate the 547 coded MX SDU 548 o K (1 Byte): the length (in terms of bits) of the coding 549 coefficient field 550 o Coding Coefficient ( N x K / 8 Bytes) 551 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 552 + padding 553 o Coded MX SDU (variable): the coded MX SDU 555 If K = 0, the simple XOR method is used to generate the Coded MX SDU 556 from N consecutive uncoded MX SDUs, and the a(i) fields are not 557 included in the message. 559 If the coded MX SDU is too long, it can be fragmented, and transported 560 by multiple MX control PDUs. The N, K, and a(i) fields are only 561 included in the MX PDU carrying the first fragment of the coded MX SDU. 563 C-MADP N-MADP 564 | | 565 |<------------------ MX SDU #1 -------------------| 566 | lost<-------- MX SDU #2 -------------------| 567 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 568 +----------------------+ | 569 | MX SDU #2 recovered | | 570 +----------------------+ | 571 | | 573 Figure 10: MAMS Packet Recovery Procedure with XOR Coding 575 5.6 Traffic Splitting Update (TSU) Message 577 The "Type" field is set to "5" for TSU messages. 579 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 580 traffic splitting configuration has changed. 582 A TSU message consists of the following fields: 584 o Connection ID (1 Byte): an unsigned integer to identify the anchor 585 connection; 586 o Traffic Class ID (1 Byte): an unsigned integer to identify the 587 traffic class; 588 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 589 message. 590 o Flags (1 Byte) 591 + Bit #0: a Reverse Path bit flag to indicate if the traffic 592 splitting configuration is for the reverse path (1) or not 593 (0); 594 + Bit #1: a Bit-Reversal bit flag to indicate if bit-reversal is 595 used in traffic splitting 596 + Others: reserved. 597 o Traffic Splitting Configuration Parameters ( 5 + (N -1) Bytes): 598 + StartSN (4 Bytes): the sequence number of the first MX SDU 599 using the traffic splitting configuration provided by the TSU 600 message 602 + L (1 Byte): the traffic splitting burst size 603 + K(i): the traffic splitting threshold of the i-th delivery 604 connection, where connections are ordered according to their 605 Connection ID. 607 Let's use f(x) to denote the traffic splitting function, which maps a 608 MX SDU Sequence Number "x" to the i-th delivery connection. 610 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 612 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 614 N is the total number of connections for delivering a data flow, 615 identified by (anchor) Connection ID and Traffic Class ID. 617 When the bit-reversal bit is set to 1, the burst size L MUST be a power 618 of 2, and the traffic splitting function is 620 f(x)=i, if K[i-1]< or = F(mod(x - StartSN, L)) < K[i] 622 Wherein F(.) is the bit reversal function [BITR] of the input variable. 624 5.7 Acknowledgement Message 626 The "Type" field is set to "6" for ACK messages. 628 C-MADP (or N-MADP) SHOULD send out the ACK message in response to the 629 successful reception of a PLR, FSN, or TSU message. 631 C-MADP SHOULD send out the ACK message in response to a Probe message 632 with the ACK flag set to "1". 634 The ACK message consists of the following fields: 636 o Acknowledgment Number (2 Bytes): the sequence number of the 637 received message. 638 o Timestamp (4 Bytes): the current value of the timestamp clock of 639 the sender in the unit of milliseconds. 641 6 Security Considerations 643 User data in MAMS framework rely on the security of the underlying 644 network transport paths. When this cannot be assumed, NCM configures 645 use of appropriate protocols for security, e.g. IPsec [RFC4301] 646 [RFC3948], DTLS [RFC6347]. 648 7 IANA Considerations 650 This draft makes no requests of IANA. 652 8 Contributing Authors 654 The editors gratefully acknowledge the following additional 655 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 656 Pentakota/Nokia. 658 9 References 660 9.1 Normative References 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 666 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 667 December 2005, . 669 9.2 Informative References 671 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 672 Security Version 1.2", RFC 6347, January 2012, 673 . 675 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 676 Kivinen, "Internet Key Exchange Protocol Version 2 677 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 678 2014, . 680 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 681 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 682 3948, DOI 10.17487/RFC3948, January 2005, . 685 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 686 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 687 mechanism-02 689 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 690 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 691 plain-mode-09.txt 693 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 694 Access Management Protocol", 695 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 696 protocol-03 698 [GMA] J. Zhu, "Trailer-based Encapsulation Protocols for Generic 699 Multi-Access Convergence", 700 https://tools.ietf.org/html/draft-zhu-intarea-gma-01 702 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 703 (GRE)", RFC 2784 March 2000, . 706 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 707 RFC 2890 September 2000, . 710 [IANA] https://www.iana.org/assignments/protocol- 711 numbers/protocol-numbers.xhtml 713 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 714 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 715 Tunnel (LWIP) encapsulation; Protocol specification" 717 [RFC791] Internet Protocol, September 1981 719 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 720 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 721 IEEE Access, 2017 723 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 724 arXiv:1212.2291, 2012 726 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 727 Symbol Representation, https://www.ietf.org/id/draft- 728 heide-nwcrg-rlnc-00.txt 730 [BITR] Alan H. Karp, "Bit reversal on uniprocessors", SIAM Review, 731 38 (1): 1-26, 1996. 733 Authors' Addresses 735 Jing Zhu 737 Intel 739 Email: jing.z.zhu@intel.com 740 SungHoon Seo 742 Korea Telecom 744 Email: sh.seo@kt.com 746 Satish Kanugovi 748 Nokia 750 Email: satish.k@nokia.com 752 Shuping Peng 754 Huawei 756 Email: pengshuping@huawei.com