Internet DRAFT - draft-fan-flow-characteristic-signaling
draft-fan-flow-characteristic-signaling
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]
