idnits 2.17.1 draft-zhu-intarea-mams-user-protocol-03.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 471 has weird spacing: '...the convergen...' == Line 493 has weird spacing: '...ergence proto...' == Line 494 has weird spacing: '...ocesses the ...' -- The document date (August 4, 2017) is 2451 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 689, 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 (~~), 5 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: February 4, 2017 Korea Telecom 5 S. Kanugovi 6 Nokia 7 S. Peng 8 Huawei 9 August 4, 2017 11 User-Plane Protocols for Multiple Access Management Service 12 draft-zhu-intarea-mams-user-protocol-03 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 February 4, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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 Layer......................................4 74 4.2 Trailer-based MX Convergence Layer.......................5 75 4.2.1 Trailer-based MX PDU Format........................5 76 4.2.2 MX Fragmentation...................................7 77 4.2.3 MX Concatenation...................................9 78 4.3 MPTCP-based MX Convergence Layer.........................9 79 4.4 GRE as MX Convergence Layer.............................10 80 4.4.1 Transmitter Procedures............................11 81 4.4.2 Receiver Procedures...............................11 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...........................................14 89 8 Contributing Authors..........................................14 90 9 References....................................................14 91 9.1 Normative References....................................14 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 fields of the IP header of the MX PDU are 298 changed as follows: 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) 303 o IP length: add the length of "MX Trailer" to the length of the 304 original IP packet 305 o IP checksum: recalculate after changing "Protocol Type" and "IP 306 Length" 308 The MX u-plane protocol can support multiple Anchor connections 309 simultaneously, each of which is uniquely identified by Connection ID. 310 It can also support multiple traffic classes per connection, each of 311 which is identified by Traffic Class ID. 313 Moreover, the MX trailer format MAY be negotiated dynamically between 314 NCM and CCM. For example, NCM can send a control message to indicate 315 which of the above fields SHOULD be included for individual delivery 316 connection, on downlink and uplink, respectively. 318 4.2.2 MX Fragmentation 320 The Trailer-based MX Convergence Layer SHOULD support MX fragmentation 321 if a delivery connection has a smaller maximum transmission unit (MTU) 322 than the original IP packet (MX SDU), and IP fragmentation is not 323 supported or enabled on the connection. The MX fragmentation procedure 324 is similar to IP fragmentation [RFC791] in principle, but with the 325 following two differences for less overhead: 327 o The fragment offset field is expressed in number of fragments not 8- 328 bytes blocks 329 o The maximum number of fragments per MX SDU is 2^7 (=128) 331 The Fragmentation Control (FC) field in the MX Trailer contains the 332 following bits: 334 o Bit #7: a More Fragment (MF) flag to indicate if the fragment is the 335 last one (0) or not (1) 336 o Bit #0~#6: Fragment Offset (in units of fragments) to specify the 337 offset of a particular fragment relative to the beginning of the MX 338 SDU 340 A MX PDU carries a whole MX SDU without fragmentation if the FC field 341 is set to all "0"s or the FC field is not present in the trailer. 342 Otherwise, the MX PDU contains a fragment of the MX SDU. 344 The Sequence Number (SN) field in the trailer is used to distinguish 345 the fragments of one MX SDU from those of another. The Fragment Offset 346 (FO) field tells the receiver the position of a fragment in the 347 original MX SDU. The More Fragment (MF) flag indicates the last 348 fragment. 350 To fragment a long MX SDU, the MADP transmitter creates two MX PDUs and 351 copies the content of the IP header fields from the long MX PDU into 352 the IP header of both MX PDUs. The length field in the IP header of MX 353 PDU SHOULD be changed to the length of the MX PDU, and the protocol 354 type SHOULD be changed to "114", indicating the presence of the MX 355 trailer. 357 The data of the long MX SDU is divided into two portions based on the 358 MTU size of the delivery connection. The first portion of the data is 359 placed in the first MX PDU. The MF flag is set to "1", and the FO field 360 is set to "0". The second portion of the data is placed in the second 361 MX PDU. The MF flag is set to "0", and the FO field is set to "1". This 362 procedure can be generalized for an n-way split, rather than the two- 363 way split described the above. 365 To assemble the fragments of a MX SDU, the MADP receiver combines MX 366 PDUs that all have the same MX Sequence Number (in the trailer). The 367 combination is done by placing the data portion of each fragment in the 368 relative order indicated by the Fragment Offset in that fragment's MX 369 trailer. The first fragment will have the Fragment Offset set to "0", 370 and the last fragment will have the More-Fragments flag reset to "0". 372 4.2.3 MX Concatenation 374 The Trailer-based MX Convergence Layer MAY support MX concatenation if 375 a delivery connection has a larger maximum transmission unit (MTU) than 376 the original IP packet (MX SDU). 378 The First SDU Length (FSL) field SHOULD be present in the MX Trailer if 379 a MX PDU contains multiple MX SDUs, i.e. concatenation, and it 380 indicates the length of the first MX SDU in the PDU. 382 Only the MX SDUs with the same client address, the same anchor 383 connection and the same Traffic Class MAY be concatenated. 385 To concatenate two or more MX SDUs, the MADP transmitter creates one MX 386 PDU and copies the content of the IP header field from the first MX SDU 387 into the IP header of the MX PDU. The data of the first MX SDU is 388 placed in the first portion of the data of the MX PDU. The whole second 389 MX SDU is then placed in the second portion of the data of the MX PDU 390 (Figure 4). The procedure continues till the MX PDU size reaches the 391 MTU of the delivery connection. 393 To disaggregate a MX PDU, the MADP receiver first obtains the length of 394 the first MX SDU from the First SDU Length field in the trailer, and 395 decodes the first MX SDU. The MADP receiver then obtains the length of 396 the second MX SDU based on the length field in the second MX SDU IP 397 header, and decodes the second MX SDU. The procedure continues till no 398 byte is left in the MX PDU. 400 If a MX PDU contains multiple SDUs, the SN field in the MX trailer is 401 for the last MX SDU, and the SN of other SDU carried by the same PDU 402 can be obtained according to its order in the PDU. For example, if the 403 SN field is 6 and a MX PDU contains 3 SDUs (IP packets), then the SN is 404 4, 5, and 6 for the first, second, and the last IP packet in the PDU, 405 respectively. 407 <---- MX Data PDU Payload ------------> 408 +------------------------------------------------------------+ 409 | IP hdr | IP payload | IP hdr | IP payload | MX Trailer | 410 +------------------------------------------------------------+ 411 Figure 4: MX PDU Format with Concatenation 413 4.3 MPTCP-based MX Convergence Sublayer 415 Figure 5 shows the MAMS u-plane protocol stack based on MPTCP. Here, 416 MPTCP is reused as the "MX Convergence Sublayer" protocol. Multiple 417 access networks are combined into a single MPTCP connection. Hence, no 418 new u-plane protocol or PDU format is needed in this case. 420 |-----------------------------------------------------| 421 | MPTCP | 422 |-----------------------------------------------------| 423 | TCP | TCP | TCP | 424 |-----------------------------------------------------| 425 | MX Adaptation | MX Adaptation | MX Adaptation | 426 | Sublayer | Sublayer | Sublayer | 427 | (optional) | (optional) | (optional) | 428 |-----------------------------------------------------| 429 | Access #1 IP | Access #2 IP | Access #3 IP | 430 +-----------------------------------------------------+ 431 Figure 5: MAMS U-plane Protocol Stack with MPTCP as MX Convergence 432 Layer 434 If NCM determines that N-MADP is to be instantiated with MPTCP as the 435 MX Convergence Protocol, it exchanges the support of MPTCP capability 436 in the discovery and capability exchange procedures [MAMS_CP]. MPTCP 437 proxy protocols [MPProxy][MPPlain] SHOULD be used to manage traffic 438 steering and aggregation over multiple delivery connections. 440 4.4 GRE as MX Convergence Sublayer 442 Figure 6 shows the MAMS u-plane protocol stack based on GRE (Generic 443 Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX 444 Convergence sub-layer" protocol. Multiple access networks are combined 445 into a single GRE connection. Hence, no new u-plane protocol or PDU 446 format is needed in this case. 448 +-----------------------------------------------------+ 449 | User Payload (e.g. IP PDU) | 450 |-----------------------------------------------------| 451 | GRE as MX Convergence Sublayer | 452 |-----------------------------------------------------| 453 | GRE Delivery Protocol (e.g. IP) | 454 |-----------------------------------------------------| 455 | MX Adaptation | MX Adaptation | MX Adaptation | 456 | Sublayer | Sublayer | Sublayer | 457 | (optional) | (optional) | (optional) | 458 |-----------------------------------------------------| 459 | Access #1 IP | Access #2 IP | Access #3 IP | 460 +-----------------------------------------------------+ 461 Figure 6: MAMS U-plane Protocol Stack with GRE as MX Convergence 462 Layer 464 If NCM determines that N-MADP is to be instantiated with GRE as the MX 465 Convergence Protocol, it exchanges the support of GRE capability in the 466 discovery and capability exchange procedures [MAMS_CP]. 468 4.4.1 Transmitter Procedures 470 Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as 471 the convergence protocol that transmits the GRE packets. The 472 Transmitter receives the User Payload (e.g. IP PDU), encapsulates it 473 with a GRE header and Delivery Protocol (e.g. IP) header to generate 474 the GRE Convergence PDU. 476 When IP is used as the GRE delivery protocol, the IP header information 477 (e.g. IP address) can be created using the IP header of the user 478 payload or a virtual IP address. The "Protocol Type" field of the 479 delivery header is set to 47 (or 0X2F, i.e. GRE)[IANA]. 481 The GRE header fields are set as specified below, 483 - If the transmitter is a C-MADP instance, then sets the LSB 16 bits 484 to the value of Connection ID for the Anchor Connection associated 485 with the user payload or sets to 0xFFFF if no Anchor Connection ID 486 needs to be specified. 487 - All other fields in the GRE header including the remaining bits in 488 the key fields are set as per [GRE_2784][GRE_2890]. 490 4.4.2 Receiver Procedures 492 Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the 493 convergence protocol that receives the GRE packets. The receiver 494 processes the received packets per the GRE procedures [GRE_2784, 495 GRE_2890] and retrieves the GRE header. 497 - If the Receiver is an N-MADP instance, 498 o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are 499 interpreted as the Connection ID of Anchor Connection for the 500 user payload. This is used to identify the network path over 501 which the User Payload (GRE Payload) is to be transmitted. 502 - All other fields in the GRE header, including the remaining bits 503 in the Key fields, are processed as per [GRE_2784][GRE_2890]. 505 The GRE Convergence PDU is passed onto the MX Adaptation Layer (if 506 present) before delivery over one of the network paths. 508 4.5 Co-existence of MX Adaptation and MX Convergence Sublayers 510 MAMS u-plane protocols support multiple combinations and instances of 511 user plane protocols to be used in the MX Adaptation and the 512 Convergence sublayers. 514 For example, one instance of the MX Convergence Layer can be MPTCP 515 Proxy [MPProxy][MPPlain] and another instance can be Trailer-based. The 516 MX Adaptation for each can be either UDP tunnel or IPsec. IPsec may be 517 set up for network paths considered as untrusted by the operator, to 518 protect the TCP subflow between client and MPTCP proxy traversing that 519 network path. 521 Each of the instances of MAMS user plane, i.e. combination of MX 522 Convergence and MX Adaptation layer protocols, can coexist 523 simultaneously and independently handle different traffic types. 525 5. MX Convergence Control Message 527 A UDP connection may be configured between C-MADP and N-MADP to 528 exchange control messages for keep-alive or path quality estimation. 529 The N-MADP end-point IP address and UDP port number of the UDP 530 connection is used to identify MX control PDU. Figure 7 shows the MX 531 control PDU format with the following fields: 533 o Type (1 Byte): the type of the MX control message 534 + 0: Keep-Alive 535 + 1: Probe REQ/ACK 536 + Others: reserved 537 o CID (1 Byte): the connection ID of the delivery connection for 538 sending out the MX control message 539 o MX Control Message (variable): the payload of the MX control message 541 Figure 8 shows the MX convergence control protocol stack, and MX 542 control PDU goes through the MX adaptation sublayer the same way as MX 543 data PDU. 545 <----MX Control PDU Payload ---------------> 546 +------------------------------------------------------------------+ 547 | IP header | UDP Header| Type | CID | MX Control Message | 548 +------------------------------------------------------------------+ 549 Figure 7: MX Control PDU Format 551 |-----------------------------------------------------| 552 | MX Convergence Control Messages | 553 |-----------------------------------------------------| 554 | UDP/IP | 555 |-----------------------------------------------------| 556 | MX Adaptation | MX Adaptation | MX Adaptation | 557 | Sublayer | Sublayer | Sublayer | 558 | (optional) | (optional) | (optional) | 559 |-----------------------------------------------------| 560 | Access #1 IP | Access #2 IP | Access #3 IP | 561 +-----------------------------------------------------+ 562 Figure 8: MX Convergence Control Protocol Stack 564 5.1 Keep-Alive Message 566 The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send 567 out Keep-Alive message periodically over one or multiple delivery 568 connections, especially if UDP tunneling is used as the adaptation 569 method for the delivery connection with a NAT function on the path. 571 A Keep-Alive message is 2 Bytes long, and consists of the following 572 fields: 574 o Keep-Alive Sequence Number (2 Bytes): the sequence number of the 575 keep-alive message 577 5.2 Probe REQ/ACK Message 579 The "Type" field is set to "1" for Probe REQ/ACK messages. 581 N-MADP may send out the Probe REQ message for path quality estimation. 582 In response, C-MADP may send back the Probe ACK message. 584 A Probe REQ message consists of the following fields: 586 o Probing Sequence Number (2 Bytes): the sequence number of the 587 Probe REQ message 588 o Probing Flag (1 Byte): 589 + Bit #0: a Probe ACK flag to indicate if the Probe ACK message 590 is expected (1) or not (0); 591 + Bit #1: a Probe Type flag to indicate if the Probe REQ/ACK 592 message is sent during the initialization phase (0) when the 593 network path is not included for transmission of user data or 594 the active phase (1) when the network path is included for 595 transmission of user data; 596 + Bit #2: a bit flag to indicate the presence of the Reverse 597 Connection ID (R-CID) field. 598 + Bit #3~7: reserved 599 o Reverse Connection ID (1 Byte): the connection ID of the delivery 600 connection for sending out the Probe ACK message on the reverse 601 path 603 o Padding (variable) 605 The "R-CID" field is only present if both Bit #0 and Bit #2 of the 606 "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing 607 Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the 608 Probe ACK message is not expected. 610 If the "R-CID" field is not present but the Bit #0 of the "Probing 611 Flag" field is set to "1", the Probe ACK message SHOULD be sent over 612 the same delivery connection as the Probe REQ message. 614 The "Padding" field is used to control the length of Probe REQ message. 616 C-MADP SHOULD send out the Probe ACK message in response to a Probe REQ 617 message with the Probe ACK flag set to "1". 619 A Probe ACK message is 3 Bytes long, and consists of the following 620 fields: 622 o Probing Acknowledgement Number (2 Bytes): the sequence number of 623 the corresponding Probe REQ message 625 6 Security Considerations 627 User data in MAMS framework rely on the security of the underlying 628 network transport paths. When this cannot be assumed, NCM configures 629 use of appropriate protocols for security, e.g. IPsec [RFC4301] 630 [RFC3948], DTLS [RFC6347]. 632 7 IANA Considerations 634 TBD 636 8 Contributing Authors 638 The editors gratefully acknowledge the following additional 639 contributors in alphabetical order: Salil Agarwal/Nokia, Hema 640 Pentakota/Nokia. 642 9 References 644 9.1 Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 650 Internet Protocol", RFC 4301, DOI10.17487/RFC4301, 651 December 2005, . 653 9.2 Informative References 655 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 656 Security Version 1.2", RFC 6347, January 2012, 657 . 659 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 660 Kivinen, "Internet Key Exchange Protocol Version 2 661 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 662 2014, . 664 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 665 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 666 3948, DOI 10.17487/RFC3948, January 2005, . 669 [MPProxy] X. Wei, C. Xiong, and E. Lopez, "MPTCP proxy mechanisms", 670 https://tools.ietf.org/html/draft-wei-mptcp-proxy- 671 mechanism-02 673 [MPPlain] M. Boucadair et al, "An MPTCP Option for Network-Assisted 674 MPTCP", https://www.ietf.org/id/draft-boucadair-mptcp- 675 plain-mode-09.txt 677 [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple 678 Access Management Protocol", 679 https://tools.ietf.org/html/draft-kanugovi-intarea-mams- 680 protocol-03 682 [MAMS_CP] S. Kanugovi, et al., "Control Plane Protocols and 683 Procedures for Multiple Access Management Services" 685 [GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation 686 (GRE)", RFC 2784 March 2000, . 689 [GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE", 690 RFC 2890 September 2000, . 693 [IANA] https://www.iana.org/assignments/protocol- 694 numbers/protocol-numbers.xhtml 696 [LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access 697 (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec 698 Tunnel (LWIP) encapsulation; Protocol specification" 700 [RFC791] Internet Protocol, September 1981 702 Authors' Addresses 704 Jing Zhu 706 Intel 708 Email: jing.z.zhu@intel.com 710 SungHoon Seo 712 Korea Telecom 714 Email: sh.seo@kt.com 716 Satish Kanugovi 718 Nokia 720 Email: satish.k@nokia.com 722 Shuping Peng 724 Huawei 726 Email: pengshuping@huawei.com