idnits 2.17.1 draft-napper-sfc-nsh-mobility-allocation-02.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 4, 2015) is 3095 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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: Informational Cisco Systems, Inc. 5 Expires: May 7, 2016 P. Muley 6 W. Hendericks 7 Alcatel-Lucent 8 November 4, 2015 10 NSH Context Header Allocation -- Mobility 11 draft-napper-sfc-nsh-mobility-allocation-02 13 Abstract 15 This document provides a recommended allocation of the mandatory 16 fixed context headers for a Network Service Header (NSH) within the 17 mobility service provider network context. NSH is described in 18 detail in [ietf-sfc-nsh]. This allocation is intended to support 19 uses cases as 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 May 7, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . 2 63 3. Network Service Header (NSH) Context Headers . . . . . . . . 3 64 4. Recommended Mobility Context Allocation . . . . . . . . . . . 3 65 5. Broadband Allocation Specifics . . . . . . . . . . . . . . . 4 66 6. Context Allocation and Control Plane Considerations . . . . . 6 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Service function chaining provides a mechanism for network traffic to 78 be forced through multiple service functions in a sequence. Metadata 79 can be useful to service functions. Network Service Headers (NSH) 80 provides support for carrying shared metadata between service 81 functions (and devices) using 4 fixed-length 32-bit context headers 82 as defined in [ietf-sfc-nsh]. NSH is then encapsulated within an 83 outer header for transport. 85 This document provides a recommended default allocation scheme for 86 the fixed-length context headers in the context of service chaining 87 within fixed and mobile broadband service provider networks. 88 Supporting use cases describing the need for a metadata header in 89 these contexts are described in [ietf-sfc-use-case-mobility]. This 90 draft does not address control plane mechanisms. 92 2. Definition Of Terms 94 This document uses the terms as defined in [RFC7498] and [RFC7665]. 96 3. Network Service Header (NSH) Context Headers 98 In Service Function Chaining, the Network Service Header is composed 99 of a 4-byte base header (BH1), a 4-byte service path header (SH1) and 100 four mandatory 4-byte context headers (CH1-CH4) as described in 101 [ietf-sfc-nsh]. 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 |Ver|O|C|R|R|R|R|R|R| Length | MD Type = 0x01| Next Protocol | BH1 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Service Path ID | Service Index | SH1 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Mandatory Context Header 1 | CH1 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Mandatory Context Header 2 | CH2 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Mandatory Context Header 3 | CH3 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Mandatory Context Header 4 | CH4 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1: Network Service Header - MD Type 0x01 120 4. Recommended Mobility Context Allocation 122 The following context header allocation provides information to 123 support service function chaining in a mobile service provider 124 network as described in [ietf-sfc-use-case-mobility]. 126 The set of context headers can be delivered to service functions that 127 can use the metadata within to enforce policy, communicate between 128 service functions, provide subscriber information and other 129 functionality. Several of the context headers are typed allowing for 130 different metadata to be provided to different service functions or 131 even to the same service function but on different packets within a 132 flow. Which metadata are sent to which service functions is decided 133 in the SFC control plane and is thus out of the scope of this 134 document. 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | R | Sub | Tag | Context ID | CH1 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Sub/Endpoint ID ~ CH2 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 ~ Sub/Endpoint ID (cont.) | CH3 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | ServiceTag | CH4 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 2: NSH Mobility Context Allocation 149 Figure 2 provides a high-level description of the fields in the 150 recommended allocation of the fixed context headers for a mobility 151 context. 153 5. Broadband Allocation Specifics 155 The intended use for each of the context header allocations is as 156 follows: 158 R - Reserved. 160 Sub - Sub/Endpoint ID type field. These bits determine the type of 161 the 64-bit Sub/Endpoint ID field that spans CH2 and CH3. 163 Tag - The Tag field indicates the type of the ServiceTag field in 164 CH4. 166 Context ID - The Context ID field allows the Subscriber/Endpoint ID 167 field to be scoped. For example, the Context ID field could 168 contain the incoming VRF, VxLAN VNID, VLAN, or policy identifier 169 within which the Subscriber/Endpoint ID field is defined. 171 Sub/App ID - 64-bit length Subscriber/Endpoint identifier (e.g., 172 IMSI, MSISDN, or implementation-specific Endpoint ID) of the 173 corresponding subscriber/machine/application for the flow. This 174 field is typed by the value of the Sub field as follows: 176 000 - If the Sub field is not set, then the 64-bit Sub/Endpoint 177 ID field is an opaque field that can be used or ignored by 178 service functions as determined by the control plane. 180 001 - The Sub/Endpoint ID field contains an IMSI [itu-e-164]. 182 010 - The Sub/Endpoint ID field contains an MSISDN (8-15 digit) 183 [itu-e-164]. 185 011 - The Sub/Endpoint ID field contains a 64-bit identifier that 186 can be used to group flows (e.g., in Machine-to-Machine, M2M). 188 100-111 - Reserved. 190 ServiceTag - A ServiceTag is a unique identifier that can carry 191 metadata specific to the flow or subscriber identified in the Sub/ 192 App ID field. Some types for this field are specified by the Tag 193 field as follows: 195 000 - If the Tag field is not set, then the ServiceTag field in 196 CH4 is an opaque field that can be used or ignored by service 197 functions as determined by the control plane. 199 001 - The ServiceTag field in CH4 contains information related to 200 the Radio Access Network (RAN) for the subscriber as follows in 201 Figure 3. Note that these values should correspond to those 202 that can be obtained for the flow from the corresponding 3GPP 203 PCRF (Policy and Charging Rules Function) component using 204 Diameter as described in [TS.29.230]. 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | CAN | QoS |U| Con | App Id | Rsvd | CH4 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 3: Service Tag RAN Allocation 213 CAN - IP-CAN-Type (Diameter AVP code 1027). 215 QoS - QoS-Class-Identifier AVP (Diameter AVP code 1028). 217 U - QoS-Upgrade AVP (Diameter AVP code 1030). 219 Con - Congestion level. 221 App Id - Application ID describing the flow type. Allocation 222 of IDs is done in the control plane and is out of the scope 223 of this document. 225 Rsvd - Reserved. 227 010-111 - Reserved. 229 6. Context Allocation and Control Plane Considerations 231 This document describes an allocation scheme for the mandatory 232 context headers in the context of mobile service providers. This 233 suggested allocation of context headers should be considered as a 234 guideline and may vary depending on the use case. The control plane 235 aspects of specifying and distributing the allocation scheme among 236 different service functions within the Service Function Chaining 237 environment to guarantee consistent semantics for the metadata is 238 beyond the scope of this document. 240 7. Security Considerations 242 The context header allocation recommended by this document includes 243 numbers that must be distributed consistently across a Service 244 Function Chaining environment. Protocols for distributing these 245 numbers securely are required in the control plane, but are out of 246 scope of this document. 248 Furthermore, some of the metadata carried in the context headers 249 require secure methods to prevent spoofing or modification by service 250 function elements that may themselves be exposed to subscriber 251 traffic and thus might be compromised. This document does not 252 address such security concerns. 254 8. IANA Considerations 256 This document has no actions for IANA. 258 9. Acknowledgments 260 The authors would like to thank Jim Guichard for his assistance 261 structuring the document. 263 10. References 265 10.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 269 RFC2119, March 1997, 270 . 272 10.2. Informative References 274 [ietf-sfc-nsh] 275 Quinn, P. and U. Elzur, "Network Service Header", I-D 276 draft-ietf-sfc-nsh-01 (work in progress), July 2015. 278 [ietf-sfc-use-case-mobility] 279 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 280 J. Uttaro, "Service Function Chaining Use Cases in Mobile 281 Networks", I-D draft-ietf-sfc-use-case-mobility-05 (work 282 in progress), January 2015. 284 [itu-e-164] 285 "The international public telecommunication numbering 286 plan", ITU-T E.164, November 2010. 288 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 289 Service Function Chaining", RFC 7498, DOI 10.17487/ 290 RFC7498, April 2015, 291 . 293 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 294 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/ 295 RFC7665, October 2015, 296 . 298 [TS.29.230] 299 "Diameter applications; 3GPP specific codes and 300 identifiers", 3GPP TS 29.230 13.2.0, September 2015. 302 Authors' Addresses 304 Jeffrey Napper 305 Cisco Systems, Inc. 307 Email: jenapper@cisco.com 309 Surendra Kumar 310 Cisco Systems, Inc. 312 Email: smkumar@cisco.com 314 Praveen Muley 315 Alcatel-Lucent 317 Email: praveen.muley@alcatel-lucent.com 319 Wim Hendericks 320 Alcatel-Lucent 322 Email: Wim.Henderickx@alcatel-lucent.com