idnits 2.17.1 draft-napper-sfc-nsh-broadband-allocation-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 12, 2017) is 2350 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) No issues found here. Summary: 0 errors (**), 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: May 16, 2018 Individual Contributor 6 P. Muley 7 W. Hendericks 8 Nokia 9 M. Boucadair 10 Orange 11 November 12, 2017 13 NSH Context Header Allocation -- Broadband 14 draft-napper-sfc-nsh-broadband-allocation-04 16 Abstract 18 This document provides a recommended allocation of context headers 19 for a Network Service Header (NSH) within the broadband service 20 provider network context. NSH is described in detail in 21 [ietf-sfc-nsh]. This allocation is intended to support uses cases as 22 defined in [ietf-sfc-use-case-mobility]. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 16, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 66 3. Network Service Header (NSH) Context Headers . . . . . . . . 3 67 4. Recommended Context Allocation . . . . . . . . . . . . . . . 4 68 4.1. MD Type 0x01 Allocation Specifics . . . . . . . . . . . . 4 69 4.2. MD Type 0x02 Allocation Specifics . . . . . . . . . . . . 7 70 5. Context Allocation and Control Plane Considerations . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 9.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Service function chaining provides a mechanism for network traffic to 82 be steered through multiple service functions in a sequence. 83 Metadata can be useful to service functions. The Network Service 84 Header (NSH) provides support for carrying shared metadata between 85 service functions (and devices) either using 4 fixed-length 32-bit 86 context headers or as optional TLVs as defined in [ietf-sfc-nsh]. 87 NSH is then encapsulated within an outer header for transport. 89 This document provides a recommended default allocation scheme for 90 the fixed-length context headers and for TLV types in the context of 91 service chaining within fixed and mobile broadband service provider 92 networks. Supporting use cases describing the need for a metadata 93 header in these contexts are described in 95 [ietf-sfc-use-case-mobility]. This draft does not address control 96 plane mechanisms. 98 2. Definition Of Terms 100 This document uses the terms as defined in [RFC7498] and [RFC7665]. 102 3. Network Service Header (NSH) Context Headers 104 In Service Function Chaining, the Network Service Header is composed 105 of a 4-byte base header (BH1), a 4-byte service path header (SH1) and 106 a mandatory 16-byte context header in the case of MD Type 0x01 and 107 optional TLVs in the case of MD Type 0x02 as described in 108 [ietf-sfc-nsh]. 110 The following Figure 1 shows the MD Type 0x01 mandatory context 111 headers. 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | BH1 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Service Path Identifier | Service Index | SH1 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | | 120 + + 121 | Fixed | 122 + Context Header + 123 | (16 Bytes) | 124 + + 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Figure 1: Network Service Header - MD Type 0x01 130 The following Figure 2 shows the MD Type 0x02 optional TLV header 131 format. 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | BH1 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Service Path Identifier | Service Index | SH1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | | 140 ~ Variable Length Context Headers (opt.) ~ 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 2: Network Service Header - MD Type 0x02 146 4. Recommended Context Allocation 148 The following header allocations provide information to support 149 service function chaining in a service provider network, for example 150 as described for mobility in [ietf-sfc-use-case-mobility]. 152 The set of metadata headers can be delivered to service functions 153 that can use the metadata within to enforce policy, communicate 154 between service functions, provide subscriber information and other 155 functionality. Several of the headers are typed allowing for 156 different metadata to be provided to different service functions or 157 even to the same service function but on different packets within a 158 flow. Which metadata are sent to which service functions is decided 159 in the SFC control plane and is thus out of the scope of this 160 document. 162 4.1. MD Type 0x01 Allocation Specifics 164 The following Figure 3 provides a high-level description of the 165 fields in the recommended allocation of the fixed sixteen byte 166 context headers for a mobility context. Each four byte word in the 167 sixteen byte context header is referred as CH1, CH2, CH3 and CH4, 168 respectively. 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | R | Sub | Tag | Context ID | CH1 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Sub/Endpoint ID ~ CH2 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 ~ Sub/Endpoint ID (cont.) | CH3 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Service Information | CH4 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 3: NSH Context Allocation 183 The intended use for each of the context header allocations is as 184 follows: 186 R - Reserved. 188 Sub - Sub/Endpoint ID type field. These bits determine the type of 189 the 64-bit Sub/Endpoint ID field that spans CH2 and CH3. 191 000 - If the Sub field is not set, then the 64-bit Sub/Endpoint 192 ID field is an opaque field that can be used or ignored by 193 service functions as determined by the control plane. 195 001 - The Sub/Endpoint ID field contains an IMSI [itu-e-164]. 197 010 - The Sub/Endpoint ID field contains an MSISDN (8-15 digit) 198 [itu-e-164]. 200 011 - The Sub/Endpoint ID field contains a 64-bit identifier that 201 can be used to group flows (e.g., in Machine-to-Machine, M2M). 203 100 - The Sub/Endpoint IP field contains a wireline subcriber ID 204 in CH2, and CH3 contains the home identifier. 206 101-111 - Reserved. 208 Tag - The Tag field indicates the type of the Service Information 209 field in CH4. Some types for this field are specified by the Tag 210 field as follows: 212 000 - If the Tag field is not set, then the Service Information 213 field in CH4 is an opaque field that can be used or ignored by 214 service functions as determined by the control plane. 216 001 - The Service Information field in CH4 contains information 217 related to the Access Network (AN) for the subscriber. This is 218 shown in Figure 4 for a 3GPP Radio Access Network (RAN). Note 219 that these values should correspond to those that can be 220 obtained for the flow from the corresponding 3GPP PCRF (Policy 221 and Charging Rules Function) component using Diameter as 222 described in [TS.29.230]. 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | CAN | QoS/DSCP | Con | App Id | Rsvd | CH4 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 4: Service Information RAN Allocation 231 CAN - IP-CAN-Type for IP Connectivity Access Network (Diameter 232 AVP code 1027). 234 QoS - QoS-Class-Identifier AVP (Diameter AVP code 1028) or 235 Differentiated Services Code Point (DSCP) marking as 236 described in [RFC2474]. 238 Con - Access congestion level. An Access Congestion level 000 239 means an unknown/undefined congestion level. An Access 240 Congestion level 001 means no congestion. For other values 241 of Access Congestion level, a higher value indicates a 242 higher level of congestion. 244 App Id - Application ID describing the flow type. Allocation 245 of IDs is done in the control plane and is out of the scope 246 of this document. 248 Rsvd - Reserved. 250 010-111 - Reserved. 252 Context ID - The Context ID field allows the Subscriber/Endpoint ID 253 field to be scoped. For example, the Context ID field could 254 contain the incoming VRF, VxLAN VNID, VLAN, or policy identifier 255 within which the Subscriber/Endpoint ID field is defined. 257 Sub/Endpoint ID - 64-bit length Subscriber/Endpoint identifier 258 (e.g., IMSI, MSISDN, or implementation-specific Endpoint ID) of 259 the corresponding subscriber/machine/application for the flow. 261 Service Information - The Service Information field is a unique 262 identifier that can carry metadata specific to the flow or 263 subscriber identified in the Sub/Endpoint ID field. 265 4.2. MD Type 0x02 Allocation Specifics 267 The following Figure 5 provides a high-level description of the 268 fields in the recommended allocation of the variable length headers 269 for a mobility context. 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 | TLV Class = 3GPP |C| Type |R|R|R| Len | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Data ... 276 +-+-+-+-+-+-+-+-+ 278 Figure 5: TLV Allocation 280 The intended use of the header is for TLVs associated with 3GPP Radio 281 Access Networks as described in [TS.29.230]. This TLV can be used by 282 3GPP to extend the metadata as per use cases. Having this TLV helps 283 to carry more information that does not fit within the MD Type 0x01. 285 The Len field carries the total length. Type = 0x01 is reserved. If 286 set to 0x01, the TLV carries the 4 context headers as defined in 287 Section 4.1. 289 5. Context Allocation and Control Plane Considerations 291 This document describes an allocation scheme for both the mandatory 292 context headers and optional TLV headers in the context of broadband 293 service providers. This suggested allocation of headers should be 294 considered as a guideline and may vary depending on the use case. 295 The control plane aspects of specifying and distributing the 296 allocation scheme among different service functions within the 297 Service Function Chaining environment to guarantee consistent 298 semantics for the metadata is beyond the scope of this document. 300 6. Security Considerations 302 The header allocation recommended by this document includes numbers 303 that must be distributed consistently across a Service Function 304 Chaining environment. Protocols for distributing these numbers 305 securely are required in the control plane, but are out of scope of 306 this document. 308 Furthermore, some of the metadata carried in the headers require 309 secure methods to prevent spoofing or modification by service 310 function elements that may themselves be exposed to subscriber 311 traffic and thus might be compromised. This document does not 312 address such security concerns. 314 7. IANA Considerations 316 This document requests IANA to assign a TLV class for 3GPP to be used 317 for its use cases. 319 8. Acknowledgments 321 The authors would like to thank Jim Guichard for his assistance 322 structuring the document. 324 9. References 326 9.1. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 9.2. Informative References 335 [ietf-sfc-nsh] 336 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 337 Header", I-D draft-ietf-sfc-nsh-15 (work in progress), 338 July 2017. 340 [ietf-sfc-use-case-mobility] 341 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 342 J. Uttaro, "Service Function Chaining Use Cases in Mobile 343 Networks", I-D draft-ietf-sfc-use-case-mobility-07 (work 344 in progress), October 2016. 346 [itu-e-164] 347 "The international public telecommunication numbering 348 plan", ITU-T E.164, November 2010. 350 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 351 "Definition of the Differentiated Services Field (DS 352 Field) in the IPv4 and IPv6 Headers", RFC 2474, 353 DOI 10.17487/RFC2474, December 1998, 354 . 356 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 357 Service Function Chaining", RFC 7498, 358 DOI 10.17487/RFC7498, April 2015, 359 . 361 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 362 Chaining (SFC) Architecture", RFC 7665, 363 DOI 10.17487/RFC7665, October 2015, 364 . 366 [TS.29.230] 367 "Diameter applications; 3GPP specific codes and 368 identifiers", 3GPP TS 29.230 14.5.0, July 2017. 370 Authors' Addresses 372 Jeffrey Napper 373 Cisco Systems, Inc. 375 Email: jenapper@cisco.com 377 Surendra Kumar 378 Individual Contributor 380 Email: surendra.stds@gmail.com 382 Praveen Muley 383 Nokia 385 Email: praveen.muley@nokia.com 387 Wim Hendericks 388 Nokia 390 Email: Wim.Henderickx@nokia.com 392 Mohamed Boucadair 393 Orange 395 Email: mohamed.boucadair@orange.com