idnits 2.17.1 draft-ietf-sfc-nsh-01.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 abstract seems to contain references ([SFC-arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 15 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 23, 2015) is 3190 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) == Missing Reference: 'RFC3022' is mentioned on line 172, but not defined == Missing Reference: 'RFC6146' is mentioned on line 172, but not defined == Missing Reference: 'RFC6296' is mentioned on line 172, but not defined == Unused Reference: 'RFC0791' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 1353, but no explicit reference was found in the text == Unused Reference: 'VXLAN-gpe' is defined on line 1378, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track U. Elzur, Ed. 5 Expires: January 24, 2016 Intel 6 July 23, 2015 8 Network Service Header 9 draft-ietf-sfc-nsh-01.txt 11 Abstract 13 This draft describes a Network Service Header (NSH) inserted onto 14 encapsulated packets or frames to realize service function paths. 15 NSH also provides a mechanism for metadata exchange along the 16 instantiated service path. NSH is the SFC encapsulation as per SFC 17 Architecture [SFC-arch] 19 1. Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 24, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 62 2.2. Problem Space . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3. NSH-based Service Chaining . . . . . . . . . . . . . . . . 8 64 3. Network Service Header . . . . . . . . . . . . . . . . . . . . 10 65 3.1. Network Service Header Format . . . . . . . . . . . . . . 10 66 3.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 10 67 3.3. Service Path Header . . . . . . . . . . . . . . . . . . . 12 68 3.4. NSH MD-type 1 . . . . . . . . . . . . . . . . . . . . . . 13 69 3.5. NSH MD-type 2 . . . . . . . . . . . . . . . . . . . . . . 13 70 3.5.1. Optional Variable Length Metadata . . . . . . . . . . 14 71 4. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . . . 18 73 6. Fragmentation Considerations . . . . . . . . . . . . . . . . . 19 74 7. Service Path Forwarding with NSH . . . . . . . . . . . . . . . 20 75 7.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . . 20 76 7.2. Mapping NSH to Network Overlay . . . . . . . . . . . . . . 22 77 7.3. Service Plane Visibility . . . . . . . . . . . . . . . . . 23 78 7.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . . 23 79 8. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 26 80 8.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 26 81 8.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . . 27 82 8.3. Service Path ID and Metadata . . . . . . . . . . . . . . . 29 83 9. NSH Encapsulation Examples . . . . . . . . . . . . . . . . . . 31 84 9.1. GRE + NSH . . . . . . . . . . . . . . . . . . . . . . . . 31 85 9.2. VXLAN-gpe + NSH . . . . . . . . . . . . . . . . . . . . . 31 86 9.3. Ethernet + NSH . . . . . . . . . . . . . . . . . . . . . . 32 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 88 11. Open Items for WG Discussion . . . . . . . . . . . . . . . . . 34 89 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 90 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 91 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 92 14.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . . 39 93 14.2. Network Service Header (NSH) Parameters . . . . . . . . . 39 94 14.2.1. NSH Base Header Reserved Bits . . . . . . . . . . . . 39 95 14.2.2. MD Type Registry . . . . . . . . . . . . . . . . . . . 39 96 14.2.3. TLV Class Registry . . . . . . . . . . . . . . . . . . 40 97 14.2.4. NSH Base Header Next Protocol . . . . . . . . . . . . 40 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 99 15.1. Normative References . . . . . . . . . . . . . . . . . . . 41 100 15.2. Informative References . . . . . . . . . . . . . . . . . . 41 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 103 2. Introduction 105 Service functions are widely deployed and essential in many networks. 106 These service functions provide a range of features such as security, 107 WAN acceleration, and server load balancing. Service functions may 108 be instantiated at different points in the network infrastructure 109 such as the wide area network, data center, campus, and so forth. 111 The current service function deployment models are relatively static, 112 and bound to topology for insertion and policy selection. 113 Furthermore, they do not adapt well to elastic service environments 114 enabled by virtualization. 116 New data center network and cloud architectures require more flexible 117 service function deployment models. Additionally, the transition to 118 virtual platforms requires an agile service insertion model that 119 supports dynamic and elastic service delivery; the movement of 120 service functions and application workloads in the network and the 121 ability to easily bind service policy to granular information such as 122 per-subscriber state and steer traffic to the requisite service 123 function(s) are necessary. 125 NSH defines a new dataplane protocol specifically for the creation of 126 dynamic service chains and is composed of the following elements: 128 1. Service Function Path identification 130 2. Transport independent service function chain 132 3. Per-packet network and service metadata or optional variable TLV 133 metadata. 135 NSH is designed to be easy to implement across a range of devices, 136 both physical and virtual, including hardware platforms. 138 An NSH aware control plane is outside the scope of this document. 140 The SFC Architecture document [SFC-arch] provides an overview of a 141 service chaining architecture that clearly defines the roles of the 142 various elements and the scope of a service function chaining 143 encapsulation. NSH is the SFC encapsulation defined in that draft. 145 2.1. Definition of Terms 146 Classification: Locally instantiated matching of traffic flows 147 against policy for subsequent application of the required set of 148 network service functions. The policy may be customer/network/ 149 service specific. 151 Service Function Forwarder (SFF): A service function forwarder is 152 responsible for forwarding traffic to one or more connected 153 service functions according to information carried in the NSH, as 154 well as handling traffic coming back from the SF. Additionally, a 155 service function forwarder is responsible for transporting traffic 156 to another SFF (in the same or different type of overlay), and 157 terminating the SFP. 159 Service Function (SF): A function that is responsible for specific 160 treatment of received packets. A Service Function can act at 161 various layers of a protocol stack (e.g., at the network layer or 162 other OSI layers). As a logical component, a Service Function can 163 be realized as a virtual element or be embedded in a physical 164 network element. One or more Service Functions can be embedded in 165 the same network element. Multiple occurrences of the Service 166 Function can exist in the same administrative domain. 168 One or more Service Functions can be involved in the delivery of 169 added-value services. A non-exhaustive list of abstract Service 170 Functions includes: firewalls, WAN and application acceleration, 171 Deep Packet Inspection (DPI), LI (Lawful Intercept), server load 172 balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], 173 HOST_ID injection, HTTP Header Enrichment functions, TCP 174 optimizer. 176 An SF may be NSH-aware, that is it receives and acts on 177 information in the NSH. The SF may also be NSH-unaware in which 178 case data forwarded to the SF does not contain NSH. 180 Service Function Chain (SFC): A service function chain defines an 181 ordered set of abstract service functions (SFs) and ordering 182 constraints that must be applied to packets and/or frames and/or 183 flows selected as a result of classification. An example of an 184 abstract service function is "a firewall". The implied order may 185 not be a linear progression as the architecture allows for SFCs 186 that copy to more than one branch, and also allows for cases where 187 there is flexibility in the order in which service functions need 188 to be applied. The term service chain is often used as shorthand 189 for service function chain. 191 Service Function Path (SFP): The Service Function Path is a 192 constrained specification of where packets assigned to a certain 193 service function path must go. While it may be so constrained as 194 to identify the exact locations, it can also be less specific. 195 The SFP provides a level of indirection between the fully abstract 196 notion of service chain as a sequence of abstract service 197 functions to be delivered, and the fully specified notion of 198 exactly which SFF/SFs the packet will visit when it actually 199 traverses the network. By allowing the control components to 200 specify this level of indirection, the operator may control the 201 degree of SFF/SF selection authority that is delegated to the 202 network. 204 Network Node/Element: Device that forwards packets or frames based 205 on outer header information. 207 Network Overlay: Logical network built on top of existing network 208 (the underlay). Packets are encapsulated or tunneled to create 209 the overlay network topology. 211 Network Service Header: provides SFP identification, and is used by 212 the NSH-aware functions, such as the Classifier, SFF and NSH-aware 213 SFs. In addition to SFP identification, the NSH may carry data 214 plane metadata. 216 Service Classifier: Logical function that performs classification 217 and imposes an NSH. The initial classifier imposes the initial 218 NSH and sends the NSH packet to the first SFF in the path. Non- 219 initial (i.e. subsequent) classification can occur as needed and 220 can alter, or create a new service path. 222 Network Locator: dataplane address, typically IPv4 or IPv6, used to 223 send and receive network traffic. 225 NSH Proxy: Removes and inserts NSH on behalf of an NSH-unaware 226 service function. The proxy node removes the NSH header and 227 delivers the original packet/frame via a local attachment circuit 228 to the service function. Examples of a local attachment circuit 229 include, but are not limited to: VLANs, IP in IP, GRE, VXLAN. 230 When complete, the Service Function returns the packet to the NSH 231 proxy via the same or different attachment circuit. The NSH 232 Proxy, in turn, re-imposes NSH on the returned packets. Often, an 233 SFF will act as an NSH-proxy when required. 235 2.2. Problem Space 237 Network Service Header (NSH) addresses several limitations associated 238 with service function deployments today (i.e. prior to use of NSH). 239 A short reference is included below, RFC 7498 [RFC7498], provides a 240 more comprehensive review of the SFC Problem Statement. 242 1. Topological Dependencies: Network service deployments are often 243 coupled to network topology. Such a dependency imposes 244 constraints on the service delivery, potentially inhibiting the 245 network operator from optimally utilizing service resources, and 246 reduces the flexibility. This limits scale, capacity, and 247 redundancy across network resources. 249 2. Service Chain Construction: Service function chains today are 250 most typically built through manual configuration processes. 251 These are slow and error prone. With the advent of newer dynamic 252 service deployment models, the control/management planes provide 253 not only connectivity state, but will also be increasingly 254 utilized for the creation of network services. Such a control/ 255 management planes could be centralized, or be distributed. 257 3. Application of Service Policy: Service functions rely on topology 258 information such as VLANs or packet (re) classification to 259 determine service policy selection, i.e. the service function 260 specific action taken. Topology information is increasingly less 261 viable due to scaling, tenancy and complexity reasons. The 262 topological information is often stale, providing the operator 263 with inaccurate service Function (SF) placement that can result 264 in suboptimal resource utilization. Furthermore topology-centric 265 information often does not convey adequate information to the 266 service functions, forcing functions to individually perform more 267 granular classification. 269 4. Per-Service (re)Classification: Classification occurs at each 270 service function independent from previously applied service 271 functions. More importantly, the classification functionality 272 often differs per service function and service functions may not 273 leverage the results from other service functions. 275 5. Common Header Format: Various proprietary methods are used to 276 share metadata and create service paths. A standardized protocol 277 provides a common format for all network and service devices. 279 6. Limited End-to-End Service Visibility: Troubleshooting service 280 related issues is a complex process that involve both network- 281 specific and service-specific expertise. This is especially the 282 case, when service function chains span multiple DCs, or across 283 administrative boundaries. Furthermore, physical and virtual 284 environments (network and service) can be highly divergent in 285 terms of topology and that topological variance adds to these 286 challenges. 288 7. Transport Dependence: Service functions can and will be deployed 289 in networks with a range of transports requiring service 290 functions to support and participate in many transports (and 291 associated control planes) or for a transport gateway function to 292 be present. 294 2.3. NSH-based Service Chaining 296 The NSH creates a dedicated service plane, that addresses many of the 297 limitations highlighted in Section 2.2. More specifically, NSH 298 enables: 300 1. Topological Independence: Service forwarding occurs within the 301 service plane, via a network overlay, the underlying network 302 topology does not require modification. NSH provides an 303 identifier used to select the network overlay for network 304 forwarding. 306 2. Service Chaining: NSH contains path identification information 307 needed to realize a service path. Furthermore, NSH provides the 308 ability to monitor and troubleshoot a service chain, end-to-end 309 via service-specific OAM messages. The NSH fields can be used by 310 administrators (via, for example a traffic analyzer) to verify 311 (account, ensure correct chaining, provide reports, etc.) the 312 path specifics of packets being forwarded along a service path. 314 3. NSH provides a mechanism to carry shared metadata between network 315 devices and service function, and between service functions. The 316 semantics of the shared metadata is communicated via a control 317 plane to participating nodes. Examples of metadata include 318 classification information used for policy enforcement and 319 network context for forwarding post service delivery. 321 4. Classification and re-classification: sharing the metadata allows 322 service functions to share initial and intermediate 323 classification results with downstream service functions saving 324 re-classification, where enough information was enclosed. 326 5. NSH offers a common and standards based header for service 327 chaining to all network and service nodes. 329 6. Transport Agnostic: NSH is transport independent and is carried 330 in an overlay, over existing underlays. If an existing overlay 331 topology provides the required service path connectivity, that 332 existing overlay may be used. 334 3. Network Service Header 336 A Network Service Header (NSH) contains service path information and 337 optionally metadata that are added to a packet or frame and used to 338 create a service plane. The original packets preceded by NSH, are 339 then encapsulated in an outer header for transport. 341 NSH is added by a Service Classifier. The NSH header is removed by 342 the last SFF in the chain or by a SF that consumes the packet. 344 3.1. Network Service Header Format 346 A NSH is composed of a 4-byte Base Header, a 4-byte Service Path 347 Header and Context Headers, as shown in Figure 1 below. 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Base Header | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Service Path Header | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | | 356 ~ Context Headers ~ 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Figure 1: Network Service Header 362 Base header: provides information about the service header and the 363 payload protocol. 365 Service Path Header: provide path identification and location within 366 a path. 368 Context headers: carry opaque metadata and variable length encoded 369 information. 371 3.2. NSH Base Header 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 2: NSH Base Header 379 Base Header Field Descriptions: 381 Version: The version field is used to ensure backward compatibility 382 going forward with future NSH updates. It MUST be set to 0x0 by the 383 sender, in this first revision of NSH. 385 O bit: when set to 0x1 indicates that this packet is an operations 386 and management (OAM) packet. The receiving SFF and SFs nodes MUST 387 examine the payload and take appropriate action (e.g. return status 388 information). 390 OAM message specifics and handling details are outside the scope of 391 this document. 393 C bit: Indicates that a critical metadata TLV is present (see Section 394 3.4.2). This bit acts as an indication for hardware implementers to 395 decide how to handle the presence of a critical TLV without 396 necessarily needing to parse all TLVs present. The C bit MUST be set 397 to 0x0 when MD Type= 0x01 and MAY be used with MD Type = 0x2 and MUST 398 be set to 0x1 if one or more critical TLVs are present. 400 All other flag fields are reserved. 402 Length: total length, in 4-byte words, of NSH including the Base 403 Header, the Service Path Header and the optional variable TLVs. The 404 Length MUST be of value 0x6 for MD Type = 0x1 and MUST be of value 405 0x2 or higher for MD Type = 0x2. The NSH header length MUST be an 406 integer number of 4 bytes. 408 MD Type: indicates the format of NSH beyond the mandatory Base Header 409 and the Service Path Header. MD Type defines the format of the 410 metadata being carried. A new registry will be requested from IANA 411 for the MD Type. 413 NSH defines two MD types: 415 0x1 - which indicates that the format of the header includes fixed 416 length context headers (see Figure 4 below). 418 0x2 - which does not mandate any headers beyond the Base Header and 419 Service Path Header, and may contain optional variable length context 420 information. 422 The format of the base header and the service path header is 423 invariant, and not affected by MD Type. 425 NSH implementations MUST support MD-Type = 0x1, and SHOULD support 426 MD- Type = 0x2. 428 Next Protocol: indicates the protocol type of the original packet. A 429 new IANA registry will be created for protocol type. 431 This draft defines the following Next Protocol values: 433 0x1 : IPv4 434 0x2 : IPv6 435 0x3 : Ethernet 436 0x253: Experimental 438 3.3. Service Path Header 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Service Path ID | Service Index | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Service path ID (SPI): 24 bits 446 Service index (SI): 8 bits 448 Figure 3: NSH Service Path Header 450 Service Path Identifier (SPI): identifies a service path. 451 Participating nodes MUST use this identifier for Service Function 452 Path selection. 454 Service Index (SI): provides location within the SFP. The first 455 Classifier (i.e. at the boundary of the NSH domain)in the NSH Service 456 Function Path, SHOULD set the SI to 255, however the control plane 457 MAY configure the initial value of SI as appropriate (i.e. taking 458 into account the length of the service function path). A Classifier 459 MUST send the packet to the first SFF in the chain. Service index 460 MUST be decremented by service functions or proxy nodes after 461 performing required services and the new decremented SI value MUST be 462 reflected in the egress NSH packet. SI MAY be used in conjunction 463 with Service Path ID for Service Function Path selection. Service 464 Index (SI) is also valuable when troubleshooting/reporting service 465 paths. In addition to indicating the location within a Service 466 Function Path, SI can be used for loop detection. 468 3.4. NSH MD-type 1 470 When the Base Header specifies MD Type = 0x1, four Context Header, 471 4-byte each, MUST be added immediately following the Service Path 472 Header, as per Figure 4. Context Headers that carry no metadata MUST 473 be set to zero. 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Service Path ID | Service Index | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Mandatory Context Header | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Mandatory Context Header | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Mandatory Context Header | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Mandatory Context Header | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 4: NSH MD-type=0x1 492 Draft-dc [dcalloc] and draft-mobility [moballoc] provide specific 493 examples of how metadata can be allocated. 495 3.5. NSH MD-type 2 497 When the base header specifies MD Type= 0x2, zero or more Variable 498 Length Context Headers MAY be added, immediately following the 499 Service Path Header. Therefore, Length = 0x2, indicates that only 500 the Base Header followed by the Service Path Header are present. The 501 optional Variable Length Context Headers MUST be of an integer number 502 of 4-bytes. 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Service Path ID | Service Index | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | | 511 ~ Variable Length Context Headers (opt.) ~ 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 5: NSH MD-type=0x2 517 3.5.1. Optional Variable Length Metadata 519 The format of the optional variable length context headers, is as 520 described below. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | TLV Class |C| Type |R|R|R| Len | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Variable Metadata | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 6: Variable Context Headers 532 TLV Class: describes the scope of the "Type" field. In some cases, 533 the TLV Class will identify a specific vendor, in others, the TLV 534 Class will identify specific standards body allocated types. A new 535 IANA registry will be created for TLV Class type. 537 Type: the specific type of information being carried, within the 538 scope of a given TLV Class. Value allocation is the responsibility 539 of the TLV Class owner. 541 Encoding the criticality of the TLV within the Type field is 542 consistent with IPv6 option types: the most significant bit of the 543 Type field indicates whether the TLV is mandatory for the receiver to 544 understand/process. This effectively allocates Type values 0 to 127 545 for non-critical options and Type values 128 to 255 for critical 546 options. Figure 7 below illustrates the placement of the Critical 547 bit within the Type field. 549 +-+-+-+-+-+-+-+-+ 550 |C| Type | 551 +-+-+-+-+-+-+-+-+ 553 Figure 7: Critical Bit Placement Within the TLV Type Field 555 If a receiver receives an encapsulated packet containing a TLV with 556 the Critical bit set to 0x1 in the Type field and it does not 557 understand how to process the Type, it MUST drop the packet. Transit 558 devices MUST NOT drop packets based on the setting of this bit. 560 Reserved bits: three reserved bit are present for future use. The 561 reserved bits MUST be set to 0x0. 563 Length: Length of the variable metadata, in 4-byte words. A value of 564 0x0 or higher can be used. A value of 0x0 denotes a TLV header 565 without a Variable Metadata field. 567 4. NSH Actions 569 NSH-aware nodes are the only nodes that MAY alter the content of the 570 NSH headers. NSH-aware nodes include: service classifiers, SFF, SF 571 and NSH proxies. These nodes have several possible header related 572 actions: 574 1. Insert or remove NSH: These actions can occur at the start and 575 end respectively of a service path. Packets are classified, and 576 if determined to require servicing, NSH will be imposed. A 577 service classifier MUST insert NSH at the start of an SFP. An 578 imposed NSH MUST contain valid Base Header and Service Path 579 Header. At the end of a service function path, a SFF, MUST be 580 the last node operating on the service header and MUST remove it. 582 Multiple logical classifiers may exist within a given service 583 path. Non-initial classifiers may re-classify data and that re- 584 classification MAY result in a new Service Function Path. When 585 the logical classifier performs re-classification that results in 586 a change of service path, it MUST remove the existing NSH and 587 MUST impose a new NSH with the Base Header and Service Path 588 Header reflecting the new service path information and set the SI 589 to 255. Metadata MAY be preserved in the new NSH. 591 2. Select service path: The Service Path Header provides service 592 chain information and is used by SFFs to determine correct 593 service path selection. SFFs MUST use the Service Path Header 594 for selecting the next SF or SFF in the service path. 596 3. Update a Service Path Header: NSH aware service functions (SF) 597 MUST decrement the service index. A service index = 0x0 598 indicates that a packet MUST be dropped by the SFF. 600 Classifier(s) MAY update Context Headers if new/updated context 601 is available. 603 If an NSH proxy (see Section 7) is in use (acting on behalf of a 604 non-NSH-aware service function for NSH actions), then the proxy 605 MUST update Service Index and MAY update contexts. When an NSH 606 proxy receives an NSH-encapsulated packet, it MUST remove the NSH 607 headers before forwarding it to an NSH unaware SF. When the NSH 608 Proxy receives a packet back from an NSH unaware SF, it MUST re- 609 encapsulate it with the correct NSH, and MUST also decrement the 610 Service Index. 612 4. Service policy selection: Service Function instances derive 613 policy (i.e. service actions such as permit or deny) selection 614 and enforcement from the service header. Metadata shared in the 615 service header can provide a range of service-relevant 616 information such as traffic classification. Service functions 617 SHOULD use NSH to select local service policy. 619 Figure 8 maps each of the four actions above to the components in the 620 SFC architecture that can perform it. 622 +---------------+------------------+-------+----------------+---------+ 623 | | Insert |Select | Update |Service | 624 | | or remove NSH |Service| NSH |policy | 625 | | |Function| |selection| 626 | Component +--------+--------+Path +----------------+ | 627 | | | | | Dec. |Update | | 628 | | Insert | Remove | |Service |Context| | 629 | | | | | Index |Header | | 630 +----------------+--------+--------+-------+--------+-------+---------+ 631 | | + | + | | | + | | 632 |Classifier | | | | | | | 633 +--------------- +--------+--------+-------+--------+-------+---------+ 634 |Service Function| | + | + | | | | 635 |Forwarder(SFF) | | | | | | | 636 +--------------- +--------+--------+-------+--------+-------+---------+ 637 |Service | | | | + | | + | 638 |Function (SF) | | | | | | | 639 +--------------- +--------+--------+-------+--------+-------+---------+ 640 |NSH Proxy | + | + | | + | | | 641 +----------------+--------+--------+-------+--------+-------+---------+ 643 Figure 8: NSH Action and Role Mapping 645 5. NSH Encapsulation 647 Once NSH is added to a packet, an outer encapsulation is used to 648 forward the original packet and the associated metadata to the start 649 of a service chain. The encapsulation serves two purposes: 651 1. Creates a topologically independent services plane. Packets are 652 forwarded to the required services without changing the 653 underlying network topology 655 2. Transit network nodes simply forward the encapsulated packets as 656 is. 658 The service header is independent of the encapsulation used and is 659 encapsulated in existing transports. The presence of NSH is 660 indicated via protocol type or other indicator in the outer 661 encapsulation. 663 See Section 9 for NSH encapsulation examples. 665 6. Fragmentation Considerations 667 Work in progress: discussion of jumbo frames and PMTUD implications. 669 7. Service Path Forwarding with NSH 671 7.1. SFFs and Overlay Selection 673 As described above, NSH contains a Service Path Identifier (SPI) and 674 a Service Index (SI). The SPI is, as per its name, an identifier. 675 The SPI alone cannot be used to forward packets along a service path. 676 Rather the SPI provide a level of indirection between the service 677 path/topology and the network transport. Furthermore, there is no 678 requirement, or expectation of an SPI being bound to a pre-determined 679 or static network path. 681 The Service Index provides an indication of location within a service 682 path. The combination of SPI and SI provides the identification of a 683 logical SF and its order within the service plane, and is used to 684 select the appropriate network locator(s) for overlay forwarding. 685 The logical SF may be a single SF, or a set of SFs that are 686 equivalent. In the latter case, the SFF provides load distribution 687 amongst the collection of SFs as needed. SI may also serve as a 688 mechanism for loop detection within a service path since each SF in 689 the path decrements the index; an Service Index of 0 indicates that a 690 loop occurred and packet must be discarded. 692 This indirection -- path ID to overlay -- creates a true service 693 plane. That is the SFF/SF topology is constructed without impacting 694 the network topology but more importantly service plane only 695 participants (i.e. most SFs) need not be part of the network overlay 696 topology and its associated infrastructure (e.g. control plane, 697 routing tables, etc.). As mentioned above, an existing overlay 698 topology may be used provided it offers the requisite connectivity. 700 The mapping of SPI to transport occurs on an SFF (as discussed above, 701 the first SFF in the path gets a NSH encapsulated packet from the 702 Classifier). The SFF consults the SPI/ID values to determine the 703 appropriate overlay transport protocol (several may be used within a 704 given network) and next hop for the requisite SF. Figure 9 below 705 depicts a simple, single next-hop SPI/SI to network overlay network 706 locator mapping. 708 +-------------------------------------------------------+ 709 | SPI | SI | NH | Transport | 710 +-------------------------------------------------------+ 711 | 10 | 255 | 1.1.1.1 | VXLAN-gpe | 712 | 10 | 254 | 2.2.2.2 | nvGRE | 713 | 10 | 251 | 10.1.2.3 | GRE | 714 | 40 | 251 | 10.1.2.3 | GRE | 715 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 716 | 15 | 212 | Null (end of path) | None | 717 +-------------------------------------------------------+ 719 Figure 9: SFF NSH Mapping Example 721 Additionally, further indirection is possible: the resolution of the 722 required SF network locator may be a localized resolution on an SFF, 723 rather than a service function chain control plane responsibility, as 724 per figures 10 and 11 below. 726 +-------------------+ 727 | SPI | SI | NH | 728 +-------------------+ 729 | 10 | 3 | SF2 | 730 | 245 | 12 | SF34 | 731 | 40 | 9 | SF9 | 732 +-------------------+ 734 Figure 10: NSH to SF Mapping Example 736 +-----------------------------------+ 737 | SF | NH | Transport | 738 +-----------------------------------| 739 | SF2 | 10.1.1.1 | VXLAN-gpe | 740 | SF34| 192.168.1.1 | UDP | 741 | SF9 | 1.1.1.1 | GRE | 742 +-----------------------------------+ 744 Figure 11: SF Locator Mapping Example 746 Since the SPI is a representation of the service path, the lookup may 747 return more than one possible next-hop within a service path for a 748 given SF, essentially a series of weighted (equally or otherwise) 749 overlay links to be used (for load distribution, redundancy or 750 policy), see Figure 12. The metric depicted in Figure 12 is an 751 example to help illustrated weighing SFs. In a real network, the 752 metric will range from a simple preference (similar to routing next- 753 hop), to a true dynamic composite metric based on some service 754 function-centric state (including load, sessions state, capacity, 755 etc.) 757 +----------------------------------+ 758 | SPI | SI | NH | Metric | 759 +----------------------------------+ 760 | 10 | 3 | 10.1.1.1 | 1 | 761 | | | 10.1.1.2 | 1 | 762 | | | | | 763 | 20 | 12 | 192.168.1.1 | 1 | 764 | | | 10.2.2.2 | 1 | 765 | | | | | 766 | 30 | 7 | 10.2.2.3 | 10 | 767 | | | 10.3.3.3 | 5 | 768 +----------------------------------+ 769 (encap type omitted for formatting) 771 Figure 12: NSH Weighted Service Path 773 7.2. Mapping NSH to Network Overlay 775 As described above, the mapping of SPI to network topology may result 776 in a single overlay path, or it might result in a more complex 777 topology. Furthermore, the SPIx to overlay mapping occurs at each 778 SFF independently. Any combination of topology selection is 779 possible. Please note, there is no requirement to create a new 780 overlay topology if a suitable one already existing. NSH packets can 781 use any (new or existing) overlay provided the requisite connectivity 782 requirements are satisfied. 784 Examples of mapping for a topology: 786 1. Next SF is located at SFFb with locator 10.1.1.1 787 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 10.1.1.1 789 2. Next SF is located at SFFc with multiple network locators for 790 load distribution purposes: 791 SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:10.2.2.1, 10.2.2.2, 792 10.2.2.3, equal cost 794 3. Next SF is located at SFFd with two paths to SFFc, one for 795 redundancy: 796 SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:10.1.1.1 cost=10, 797 10.1.1.2, cost=20 799 In the above example, each SFF makes an independent decision about 800 the network overlay path and policy for that path. In other words, 801 there is no a priori mandate about how to forward packets in the 802 network (only the order of services that must be traversed). 804 The network operator retains the ability to engineer the overlay 805 paths as required. For example, the overlay path between service 806 functions forwarders may utilize traffic engineering, QoS marking, or 807 ECMP, without requiring complex configuration and network protocol 808 support to be extended to the service path explicitly. In other 809 words, the network operates as expected, and evolves as required, as 810 does the service function plane. 812 7.3. Service Plane Visibility 814 The SPI and SI serve an important function for visibility into the 815 service topology. An operator can determine what service path a 816 packet is "on", and its location within that path simply by viewing 817 the NSH information (packet capture, IPFIX, etc.). The information 818 can be used for service scheduling and placement decisions, 819 troubleshooting and compliance verification. 821 7.4. Service Graphs 823 In some cases, a service path is exactly that -- a linear list of 824 service functions that must be traversed. However, the "path" is 825 actually a directed graph. Furthermore, within a given service 826 topology several directed graphs may exist with packets moving 827 between graphs based on non-initial classification (in Figure 13, co- 828 located with the SFs). 830 ,---. ,---. ,---. 831 / \ / \ / \ 832 ( SF2 +------+ SF7 +--------+ SF3 ) 833 ,------\ / \ / /-+ / 834 ; |---' `---'\ / `-+-' 835 | : \ / 836 | \ /---:--- 837 ,-+-. `. ,---. / : 838 / \ '---+ \/ \ 839 ( SF1 ) ( SF6 ) \ 840 \ / \ +--. : 841 `---' `---' `-. ,-+-. 842 `+ \ 843 ( SF4 ) 844 \ / 845 `---' 847 Figure 13: Service Graph Example 849 The SPI/SI combination provides a simple representation of a directed 850 graph, the SPI represents a graph ID; and the SI a node ID. The 851 service topology formed by SPI/SI support cycles, weighting, and 852 alternate topology selection, all within the service plane. The 853 realization of the network topology occurs as described above: SPI/ID 854 mapping to an appropriate transport and associated next network hops. 856 NSH-aware services receive the entire header, including the SPI/SI. 857 An non-initial logical classifier (in many deployment, this 858 classifier will be co-resident with a SF) can now, based on local 859 policy, alter the SPI, which in turn effects both the service graph, 860 and in turn the selection of overlay at the SFF. The figure below 861 depicts the policy associated with the graph in Figure 13 above. 862 Note: this illustrates multiple graphs and their representation; it 863 does not depict the use of metadata within a single service function 864 graph. 866 SF1: 867 SPI: 10 868 NH: SF2 869 SF2: 870 Class: Bad 871 SPI: 20 872 NH: SF6 873 Class: Good 874 SPI: 30 875 NH: SF7 876 SF6: 877 Class: Employee 878 SPI: 21 879 NH: SF4 880 Class: Guest 881 SPI: 22 882 NH: SF3 883 SF7: 884 Class: Employee 885 SPI: 31 886 NH: SF4 887 Class: Guest 888 SPI: 32 889 NH: SF3 891 Figure 14: Service Graphs Using SPI 893 This example above does not show the mapping of the service topology 894 to the network overlay topology. As discussed in the sections above, 895 the overlay selection occurs as per network policy. 897 8. Policy Enforcement with NSH 899 8.1. NSH Metadata and Policy Enforcement 901 As described in Section 3, NSH provides the ability to carry metadata 902 along a service path. This metadata may be derived from several 903 sources, common examples include: 905 Network nodes/devices: Information provided by network nodes can 906 indicate network-centric information (such as VRF or tenant) that 907 may be used by service functions, or conveyed to another network 908 node post service path egress. 910 External (to the network) systems: External systems, such as 911 orchestration systems, often contain information that is valuable 912 for service function policy decisions. In most cases, this 913 information cannot be deduced by network nodes. For example, a 914 cloud orchestration platform placing workloads "knows" what 915 application is being instantiated and can communicate this 916 information to all NSH nodes via metadata carried in the context 917 header(s). 919 Service Functions: A classifier co-resident with Service Functions 920 often perform very detailed and valuable classification. In some 921 cases they may terminate, and be able to inspect encrypted 922 traffic. 924 Regardless of the source, metadata reflects the "result" of 925 classification. The granularity of classification may vary. For 926 example, a network switch, acting as a classifier, might only be able 927 to classify based on a 5-tuple, whereas, a service function may be 928 able to inspect application information. Regardless of granularity, 929 the classification information can be represented in NSH. 931 Once the data is added to NSH, it is carried along the service path, 932 NSH-aware SFs receive the metadata, and can use that metadata for 933 local decisions and policy enforcement. The following two examples 934 highlight the relationship between metadata and policy: 936 +-------+ +-------+ +-------+ 937 | SFF )------->( SFF |------->| SFF | 938 +---^---+ +---|---+ +---|---+ 939 ,-|-. ,-|-. ,-|-. 940 / \ / \ / \ 941 ( Class ) SF1 ) ( SF2 ) 942 \ ify / \ / \ / 943 `---' `---' `---' 944 5-tuple: Permit Inspect 945 Tenant A Tenant A AppY 946 AppY 948 Figure 15: Metadata and Policy 950 +-----+ +-----+ +-----+ 951 | SFF |---------> | SFF |----------> | SFF | 952 +--+--+ +--+--+ +--+--+ 953 ^ | | 954 ,-+-. ,-+-. ,-+-. 955 / \ / \ / \ 956 ( Class ) ( SF1 ) ( SF2 ) 957 \ ify / \ / \ / 958 `-+-' `---' `---' 959 | Permit Deny AppZ 960 +---+---+ employees 961 | | 962 +-------+ 963 external 964 system: 965 Employee 966 AppZ 968 Figure 16: External Metadata and Policy 970 In both of the examples above, the service functions perform policy 971 decisions based on the result of the initial classification: the SFs 972 did not need to perform re-classification, rather they rely on a 973 antecedent classification for local policy enforcement. 975 8.2. Updating/Augmenting Metadata 977 Post-initial metadata imposition (typically performed during initial 978 service path determination), metadata may be augmented or updated: 980 1. Metadata Augmentation: Information may be added to NSH's existing 981 metadata, as depicted in Figure 17. For example, if the initial 982 classification returns the tenant information, a secondary 983 classification (perhaps co-resident with DPI or SLB) may augment 984 the tenant classification with application information, and 985 impose that new information in the NSH metadata. The tenant 986 classification is still valid and present, but additional 987 information has been added to it. 989 2. Metadata Update: Subsequent classifiers may update the initial 990 classification if it is determined to be incorrect or not 991 descriptive enough. For example, the initial classifier adds 992 metadata that describes the traffic as "internet" but a security 993 service function determines that the traffic is really "attack". 994 Figure 18 illustrates an example of updating metadata. 996 +-----+ +-----+ +-----+ 997 | SFF |---------> | SFF |----------> | SFF | 998 +--+--+ +--+--+ +--+--+ 999 ^ | | 1000 ,---. ,---. ,---. 1001 / \ / \ / \ 1002 ( Class ) ( SF1 ) ( SF2 ) 1003 \ / \ / \ / 1004 `-+-' `---' `---' 1005 | Inspect Deny 1006 +---+---+ employees employee+ 1007 | | Class=AppZ appZ 1008 +-------+ 1009 external 1010 system: 1011 Employee 1013 Figure 17: Metadata Augmentation 1015 +-----+ +-----+ +-----+ 1016 | SFF |---------> | SFF |----------> | SFF | 1017 +--+--+ +--+--+ +--+--+ 1018 ^ | | 1019 ,---. ,---. ,---. 1020 / \ / \ / \ 1021 ( Class ) ( SF1 ) ( SF2 ) 1022 \ / \ / \ / 1023 `---' `---' `---' 1024 5-tuple: Inspect Deny 1025 Tenant A Tenant A attack 1026 --> attack 1028 Figure 18: Metadata Update 1030 8.3. Service Path ID and Metadata 1032 Metadata information may influence the service path selection since 1033 the Service Path Identifier can represent the result of 1034 classification. A given SPI can represent all or some of the 1035 metadata, and be updated based on metadata classification results. 1036 This relationship provides the ability to create a dynamic services 1037 plane based on complex classification without requiring each node to 1038 be capable of such classification, or requiring a coupling to the 1039 network topology. This yields service graph functionality as 1040 described in Section 7.4. Figure 19 illustrates an example of this 1041 behavior. 1043 +-----+ +-----+ +-----+ 1044 | SFF |---------> | SFF |------+---> | SFF | 1045 +--+--+ +--+--+ | +--+--+ 1046 | | | | 1047 ,---. ,---. | ,---. 1048 / \ / \ | / \ 1049 ( SCL ) ( SF1 ) | ( SF2 ) 1050 \ / \ / | \ / 1051 `---' `---' +-----+ `---' 1052 5-tuple: Inspect | SFF | Original 1053 Tenant A Tenant A +--+--+ next SF 1054 --> DoS | 1055 V 1056 ,-+-. 1057 / \ 1058 ( SF10 ) 1059 \ / 1060 `---' 1061 DoS 1062 "Scrubber" 1064 Figure 19: Path ID and Metadata 1066 Specific algorithms for mapping metadata to an SPI are outside the 1067 scope of this draft. 1069 9. NSH Encapsulation Examples 1071 9.1. GRE + NSH 1073 IPv4 Packet: 1074 +----------+--------------------+--------------------+ 1075 |L2 header | L3 header, proto=47|GRE header,PT=0x894F| 1076 +----------+--------------------+--------------------+ 1077 --------------+----------------+ 1078 NSH, NP=0x1 |original packet | 1079 --------------+----------------+ 1081 L2 Frame: 1082 +----------+--------------------+--------------------+ 1083 |L2 header | L3 header, proto=47|GRE header,PT=0x894F| 1084 +----------+--------------------+--------------------+ 1085 ---------------+---------------+ 1086 NSH, NP=0x3 |original frame | 1087 ---------------+---------------+ 1089 Figure 20: GRE + NSH 1091 9.2. VXLAN-gpe + NSH 1093 IPv4 Packet: 1094 +----------+------------------------+---------------------+ 1095 |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| 1096 +----------+------------------------+---------------------+ 1097 --------------+----------------+ 1098 NSH, NP=0x1 |original packet | 1099 --------------+----------------+ 1101 L2 Frame: 1102 +----------+------------------------+---------------------+ 1103 |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| 1104 +----------+------------------------+---------------------+ 1105 ---------------+---------------+ 1106 NSH,NP=0x3 |original frame | 1107 ---------------+---------------+ 1109 Figure 21: VXLAN-gpe + NSH 1111 9.3. Ethernet + NSH 1113 IPv4 Packet: 1114 +-------------------------------+---------------+--------------------+ 1115 |Outer Ethernet, ET=0x894F | NSH, NP = 0x1 | original IP Packet | 1116 +-------------------------------+---------------+--------------------+ 1118 L2 Frame: 1119 +-------------------------------+---------------+----------------+ 1120 |Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original frame | 1121 +-------------------------------+---------------+----------------+ 1123 Figure 22: Ethernet + NSH 1125 10. Security Considerations 1127 As with many other protocols, NSH data can be spoofed or otherwise 1128 modified. In many deployments, NSH will be used in a controlled 1129 environment, with trusted devices (e.g. a data center) thus 1130 mitigating the risk of unauthorized header manipulation. 1132 NSH is always encapsulated in a transport protocol and therefore, 1133 when required, existing security protocols that provide authenticity 1134 (e.g. RFC 2119 [RFC6071]) can be used. 1136 Similarly if confidentiality is required, existing encryption 1137 protocols can be used in conjunction with encapsulated NSH. 1139 11. Open Items for WG Discussion 1141 1. MD type 1 metadata semantics specifics 1143 2. Bypass bit in NSH. 1145 3. Rendered Service Path ID (RSPID). 1147 12. Contributors 1149 This WG document originated as draft-quinn-sfc-nsh and had the 1150 following co-authors and contributors. The editors of this document 1151 would like to thank and recognize them and their contributions. 1152 These co-authors and contributors provided invaluable concepts and 1153 content for this document's creation. 1155 Surendra Kumar 1156 Cisco Systems 1157 smkumar@cisco.com 1159 Michael Smith 1160 Cisco Systems 1161 michsmit@cisco.com 1163 Jim Guichard 1164 Cisco Systems 1165 jguichar@cisco.com 1167 Rex Fernando 1168 Cisco Systems 1169 Email: rex@cisco.com 1171 Navindra Yadav 1172 Cisco Systems 1173 Email: nyadav@cisco.com 1175 Wim Henderickx 1176 Alcatel-Lucent 1177 wim.henderickx@alcatel-lucent.com 1179 Andrew Dolganow 1180 Alcaltel-Lucent 1181 Email: andrew.dolganow@alcatel-lucent.com 1183 Praveen Muley 1184 Alcaltel-Lucent 1185 Email: praveen.muley@alcatel-lucent.com 1187 Tom Nadeau 1188 Brocade 1189 tnadeau@lucidvision.com 1191 Puneet Agarwal 1192 puneet@acm.org 1194 Rajeev Manur 1195 Broadcom 1196 rmanur@broadcom.com 1198 Abhishek Chauhan 1199 Citrix 1200 Abhishek.Chauhan@citrix.com 1202 Joel Halpern 1203 Ericsson 1204 joel.halpern@ericsson.com 1206 Sumandra Majee 1207 F5 1208 S.Majee@f5.com 1210 David Melman 1211 Marvell 1212 davidme@marvell.com 1214 Pankaj Garg 1215 Microsoft 1216 Garg.Pankaj@microsoft.com 1218 Brad McConnell 1219 Rackspace 1220 bmcconne@rackspace.com 1222 Chris Wright 1223 Red Hat Inc. 1224 chrisw@redhat.com 1226 Kevin Glavin 1227 Riverbed 1228 kevin.glavin@riverbed.com 1230 Hong (Cathy) Zhang 1231 Huawei US R&D 1232 cathy.h.zhang@huawei.com 1234 Louis Fourie 1235 Huawei US R&D 1236 louis.fourie@huawei.com 1238 Ron Parker 1239 Affirmed Networks 1240 ron_parker@affirmednetworks.com 1242 Myo Zarny 1243 Goldman Sachs 1244 myo.zarny@gs.com 1246 13. Acknowledgments 1248 The authors would like to thank Nagaraj Bagepalli, Abhijit Patra, 1249 Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal Mizrahi and Ken Gray 1250 for their detailed review, comments and contributions. 1252 A special thank you goes to David Ward and Tom Edsall for their 1253 guidance and feedback. 1255 Additionally the authors would like to thank Carlos Pignataro and 1256 Larry Kreeger for their invaluable ideas and contributions which are 1257 reflected throughout this draft. 1259 Lastly, Reinaldo Penno deserves a particular thank you for his 1260 architecture and implementation work that helped guide the protocol 1261 concepts and design. 1263 14. IANA Considerations 1265 14.1. NSH EtherType 1267 An IEEE EtherType, 0x894F, has been allocated for NSH. 1269 14.2. Network Service Header (NSH) Parameters 1271 IANA is requested to create a new "Network Service Header (NSH) 1272 Parameters" registry. The following sub-sections request new 1273 registries within the "Network Service Header (NSH) Parameters " 1274 registry. 1276 14.2.1. NSH Base Header Reserved Bits 1278 There are ten bits at the beginning of the NSH Base Header. New bits 1279 are assigned via Standards Action [RFC5226]. 1281 Bits 0-1 - Version 1282 Bit 2 - OAM (O bit) 1283 Bits 2-9 - Reserved 1285 14.2.2. MD Type Registry 1287 IANA is requested to set up a registry of "MD Types". These are 1288 8-bit values. MD Type values 0, 1, 2, 254, and 255 are specified in 1289 this document. Registry entries are assigned by using the "IETF 1290 Review" policy defined in RFC 5226 [RFC5226]. 1292 +---------+--------------+---------------+ 1293 | MD Type | Description | Reference | 1294 +---------+--------------+---------------+ 1295 | 0 | Reserved | This document | 1296 | | | | 1297 | 1 | NSH | This document | 1298 | | | | 1299 | 2 | NSH | This document | 1300 | | | | 1301 | 3..253 | Unassigned | | 1302 | | | | 1303 | 254 | Experiment 1 | This document | 1304 | | | | 1305 | 255 | Experiment 2 | This document | 1306 +---------+--------------+---------------+ 1308 Table 1 1310 14.2.3. TLV Class Registry 1312 IANA is requested to set up a registry of "TLV Types". These are 16- 1313 bit values. Registry entries are assigned by using the "IETF Review" 1314 policy defined in RFC 5226 [RFC5226]. 1316 14.2.4. NSH Base Header Next Protocol 1318 IANA is requested to set up a registry of "Next Protocol". These are 1319 8-bit values. Next Protocol values 0, 1, 2 and 3 are defined in this 1320 draft. New values are assigned via Standards Action [RFC5226]. 1322 +---------------+-------------+---------------+ 1323 | Next Protocol | Description | Reference | 1324 +---------------+-------------+---------------+ 1325 | 0 | Reserved | This document | 1326 | | | | 1327 | 1 | IPv4 | This document | 1328 | | | | 1329 | 2 | IPv6 | This document | 1330 | | | | 1331 | 3 | Ethernet | This document | 1332 | | | | 1333 | 4..253 | Unassigned | | 1334 +---------------+-------------+---------------+ 1336 Table 2 1338 15. References 1340 15.1. Normative References 1342 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1343 DOI 10.17487/RFC0791, September 1981, 1344 . 1346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1347 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1348 RFC2119, March 1997, 1349 . 1351 15.2. Informative References 1353 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1354 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1355 DOI 10.17487/RFC2784, March 2000, 1356 . 1358 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1359 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1360 DOI 10.17487/RFC5226, May 2008, 1361 . 1363 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1364 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1365 DOI 10.17487/RFC6071, February 2011, 1366 . 1368 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1369 Service Function Chaining", RFC 7498, DOI 10.17487/ 1370 RFC7498, April 2015, 1371 . 1373 [SFC-arch] 1374 Quinn, P., Ed. and J. Halpern, Ed., "Service Function 1375 Chaining (SFC) Architecture", 2014, 1376 . 1378 [VXLAN-gpe] 1379 Quinn, P., Manur, R., Agarwal, P., Kreeger, L., Lewis, D., 1380 Maino, F., Smith, M., Yong, L., Xu, X., Elzur, U., Garg, 1381 P., and D. Melman, "Generic Protocol Extension for VXLAN", 1382 . 1385 [dcalloc] Guichard, J., Smith, M., and S. Kumar, "Network Service 1386 Header (NSH) Context Header Allocation (Data Center)", 1387 2014, . 1390 [moballoc] 1391 Napper, J. and S. Kumar, "NSH Context Header Allocation -- 1392 Mobility", 2014, . 1395 Authors' Addresses 1397 Paul Quinn (editor) 1398 Cisco Systems, Inc. 1400 Email: paulq@cisco.com 1402 Uri Elzur (editor) 1403 Intel 1405 Email: uri.elzur@intel.com