idnits 2.17.1 draft-zhu-intarea-mams-user-protocol-04.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 493 has weird spacing: '...the convergen...' == Line 516 has weird spacing: '...ergence proto...' == Line 517 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 (January 22, 2018) is 2279 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 711, 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: July 22, 2017 Korea Telecom 5 S. Kanugovi 6 Nokia 7 S. Peng 8 Huawei 9 January 22, 2018 11 User-Plane Protocols for Multiple Access Management Service 12 draft-zhu-intarea-mams-user-protocol-04 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 July 22, 2018. 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...................................13 87 6 Security Considerations.......................................14 88 7 IANA Considerations...........................................15 89 8 Contributing Authors..........................................15 90 9 References....................................................15 91 9.1 Normative References....................................15 92 9.2 Informative References..................................15 94 1. Introduction 96 Multi Access Management Service (MAMS) [MAMS] is a programmable 97 framework to select and configure network paths, as well as adapt to 98 dynamic network conditions, when multiple network connections can 99 serve a client device. It is based on principles of user plane 100 interworking that enables the solution to be deployed as an overlay 101 without impacting the underlying networks. 103 This document presents the u-plane protocols for enabling the MAMS 104 framework. It co-exists and complements the existing protocols by 105 providing a way to negotiate and configure the protocols based on 106 client and network capabilities. Further it allows exchange of 107 network state information and leveraging network intelligence to 108 optimize the performance of such protocols. An important goal for 109 MAMS is to ensure that there is minimal or no dependency on the 110 actual access technology of the participating links. This allows the 111 scheme to be scalable for addition of newer access technologies and 112 for independent evolution of the existing access technologies. 114 2. Terminologies 116 Anchor Connection: refers to the network path from the N-MADP to the 117 Application Server that corresponds to a specific IP anchor that has 118 assigned an IP address to the client. 120 Delivery Connection: refers to the network path from the N-MADP to 121 the C-MADP. 123 "Network Connection Manager" (NCM), "Client Connection Manager" 124 (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi 125 Access Data Proxy" (C-MADP) in this document are to be interpreted 126 as described in [MAMS]. 128 3. Conventions used in this document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 The terminologies "Network Connection Manager" (NCM), "Client 135 Connection Manager" (CCM), "Network Multi Access Data Proxy" (N- 136 MADP), and "Client Multi Access Data Proxy" (C-MADP) in this 137 document are to be interpreted as described in [MAMS]. 139 4 MAMS User-Plane Protocols 141 Figure 1 shows the MAMS u-plane protocol stack as specified in 142 [MAMS_CP]. 143 +-----------------------------------------------------+ 144 | User Payload (e.g. IP PDU) | 145 |-----------------------------------------------------| 146 +--|-----------------------------------------------------|--+ 147 | |-----------------------------------------------------| | 148 | | Multi-Access (MX) Convergence Sublayer | | 149 | |-----------------------------------------------------| | 150 | |-----------------------------------------------------| | 151 | | MX Adaptation | MX Adaptation | MX Adaptation | | 152 | | Sublayer | Sublayer | Sublayer | | 153 | | (optional) | (optional) | (optional) | | 154 | |-----------------------------------------------------| | 155 | | Access #1 IP | Access #2 IP | Access #3 IP | | 156 | +-----------------------------------------------------+ | 157 +-----------------------------------------------------------+ 158 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. 185 o IPsec Tunneling: The user plane packets of the anchor connection are 186 sent through an IPsec tunnel of a delivery connection. 187 o Client Net Address Translation (NAT): The Client IP address of user 188 plane packet of the anchor connection is changed, and sent over a 189 delivery connection. 190 o Pass Through: The user plane packets are passing through without any 191 change over the anchor connection. 193 The MX adaptation sublayer also supports the following mechanisms and 194 protocols to ensure security of user plane packets over the network 195 path. 197 o IPsec Tunneling: An IPsec [RFC7296] tunnel is established between the 198 N-MADP and C-MADP on the network path that is considered untrusted. 199 o DTLS: If UDP tunneling is used on the network path that is considered 200 "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can 201 be used. 203 The Client NAT method is the most efficient due to no tunneling 204 overhead. It SHOULD be used if a delivery connection is "trusted" and 205 without NAT function on the path. 207 The UDP or IPsec Tunnelling method SHOULD be used if a delivery 208 connection has a NAT function placed on the path. 210 4.2 Trailer-based MX Convergence Sublayer 212 4.2.1 Trailer-based MX PDU Format 214 Trailer-based MX convergence integrates multiple connections into a 215 single e2e IP connection. It operates between Layer 2 (L2) and Layer 3 216 (network/IP). 218 <-- MX Data PDU Payload -------> 219 +------------------------------------------------------+ 220 | IP hdr | IP payload | MX Trailer | 221 +------------------------------------------------------+ 222 Figure 2: Trailer-based Multi-Access (MX) Data PDU Format 224 Figure 2 shows the trailer-based Multi-Access (MX) PDU (Protocol Data 225 Unit) format. A MX PDU MAY carry multiple IP PDUs in the payload if 226 concatenation is supported, and MAY carry a fragment of the IP PDU if 227 fragmentation is supported. 229 The MX trailer may consist of the following fields: 231 o MX flags (e.g. 1 Byte): Bit 0 is the most significant bit, bit 7 is 232 the least significant bit. Bit 6 and 7 are reserved for future. 233 + Next Header Present (bit 0): If the Next Header Present bit is 234 set to 1, then the Next Header field is present and contains 235 valid information. 236 + Connection ID Present (bit 1): If the Connection ID Present bit 237 is set to 1, then the Connection ID field is present and 238 contains valid information. 239 + Traffic Class Present (bit 2): If the Traffic Class Present bit 240 is set to 1, then the Traffic Class field is present and 241 contains valid information. 242 + Sequence Number Present (bit 3): If the Sequence Number Present 243 bit is set to 1, then the Sequence Number field is present and 244 contains valid information. 245 + Packet Length Present (bit 4): If the Packet Length Present bit 246 is set to 1, then the First SDU (Service Data Unit) Length field 247 is present and contains valid information. 248 + Fragmentation Control Present (bit 5): If the Fragmentation 249 Control Present bit is set to 1, then the Fragmentation Control 250 field is present and contains valid information. 251 + Bit 6~7: reserved 252 o Next Header (e.g. 1 Byte): the IP protocol type of the (first) IP 253 packet in a MX PDU 254 o Connection ID (e.g.1 Byte): an unsigned integer to identify the 255 anchor connection of the IP packets in a MX PDU 256 o Traffic Class (TC) ID (e.g. 1 Byte): an unsigned integer to identify 257 the traffic class of the IP packets in a MX PDU, for example Data 258 Radio Bearer (DRB) ID [LWIPEP] for a cellular (e.g. LTE) connection 259 o Sequence Number (e.g. 2 Bytes): an auto-incremented integer to 260 indicate order of transmission of the IP packet, needed for lossless 261 switching or multi-link (path) aggregation or fragmentation. Sequence 262 Number SHALL be generated on a per Connection and per Traffic Class 263 (TC) basis. 264 o First SDU Length (e.g. 2 Bytes): the length of the first IP packet, 265 only included if a MX PDU contains multiple IP packets, i.e. 266 concatenation. 267 o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary 268 information for re-assembly, only needed if a MX PDU carries 269 fragments, i.e. fragmentation. 271 Figure 3 shows the MX trailer format with all the fields present. The 272 MX flags are always encoded in the last octet of the MX Trailer at the 273 end of a MX PDU. Hence, the Receiver SHOULD first decode the MX flags 274 field to determine the length of the MX trailer, and then decode each 275 MX field accordingly. 277 0 1 2 3 279 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Next Header | Connection ID | TC ID | Sequence 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Number | First SDU Length | FC | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | MX Flags | 293 +-+-+-+-+-+-+-+-+ 295 Figure 3: MX Trailer Format 297 Moreover, the following field of the IP header of the MX PDU SHOULD be 298 changed: 300 o Protocol Type: "114" to indicate that the presence of MX trailer 301 (i.e. the trailer based MAMS u-plane protocol is a "0-hop" protocol, 302 not subject to IP routing) 304 If the MX PDU is transported with the MX adaptation method of IPSec 305 tunnelling, Client NAT, or Pass Through, the following fields of the IP 306 header of the MX PDU SHOULD also be changed: 308 o IP length: add the length of "MX Trailer" to the length of the 309 original IP packet 310 o IP checksum: recalculate after changing "Protocol Type" and "IP 311 Length" 313 If the MX adaptation method is UDP tunnelling and "MX header 314 optimization" in the "MX_UP_Setup_Configuration_Request" message [MAMS] 315 is true, the "IP length" and "IP checksum" header fields of the MX PDU 316 SHOULD remain unchanged. 318 The MX u-plane protocol can support multiple Anchor connections 319 simultaneously, each of which is uniquely identified by Connection ID. 320 It can also support multiple traffic classes per connection, each of 321 which is identified by Traffic Class ID. 323 Moreover, the MX trailer format MAY be negotiated dynamically between 324 NCM and CCM. For example, NCM can send a control message to indicate 325 which of the above fields SHOULD be included for individual delivery 326 connection, on downlink and uplink, respectively. 328 4.2.2 MX Fragmentation 330 The Trailer-based MX Convergence Layer SHOULD support MX fragmentation 331 if a delivery connection has a smaller maximum transmission unit (MTU) 332 than the original IP packet (MX SDU), and IP fragmentation is not 333 supported or enabled on the connection. The MX fragmentation procedure 334 is similar to IP fragmentation [RFC791] in principle, but with the 335 following two differences for less overhead: 337 o The fragment offset field is expressed in number of fragments not 8- 338 bytes blocks 339 o The maximum number of fragments per MX SDU is 2^7 (=128) 341 The Fragmentation Control (FC) field in the MX Trailer contains the 342 following bits: 344 o Bit #7: a More Fragment (MF) flag to indicate if the fragment is the 345 last one (0) or not (1) 346 o Bit #0~#6: Fragment Offset (in units of fragments) to specify the 347 offset of a particular fragment relative to the beginning of the MX 348 SDU 350 A MX PDU carries a whole MX SDU without fragmentation if the FC field 351 is set to all "0"s or the FC field is not present in the trailer. 352 Otherwise, the MX PDU contains a fragment of the MX SDU. 354 The Sequence Number (SN) field in the trailer is used to distinguish 355 the fragments of one MX SDU from those of another. The Fragment Offset 356 (FO) field tells the receiver the position of a fragment in the 357 original MX SDU. The More Fragment (MF) flag indicates the last 358 fragment. 360 To fragment a long MX SDU, the MADP transmitter creates two MX PDUs and 361 copies the content of the IP header fields from the long MX PDU into 362 the IP header of both MX PDUs. The length field in the IP header of MX 363 PDU SHOULD be changed to the length of the MX PDU, and the protocol 364 type SHOULD be changed to "114", indicating the presence of the MX 365 trailer. 367 The data of the long MX SDU is divided into two portions based on the 368 MTU size of the delivery connection. The first portion of the data is 369 placed in the first MX PDU. The MF flag is set to "1", and the FO field 370 is set to "0". The second portion of the data is placed in the second 371 MX PDU. The MF flag is set to "0", and the FO field is set to "1". This 372 procedure can be generalized for an n-way split, rather than the two- 373 way split described the above. 375 To assemble the fragments of a MX SDU, the MADP receiver combines MX 376 PDUs that all have the same MX Sequence Number (in the trailer). The 377 combination is done by placing the data portion of each fragment in the 378 relative order indicated by the Fragment Offset in that fragment's MX 379 trailer. The first fragment will have the Fragment Offset set to "0", 380 and the last fragment will have the More-Fragments flag reset to "0". 382 4.2.3 MX Concatenation 384 The Trailer-based MX Convergence Layer MAY support MX concatenation if 385 a delivery connection has a larger maximum transmission unit (MTU) than 386 the original IP packet (MX SDU). Only the MX SDUs with the same client 387 address, the same anchor connection and the same Traffic Class MAY be 388 concatenated. 390 If the MX adaptation method is IPSec tunnelling, Client NAT, or Pass 391 Through, The First SDU Length (FSL) field SHOULD be included in the MX 392 Trailer to indicate the length of the first MX SDU. 394 If the MX adaptation method is UDP tunneling and "MX header 395 optimization" in the "MX_UP_Setup_Configuration_Request" message [MAMS] 396 is true, the FSL field SHOULD not be present, or the entire MX trailer 397 MAY not be present. The MADP receiver compares the IP length field of 398 the MX PDU and the actual length of the MX PDU to determine if the MX 399 PDU contains multiple MX SDUs. If the MX PDU is larger than what the IP 400 length field indicates, the MX PDU contains multiple MX SDUs; 401 otherwise, the MX PDU contains only one MX SDU. To concatenate two or 402 more MX SDUs, the MADP transmitter creates one MX PDU and copies the 403 content of the IP header field from the first MX SDU into the IP header 404 of the MX PDU. The data of the first MX SDU is placed in the first 405 portion of the data of the MX PDU. The whole second MX SDU is then 406 placed in the second portion of the data of the MX PDU (Figure 4). The 407 procedure continues till the MX PDU size reaches the MTU of the 408 delivery connection. If the FSL field is present in the MX Trailer, the 409 IP length field of the MX PDU SHOULD be updated to include all 410 concatenated SDUs and the trailer, and the IP checksum field SHOULD be 411 recalculated. 413 To disaggregate a MX PDU, the MADP receiver first obtains the length of 414 the first MX SDU from the FSL field in the trailer, and decodes the 415 first MX SDU. If the FSL field or the MX Trailer is not present, the 416 MADP receiver obtains the length of the first MX SDU directly from the 417 IP length field of the MX PDU. The MADP receiver then obtains the 418 length of the second MX SDU based on the length field in the second MX 419 SDU IP header, and decodes the second MX SDU. The procedure continues 420 till no byte is left in the MX PDU. 422 If a MX PDU contains multiple SDUs, the SN field in the MX trailer is 423 for the last MX SDU, and the SN of other SDU carried by the same PDU 424 can be obtained according to its order in the PDU. For example, if the 425 SN field is 6 and a MX PDU contains 3 SDUs (IP packets), then the SN is 426 4, 5, and 6 for the first, second, and the last IP packet in the PDU, 427 respectively. 429 <---- MX Data PDU Payload ------------> 430 +------------------------------------------------------------+ 431 | IP hdr | IP payload | IP hdr | IP payload | MX Trailer | 432 +------------------------------------------------------------+ 433 Figure 4: MX PDU Format with Concatenation 435 4.3 MPTCP-based MX Convergence Sublayer 437 Figure 5 shows the MAMS u-plane protocol stack based on MPTCP. Here, 438 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 439 access networks are combined into a single MPTCP connection. Hence, no 440 new u-plane protocol or PDU format is needed in this case. 442 |-----------------------------------------------------| 443 | MPTCP | 444 |-----------------------------------------------------| 445 | TCP | TCP | TCP | 446 |-----------------------------------------------------| 447 | MX Adaptation | MX Adaptation | MX Adaptation | 448 | Sublayer | Sublayer | Sublayer | 449 | (optional) | (optional) | (optional) | 450 |-----------------------------------------------------| 451 | Access #1 IP | Access #2 IP | Access #3 IP | 452 +-----------------------------------------------------+ 453 Figure 5: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 454 Layer 456 If NCM determines that N-MADP is to be instantiated with MPTCP as the 457 MX Convergence Protocol, it exchanges the support of MPTCP capability 458 in the discovery and capability exchange procedures [MAMS_CP]. MPTCP 459 proxy protocols [MPProxy][MPPlain] SHOULD be used to manage traffic 460 steering and aggregation over multiple delivery connections. 462 4.4 GRE as MX Convergence Sublayer 464 Figure 6 shows the MAMS u-plane protocol stack based on GRE (Generic 465 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 466 Convergence sub-layer" protocol. Multiple access networks are combined 467 into a single GRE connection. Hence, no new u-plane protocol or PDU 468 format is needed in this case. 470 +-----------------------------------------------------+ 471 | User Payload (e.g. IP PDU) | 472 |-----------------------------------------------------| 473 | GRE as MX Convergence Sublayer | 474 |-----------------------------------------------------| 475 | GRE Delivery Protocol (e.g. IP) | 476 |-----------------------------------------------------| 477 | MX Adaptation | MX Adaptation | MX Adaptation | 478 | Sublayer | Sublayer | Sublayer | 479 | (optional) | (optional) | (optional) | 480 |-----------------------------------------------------| 481 | Access #1 IP | Access #2 IP | Access #3 IP | 482 +-----------------------------------------------------+ 483 Figure 6: MAMS U-plane Protocol Stack with GRE as MX Convergence 484 Layer 486 If NCM determines that N-MADP is to be instantiated with GRE as the MX 487 Convergence Protocol, it exchanges the support of GRE capability in the 488 discovery and capability exchange procedures [MAMS_CP]. 490 4.4.1 Transmitter Procedures 492 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 493 the convergence protocol that transmits the GRE packets. The 494 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 495 with a GRE header and Delivery Protocol (e.g. IP) header to generate 496 the GRE Convergence PDU. 498 When IP is used as the GRE delivery protocol, the IP header information 499 (e.g. IP address) can be created using the IP header of the user 500 payload or a virtual IP address. The "Protocol Type" field of the 501 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 503 The GRE header fields are set as specified below, 505 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 506 to the value of Connection ID for the Anchor Connection associated 507 with the user payload or sets to 0xFFFF if no Anchor Connection ID 508 needs to be specified. 510 - All other fields in the GRE header including the remaining bits in 511 the key fields are set as per [GRE_2784][GRE_2890]. 513 4.4.2 Receiver Procedures 515 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 516 convergence protocol that receives the GRE packets. The receiver 517 processes the received packets per the GRE procedures [GRE_2784, 518 GRE_2890] and retrieves the GRE header. 520 - If the Receiver is an N-MADP instance, 521 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 522 interpreted as the Connection ID of Anchor Connection for the 523 user payload. This is used to identify the network path over 524 which the User Payload (GRE Payload) is to be transmitted. 525 - All other fields in the GRE header, including the remaining bits 526 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 528 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 529 present) before delivery over one of the network paths. 531 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 533 MAMS u-plane protocols support multiple combinations and instances of 534 user plane protocols to be used in the MX Adaptation and the 535 Convergence sublayers. 537 For example, one instance of the MX Convergence Layer can be MPTCP 538 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 539 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 540 set up for network paths considered as untrusted by the operator, to 541 protect the TCP subflow between client and MPTCP proxy traversing that 542 network path. 544 Each of the instances of MAMS user plane, i.e. combination of MX 545 Convergence and MX Adaptation layer protocols, can coexist 546 simultaneously and independently handle different traffic types. 548 5. MX Convergence Control Message 550 A UDP connection may be configured between C-MADP and N-MADP to 551 exchange control messages for keep-alive or path quality estimation. 552 The N-MADP end-point IP address and UDP port number of the UDP 553 connection is used to identify MX control PDU. Figure 7 shows the MX 554 control PDU format with the following fields: 556 o Type (1 Byte): the type of the MX control message 557 + 0: Keep-Alive 558 + 1: Probe REQ/ACK 559 + Others: reserved 560 o CID (1 Byte): the connection ID of the delivery connection for 561 sending out the MX control message 562 o MX Control Message (variable): the payload of the MX control message 564 Figure 8 shows the MX convergence control protocol stack, and MX 565 control PDU goes through the MX adaptation sublayer the same way as MX 566 data PDU. 568 <----MX Control PDU Payload ---------------> 569 +------------------------------------------------------------------+ 570 | IP header | UDP Header| Type | CID | MX Control Message | 571 +------------------------------------------------------------------+ 572 Figure 7: MX Control PDU Format 574 |-----------------------------------------------------| 575 | MX Convergence Control Messages | 576 |-----------------------------------------------------| 577 | UDP/IP | 578 |-----------------------------------------------------| 579 | MX Adaptation | MX Adaptation | MX Adaptation | 580 | Sublayer | Sublayer | Sublayer | 581 | (optional) | (optional) | (optional) | 582 |-----------------------------------------------------| 583 | Access #1 IP | Access #2 IP | Access #3 IP | 584 +-----------------------------------------------------+ 585 Figure 8: MX Convergence Control Protocol Stack 587 5.1 Keep-Alive Message 589 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 590 out Keep-Alive message periodically over one or multiple delivery 591 connections, especially if UDP tunneling is used as the adaptation 592 method for the delivery connection with a NAT function on the path. 594 A Keep-Alive message is 2 Bytes long, and consists of the following 595 fields: 597 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 598 keep-alive message 600 5.2 Probe REQ/ACK Message 602 The "Type" field is set to "1" for Probe REQ/ACK messages. 604 N-MADP may send out the Probe REQ message for path quality estimation. 605 In response, C-MADP may send back the Probe ACK message. 607 A Probe REQ message consists of the following fields: 609 o Probing Sequence Number (2 Bytes): the sequence number of the 610 Probe REQ message 611 o Probing Flag (1 Byte): 612 + Bit #0: a Probe ACK flag to indicate if the Probe ACK message 613 is expected (1) or not (0); 614 + Bit #1: a Probe Type flag to indicate if the Probe REQ/ACK 615 message is sent during the initialization phase (0) when the 616 network path is not included for transmission of user data or 617 the active phase (1) when the network path is included for 618 transmission of user data; 619 + Bit #2: a bit flag to indicate the presence of the Reverse 620 Connection ID (R-CID) field. 621 + Bit #3~7: reserved 622 o Reverse Connection ID (1 Byte): the connection ID of the delivery 623 connection for sending out the Probe ACK message on the reverse 624 path 625 o Padding (variable) 627 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 628 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 629 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 630 Probe ACK message is not expected. 632 If the "R-CID" field is not present but the Bit #0 of the "Probing 633 Flag" field is set to "1", the Probe ACK message SHOULD be sent over 634 the same delivery connection as the Probe REQ message. 636 The "Padding" field is used to control the length of Probe REQ message. 638 C-MADP SHOULD send out the Probe ACK message in response to a Probe REQ 639 message with the Probe ACK flag set to "1". 641 A Probe ACK message is 3 Bytes long, and consists of the following 642 fields: 644 o Probing Acknowledgement Number (2 Bytes): the sequence number of 645 the corresponding Probe REQ message 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 TBD 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 [MAMS_CP] S. Kanugovi, et al., "Control Plane Protocols and 705 Procedures for Multiple Access Management Services" 707 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 708 (GRE)", RFC 2784 March 2000, . 711 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 712 RFC 2890 September 2000, . 715 [IANA] https://www.iana.org/assignments/protocol- 716 numbers/protocol-numbers.xhtml 718 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 719 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 720 Tunnel (LWIP) encapsulation; Protocol specification" 722 [RFC791] Internet Protocol, September 1981 724 Authors' Addresses 726 Jing Zhu 728 Intel 730 Email: jing.z.zhu@intel.com 732 SungHoon Seo 734 Korea Telecom 736 Email: sh.seo@kt.com 738 Satish Kanugovi 740 Nokia 742 Email: satish.k@nokia.com 744 Shuping Peng 746 Huawei 747 Email: pengshuping@huawei.com