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