idnits 2.17.1 draft-guichard-sfc-nsh-dc-allocation-07.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 (August 18, 2017) is 2442 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-19 == Outdated reference: A later version (-01) exists of draft-mizrahi-intarea-packet-timestamps-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining J. Guichard 3 Internet-Draft Huawei 4 Intended status: Informational M. Smith 5 Expires: February 19, 2018 S. Kumar 6 Cisco Systems, Inc. 7 S. Majee 8 F5 Networks 9 P. Agarwal 10 Broadcom 11 K. Glavin 12 Riverbed 13 Y. Laribi 14 Citrix 15 T. Mizrahi 16 Marvell 17 August 18, 2017 19 Network Service Header (NSH) MD Type 1: Context Header Allocation (Data 20 Center) 21 draft-guichard-sfc-nsh-dc-allocation-07 23 Abstract 25 This document provides a recommended default allocation for the 26 Network Service Header (NSH) MD Type 1 fixed length context header 27 when NSH is used for Service Function Chaining within a data center. 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 February 19, 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 66 3. Recommended Data Center MD Type 1 Fixed Length Context 67 Allocation . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Data Center Allocation Specifics . . . . . . . . . . . . 3 69 4. Context Allocation and Control Plane Considerations . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Network Service Header (NSH) [I-D.ietf-sfc-nsh] provides a mechanism 81 to carry shared metadata between network devices and service 82 functions, and between service functions. When MD Type 1 is used, 83 such metadata is carried within a fixed length (16-bytes) context 84 header. 86 This document provides a recommended default allocation of the MD 87 Type 1 context header for Service Function Chaining [RFC7665] within 88 a data center. The context header may be used to support use cases 89 such as those described in [I-D.ietf-sfc-dc-use-cases]. 91 The goal of this document is to provide a reference allocation that 92 may be used with or without a control plane. It also serves as a 93 guide to implementers and network operators. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Definition Of Terms 103 This document uses the terms as defined in [RFC7498], [RFC7665], and 104 [I-D.ietf-sfc-nsh] . 106 3. Recommended Data Center MD Type 1 Fixed Length Context Allocation 108 The following context header allocation provides information used to 109 support SFC operation within a generic data center environment. 110 [I-D.ietf-sfc-dc-use-cases] provides an overview of data center use 111 cases to support the allocation. 113 The 16 bytes of Fixed Length Context Header is delivered to service 114 functions that may then use the metadata it carries for local policy 115 enforcement and other functionality. 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |D| F |R| Source Node ID | Source Interface ID | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Reserved | Tenant ID | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Destination Class / Reserved | Source Class | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Opaque Service Class | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Figure 1: NSH DC Context Allocation 130 3.1. Data Center Allocation Specifics 132 The specific 16 byte allocation of the Fixed Length Context Header is 133 as follows: 135 Flag bits: Bits 0-3 are flag bits. Bits 0-2 are defined in this 136 document and the remaining bit is reserved. 138 D bit: The D-bit is used to indicate whether the Destination Class 139 field in the 3rd word is used. If D-bit is not set then the field 140 is reserved. 142 F bits: Two-bit value that indicates the format of the Opaque 143 Service Class in the 4th word. 145 Source Node ID: An identifier indicating the source device where the 146 original traffic initially entered the Service Function Chain. This 147 identifier is unique within an SFC-enabled domain. 149 Source Interface ID: An identifier indicating the source interface 150 where the original traffic initially entered the Service Function 151 Chain. This identifier is scoped within the context of the Source 152 Node ID. 154 Tenant ID: The tenant identifier is used to represent the tenant that 155 the Service Function Chain is being applied to. The Tenant ID is a 156 unique value assigned by a control plane. The distribution of Tenant 157 ID's is outside the scope of this document. As an example 158 application of this field, hardware may insert a VRF ID, VLAN number 159 or VXLAN VNI. 161 Destination Class: The destination class represents the logical 162 classification of the destination of the traffic. This field is 163 optional and/or the Destination Class may not be known. The D-bit is 164 used to indicate that this field contains a valid Destination Class. 166 Source Class: represents the logical classification of the source of 167 the traffic. For example, this might represent a source application, 168 a group of like endpoints, or a set of users originating the traffic. 169 This grouping is done for the purposes of applying policy. Policy is 170 applied to groups rather than individual endpoints. 172 Opaque Service Class: A unique identifier that can carry metadata 173 specific to a Rendered Service Path, the format of which is specified 174 by the value of the F-bits as follows: 176 00: If the F-bits are not set, then the Opaque Service Class field 177 is not specified and can be used as determined by the control 178 plane. 180 01 (ServiceTag): a ServiceTag is used to identify a particular 181 flow, transaction or an application message unit. The ServiceTag 182 may be used to augment the source and/or destination class. A 183 ServiceTag is a unique identifier that can be used to enable 184 functionality such as classification bypass, slow path skipping 185 and flow programming. As part of the ServiceTag word, bit 0 is 186 the A bit and is used, when needed, to indicate acknowledgement of 187 a ServiceTag by a Service Function. 189 02 (Application ID): contains an application identification as 190 described in [RFC6759], and [I-D.penno-sfc-appid] 192 03 (Timestamp): indicates the time at which the packet was 193 received by the Classifier. 195 The Timestamp has two possible formats: 197 * A 32-bit nanosecond field (Figure 2), which uses the 32 least 198 significant bits of the IEEE 1588 [IEEE1588] timestamp format. 200 * The NTP [RFC5905] 32-bit Timestamp format (Figure 3), which is 201 one of the recommended timestamp formats in 202 [I-D.mizrahi-intarea-packet-timestamps]. 204 It is assumed that in a given administrative domain only one of 205 the formats will be used, and that the control plane determines 206 which timestamp format is used. 208 The two timestamp formats are illustrated in the following 209 figures. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Nanoseconds | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2: 32-bit Timestamp Format based on PTP [IEEE1588] 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Seconds | Fraction | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 3: NTP [RFC5905] 32-bit Timestamp Format 227 4. Context Allocation and Control Plane Considerations 229 The context header allocations specified in this document are one of 230 many possible allocation schemes and should be used as a guideline 231 only; that is to say these allocations may vary based upon deployment 232 specifics and use cases. The suggested allocation is valid with or 233 without a control plane but the semantics of context values MUST be 234 shared amongst participating nodes via some mechanism. The actual 235 method of defining and distributing the allocation scheme is outside 236 of the scope of this document. 238 5. Security Considerations 240 This document describes an allocation scheme for the metadata carried 241 within the NSH Fixed Length Context Header. This allocation includes 242 a number of identifiers that must be distributed to participating 243 network elements. While the control plane protocols for distributing 244 these identifiers is outside the scope of this document, any control 245 plane protocol should ensure that these identifiers are securely 246 distributed to the network elements participating in the SFC. 248 Additionally, many of the fields such as Source and Destination Class 249 described in the metadata directly impact the network policy applied 250 to the traffic flowing through the SFC. There is a risk that these 251 identifiers may be spoofed and proper precautions should be put in 252 place to ensure that these fields can only be updated by trusted 253 entities. Due to the importance of these fields, confidentiality may 254 also be required to ensure that traffic cannot be targeted for attack 255 based on the policy identifiers. This document does not directly 256 address these threats but provides input to the NSH specification as 257 requirements to be considered in securing the contents of the 258 metadata. 260 6. Acknowledgments 262 The authors would like to thank Mohamed Boucadair for his helpful 263 review and comments. 265 7. IANA Considerations 267 This document includes no request to IANA. 269 8. References 271 8.1. Normative References 273 [I-D.ietf-sfc-nsh] 274 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 275 Header (NSH)", draft-ietf-sfc-nsh-19 (work in progress), 276 August 2017. 278 [I-D.penno-sfc-appid] 279 Penno, R., Claise, B., Pignataro, C., and C. Fontaine, 280 "Using Application Identification in Services Function 281 Chaining Metadata", draft-penno-sfc-appid-05 (work in 282 progress), August 2016. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, . 289 [RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems 290 Export of Application Information in IP Flow Information 291 Export (IPFIX)", RFC 6759, DOI 10.17487/RFC6759, November 292 2012, . 294 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 295 Chaining (SFC) Architecture", RFC 7665, 296 DOI 10.17487/RFC7665, October 2015, . 299 8.2. Informative References 301 [I-D.ietf-sfc-dc-use-cases] 302 Kumar, S., Tufail, M., Majee, S., Captari, C., and S. 303 Homma, "Service Function Chaining Use Cases In Data 304 Centers", draft-ietf-sfc-dc-use-cases-06 (work in 305 progress), February 2017. 307 [I-D.mizrahi-intarea-packet-timestamps] 308 Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 309 Defining Packet Timestamps", draft-mizrahi-intarea-packet- 310 timestamps-00 (work in progress), June 2017. 312 [IEEE1588] 313 IEEE, "IEEE 1588 Standard for a Precision Clock 314 Synchronization Protocol for Networked Measurement and 315 Control Systems Version 2", 2008. 317 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 318 "Network Time Protocol Version 4: Protocol and Algorithms 319 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 320 . 322 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 323 Service Function Chaining", RFC 7498, 324 DOI 10.17487/RFC7498, April 2015, . 327 Authors' Addresses 329 Jim Guichard 330 Huawei 332 Email: james.n.guichard@huawei.com 334 Michael Smith 335 Cisco Systems, Inc. 337 Email: michsmit@cisco.com 339 Surendra Kumar 340 Cisco Systems, Inc. 342 Email: smkumar@cisco.com 344 Sumandra Majee 345 F5 Networks 346 90 Rio Robles 347 San Jose, CA 95134 349 Email: S.Majee@f5.com 351 Puneet Agarwal 352 Broadcom 354 Email: pagarwal@broadcom.com 356 Kevin Glavin 357 Riverbed 359 Email: Kevin.Glavin@riverbed.com 361 Youcef Laribi 362 Citrix 364 Email: Youcef.Laribi@citrix.com 365 Tal Mizrahi 366 Marvell 368 Email: talmi@marvell.com