PCP Working Group M. Boucadair Internet-Draft France Telecom Intended status: Standards Track April 15, 2014 Expires: October 17, 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 17, 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 Boucadair Expires October 17, 2014 [Page 1] Internet-Draft PCP & Traffic Classification April 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scope of this Document . . . . . . . . . . . . . . . . . . . 3 3. Objectives for Controlling Classifiers . . . . . . . . . . . 3 4. Candidate Extensions . . . . . . . . . . . . . . . . . . . . 5 5. Detailed Specification . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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]: Boucadair Expires October 17, 2014 [Page 2] Internet-Draft PCP & Traffic Classification April 2014 "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., [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: o Rationalize the management of classification rules. Boucadair Expires October 17, 2014 [Page 3] Internet-Draft PCP & Traffic Classification April 2014 o Help assessing the impact of removing or modifying a classification rule. o Check the coherency of instantiated classification rules. o Help aggregating rules: this allows to optimize the classification rule table and therefor accelerate packet/flow processing (mainly reduce lookup delays). o Adjust classification rules when rules are based on volatile identifiers (e.g., IP address). o Maintain an global overview of instantiated rules in involved Network Elements. o Rapidly restore state during failure events. o Network Elements can retrieve their table after failure events whiteout requiring permanent storage capacity. PCP allows the following: o Directionality o Classification involving port sets o Classification rules involving IPv4 addresses o Classification rules involving IPv4 prefixes o Classification rules involving IPv6 addresses o Classification rules involving IPv6 prefixes o Classification rules with or without NAT o Feedback loop to assess whether a classification rule has been successfully enforced: PREFERE_FAILURE o Associate a description with classification rules o Classification rules are associated with lifetimes o PCP client can re-install states if a loss is detected o PCP server does not need to store the entries in a permanent storage; state can be installed by the PCP client. Boucadair Expires October 17, 2014 [Page 4] Internet-Draft PCP & Traffic Classification April 2014 o PCP client detects rapidly any state loss, including reboot of the PCP server o Multiple PCP clients can control the same PCP server o 2-way exchange is needed to install new state; o No need to lock the server waiting when concurrent clients are in contact with the server. 4. Candidate Extensions Some candidate extensions are listed below: o Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC address), an opaque subscriber-identifier, an IMSI, etc. o Extended FILTER to include a remote range of ports. This extension might be useful for the firewall case. o DSCP-based filtering. This extension might be useful for the firewall case. o 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. o Explicit actions: re-mark, drop, shape (can be used with FLOWDATA). o A means to indicate the SFC binding. 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. Boucadair Expires October 17, 2014 [Page 5] Internet-Draft PCP & Traffic Classification April 2014 8. Acknowledgements TBC. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. 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", draft-boucadair-sfc- framework-02 (work in progress), February 2014. [I-D.ietf-sfc-problem-statement] Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", draft-ietf-sfc-problem-statement-03 (work in progress), April 2014. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., 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. Author's Address Boucadair Expires October 17, 2014 [Page 6] Internet-Draft PCP & Traffic Classification April 2014 Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Boucadair Expires October 17, 2014 [Page 7]