idnits 2.17.00 (12 Aug 2021) /tmp/idnits37030/draft-boucadair-pcp-sfc-classifier-control-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2014) is 2763 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-sfc-architecture has been published as RFC 7665 == Outdated reference: draft-ietf-sfc-problem-statement has been published as RFC 7498 == Outdated reference: A later version (-02) exists of draft-ripke-pcp-tunnel-id-option-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track October 20, 2014 5 Expires: April 23, 2015 7 PCP as a Traffic Classifier Control Protocol 8 draft-boucadair-pcp-sfc-classifier-control-01 10 Abstract 12 This document specifies how PCP (Port Control Protocol) can be used 13 as a classifier control protocol. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 23, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Scope of this Document . . . . . . . . . . . . . . . . . . . 3 57 3. Objectives for Controlling Classifiers . . . . . . . . . . . 3 58 4. PCP as a Traffic Classifier Control Protocol . . . . . . . . 4 59 5. Deployment Model . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Missing PCP Extensions . . . . . . . . . . . . . . . . . . . 5 61 7. Detailed Specification . . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 11.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 PCP (Port Control Protocol, [RFC6887]) has been specified to control 73 an upstream function such as NATs or firewalls. PCP can be used to 74 interact with both statefull and stateless functions. 76 PCP can be abstracted as a means to notify an upstream network with 77 the flow characteristics that would trigger decisions on the 78 appropriate policies to be applied on these flows at the network 79 side. This document focuses on a typical function that is present in 80 operational networks: Traffic Classifier Function. Two examples are 81 listed below: 83 DiffServ Classifiers A typical example of packet classifier is 84 DiffServ Classifier [RFC2475] that is responsible to select 85 packets in a traffic stream based on the content of some portion 86 of the packet header: this can be based solely on the DSCP field 87 or based on a combination of more header fields, such as source 88 address, destination address, DSCP field, protocol ID, source port 89 and destination port numbers, and other information such as 90 incoming interface. These classifiers must be configured by some 91 means as documented in [RFC2475]: 93 "Classifiers are used to "steer" packets matching some 94 specified rule to an element of a traffic conditioner for 95 further processing. Classifiers must be configured by some 96 management procedure in accordance with the appropriate TCA 97 (Traffic Conditioning Agreemet)." 99 This document proposes PCP to configure DiffServ Classifiers. 101 SFC Classifiers Another classifier is SFC Classifier (e.g., 102 [I-D.ietf-sfc-problem-statement] [I-D.ietf-sfc-architecture]). 103 This classifier is responsible for classifying flows to determine 104 which Service Function Chain (SFC) they belong to. 106 Similar to DiffServ, an SFC Classifier can rely on a variety of 107 classifying rules. 109 PCP can be used to instruct SFC Classifier policies. 111 A traffic classifier (or classifier for short) is a function that is 112 responsible for classifying flows based on (pre-defined) rules. Once 113 the traffic is classified, it can be marked to bear its class of 114 service (DSCP re-marking [RFC2474]), dropped, shaped, or any other 115 action instructed by the matching rule. This document focuses on 116 classification rules that manipulate L3/L4 fields of IP packets. 118 A Classifier can be seen as a statefull service function that applies 119 a set of policies for packets and/or flows matching a set of 120 criteria. This document specifies how PCP can be used as a 121 classifier control protocol. 123 Note a classifier can be co-located with a CGN (Carrier Grade NAT, 124 [RFC6888]), or a firewall. PCP can be used to install policies in 125 all these functions. 127 2. Scope of this Document 129 This version of the document explains the motivations, basic 130 assumptions, and identifies some missing features. Detailed 131 specification of required extensions will be elaborated in future 132 versions of the document. 134 This document focuses on the control of L2/L3/L4 Classifiers. 135 Sophisticated classifiers based on heuristics (e.g., those involving 136 DPI (Deep Packet Inspection) modules) are out of scope. 138 3. Objectives for Controlling Classifiers 140 Below are listed some objectives for a classifier control means: 142 o Rationalize the management of classification rules. 144 o Help assessing the impact of removing or modifying a 145 classification rule. 147 o Check the coherency of instantiated classification rules. 149 o Help aggregating rules: this allows to optimize the classification 150 rule table and therefor accelerate packet/flow processing (mainly 151 reduce lookup delays). 153 o Adjust classification rules when rules are based on volatile 154 identifiers (e.g., IP address). 156 o Maintain an global overview of instantiated rules in involved 157 Network Elements. 159 o Rapidly restore state during failure events. 161 o Network Elements can retrieve their table after failure events 162 whiteout requiring permanent storage capacity. 164 4. PCP as a Traffic Classifier Control Protocol 166 PCP fulfils most of the objectives listed in the previous section. 167 Concretely, PCP allows for the following: 169 o Directionality 171 o Classification involving port sets 173 o Classification rules involving IPv4 addresses 175 o Classification rules involving IPv4 prefixes 177 o Classification rules involving IPv6 addresses 179 o Classification rules involving IPv6 prefixes 181 o Classification rules with or without NAT 183 o Feedback loop to assess whether a classification rule has been 184 successfully enforced: PREFER_FAILURE 186 o Associate a description with classification rules 188 o Classification rules are associated with lifetimes 190 o PCP client can re-install states if a loss is detected 191 o PCP server does not need to store the entries in a permanent 192 storage; state can be installed by the PCP client 194 o PCP client detects rapidly any state loss, including reboot of the 195 PCP server 197 o Multiple PCP clients can control the same PCP server 199 o 2-way exchange is needed to install new state 201 o No need to lock the server waiting when concurrent clients are in 202 contact with the server. 204 5. Deployment Model 206 The reference architecture adopted in this document assumes that both 207 the PCP client and server are managed by the same administrative 208 entity (e.g., an operator). 210 Classification rules are not exposed outside an administrative 211 domain. In particular, subscribers are not aware of these policies. 213 PCP requests received in the subscriber-faced interfaces are not 214 allowed to manage policies enforced in the classifiers. 216 6. Missing PCP Extensions 218 Some candidate extensions are listed below: 220 o Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC 221 address), an opaque subscriber-identifier, an IMSI, etc. A 222 candidate option is defined in [I-D.ripke-pcp-tunnel-id-option]. 224 This extension is also needed to control NATs that are Layer-2 225 Aware (see Section 2.1 of [RFC6887]). 227 o Extended FILTER to include a remote range of ports. This 228 extension might be useful for the firewall case. 230 o DSCP-based filtering. This extension is also useful for the 231 firewall control case. 233 o DSCP re-marking: this is to be enforced at the boundaries of a 234 domain. The marking at the access segment may not the same as the 235 core network. Marking must be enforced by a trusted device. 237 o Explicit actions: re-mark, drop, shape (can be used with FLOWDATA 238 [I-D.wing-pcp-flowdata]). 240 o A means to indicate the SFC binding. 242 7. Detailed Specification 244 This section will be completed if the working group agrees with the 245 problem to be solved. 247 8. IANA Considerations 249 To be completed. 251 9. Security Considerations 253 Security considerations discussed in [RFC6887] MUST be taken into 254 account. 256 10. Acknowledgements 258 TBC. 260 11. References 262 11.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 268 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 269 2013. 271 11.2. Informative References 273 [I-D.ietf-sfc-architecture] 274 Halpern, J. and C. Pignataro, "Service Function Chaining 275 (SFC) Architecture", draft-ietf-sfc-architecture-02 (work 276 in progress), September 2014. 278 [I-D.ietf-sfc-problem-statement] 279 Quinn, P. and T. Nadeau, "Service Function Chaining 280 Problem Statement", draft-ietf-sfc-problem-statement-10 281 (work in progress), August 2014. 283 [I-D.ripke-pcp-tunnel-id-option] 284 Ripke, A., Dietz, T., Quittek, J., and R. Silva, "PCP 285 Tunnel-ID Option", draft-ripke-pcp-tunnel-id-option-01 286 (work in progress), July 2014. 288 [I-D.wing-pcp-flowdata] 289 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 290 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 292 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 293 "Definition of the Differentiated Services Field (DS 294 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 295 1998. 297 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 298 and W. Weiss, "An Architecture for Differentiated 299 Services", RFC 2475, December 1998. 301 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 302 and H. Ashida, "Common Requirements for Carrier-Grade NATs 303 (CGNs)", BCP 127, RFC 6888, April 2013. 305 Author's Address 307 Mohamed Boucadair 308 France Telecom 309 Rennes 35000 310 France 312 Email: mohamed.boucadair@orange.com