idnits 2.17.1 draft-ietf-sfc-serviceid-header-03.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 (August 8, 2019) is 1694 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) == Missing Reference: 'ThisDocument' is mentioned on line 305, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-11 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC B. Sarikaya 3 Internet-Draft Denpel Informatique 4 Intended status: Standards Track D. von Hugo 5 Expires: February 9, 2020 Deutsche Telekom 6 M. Boucadair 7 Orange 8 August 8, 2019 10 Service Function Chaining: Subscriber and Performance Policy 11 Identification Variable-Length Network Service Header (NSH) Context 12 Headers 13 draft-ietf-sfc-serviceid-header-03 15 Abstract 17 This document defines Subscriber and Performance Policy Identifiers 18 Network Service Header Variable-Length Context Headers to inform 19 Service Functions about subscriber- and service-related information 20 for the sake of policy enforcement and appropriate service function 21 chaining operations. The structure of each context header is 22 defined, their use and processing instructions by SFC-aware nodes are 23 explained. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 9, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 61 3. Subscriber Identification NSH Variable-Length Context Header 4 62 4. Performance Policy Identification NSH Variable-Length Context 63 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 This document discusses how to inform Service Functions (SFs, 76 [RFC7665]) about subscriber- and service-related information, when 77 required, for the sake of policy enforcement within a single 78 administrative domain. Particularly, subscriber-related information 79 may be required to enforce subscriber-specific SFC-based traffic 80 policies. Nevertheless, the information carried in packets may not 81 be sufficient to unambiguously identify a subscriber. This document 82 fills this void by specifying a new Network Service Header (NSH) 83 [RFC8300] context header to convey and disseminate such information 84 within the boundaries of a single administrative domain. 86 Also, the enforcement of SFC-based differentiated traffic policies 87 may be inferred, for example, by QoS (Quality of Service) 88 considerations. Typically, QoS information may serve as an input to 89 the Service Function Path (SFP) for path computation, establishment, 90 and selection. Furthermore, the dynamic structuring of service 91 function chains and their subsequent enforcement may be conditioned 92 by QoS requirements that will affect SF instance identification, 93 location, and sequencing. Hence, the need to supply a performance 94 policy identifier to upstream SFs to appropriately meet the service 95 requirements arises. 97 SFs and SF Forwarders (SFFs) involved in a service chain have to 98 contribute to the respective service policy (QoS, for example) 99 requirements characterized by low transmission delay between each 100 other, by exposing a high availability of resources to process 101 function tasks, or by redundancy provided by stand-by machines for 102 seamless execution continuation in case of failures. These 103 requirements may be satisfied by means of control plane protocols, 104 but in some contexts, e.g., in networks where resources are very much 105 constrained, carrying QoS-related information directly in packets may 106 improve the overall SFC operation instead of relying upon the 107 potential complexity or adding overhead introduced by some SFC 108 control plane features. This information is typically included as 109 context header in the NSH. 111 The context information defined in this document can be applicable in 112 the context of mobile networks (typically, in the 3GPP defined (S)Gi 113 Interface) [I-D.ietf-sfc-use-case-mobility]. Because of the 114 widespread use of private addressing in those networks, if SFs to be 115 invoked are located after a NAT function (that can reside in the 116 Packet Data Network (PDN) Gateway (PGW) or in a distinct node), the 117 identification based on the internal IP address is not possible once 118 the NAT has been crossed. As such, means to allow passing the 119 internal information may optimise packet traversal within an SFC- 120 enabled mobile network domain. Furthermore, some SFs that are not 121 enabled on the PGW may require a subscriber identifier to properly 122 operate. It is out of scope of this document to include a 123 comprehensive list of deployment contexts which may make use of the 124 context headers defined in the document. 126 This document does not make any assumption about the structure of 127 subscriber or performance policy identifiers; each such identifier is 128 treated as an opaque value. The semantics and validation of these 129 identifiers are up to the control plane used for SFC. Expectations 130 to SFC control plane protocols are laid down, e.g., in [RFC8459], but 131 specifications of SFC control plane functions are also discussed in, 132 for example, [I-D.ietf-bess-nsh-bgp-control-plane]. Control plane 133 related considerations are out of scope. 135 This document assumes the NSH is used exclusively within a single 136 administrative domain. 138 This document adheres to the architecture defined in [RFC7665]. This 139 document assumes the reader is familiar with [RFC8300]. 141 2. Conventions and Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119][RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 The reader should be familiar with the terms defined in [RFC7665]. 151 3. Subscriber Identification NSH Variable-Length Context Header 153 Subscriber Identifier is defined as an optional variable-length NSH 154 context header. Its structure is shown in Figure 1. 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Metadata Class | Type |U| Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 ~ Subscriber Identifier ~ 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: Subscriber Identifier Variable-Length Context Header 167 The description of the fields is as follows: 169 o Metadata Class: MUST be set to 0x0 [RFC8300]. 171 o Type: TBD1 (See Section 5) 173 o Subscriber Identifier: Carries an opaque subscriber identifier. 175 The subscriber identifier is used to convey an identifier assigned by 176 the service provider to uniquely identify a subscriber. This 177 subscriber identifier can be used by service functions to enforce 178 per-subscriber policies. 180 The classifier and SFC-aware SFs MAY be instructed via a control 181 interface to inject or strip a subscriber identifier context header. 182 Also, the data to be injected in such header SHOULD be configured to 183 nodes authorized to inject such headers. Typically, a node can be 184 instructed to insert such data following a type/set scheme (e.g., 185 node X should inject subscriber ID type Y). Other schemes may be 186 envisaged. 188 Failures to inject such headers SHOULD be logged locally while a 189 notification alarm MAY be sent to a Control Element. The details of 190 sending notification alarms (i.e., the parameters affecting the 191 transmission of the notification alarms depend on the information in 192 the context header such as frequency, thresholds, and content in the 193 alarm (full header, header ID, timestamp), etc.) SHOULD be 194 configurable by the control plane. 196 This document adheres to the recommendations in [RFC8300] for 197 handling the context headers at both ingress and egress SFC boundary 198 nodes. That is, to strip such context headers. Revealing any 199 personal and subscriber-related information to third parties is 200 avoided by design to prevent privacy breaches in terms of user 201 tracking. 203 SFC-aware SFs and proxies MAY be instructed to strip a subscriber 204 identifier context header from the packet or to pass the data to the 205 next SF in the service chain after processing the content of the 206 context headers. If no instruction is provided, the default behavior 207 for intermediary SFC-aware nodes is to maintain such context headers 208 so that the information can be passed to next SFC-aware hops. 210 SFC-aware SFs MAY be instructed via the control plane about the 211 validation checks to run on the content of these context headers 212 (e.g., accept only some lengths) and the behavior to adopt. For 213 example, SFC-aware SFs may be instructed to ignore the context 214 header, to remove the context header from the packet, etc. 215 Nevertheless, this specification does not require nor preclude such 216 additional validation checks. These validation checks are 217 deployment-specific. If validation checks fail on a subscriber 218 identifier context header, an SFC-aware SF MUST ignore that context 219 header. The event SHOULD be logged locally while a notification 220 alarm MAY be sent to a Control Element if the SFC-aware SF is 221 instructed to do so. 223 Multiple subscriber Identifier context TLVs MAY be present in the NSH 224 each carrying a distinct opaque value but all pointing to the same 225 subscriber. When multiple subscriber identifier context TLVs are 226 present and an SF is instructed to strip the subscriber identifier 227 context header, that SF has to remove all subscriber identifier 228 context TLVs. 230 4. Performance Policy Identification NSH Variable-Length Context 231 Headers 233 Dedicated service-specific performance identifier is defined to 234 differentiate between services requiring specific treatment to 235 exhibit a performance characterized by, e.g., ultra-low latency (ULL) 236 or ultra-high reliability (UHR). Other policies can be considered 237 when instantiating a service function chain within an SFC-enabled 238 domain. They are conveyed in the Performance Policy Identifier 239 context header. 241 The performance policy identifier is inserted in an NSH packet so 242 that upstream SFC-aware nodes can make use of the performance 243 information for proper distributed SFC path selection, SF instance 244 selection, or policy selection at SFs. 246 Thus, the performance policy identifier allows for the distributed 247 enforcement of a per-service policy such as a service function path 248 to only include specific SFs instances. Details of this process are 249 implementation-specific. For illustration purposes, an SFF may 250 retrieve the details of usable SFs based upon the corresponding 251 performance policy identifier. Typical criteria for instantiating 252 specific SFs include location, performance, or proximity 253 considerations. For the particular case of UHR services, the stand- 254 by operation of back-up capacity or the deployment of multiple SF 255 instances may be requested. 257 Performance Policy Identifier is defined as optional variable length 258 context header. Its structure is shown in Figure 2. 260 Similar control plane considerations as those discussed in Section 3 261 are to be followed. 263 Multiple performance policy identifier context headers MAY be present 264 in the NSH; each carrying a distinct opaque value but all are 265 pointing to policies that need to be enforced for a flow. It is up 266 to the control plane to ensure that these policies are not 267 conflicting. When such conflict is detected by an SFC-aware node, 268 the default behavior of the node is to discard the packet and send a 269 notification alarm to a Control Element. 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Metadata Class | Type |U| Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 ~ Performance Policy Identifier ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 2: Performance Policy Identifier Variable-Length Context 281 Header 283 The description of the fields is as follows: 285 o Metadata Class: MUST be set to 0x0 [RFC8300]. 287 o Type: TBD2 (See Section 5) 289 o Performance Policy Identifier: Represents an opaque value pointing 290 to specific performance policy to be enforced. The structure and 291 semantic of this field is deployment-specific. 293 5. IANA Considerations 295 This document requests IANA to assign the following types from the 296 "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 297 IETF Base NSH MD Class) registry available at: 298 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 299 length-metadata-types. 301 +-------+-------------------------------+----------------+ 302 | Value | Description | Reference | 303 +-------+-------------------------------+----------------+ 304 | TBD1 | Subscriber Identifier | [ThisDocument] | 305 | TBD2 | Performance Policy Identifier | [ThisDocument] | 306 +-------+-------------------------------+----------------+ 308 6. Security Considerations 310 Data plane SFC-related security considerations, including privacy, 311 are discussed in [RFC7665] and [RFC8300]. 313 Nodes that are involved in an SFC-enabled domain are assumed to be 314 trusted ([RFC8300]). Means to check that only authorized nodes are 315 solicited when a packet is crossing an SFC-enabled domain are out of 316 scope of this document. 318 A misbehaving node within from the SFC-enabled domain may alter the 319 content of Subscriber and Performance Policy TLVs which may lead to 320 service disruption. Such attach is not unique to the TLVs documents 321 defined in the document; measures discussed in [RFC8300] are to be 322 followed. Also, integrity checks offered by the transport 323 encapsulation can be used to detect anomalies. 325 An SF maintaining logs for operational reasons MUST NOT log the 326 content of Subscriber and Performance Policy context headers received 327 in NSH packets if the SF does not use the content of that header for 328 its operation. 330 7. Acknowledgements 332 Comments from Joel Halpern on a previous version and by Carlos 333 Bernardos are appreciated. 335 Contributions and review by Christian Jacquenet, Danny Lachos, 336 Debashish Purkayastha, Christian Esteve Rothenberg, and Kyle Larose 337 are thankfully acknowledged. 339 8. Change Log 341 o submitted version -00 as a working group draft after adoption 343 o submitted version -01 for editorial improvements 345 o submitted version -02 with these changes: fixed the abbreviated 346 title, corrected typos, editorial improvements, rename policy 347 identifier as performance policy identifier 349 o 03: As discussed in Prague 350 (https://datatracker.ietf.org/meeting/104/materials/slides-104- 351 sfc-sfc-chair-slides-01), there was a question whether the authors 352 should investigate a solution specific to this I-D o cover 353 integrity protection, but this seems not the good option given 354 that this is a generic concerns for all TLVs. No change is thus 355 added to the document. 357 9. References 359 9.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 367 Chaining (SFC) Architecture", RFC 7665, 368 DOI 10.17487/RFC7665, October 2015, 369 . 371 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 372 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 373 May 2017, . 375 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 376 "Network Service Header (NSH)", RFC 8300, 377 DOI 10.17487/RFC8300, January 2018, 378 . 380 9.2. Informative References 382 [I-D.ietf-bess-nsh-bgp-control-plane] 383 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 384 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 385 nsh-bgp-control-plane-11 (work in progress), May 2019. 387 [I-D.ietf-sfc-use-case-mobility] 388 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 389 J. Uttaro, "Service Function Chaining Use Cases in Mobile 390 Networks", draft-ietf-sfc-use-case-mobility-09 (work in 391 progress), January 2019. 393 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 394 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 395 DOI 10.17487/RFC8459, September 2018, 396 . 398 Authors' Addresses 400 Behcet Sarikaya 401 Denpel Informatique 403 Email: sarikaya@ieee.org 405 Dirk von Hugo 406 Deutsche Telekom 407 Deutsche-Telekom-Allee 7 408 D-64295 Darmstadt 409 Germany 411 Email: Dirk.von-Hugo@telekom.de 413 Mohamed Boucadair 414 Orange 415 Rennes 3500 416 France 418 Email: mohamed.boucadair@orange.com