| < draft-zhu-intarea-gma-control-00.txt | draft-zhu-intarea-gma-control-01.txt > | |||
|---|---|---|---|---|
| Network Working Group J. Zhu | Network Working Group J. Zhu | |||
| Internet Draft M. Zhang | Internet Draft M. Zhang | |||
| Intended status: Experimental Intel | Intended status: Experimental Intel | |||
| Expires: April 13,2022 | Expires: October 11,2022 | |||
| October 13, 2021 | April 11, 2022 | |||
| UDP-based Generic Multi-Access (GMA) Control Protocol | UDP-based Generic Multi-Access (GMA) Control Protocol | |||
| draft-zhu-intarea-gma-control-00 | draft-zhu-intarea-gma-control-01 | |||
| Abstract | Abstract | |||
| A device can be simultaneously connected to multiple networks, | A device can be simultaneously connected to multiple networks, | |||
| e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly | e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly | |||
| combine the connectivity over these networks below the transport | combine the connectivity over these networks below the transport | |||
| layer (L4) to improve quality of experience for applications that | layer (L4) to improve quality of experience for applications that | |||
| do not have built in multi-path capabilities. This document | do not have built in multi-path capabilities. This document | |||
| presents a new control protocol to manage traffic steering, | presents a new control protocol to manage traffic steering, | |||
| splitting, and duplicating across multiple connections. The | splitting, and duplicating across multiple connections. The | |||
| skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
| months and may be updated, replaced, or obsoleted by other | months and may be updated, replaced, or obsoleted by other | |||
| documents at any time. It is inappropriate to use Internet-Drafts | documents at any time. It is inappropriate to use Internet-Drafts | |||
| as reference material or to cite them other than as "work in | as reference material or to cite them other than as "work in | |||
| progress." | 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 April 13, 2022. | This Internet-Draft will expire on October 11, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 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 | |||
| carefully, as they describe your rights and restrictions with | carefully, as they describe your rights and restrictions with | |||
| respect to this document. Code Components extracted from this | respect to this document. Code Components extracted from this | |||
| document must include Simplified BSD License text as described in | document must include Simplified BSD License text as described in | |||
| Section 4.e of the Trust Legal Provisions and are provided without | Section 4.e of the Trust Legal Provisions and are provided without | |||
| warranty as described in the Simplified BSD License. | warranty as described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction ................................................. 2 | 1. Introduction ................................................. 2 | |||
| 1.1. Scope of Experiment ....................................4 | 1.1. Scope of Experiment ....................................4 | |||
| 2. Conventions used in this document ............................ 5 | 2. Conventions used in this document ............................ 5 | |||
| 3. Use Case ..................................................... 5 | 3. Use Case ..................................................... 5 | |||
| 4. UDP-based GMA Encapsulation Protocol ......................... 6 | 4. UDP-based GMA Encapsulation Protocol ......................... 6 | |||
| 5. GMA Control Messages ......................................... 9 | 5. GMA Control Messages ......................................... 9 | |||
| 5.1 Probe Message ........................................10 | 5.1 Probe Message .........................................9 | |||
| 5.2 Acknowledgement (ACK) Message ........................11 | 5.2 Acknowledgement (ACK) Message ........................10 | |||
| 5.3 Traffic Splitting Update (TSU) Message ...............11 | 5.3 Traffic Splitting Update (TSU) Message ...............11 | |||
| 5.4 Traffic Splitting Acknowledgement (TSA) Message ......13 | 5.4 Traffic Splitting Acknowledgement (TSA) Message ......12 | |||
| 5.5 Timestamp Reset Request (TSR) Message ................14 | 5.5 Timestamp Reset Request (TSR) Message ................14 | |||
| 6. GMA Control Flows ........................................... 15 | 6. GMA Control Flows ........................................... 14 | |||
| 6.1. Initialization ........................................15 | 6.1. Initialization ........................................14 | |||
| 6.2. GMA Operation .........................................16 | 6.2. GMA Operation .........................................15 | |||
| 6.3. Termination ...........................................17 | 6.3. Termination ...........................................17 | |||
| 7. Security Considerations ..................................... 18 | 7. Security Considerations ..................................... 17 | |||
| 8. IANA Considerations ......................................... 18 | 8. IANA Considerations ......................................... 18 | |||
| 9. References .................................................. 18 | 9. References .................................................. 18 | |||
| 9.1. Normative References ..................................18 | 9.1. Normative References ..................................18 | |||
| 9.2. Informative References ................................18 | 9.2. Informative References ................................18 | |||
| 1. Introduction | 1. Introduction | |||
| A device can be simultaneously connected to multiple networks, | A device can be simultaneously connected to multiple networks, | |||
| e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly | e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly | |||
| combine the connectivity over these networks below the transport | combine the connectivity over these networks below the transport | |||
| skipping to change at page 7, line 15 ¶ | skipping to change at page 7, line 15 ¶ | |||
| the MAMS message (MX UP Setup Config) [MAMS]. | the MAMS message (MX UP Setup Config) [MAMS]. | |||
| +------------------------------------------------+ | +------------------------------------------------+ | |||
| | IP hdr | UDP hdr | GMA Header | Payload | | | IP hdr | UDP hdr | GMA Header | Payload | | |||
| +------------------------------------------------+ | +------------------------------------------------+ | |||
| Figure 4: UDP-based GMA PDU Format | Figure 4: UDP-based GMA PDU Format | |||
| The GMA (Generic Multi-Access) header MUST consist of the | The GMA (Generic Multi-Access) header MUST consist of the | |||
| mandatory "Flags" field (the first two bytes), defined as follows: | mandatory "Flags" field (the first two bytes), defined as follows: | |||
| o Payload Type (bit 0): to indicate the GMA PDU payload type | o Client ID Present (bit 0): If the Client ID Present bit is set | |||
| + 0: control message | ||||
| + 1: user-plane message | ||||
| o Client ID Present (bit 1): If the Client ID Present bit is set | ||||
| to 1, then the Client ID field is present | to 1, then the Client ID field is present | |||
| o Slice ID Present (bit 2): if the Slice ID Present bit is set, to | o Flow ID Present (bit 1): If the Flow ID Present bit is set to 1, | |||
| 1, then the Slice ID field is present | ||||
| o Connection ID Present (bit 3): If the Connection ID Present bit | ||||
| is set to 1, then the Connection ID field is present | ||||
| o Flow ID Present (bit 4): If the Flow ID Present bit is set to 1, | ||||
| then the Flow ID field is present | then the Flow ID field is present | |||
| o Per-Packet Priority (PPP) Present (bit 5): If the PPP Present | o Per-Packet Priority (PPP) Present (bit 2): If the PPP Present | |||
| bit is set to 1, then the PPP field is present | bit is set to 1, then the PPP field is present | |||
| o Delivery SN Present (bit 6): If the Delivery SN (Sequence | o SN Present (bit 3): If the SN (Sequence Number) Present bit is | |||
| Number) Present bit is set to 1, then the Delivery SN field is | set to 1, then the Delivery and Flow SN fields are present and | |||
| present and contains the valid information | contains the valid information | |||
| o Flow SN Present (bit 7): If the Flow SN Present bit is set to 1, | o Timestamp Present (bit 4): If the Timestamp Present bit is set | |||
| then the Sequence Number field is present | ||||
| o Timestamp Present (bit 8): If the Timestamp Present bit is set | ||||
| to 1, then the Timestamp field is present | to 1, then the Timestamp field is present | |||
| o Concatenation Present (bit 9): If the Concatenation Present bit | o Reserved (bit 5-15): set to "0" and ignored on receipt | |||
| is set to 1, then the PDU carries multiple SDUs | ||||
| o Reserved (bit 10-15): set to "0" and ignored on receipt | ||||
| Bit 0 is the most significant bit (MSB), and Bit 15 is the least | Bit 0 is the most significant bit (MSB), and Bit 15 is the least | |||
| significant bit (LSB). | significant bit (LSB). | |||
| The Receiver SHOULD first decode the Flags field to determine the | The Receiver SHOULD first decode the Flags field to determine the | |||
| length of the GMA header, and then decode each optional field | length of the GMA header, and then decode each optional field | |||
| accordingly. The GMA (Generic Multi-Access) header MAY consist of | accordingly. The GMA (Generic Multi-Access) header MAY consist of | |||
| the following optional fields: | the following optional fields: | |||
| o Client ID (2 Byte): an unsigned integer to identify the client | o Client ID (2 Byte): an unsigned integer to identify the client | |||
| o Slice ID (1 Byte): an unsigned integer to identify the network | ||||
| slice of the GMA SDU | ||||
| o Connection ID (1 Byte): an unsigned integer to identify the | ||||
| anchor connection of the GMA SDU. | ||||
| o Flow ID (1 Byte): an unsigned integer to identify the IP flow | o Flow ID (1 Byte): an unsigned integer to identify the IP flow | |||
| of the GMA SDU. | of the GMA SDU. | |||
| o Per-Packet Priority (1 Byte): an unsigned integer to identify | o Per-Packet Priority (1 Byte): an unsigned integer to identify | |||
| the relative priority of the GMA SDU in the flow (smaller | the relative priority of the GMA SDU in the flow (smaller | |||
| value means higher priority). | value means higher priority). | |||
| o Delivery SN (1 Byte): an auto-incremented integer to indicate | o Delivery SN (1 Byte): an auto-incremented integer to indicate | |||
| the GMA PDU transmission order on a delivery connection. | the GMA PDU transmission order on a delivery connection. | |||
| Delivery SN is used to measure packet loss of each delivery | Delivery SN is used to measure packet loss of each delivery | |||
| connection and therefore generated per delivery connection | connection and therefore generated per delivery connection | |||
| per flow. This field is present only if the Delivery SN | per flow. This field is present only if the Delivery SN | |||
| skipping to change at page 8, line 38 ¶ | skipping to change at page 8, line 22 ¶ | |||
| and the order of the GMA control fields SHALL follow the bit order | and the order of the GMA control fields SHALL follow the bit order | |||
| in the Flags field. Note that the bits in the Flags field are | in the Flags field. Note that the bits in the Flags field are | |||
| ordered with the first bit transmitted being bit 0 (MSB). All | ordered with the first bit transmitted being bit 0 (MSB). All | |||
| fields are transmitted in regular network byte order and appear in | fields are transmitted in regular network byte order and appear in | |||
| order to their corresponding flag bits. If a flag bit is clear, | order to their corresponding flag bits. If a flag bit is clear, | |||
| the corresponding optional field is absent. | the corresponding optional field is absent. | |||
| 0 1 2 3 | 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | reserved | Client ID | | | Flags | reserved | Client ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Slice ID | Conn ID | Flow ID | PPP | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Delivery SN | Flow SN | | | Flow ID | PPP | Delivery SN | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Timestamp | | Flow SN | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Timestamp | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 5: GMA Header Format with all Optional Fields Present | Figure 5: GMA Header Format with all Optional Fields Present | |||
| Some GMA header fields, e.g. Slice ID, Conn ID, Flow ID, and PPP | Some GMA header fields, e.g. Client ID, Flow ID, and PPP are | |||
| are designed to support hierarchical QoS (hQoS) and fine granular | designed to support hierarchical QoS (hQoS) and fine granular | |||
| packet classification. Notice that GMA header fields (unlike IP | packet classification. Notice that GMA header fields (unlike IP | |||
| header field) won't change regardless how a GMA PDU is delivered | header field) won't change regardless how a GMA PDU is delivered | |||
| on the way, since they are encapsulated as part of UDP payload. | on the way, since they are encapsulated as part of UDP payload. | |||
| Therefore, an intermediate node, e.g. router, Access Point, Base | Therefore, an intermediate node, e.g. router, Access Point, Base | |||
| Station, etc., can perform hQoS scheduling and active queue | Station, etc., can perform hQoS scheduling and active queue | |||
| management (AQM) directly based on these GMA header fields without | management (AQM) directly based on these GMA header fields without | |||
| additional packet classification processing. | additional packet classification processing. | |||
| Other GMA header fields, e.g. Delivery SN, Flow SN, and Timestamp, | Other GMA header fields, e.g. Delivery SN, Flow SN, and Timestamp, | |||
| are designed to support multi-access traffic management. For | are designed to support multi-access traffic management. For | |||
| example, Flow SN allows reordering at the receiver when a flow is | example, Flow SN allows reordering at the receiver when a flow is | |||
| split over multiple connections. In the meantime, Delivery SN is | split over multiple connections. In the meantime, Delivery SN is | |||
| needed for packet loss measurement per delivery connection, and | needed for packet loss measurement per delivery connection, and | |||
| Timestamp allows one-way-delay measurement, which can then be used | Timestamp allows one-way-delay measurement, which can then be used | |||
| to detect congestion and buffer overflow at intermediate nodes. | to detect congestion and buffer overflow at intermediate nodes. | |||
| If concatenation is supported, a GMA PDU MAY carry multiple GMA | ||||
| SDUs with the same Slice ID, Connection ID, Flow ID, and PPP. | ||||
| However, concatenation is only applicable to IP-based virtual | ||||
| (anchor) connection. Please refer to [GMAE] for more details on | ||||
| concatenation. | ||||
| 5. GMA Control Messages | 5. GMA Control Messages | |||
| A GMA control message is encapsulated as the payload of a GMA PDU | A GMA control message is encapsulated as the payload of a GMA PDU | |||
| (see Figure 4) and indicated by setting Bit 0 in the Flags field | (see Figure 4) and the GMA header MUST include the Client ID | |||
| of the GMA header to 0. Moreover, the GMA header MUST include the | field, but not any other optional fields. As a result, the Flag in | |||
| Client ID field, but not any other optional fields. As a result, | the GMA header is always set to 0x8000 for a GMA control message. | |||
| the Flag in the GMA header is always set to 0x4000 for a GMA | ||||
| control message. | ||||
| GMA control message MAY be encrypted with a symmetric key cipher, | GMA control message MAY be encrypted with a symmetric key cipher, | |||
| e.g. AES256-GCM. If a GMA control message is encrypted, the | e.g. AES256-GCM. If a GMA control message is encrypted, the | |||
| receiver will use the Client ID field to obtain the corresponding | receiver will use the Client ID field to obtain the corresponding | |||
| key for decryption. Notice that only the GMA control message is | key for decryption. Notice that only the GMA control message is | |||
| encrypted. The GMA header is authenticated but not encrypted. | encrypted. The GMA header is authenticated but not encrypted. | |||
| Figure 6 shows the format of an encrypted GMA control message, | Figure 6 shows the format of an encrypted GMA control message, | |||
| where IV (initialization vector) is 12 bytes long and GCM Tag is | where IV (initialization vector) is 12 bytes long and GCM Tag is | |||
| 16 bytes long. The GMA header (Flag (2B) + Client ID (2B)) is used | 16 bytes long. The GMA header (Flag (2B) + Client ID (2B)) is used | |||
| as additional authenticated data (AAD). | as additional authenticated data (AAD). | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| |Flag(0x4000) | Client ID | GMA control message | GCM Tag | IV | | |Flag(0x8000) | Client ID | GMA control message | GCM Tag | IV | | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| |<------authenticated---->|<----encrypted ----->| | |<------authenticated---->|<----encrypted ----->| | |||
| Figure 6: Encrypted GMA Control Message | Figure 6: Encrypted GMA Control Message | |||
| A GMA control message consists of the following fields: | A GMA control message consists of the following fields: | |||
| o Header (2 Bytes) | o Header (2 Bytes) | |||
| + Type (1 Byte): the GMA control message type | + Type (1 Byte): the GMA control message type | |||
| + Connection ID (1 Byte): an unsigned integer to identify | + Connection ID (1 Byte): an unsigned integer to identify | |||
| the anchor connection for the GMA control message | the anchor connection for the GMA control message | |||
| o Payload (variable): the payload of the GMA control message | o Payload (variable): the payload of the GMA control message | |||
| 5.1 Probe Message | 5.1 Probe Message | |||
| The "Type" field is set to "1" for Probe messages. | The "Type" field is set to "1" for Probe messages. | |||
| Client (or multi-access gateway) may send out Probe message for | Client (or multi-access gateway) may send out Probe message for | |||
| path quality estimation or keepalive. In response, multi-access | path quality estimation or keepalive. In response, multi-access | |||
| gateway (or client) may send back the ACK message. | gateway (or client) may send back the ACK message. | |||
| 0 1 2 3 | 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Sequence Number | LS Bitmap | Probing Flag | | | Sequence Number | LS Bitmap | Probing Flag | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Timestamp | | | Timestamp | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Padding | | | Padding | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 7: Probe Message Format | Figure 7: Probe Message Format | |||
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| A Probe message consists of the following fields: | A Probe message consists of the following fields: | |||
| o Sequence Number (2 Bytes): the sequence number of the message | o Sequence Number (2 Bytes): the sequence number of the message | |||
| o Link Status (LS) Bitmap (1 Bytes): to indicate the status (0: | o Link Status (LS) Bitmap (1 Bytes): to indicate the status (0: | |||
| not connected; 1: connected) of the i-th delivery connection, | not connected; 1: connected) of the i-th delivery connection, | |||
| where connections are ordered according to their Connection ID, | where connections are ordered according to their Connection ID, | |||
| bit #7 (LSB) corresponds to the 1st delivery connection and bit | bit #7 (LSB) corresponds to the 1st delivery connection and bit | |||
| #0 (MSB) corresponds to the 8th delivery connection. | #0 (MSB) corresponds to the 8th delivery connection. | |||
| End of changes. 25 change blocks. | ||||
| 65 lines changed or deleted | 42 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||