< draft-zhu-intarea-mams-user-protocol-01.txt   draft-zhu-intarea-mams-user-protocol-02.txt >
INTAREA J. Zhu INTAREA J. Zhu
Internet Draft Intel Internet Draft Intel
Intended status: Standards Track S. Seo Intended status: Standards Track S. Seo
Expires: September 27, 2017 Korea Telecom Expires: December 16, 2017 Korea Telecom
March 27, 2017 S. Kanugovi
Nokia
S. Peng
Huawei
June 16, 2017
User-Plane Protocols for Multiple Access Management Service User-Plane Protocols for Multiple Access Management Service
draft-zhu-intarea-mams-user-protocol-01 draft-zhu-intarea-mams-user-protocol-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 36
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 27, 2017. This Internet-Draft will expire on December 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 18
Abstract Abstract
Today, a device can be simultaneously connected to multiple Today, a device can be simultaneously connected to multiple
communication networks based on different technology implementations communication networks based on different technology implementations
and network architectures like WiFi, LTE, DSL. In such multi- and network architectures like WiFi, LTE, DSL. In such multi-
connectivity scenario, it is desirable to combine multiple access connectivity scenario, it is desirable to combine multiple access
networks or select the best one to improve quality of experience for networks or select the best one to improve quality of experience for
a user and improve overall network utilization and efficiency. This a user and improve overall network utilization and efficiency. This
document presents the u-plane protocols for a multi access document presents the u-plane protocols for a multi access
management services (MAMS) framework that can be used to flexibly management services (MAMS) framework that can be used to flexibly
select the best combination of uplink and downlink access and core select the combination of uplink and downlink access and core
network paths, and user plane treatment for improving network network paths having the optimal performance, and user plane
efficiency and enhanced application quality of experience. treatment for improving network utilization and efficiency and
enhanced quality of experience for user applications.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................3
2. Terminologies..................................................3 2. Terminologies..................................................3
3. Conventions used in this document..............................3 3. Conventions used in this document..............................3
4 MAMS User-Plane Protocols......................................3 4 MAMS User-Plane Protocols......................................4
4.1 MX Adaptation Layer......................................4 4.1 MX Adaptation Layer......................................4
4.2 Trailer-based MX Convergence Layer.......................5 4.2 Trailer-based MX Convergence Layer.......................5
4.3 MPTCP-based MX Convergence Layer.........................6 4.2.1 Trailer-based MX PDU Format........................5
4.4 Co-existence of MX Adaptation and MX Convergence Layers..6 4.2.2 MX Fragmentation...................................7
5 Security Considerations........................................6 4.2.3 MX Concatenation...................................8
6 IANA Considerations............................................6 4.3 MPTCP-based MX Convergence Layer.........................9
7 Contributing Authors...........................................7 4.4 GRE as MX Convergence Layer.............................10
8 References.....................................................7 5.4.1 Transmitter Procedures............................11
8.1 Normative References.....................................7 5.4.2 Receiver Procedures...............................11
8.2 Informative References...................................7 5.5 Co-existence of MX Adaptation and MX Convergence Sublayers
11
6 MX Convergence Control........................................12
6.1 Keep-Alive Message......................................13
6.2 Probe REQ/ACK Message...................................13
7 Security Considerations.......................................14
8 IANA Considerations...........................................14
9 Contributing Authors..........................................14
10 References....................................................14
10.1 Normative References....................................14
10.2 Informative References..................................14
1. Introduction 1. Introduction
Multi Access Management Service (MAMS) [MAMS] is a programmable Multi Access Management Service (MAMS) [MAMS] is a programmable
framework to select and configure network paths, as well as adapt to framework to select and configure network paths, as well as adapt to
dynamic network conditions, when multiple network connections can dynamic network conditions, when multiple network connections can
serve a client device. It is based on principles of user plane serve a client device. It is based on principles of user plane
interworking that enables the solution to be deployed as an overlay interworking that enables the solution to be deployed as an overlay
without impacting the underlying networks. without impacting the underlying networks.
This document presents the u-plane protocols for the MAMS framework. This document presents the u-plane protocols for enabling the MAMS
It co-exists and complements the existing protocols by providing a framework. It co-exists and complements the existing protocols by
way to negotiate and configure the protocols based on client and providing a way to negotiate and configure the protocols based on
network capabilities. Further it allows exchange of network state client and network capabilities. Further it allows exchange of
information and leveraging network intelligence to optimize the network state information and leveraging network intelligence to
performance of such protocols. An important goal for MAMS is to optimize the performance of such protocols. An important goal for
ensure that there is minimal or no dependency on the actual access MAMS is to ensure that there is minimal or no dependency on the
technology of the participating links. This allows the scheme to be actual access technology of the participating links. This allows the
scalable for addition of newer accesses and for independent scheme to be scalable for addition of newer accesses and for
technology evolution of the existing accesses. independent evolution of the existing access technologies.
2. Terminologies 2. Terminologies
Anchor Connection: refers to the network path from the N-MADP to the Anchor Connection: refers to the network path from the N-MADP to the
Application Server that corresponds to a specific IP anchor that has Application Server that corresponds to a specific IP anchor that has
assigned an IP address to the client assigned an IP address to the client
Delivery Connection: refers to the network path from the N-MADP to Delivery Connection: refers to the network path from the N-MADP to
the client. the C-MADP.
"Network Connection Manager" (NCM), "Client Connection Manager" "Network Connection Manager" (NCM), "Client Connection Manager"
(CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi
Access Data Proxy" (C-MADP) in this document are to be interpreted Access Data Proxy" (C-MADP) in this document are to be interpreted
as described in [MAMS]. as described in [MAMS].
3. Conventions used in this document 3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 13 skipping to change at page 4, line 31
| | Access #1 IP | Access #2 IP | Access #3 IP | | | | Access #1 IP | Access #2 IP | Access #3 IP | |
| +-----------------------------------------------------+ | | +-----------------------------------------------------+ |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 1: MAMS U-plane Protocol Stack Figure 1: MAMS U-plane Protocol Stack
It consists of the following two Sublayers: It consists of the following two Sublayers:
o Multi-Access (MX) Convergence Sublayer: This layer performs multi- o Multi-Access (MX) Convergence Sublayer: This layer performs multi-
access specific tasks, e.g., access (path) selection, multi-link access specific tasks, e.g., access (path) selection, multi-link
(path) aggregation, splitting/reordering, lossless switching, (path) aggregation, splitting/reordering, lossless switching,
fragmentation, concatenation, etc. fragmentation, concatenation, keep-alive, probing etc.
o Multi-Access (MX) Adaptation Sublayer: This layer performs functions o Multi-Access (MX) Adaptation Sublayer: This layer performs functions
to handle tunnelling, network layer security, and NAT. to handle tunneling, network layer security, and NAT.
The MX convergence sublayer operates on top of the MX adaptation
sublayer in the protocol stack. From the Transmitter perspective, a
User Payload (e.g. IP PDU) is processed by the convergence sublayer
first, and then by the adaptation sublayer before being transported
over a delivery access connection; From the Receiver perspective, an IP
packet received over a delivery connection is processed by the MX
adaptation sublayer first, and then by the MX convergence sublayer.
4.1 MX Adaptation Layer 4.1 MX Adaptation Layer
The MX adaptation layer supports the following mechanisms and protocols The MX adaptation layer supports the following mechanisms and protocols
while transmitting user plane packets on the network path: while transmitting user plane packets on the network path:
o UDP Tunneling: The user plane packets of the anchor connection can be o UDP Tunneling: The user plane packets of the anchor connection can be
encapsulated in a UDP tunnel of a delivery connection between the N- encapsulated in a UDP tunnel of a delivery connection between the N-
MADP and C-MADP. MADP and C-MADP.
o IPsec Tunneling: The user plane packets of the anchor connection are o IPsec Tunneling: The user plane packets of the anchor connection are
skipping to change at page 4, line 43 skipping to change at page 5, line 26
The MX adaptation layer also supports the following mechanisms and The MX adaptation layer also supports the following mechanisms and
protocols to ensure security of user plane packets over the network protocols to ensure security of user plane packets over the network
path. path.
o IPSec Tunneling: An IPsec [RFC7296] tunnel is established between the o IPSec Tunneling: An IPsec [RFC7296] tunnel is established between the
N-MADP and C-MADP on the network path that is considered untrusted. N-MADP and C-MADP on the network path that is considered untrusted.
o DTLS: If UDP tunneling is used on the network path that is considered o DTLS: If UDP tunneling is used on the network path that is considered
"untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can "untrusted", DTLS (Datagram Transport Layer Security) [RFC6347] can
be used. be used.
The Client NAT method is most efficient due to no tunneling overhead. The Client NAT method is the most efficient due to no tunneling
It SHOULD be used if a delivery connection is "trusted" and without NAT overhead. It SHOULD be used if a delivery connection is "trusted" and
function on the path. without NAT function on the path.
The UDP or IPSec Tunnelling method SHOULD be used if a delivery The UDP or IPSec Tunnelling method SHOULD be used if a delivery
connection has a NAT function on the path. connection has a NAT function placed on the path.
4.2 Trailer-based MX Convergence Layer 4.2 Trailer-based MX Convergence Layer
Trailer based MX convergence integrates multiple connections into a 4.2.1 Trailer-based MX PDU Format
Trailer-based MX convergence integrates multiple connections into a
single e2e IP connection. It operates between Layer 2 (L2) and Layer 3 single e2e IP connection. It operates between Layer 2 (L2) and Layer 3
(network/IP). (network/IP).
<-------- MX PDU Payload ----------------> <-- MX Data PDU Payload ------->
+------------------------------------------------------+ +------------------------------------------------------+
| IP (v4 or v6) header | IP payload | MX Trailer | | IP hdr | IP payload | MX Trailer |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 2: Trailer-based Multi-Access (MX) PDU Format Figure 2: Trailer-based Multi-Access (MX) Data PDU Format
Figure 2 shows the trailer-based Multi-Access (MX) PDU (Protocol Data Figure 2 shows the trailer-based Multi-Access (MX) PDU (Protocol Data
Unit) format. A MX PDU MAY carry multiple IP PDUs in the payload if Unit) format. A MX PDU MAY carry multiple IP PDUs in the payload if
concatenation is supported, and MAY carry a fragment of the IP PDU if concatenation is supported, and MAY carry a fragment of the IP PDU if
fragmentation is supported. fragmentation is supported.
The MX trailer may consist of the following fields: The MX trailer may consist of the following fields:
o MX flags (e.g. 1 byte): Bit 0 is the most significant bit, bit 7 is
the least significant bit. Bit 6 and 7 are reserved for future.
+ Next Header Present (bit 0): If the Next Header Present bit is
set to 1, then the Next Header field is present and contains
valid information.
+ Connection ID Present (bit 1): If the Connection ID Present bit
is set to 1, then the Connection ID field is present and
contains valid information.
+ Traffic Class Present (bit 2): If the Traffic Class Present bit
is set to 1, then the Traffic Class field is present and
contains valid information.
+ Sequence Number Present (bit 3): If the Sequence Number Present
bit is set to 1, then the Sequence Number field is present and
contains valid information.
+ Packet Length Present (bit 4): If the Packet Length Present bit
is set to 1, then the First SDU Length field is present and
contains valid information.
+ Fragmentation Control Present (bit 5): If the Fragmentation
Control Present bit is set to 1, then the Fragmentation Control
field is present and contains valid information.
+ Bit 6~7: reserved
o Next Header (e.g. 1 byte): the IP protocol type of the (first) IP o Next Header (e.g. 1 byte): the IP protocol type of the (first) IP
packet in a MX PDU packet in a MX PDU
o Connection ID (e.g.1 byte): an unsigned integer to identify the o Connection ID (e.g.1 byte): an unsigned integer to identify the
anchor connection of the IP packets in a MX PDU anchor connection of the IP packets in a MX PDU
o Traffic Class ID (e.g. 1 byte): an unsigned integer to identify the o Traffic Class (TC) ID (e.g. 1 byte): an unsigned integer to identify
traffic class of the IP packets in a MX PDU, for example Data Radio the traffic class of the IP packets in a MX PDU, for example Data
Bearer (DRB) ID for a cellular connection Radio Bearer (DRB) ID [LWIPEP] for a cellular (e.g. LTE) connection
o Sequence Number (e.g. 2 bytes): an auto-incremented integer to o Sequence Number (e.g. 2 bytes): an auto-incremented integer to
indicate order of transmission of the IP packet, needed for lossless indicate order of transmission of the IP packet, needed for lossless
switching or multi-link (path) aggregation. switching or multi-link (path) aggregation or fragmentation.
o Packet Length (e.g. 2 bytes): the length of the first IP packet, only o First SDU Length (e.g. 2 bytes): the length of the first IP packet,
included if a MX PDU contains multiple IP packets, i.e. concatenation only included if a MX PDU contains multiple IP packets, i.e.
o Fragmentation Control (e.g. 1 Byte): to provide necessary information concatenation.
for re-assembly, only needed if a MX PDU carries fragments, i.e. o Fragmentation Control (FC) (e.g. 1 Byte): to provide necessary
fragmentation information for re-assembly, only needed if a MX PDU carries
o Bit #7: a More Fragment (MF) flag to indicate if the fragment is fragments, i.e. fragmentation.
the last one or not
o Bit #0~#6: Fragment Offset (in units of fragments) to specify the Figure 3 shows the MX trailer format with all the fields present. The
offset of a particular fragment relative to the beginning of the MX flags are always encoded in the last octet of the MX Trailer at the
original unfragmented IP datagram end of a MX PDU. Hence, the Receiver SHOULD first decode the MX flags
field to determine the length of the MX trailer, and then decode each
MX field accordingly.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Connection ID | TC ID | Sequence
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number | First SDU Length | FC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MX Flags |
+-+-+-+-+-+-+-+-+
Figure 3: MX Trailer Format
Moreover, the following fields of the IP header of the MX PDU are Moreover, the following fields of the IP header of the MX PDU are
changed as follows: changed as follows:
o Protocol Type: "114" to indicate that the presence of MX trailer o Protocol Type: "114" to indicate that the presence of MX trailer
(i.e. the trailer based MAMS u-plane protocol is a "0-hop" protocol, (i.e. the trailer based MAMS u-plane protocol is a "0-hop" protocol,
not subject to IP routing) not subject to IP routing)
o IP length: add the length of "MX Trailer" to the length of the o IP length: add the length of "MX Trailer" to the length of the
original IP packet original IP packet
o IP checksum: recalculate after changing "Protocol Type" and "IP o IP checksum: recalculate after changing "Protocol Type" and "IP
skipping to change at page 6, line 19 skipping to change at page 7, line 43
The MX u-plane protocol can support multiple Anchor connections The MX u-plane protocol can support multiple Anchor connections
simultaneously, each of which is uniquely identified by Connection ID. simultaneously, each of which is uniquely identified by Connection ID.
It can also support multiple traffic classes per connection, each of It can also support multiple traffic classes per connection, each of
which is identified by Traffic Class ID. which is identified by Traffic Class ID.
Moreover, the MX trailer format MAY be negotiated dynamically between Moreover, the MX trailer format MAY be negotiated dynamically between
NCM and CCM. For example, NCM can send a control message to indicate NCM and CCM. For example, NCM can send a control message to indicate
which of the above fields SHOULD be included for individual delivery which of the above fields SHOULD be included for individual delivery
connection, on downlink and uplink, respectively. connection, on downlink and uplink, respectively.
4.2.2 MX Fragmentation
The Trailer-based MX Convergence Layer SHOULD support MX fragmentation
if a delivery connection has a smaller maximum transmission unit (MTU)
than the original IP packet (MX SDU), and IP fragmentation is not
supported or enabled on the connection. The MX fragmentation
procedure is similar to IP fragmentation [RFC791] in principle, but
with the following two differences for less overhead:
o The fragment offset unit is fragment not eight-bye blocks.
o The maximum number of fragments per MX SDU is 2^7 (=128)
The Fragmentation Control (FC) field in the MX Trailer contains the
following bits:
o Bit #7: a More Fragment (MF) flag to indicate if the fragment is the
last one (0) or not (1)
o Bit #0~#6: Fragment Offset (in units of fragments) to specify the
offset of a particular fragment relative to the beginning of the MX
SDU
A MX PDU carries a whole MX SDU without fragmentation if the FC field
is set to all "0"s or the FC field is not present in the trailer.
Otherwise, the MX PDU contains a fragment of the MX SDU.
The Sequence Number field in the trailer is used to distinguish the
fragments of one MX SDU from those of another. The Fragment Offset (FO)
field tells the receiver the position of a fragment in the original MX
SDU. The More Fragment (MF) flag indicates the last fragment.
To fragment a long MX SDU, the MADP transmitter creates two MX PDUs and
copies the contents of the IP header fields from the long MX PDU into
the IP header of both MX PDUs. The length field in the IP header of MX
PDU SHOULD be changed to the length of the MX PDU, and the protocol
type SHOULD be changed to "114", indicating the presence of the MX
trailer.
The data of the long MX SDU is divided into two portions based on the
MTU size of the delivery connection. The first portion of the data is
placed in the first MX PDU. The MF flag is set to 1, and the FO field
is set to 0. The second portion of the data is placed in the second MX
PDU. The MF flag is set to 0, and the FO field is set to 1. This
procedure can be generalized for an n-way split, rather than the two-
way split described.
To assemble the fragments of a MX SDU, the MADP receiver combines MX
PDUs that all have the same MX Sequence Number (in the trailer). The
combination is done by placing the data portion of each fragment in the
relative order indicated by the Fragment Offset in that fragment's MX
trailer. The first fragment will have the Fragment Offset zero, and the
last fragment will have the More-Fragments flag reset to zero.
4.2.3 MX Concatenation
The Trailer-based MX Convergence Layer MAY support MX concatenation if
a delivery connection has a larger maximum transmission unit (MTU) than
the original IP packet (MX SDU).
The First SDU Length (FSL) field SHOULD be present in the MX Trailer if
a MX PDU contains multiple MX SDUs, i.e. concatenation, and it
indicates the length of the first MX SDU in the PDU.
Only the MX SDUs with the same client address, the same anchor
connection and the same Traffic Class MAY be concatenated.
To concatenate two or more MX SDUs, the MADP transmitter creates one MX
PDU and copies the contents 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.
To disaggregate a MX PDU, the MADP receiver first obtains the length of
the first MX SDU from the First SDU Length field in the trailer, and
decodes the first MX SDU. The MADP receiver then obtains the length of
the second MX SDU based on the length field in the second MX SDU IP
header, and decodes the second MX SDU. The procedure continues till no
byte is left in the MX PDU.
If a MX PDU contains multiple SDUs, the SN field in the MX trailer is
for the last MX SDU, and the SN of other SDU carried by the same PDU
can be obtained according to its order in the PDU. For example, if the
SN field is 6 and a MX PDU contains 3 SDUs (IP packets), then the SN is
4, 5, and 6 for the first, second, and the last IP packet in the PDU,
respectively.
<---- MX Data PDU Payload ------------>
+------------------------------------------------------------+
| IP hdr | IP payload | IP hdr | IP payload | MX Trailer |
+------------------------------------------------------------+
Figure 4: MX PDU Format with Concatenation
4.3 MPTCP-based MX Convergence Layer 4.3 MPTCP-based MX Convergence Layer
TBD Figure 5 shows the MAMS u-plane protocol stack based on MPTCP. Here,
MPTCP is reused as the "MX Convergence sub-layer" protocol. Multiple
access networks are combined into a single MPTCP connection. Hence, no
new u-plane protocol or PDU format is needed in this case.
4.4 Co-existence of MX Adaptation and MX Convergence Layers |-----------------------------------------------------|
| MPTCP |
|-----------------------------------------------------|
| TCP | TCP | TCP |
|-----------------------------------------------------|
| MX Adaptation | MX Adaptation | MX Adaptation |
| Sublayer | Sublayer | Sublayer |
| (optional) | (optional) | (optional) |
|-----------------------------------------------------|
| Access #1 IP | Access #2 IP | Access #3 IP |
+-----------------------------------------------------+
Figure 5: MAMS U-plane Protocol Stack with MPTCP as MX Convergence
Layer
If NCM determines that N-MADP is to be instantiated with MPTCP as the
MX Convergence Protocol, it exchanges the support of MPTCP capability
in the discovery and capability exchange procedures [MAMS_CP]. MPTCP
proxy protocols [MPProxy] [MPPlain] SHOULD be used to manage traffic
steering and aggregation over multiple delivery connections.
4.4 GRE as MX Convergence Layer
Figure 6 shows the MAMS u-plane protocol stack based on GRE (Generic
Routing Encapsulation) [GRE2784]. Here, GRE is reused as the "MX
Convergence sub-layer" protocol. Multiple access networks are combined
into a single GRE connection. Hence, no new u-plane protocol or PDU
format is needed in this case.
+-----------------------------------------------------+
| User Payload (e.g. IP PDU) |
|-----------------------------------------------------|
| GRE as MX Convergence Layer |
|-----------------------------------------------------|
| GRE Delivery Protocol (e.g. IP) |
|-----------------------------------------------------|
| MX Adaptation | MX Adaptation | MX Adaptation |
| Sublayer | Sublayer | Sublayer |
| (optional) | (optional) | (optional) |
|-----------------------------------------------------|
| Access #1 IP | Access #2 IP | Access #3 IP |
+-----------------------------------------------------+
Figure 6: MAMS U-plane Protocol Stack with GRE as MX Convergence
Layer
If NCM determines that N-MADP is to be instantiated with GRE as the MX
Convergence Protocol, it exchanges the support of GRE capability in the
discovery and capability exchange procedures [MAMS_CP].
5.4.1 Transmitter Procedures
Transmitter is the N-MADP or C-MADP instance, instantiated with GRE as
the convergence protocol that transmits the GRE packets. The
Transmitter receives the User Payload (e.g. IP PDU), encapsulates it
with a GRE header and Delivery Protocol (e.g. IP) header to generate
the GRE Convergence PDU.
When IP is used as the GRE delivery protocol, the IP header information
(e.g. IP address) can be created using the IP header of the user
payload or a virtual IP address. The "Protocol Type" field of the
delivery header is set to 47 (or 0X2F)[IANA].
The GRE header fields are set as specified below
- If the transmitter is a C-MADP instance, then set the LSB 16 bits
to the value of Connection ID for the Anchor Connection associated
with the user payload or set to 0xFFFF, if no Anchor Connection ID
needs to be specified.
- All other fields in the GRE header including the remaining bits in
the key field are set per [GRE_2784][GRE_2890].
5.4.2 Receiver Procedures
Receiver is the N-MADP or C-MADP instance, instantiated with GRE as the
convergence protocol, that receives the GRE packets. The receiver
processes the received packets per the GRE procedures [GRE_2784,
GRE_2890] and retrieves the GRE header.
- If the Receiver is an N-MADP instance,
o Unless the LSB 16 Bits of the Key field are 0xFFFF, they are
interpreted as the Connection ID of Anchor Connection for the
user payload. This is used to identify the network path over
which the User Payload (GRE Payload) is to be transmitted.
- All other fields in the GRE header, including the remaining bits
in the Key field, are processed per [GRE_2784][GRE_2890].
The GRE Convergence PDU is passed onto the MX Adaptation Layer (if
present) before delivery over one of the network paths.
5.5 Co-existence of MX Adaptation and MX Convergence Sublayers
MAMS u-plane protocols support multiple combinations and instances of MAMS u-plane protocols support multiple combinations and instances of
user plane protocols to be used in the MX Adaptation and the user plane protocols to be used in the MX Adaptation and the
Convergence layer. Convergence sublayers.
For example, one instance of the MX Convergence Layer can be MPTCP For example, one instance of the MX Convergence Layer can be MPTCP
Proxy [MPPRoxy] [MPPlain] and another instance can be Trailer based. Proxy [MPProxy] [MPPlain] and another instance can be Trailer-based.
The MX Adaptation for each can be either UDP tunnel or IPsec. IPSec may The MX Adaptation for each can be either UDP tunnel or IPsec. IPSec may
be set up for network paths considered untrusted by the operator, to be set up for network paths considered as untrusted by the operator, to
protect the TCP subflow between client and MPTCP proxy traversing that protect the TCP subflow between client and MPTCP proxy traversing that
network path. network path.
Each of the instances of MAMS user plane, i.e. combination of MX Each of the instances of MAMS user plane, i.e. combination of MX
Convergence and MX Adaptation layer protocols, can coexist Convergence and MX Adaptation layer protocols, can coexist
simultaneously and independently handle different traffic types. simultaneously and independently handle different traffic types.
5 Security Considerations 6 MX Convergence Control
A UDP connection may be configured between C-MADP and N-MADP to
exchange control messages for keep-alive or path quality estimation.
The N-MADP end-point IP address and UDP port number of the UDP
connection is used to identify MX control PDU. Figure 7 shows the MX
control PDU format with the following fields:
o Type (1 Byte): the type of the MX control message
+ 0: Keep-Alive
+ 1: Probe REQ/ACK
+ Others: reserved
o CID (1 Byte): the connection ID of the delivery connection for
sending out the MX control message
o MX Control Message (variable): the payload of the MX control message
Figure 8 shows the MX convergence control protocol stack, and MX
control PDU goes through the MX adaptation sublayer the same way as MX
data PDU.
<----MX Control PDU Payload --------------->
+------------------------------------------------------------------+
| IP header | UDP Header| Type | CID | MX Control Message |
+------------------------------------------------------------------+
Figure 7: MX Control PDU Format
|-----------------------------------------------------|
| MX Convergence Control Messages |
|-----------------------------------------------------|
| UDP/IP |
|-----------------------------------------------------|
| MX Adaptation | MX Adaptation | MX Adaptation |
| Sublayer | Sublayer | Sublayer |
| (optional) | (optional) | (optional) |
|-----------------------------------------------------|
| Access #1 IP | Access #2 IP | Access #3 IP |
+-----------------------------------------------------+
Figure 8: MX Convergence Control Protocol Stack
6.1 Keep-Alive Message
The "Type" field is set to 0 for Keep-Alive messages. C-MADP may send
out Keep-Alive message periodically over one or multiple delivery
connections, especially if UDP tunneling is used as the adaptation
method for the delivery connection with a NAT function on the path.
A Keep-Alive message is 2 bytes long, and consists of the following
fields:
o Keep-Alive Sequence Number (2 Bytes): the sequence number of the
keep-alive message
6.2 Probe REQ/ACK Message
The "Type" field is set to 1 for Probe REQ/ACK messages.
N-MADP may send out the Probe REQ message for path quality estimation.
In response, C-MADP may send back the Probe ACK message.
A Probe REQ message consists of the following fields:
o Probing Sequence Number (2 Bytes): the sequence number of the
Probe REQ message
o Probing Flag (1 Byte):
+ Bit #0: a Probe ACK flag to indicate if the Probe ACK message
is expected (1) or not (0);
+ Bit #1: a Probe Type flag to indicate if the Probe REQ/ACK
message is sent during the initialization phase (0) when the
network path is not included for transmission of user data or
the active phase (1) when the network path is included for
transmission of user data;
+ Bit #2~7: reserved
o Padding (variable)
The "Padding" field is used to control the length of Probe REQ message.
C-MADP SHOULD send out the Probe ACK message in response to a Probe REQ
message with the Probe ACK flag set to "1".
A Probe ACK message is 3 bytes long, and consists of the following
fields:
o Probing Acknowledgement Number (2 Bytes): the sequence number of
the corresponding Probe REQ message
7 Security Considerations
User data in MAMS framework rely on the security of the underlying User data in MAMS framework rely on the security of the underlying
network transport paths. When this cannot be assumed, NCM configures network transport paths. When this cannot be assumed, NCM configures
use of protocols, like IPsec [RFC4301] [RFC3948], for security. use of appropriate protocols for security, e.g. IPsec [RFC4301]
[RFC3948], DTLS [RFC6347].
6 IANA Considerations 8 IANA Considerations
TBD TBD
7 Contributing Authors
9 Contributing Authors
The editors gratefully acknowledge the following additional The editors gratefully acknowledge the following additional
contributors in alphabetical order: Hema Pentakota/Nokia, Satish contributors in alphabetical order: Salil Agarwal/Nokia, Hema
Kanugovi/Nokia. Pentakota/Nokia.
8 References 10 References
8.1 Normative References 10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI10.17487/RFC4301, Internet Protocol", RFC 4301, DOI10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
8.2 Informative References 10.2 Informative References
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January Security Version 1.2", RFC 6347, January
2012,<http://www.rfc-editor.org/info/rfc6347>. 2012,<http://www.rfc-editor.org/info/rfc6347>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
skipping to change at page 8, line 5 skipping to change at page 15, line 17
plain-mode-09.txt plain-mode-09.txt
[MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple [MAMS] S. Kanugovi, S. Vasudevan, F. Baboescu, and J. Zhu, "Multiple
Access Management Protocol", Access Management Protocol",
https://tools.ietf.org/html/draft-kanugovi-intarea-mams- https://tools.ietf.org/html/draft-kanugovi-intarea-mams-
protocol-03 protocol-03
[MAMS_CP] S. Kanugovi, et al., "Control Plane Protocols and [MAMS_CP] S. Kanugovi, et al., "Control Plane Protocols and
Procedures for Multiple Access Management Services" Procedures for Multiple Access Management Services"
[GRE2784] D. Farinacci, et al., "Generic Routing Encapsulation
(GRE)", RFC 2784 March 2000, <http://www.rfc-
editor.org/info/rfc2784>.
[GRE2890] G. Dommety, "Key and Sequence Number Extensions to GRE",
RFC 2890 September 2000, <http://www.rfc-
editor.org/info/rfc2890>.
[IANA] https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml
[LWIPEP] 3GPP TS 36.361, "Evolved Universal Terrestrial Radio Access
(E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec
Tunnel (LWIP) encapsulation; Protocol specification"
[RFC791] Internet Protocol, September 1981
Authors' Addresses Authors' Addresses
Jing Zhu Jing Zhu
Intel Intel
Email: jing.z.zhu@intel.com Email: jing.z.zhu@intel.com
SungHoon Seo SungHoon Seo
Korea Telecom Korea Telecom
Email: sh.seo@kt.com Email: sh.seo@kt.com
Satish Kanugovi
Nokia
Email: satish.k@nokia.com
Shuping Peng
Huawei
Email: pengshuping@huawei.com
 End of changes. 36 change blocks. 
66 lines changed or deleted 422 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/