INTAREA S. Agarwal Internet-Draft S. Kanugovi Intended status: Standards Track Nokia Expires: January 4, 2018 S. Peng Huawei J. Mueller AT&T July 03, 2017 Control Plane Message Definitions for Multiple Access Management Services in JSON draft-agarwal-intarea-mams-protocol-json-00 Abstract Today, a device can be simultaneously connected to multiple communication networks based on different technology implementations and network architectures like WiFi, LTE, DSL. In such multi- connectivity scenario, it is desirable to combine multiple access networks or select the best one to improve quality of experience for a user and improve overall network utilization and efficiency. This document presents the control plane message definitions and their presentations in JSON, for control plane procedures for configuring the user plane in a multi access management services (MAMS) framework that can be used to flexibly select the combination of uplink and downlink access and core network paths, and user plane treatment for improving network efficiency and enhanced application quality of experience. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2018. Agarwal, et al. Expires January 4, 2018 [Page 1] Internet-Draft MAMS C-plane JSON July 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Specification: General Processing . . . . . . . . . 5 4.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 5 4.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Discovery Procedure . . . . . . . . . . . . . . . . . . . 6 4.3.1. MX Discovery Message . . . . . . . . . . . . . . . . 6 4.4. System Information Procedure . . . . . . . . . . . . . . 6 4.4.1. MX System Information Message . . . . . . . . . . . . 6 4.5. Capability Exchange Procedure . . . . . . . . . . . . . . 7 4.5.1. MX Capability Request . . . . . . . . . . . . . . . . 7 4.5.2. MX Capability Response . . . . . . . . . . . . . . . 7 4.5.3. MX Capability Acknowledge . . . . . . . . . . . . . . 8 4.6. User Plane Configuration Procedure . . . . . . . . . . . 8 4.6.1. MX User Plane Configuration Request . . . . . . . . . 8 4.6.2. MX User Plane Configuration Confirmation . . . . . . 9 4.7. Reconfiguration Procedure . . . . . . . . . . . . . . . . 10 4.7.1. Reconfiguration Request . . . . . . . . . . . . . . . 10 4.7.2. Reconfiguration Response . . . . . . . . . . . . . . 10 4.8. Path Estimation Procedure . . . . . . . . . . . . . . . . 11 4.8.1. Path Estimation Request . . . . . . . . . . . . . . . 11 4.8.2. Path Estimation Report . . . . . . . . . . . . . . . 12 4.9. Traffic Steering Procedure . . . . . . . . . . . . . . . 12 4.9.1. Traffic Steering Request . . . . . . . . . . . . . . 12 4.9.2. Traffic Steering Response . . . . . . . . . . . . . . 13 4.10. SSID Indication . . . . . . . . . . . . . . . . . . . . . 13 4.11. Measurements . . . . . . . . . . . . . . . . . . . . . . 13 4.11.1. Measurement Configuration . . . . . . . . . . . . . 13 4.11.2. Measurement Report . . . . . . . . . . . . . . . . . 14 4.12. Keep Alive . . . . . . . . . . . . . . . . . . . . . . . 14 Agarwal, et al. Expires January 4, 2018 [Page 2] Internet-Draft MAMS C-plane JSON July 2017 4.12.1. Keep Alive Request . . . . . . . . . . . . . . . . . 14 4.12.2. Keep Alive Response . . . . . . . . . . . . . . . . 15 4.13. Session Termination Procedure . . . . . . . . . . . . . . 15 4.13.1. Session Terminate Request . . . . . . . . . . . . . 15 4.13.2. Session Terminate Response . . . . . . . . . . . . . 16 5. Protocol Specification: Data Types . . . . . . . . . . . . . 16 5.1. MXBase . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Unique Session Id . . . . . . . . . . . . . . . . . . . . 17 5.3. NCM Connections . . . . . . . . . . . . . . . . . . . . . 17 5.4. Connection Information . . . . . . . . . . . . . . . . . 18 5.5. Features Activation Status . . . . . . . . . . . . . . . 18 5.6. Anchor Connections . . . . . . . . . . . . . . . . . . . 19 5.7. Delivery Connections . . . . . . . . . . . . . . . . . . 19 5.8. Method Support . . . . . . . . . . . . . . . . . . . . . 19 5.9. Convergence Methods . . . . . . . . . . . . . . . . . . . 20 5.10. Adaptation Methods . . . . . . . . . . . . . . . . . . . 20 5.11. Setup of Anchor Connections . . . . . . . . . . . . . . . 20 5.11.1. Convergence Method Parameters . . . . . . . . . . . 21 5.11.2. Setup Delivery Connections . . . . . . . . . . . . . 21 5.12. Init Probe Results . . . . . . . . . . . . . . . . . . . 22 5.13. Active Probe Results . . . . . . . . . . . . . . . . . . 22 5.14. Downlink Delivery . . . . . . . . . . . . . . . . . . . . 23 5.15. Uplink Delivery . . . . . . . . . . . . . . . . . . . . . 23 5.16. Traffic Flow Template . . . . . . . . . . . . . . . . . . 23 5.17. Measurement Report Configuration . . . . . . . . . . . . 24 5.18. Measurement Report . . . . . . . . . . . . . . . . . . . 25 6. Schemas in JSON . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. MX Base Schema . . . . . . . . . . . . . . . . . . . . . 26 6.2. MX Definitions . . . . . . . . . . . . . . . . . . . . . 26 6.3. MX Discover . . . . . . . . . . . . . . . . . . . . . . . 31 6.4. MX System Update . . . . . . . . . . . . . . . . . . . . 31 6.5. MX Capability Request . . . . . . . . . . . . . . . . . . 32 6.6. MX Capability Response . . . . . . . . . . . . . . . . . 33 6.7. MX Capability Ack . . . . . . . . . . . . . . . . . . . . 34 6.8. MX Reconfiguration Request . . . . . . . . . . . . . . . 35 6.9. MX Reconfiguration Response . . . . . . . . . . . . . . . 36 6.10. MX UP Setup Configuration . . . . . . . . . . . . . . . . 37 6.11. MX UP Setup Confirmation . . . . . . . . . . . . . . . . 38 6.12. MX Traffic Steering Request . . . . . . . . . . . . . . . 39 6.13. MX Traffic Steering Response . . . . . . . . . . . . . . 40 6.14. MX Path Estimation Request . . . . . . . . . . . . . . . 41 6.15. MX Path Estimation Report . . . . . . . . . . . . . . . . 42 6.16. MX SSID Indication . . . . . . . . . . . . . . . . . . . 43 6.17. MX Measurements Configuration . . . . . . . . . . . . . . 44 6.18. MX Measurements Report . . . . . . . . . . . . . . . . . 45 6.19. MX Keep Alive Request . . . . . . . . . . . . . . . . . . 47 6.20. MX Keep Alive Response . . . . . . . . . . . . . . . . . 47 6.21. MX Session Termination Request . . . . . . . . . . . . . 47 Agarwal, et al. Expires January 4, 2018 [Page 3] Internet-Draft MAMS C-plane JSON July 2017 6.22. MX Session Termination Response . . . . . . . . . . . . . 48 7. Examples in JSON . . . . . . . . . . . . . . . . . . . . . . 48 7.1. MX Discover . . . . . . . . . . . . . . . . . . . . . . . 48 7.2. MX System Update . . . . . . . . . . . . . . . . . . . . 49 7.3. MX Capability Request . . . . . . . . . . . . . . . . . . 49 7.4. MX Capability Response . . . . . . . . . . . . . . . . . 51 7.5. MX Capacity Ack . . . . . . . . . . . . . . . . . . . . . 52 7.6. MX Reconfiguration Request . . . . . . . . . . . . . . . 52 7.7. MX Reconfiguration Response . . . . . . . . . . . . . . . 53 7.8. MX UP Setup Configuration Request . . . . . . . . . . . . 53 7.9. MX UP Setup Confirmation . . . . . . . . . . . . . . . . 54 7.10. MX Traffic Steering Request . . . . . . . . . . . . . . . 55 7.11. MX Traffic Steering Response . . . . . . . . . . . . . . 57 7.12. MX Path Estimation Request . . . . . . . . . . . . . . . 57 7.13. MX Path Estimation Results . . . . . . . . . . . . . . . 58 7.14. MX SSID Indication . . . . . . . . . . . . . . . . . . . 58 7.15. MX Measurements Configuration . . . . . . . . . . . . . . 59 7.16. MX Measurements Report . . . . . . . . . . . . . . . . . 60 7.17. MX Keep Alive Request . . . . . . . . . . . . . . . . . . 62 7.18. MX Keep Alive Response . . . . . . . . . . . . . . . . . 62 7.19. MX Session Termination Request . . . . . . . . . . . . . 62 7.20. MX Session Termination Response . . . . . . . . . . . . . 62 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 63 9.2. Informative References . . . . . . . . . . . . . . . . . 63 Appendix A. Implementation Example . . . . . . . . . . . . . . . 64 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction Multi Access Management Service (MAMS) [I-D.kanugovi-intarea-mams-protocol] is a framework to select and configure network paths when multiple connections can serve a client device. It allows the path selection and configuration to adapt to dynamic network conditions. It is based on principles of user plane interworking that enables the solution to be deployed as an overlay without impacting the underlying networks. This document presents the JSON based definitions for control plane messages for the MAMS framework. The control plane messages for which have been defined in [I-D.zhu-intarea-mams-control-protocol]. Agarwal, et al. Expires January 4, 2018 [Page 4] Internet-Draft MAMS C-plane JSON July 2017 3. Terminology "Anchor Connection": Refers to the network path from the N-MADP to the Application Server that corresponds to a specific IP anchor that has assigned an IP address to the client. "Delivery Connection": Refers to the network path from the N-MADP to the client. "Network Connection Manager" (NCM), "Client Connection Manager" (CCM), "Network Multi Access Data Proxy" (N-MADP), and "Client Multi Access Data Proxy" (C-MADP) in this document are to be interpreted as described in [I-D.kanugovi-intarea-mams-protocol]. 4. Protocol Specification: General Processing 4.1. Overall Design Control plane messages for MAMS are exchanged between the CCM and NCM over WebSocket, the content of messages is defined in "Java Script Object Notation" (JSON) format. 4.2. Notation This document uses JSONString, JSONNumber, and JSONBool to indicate the JSON string, number, and boolean types, respectively. The type JSONValue indicates a JSON value, as specified in Section 3 of [RFC7159]. This document uses an adaptation of the C-style struct notation to define JSON objects. A JSON object consists of name/value pairs. This document refers to each pair as a field. In some context, this document also refers to a field as an attribute. The name of a field/attribute may be referred to as the key. An optional field is enclosed by [ ]. In the definitions, the JSON names of the fields are case sensitive. An array is indicated by two numbers in angle brackets, <m..n>, where m indicates the minimal number of values and n is the maximum. When this document uses * for n, it means no upper bound. For example, the definition below defines a new type Type4, with three fields named "name1", "name2", and "name3", respectively. The field named "name3" is optional, and the field named "name2" is an array of at least one value. object { Type1 name1; Type2 name2<1..*>; [Type3 name3;] } Type4; Agarwal, et al. Expires January 4, 2018 [Page 5] Internet-Draft MAMS C-plane JSON July 2017 This document uses subtyping to denote that one type is derived from another type. The example below denotes that TypeDerived is derived from TypeBase. TypeDerived includes all fields defined in TypeBase. If TypeBase does not have a field named "name1", TypeDerived will have a new field named "name1". If TypeBase already has a field named "name1" but with a different type, TypeDerived will have a field named "name1" with the type defined in TypeDerived (i.e., Type1 in the example). object { Type1 name1; } TypeDerived : TypeBase; Note that, despite the notation, no standard, machine-readable interface definition or schema is provided in this document. Extension documents may describe these as necessary. 4.3. Discovery Procedure 4.3.1. MX Discovery Message This message is the first message sent by CCM to discover the presence of NCM in the network. It contains only the base information as described in Section 5.1 with message_type set as mx_discover. Following is the representation of the message: object { } MXDiscover : MXBase; 4.4. System Information Procedure 4.4.1. MX System Information Message This message is sent by NCM to CCM to inform the endpoints that NCM supports for MAMS functionality. In addition to base information (Section 5.1) it contains following information: a) NCM Connections (described in Section 5.3) Following is the representation of the message: object { NCMConnections ncm_connections; } MXSystemInfo : MXBase; Agarwal, et al. Expires January 4, 2018 [Page 6] Internet-Draft MAMS C-plane JSON July 2017 4.5. Capability Exchange Procedure 4.5.1. MX Capability Request This message is sent by CCM to NCM to indicate the capabilities of the CCM instance available to the NCM indicated in System Info message earlier. In addition to base information (Section 5.1) it contains following information: (a) Features Activation Status: Described in Section 5.5 (b) Number of anchor connections: Number of anchor connection (towards core) supported by the NCM. (c) Anchor Connections: Described in sec Section 5.6 (d) Number of Delivery connections: Number of delivery connection (towards access) supported by the NCM. (e) Delivery Connections: Described in Section 5.7 (f) Convergence Methods: Described in Section 5.9 (g) Adaptation Methods: Described in Section 5.10 Following is the representation of the message: object { FeaturesActive feature_active; JSONNumber num_anchor_connections; AnchorConnections anchor_connections; JSONNumber num_delivery_connections; DeliveryConnections delivery_connections; ConvergenceMethods convergence_methods; AdaptationMethods adaptation_methods } MXCapabilityReq : MXBase; 4.5.2. MX Capability Response This message is sent by NCM to CCM to indicate the capabilities of the NCM instance and unique session identifier for CCM. In addition to base information (Section 5.1) it contains following information: (a) Features Activation Status: Described in Section 5.5 (b) Number of anchor connections: Number of anchor connection (towards core) supported by the NCM. (c) Anchor Connections: Described in Section 5.6 (d) Number of Delivery connections: Number of delivery connection (towards access) supported by the NCM. (e) Delivery Connections: Described in Section 5.7 (f) Convergence Methods: Described in Section 5.9 (g) Adaptation Methods: Described in Section 5.10 (h) Unique Session Id: This uniquely identifies the session between CCM and NCM in a network. Described in Section 5.2 Agarwal, et al. Expires January 4, 2018 [Page 7] Internet-Draft MAMS C-plane JSON July 2017 Following is the representation of the message: object { FeaturesActive feature_active; JSONNumber num_anchor_connections; AnchorConnections anchor_connections; JSONNumber num_delivery_connections; DeliveryConnections delivery_connections; ConvergenceMethods convergence_methods; AdaptationMethods adaptation_methods UniqueSessionId unique_session_id; } MXCapabilityRsq : MXBase; 4.5.3. MX Capability Acknowledge This message is sent by CCM to NCM to indicate acceptance of capabilities advertised by NCM in earlier MX Capability Response message. In addition to base information (Section 5.1) it contains following information: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Section 5.2. (b) Capability Acknowledgement: Either Accept or Reject of the capabilities sent by CCM. Can take either "MX_ACCEPT" or "MX_REJECT" as acceptable values. Following is the representation of the message: object { UniqueSessionId unique_session_id; JSONString capability_ack; } MXCapabilityAck : MXBase; 4.6. User Plane Configuration Procedure 4.6.1. MX User Plane Configuration Request This message is sent by NCM to CCM to configure the user plane for MAMS. In addition to base information (Section 5.1) it contains following information: (a) Number of Anchor Connection: Number of anchor connections supported by NCM. (b) Setup of Anchor Connections: Described in Section 5.11. Following is the representation of the message: object { Agarwal, et al. Expires January 4, 2018 [Page 8] Internet-Draft MAMS C-plane JSON July 2017 JSONNumber num_anchor_connections; SetupAnchorConns anchor_connections; } MXUPSetupConfigReq : MXBase; 4.6.2. MX User Plane Configuration Confirmation This message is the confirmation of user plane setup message sent from CCM after successfully configuring the user plane at user equipment. This message contains following information: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Section 5.2. (b) MX Probe Parameters (included if probing is supported) (1) Probe Port: UDP port for accepting probe message. (c) For each delivery connection following is required: (1) Connection ID: Delivery connection id supported by UE. (2) Client Adaptation Layer Parameters: If UDP adaptation layer is in use then the UDP port to be used at C-MADP side. Following is the representation of the message: object { UniqueSessionId unique_session_id; [ProbeParam probe_param;] JSONNumber num_delivery_conn; ClientParam client_params <1...*>; } MXUPSetupConfigCnf : MXBase; Where ProbeParam is defined as following: object { JSONNumber probe_port; } ProbeParam; Where ClientParam is defined as following: object { JSONNumber connection_id; [AdaptationParam adapt_param;] } ClientParam; Where AdaptationParam is defined as following: object { JSONNumber udp_adapt_port; } AdaptationParam; Agarwal, et al. Expires January 4, 2018 [Page 9] Internet-Draft MAMS C-plane JSON July 2017 4.7. Reconfiguration Procedure 4.7.1. Reconfiguration Request This message is sent by CCM to NCM in case of reconfiguration of any the connections from user equipment’s side. In addition to base information (Section 5.1) it contains following information: (a) Unique Session Id: Identifier for CCM-NCM association Section 5.2. (b) Reconfiguration Action: Type of reconfiguration action can be one of "setup", "release" or "modify". (c) Connection Id: Connection Id for which the reconfiguration is taking place. (d) IP address: IP address in case of setup and modify type of reconfiguration. (e) SSID: If the connection type is WiFi, in that case the SSID the UE has attached to is contained in this parameter. (f) MTU of connection: MTU of the delivery path that is calculated at the UE for use by NCM to configure fragmentation and concatenation procedures at N-MADP. (g) Connection Status: This parameter informs if the connection is currently "disabled", "enabled" or "connected". Default: "connected". (h) Delivery Node Id: Identity of the node to which the client is attached. ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi. Following is the representation of the message: object { UniqueSessionId unique_session_id; JSONString reconf_action; JSONNumber connection_id; JSONString ip_address; JSONString ssid; JSONNumber mtu_size; JSONString connection_status; [JSONSring delivery_node_id;] } MXReconfReq : MXBase; 4.7.2. Reconfiguration Response This message is sent by NCM to CCM as a confirmation towards reconfiguration requirement after taking the reconfiguration into use and contains only the base information (as defined in Section 5.1). Following is the representation of the message:] Agarwal, et al. Expires January 4, 2018 [Page 10]