Internet DRAFT - draft-wing-pcp-flowdata
draft-wing-pcp-flowdata
PCP Working Group D. Wing
Internet-Draft R. Penno
Intended status: Standards Track T. Reddy
Expires: January 04, 2014 Cisco
July 03, 2013
PCP Flowdata Option
draft-wing-pcp-flowdata-00
Abstract
This document defines a mechanism for a host to signal flow
characteristics to the network, and the network to signal its ability
to accommodate that flow back to the host. The mechanism defines a
new PCP option for the existing MAP and PEER opcodes.
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 04, 2014.
Copyright Notice
Copyright (c) 2013 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.
Wing, et al. Expires January 04, 2014 [Page 1]
Internet-Draft PCP Flowdata Option July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PCP FLOWDATA Option . . . . . . . . . . . . . . . . . . . . . 3
3.1. Usage and Processing . . . . . . . . . . . . . . . . . . 4
3.2. Generating a PCP Request with FLOWDATA Option . . . . . . 5
3.3. Processing a Request with FLOWDATA Option . . . . . . . . 6
3.4. Processing a Response with FLOWDATA Option . . . . . . . 7
3.5. Link or State Changes on PCP Server . . . . . . . . . . . 7
3.6. Conflict Resolution . . . . . . . . . . . . . . . . . . . 8
4. PCP FLOWDATA Option Data Fields . . . . . . . . . . . . . . . 9
5. FLOWDATA Interaction with PCP Proxy . . . . . . . . . . . . . 14
6. Network Authorization . . . . . . . . . . . . . . . . . . . . 15
7. Scaling Considerations . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Access networks often have insufficient bandwidth or other
characteristics that prevent some applications from functioning as
well as desired. Although the quality of wireless and wired access
networks continue to improve, those access networks are often
constrained for various reasons. This document provides a mechanism
to signal the application's network requirements to the access
network, so that certain network flows can receive service that is
differentiated from other network flows. With this mechanism, a host
can request the network provide certain characteristics for a flow in
both the upstream and downstream directions. The network authorizes
the request and signals back to the host that it can (fully or
partially) accommodate the flow. This sort of signaling is useful
for long-lived flows such as interactive audio/video, streaming
video, and network control traffic (call signaling, routing
protocols).
In order to obtain such differentiated service from a network, many
previous mechanisms have been created for hosts to convey flow
information to the network. The mechanism described in this document
has several useful properties:
o Usable at the application level, without needing operating system
support;
Wing, et al. Expires January 04, 2014 [Page 2]
Internet-Draft PCP Flowdata Option July 2013
o Abstracts layer 2 specifics, so host and applications can avoid
layer 2-specific signaling;
o Robust metadata support, to convey sufficient information to the
network about the flow;
o Differentiates service on the local network and the immediately
adjacent access network, which is typically bandwidth constrained;
o Deployable on a local network and its adjacent access link,
without needing support of the remote host's network or support of
the remote host;
o Provides differentiated service for both directions of a flow,
including flows that cross administrative boundaries (such as the
Internet).
The mechanism described in this specification defines an extension to
Port Control Protocol (PCP [RFC6887]). This may be surprising at
first because PCP is considered as a protocol for managing mappings
in NATs and firewalls. However, PCP does not require the network
implement a NAT or to implement a firewall. This is an important
point: this specification does not require the network operate a NAT,
and does not require the network operate a firewall. At a high
level, PCP provides bi-directional communication a flow to the
network. PCP can recursively communicate flow information to a
number of on-path devices using PCP itself
([I-D.cheshire-recursive-pcp], [I-D.ietf-pcp-proxy]) or using an SDN
protocol. Such recursion provides the flow information to more
devices on the path, allowing each of them to optimize the flow over
their respective links.
2. Terminology
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].
3. PCP FLOWDATA Option
The FLOWDATA option described in this document allows a host to
signal the bi-directional characteristics of a flow to its PCP
server. After signaling, the PCP server determines if it can
accommodate that flow, making configuration changes if necessary to
accommodate the flow, and returns information in the FLOWDATA option
indicating its ability to accommodate the described flow.
Wing, et al. Expires January 04, 2014 [Page 3]
Internet-Draft PCP Flowdata Option July 2013
3.1. Usage and Processing
A host may want to indicate to the network the priority of a flow
after the flow has been established (typical if the host is operating
as a client) or before the flow has been established (typical if the
host is operating as a server). Both of these are supported and
depicted in the following diagrams.
The following diagram shows how a connection is first established and
then the flow is prioritized. This allows for the fastest connection
setup time with the server.
PCP client PCP server UDP/TCP server
| | |
|-------------TCP SYN, SYNACK, ACK----------------------->|
| | |
| (flow is not prioritized) | |
| | |
|------- PCP PEER + FLOWDATA Option ------>| |
|<-----------------SUCCESS-----------------| |
| | |
| (flow is prioritized) | |
| | |
Figure 1: Message diagram, client connects first
The following diagram shows first asking the network to prioritize a
flow, then establishing a flow. This is useful if the priority of
the flow is more important than establishing the flow quickly.
PCP client PCP server UDP/TCP server
| | |
| | |
|------- PCP PEER + FLOWDATA Option ------>| |
|<-----------------SUCCESS-----------------| |
| | |
| (flow is prioritized) | |
| | |
|-------------TCP SYN, SYNACK, ACK----------------------->|
| | |
Figure 2: Message diagram, client sets priority first
The following diagram shows a PCP client getting a PCP MAP mapping
for incoming flows with priority. This ensures that the PCP client
has a mapping and all packets associated with the incoming TCP
connections matching that mapping are prioritized. The PCP Client in
this case could be a video server in a data center.
Wing, et al. Expires January 04, 2014 [Page 4]
Internet-Draft PCP Flowdata Option July 2013
PCP client PCP server UDP/TCP client
| | |
(listening on port XYZ) | |
| | |
|-------PCP MAP + FLOWDATA Option------>| |
|<-------------SUCCESS------------------| |
| | |
| (flow is prioritized) | |
... ... ...
| | |
|<------------TCP SYN, SYNACK, ACK---------------------|
| | |
Figure 3: Message diagram, operating a server
The following diagram shows how two separate connections, where only
one is active at a time, use the same instance identifier.
PCP client PCP server TCP srvr 1 TCP srvr 2
| | | |
|-------------TCP SYN, SYNACK, ACK----------->| |
| | | |
| (flow to server 1 is not prioritized) | |
| | | |
|-PCP PEER+FLOWDATA instance=123-->| | |
|<-----------------SUCCESS---------| | |
| | | |
| (flow to server 1 is prioritized) | |
| | | |
|-------------TCP SYN, SYNACK, ACK------------------------>|
| | | |
| (flow to server 2 is not prioritized) | |
| | | |
|-PCP PEER+FLOWDATA instance=123-->| | |
|<-----------------SUCCESS---------| | |
| | | |
| (flow to server 2 is sharing | |
| characteristics with flow to server 1) | |
| | | |
Figure 4: Message diagram with Instance Identifier
3.2. Generating a PCP Request with FLOWDATA Option
The PCP client first does all the processing described in Sections
8.1, 11.2, and 12.3 of [RFC6887] as appropriate for generating a MAP
or PEER opcode request. Included in that request is a FLOWDATA
option formatted as described in this document. For flows
Wing, et al. Expires January 04, 2014 [Page 5]
Internet-Draft PCP Flowdata Option July 2013
established by the PCP client, the MAP or PEER request with FLOWDATA
option can be sent before or after the PCP client has established any
flows. For flows terminated by the PCP client (that is, when
operating a server), the FLOWDATA option can be received and
processed by the PCP server together with a MAP request or later
during a MAP refresh request as shown in Figure 3.
3.3. Processing a Request with FLOWDATA Option
The PCP server performs processing in the order of the paragraphs
below.
Upon receiving a PCP Request with FLOWDATA option first does the
processing described in Section 8.2, 11.3, and 12.2 of [RFC6887], as
appropriate for processing a MAP or PEER opcode request. If the MAP
or PEER request contains the FLOWDATA option, the PCP server
determines if the flow characteristics described in the FLOWDATA
option can be accommodated by the network element controlled by the
PCP server (that is, the router, NAT, or firewall controlled by the
PCP server). To determine this, the PCP server might examine its
static configuration and do bandwidth counting, or it might
reconfigure the underlying network so that additional bandwidth is
made available for this particular flow, or might perform other
actions. If the PCP server determines the flow can only be partially
accommodated, it returns values in the FLOWDATA fields that it can
accommodate or returns 0 in those FLOWDATA fields where it has no
information. In other words if the request indicated a low tolerance
for delay but the PCP server and its controlled device determine that
only high delay is available, the FLOWDATA response indicates high
delay is available. The same sort of processing occurs on all of the
FLOWDATA fields of the response (upstream and downstream delay
tolerance, loss tolerance, jitter tolerance, minimum bandwidth,
maximum bandwidth).
A PCP server that processes the FLOWDATA option is likely to create
state for that flow (e.g., for bandwidth counting so that the
bandwidth is returned to the bandwidth pool when the flow lifetime
expires). Because Memory and other resources limit how much state
can be created, the PCP server MUST implement a policy limit so that
all state is not consumed by one host. It MAY also implement other
limits, such as rate limits. The PCP server can implement its own
policy to remove flows from its memory, such as FIFO. If a host has
exceeded its quota, the existing error USER_EX_QUOTA SHOULD be
returned.
If the PCP server can accommodate the flow as described in the
FLOWDATA option, and can create the mapping as described in the MAP
or PEER opcode, it sends a PCP response with the SUCCESS response
Wing, et al. Expires January 04, 2014 [Page 6]
Internet-Draft PCP Flowdata Option July 2013
code, and includes the FLOWDATA option filled in according to
Section 4.
After performing the above steps, the router creates state (if
necessary for its implementation) and sends SUCCESS response code to
the client with the data fields in the FLOWDATA option properly
filled out.
3.4. Processing a Response with FLOWDATA Option
The PCP client performs processing in the order of the paragraphs
below.
Upon receiving a PCP response, the PCP client performs the normal
processing described in Section 8.3 of [RFC6887].
If the PCP response was SUCCESS (0), the PCP server has created a
mapping. If the PCP response contains the FLOWDATA option, the
FLOWDATA fields indicate if the network could accommodate the
requested flow characteristics. The PCP client can use that
information to influence the traffic it sends and receives on the
network. For example, if the FLOWDATA response indicates the network
can accommodate a flow of a certain downstream bandwidth, the PCP
client will likely achieve the best result if it does not initiate a
flow that exceeds that bandwidth.
Note to implementers: PCP allows the server to send multiple
responses to a single request. This means that after sending a
request and receiving a (positive) response, a subsequent response
might be sent updating the information about the flow, should the
network conditions change. The response could carry a FLOWDATA
option where the data fields contain different values from the
first response. This might occur, for example, if a competing
high-bandwidth flow has finished, more bandwidth is available for
this host; the DSL line rate might have improved (or degraded);
the link speed may have been dynamically increased (or decreased).
Thus, a PCP client should expect these subsequent responses and
react accordingly.
3.5. Link or State Changes on PCP Server
After the PCP server has sent a SUCCESS response code including the
FLOWDATA option, link characteristics might change causing a flow to
no longer be accommodated by the network (e.g., link speed degrades)
or for the PCP server to flush a flow from its list of prioritized
flows (e.g., due to memory constraints). Whenever the network can no
longer accommodate a flow, the PCP server MUST inform the PCP client
by sending a mapping update response including an updated FLOWDATA
Wing, et al. Expires January 04, 2014 [Page 7]
Internet-Draft PCP Flowdata Option July 2013
option, following the same procedure as a Mapping Update
(Section 14.2 of [RFC6887]). As with PCP without FLOWDATA, if the
PCP server loses all its state it will alert the PCP clients using
rapid recovery (Section 14 of [RFC6887]) which also indicates loss of
FLOWDATA state in the network.
Note: it is also possible that originally-requested flowdata could be
accommodated (e.g., link speed improved). We might want to signal to
endpoints that they should ask again for their originally-requested
flowdata. This is for future study.
3.6. Conflict Resolution
It is possible that two hosts send requests with different thresholds
for delay or jitter or different values for bandwidth in each
direction, and their requests arrive at the same PCP server. An
example is a media streamer and a television within the same home
where one indicates its sending bandwidth is higher than the other
indicates its receiving bandwidth. As another example, the indicated
tolerance for delay might be different.
If this occurs, it is RECOMMENDED that the PCP server use the smaller
bandwidth and stricter delay/loss tolerance (that is, the lower
tolerance to delay or jitter), and issue a FLOWDATA update so both
PCP clients receive the same information. The diagram below depicts
a conflict message flow.
media streamer PCP server television
| | |
|-7mbps, delay=med-->| |
|<--OK---------------| |
| | |
| |<-5mbps, delay=hi---|
| | |
| (conflict!) |
| | |
| |--OK, 5mbps, d=m--->|
| | |
| (send mapping update |
| with FLOWDATA option) |
| | |
|<--OK, 5mbps, d=m---| |
|<--OK, 5mbps, d=m---| |
|<--OK, 5mbps, d=m---| |
Figure 5: Message diagram, resolving conflict
Wing, et al. Expires January 04, 2014 [Page 8]
Internet-Draft PCP Flowdata Option July 2013
It is also possible for one PCP client to think two flows should use
the same instance identifier but the other PCP client to use
different instance identifiers for those two flows. In this case,
the operation of the PCP server (and the device it controls) is
implementation specific.
4. PCP FLOWDATA Option Data Fields
The FLOWDATA option has the following characteristics:
Option Name: FLOWDATA
Number: (to be assigned by IANA)
Purpose: Describe flow characteristics to the network
Valid for Opcodes: MAP, PEER
Length: 24 octets
May appear in: request. May appear in response only if it
appeared in the associated request.
Maximum occurrences: 1
The FLOWDATA option request has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Code=TBA| Reserved | Option Length=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| uDT | uLT | uJT | RSVD1 | dDT | dLT | dJT | RSVD2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FLOWDATA Option
Description of the fields:
Wing, et al. Expires January 04, 2014 [Page 9]
Internet-Draft PCP Flowdata Option July 2013
Instance Identifier: 96 bit identifier, unique to each
simultaneously-active flow. This is a pseudo random number that
MUST be generated following the procedures described in [RFC4086].
uDT: Upstream Delay Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
uLT: Upstream Loss Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
uJT: Upstream Jitter Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
dDT: Downstream Delay Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
dLT: Downstream Loss Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
dJT: Downstream Jitter Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
Upstream Minimum Bandwidth Measures bandwidth sent by the PCP
client. Value is in octets per second. The value 0 means no
information is available.
Downstream Minimum Bandwidth Measures bandwidth sent to the PCP
client. Value is in octets per second. The value 0 means no
information is available.
Upstream Maximum Bandwidth: Measures bandwidth sent by the PCP
client. Value is in octets per second. The value 0 means no
information is available.
Downstream Maximum Bandwidth Measures bandwidth sent to the PCP
client. Value is in octets per second. The value 0 means no
information is available.
The instance identifier accommodates network traffic where multiple
5-tuples exist for a particular data flow, but the bandwidth flows
only over the aggregate of the multiple 5-tuples. A use-case for
this identifier is TCP video streaming which retrieves short pieces
Wing, et al. Expires January 04, 2014 [Page 10]
Internet-Draft PCP Flowdata Option July 2013
of the movie, often over separate TCP connections for load balancing,
which would use the same Instance Identifier for each TCP connection.
An instance is considered unique if the combination of the PCP
client's IP address and the instance identifier are unique.
Discussion point: Minimum and maximum value of bandwidth is 1 byte
per second to 4 gigaBYTES per second. We probably need to express
higher bandwidth, and maybe also lower bandwidth?
Different applications have different needs for their flows. The
following table is derived from [RFC4594] to serve as a guideline for
tolerance to loss, delay and jitter for some sample applications.
Wing, et al. Expires January 04, 2014 [Page 11]
Internet-Draft PCP Flowdata Option July 2013
-------------------------------------------------------------------
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | High |
| | traffic can also burst | | | |
| | (e.g., OSPF) | | | |
|---------------+------------------------------+------+------+------|
| | Fixed-size small packets, | Very | Very | Very |
| Telephony | constant emission rate, | Low | Low | Low |
| | inelastic and low-rate flows | | | |
| | (e.g., G.711, G.729) | | | |
|---------------+------------------------------+------+------+------|
| Signaling | Variable size packets, some | Low | Low | High |
| | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, | Low | Very | |
| Conferencing | constant transmit interval, | - | Low | Low |
| |rate adaptive, reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------|
| Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, |Low - |Medium| High |
| Streaming | elastic with variable rate |Medium| | |
|---------------+------------------------------+------+------+------|
| Broadcast | Constant and variable rate, | Very |Medium| Low |
| Video | inelastic, non-bursty flows | Low | | |
|---------------+------------------------------+------+------+------|
| Low-Latency | Variable rate, bursty short- | Low |Low - | High |
| Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| High |
| | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------|
|High-Throughput| Variable rate, bursty long- | Low |Medium| High |
| Data | lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------|
| Standard | A bit of everything | 0 0 0 |
|---------------+------------------------------+------+------+------|
| Low-Priority | Non-real-time and elastic | High | High | High |
| Data | (e.g., network backup) | | | |
-------------------------------------------------------------------
The FLOWDATA Option response has the following format. The fields
indicate what the network can accommodate of the request.
Wing, et al. Expires January 04, 2014 [Page 12]
Internet-Draft PCP Flowdata Option July 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Code=TBA| Reserved | Option Length=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reserved |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AuDT| AuLT| AuJT| RSVD1 | AdDT| AdLT| AdJT| RSVD2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accommodated Upstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accommodated Downstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accommodated Upstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accommodated Downstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FLOWDATA Option
Description of the fields:
Reserved: 96 bits, MUST be ignored on reception and MUST be 0 on
transmission.
AuDT: Accommodated Upstream Delay Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
AuLT: Accommodated Upstream Loss Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
AuJT: Accommodated Upstream Jitter Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
AdDT: Accommodated Downstream Delay Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high..
Wing, et al. Expires January 04, 2014 [Page 13]
Internet-Draft PCP Flowdata Option July 2013
AdLT: Accommodated Downstream Loss Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
AdJT: Accommodated Downstream Jitter Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
Accommodated Upstream Minimum Bandwidth Bandwidth the network can
accommodate for this flow, sent by the PCP client. Value in bytes
per second. 0 means no information is available.
Accommodated Downstream Minimum Bandwidth Bandwidth the network can
accommodate for this flow, sent to the PCP client. Value in bytes
per second. 0 means no information is available.
Accommodated Upstream Maximum Bandwidth: Bandwidth the network can
accommodate for this flow, sent by the PCP client. Value in bytes
per second. 0 means no information is available.
Accommodated Downstream Maximum Bandwidth Bandwidth the network can
accommodate for this flow, sent to the PCP client. Maximum
Downstream bandwidth in bytes per second, 0 means no information
is available.
5. FLOWDATA Interaction with PCP Proxy
The FLOWDATA option is optional to process. A PCP Proxy performs the
functions described in [I-D.ietf-pcp-proxy], and if the PCP request
contains the FLOWDATA option it also performs the functions described
in this section.
The PCP request containing the FLOWDATA option SHOULD be proxied
normally, so that the upstream PCP server can be aware of the entire
request. The PCP proxy MAY have its own policies specific to the
FLOWDATA option which require it to modify the FLOWDATA values
request (e.g., reduce bandwidth for a certain PCP client).
After proxying the message containing FLOWDATA, when the PCP proxy
receives the associated PCP response, the PCP proxy MAY reduce the
bandwidth values or use worse (higher) values for delay, loss, or
jitter tolerance. It MUST NOT increase the bandwidth or use better
(lower) values for the delay, loss, or jitter tolerance.
Wing, et al. Expires January 04, 2014 [Page 14]
Internet-Draft PCP Flowdata Option July 2013
6. Network Authorization
Oftentimes the endpoints themselves are not authorized to request
network resources, but instead authorization has to first be obtained
from a network element such as a call controller or policy element.
To accommodate such deployments, third party authorization can be
used with FLOWDATA . At a high level, this authorization works by the
PCP client first obtaining a cryptographic token from the authorizing
network element (e.g., call controller) and includes that token in
the PCP request. The PCP server in the network validates the token
and grants access.
7. Scaling Considerations
The network elements need only act upon those flows explicitly
signaled by a PCP client, instead of all possible flows that a host
generates.
Short lived flows (e.g., HTTP/1.0) or best-effort flows would receive
little to no benefit from the signaling described in this document.
As explained in Section 3.3, the PCP server will limit excessive
flowdata requests, so hosts are encouraged to be conservative in how
many flows are signaled with flowdata.
8. Security Considerations
On some networks, only certain users or certain applications are
authorized to signal the priority of a flow. This authorization can
be achieved with PCP client authentication
[I-D.ietf-pcp-authentication].
9. IANA Considerations
IANA is requested to assign a new PCP option called FLOWDATA from the
optional to process range (128-255) in the [pcp-iana] registry.
10. Acknowledgements
Thanks to Anca Zamfir for review comments.
11. References
11.1. Normative References
[I-D.ietf-pcp-authentication]
Wasserman, M., Hartman, S., and D. Zhang, "Port Control
Protocol (PCP) Authentication Mechanism", draft-ietf-pcp-
authentication-01 (work in progress), October 2012.
Wing, et al. Expires January 04, 2014 [Page 15]
Internet-Draft PCP Flowdata Option July 2013
[I-D.ietf-pcp-proxy]
Boucadair, M., Penno, R., and D. Wing, "Port Control
Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-03
(work in progress), June 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
11.2. Informative References
[I-D.cheshire-recursive-pcp]
Cheshire, S., "Recursive PCP", draft-cheshire-recursive-
pcp-02 (work in progress), March 2013.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, August
2006.
[pcp-iana]
IANA, "Port Control Protocol (PCP) Parameters", May 2013,
<http://www.iana.org/assignments/pcp-parameters/pcp-
parameters.xml#options>.
Authors' Addresses
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Reinaldo Penno
Cisco Systems, Inc.
170 West Tasman Drive
San Jose 95134
USA
Email: repenno@cisco.com
Wing, et al. Expires January 04, 2014 [Page 16]
Internet-Draft PCP Flowdata Option July 2013
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Wing, et al. Expires January 04, 2014 [Page 17]
