Internet Engineering Task Force P. Fan Internet-Draft H. Deng Intended status: Informational China Mobile Expires: April 30, 2015 October 27, 2014 HTTP based flow characteristic signaling draft-fan-flow-characteristic-signaling-00 Abstract This document describes an HTTP based flow characteristic signaling mechanism to enable explicit information exchange between applications and the network. 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 April 30, 2015. Copyright Notice Copyright (c) 2014 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. Fan & Deng Expires April 30, 2015 [Page 1] Internet-Draft HTTP Flow Characteristic Signaling October 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. AECON . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Flow Characteristics . . . . . . . . . . . . . . . . . . . . 4 4. Signaling Operation . . . . . . . . . . . . . . . . . . . . . 6 4.1. Flow characteristic creation . . . . . . . . . . . . . . 6 4.2. Flow characteristic modification . . . . . . . . . . . . 8 4.3. Flow characteristic deletion . . . . . . . . . . . . . . 9 5. Error Reporting . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Consideration . . . . . . . . . . . . . . . . . . . 10 6.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Signaling misuse . . . . . . . . . . . . . . . . . . . . 11 7. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Identification and treatment of application flows are important to many application providers and network operators. Problems faced by existing solutions that try to provide such visibility and to enable appropriate treatment of application flows are described in [I-D.conet-aeon-problem-statement]. There is a growing need for mechanisms to allow applications and the network to explicitly exchange information to help flow identification and treatment. A set of use cases addressable by this explicit information exchange is described in [I-D.conet-aeon-use-cases]. This documents describes an HTTP [RFC2616] based mechanism to enable active flow characteristic signaling so that application and network can better coordinate with each other in a collaborative way. As the pervasive implementation of HTTP protocol in applications, this documents aims to provide a signaling mechanism which can be easily developed and integrated by application developers. 2. Terminology The section clarifies the intended meaning of specific terms used within 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]. Fan & Deng Expires April 30, 2015 [Page 2] Internet-Draft HTTP Flow Characteristic Signaling October 2014 2.1. AECON The following terms are defined in [I-D.conet-aeon-requirements]: o 5-tuple o Application o Flow characteristics o Network node 2.2. HTTP The following terms are defined in [RFC2616]: o Request o Response o Message o Status code o Message body 2.3. OAuth The following terms are defined in [RFC6749]: o Resource Owner o Resource Server o Authorization Server o Access Token 2.4. Terms The following terms are used within this document: o Client: a program which signals flow characteristics carried by HTTP request messages to a server, and receives feedback from the server. The client is typically implemented in an application. o Server: a program which receives and parses flow characteristics signalled by a client, interacts with network node to change Fan & Deng Expires April 30, 2015 [Page 3] Internet-Draft HTTP Flow Characteristic Signaling October 2014 forwarding behaviour of the flow, and sends feedback carried by HTTP response messages to the client. A server can be integrated in a network node or a dedicated device. 3. Flow Characteristics Flow characteristic contains the information used to identify of an individual application flow and express anticipated network resource for the flow. The following specifies attributes contributing to flow characteristic. Fan & Deng Expires April 30, 2015 [Page 4] Internet-Draft HTTP Flow Characteristic Signaling October 2014 ----------------------------------------------------------------------- attribute type description ----------------------------------------------------------------------- flow_id uint64 The ID of the signaled flow characteristic. This value is assigned by the server, and used to distinguish from other flow characteristics. created_at string A date and time value showing the time when the flow characteristic comes into effect, after flow characteristic is received by the server and appropriate treatment is applied to the flow. This value is set by the server. expire_at string A date and time value showing the lifetime of the flow characteristic. This value can be set by both client and server: client can use it to express expected lifetime, and server can set the final decision on the lifetime. flow_ object A set of definition information provided by the description client to help network nodes identify the application flow. local_ipv4 string The local IPv4 address of the application flow. local_ipv6 string The local IPv6 address of the application flow. remote_ipv4 string The remote IPv4 address of the application flow. remote_ipv6 string The remote IPv6 address of the application flow. local_port string The local port of the application flow. remote_port string The remote port of the application flow. transport_ string The transport protocol used to transport the protocol application flow. flow_ object A set of information provided by the client showing treatment the expected flow treatment, or provided by the server showing how the flow will actually be treated by network nodes. relative_ uint8 The expected or guaranteed flow priority among priority other flows of the application. The value indicates priority order. bandwidth uint32 The expected or guaranteed maximum bandwidth for the application flow. The unit of this value is kbps. delay uint16 The expected or guaranteed maximum delay for the application flow. The unit of this value is microsecond. jitter uint16 The expected or guaranteed maximum jitter for the application flow. The unit of this value is microsecond. packet_loss float The expected or guaranteed maximum packet loss rate for the application flow. The unit of this value is percentage. ----------------------------------------------------------------------- Fan & Deng Expires April 30, 2015 [Page 5] Internet-Draft HTTP Flow Characteristic Signaling October 2014 4. Signaling Operation 4.1. Flow characteristic creation o Request URI: POST /flow-characteristic/creat o Request parameter: The following flow characteristic attributes defined in section 2 are used in the HTTP request message sent by the client: +-- expire_at optional +-- flow_description mandatory | +-- local_ipv4 optional | +-- local_ipv6 optional | +-- remote_ipv4 optional | +-- remote_ipv6 optional | +-- local_port optional | +-- remote_port optional | +-- transport_protocol optional +-- flow_treatment optional +-- bandwidth optional +-- delay optional +-- jitter optional +-- packet_loss optional +-- relative_priority optional The following is a JSON example of request body: { "expire_at" : "Wed Oct 15 14:30:00 +0800 2014", "flow_description" : { "local_ipv4" : "10.73.144.162", "local_port" : 40661, "remote_ipv4" : "221.130.45.101", "remote_port" : 80, "transport_protocol" : "TCP" }, "flow_treatment" : { "relative_priority" : 100 } } o Response data: Fan & Deng Expires April 30, 2015 [Page 6] Internet-Draft HTTP Flow Characteristic Signaling October 2014 If no error occurs for the request, the server will return a normal response message with status code 201. The normal response message contains the following flow characteristic attributes: +-- flow_id mandatory +-- created_at mandatory +-- expire_at mandatory +-- flow_description mandatory | +-- local_ipv4 optional | +-- local_ipv6 optional | +-- remote_ipv4 optional | +-- remote_ipv6 optional | +-- local_port optional | +-- remote_port optional | +-- transport_protocol optional +-- flow_treatment mandatory +-- bandwidth optional +-- delay optional +-- jitter optional +-- packet_loss optional +-- relative_priority optional The following is a JSON example of normal response body: { "flow_id" : 2305480030280000 "created_at" : "Wed Oct 15 14:01:37 +0800 2014" "expire_at" : "Wed Oct 15 14:10:00 +0800 2014", "flow_description" : { "local_ipv4" : "10.73.144.162", "local_port" : 40661, "remote_ipv4" : "221.130.45.101", "remote_port" : 80, "transport_protocol" : "TCP" }, "flow_treatment" : { "relative_priority" : 80 } } If an error occurs for the request, the server will return an error response containing error information. Error reporting details are described in section 4. Fan & Deng Expires April 30, 2015 [Page 7] Internet-Draft HTTP Flow Characteristic Signaling October 2014 4.2. Flow characteristic modification o Request URI: POST /flow-characteristic/modify o Request parameter: The following flow characteristic attributes defined in section 2 are used in the HTTP request message sent by the client: +-- flow_id mandatory +-- expire_at optional +-- flow_treatment mandatory +-- bandwidth optional +-- delay optional +-- jitter optional +-- packet_loss optional +-- relative_priority optional The following is a JSON example of request body: { "flow_id" : "2305480030280000", "expire_at" : "Wed Oct 15 14:15:00 +0800 2014", "flow_treatment" : { "relative_priority" : 20 } } o Response data: If no error occurs for the request, the server will return a normal response message with status code 201. The normal response message contains the following flow characteristic attributes: +-- flow_id mandatory +-- created_at mandatory +-- expire-at mandatory +-- flow_treatment mandatory +-- bandwidth optional +-- delay optional +-- jitter optional +-- packet_loss optional +-- relative_priority optional The following is a JSON example of normal response body: Fan & Deng Expires April 30, 2015 [Page 8] Internet-Draft HTTP Flow Characteristic Signaling October 2014 { "flow_id" : 2305480030280000 "created_at" : "Wed Oct 15 14:05:12 +0800 2014" "expire_at" : "Wed Oct 15 14:15:00 +0800 2014", "flow_treatment" : { "relative_priority" : 20 } } If an error occurs for the request, the server will return an error response containing error information. Error reporting details are described in section 4. 4.3. Flow characteristic deletion o Request URI: POST /flow-characteristic/delete o Request parameter: The following flow characteristic attributes defined in section 2 are used in the HTTP request message sent by the client: +-- flow_id mandatory The following is a JSON example of request body: { "flow_id" : "2305480030280000", } o Response data: If no error occurs for the request, the server will return a normal response message with status code 204. The normal response message contains no message body. If an error occurs for the request, the server will return an error response containing error information. Error reporting details are described in section 4. 5. Error Reporting When an error occurs for a flow characteristic request, the server must send an error response message to the client with an HTTP Status Code "4xx" indicating the failure of the signaling operation. The Fan & Deng Expires April 30, 2015 [Page 9] Internet-Draft HTTP Flow Characteristic Signaling October 2014 error response must contain a message body showing the detailed error information as follows: +-- request_uri string mandatory +-- error_code string mandatory +-- error_description string mandatory The following specifies the error codes and description, as well as Status Code used in the message: ----------------------------------------------------------------------- error_code error_description Status Code ----------------------------------------------------------------------- 10101 Invalid attribute value 400 Bad Request 10102 Mandatory attribute is missing or empty 400 Bad Request 10201 Flow characteristic does not exist 404 Not Found 10202 Conflict with existing flow characteristic 409 Conflict 10203 Not your own flow characteristic 403 Forbidden 20101 Can not create more flow characteristics 403 Forbidden 20102 signaling is too frequent 403 Forbidden ----------------------------------------------------------------------- The following JSON example shows an error response body returned for deleting an non-existent flow characteristic: { "request_uri" : "/flow-characteristic/delete", "error_code" : "10201", "error_description" : "Flow characteristic does not exist" } 6. Security Consideration 6.1. Authorization By HTTP based flow characteristic signaling, the network is opening its ability to identify traffic flows and accept flow treatment request. The network ability, opened as a kind of service resource, is supposed to be offered to users, while applications can gain access to it under the permission of user. Flow characteristic signaling must support third party authorization to ensure the applications get grated by the user and authenticated by the network. This document utilizes OAuth [RFC6749], with user being Resource Owner and flow characteristic signaling server being Resource Server and Authorization Server. The application must interact with Resource Owner and Authorization Server to acquire Access Token Fan & Deng Expires April 30, 2015 [Page 10] Internet-Draft HTTP Flow Characteristic Signaling October 2014 first, and then use Access Token in the signaling request described in section 4 to complete authorization. 6.2. Transport Flow characteristic signaling must provide mechanism to ensure message integrity and protect from unwanted information leakage. OAuth requires the use of TLS [RFC2246] in the authorization process, and the signaling operation specified in this document can also rely on TLS as a transport-layer security mechanism. Flow characteristic signaling must use HTTP over TLS (HTTPS) [RFC2818] to provide data integrity and privacy. 6.3. Signaling misuse In actual implementation, the server must consider possible processing pressure of signaling request from clients. To avoid abuse of network resource, the server must set limitation to users and applications to restrict their access to network resource from the perspectives such as duration, frequency and quantity. The limitation may be based on pre-configuration, and should be able to vary from different users and applications. Flow characteristics signaling is associated with an effect scope. The scope can be flows generated by the user, application, terminal, or access link the client is running for. Normally, a client should only signal flow characteristics within its own scope. The server may pre-configure client privilege and scope definition to restrict signaling operation from clients. The server must check received signaling requests and prevent clients from interfering intentionally or unintentionally with flows in other scopes. The server must keep a track record of flow characteristics signaling operation and subsequent network adjustment so that applications and users can be examined for the misuse of flow characteristics signaling. 7. Normative References [I-D.conet-aeon-problem-statement] Fan, P., Deng, H., Boucadair, M., Reddy, T., Eckel, C., and B. Williams, "Application Enabled Collaborative Networking: Problem Statement", draft-conet-aeon-problem- statement-01 (work in progress), July 2014. Fan & Deng Expires April 30, 2015 [Page 11] Internet-Draft HTTP Flow Characteristic Signaling October 2014 [I-D.conet-aeon-requirements] Fan, P., Boucadair, M., Williams, B., Reddy, T., and C. Eckel, "Application Enabled Collaborative Networking Requirements", draft-conet-aeon-requirements-00 (work in progress), July 2014. [I-D.conet-aeon-use-cases] George, W., Fan, P., Matsushima, S., Reddy, T., and C. Eckel, "Application Enabled Collaborative Networking Use Cases", draft-conet-aeon-use-cases-01 (work in progress), July 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. Authors' Addresses Peng Fan China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: fanpeng@chinamobile.com Hui Deng China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: denghui02@gmail.com Fan & Deng Expires April 30, 2015 [Page 12]