idnits 2.17.1 draft-ietf-sfc-serviceid-header-06.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 (January 13, 2020) is 1559 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 330, 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-13 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: July 16, 2020 Deutsche Telekom 6 M. Boucadair 7 Orange 8 January 13, 2020 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-06 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 July 16, 2020. 42 Copyright Notice 44 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 This document discusses how to inform Service Functions (SFs, 75 [RFC7665]) about subscriber- and service-related information, when 76 required, for the sake of policy enforcement within a single 77 administrative domain. Particularly, subscriber-related information 78 may be required to enforce subscriber-specific SFC-based traffic 79 policies. Nevertheless, the information carried in packets may not 80 be sufficient to unambiguously identify a subscriber. This document 81 fills this void by specifying a new Network Service Header (NSH) 82 [RFC8300] context header to convey and disseminate such information 83 within the boundaries of a single administrative domain. 85 Also, the enforcement of SFC-based differentiated traffic policies 86 may be inferred, for example, by QoS (Quality of Service) 87 considerations. Typically, QoS information may serve as an input to 88 the Service Function Path (SFP) for path computation, establishment, 89 and selection. Furthermore, the dynamic structuring of service 90 function chains and their subsequent enforcement may be conditioned 91 by QoS requirements that will affect SF instance identification, 92 location, and sequencing. Hence, the need to supply a performance 93 policy identifier to upstream SFs to appropriately meet the service 94 requirements arises. 96 SFs and SF Forwarders (SFFs) involved in a service chain have to 97 contribute to the respective service policy (QoS, for example) 98 requirements characterized by low transmission delay between each 99 other, by exposing a high availability of resources to process 100 function tasks, or by redundancy provided by stand-by machines for 101 seamless execution continuation in case of failures. These 102 requirements may be satisfied by means of control plane protocols, 103 but in some contexts, e.g., in networks where resources are very much 104 constrained, carrying QoS-related information directly in packets may 105 improve the overall SFC operation instead of relying upon the 106 potential complexity or adding overhead introduced by some SFC 107 control plane features. This information is typically included as a 108 context header in the NSH. 110 The context information defined in this document can be applicable in 111 the context of mobile networks (particularly, in the 3GPP defined 112 (S)Gi Interface) [I-D.ietf-sfc-use-case-mobility]. Typically, 113 because of the widespread use of private addressing in those 114 networks, if SFs to be invoked are located after a NAT function, the 115 identification based on the internal IP address is not possible once 116 the NAT has been crossed. NAT functionality can reside in a distinct 117 node which for 3GPP network can be the Packet Data Network (PDN) 118 Gateway (PGW) as specified in [TS23401] in case of 4G or the User 119 Plane Function (UPF) facing the external Data Network (DN) [TS23501] 120 in case of 5G, respectively. As such, means to allow passing the 121 internal information may optimise packet traversal within an SFC- 122 enabled mobile network domain. Furthermore, some SFs that are not 123 enabled on the PGW/UPF may require a subscriber identifier to 124 properly operate. As such identifier one of already specified 3GPP 125 identifiers may serve (see, for example, those listed in [RFC8371]), 126 but it is out of scope of this document to include a comprehensive 127 list of deployment contexts which may make use of the context headers 128 defined in the document. 130 This document does not make any assumption about the structure of 131 subscriber or performance policy identifiers; each such identifier is 132 treated as an opaque value. The semantics and validation of these 133 identifiers are up to the control plane used for SFC within an SFC- 134 enabled domain. Expectations to SFC control plane protocols are laid 135 down, e.g., in [RFC8459], but specifications of SFC control plane 136 functions are also discussed in, for example, 137 [I-D.ietf-bess-nsh-bgp-control-plane]. Control plane related 138 considerations are out of scope. 140 This document assumes the NSH is used exclusively within a single 141 administrative domain. 143 This document adheres to the architecture defined in [RFC7665]. This 144 document assumes the reader is familiar with [RFC8300]. 146 2. Conventions and Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119][RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 The reader should be familiar with the terms defined in [RFC7665]. 156 3. Subscriber Identification NSH Variable-Length Context Header 158 Subscriber Identifier is defined as an optional variable-length NSH 159 context header. Its structure is shown in Figure 1. 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Metadata Class | Type |U| Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 ~ Subscriber Identifier ~ 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: Subscriber Identifier Variable-Length Context Header 172 The description of the fields is as follows: 174 o Metadata Class: MUST be set to 0x0 [RFC8300]. 176 o Type: TBD1 (See Section 5). 178 o U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]). 180 o Length: Indicates the length of the Subscriber Identifier, in 181 bytes (see Section 2.5.1 of [RFC8300]). 183 o Subscriber Identifier: Carries an opaque subscriber identifier. 185 The subscriber identifier is used to convey an identifier assigned by 186 the service provider to uniquely identify a subscriber. This 187 subscriber identifier can be used by service functions to enforce 188 per-subscriber policies (e.g., apply resource quota). 190 The classifier and SFC-aware SFs MAY be instructed via a control 191 interface to inject or strip a subscriber identifier context header. 192 Also, the data to be injected in such header SHOULD be configured to 193 nodes authorized to inject such headers. Typically, a node can be 194 instructed to insert such data following a type/set scheme (e.g., 195 node X should inject subscriber ID type Y). Other schemes may be 196 envisaged. 198 Failures to inject such headers SHOULD be logged locally while a 199 notification alarm MAY be sent to a Control Element. The details of 200 sending notification alarms (i.e., the parameters affecting the 201 transmission of the notification alarms depend on the information in 202 the context header such as frequency, thresholds, and content of the 203 alarm (full header, timestamp, etc.)) SHOULD be configurable by the 204 control plane. 206 This document adheres to the recommendations in [RFC8300] for 207 handling the context headers at both ingress and egress SFC boundary 208 nodes. That is, to strip such context headers. Revealing any 209 personal and subscriber-related information to third parties is 210 avoided by design to prevent privacy breaches in terms of user 211 tracking. 213 SFC-aware SFs and proxies MAY be instructed to strip a subscriber 214 identifier context header from the packet or to pass the data to the 215 next SF in the service chain after processing the content of the 216 context headers. If no instruction is provided, the default behavior 217 for intermediary SFC-aware nodes is to maintain such context headers 218 so that the information can be passed to next SFC-aware hops. 220 SFC-aware SFs MAY be instructed via the control plane about the 221 validation checks to run on the content of these context headers 222 (e.g., accept only some lengths) and the behavior to adopt. For 223 example, SFC-aware SFs may be instructed to ignore the context 224 header, to remove the context header from the packet, etc. 225 Nevertheless, this specification does not require nor preclude such 226 additional validation checks. These validation checks are 227 deployment-specific. If validation checks fail on a subscriber 228 identifier context header, an SFC-aware SF MUST ignore that context 229 header. The event SHOULD be logged locally while a notification 230 alarm MAY be sent to a Control Element if the SFC-aware SF is 231 instructed to do so. 233 Multiple subscriber Identifier context TLVs MAY be present in the NSH 234 each carrying a distinct opaque value but all pointing to the same 235 subscriber. When multiple subscriber identifier context TLVs are 236 present and an SF is instructed to strip the subscriber identifier 237 context header, that SF has to remove all subscriber identifier 238 context TLVs. 240 4. Performance Policy Identification NSH Variable-Length Context 241 Headers 243 Dedicated service-specific performance identifier is defined to 244 differentiate between services requiring specific treatment to 245 exhibit a performance characterized by, e.g., ultra-low latency (ULL) 246 or ultra-high reliability (UHR). Other policies can be considered 247 when instantiating a service function chain within an SFC-enabled 248 domain. They are conveyed in the Performance Policy Identifier 249 context header. 251 The performance policy identifier is inserted in an NSH packet so 252 that upstream SFC-aware nodes can make use of the performance 253 information for proper distributed SFC path selection, SF instance 254 selection, or policy selection at SFs. Note that the use of 255 performance policy identifier is not helpful if the path computation 256 is centralized and a strict SFP is passed by means of SFC control 257 plane to SFFs. 259 The performance policy identifier allows for the distributed 260 enforcement of a per-service policy such as a service function path 261 to only include specific SFs instances (e.g., SFs located within the 262 same DC or those that are exposing the shortest delay from an SFF). 263 Details of this process are implementation-specific. For 264 illustration purposes, an SFF may retrieve the details of usable SFs 265 based upon the corresponding performance policy identifier. Typical 266 criteria for instantiating specific SFs include location, 267 performance, or proximity considerations. For the particular case of 268 UHR services, the stand-by operation of back-up capacity or the 269 deployment of multiple SF instances may be requested. 271 In an environment characterised by frequent changes of link and path 272 behaviour, for example due to variable load or availablility caused 273 by propagation conditions on a wireless link, the SFP may have to be 274 adapted dynamically by on-the move SFC path and SF instance 275 selection. 277 Performance Policy Identifier is defined as optional variable length 278 context header. Its structure is shown in Figure 2. 280 Similar control plane considerations as those discussed in Section 3 281 are to be followed. 283 Multiple performance policy identifier context headers MAY be present 284 in the NSH; each carrying a distinct opaque value but all are 285 pointing to policies that need to be enforced for a flow. It is up 286 to the control plane to ensure that these policies are not 287 conflicting. When such conflict is detected by an SFC-aware node, 288 the default behavior of the node is to discard the packet and send a 289 notification alarm to a Control Element. 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Metadata Class | Type |U| Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 ~ Performance Policy Identifier ~ 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 2: Performance Policy Identifier Variable-Length Context 301 Header 303 The description of the fields is as follows: 305 o Metadata Class: MUST be set to 0x0 [RFC8300]. 307 o Type: TBD2 (See Section 5). 309 o U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]). 311 o Length: Indicates the length of the Performance Policy Identifier, 312 in bytes (see Section 2.5.1 of [RFC8300]). 314 o Performance Policy Identifier: Represents an opaque value pointing 315 to specific performance policy to be enforced. The structure and 316 semantic of this field is deployment-specific. 318 5. IANA Considerations 320 This document requests IANA to assign the following types from the 321 "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 322 IETF Base NSH MD Class) registry available at: 323 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 324 length-metadata-types. 326 +-------+-------------------------------+----------------+ 327 | Value | Description | Reference | 328 +-------+-------------------------------+----------------+ 329 | TBD1 | Subscriber Identifier | [ThisDocument] | 330 | TBD2 | Performance Policy Identifier | [ThisDocument] | 331 +-------+-------------------------------+----------------+ 333 6. Security Considerations 335 Data plane SFC-related security considerations, including privacy, 336 are discussed in [RFC7665] and [RFC8300]. 338 Nodes that are involved in an SFC-enabled domain are assumed to be 339 trusted ([RFC8300]). Means to check that only authorized nodes are 340 solicited when a packet is crossing an SFC-enabled domain are out of 341 scope of this document. 343 A misbehaving node within from the SFC-enabled domain may alter the 344 content of Subscriber and Performance Policy TLVs which may lead to 345 service disruption. Such attach is not unique to the TLVs documents 346 defined in the document; measures discussed in [RFC8300] are to be 347 followed. Also, integrity checks offered by the transport 348 encapsulation can be used to detect anomalies. 350 An SF maintaining logs for operational reasons MUST NOT log the 351 content of Subscriber and Performance Policy context headers received 352 in NSH packets if the SF does not use the content of that header for 353 its operation. 355 7. Acknowledgements 357 Comments from Joel Halpern on a previous version and by Carlos 358 Bernardos are appreciated. 360 Contributions and review by Christian Jacquenet, Danny Lachos, 361 Debashish Purkayastha, Christian Esteve Rothenberg, Kyle Larose, 362 Donald Eastlake, Qin Wu, and Shunsuke Homma are thankfully 363 acknowledged. 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 375 Chaining (SFC) Architecture", RFC 7665, 376 DOI 10.17487/RFC7665, October 2015, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 384 "Network Service Header (NSH)", RFC 8300, 385 DOI 10.17487/RFC8300, January 2018, 386 . 388 8.2. Informative References 390 [I-D.ietf-bess-nsh-bgp-control-plane] 391 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 392 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 393 nsh-bgp-control-plane-13 (work in progress), December 394 2019. 396 [I-D.ietf-sfc-use-case-mobility] 397 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 398 J. Uttaro, "Service Function Chaining Use Cases in Mobile 399 Networks", draft-ietf-sfc-use-case-mobility-09 (work in 400 progress), January 2019. 402 [RFC8371] Perkins, C. and V. Devarapalli, "Mobile Node Identifier 403 Types for MIPv6", RFC 8371, DOI 10.17487/RFC8371, July 404 2018, . 406 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 407 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 408 DOI 10.17487/RFC8459, September 2018, 409 . 411 [TS23401] 3GPP 23.401 16.5.0, "General Packet Radio Service (GPRS) 412 enhancements for Evolved Universal Terrestrial Radio 413 Access Network (E-UTRAN) access,", December 2019. 415 [TS23501] 3GPP 23.501 16.3.0, "System architecture for the 5G System 416 (5GS),", December 2019. 418 Authors' Addresses 420 Behcet Sarikaya 421 Denpel Informatique 423 Email: sarikaya@ieee.org 424 Dirk von Hugo 425 Deutsche Telekom 426 T-Online-Allee 1 427 D-64295 Darmstadt 428 Germany 430 Email: Dirk.von-Hugo@telekom.de 432 Mohamed Boucadair 433 Orange 434 Rennes 3500 435 France 437 Email: mohamed.boucadair@orange.com