PCP Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Standards Track April 16, 2014
Expires: October 18, 2014

PCP as a Traffic Classifier Control Protocol
draft-boucadair-pcp-sfc-classifier-control-00

Abstract

This document specifies how PCP (Port Control Protocol) can be used as a classifier control protocol.

Requirements Language

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 [RFC2119].

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 October 18, 2014.

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.


Table of Contents

1. Introduction

PCP (Port Control Protocol, [RFC6887]) 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 [RFC2474]), 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 [RFC2475] 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 [RFC2475]:

Another classifier is SFC Classifier (e.g., [I-D.ietf-sfc-problem-statement][I-D.boucadair-sfc-framework]). 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, [RFC6888]), 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.

2. Scope of this Document

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.

3. Objectives for Controlling Classifiers

Below are listed some objectives for a classifier control means:

PCP allows the following:

4. Candidate Extensions

Some candidate extensions are listed below:

5. Detailed Specification

This section will be completed if the working group agrees with the problem to be solved.

6. IANA Considerations

To be completed.

7. Security Considerations

Security considerations discussed in [RFC6887] MUST be taken into account.

8. Acknowledgements

TBC.

9. References

9.1. Normative References

[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R. and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

[I-D.boucadair-sfc-framework] Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., Guichard, J. and C. Pignataro, "Service Function Chaining: Framework & Architecture", Internet-Draft draft-boucadair-sfc-framework-02, February 2014.
[I-D.ietf-sfc-problem-statement] Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", Internet-Draft draft-ietf-sfc-problem-statement-03, April 2014.
[RFC2475] Blake, S., Black, D.L., Carlson, M.A., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A. and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D.L. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

Author's Address

Mohamed Boucadair France Telecom Rennes, 35000 France EMail: mohamed.boucadair@orange.com