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