idnits 2.17.1 draft-quinn-sfc-nsh-tlv-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... Context Headers MAY be added, immedia...' RFC 2119 keyword, line 103: '... Context Headers MUST be of an integer...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2016) is 2716 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NSH' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track U. Elzur 5 Expires: April 24, 2017 Intel 6 S. Majee 7 F5 8 J. Halpern 9 Ericsson 10 October 21, 2016 12 Network Service Header TLVs 13 draft-quinn-sfc-nsh-tlv-02.txt 15 Abstract 17 This draft describes Network Service Header (NSH) MD-Type 2 metadata 18 TLVs that can be used within a service function path. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. NSH Type 2 Format . . . . . . . . . . . . . . . . . . . . . . 4 56 3. NSH Type 2 TLVs . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 58 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 65 1. Introduction 67 Network Service Header [NSH] is the SFC encapsulation protocol used 68 to create Service Function Chains. As such, NSH provides two key 69 elements: 71 1. Service Function Path identification 73 2. Metadata 75 NSH further defines two metadata formats (MD Types): 1 and 2. MD 76 Type 1 defines fixed length, 16 byte metadata, whereas MD Type 2 77 defines a variable-length TLV format for metadata. This draft 78 defines some common TLVs for use with NSH MD Type 2. 80 This draft does not address metadata usage, updating/chaining of 81 metadata or other SFP functions. Those topics are described in NSH. 83 2. NSH Type 2 Format 85 A NSH is composed of a 4-byte Base Header, a 4-byte Service Path 86 Header and Context Headers. The Base Header identifies the MD-Type 87 in use: 89 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 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 Figure 1: NSH Base Header 96 Please refer to NSH [NSH] for a detailed header description. 98 When the base header specifies MD Type= 0x2, zero or more Variable 99 Length Context Headers MAY be added, immediately following the 100 Service Path Header. Therefore, Length = 0x2, indicates that only 101 the Base Header followed by the Service Path Header are present. The 102 number, indicated in the length field, of optional Variable Length 103 Context Headers MUST be of an integer indicating length in 4-bytes 104 words Figure 3 below depicts the format the context header. 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | TLV Class |C| Type |R|R|R| Len | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Variable Metadata | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 2: NSH TLV Format 116 3. NSH Type 2 TLVs 118 As per NSH, TLV Class 0-7 are reserved for standards use. In this 119 draft we use TLV Class 0 for the following Types: 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | TLV Class = 0x0 |C| Type |R|R|R| Len | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Variable Metadata | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Figure 3: NSH TLV Class=0x0 129 1. Forwarding Context 131 This TLV carries network-centric forwarding context, used for 132 segregation and forwarding scope. Forwarding context can take 133 several forms depending on the network environment. Commonly 134 used data includes VXLAN/VXLAN- GPE VNID, VRF identification or 135 VLAN. 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | TLV Class = 0x0 |C| Type=0x1 |R|R|R| L=0x2 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |CT (4)| Reserved | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Tentant ID | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Context Type (CT), 4 bits: 146 0x0: 24 bit VXLAN/LISP virtual network identifier (VNI) 147 0x1: 32 bit MPLS VPN label 148 0x2: VLAN 150 Figure 4: Forwarding Context 152 2. Subscriber/user Information 154 Subscriber information varies in both format and source 155 depending on network environment. A commonly used example is 156 PCRF information in mobile deployments. Considerations for 157 usage of this TLV are addressed in [subhost]. 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | TLV Class = 0x0 |C| Type=0x2 |R|R|R| L=var | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 |ST (4)| Reserved | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 ~ Sub Info ~ 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Subscriber Type (ST), 4 bits: 168 0x0: Hex 169 0x1: String 171 Figure 5: Subscriber/user Information 173 3. Host Identifier 175 Host Identifier (ID) varies based on the type of host ID being 176 conveyed. A common example is a host IP address. Guidelines 177 for host ID usage in a network are discussed in [subhost]. 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | TLV Class = 0x0 |C| Type=0x3 |R|R|R| L=var | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |HT (4)| Reserved | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 ~ Host ID ~ 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Subscriber Type (ST), 4 bits: 188 0x0: IP 189 0x1: MAC 190 0x4: other 192 Figure 6: Host Identifier 194 4. Tenant 196 Tenant identification is often used for segregation within a 197 multi-tenant environment. Orchestration system generated tenant 198 IDs are an example of such data. 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | TLV Class = 0x0 |C| Type=0x4 |R|R|R| L=0x3 | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |TT (4)| Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Tenant ID | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Tenant ID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Tenant Type (TT), 4 bits: 211 0x0: 32 bit 212 0x1: 64 bit 214 Figure 7: Tenant Identifier 216 5. Application ID 218 Application identification may be used for SF policy 219 enforcement. [NSH AppID] provides guidelines and examples of 220 such data. 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | TLV Class = 0x0 |C| Type=0x5 |R|R|R| L=0x2 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | App ID | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | App ID | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 8: Application ID 232 6. Content Type 234 Provides explicit information about the content being carried, 235 for example, type of video or content value for billing purposes 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | TLV Class = 0x0 |C| Type=0x6 |R|R|R| L=0x1 | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Content Type | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 9: Content Type 245 7. Ingress Network Information 247 This data identifies ingress network node, and, if required, 248 ingress interface. 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | TLV Class = 0x0 |C| Type=0x7 |R|R|R| L=0x2 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Node ID | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Source Interface/Port | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 10: Ingress Network Info 260 8. Flow ID 262 Flow ID provides a representation of flow. Akin, but not 263 identical to the usage described in [RFC6437] 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | TLV Class = 0x0 |C| Type=0x8 |R|R|R| L=0x1 | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Flow ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 11: Flow ID 273 9. Source and/or Destination Groups 275 Intent-based systems can use this data to express the logical 276 grouping of source and/or destination objects. 277 [GROUPBASEDPOLICY] and [GROUPPOLICY] provide examples of such a 278 system. 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | TLV Class = 0x0 |C| Type=0x9 |R|R|R| L=0x3 | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |GT(4) | Reserved | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Source Group | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Dest Group | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Group type (4): 291 0x1: Group Based Policy (GBP) end point group (EPG) 293 Figure 12: End Point Group 295 10. Universal Resource Identifier (URI) 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | TLV Class = 0x0 |C| Type=0xA |R|R|R| L=var | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |UT(4) | URI | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ URI ~ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 URI type (4): 306 0x1: URI in standard string format as defined in RFC 3986 307 0x2: URI represented in a compacted hash format 309 Figure 13: URI 311 11. MD-type 1 Data Center Allocation 313 [dc-alloc] describes a recommended NSH MD-type 1 allocation for 314 use in data center deployments. This TLV provides a equivalent 315 TLV allocation to facilitate MD type 1 to MD type 2 316 interoperability. 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | TLV Class = 0x0 |C| Type=0xB |R|R|R| L=0x4 | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |D| F |R| Source Node ID | Source Interface ID | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Reserved | Tenant ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Destination Class / Reserved | Source Class | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Opaque Service Class | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 14: MD-type 1 Data Center Allocation 332 12. MD-type 1 Mobility/Broadband Allocation 334 [broad-alloc] describes a recommended NSH MD-type 1 allocation 335 for use in mobility deployments. This TLV provides a equivalent 336 TLV allocation to help with MD type 1 to MD type 2 337 interoperability. 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | TLV Class = 0x0 |C| Type=0xC |R|R|R| L=0x4 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | R | Sub | Tag | Context ID | CH1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Sub/Endpoint ID ~ CH2 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 ~ Sub/Endpoint ID (cont.) | CH3 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | ServiceTag | CH4 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 15: MD-type 1 Mobility/Broadband Allocation 353 4. Security Considerations 355 NSH describes the requisite security considerations for protecting 356 NSH metadata. 358 5. Acknowledgments 360 The authors would like to thank Behcet Sarikaya, Dirk von Hugo and 361 Mohamed Boucadair for their work regarding usage of subscriber and 362 host information TLVs. 364 6. IANA Considerations 366 IANA is requested to create a new "Network Service Header (NSH) TLV 367 Type" registry. TLV types 0-127 are specified in this document. New 368 values are assigned via Standards Action [RFC5226]. 370 7. References 372 7.1. Normative References 374 [NSH] Quinn, P., Ed. and U. Elzur, Ed., "Network Service 375 Header", 2016. 377 7.2. Informative References 379 [GROUPBASEDPOLICY] 380 OpenStack, "Group Based Policy", 2014. 382 [GROUPPOLICY] 383 OpenDaylight, "Group Policy", 2014. 385 [NSH AppID] 386 Penno, R., Claise, B., and C. Fontaine, "Using Application 387 Identification in Services Function Chaining Metadata", 388 2015. 390 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 391 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 392 DOI 10.17487/RFC5226, May 2008, 393 . 395 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 396 "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ 397 RFC6437, November 2011, 398 . 400 [broad-alloc] 401 Napper, J., Kumar, S., Hendericks, W., and P. Muley, "NSH 402 Context Header Allocation -- Broadband", 2016, . 406 [dc-alloc] 407 Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, 408 P., Glavin, K., and Y. Laribi, "Network Service Header 409 (NSH) Context Header Allocation (Data Center)", 2016, . 413 [subhost] Sarikaya, B., von Hugo, D., and M. Boucadair, "Service 414 Function Chaining (SFC): Subscriber and Host 415 Identification Considerations", 2016. 417 Authors' Addresses 419 Paul Quinn 420 Cisco Systems, Inc. 422 Email: paulq@cisco.com 424 Uri Elzur 425 Intel 427 Email: uri.elzur@intel.com 429 Sumandra Majee 430 F5 432 Email: S.Majee@F5.com 434 Joel Halpern 435 Ericsson 437 Email: joel.halpern@ericsson.com