idnits 2.17.1 draft-ietf-sfc-nsh-05.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 (May 26, 2016) is 2892 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) ** Downref: Normative reference to an Informational RFC: RFC 7498 ** Downref: Normative reference to an Informational RFC: RFC 7665 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining P. Quinn, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track U. Elzur, Ed. 5 Expires: November 27, 2016 Intel 6 May 26, 2016 8 Network Service Header 9 draft-ietf-sfc-nsh-05.txt 11 Abstract 13 This document 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 required to 17 support the Service Function Chaining (SFC) Architecture (defined in 18 RFC7665). 20 1. Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 27, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 63 2.2. Problem Space . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. NSH-based Service Chaining . . . . . . . . . . . . . . . . 5 65 3. Network Service Header . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Network Service Header Format . . . . . . . . . . . . . . 7 67 3.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. Service Path Header . . . . . . . . . . . . . . . . . . . 9 69 3.4. NSH MD-type 1 . . . . . . . . . . . . . . . . . . . . . . 10 70 3.5. NSH MD-type 2 . . . . . . . . . . . . . . . . . . . . . . 10 71 3.5.1. Optional Variable Length Metadata . . . . . . . . . . 11 72 4. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . . . 15 74 6. Fragmentation Considerations . . . . . . . . . . . . . . . . . 16 75 7. Service Path Forwarding with NSH . . . . . . . . . . . . . . . 17 76 7.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . . 17 77 7.2. Mapping NSH to Network Transport . . . . . . . . . . . . . 19 78 7.3. Service Plane Visibility . . . . . . . . . . . . . . . . . 20 79 7.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . . 20 80 8. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21 81 8.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21 82 8.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . . 22 83 8.3. Service Path Identifier and Metadata . . . . . . . . . . . 24 84 9. NSH Encapsulation Examples . . . . . . . . . . . . . . . . . . 26 85 9.1. GRE + NSH . . . . . . . . . . . . . . . . . . . . . . . . 26 86 9.2. VXLAN-gpe + NSH . . . . . . . . . . . . . . . . . . . . . 26 87 9.3. Ethernet + NSH . . . . . . . . . . . . . . . . . . . . . . 27 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 89 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 91 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 92 13.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . . 33 93 13.2. Network Service Header (NSH) Parameters . . . . . . . . . 33 94 13.2.1. NSH Base Header Reserved Bits . . . . . . . . . . . . 33 95 13.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . . 33 96 13.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . . 33 97 13.2.4. MD Class Registry . . . . . . . . . . . . . . . . . . 34 98 13.2.5. NSH Base Header Next Protocol . . . . . . . . . . . . 34 99 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 100 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 101 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 104 2. Introduction 106 Service functions are widely deployed and essential in many networks. 107 These service functions provide a range of features such as security, 108 WAN acceleration, and server load balancing. Service functions may 109 be instantiated at different points in the network infrastructure 110 such as the wide area network, data center, campus, and so forth. 112 Prior to development of the SFC architecture [RFC7665] and the 113 protocol specified in this document, current service function 114 deployment models have been relatively static, and bound to topology 115 for insertion and policy selection. Furthermore, they do not adapt 116 well to elastic service environments enabled by virtualization. 118 New data center network and cloud architectures require more flexible 119 service function deployment models. Additionally, the transition to 120 virtual platforms requires an agile service insertion model that 121 supports dynamic and elastic service delivery; the movement of 122 service functions and application workloads in the network and the 123 ability to easily bind service policy to granular information such as 124 per-subscriber state and steer traffic to the requisite service 125 function(s) are necessary. 127 NSH defines a new service plane protocol specifically for the 128 creation of dynamic service chains and is composed of the following 129 elements: 131 1. Service Function Path identification 133 2. Transport independent service function chain 135 3. Per-packet network and service metadata or optional variable 136 type-length-value (TLV) metadata. 138 NSH is designed to be easy to implement across a range of devices, 139 both physical and virtual, including hardware platforms. 141 An NSH-aware control plane is outside the scope of this document. 143 [RFC7665] provides an overview of a service chaining architecture 144 that clearly defines the roles of the various elements and the scope 145 of a service function chaining encapsulation. NSH is the SFC 146 encapsulation referenced in RFC7665 document. 148 2.1. Definition of Terms 149 Classification: Defined in [RFC7665]. 151 Classifier: Defined in [RFC7665]. 153 Metadata: Defined in [RFC7665]. 155 Network Locator: dataplane address, typically IPv4 or IPv6, used to 156 send and receive network traffic. 158 Network Node/Element: Device that forwards packets or frames based 159 on outer header (i.e. transport) information. 161 Network Overlay: Logical network built on top of existing network 162 (the underlay). Packets are encapsulated or tunneled to create 163 the overlay network topology. 165 Service Classifier: Logical entity providing classification 166 function. Since they are logical, classifiers may be co-resident 167 with SFC elements such as SFs or SFFs. Service classifiers 168 perform classification and impose NSH. The initial classifier 169 imposes the initial NSH and sends the NSH packet to the first SFF 170 in the path. Non-initial (i.e. subsequent) classification can 171 occur as needed and can alter, or create a new service path. 173 Service Function (SF): Defined in [RFC7665]. 175 Service Function Chain (SFC): Defined in [RFC7665]. 177 Service Function Forwarder (SFF): Defined in [RFC7665]. 179 Service Function Path (SFP): Defined in [RFC7665]. 181 SFC Proxy: Defined in [RFC7665]. 183 2.2. Problem Space 185 Network Service Header (NSH) addresses several limitations associated 186 with service function deployments. RFC 7498 [RFC7498] provides a 187 comprehensive review of those issues. 189 2.3. NSH-based Service Chaining 191 The NSH creates a dedicated service plane, more specifically, NSH 192 enables: 194 1. Topological Independence: Service forwarding occurs within the 195 service plane, the underlying network topology does not require 196 modification. NSH provides an identifier used to select the 197 network overlay for network forwarding. 199 2. Service Chaining: NSH enables Service Chaining per [RFC7665]. 200 NSH contains path identification information needed to realize a 201 service path. Furthermore, NSH provides the ability to monitor 202 and troubleshoot a service chain, end-to-end via service-specific 203 OAM messages. The NSH fields can be used by administrators (via, 204 for example a traffic analyser) to verify (account, ensure 205 correct chaining, provide reports, etc.) the path specifics of 206 packets being forwarded along a service path. 208 3. NSH provides a mechanism to carry shared metadata between network 209 devices and service function, and between service functions. The 210 semantics of the shared metadata is communicated via a control 211 plane to participating nodes. Examples of metadata include 212 classification information used for policy enforcement and 213 network context for forwarding post service delivery. 215 4. Classification and re-classification: sharing the metadata allows 216 service functions to share initial and intermediate 217 classification results with downstream service functions saving 218 re-classification, where enough information was enclosed. 220 5. NSH offers a common and standards-based header for service 221 chaining to all network and service nodes. 223 6. Transport Agnostic: NSH is transport independent and is often 224 carried via a network transport protocol, over existing 225 underlays. This transport may form an overlay network and if an 226 existing overlay topology provides the required service path 227 connectivity, that existing overlay may be used. 229 3. Network Service Header 231 A Network Service Header (NSH) contains service path information and 232 optionally metadata that are added to a packet or frame and used to 233 create a service plane. The original packets preceded by NSH, are 234 then encapsulated in an outer header for transport. 236 A Service Classifier adds the NSH. The NSH is removed by the last 237 SFF in the service chain or by a SF that consumes the packet. 239 3.1. Network Service Header Format 241 An NSH is composed of a 4-byte Base Header, a 4-byte Service Path 242 Header and Context Headers, as shown in Figure 1 below. 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Base Header | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Service Path Header | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 ~ Context Headers ~ 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1: Network Service Header 257 Base header: provides information about the service header and the 258 payload protocol. 260 Service Path Header: provide path identification and location within 261 a service path. 263 Context headers: carry metadata (i.e. context data) along a service 264 path. 266 3.2. NSH Base Header 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2: NSH Base Header 274 Base Header Field Descriptions: 276 Version: The version field is used to ensure backward compatibility 277 going forward with future NSH updates. It MUST be set to 0x0 by the 278 sender, in this first revision of NSH. Given the widespread 279 implementation of existing hardware that uses the first nibble after 280 an MPLS label stack for ECMP decision processing, this document 281 reserves version 01 and this value MUST NOT be used in future 282 versions of the protocol. 284 O bit: when set to 0x1 indicates that this packet is an Operations, 285 Administration and Maintenance (OAM) message. The receiving SFF and 286 SFs nodes MUST examine the payload and take appropriate action (e.g. 287 return status information). OAM message specifics and handling 288 details are outside the scope of this document. 290 C bit: Indicates that a critical metadata TLV is present. This bit 291 acts as an indication for hardware implementers to decide how to 292 handle the presence of a critical TLV without necessarily needing to 293 parse all TLVs present. For an MD Type of 0x1 (i.e. no variable 294 length metadata is present), the C bit MUST be set to 0x0. 296 All other flag fields are reserved for future use. Reserved bits 297 MUST be set to zero when sent and MUST be ignored upon receipt. 299 Length: total length, in 4-byte words, of NSH including the Base 300 Header, the Service Path Header and the context headers or optional 301 variable length metadata. The Length MUST be of value 0x6 for MD 302 Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type 303 equal to 0x2. The NSH header length MUST be an integer number of 4 304 bytes. The length field indicates the "end" of NSH and where the 305 original packet/frame begins. 307 MD Type: indicates the format of NSH beyond the mandatory Base Header 308 and the Service Path Header. MD Type defines the format of the 309 metadata being carried. Please see IANA Considerations section 310 below. 312 NSH defines two MD types: 314 0x1 - which indicates that the format of the header includes fixed 315 length context headers (see Figure 4 below). 317 0x2 - which does not mandate any headers beyond the Base Header and 318 Service Path Header, but may contain optional variable length context 319 information. 321 The format of the base header and the service path header is 322 invariant, and not affected by MD Type. 324 NSH implementations MUST support MD-Type = 0x1, and SHOULD support 325 MD- Type = 0x2. There exists, however, a middle ground, wherein a 326 device will support MD-Type 0x1 (as per the MUST) metadata, yet be 327 deployed in a network with MD-Type 0x2 metadata packets. In that 328 case, the MD-Type 0x1 node, MUST utilize the base header length field 329 to determine the original payload offset if it requires access to the 330 original packet/frame. 332 Next Protocol: indicates the protocol type of the original packet. 333 Please see IANA Considerations section below. 335 This draft defines the following Next Protocol values: 337 0x1 : IPv4 338 0x2 : IPv6 339 0x3 : Ethernet 340 0x4: NSH 341 0x5: MPLS 342 0x6-0xFD: Unassigned 343 0xFE-0xFF: Experimental 345 3.3. Service Path Header 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Service Path Identifier (SPI) | Service Index | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Service Path Identifier (SPI): 24 bits 353 Service Index (SI): 8 bits 355 Figure 3: NSH Service Path Header 357 Service Path Identifier (SPI): identifies a service path. 358 Participating nodes MUST use this identifier for Service Function 359 Path selection. 361 Service Index (SI): provides location within the SFP. The first 362 classifier (i.e. at the boundary of the NSH domain) in the NSH 363 Service Function Path, SHOULD set the SI to 255, however the control 364 plane MAY configure the initial value of SI as appropriate (i.e. 365 taking into account the length of the service function path). A 366 Classifier MUST send the packet to the first SFF in the chain. 367 Service index MUST be decremented by service functions or proxy nodes 368 after performing required services and the new decremented SI value 369 MUST be used in the egress NSH packet. SI SHOULD be used in 370 conjunction with Service Path Identifier for Service Function Path 371 selection. Service Index (SI) is also valuable when troubleshooting/ 372 reporting service paths. In addition to indicating the location 373 within a Service Function Path, SI can be used for service plane loop 374 detection. 376 3.4. NSH MD-type 1 378 When the Base Header specifies MD Type = 0x1, four Context Headers, 379 4-byte each, MUST be added immediately following the Service Path 380 Header, as per Figure 4. Context Headers that carry no metadata MUST 381 be set to zero. 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Service Path Identifer | Service Index | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Mandatory Context Header | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Mandatory Context Header | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Mandatory Context Header | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Mandatory Context Header | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 4: NSH MD-type=0x1 400 [dcalloc] and [broadalloc] provide specific examples of how metadata 401 can be allocated. 403 3.5. NSH MD-type 2 405 When the base header specifies MD Type= 0x2, zero or more Variable 406 Length Context Headers MAY be added, immediately following the 407 Service Path Header. Therefore, Length = 0x2, indicates that only 408 the Base Header followed by the Service Path Header are present. The 409 optional Variable Length Context Headers MUST be of an integer number 410 of 4-bytes. The base header length field MUST be used to determine 411 the offset to locate the original packet or frame for SFC nodes that 412 require access to that information. 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Service Path Identifier | Service Index | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 ~ Variable Length Context Headers (opt.) ~ 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 5: NSH MD-type=0x2 427 3.5.1. Optional Variable Length Metadata 429 The format of the optional variable length context headers, is as 430 described below. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Metadata Class |C| Type |R|R|R| Len | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Variable Metadata | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Figure 6: Variable Context Headers 442 Metadata Class (MD Class): describes the scope of the "Type" field. 443 In some cases, the MD Class will identify a specific vendor, in 444 others, the MD Class will identify specific standards body allocated 445 types. Please see IANA Considerations section below. 447 Type: the specific type of information being carried, within the 448 scope of a given MD Class. Value allocation is the responsibility of 449 the MD Class owner. 451 Encoding the criticality of the TLV within the Type field is 452 consistent with IPv6 option types: the most significant bit of the 453 Type field indicates whether the TLV is mandatory for the receiver to 454 understand/process. This effectively allocates Type values 0 to 127 455 for non-critical options and Type values 128 to 255 for critical 456 options. Figure 7 below illustrates the placement of the Critical 457 bit within the Type field. 459 +-+-+-+-+-+-+-+-+ 460 |C| Type | 461 +-+-+-+-+-+-+-+-+ 463 Figure 7: Critical Bit Placement Within the TLV Type Field 465 If an NSH-aware node receives an encapsulated packet containing a TLV 466 with the Critical bit set to 0x1 in the Type field and it does not 467 understand how to process the Type, it MUST drop the packet. Transit 468 devices (i.e. network nodes that do not participate in the service 469 plane) MUST NOT drop packets based on the setting of this bit. 471 Reserved bits: three reserved bit are present for future use. The 472 reserved bits MUST be set to 0x0. 474 Length: Length of the variable metadata, in 4-byte words. A value of 475 0x0 or higher can be used. A value of 0x0 denotes a TLV header 476 without a Variable Metadata field. 478 4. NSH Actions 480 NSH-aware nodes are the only nodes that MAY alter the content of the 481 NSH headers. NSH-aware nodes include: service classifiers, SFF, SF 482 and SFC proxies. These nodes have several possible header related 483 actions: 485 1. Insert or remove NSH: These actions can occur at the start and 486 end respectively of a service path. Packets are classified, and 487 if determined to require servicing, NSH will be imposed. A 488 service classifier MUST insert NSH at the start of an SFP. An 489 imposed NSH MUST contain valid Base Header and Service Path 490 Header. At the end of a service function path, a SFF, MUST be 491 the last node operating on the service header and MUST remove it. 493 Multiple logical classifiers may exist within a given service 494 path. Non-initial classifiers may re-classify data and that re- 495 classification MAY result in a new Service Function Path. When 496 the logical classifier performs re-classification that results in 497 a change of service path, it MUST remove the existing NSH and 498 MUST impose a new NSH with the Base Header and Service Path 499 Header reflecting the new service path information and set the 500 initial SI. Metadata MAY be preserved in the new NSH. 502 2. Select service path: The Service Path Header provides service 503 chain information and is used by SFFs to determine correct 504 service path selection. SFFs MUST use the Service Path Header 505 for selecting the next SF or SFF in the service path. 507 3. Update a Service Path Header: NSH-aware service functions (SF) 508 MUST decrement the service index. If an SFF receives a packet 509 with SI equal to 0x0, that packet MUST be dropped by the SFF. 511 Classifier(s) MAY update Context Headers if new/updated context 512 is available. 514 If an SFC proxy is in use (acting on behalf of a non-NSH-aware 515 service function for NSH actions), then the proxy MUST update 516 Service Index and MAY update contexts. When an SFC proxy 517 receives an NSH-encapsulated packet, it MUST remove the NSH 518 headers before forwarding it to an NSH unaware SF. When the SFC 519 Proxy receives a packet back from an NSH unaware SF, it MUST re- 520 encapsulates it with the correct NSH, and MUST decrement the 521 Service Index. 523 4. Service policy selection: Service Function instances derive 524 policy (i.e. service actions such as permit or deny) selection 525 and enforcement from the service header. Metadata shared in the 526 service header can provide a range of service-relevant 527 information such as traffic classification. Service functions 528 SHOULD use NSH to select local service policy. 530 Figure 8 maps each of the four actions above to the components in the 531 SFC architecture that can perform it. 533 +---------------+------------------+-------+----------------+---------+ 534 | | Insert |Select | Update |Service | 535 | | or remove NSH |Service| NSH |policy | 536 | | |Function| |selection| 537 | Component +--------+--------+Path +----------------+ | 538 | | | | | Dec. |Update | | 539 | | Insert | Remove | |Service |Context| | 540 | | | | | Index |Header | | 541 +----------------+--------+--------+-------+--------+-------+---------+ 542 | | + | + | | | + | | 543 |Classifier | | | | | | | 544 +--------------- +--------+--------+-------+--------+-------+---------+ 545 |Service Function| | + | + | | | | 546 |Forwarder(SFF) | | | | | | | 547 +--------------- +--------+--------+-------+--------+-------+---------+ 548 |Service | | | | + | + | + | 549 |Function (SF) | | | | | | | 550 +--------------- +--------+--------+-------+--------+-------+---------+ 551 |SFC Proxy | + | + | | + | | | 552 +----------------+--------+--------+-------+--------+-------+---------+ 554 Figure 8: NSH Action and Role Mapping 556 5. NSH Encapsulation 558 Once NSH is added to a packet, an outer encapsulation is used to 559 forward the original packet and the associated metadata to the start 560 of a service chain. The encapsulation serves two purposes: 562 1. Creates a topologically independent services plane. Packets are 563 forwarded to the required services without changing the 564 underlying network topology 566 2. Transit network nodes simply forward the encapsulated packets as 567 is. 569 The service header is independent of the encapsulation used and is 570 encapsulated in existing transports. The presence of NSH is 571 indicated via protocol type or other indicator in the outer 572 encapsulation. 574 See Section 9 for NSH encapsulation examples. 576 6. Fragmentation Considerations 578 NSH and the associated transport header are "added" to the 579 encapsulated packet/frame. This additional information increases the 580 size of the packet. In order the ensure proper forwarding of NSH 581 packets, several options for handling fragmentation and re-assembly 582 exist: 584 1. Jumbo Frames, when supported, enable the transport of NSH and 585 associated transport packets without requiring fragmentation. 587 2. and [RFC1191][RFC1981] describe a technique for dynamically 588 discovering the maximum transmission unit (MTU) of an arbitrary 589 internet path" and can be utilized to ensure the required packet 590 size is used. 592 3. Use the fragmentation provided by the network transport/overlay. 593 One example can be found in [RFC6830], section 5.4. 595 7. Service Path Forwarding with NSH 597 7.1. SFFs and Overlay Selection 599 As described above, NSH contains a Service Path Identifier (SPI) and 600 a Service Index (SI). The SPI is, as per its name, an identifier. 601 The SPI alone cannot be used to forward packets along a service path. 602 Rather the SPI provide a level of indirection between the service 603 path/topology and the network transport. Furthermore, there is no 604 requirement, or expectation of an SPI being bound to a pre-determined 605 or static network path. 607 The Service Index provides an indication of location within a service 608 path. The combination of SPI and SI provides the identification of a 609 logical SF and its order within the service plane, and is used to 610 select the appropriate network locator(s) for overlay forwarding. 611 The logical SF may be a single SF, or a set of eligible SFs that are 612 equivalent. In the latter case, the SFF provides load distribution 613 amongst the collection of SFs as needed. 615 SI can also serve as a mechanism for loop detection within a service 616 path since each SF in the path decrements the index; an Service Index 617 of 0 indicates that a loop occurred and the packet must be discarded. 619 This indirection -- path ID to overlay -- creates a true service 620 plane. That is the SFF/SF topology is constructed without impacting 621 the network topology but more importantly service plane only 622 participants (i.e. most SFs) need not be part of the network overlay 623 topology and its associated infrastructure (e.g. control plane, 624 routing tables, etc.). As mentioned above, an existing overlay 625 topology may be used provided it offers the requisite connectivity. 627 The mapping of SPI to transport occurs on an SFF (as discussed above, 628 the first SFF in the path gets a NSH encapsulated packet from the 629 Classifier). The SFF consults the SPI/ID values to determine the 630 appropriate overlay transport protocol (several may be used within a 631 given network) and next hop for the requisite SF. Figure 9 below 632 depicts an example of a single next-hop SPI/SI to network overlay 633 network locator mapping. 635 +-------------------------------------------------------+ 636 | SPI | SI | NH | Transport | 637 +-------------------------------------------------------+ 638 | 10 | 255 | 192.0.2.1 | VXLAN-gpe | 639 | 10 | 254 | 198.51.100.10 | GRE | 640 | 10 | 251 | 198.51.100.15 | GRE | 641 | 40 | 251 | 198.51.100.15 | GRE | 642 | 50 | 200 | 01:23:45:67:89:ab | Ethernet | 643 | 15 | 212 | Null (end of path) | None | 644 +-------------------------------------------------------+ 646 Figure 9: SFF NSH Mapping Example 648 Additionally, further indirection is possible: the resolution of the 649 required SF network locator may be a localized resolution on an SFF, 650 rather than a service function chain control plane responsibility, as 651 per figures 10 and 11 below. 653 Please note: VXLAN-gpe and GRE in the above table refer to 654 [VXLAN-gpe] and [RFC2784], respectively. 656 +-------------------+ 657 | SPI | SI | NH | 658 +-------------------+ 659 | 10 | 3 | SF2 | 660 | 245 | 12 | SF34 | 661 | 40 | 9 | SF9 | 662 +-------------------+ 664 Figure 10: NSH to SF Mapping Example 666 +----------------------------------------+ 667 | SF | NH | Transport | 668 +----------------------------------------| 669 | SF2 | 192.0.2.2 | VXLAN-gpe | 670 | SF34| 198.51.100.34 | UDP | 671 | SF9 | 2001:db8::1 | GRE | 672 +--------------------------+------------- 673 = 674 Figure 11: SF Locator Mapping Example 676 Since the SPI is a representation of the service path, the lookup may 677 return more than one possible next-hop within a service path for a 678 given SF, essentially a series of weighted (equally or otherwise) 679 paths to be used (for load distribution, redundancy or policy), see 680 Figure 12. The metric depicted in Figure 12 is an example to help 681 illustrated weighing SFs. In a real network, the metric will range 682 from a simple preference (similar to routing next- hop), to a true 683 dynamic composite metric based on some service function-centric state 684 (including load, sessions state, capacity, etc.) 686 +----------------------------------+ 687 | SPI | SI | NH | Metric | 688 +----------------------------------+ 689 | 10 | 3 | 203.0.113.1 | 1 | 690 | | | 203.0.113.2 | 1 | 691 | | | | | 692 | 20 | 12 | 192.0.2.1 | 1 | 693 | | | 203.0.113.4 | 1 | 694 | | | | | 695 | 30 | 7 | 192.0.2.10 | 10 | 696 | | | 198.51.100.1| 5 | 697 +----------------------------------+ 698 (encapsulation type omitted for formatting) 700 Figure 12: NSH Weighted Service Path 702 7.2. Mapping NSH to Network Transport 704 As described above, the mapping of SPI to network topology may result 705 in a single path, or it might result in a more complex topology. 706 Furthermore, the SPI to overlay mapping occurs at each SFF 707 independently. Any combination of topology selection is possible. 708 Please note, there is no requirement to create a new overlay topology 709 if a suitable one already existing. NSH packets can use any (new or 710 existing) overlay provided the requisite connectivity requirements 711 are satisfied. 713 Examples of mapping for a topology: 715 1. Next SF is located at SFFb with locator 192.0.2.1 716 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 192.0.2.1 718 2. Next SF is located at SFFc with multiple network locators for 719 load distribution purposes: 720 SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1, 721 203.0.113.2, 203.0.113.3, equal cost 723 3. Next SF is located at SFFd with two paths from SFFc, one for 724 redundancy: 725 SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10, 726 203.0.113.10, cost=20 728 In the above example, each SFF makes an independent decision about 729 the network overlay path and policy for that path. In other words, 730 there is no a priori mandate about how to forward packets in the 731 network (only the order of services that must be traversed). 733 The network operator retains the ability to engineer the network 734 paths as required. For example, the overlay path between SFFs may 735 utilize traffic engineering, QoS marking, or ECMP, without requiring 736 complex configuration and network protocol support to be extended to 737 the service path explicitly. In other words, the network operates as 738 expected, and evolves as required, as does the service plane. 740 7.3. Service Plane Visibility 742 The SPI and SI serve an important function for visibility into the 743 service topology. An operator can determine what service path a 744 packet is "on", and its location within that path simply by viewing 745 the NSH information (packet capture, IPFIX, etc.). The information 746 can be used for service scheduling and placement decisions, 747 troubleshooting and compliance verification. 749 7.4. Service Graphs 751 While a given realized service function path is a specific sequence 752 of service functions, the service as seen by a user can actually be a 753 collection of service function paths, with the interconnection 754 provided by classifiers (in-service path, non-initial 755 reclassification). These internal reclassifiers examine the packet 756 at relevant points in the network, and rewrite the SPI and SI to 757 reflect the results of the reclassification. (These classifiers may 758 also of course modify the metadata associated with the packet.) 759 RFC7665, section 2.1 describes Service Graphs in detail. 761 8. Policy Enforcement with NSH 763 8.1. NSH Metadata and Policy Enforcement 765 As described in Section 3, NSH provides the ability to carry metadata 766 along a service path. This metadata may be derived from several 767 sources, common examples include: 769 Network nodes/devices: Information provided by network nodes can 770 indicate network-centric information (such as VRF or tenant) that 771 may be used by service functions, or conveyed to another network 772 node post service path egress. 774 External (to the network) systems: External systems, such as 775 orchestration systems, often contain information that is valuable 776 for service function policy decisions. In most cases, this 777 information cannot be deduced by network nodes. For example, a 778 cloud orchestration platform placing workloads "knows" what 779 application is being instantiated and can communicate this 780 information to all NSH nodes via metadata carried in the context 781 header(s). 783 Service Functions: A classifier co-resident with Service Functions 784 often perform very detailed and valuable classification. In some 785 cases they may terminate, and be able to inspect encrypted 786 traffic. 788 Regardless of the source, metadata reflects the "result" of 789 classification. The granularity of classification may vary. For 790 example, a network switch, acting as a classifier, might only be able 791 to classify based on a 5-tuple, whereas, a service function may be 792 able to inspect application information. Regardless of granularity, 793 the classification information can be represented in NSH. 795 Once the data is added to NSH, it is carried along the service path, 796 NSH-aware SFs receive the metadata, and can use that metadata for 797 local decisions and policy enforcement. The following two examples 798 highlight the relationship between metadata and policy: 800 +-------+ +-------+ +-------+ 801 | SFF )------->( SFF |------->| SFF | 802 +---^---+ +---|---+ +---|---+ 803 ,-|-. ,-|-. ,-|-. 804 / \ / \ / \ 805 ( Class ) SF1 ) ( SF2 ) 806 \ ify / \ / \ / 807 `---' `---' `---' 808 5-tuple: Permit Inspect 809 Tenant A Tenant A AppY 810 AppY 812 Figure 13: Metadata and Policy 814 +-----+ +-----+ +-----+ 815 | SFF |---------> | SFF |----------> | SFF | 816 +--+--+ +--+--+ +--+--+ 817 ^ | | 818 ,-+-. ,-+-. ,-+-. 819 / \ / \ / \ 820 ( Class ) ( SF1 ) ( SF2 ) 821 \ ify / \ / \ / 822 `-+-' `---' `---' 823 | Permit Deny AppZ 824 +---+---+ employees 825 | | 826 +-------+ 827 external 828 system: 829 Employee 830 AppZ 832 Figure 14: External Metadata and Policy 834 In both of the examples above, the service functions perform policy 835 decisions based on the result of the initial classification: the SFs 836 did not need to perform re-classification, rather they rely on a 837 antecedent classification for local policy enforcement. 839 8.2. Updating/Augmenting Metadata 841 Post-initial metadata imposition (typically performed during initial 842 service path determination), metadata may be augmented or updated: 844 1. Metadata Augmentation: Information may be added to NSH's existing 845 metadata, as depicted in Figure 17. For example, if the initial 846 classification returns the tenant information, a secondary 847 classification (perhaps co-resident with DPI or SLB) may augment 848 the tenant classification with application information, and 849 impose that new information in the NSH metadata. The tenant 850 classification is still valid and present, but additional 851 information has been added to it. 853 2. Metadata Update: Subsequent classifiers may update the initial 854 classification if it is determined to be incorrect or not 855 descriptive enough. For example, the initial classifier adds 856 metadata that describes the traffic as "internet" but a security 857 service function determines that the traffic is really "attack". 858 Figure 18 illustrates an example of updating metadata. 860 +-----+ +-----+ +-----+ 861 | SFF |---------> | SFF |----------> | SFF | 862 +--+--+ +--+--+ +--+--+ 863 ^ | | 864 ,---. ,---. ,---. 865 / \ / \ / \ 866 ( Class ) ( SF1 ) ( SF2 ) 867 \ / \ / \ / 868 `-+-' `---' `---' 869 | Inspect Deny 870 +---+---+ employees employee+ 871 | | Class=AppZ appZ 872 +-------+ 873 external 874 system: 875 Employee 877 Figure 15: Metadata Augmentation 879 +-----+ +-----+ +-----+ 880 | SFF |---------> | SFF |----------> | SFF | 881 +--+--+ +--+--+ +--+--+ 882 ^ | | 883 ,---. ,---. ,---. 884 / \ / \ / \ 885 ( Class ) ( SF1 ) ( SF2 ) 886 \ / \ / \ / 887 `---' `---' `---' 888 5-tuple: Inspect Deny 889 Tenant A Tenant A attack 890 --> attack 892 Figure 16: Metadata Update 894 8.3. Service Path Identifier and Metadata 896 Metadata information may influence the service path selection since 897 the Service Path Identifier can represent the result of 898 classification. A given SPI can represent all or some of the 899 metadata, and be updated based on metadata classification results. 900 This relationship provides the ability to create a dynamic service 901 plane based on complex classification without requiring each node to 902 be capable of such classification, or requiring a coupling to the 903 network topology. This yields service graph functionality as 904 described in Section 7.4. Figure 19 illustrates an example of this 905 behavior. 907 +-----+ +-----+ +-----+ 908 | SFF |---------> | SFF |------+---> | SFF | 909 +--+--+ +--+--+ | +--+--+ 910 | | | | 911 ,---. ,---. | ,---. 912 / \ / \ | / \ 913 ( SCL ) ( SF1 ) | ( SF2 ) 914 \ / \ / | \ / 915 `---' `---' +-----+ `---' 916 5-tuple: Inspect | SFF | Original 917 Tenant A Tenant A +--+--+ next SF 918 --> DoS | 919 V 920 ,-+-. 921 / \ 922 ( SF10 ) 923 \ / 924 `---' 925 DoS 926 "Scrubber" 928 Figure 17: Path ID and Metadata 930 Specific algorithms for mapping metadata to an SPI are outside the 931 scope of this document. 933 9. NSH Encapsulation Examples 935 9.1. GRE + NSH 937 IPv4 Packet: 938 +----------+--------------------+--------------------+ 939 |L2 header | L3 header, proto=47|GRE header,PT=0x894F| 940 +----------+--------------------+--------------------+ 941 --------------+----------------+ 942 NSH, NP=0x1 |original packet | 943 --------------+----------------+ 945 L2 Frame: 946 +----------+--------------------+--------------------+ 947 |L2 header | L3 header, proto=47|GRE header,PT=0x894F| 948 +----------+--------------------+--------------------+ 949 ---------------+---------------+ 950 NSH, NP=0x3 |original frame | 951 ---------------+---------------+ 953 Figure 18: GRE + NSH 955 9.2. VXLAN-gpe + NSH 957 IPv4 Packet: 958 +----------+------------------------+---------------------+ 959 |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| 960 +----------+------------------------+---------------------+ 961 --------------+----------------+ 962 NSH, NP=0x1 |original packet | 963 --------------+----------------+ 965 L2 Frame: 966 +----------+------------------------+---------------------+ 967 |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)| 968 +----------+------------------------+---------------------+ 969 ---------------+---------------+ 970 NSH,NP=0x3 |original frame | 971 ---------------+---------------+ 973 Figure 19: VXLAN-gpe + NSH 975 9.3. Ethernet + NSH 977 IPv4 Packet: 978 +-------------------------------+---------------+--------------------+ 979 |Outer Ethernet, ET=0x894F | NSH, NP = 0x1 | original IP Packet | 980 +-------------------------------+---------------+--------------------+ 982 L2 Frame: 983 +-------------------------------+---------------+----------------+ 984 |Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original frame | 985 +-------------------------------+---------------+----------------+ 987 Figure 20: Ethernet + NSH 989 10. Security Considerations 991 As with many other protocols, NSH data can be spoofed or otherwise 992 modified. In many deployments, NSH will be used in a controlled 993 environment, with trusted devices (e.g. a data center) thus 994 mitigating the risk of unauthorized header manipulation. 996 NSH is always encapsulated in a transport protocol and therefore, 997 when required, existing security protocols that provide authenticity 998 (e.g. RFC 2119 [RFC6071]) can be used. 1000 Similarly if confidentiality is required, existing encryption 1001 protocols can be used in conjunction with encapsulated NSH. 1003 Further security considerations are discussed in [nsh-sec]. 1005 11. Contributors 1007 This WG document originated as draft-quinn-sfc-nsh and had the 1008 following co-authors and contributors. The editors of this document 1009 would like to thank and recognize them and their contributions. 1010 These co-authors and contributors provided invaluable concepts and 1011 content for this document's creation. 1013 Surendra Kumar 1014 Cisco Systems 1015 smkumar@cisco.com 1017 Michael Smith 1018 Cisco Systems 1019 michsmit@cisco.com 1021 Jim Guichard 1022 Cisco Systems 1023 jguichar@cisco.com 1025 Rex Fernando 1026 Cisco Systems 1027 Email: rex@cisco.com 1029 Navindra Yadav 1030 Cisco Systems 1031 Email: nyadav@cisco.com 1033 Wim Henderickx 1034 Alcatel-Lucent 1035 wim.henderickx@alcatel-lucent.com 1037 Andrew Dolganow 1038 Alcaltel-Lucent 1039 Email: andrew.dolganow@alcatel-lucent.com 1041 Praveen Muley 1042 Alcaltel-Lucent 1043 Email: praveen.muley@alcatel-lucent.com 1045 Tom Nadeau 1046 Brocade 1047 tnadeau@lucidvision.com 1049 Puneet Agarwal 1050 puneet@acm.org 1052 Rajeev Manur 1053 Broadcom 1054 rmanur@broadcom.com 1056 Abhishek Chauhan 1057 Citrix 1058 Abhishek.Chauhan@citrix.com 1060 Joel Halpern 1061 Ericsson 1062 joel.halpern@ericsson.com 1064 Sumandra Majee 1065 F5 1066 S.Majee@f5.com 1068 David Melman 1069 Marvell 1070 davidme@marvell.com 1072 Pankaj Garg 1073 Microsoft 1074 pankajg@microsoft.com 1076 Brad McConnell 1077 Rackspace 1078 bmcconne@rackspace.com 1080 Chris Wright 1081 Red Hat Inc. 1082 chrisw@redhat.com 1084 Kevin Glavin 1085 Riverbed 1086 kevin.glavin@riverbed.com 1088 Hong (Cathy) Zhang 1089 Huawei US R&D 1090 cathy.h.zhang@huawei.com 1092 Louis Fourie 1093 Huawei US R&D 1094 louis.fourie@huawei.com 1096 Ron Parker 1097 Affirmed Networks 1098 ron_parker@affirmednetworks.com 1100 Myo Zarny 1101 Goldman Sachs 1102 myo.zarny@gs.com 1104 12. Acknowledgments 1106 The authors would like to thank Nagaraj Bagepalli, Abhijit Patra, 1107 Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal Mizrahi and Ken Gray 1108 for their detailed review, comments and contributions. 1110 A special thank you goes to David Ward and Tom Edsall for their 1111 guidance and feedback. 1113 Additionally the authors would like to thank Carlos Pignataro and 1114 Larry Kreeger for their invaluable ideas and contributions which are 1115 reflected throughout this document. 1117 Loa Andersson provided a thorough review and valuable comments, we 1118 thank him for that. 1120 Lastly, Reinaldo Penno deserves a particular thank you for his 1121 architecture and implementation work that helped guide the protocol 1122 concepts and design. 1124 13. IANA Considerations 1126 13.1. NSH EtherType 1128 An IEEE EtherType, 0x894F, has been allocated for NSH. 1130 13.2. Network Service Header (NSH) Parameters 1132 IANA is requested to create a new "Network Service Header (NSH) 1133 Parameters" registry. The following sub-sections request new 1134 registries within the "Network Service Header (NSH) Parameters " 1135 registry. 1137 13.2.1. NSH Base Header Reserved Bits 1139 There are ten bits at the beginning of the NSH Base Header. New bits 1140 are assigned via Standards Action [RFC5226]. 1142 Bits 0-1 - Version 1143 Bit 2 - OAM (O bit) 1144 Bit 3 - Critical TLV (C bit) 1145 Bits 4-9 - Reserved 1147 13.2.2. NSH Version 1149 IANA is requested to setup a registry of "NSH Version". New values 1150 are assigned via Standards Action [RFC5226]. 1152 Version 00: This protocol version. This document. 1153 Version 01: Reserved. This document. 1154 Version 10: Unassigned. 1155 Version 11: Unassigned. 1157 13.2.3. MD Type Registry 1159 IANA is requested to set up a registry of "MD Types". These are 1160 8-bit values. MD Type values 0, 1, 2, 254, and 255 are specified in 1161 this document. Registry entries are assigned by using the "IETF 1162 Review" policy defined in RFC 5226 [RFC5226]. 1164 +---------+--------------+---------------+ 1165 | MD Type | Description | Reference | 1166 +---------+--------------+---------------+ 1167 | 0 | Reserved | This document | 1168 | | | | 1169 | 1 | NSH | This document | 1170 | | | | 1171 | 2 | NSH | This document | 1172 | | | | 1173 | 3..253 | Unassigned | | 1174 | | | | 1175 | 254 | Experiment 1 | This document | 1176 | | | | 1177 | 255 | Experiment 2 | This document | 1178 +---------+--------------+---------------+ 1180 Table 1 1182 13.2.4. MD Class Registry 1184 IANA is requested to set up a registry of "MD Class". These are 16- 1185 bit values. Registry entries are assigned by using the "IETF Review" 1186 policy defined in RFC 5226 [RFC5226]. TLV Classes defined by this 1187 document are listed below. New values are assigned via Standards 1188 Action [RFC5226]. 1189 0x0000 to 0x01ff: IETF Consensus 1190 0x0200 to 0x7fff: Expert Review 1191 0xfff6 to 0xfffe: Experimental 1192 0xffff: Reserved 1194 13.2.5. NSH Base Header Next Protocol 1196 IANA is requested to set up a registry of "Next Protocol". These are 1197 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 1198 in this draft. New values are assigned via Standards Action 1199 [RFC5226]. 1201 +---------------+--------------+---------------+ 1202 | Next Protocol | Description | Reference | 1203 +---------------+--------------+---------------+ 1204 | 0 | Reserved | This document | 1205 | | | | 1206 | 1 | IPv4 | This document | 1207 | | | | 1208 | 2 | IPv6 | This document | 1209 | | | | 1210 | 3 | Ethernet | This document | 1211 | | | | 1212 | 4 | NSH | This document | 1213 | | | | 1214 | 5 | MPLS | This document | 1215 | | | | 1216 | 6..253 | Unassigned | | 1217 | | | | 1218 | 254 | Experiment 1 | This document | 1219 | | | | 1220 | 255 | Experiment 2 | This document | 1221 +---------------+--------------+---------------+ 1223 Table 2 1225 14. References 1227 14.1. Normative References 1229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1230 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1231 RFC2119, March 1997, 1232 . 1234 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1235 Service Function Chaining", RFC 7498, DOI 10.17487/ 1236 RFC7498, April 2015, 1237 . 1239 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1240 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/ 1241 RFC7665, October 2015, 1242 . 1244 14.2. Informative References 1246 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1247 DOI 10.17487/RFC1191, November 1990, 1248 . 1250 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1251 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, 1252 August 1996, . 1254 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1255 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1256 DOI 10.17487/RFC2784, March 2000, 1257 . 1259 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1260 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1261 DOI 10.17487/RFC5226, May 2008, 1262 . 1264 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1265 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1266 DOI 10.17487/RFC6071, February 2011, 1267 . 1269 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1270 Locator/ID Separation Protocol (LISP)", RFC 6830, 1271 DOI 10.17487/RFC6830, January 2013, 1272 . 1274 [VXLAN-gpe] 1275 Quinn, P., Manur, R., Agarwal, P., Kreeger, L., Lewis, D., 1276 Maino, F., Smith, M., Yong, L., Xu, X., Elzur, U., Garg, 1277 P., and D. Melman, "Generic Protocol Extension for VXLAN", 1278 . 1281 [broadalloc] 1282 Napper, J., Kumar, S., Muley, P., and W. Hendericks, "NSH 1283 Context Header Allocation -- Mobility", 2016, . 1287 [dcalloc] Guichard, J., Smith, M., and et al., "Network Service 1288 Header (NSH) Context Header Allocation (Data Center)", 1289 2016, . 1292 [nsh-sec] Reddy, T., Migault, D., Pignataro, C., Quinn, P., and C. 1293 Inacio, "NSH Security and Privacy requirements", 2016, . 1297 Authors' Addresses 1299 Paul Quinn (editor) 1300 Cisco Systems, Inc. 1302 Email: paulq@cisco.com 1304 Uri Elzur (editor) 1305 Intel 1307 Email: uri.elzur@intel.com