idnits 2.17.1 draft-zhu-intarea-mams-user-protocol-06.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 500 has weird spacing: '...the convergen...' == Line 523 has weird spacing: '...ergence proto...' == Line 524 has weird spacing: '...ocesses the ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the MX adaptation method is UDP tunneling and "MX header optimization" in the "MX_UP_Setup_Configuration_Request" message [MAMS] is true, the FSL field SHOULD not be present, or the entire MX trailer MAY not be present. The MADP receiver compares the IP length field of the MX PDU and the actual length of the MX PDU to determine if the MX PDU contains multiple MX SDUs. If the MX PDU is larger than what the IP length field indicates, the MX PDU contains multiple MX SDUs; otherwise, the MX PDU contains only one MX SDU. To concatenate two or more MX SDUs, the MADP transmitter creates one MX PDU and copies the content of the IP header field from the first MX SDU into the IP header of the MX PDU. The data of the first MX SDU is placed in the first portion of the data of the MX PDU. The whole second MX SDU is then placed in the second portion of the data of the MX PDU (Figure 4). The procedure continues till the MX PDU size reaches the MTU of the delivery connection. If the FSL field is present in the MX Trailer, the IP length field of the MX PDU SHOULD be updated to include all concatenated SDUs and the trailer, and the IP checksum field SHOULD be recalculated. -- The document date (October 19, 2018) is 2016 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 900, 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 (~~), 6 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: April 19,2019 Korea Telecom 5 S. Kanugovi 6 Nokia 7 S. Peng 8 Huawei 9 October 19, 2018 11 User-Plane Protocols for Multiple Access Management Service 12 draft-zhu-intarea-mams-user-protocol-06 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 19, 2009. 37 Copyright Notice 39 Copyright (c) 2018 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 Trailer-based MX Convergence Sublayer....................5 75 4.2.1 Trailer-based MX PDU Format........................5 76 4.2.2 MX Fragmentation...................................8 77 4.2.3 MX Concatenation...................................9 78 4.3 MPTCP-based MX Convergence Sublayer.....................10 79 4.4 GRE as MX Convergence Sublayer..........................11 80 4.4.1 Transmitter Procedures............................11 81 4.4.2 Receiver Procedures...............................12 82 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 83 12 84 5. MX Convergence Control Message................................12 85 5.1 Keep-Alive Message......................................13 86 5.2 Probe REQ/ACK Message...................................14 87 5.3 Packet Loss Report (PLR) Message........................15 88 5.4 First Sequence Number (FSN) Message.....................15 89 5.5 Coded MX SDU (CMS) Message..............................16 90 5.6 Traffic Splitting Update (TSU) Message..................17 91 5.7 Traffic Splitting Acknowledgement (TSA) Message.........18 92 6 Security Considerations.......................................18 93 7 IANA Considerations...........................................19 94 8 Contributing Authors..........................................19 95 9 References....................................................19 96 9.1 Normative References....................................19 97 9.2 Informative References..................................19 99 1. Introduction 101 Multi Access Management Service (MAMS) [MAMS] is a programmable 102 framework to select and configure network paths, as well as adapt to 103 dynamic network conditions, when multiple network connections can 104 serve a client device. It is based on principles of user plane 105 interworking that enables the solution to be deployed as an overlay 106 without impacting the underlying networks. 108 This document presents the u-plane protocols for enabling the MAMS 109 framework. It co-exists and complements the existing protocols by 110 providing a way to negotiate and configure the protocols based on 111 client and network capabilities. Further it allows exchange of 112 network state information and leveraging network intelligence to 113 optimize the performance of such protocols. An important goal for 114 MAMS is to ensure that there is minimal or no dependency on the 115 actual access technology of the participating links. This allows the 116 scheme to be scalable for addition of newer access technologies and 117 for independent evolution of the existing access technologies. 119 2. Terminologies 121 Anchor Connection: refers to the network path from the N-MADP to the 122 Application Server that corresponds to a specific IP anchor that has 123 assigned an IP address to the client. 125 Delivery Connection: refers to the network path from the N-MADP to 126 the C-MADP. 128 "Network Connection Manager" (NCM), "Client Connection Manager" 129 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 130 Access Data Proxy" (C-MADP) in this document are to be interpreted 131 as described in [MAMS]. 133 3. Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 The terminologies "Network Connection Manager" (NCM), "Client 140 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 141 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 142 document are to be interpreted as described in [MAMS]. 144 4 MAMS User-Plane Protocols 146 Figure 1 shows the MAMS u-plane protocol stack as specified in 147 [MAMS_CP]. 148 +-----------------------------------------------------+ 149 | User Payload (e.g. IP PDU) | 150 |-----------------------------------------------------| 151 +--|-----------------------------------------------------|--+ 152 | |-----------------------------------------------------| | 153 | | Multi-Access (MX) Convergence Sublayer | | 154 | |-----------------------------------------------------| | 155 | |-----------------------------------------------------| | 156 | | MX Adaptation | MX Adaptation | MX Adaptation | | 157 | | Sublayer | Sublayer | Sublayer | | 158 | | (optional) | (optional) | (optional) | | 159 | |-----------------------------------------------------| | 160 | | Access #1 IP | Access #2 IP | Access #3 IP | | 161 | +-----------------------------------------------------+ | 162 +-----------------------------------------------------------+ 163 Figure 1: MAMS U-plane Protocol Stack 165 It consists of the following two Sublayers: 167 o Multi-Access (MX) Convergence Sublayer: This layer performs multi- 168 access specific tasks, e.g., access (path) selection, multi-link 169 (path) aggregation, splitting/reordering, lossless switching, 170 fragmentation, concatenation, keep-alive, and probing etc. 171 o Multi-Access (MX) Adaptation Sublayer: This layer performs functions 172 to handle tunneling, network layer security, and NAT. 174 The MX convergence sublayer operates on top of the MX adaptation 175 sublayer in the protocol stack. From the Transmitter perspective, a 176 User Payload (e.g. IP PDU) is processed by the convergence sublayer 177 first, and then by the adaptation sublayer before being transported 178 over a delivery access connection; from the Receiver perspective, an IP 179 packet received over a delivery connection is processed by the MX 180 adaptation sublayer first, and then by the MX convergence sublayer. 182 4.1 MX Adaptation Sublayer 184 The MX adaptation sublayer supports the following mechanisms and 185 protocols while transmitting user plane packets on the network path: 187 o UDP Tunneling: The user plane packets of the anchor connection can be 188 encapsulated in a UDP tunnel of a delivery connection between the N- 189 MADP and C-MADP. 190 o IPsec Tunneling: The user plane packets of the anchor connection are 191 sent through an IPsec tunnel of a delivery connection. 192 o Client Net Address Translation (NAT): The Client IP address of user 193 plane packet of the anchor connection is changed, and sent over a 194 delivery connection. 195 o Pass Through: The user plane packets are passing through without any 196 change over the anchor connection. 198 The MX adaptation sublayer also supports the following mechanisms and 199 protocols to ensure security of user plane packets over the network 200 path. 202 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 203 N-MADP and C-MADP on the network path that is considered untrusted. 204 o DTLS: If UDP tunneling is used on the network path that is considered 205 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 206 be used. 208 The Client NAT method is the most efficient due to no tunneling 209 overhead. It SHOULD be used if a delivery connection is "trusted" and 210 without NAT function on the path. 212 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 213 connection has a NAT function placed on the path. 215 4.2 Trailer-based MX Convergence Sublayer 217 4.2.1 Trailer-based MX PDU Format 219 Trailer-based MX convergence integrates multiple connections into a 220 single e2e IP connection. It operates between Layer 2 (L2) and Layer 3 221 (network/IP). 223 <-- MX Data PDU Payload -------> 224 +------------------------------------------------------+ 225 | IP hdr | IP payload | MX Trailer | 226 +------------------------------------------------------+ 227 Figure 2: Trailer-based Multi-Access (MX) Data PDU Format 229 Figure 2 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 230 Unit) format. A MX PDU MAY carry multiple IP PDUs in the payload if 231 concatenation is supported, and MAY carry a fragment of the IP PDU if 232 fragmentation is supported. 234 The MX trailer may consist of the following fields: 236 o MX flags (e.g. 1 Byte): Bit 0 is the most significant bit, bit 7 is 237 the least significant bit. Bit 6 and 7 are reserved for future. 238 + Next Header Present (bit 0): If the Next Header Present bit is 239 set to 1, then the Next Header field is present and contains 240 valid information. 241 + Connection ID Present (bit 1): If the Connection ID Present bit 242 is set to 1, then the Connection ID field is present and 243 contains valid information. 244 + Traffic Class Present (bit 2): If the Traffic Class Present bit 245 is set to 1, then the Traffic Class field is present and 246 contains valid information. 247 + Sequence Number Present (bit 3): If the Sequence Number Present 248 bit is set to 1, then the Sequence Number field is present and 249 contains valid information. 250 + Packet Length Present (bit 4): If the Packet Length Present bit 251 is set to 1, then the First SDU (Service Data Unit) Length field 252 is present and contains valid information. 253 + Fragmentation Control Present (bit 5): If the Fragmentation 254 Control Present bit is set to 1, then the Fragmentation Control 255 field is present and contains valid information. 256 + Traffic Splitting Flag (bit 6): The bit will be flipped (0 or 1) 257 when the traffic splitting configuration changes 258 + Bit 7: reserved 259 o Next Header (e.g. 1 Byte): the IP protocol type of the (first) IP 260 packet in a MX PDU 261 o Connection ID (e.g.1 Byte): an unsigned integer to identify the 262 anchor connection of the IP packets in a MX PDU 263 o Traffic Class (TC) ID (e.g. 1 Byte): an unsigned integer to identify 264 the traffic class of the IP packets in a MX PDU, for example Data 265 Radio Bearer (DRB) ID [LWIPEP] for a cellular (e.g. LTE) connection 266 o Sequence Number (e.g. 2 Bytes): an auto-incremented integer to 267 indicate order of transmission of the MX SDU (e.g. IP packet), needed 268 for lossless switching or multi-link (path) aggregation or 269 fragmentation. Sequence Number SHALL be generated on a per Connection 270 and per Traffic Class (TC) basis. 271 o First SDU Length (e.g. 2 Bytes): the length of the first IP packet, 272 only included if a MX PDU contains multiple IP packets, i.e. 273 concatenation. 274 o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary 275 information for re-assembly, only needed if a MX PDU carries 276 fragments, i.e. fragmentation. 278 Figure 3 shows the MX trailer format with all the fields present. The 279 MX flags are always encoded in the last octet of the MX Trailer at the 280 end of a MX PDU. Hence, the Receiver SHOULD first decode the MX flags 281 field to determine the length of the MX trailer, and then decode each 282 MX field accordingly. 284 0 1 2 3 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Next Header | Connection ID | TC ID | Sequence 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Number | First SDU Length | FC | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | MX Flags | 300 +-+-+-+-+-+-+-+-+ 302 Figure 3: MX Trailer Format 304 Moreover, the following field of the IP header of the MX PDU SHOULD be 305 changed: 307 o Protocol Type: "114" to indicate that the presence of MX trailer 308 (i.e. the trailer based MAMS u-plane protocol is a "0-hop" protocol, 309 not subject to IP routing) 311 If the MX PDU is transported with the MX adaptation method of IPSec 312 tunnelling, Client NAT, or Pass Through, the following fields of the IP 313 header of the MX PDU SHOULD also be changed: 315 o IP length: add the length of "MX Trailer" to the length of the 316 original IP packet 317 o IP checksum: recalculate after changing "Protocol Type" and "IP 318 Length" 320 If the MX adaptation method is UDP tunnelling and "MX header 321 optimization" in the "MX_UP_Setup_Configuration_Request" message [MAMS] 322 is true, the "IP length" and "IP checksum" header fields of the MX PDU 323 SHOULD remain unchanged. 325 The MX u-plane protocol can support multiple Anchor connections 326 simultaneously, each of which is uniquely identified by Connection ID. 327 It can also support multiple traffic classes per connection, each of 328 which is identified by Traffic Class ID. 330 Moreover, the MX trailer format MAY be negotiated dynamically between 331 NCM and CCM. For example, NCM can send a control message to indicate 332 which of the above fields SHOULD be included for individual delivery 333 connection, on downlink and uplink, respectively. 335 4.2.2 MX Fragmentation 337 The Trailer-based MX Convergence Layer SHOULD support MX fragmentation 338 if a delivery connection has a smaller maximum transmission unit (MTU) 339 than the original IP packet (MX SDU), and IP fragmentation is not 340 supported or enabled on the connection. The MX fragmentation procedure 341 is similar to IP fragmentation [RFC791] in principle, but with the 342 following two differences for less overhead: 344 o The fragment offset field is expressed in number of fragments not 8- 345 bytes blocks 346 o The maximum number of fragments per MX SDU is 2^7 (=128) 348 The Fragmentation Control (FC) field in the MX Trailer contains the 349 following bits: 351 o Bit #7: a More Fragment (MF) flag to indicate if the fragment is the 352 last one (0) or not (1) 353 o Bit #0~#6: Fragment Offset (in units of fragments) to specify the 354 offset of a particular fragment relative to the beginning of the MX 355 SDU 357 A MX PDU carries a whole MX SDU without fragmentation if the FC field 358 is set to all "0"s or the FC field is not present in the trailer. 359 Otherwise, the MX PDU contains a fragment of the MX SDU. 361 The Sequence Number (SN) field in the trailer is used to distinguish 362 the fragments of one MX SDU from those of another. The Fragment Offset 363 (FO) field tells the receiver the position of a fragment in the 364 original MX SDU. The More Fragment (MF) flag indicates the last 365 fragment. 367 To fragment a long MX SDU, the MADP transmitter creates two MX PDUs and 368 copies the content of the IP header fields from the long MX PDU into 369 the IP header of both MX PDUs. The length field in the IP header of MX 370 PDU SHOULD be changed to the length of the MX PDU, and the protocol 371 type SHOULD be changed to "114", indicating the presence of the MX 372 trailer. 374 The data of the long MX SDU is divided into two portions based on the 375 MTU size of the delivery connection. The first portion of the data is 376 placed in the first MX PDU. The MF flag is set to "1", and the FO field 377 is set to "0". The second portion of the data is placed in the second 378 MX PDU. The MF flag is set to "0", and the FO field is set to "1". This 379 procedure can be generalized for an n-way split, rather than the two- 380 way split described the above. 382 To assemble the fragments of a MX SDU, the MADP receiver combines MX 383 PDUs that all have the same MX Sequence Number (in the trailer). The 384 combination is done by placing the data portion of each fragment in the 385 relative order indicated by the Fragment Offset in that fragment's MX 386 trailer. The first fragment will have the Fragment Offset set to "0", 387 and the last fragment will have the More-Fragments flag reset to "0". 389 4.2.3 MX Concatenation 391 The Trailer-based MX Convergence Layer MAY support MX concatenation if 392 a delivery connection has a larger maximum transmission unit (MTU) than 393 the original IP packet (MX SDU). Only the MX SDUs with the same client 394 address, the same anchor connection and the same Traffic Class MAY be 395 concatenated. 397 If the MX adaptation method is IPSec tunnelling, Client NAT, or Pass 398 Through, The First SDU Length (FSL) field SHOULD be included in the MX 399 Trailer to indicate the length of the first MX SDU. 401 If the MX adaptation method is UDP tunneling and "MX header 402 optimization" in the "MX_UP_Setup_Configuration_Request" message [MAMS] 403 is true, the FSL field SHOULD not be present, or the entire MX trailer 404 MAY not be present. The MADP receiver compares the IP length field of 405 the MX PDU and the actual length of the MX PDU to determine if the MX 406 PDU contains multiple MX SDUs. If the MX PDU is larger than what the IP 407 length field indicates, the MX PDU contains multiple MX SDUs; 408 otherwise, the MX PDU contains only one MX SDU. To concatenate two or 409 more MX SDUs, the MADP transmitter creates one MX PDU and copies the 410 content of the IP header field from the first MX SDU into the IP header 411 of the MX PDU. The data of the first MX SDU is placed in the first 412 portion of the data of the MX PDU. The whole second MX SDU is then 413 placed in the second portion of the data of the MX PDU (Figure 4). The 414 procedure continues till the MX PDU size reaches the MTU of the 415 delivery connection. If the FSL field is present in the MX Trailer, the 416 IP length field of the MX PDU SHOULD be updated to include all 417 concatenated SDUs and the trailer, and the IP checksum field SHOULD be 418 recalculated. 420 To disaggregate a MX PDU, the MADP receiver first obtains the length of 421 the first MX SDU from the FSL field in the trailer, and decodes the 422 first MX SDU. If the FSL field or the MX Trailer is not present, the 423 MADP receiver obtains the length of the first MX SDU directly from the 424 IP length field of the MX PDU. The MADP receiver then obtains the 425 length of the second MX SDU based on the length field in the second MX 426 SDU IP header, and decodes the second MX SDU. The procedure continues 427 till no byte is left in the MX PDU. 429 If a MX PDU contains multiple SDUs, the SN field in the MX trailer is 430 for the last MX SDU, and the SN of other SDU carried by the same PDU 431 can be obtained according to its order in the PDU. For example, if the 432 SN field is 6 and a MX PDU contains 3 SDUs (IP packets), then the SN is 433 4, 5, and 6 for the first, second, and the last IP packet in the PDU, 434 respectively. 436 <---- MX Data PDU Payload ------------> 437 +------------------------------------------------------------+ 438 | IP hdr | IP payload | IP hdr | IP payload | MX Trailer | 439 +------------------------------------------------------------+ 440 Figure 4: MX PDU Format with Concatenation 442 4.3 MPTCP-based MX Convergence Sublayer 444 Figure 5 shows the MAMS u-plane protocol stack based on MPTCP. Here, 445 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 446 access networks are combined into a single MPTCP connection. Hence, no 447 new u-plane protocol or PDU format is needed in this case. 449 |-----------------------------------------------------| 450 | MPTCP | 451 |-----------------------------------------------------| 452 | TCP | TCP | TCP | 453 |-----------------------------------------------------| 454 | MX Adaptation | MX Adaptation | MX Adaptation | 455 | Sublayer | Sublayer | Sublayer | 456 | (optional) | (optional) | (optional) | 457 |-----------------------------------------------------| 458 | Access #1 IP | Access #2 IP | Access #3 IP | 459 +-----------------------------------------------------+ 460 Figure 5: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 461 Layer 463 If NCM determines that N-MADP is to be instantiated with MPTCP as the 464 MX Convergence Protocol, it exchanges the support of MPTCP capability 465 in the discovery and capability exchange procedures [MAMS_CP]. MPTCP 466 proxy protocols [MPProxy][MPPlain] SHOULD be used to manage traffic 467 steering and aggregation over multiple delivery connections. 469 4.4 GRE as MX Convergence Sublayer 471 Figure 6 shows the MAMS u-plane protocol stack based on GRE (Generic 472 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 473 Convergence sub-layer" protocol. Multiple access networks are combined 474 into a single GRE connection. Hence, no new u-plane protocol or PDU 475 format is needed in this case. 477 +-----------------------------------------------------+ 478 | User Payload (e.g. IP PDU) | 479 |-----------------------------------------------------| 480 | GRE as MX Convergence Sublayer | 481 |-----------------------------------------------------| 482 | GRE Delivery Protocol (e.g. IP) | 483 |-----------------------------------------------------| 484 | MX Adaptation | MX Adaptation | MX Adaptation | 485 | Sublayer | Sublayer | Sublayer | 486 | (optional) | (optional) | (optional) | 487 |-----------------------------------------------------| 488 | Access #1 IP | Access #2 IP | Access #3 IP | 489 +-----------------------------------------------------+ 490 Figure 6: MAMS U-plane Protocol Stack with GRE as MX Convergence 491 Layer 493 If NCM determines that N-MADP is to be instantiated with GRE as the MX 494 Convergence Protocol, it exchanges the support of GRE capability in the 495 discovery and capability exchange procedures [MAMS_CP]. 497 4.4.1 Transmitter Procedures 499 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 500 the convergence protocol that transmits the GRE packets. The 501 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 502 with a GRE header and Delivery Protocol (e.g. IP) header to generate 503 the GRE Convergence PDU. 505 When IP is used as the GRE delivery protocol, the IP header information 506 (e.g. IP address) can be created using the IP header of the user 507 payload or a virtual IP address. The "Protocol Type" field of the 508 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 510 The GRE header fields are set as specified below, 512 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 513 to the value of Connection ID for the Anchor Connection associated 514 with the user payload or sets to 0xFFFF if no Anchor Connection ID 515 needs to be specified. 517 - All other fields in the GRE header including the remaining bits in 518 the key fields are set as per [GRE_2784][GRE_2890]. 520 4.4.2 Receiver Procedures 522 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 523 convergence protocol that receives the GRE packets. The receiver 524 processes the received packets per the GRE procedures [GRE_2784, 525 GRE_2890] and retrieves the GRE header. 527 - If the Receiver is an N-MADP instance, 528 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 529 interpreted as the Connection ID of Anchor Connection for the 530 user payload. This is used to identify the network path over 531 which the User Payload (GRE Payload) is to be transmitted. 532 - All other fields in the GRE header, including the remaining bits 533 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 535 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 536 present) before delivery over one of the network paths. 538 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 540 MAMS u-plane protocols support multiple combinations and instances of 541 user plane protocols to be used in the MX Adaptation and the 542 Convergence sublayers. 544 For example, one instance of the MX Convergence Layer can be MPTCP 545 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 546 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 547 set up for network paths considered as untrusted by the operator, to 548 protect the TCP subflow between client and MPTCP proxy traversing that 549 network path. 551 Each of the instances of MAMS user plane, i.e. combination of MX 552 Convergence and MX Adaptation layer protocols, can coexist 553 simultaneously and independently handle different traffic types. 555 5. MX Convergence Control Message 557 A UDP connection may be configured between C-MADP and N-MADP to 558 exchange control messages for keep-alive or path quality estimation. 559 The N-MADP end-point IP address and UDP port number of the UDP 560 connection is used to identify MX control PDU. Figure 7 shows the MX 561 control PDU format with the following fields: 563 o Type (1 Byte): the type of the MX control message 564 + 0: Keep-Alive 565 + 1: Probe REQ/ACK 566 + 2: Packet Loss Report (PLR) 567 + 3: First Sequence Number (FSN) 568 + 4: Coded MX SDU (CMS) 569 + 5: Traffic Splitting Update (TSU) 570 + 6: Traffic Splitting Acknowledgement (TSA) 571 + Others: reserved 572 o CID (1 Byte): the connection ID of the delivery connection for 573 sending out the MX control message 574 o MX Control Message (variable): the payload of the MX control message 576 Figure 8 shows the MX convergence control protocol stack, and MX 577 control PDU goes through the MX adaptation sublayer the same way as MX 578 data PDU. 580 <----MX Control PDU Payload ---------------> 581 +------------------------------------------------------------------+ 582 | IP header | UDP Header| Type | CID | MX Control Message | 583 +------------------------------------------------------------------+ 584 Figure 7: MX Control PDU Format 586 |-----------------------------------------------------| 587 | MX Convergence Control Messages | 588 |-----------------------------------------------------| 589 | UDP/IP | 590 |-----------------------------------------------------| 591 | MX Adaptation | MX Adaptation | MX Adaptation | 592 | Sublayer | Sublayer | Sublayer | 593 | (optional) | (optional) | (optional) | 594 |-----------------------------------------------------| 595 | Access #1 IP | Access #2 IP | Access #3 IP | 596 +-----------------------------------------------------+ 597 Figure 8: MX Convergence Control Protocol Stack 599 5.1 Keep-Alive Message 601 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 602 out Keep-Alive message periodically over one or multiple delivery 603 connections, especially if UDP tunneling is used as the adaptation 604 method for the delivery connection with a NAT function on the path. 606 A Keep-Alive message is 2 Bytes long, and consists of the following 607 fields: 609 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 610 keep-alive message 612 5.2 Probe REQ/ACK Message 614 The "Type" field is set to "1" for Probe REQ/ACK messages. 616 N-MADP may send out the Probe REQ message for path quality estimation. 617 In response, C-MADP may send back the Probe ACK message. 619 A Probe REQ message consists of the following fields: 621 o Probing Sequence Number (2 Bytes): the sequence number of the 622 Probe REQ message 623 o Probing Flag (1 Byte): 624 + Bit #0: a Probe ACK flag to indicate if the Probe ACK message 625 is expected (1) or not (0); 626 + Bit #1: a Probe Type flag to indicate if the Probe REQ/ACK 627 message is sent during the initialization phase (0) when the 628 network path is not included for transmission of user data or 629 the active phase (1) when the network path is included for 630 transmission of user data; 631 + Bit #2: a bit flag to indicate the presence of the Reverse 632 Connection ID (R-CID) field. 633 + Bit #3~7: reserved 634 o Reverse Connection ID (1 Byte): the connection ID of the delivery 635 connection for sending out the Probe ACK message on the reverse 636 path 637 o Padding (variable) 639 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 640 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 641 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 642 Probe ACK message is not expected. 644 If the "R-CID" field is not present but the Bit #0 of the "Probing 645 Flag" field is set to "1", the Probe ACK message SHOULD be sent over 646 the same delivery connection as the Probe REQ message. 648 The "Padding" field is used to control the length of Probe REQ message. 650 C-MADP SHOULD send out the Probe ACK message in response to a Probe REQ 651 message with the Probe ACK flag set to "1". 653 A Probe ACK message is 2 Bytes long, and consists of the following 654 fields: 656 o Probing Acknowledgement Number (2 Bytes): the sequence number of 657 the corresponding Probe REQ message 659 5.3 Packet Loss Report (PLR) Message 661 The "Type" field is set to "2" for PLR messages. 663 C-MADP may send out the PLR messages to report lost MX SDU for example 664 during handover. In response, C-MADP may retransmit the lost MX SDU 665 accordingly. 667 A PLR message consists of the following fields: 669 o Connection ID (1 Byte): an unsigned integer to identify the anchor 670 connection which the ACK message is for; 671 o Traffic Class ID (1 Byte): an unsigned integer to identify the 672 traffic class of the anchor connection which the ACK message is 673 for; 674 o ACK number (2 Bytes): the next (in-order) sequence number (SN) 675 that the sender of the PLR message is expecting 676 o Number of Loss Bursts (1 Byte) 677 For each loss burst, include the following 678 + Sequence Number of the first lost MX SDU in a burst (2 Bytes) 679 + Number of consecutive lost MX SDUs in the burst (1 Byte) 681 C-MADP N-MADP 682 | | 683 |<------------------ MX SDU (data packets)--------| 684 | | 685 +---------------------------------+ | 686 |Packet Loss detected | | 687 +---------------------------------+ | 688 | | 689 |----- PLR Message ------------------------------>| 690 |<-------------retransmit(lost)MX SDUs -----------| 692 Figure 9: MAMS Retransmission Procedure 694 Figure 9 shows the MAMS retransmission procedure in an example where 695 the lost packet is found and retransmitted. 697 5.4 First Sequence Number (FSN) Message 699 The "Type" field is set to "3" for FSN messages. 701 N-MADP may send out the FSN messages to indicate the oldest MX SDU in 702 its buffer if a lost MX SDU is not found in the buffer after receiving 703 the PLR message from C-MADP. In response, C-MADP SHALL only report 704 packet loss with SN not smaller than FSN. 706 A FSN message consists of the following fields: 708 o Connection ID (1 Byte): an unsigned integer to identify the anchor 709 connection which the FSN message is for; 710 o Traffic Class ID (1 Byte): an unsigned integer to identify the 711 traffic class of the anchor connection which the FSN message is 712 for; 713 o First Sequence Number (2 Bytes): the sequence number (SN) of the 714 oldest MX SDU in the (retransmission) buffer of the sender of the 715 FSN message. 717 Figure 10 shows the MAMS retransmission procedure in an example where 718 the lost packet is not found. 720 C-MADP N-MADP 721 | | 722 |<------------------ MX SDU (data packets)--------| 723 | | 724 +---------------------------------+ | 725 |Packet Loss detected | | 726 +---------------------------------+ | 727 | | 728 |----- PLR Message ------------------------------>| 729 | +---------------------+ 730 | |Lost packet not found| 731 | +---------------------+ 732 |<-------------FSN message -----------------------| 734 Figure 10: MAMS Retransmission Procedure with FSN 736 5.5 Coded MX SDU (CMS) Message 738 The "Type" field is set to "4" for CMS messages. 740 N-MADP (or C-MADP) may send out the CMS message to support downlink (or 741 uplink) packet loss recovery through coding, e.g. [CRLNC], [CTCP], 742 [RLNC]. A coded MX SDU is generated by applying a network coding 743 algorithm to multiple consecutive (uncoded) MX SDUs, and it is used for 744 fast recovery without retransmission if any of the MX SDUs is lost. 746 A Coded MX SDU message consists of the following fields: 748 o Connection ID (1 Byte): an unsigned integer to identify the anchor 749 connection of the coded MX SDU; 750 o Traffic Class ID (1 Byte): an unsigned integer to identify the 751 traffic class of the coded MX; 752 o Sequence Number (2 Bytes): the sequence number of the first 753 (uncoded) MX SDU used to generate the coded MX SDU. 754 o Fragmentation Control (FC) (1 Byte): to provide necessary 755 information for re-assembly, only needed if the coded MX SDU is 756 too long to transport in a single MX control PDU. 757 o N (1 Byte): the number of consecutive MX SDUs used to generate the 758 coded MX SDU 759 o K (1 Byte): the length (in terms of bits) of the coding 760 coefficient field 761 o Coding Coefficient ( N x K / 8 Bytes) 762 + a(i): the coding coefficient of the i-th (uncoded) MX SDU 763 + padding 764 o Coded MX SDU (variable): the coded MX SDU 766 If N = 2 and K = 0, the simple XOR method is used to generate the Coded 767 MX SDU from two consecutive uncoded MX SDUs, and the a(i) fields are 768 not included in the message. 770 If the coded MX SDU is too long, it can be fragmented, and transported 771 by multiple MX control PDUs. The N, K, and a(i) fields are only 772 included in the MX PDU carrying the first fragment of the coded MX SDU. 774 C-MADP N-MADP 775 | | 776 |<------------------ MX SDU #1 -------------------| 777 | lost<-------- MX SDU #2 -------------------| 778 |<---- CMS Message (MX SDU #1 XOR MX SDU #2)------| 779 +----------------------+ | 780 | MX SDU #2 recovered | | 781 +----------------------+ | 782 | | 784 Figure 11: MAMS Packet Recovery Procedure with XOR Coding 786 5.6 Traffic Splitting Update (TSU) Message 788 The "Type" field is set to "5" for TSU messages. 790 N-MADP (or C-MADP) may send out a TSU message if downlink (or uplink) 791 traffic splitting configuration has changed. 793 A TSU message consists of the following fields: 795 o Connection ID (1 Byte): an unsigned integer to identify the anchor 796 connection; 797 o Traffic Class ID (1 Byte): an unsigned integer to identify the 798 traffic class; 799 o Sequence Number (2 Bytes): an unsigned integer to identify the TSU 800 message. 801 o Traffic Splitting Configuration Parameters ( 3 + (N -1) Bytes): 802 + StartSN (2 Bytes): the sequence number of the first MX SDU 803 using the traffic splitting configuration provided by the TSU 804 message 805 + L (1 Byte): the traffic splitting burst size 806 + K(i): the traffic splitting threshold of the i-th delivery 807 connection, where connections are ordered according to their 808 Connection ID. 810 Let's use f(x) to denote the traffic splitting function, which maps a 811 MX SDU Sequence Number "x" to the i-th delivery connection. 813 f(x)=i, if K[i-1]< or = mod(x - StartSN, L) < K[i] 815 Wherein, 1 < or = i < N, K[0]=0, and K[N]=L. 817 N is the total number of connections for delivering a data flow, 818 identified by (anchor) Connection ID and Traffic Class ID. 820 5.7 Traffic Splitting Acknowledgement (TSA) Message 822 The "Type" field is set to "6" for TSA messages. 824 C-MADP (or N-MADP) SHOULD send out the TSA message in response to the 825 successful reception of a TSU message. 827 A TSU message consists of the following fields: 829 o Connection ID (1 Byte): an unsigned integer to identify the anchor 830 connection; 831 o Traffic Class ID (1 Byte): an unsigned integer to identify the 832 traffic class; 833 o Acknowledgment Number (2 Bytes): the sequence number of the 834 received TSU message. 836 6 Security Considerations 838 User data in MAMS framework rely on the security of the underlying 839 network transport paths. When this cannot be assumed, NCM configures 840 use of appropriate protocols for security, e.g. IPsec [RFC4301] 841 [RFC3948], DTLS [RFC6347]. 843 7 IANA Considerations 845 TBD 847 8 Contributing Authors 849 The editors gratefully acknowledge the following additional 850 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 851 Pentakota/Nokia. 853 9 References 855 9.1 Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 861 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 862 December 2005, . 864 9.2 Informative References 866 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 867 Security Version 1.2", RFC 6347, January 2012, 868 . 870 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 871 Kivinen, "Internet Key Exchange Protocol Version 2 872 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 873 2014, . 875 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 876 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 877 3948, DOI 10.17487/RFC3948, January 2005, . 880 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 881 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 882 mechanism-02 884 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 885 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 886 plain-mode-09.txt 888 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 889 Access Management Protocol", 890 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 891 protocol-03 893 [MAMS_CP] S. Kanugovi, et al., "Control Plane Protocols and 894 Procedures for Multiple Access Management Services" 896 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 897 (GRE)", RFC 2784 March 2000, . 900 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 901 RFC 2890 September 2000, . 904 [IANA] https://www.iana.org/assignments/protocol- 905 numbers/protocol-numbers.xhtml 907 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 908 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 909 Tunnel (LWIP) encapsulation; Protocol specification" 911 [RFC791] Internet Protocol, September 1981 913 [CRLNC] S Wunderlich, F Gabriel, S Pandi, et al. Caterpillar RLNC 914 (CRLNC): A Practical Finite Sliding Window RLNC Approach, 915 IEEE Access, 2017 917 [CTCP] M. Kim, et al. Network Coded TCP (CTCP), eprint 918 arXiv:1212.2291, 2012 920 [RLNC] J. Heide, et al. Random Linear Network Coding (RLNC)-Based 921 Symbol Representation, https://www.ietf.org/id/draft- 922 heide-nwcrg-rlnc-00.txt 924 Authors' Addresses 926 Jing Zhu 928 Intel 930 Email: jing.z.zhu@intel.com 932 SungHoon Seo 934 Korea Telecom 935 Email: sh.seo@kt.com 937 Satish Kanugovi 939 Nokia 941 Email: satish.k@nokia.com 943 Shuping Peng 945 Huawei 947 Email: pengshuping@huawei.com