idnits 2.17.1 draft-ietf-sfc-nsh-broadband-allocation-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 (June 19, 2018) is 2138 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) ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining J. Napper 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Kumar 5 Expires: December 21, 2018 Individual Contributor 6 P. Muley 7 W. Hendericks 8 Nokia 9 M. Boucadair 10 Orange 11 June 19, 2018 13 NSH Context Header Allocation for Broadband 14 draft-ietf-sfc-nsh-broadband-allocation-01 16 Abstract 18 This document provides a recommended allocation of Network Service 19 Header (NSH) context headers within the broadband service provider 20 network context. Both fixed and mobile deployments are considered. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 21, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Network Service Header (NSH) Context Headers: A Reminder . . 3 65 4. Recommended Context Allocation For Broadband . . . . . . . . 4 66 4.1. MD Type 0x01 Allocation Specifics . . . . . . . . . . . . 4 67 4.2. MD Type 0x02 Allocation Specifics . . . . . . . . . . . . 6 68 5. Context Allocation and Control Plane Considerations . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 Service Function Chaining (SFC) [RFC7665] provides a mechanism for 80 network traffic to be steered through an ordered list of Service 81 Functions (SFs). Furthermore, SFC allows to share metadata among 82 involved SFC data functional elements (classifiers and SFs). 83 Particularly, the Network Service Header (NSH, [RFC8300]) provides 84 support for carrying shared metadata either using a fixed context 85 header or as optional TLVs. 87 This document describes a recommended default allocation scheme for 88 the fixed-length context header used for SFC within fixed and mobile 89 broadband service provider networks. Also, the document defines 90 companion TLV types when MD Type 0x02 is used. The use cases 91 describing the need for metadata in these deployment contexts are 92 described in [I-D.ietf-sfc-use-case-mobility]. 94 This document does not address control plane considerations. The 95 reader may refer to [I-D.ietf-sfc-control-plane]. 97 2. Terminology 99 This document makes use of the terms as defined in [RFC7498], 100 [RFC7665], and [RFC8300]. 102 3. Network Service Header (NSH) Context Headers: A Reminder 104 The NSH is composed of a 4-byte base header (BH1), a 4-byte service 105 path header (SH1), and a fixed 16-byte context header in the case of 106 MD Type 0x01 or optional TLVs in the case of MD Type 0x02 [RFC8300]. 108 Figure 1 shows the format of the MD Type 0x01 NSH header. 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | BH1 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Service Path Identifier | Service Index | SH1 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | | 117 + + 118 | Fixed | 119 + Context Header + 120 | (16 Bytes) | 121 + + 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 1: Network Service Header (MD Type 0x01) 127 Figure 2 shows the MD Type 0x02 NSH header format. 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | BH1 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Service Path Identifier | Service Index | SH1 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | 136 ~ Variable Length Context Headers (opt.) ~ 137 | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 2: Network Service Header (MD Type 0x02) 142 4. Recommended Context Allocation For Broadband 144 The following header allocations provide information to support 145 service function chaining in a service provider network, for example 146 as described for mobility in [I-D.ietf-sfc-use-case-mobility]. 148 The set of metadata headers can be delivered to SFs that can use the 149 metadata within to enforce service policy, communicate between 150 service functions, provide subscriber information, and other 151 functionality. Several of the headers are typed allowing for 152 different metadata to be provided to different SFs or even to the 153 same SF but on different packets within a flow. 155 Which metadata are sent to which SFs is decided in the SFC control 156 plane and is thus out of the scope of this document. 158 4.1. MD Type 0x01 Allocation Specifics 160 Figure 3 provides a high-level description of the fields in the 161 recommended allocation of the fixed sixteen byte context header for a 162 broadband context. Each four byte word in the sixteen byte context 163 header is referred to as CH1, CH2, CH3, and CH4, respectively. 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | R | Sub | Tag | Context ID | CH1 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Sub/Endpoint ID ~ CH2 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 ~ Sub/Endpoint ID (cont.) | CH3 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Service Information | CH4 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 3: NSH Context Allocation 178 The intended use for each of the context header fields is as follows: 180 R: MUST be set to zero upon origination, and they MUST be ignored and 181 preserved unmodified by other NSH supporting elements. 183 Sub: Sub/Endpoint ID type field. These bits determine the type of 184 the 64-bit Sub/Endpoint ID field that spans CH2 and CH3. 186 000: The 64-bit Sub/Endpoint ID field is an opaque field that can 187 be used or ignored by SFs as determined by the control plane. 189 001: The Sub/Endpoint ID field contains an IMSI [itu-e-164]. 191 010: The Sub/Endpoint ID field contains an MSISDN (8-15 digit) 192 [itu-e-164]. 194 011: The Sub/Endpoint ID field contains a 64-bit identifier that 195 can be used to group flows (e.g., in Machine-to-Machine (M2M) 196 contexts). 198 100: The Sub/Endpoint IP field contains a wireline subscriber ID 199 in CH2, and CH3 contains the line identifier. 201 101-111: Reserved. 203 Tag: Indicates the type of the Service Information field in CH4. 204 The following values are defined: 206 000: If the Tag field is not set, the Service Information field 207 in CH4 is an opaque field that can be used or ignored by SFs as 208 determined by the control plane. 210 001: The Service Information field in CH4 contains information 211 related to the Access Network (AN) for the subscriber. This is 212 shown in Figure 4 for a 3GPP Radio Access Network (RAN). 214 Note that these values should correspond to those that can be 215 obtained for the flow from the corresponding 3GPP PCRF (Policy 216 and Charging Rules Function) component using Diameter as 217 described in [TS.29.230]. 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | CAN | QoS/DSCP | Con | App Id | Rsvd | CH4 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 4: Service Information RAN Allocation 226 CAN: IP-CAN-Type for IP Connectivity Access Network (Diameter 227 AVP code 1027). 229 QoS: QoS-Class-Identifier AVP (Diameter AVP code 1028) or 230 Differentiated Services Code Point (DSCP) marking as 231 described in [RFC2474]. 233 Con: Access congestion level. An Access Congestion level 234 '000' means an unknown/undefined congestion level. An 235 Access Congestion level '001' means no congestion. For 236 other values of Access Congestion level, a higher value 237 indicates a higher level of congestion. 239 App Id: Application ID describing the flow type. Allocation 240 of IDs is done using the control plane and is out of the 241 scope of this document. 243 Rsvd: Reserved. 245 010-111: Reserved. 247 Context ID: The Context ID field allows the Sub/Endpoint ID field to 248 be scoped. For example, the Context ID field may contain the 249 incoming VRF, VxLAN VNID, VLAN, or a policy identifier within 250 which the Sub/Endpoint ID field is defined. 252 Sub/Endpoint ID: 64-bit length Subscriber/Endpoint identifier (e.g., 253 IMSI, MSISDN, or implementation-specific Endpoint ID) of the 254 corresponding subscriber/machine/application for the flow. 256 Service Information: The Service Information field is a unique 257 identifier that can carry metadata specific to the flow or 258 subscriber identified in the Sub/Endpoint ID field. 260 4.2. MD Type 0x02 Allocation Specifics 262 Figure 5 depictes the format of the recommended allocation of the 263 variable length headers for a mobility context. 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | TLV Class = 3GPP |C| Type |U|U|U| Len | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Data ... 270 +-+-+-+-+-+-+-+-+ 272 Figure 5: TLV Allocation 274 The intended use of the header is for TLVs associated with 3GPP Radio 275 Access Networks as described in [TS.29.230]. This TLV can be used by 276 3GPP to extend the metadata as per use cases. Having this TLV helps 277 to carry more information that does not fit within the MD Type 0x01. 279 The Len field carries the total length. Type = 0x01 is reserved. If 280 set to 0x01, the TLV carries the 4 context headers as defined in 281 Section 4.1. 283 5. Context Allocation and Control Plane Considerations 285 This document describes an allocation scheme for both the fixed 286 context header (MD Type#1) and optional TLV headers (MD Type#2) in 287 the context of broadband service providers. This allocation of 288 headers should be considered as a guideline and may vary depending on 289 the use case. 291 The control plane aspects of specifying and distributing the 292 allocation scheme among different SFs within the Service Function 293 Chaining environment to guarantee consistent semantics for the 294 metadata is beyond the scope of this document. 296 6. Security Considerations 298 This specification relies on NSH to share metadata among SFC data 299 plane elements. Security-related consideration discussed in 300 [RFC8300] MUST be followed. 302 The recommended header allocation in this document includes sensitive 303 information that MUST NOT be revealed outside an SFC-enabled domain. 304 Those considerations are already discussed in [RFC8300]. NSH allows 305 by design to remove any NSH data before existing an SFC-enabled 306 domain. 308 Furthermore, means to prevent that illegitimate nodes insert spoofed 309 data MUST be supported. As a reminder, the NSH specification assumes 310 ingress boundary nodes strip any NSH data that may be present in a 311 packet. Misbehaving nodes from within an SFC-enabled domain may 312 alter the content of the NSH data. Such treats are discussed in 313 [RFC8300]. This document does not introduce new treats compared to 314 those discussed in [RFC8300]. 316 7. IANA Considerations 318 This document requests IANA to assign a TLV class for 3GPP to be used 319 for its use cases. 321 8. Acknowledgments 323 The authors would like to thank Jim Guichard for his assistance 324 structuring the document. 326 9. References 327 9.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 335 Chaining (SFC) Architecture", RFC 7665, 336 DOI 10.17487/RFC7665, October 2015, 337 . 339 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 340 "Network Service Header (NSH)", RFC 8300, 341 DOI 10.17487/RFC8300, January 2018, 342 . 344 9.2. Informative References 346 [I-D.ietf-sfc-control-plane] 347 Boucadair, M., "Service Function Chaining (SFC) Control 348 Plane Components & Requirements", draft-ietf-sfc-control- 349 plane-08 (work in progress), October 2016. 351 [I-D.ietf-sfc-use-case-mobility] 352 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 353 J. Uttaro, "Service Function Chaining Use Cases in Mobile 354 Networks", draft-ietf-sfc-use-case-mobility-08 (work in 355 progress), May 2018. 357 [itu-e-164] 358 "The international public telecommunication numbering 359 plan", ITU-T E.164, November 2010. 361 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 362 "Definition of the Differentiated Services Field (DS 363 Field) in the IPv4 and IPv6 Headers", RFC 2474, 364 DOI 10.17487/RFC2474, December 1998, 365 . 367 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 368 Service Function Chaining", RFC 7498, 369 DOI 10.17487/RFC7498, April 2015, 370 . 372 [TS.29.230] 373 "Diameter applications; 3GPP specific codes and 374 identifiers", 3GPP TS 29.230 14.5.0, July 2017. 376 Authors' Addresses 378 Jeffrey Napper 379 Cisco Systems, Inc. 381 Email: jenapper@cisco.com 383 Surendra Kumar 384 Individual Contributor 386 Email: surendra.stds@gmail.com 388 Praveen Muley 389 Nokia 391 Email: praveen.muley@nokia.com 393 Wim Hendericks 394 Nokia 396 Email: Wim.Henderickx@nokia.com 398 Mohamed Boucadair 399 Orange 400 France 402 Email: mohamed.boucadair@orange.com