PCP as a Traffic
Classifier Control Protocol
France Telecom
Rennes
35000
France
mohamed.boucadair@orange.com
PCP Working Group
This document specifies how PCP (Port Control Protocol) can be used
as a classifier control protocol.
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 RFC 2119.
PCP (Port Control Protocol, ) is a
protocol that has been specified to control an upstream function such
NATs or firewalls. PCP can be used to interact with statefull and
stateless functions.
PCP can be abstracted as a means to notify an upstream network with
the flow characteristics that would trigger decisions on the appropriate
policies to be applied on these flows at the network side. This document
focuses on a typical function that is present in operational networks:
Traffic Classifier Function.
A traffic classifier (or classifier for short) is a function that is
responsible for classifying flows based on (pre-defined) rules. Once the
traffic is classified, it can be marked to bear its class of service
(DSCP re-marking ), dropped, shaped, or
any other action instructed by the matching rule. This document focuses
on classification rules that manipulate L3/L4 fields of IP packets.
A typical example of packet classifier is DiffServ Classifier that responsible to select packets in a traffic
stream based on the content of some portion of the packet header: this
can be solely on the DSCP field or based on a combination of one or more
header fields, such as source address, destination address, DSCP field,
protocol ID, source port and destination port numbers, and other
information such as incoming interface. These classifiers must be
configured by some means as documented in :
"Classifiers are used to "steer" packets matching some specified
rule to an element of a traffic conditioner for further processing.
Classifiers must be configured by some management procedure in
accordance with the appropriate TCA (Traffic Conditioning
Agreemet)."
Another classifier is SFC Classifier (e.g., ). This classifier is
responsible for classifying flows to determine which Service Function
Chain they belong to. Similar to Diffserv, an SFC Classifier can rely on
a variety of classifying rules.
A Classifier can be seen as a statefull service function that applies
a set of policies for packets and/or flows matching a set of criteria.
This document specifies how PCP can be used as a classifier control
protocol.
Note a classifier can be co-located with a CGN (Carrier Grade NAT,
), or a firewall. PCP can be used to
install policies in all these functions.
The reference architecture adopted in this document assumes that both
the PCP client and server are managed by the same administrative entity
(e.g., an operator).
Classification rules are not exposed outside an administrative
domain. In particular, subscribers are not aware of these policies. PCP
requests received in the subscriber-faced interfaces are not allowed to
manage policies enforced in the classifiers.
Early versions of the document explains the motivations, basic
assumptions, and identify some missing features. Detailed specification
of required extensions will be elaborated in future versions of the
document.
This document focuses on the control of L2/L3/L4 Classifiers.
Sophisticated classifiers based on heuristics (e.g., those involving DPI
(Deep Packet Inspection) modules) are out of scope of this document.
Below are listed some objectives for a classifier control means:
Rationalize the management of classification rules.
Help assessing the impact of removing or modifying a
classification rule.
Check the coherency of instantiated classification rules.
Help aggregating rules: this allows to optimize the
classification rule table and therefor accelerate packet/flow
processing (mainly reduce lookup delays).
Adjust classification rules when rules are based on volatile
identifiers (e.g., IP address).
Maintain an global overview of instantiated rules in involved
Network Elements.
Rapidly restore state during failure events.
Network Elements can retrieve their table after failure events
whiteout requiring permanent storage capacity.
PCP allows the following:
Directionality
Classification involving port sets
Classification rules involving IPv4 addresses
Classification rules involving IPv4 prefixes
Classification rules involving IPv6 addresses
Classification rules involving IPv6 prefixes
Classification rules with or without NAT
Feedback loop to assess whether a classification rule has been
successfully enforced: PREFERE_FAILURE
Associate a description with classification rules
Classification rules are associated with lifetimes
PCP client can re-install states if a loss is detected
PCP server does not need to store the entries in a permanent
storage; state can be installed by the PCP client.
PCP client detects rapidly any state loss, including reboot of
the PCP server
Multiple PCP clients can control the same PCP server
2-way exchange is needed to install new state;
No need to lock the server waiting when concurrent clients are in
contact with the server.
Some candidate extensions are listed below:
Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC
address), an opaque subscriber-identifier, an IMSI, etc.
Extended FILTER to include a remote range of ports. This
extension might be useful for the firewall case.
DSCP-based filtering. This extension might be useful for the
firewall case.
DSCP re-marking: this is to be enforced at the boundaries of a
domain. The marking at the access segment may not the same as the
core network. Marking must be enforced by a trusted device.
Explicit actions: re-mark, drop, shape (can be used with
FLOWDATA).
A means to indicate the SFC binding.
This section will be completed if the working group agrees with the
problem to be solved.
Security considerations discussed in
MUST be taken into account.