idnits 2.17.1 draft-ietf-mpls-sfc-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2019) is 1876 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) == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-09 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group A. Farrel 3 Internet-Draft Old Dog Consulting 4 Intended status: Standards Track S. Bryant 5 Expires: September 8, 2019 Huawei 6 J. Drake 7 Juniper Networks 8 March 7, 2019 10 An MPLS-Based Forwarding Plane for Service Function Chaining 11 draft-ietf-mpls-sfc-07 13 Abstract 15 This document describes how Service Function Chaining (SFC) can be 16 achieved in an MPLS network by means of a logical representation of 17 the Network Service Header (NSH) in an MPLS label stack. That is, 18 the NSH is not used, but the fields of the NSH are mapped to fields 19 in the MPLS label stack. It does not deprecate or replace the NSH, 20 but acknowledges that there may be a need for an interim deployment 21 of SFC functionality in brownfield networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 8, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 60 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5 62 4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5 63 4.3. Fine Control of Service Function Instances . . . . . . . 5 64 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 5 65 4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6 66 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 67 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7 68 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 69 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 11 70 9. A Note on Service Function Capabilities and SFC Proxies . . . 13 71 10. Control Plane Considerations . . . . . . . . . . . . . . . . 13 72 11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14 73 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15 75 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17 76 12.2.1. Loss of Inband Metadata . . . . . . . . . . . . . . 20 77 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 21 78 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 79 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 80 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 81 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 82 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 83 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 19.1. Normative References . . . . . . . . . . . . . . . . . . 28 85 19.2. Informative References . . . . . . . . . . . . . . . . . 29 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 88 1. Introduction 90 Service Function Chaining (SFC) is the process of directing packets 91 through a network so that they can be acted on by an ordered set of 92 abstract service functions before being delivered to the intended 93 destination. An architecture for SFC is defined in [RFC7665]. 95 When applying a particular Service Function Chain to the traffic 96 selected by a service classifier, the traffic needs to be steered 97 through an ordered set of Service Functions (SFs) in the network. 98 This ordered set of SFs is termed a Service Function Path (SFP), and 99 the traffic is passed between Service Function Forwarders (SFFs) that 100 are responsible for delivering the packets to the SFs and for 101 forwarding them onward to the next SFF. 103 In order to steer the selected traffic between SFFs and to the 104 correct SFs the service classifier needs to attach information to 105 each packet. This information indicates the SFP on which the packet 106 is being forwarded and hence the SFs to which it must be delivered. 107 The information also indicates the progress the packet has already 108 made along the SFP. 110 The Network Service Header (NSH) [RFC8300] has been defined to carry 111 the necessary information for Service Function Chaining in packets. 112 The NSH can be inserted into packets and contains various information 113 including a Service Path Indicator (SPI), a Service Index (SI), and a 114 Time To Live (TTL) counter. 116 Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed 117 forwarding technology that uses labels placed in a packet in a label 118 stack to identify the forwarding actions to be taken at each hop 119 through a network. Actions may include swapping or popping the 120 labels as well, as using the labels to determine the next hop for 121 forwarding the packet. Labels may also be used to establish the 122 context under which the packet is forwarded. In many cases, MPLS 123 will be used as a tunneling technology to carry packets through 124 networks between SFFs. 126 This document describes how Service Function Chaining can be achieved 127 in an MPLS network by means of a logical representation of the NSH in 128 an MPLS label stack. This approach is applicable to all forms of 129 MPLS forwarding (where labels are looked up at each hop, and swapped 130 or popped [RFC3031]). It does not deprecate or replace the NSH, but 131 acknowledges that there may be a need for an interim deployment of 132 SFC functionality in brownfield networks. The mechanisms described 133 in this document are a compromise between the full function that can 134 be achieved using the NSH, and the benefits of reusing the existing 135 MPLS forwarding paradigms (the approach defined here does not include 136 the O-bit defined in [RFC8300] and has some limitations to the use of 137 metadata as described in Section 12. 139 Section 4 provides a short overview of several use case scenarios 140 that help to explain the relationship between the MPLS label 141 operations (swapping, popping, stacking) and the MPLS encoding of the 142 logical NSH described in this document. 144 It is assumed that the reader is fully familiar with the terms and 145 concepts introduced in [RFC7665] and [RFC8300]. 147 Note that one of the features of the SFC architecture described in 148 [RFC7665] is the "SFC proxy" that exists to include legacy SFs that 149 are not able to process NSH-encapsulated packets. This issue is 150 equally applicable to the use of MPLS-encapsulated packets that 151 encode a logical representation of an NSH. It is discussed further 152 in Section 9. 154 2. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 3. Choice of Data Plane SPI/SI Representation 164 While [RFC8300] defines the NSH that can be used in a number of 165 environments, this document provides a mechanism to handle situations 166 in which the NSH is not ubiquitously deployed. In this case it is 167 possible to use an alternative data plane representation of the SPI/ 168 SI by carrying the identical semantics in MPLS labels. 170 In order to correctly select the mechanism by which SFC information 171 is encoded and carried between SFFs, it may be necessary to configure 172 the capabilities and choices either within the whole Service Function 173 Overlay Network, or on a hop by hop basis. It is a requirement that 174 both ends of a tunnel over the underlay network (i.e., a pair of SFFs 175 adjacent in the SFC) know that the tunnel is used for SFC and know 176 what form of NSH representation is used. A control plane signalling 177 approach to achieve these objectives is provided using BGP in 178 [I-D.ietf-bess-nsh-bgp-control-plane]. 180 Note that the encoding of the SFC information is independent of the 181 choice of tunneling technology used between SFFs. Thus, an MPLS 182 representation of the logical NSH (as defined in this document) may 183 be used even if the tunnel between a pair of SFFs is not an MPLS 184 tunnel. Conversely, MPLS tunnels may be used to carry other 185 encodings of the logical NSH (specifically, the NSH itself). 187 4. Use Case Scenarios 189 There are five scenarios that can be considered for the use of an 190 MPLS encoding in support of SFC. These are set out in the following 191 sub-sections. 193 4.1. Label Swapping for Logical NSH 195 The primary use case for SFC is described in [RFC7665] and delivered 196 using the NSH which, as described in [RFC8300], uses an encapsulation 197 with a position indicator that is modified at each SFC hop along the 198 chain to indicate the next hop. 200 The label swapping use case scenario effectively replaces the NSH 201 with an MPLS encapsulation as described in Section 6. The MPLS 202 labels encode the same information as the NSH to form a logical NSH. 203 The labels are modified (swapped per [RFC3031]) at each SFC hop along 204 the chain to indicate the next hop. The processing and forwarding 205 state for a chain (i.e., the actions to take on a received label) are 206 programmed in to the network using a control plane or management 207 plane. 209 4.2. Hierarchical Encapsulation 211 [RFC8459] describes an architecture for hierarchical encapsulation 212 using the NSH. It facilitates partitioning of SFC domains for 213 administrative reasons, and allows concatenation of service function 214 chains under the control of a service classifier. 216 The same function can be achieved in an MPLS network using an MPLS 217 encoding of the logical NSH, and label stacking as defined in 218 [RFC3031] and described in Section 7. In this model, swapping is 219 used per Section 4.1 to navigate one chain, and when the end of the 220 chain is reached, the final label is popped revealing the label for 221 another chain. Thus, the primary mode is swapping, but stacking is 222 used to enable the ingress classifier to control concatenation of 223 service function chains. 225 4.3. Fine Control of Service Function Instances 227 It may be that a service function chain (as described in Section 4.1) 228 allows some leeway in the choice of service function instances along 229 the chain. However, it may be that a service classifier wishes to 230 constrain the choice and this can be achieved using chain 231 concatenation so that the first chain ends at the point of choice, 232 the next label in the stack indicates the specific service function 233 instance to be executed, and the next label in the stack starts a new 234 chain. Thus, a mixture of label swapping and stacking is used. 236 4.4. Micro Chains and Label Stacking 238 The scenario in Section 4.2 may be extended to its logical extreme by 239 making each concatenated chain as short as it can be: one service 240 function. Each label in the stack indicates the next service 241 function to be executed, and the network is programmed through the 242 control plane or management plane to know how to route to the next 243 (i.e., first) hop in each chain just as it would be to support the 244 scenarios in Section 4.1 and Section 4.2. 246 This scenario is functionally identical to the use of MPLS-SR for SFC 247 as described Section 4.5, and the discussion in that section applies 248 to this section as well. 250 4.5. SFC and Segment Routing 252 Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a 253 stack of MPLS labels to encode information about the path and network 254 functions that a packet should traverse. MPLS-SR is achieved by 255 applying control plane and management plane techniques to program the 256 MPLS forwarding plane, and by imposing labels on packets at the 257 entrance to the MPLS-SR network. An implementation proposal for 258 achieving SFC using MPLS-SR can be found in 259 [I-D.xuclad-spring-sr-service-programming] and is not discussed 260 further in this document. 262 5. Basic Unit of Representation 264 When an MPLS label stack is used to carry a logical NSH, a basic unit 265 of representation is used. This unit comprises two MPLS labels as 266 shown below. The unit may be present one or more times in the label 267 stack as explained in subsequent sections. 269 In order to convey the same information as is present in the NSH, two 270 MPLS label stack entries are used. One carries a label to provide 271 context within the SFC scope (the SFC Context Label), and the other 272 carries a label to show which service function is to be actioned (the 273 SF Label). This two-label unit is shown in Figure 1. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | SFC Context Label | TC |S| TTL | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | SF Label | TC |S| TTL | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 1: The Basic Unit of MPLS Label Stack for SFC 285 The fields of these two label stack entries are encoded as follows: 287 Label: The Label fields contain the values of the SFC Context Label 288 and the SF Label encoded as 20 bit integers. The precise 289 semantics of these label fields are dependent on whether the label 290 stack entries are used for MPLS label swapping (see Section 6) or 291 MPLS label stacking (see Section 7). 293 TC: The TC bits have no meaning in this case. They SHOULD be set to 294 zero in both label stack entries when a packet is sent and MUST be 295 ignored on receipt. 297 S: The bottom of stack bit has its usual meaning in MPLS. It MUST be 298 clear in the SFC Context label stack entry. In the SF label stack 299 entry it MUST be clear in all cases except when the label is the 300 bottom of stack, when it MUST be set. 302 TTL: The TTL field in the SFC Context label stack entry SHOULD be 303 set to 1. The TTL in SF label stack entry (called the SF TTL) is 304 set according to its use for MPLS label swapping (see Section 6) 305 or MPLS label stacking (see Section 7 and is used to mitigate 306 packet loops. 308 The sections that follow show how this basic unit of MPLS label stack 309 may be used for SFC in the MPLS label swapping case and in the MPLS 310 label stacking. For simplicity, these sections do not describe the 311 use of metadata: that is covered separately in Section 12. 313 6. MPLS Label Swapping 315 This section describes how the basic unit of MPLS label stack for SFC 316 introduced in Section 5 is used when MPLS label swapping is in use. 317 The use case scenario for this approach is introduced in Section 4.1. 319 As can be seen from Figure 2, the top of the label stack comprises 320 the labels necessary to deliver the packet over the MPLS tunnel 321 between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS 322 in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel 323 technology does not need to be MPLS, but that is shown here for 324 simplicity. 326 An entropy label ([RFC6790]) may also be present as described in 327 Section 11. 329 Under these labels (or other encapsulation) comes a single instance 330 of the basic unit of MPLS label stack for SFC. In addition to the 331 interpretation of the fields of these label stack entries provided in 332 Section 5 the following meanings are applied: 334 SPI Label: The Label field of the SFC Context label stack entry 335 contains the value of the SPI encoded as a 20 bit integer. The 336 semantics of the SPI is exactly as defined in [RFC8300]. Note 337 that an SPI as defined by [RFC8300] can be encoded in 3 octets 338 (i.e., 24 bits), but that the Label field allows for only 20 bits 339 and reserves the values 0 though 15 as 'special purpose' labels 340 [RFC7274]. Thus, a system using MPLS representation of the 341 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 342 less than 16. 344 SI Label: The Label field of the SF label stack entry contains the 345 value of the SI exactly as defined in [RFC8300]. Since the SI 346 requires only 8 bits, and to avoid overlap with the 'special 347 purpose' label range of 0 through 15 [RFC7274], the SI is carried 348 in the top (most significant) 8 bits of the Label field with the 349 low order 12 bits set to zero. 351 TC: The TC fields are as described in Section 5. 353 S: The S bits are as described in Section 5. 355 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 356 as stated in Section 5. The TTL in SF label stack entry is 357 decremented once for each forwarding hop in the SFP, i.e., for 358 each SFF transited, and so mirrors the TTL field in the NSH. 360 --------------- 361 ~ Tunnel Labels ~ 362 +---------------+ 363 ~ Optional ~ 364 ~ Entropy Label ~ 365 +---------------+ - - - 366 | SPI Label | 367 +---------------+ Basic unit of MPLS label stack for SFC 368 | SI Label | 369 +---------------+ - - - 370 | | 371 ~ Payload ~ 372 | | 373 --------------- 375 Figure 2: The MPLS SFC Label Stack 377 The following processing rules apply to the Label fields: 379 o When a classifier inserts a packet onto an SFP it sets the SPI 380 Label to indicate the identity of the SFP, and sets the SI Label 381 to indicate the first SF in the path. 383 o When a component of the SFC system processes a packet it uses the 384 SPI Label to identify the SFP and the SI Label to determine which 385 SFF or instance of an SF (an SFI) to deliver the packet to. Under 386 normal circumstances (with the exception of branching and re- 387 classification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the 388 SPI Label value is preserved on all packets. The SI Label value 389 is modified by SFFs and through re-classification to indicate the 390 next hop along the SFP. 392 The following processing rules apply to the TTL field of the SF label 393 stack entry, and are derived from section 2.2 of [RFC8300]: 395 o When a classifier places a packet onto an SFP it MUST set the TTL 396 to a value between 1 and 255. It SHOULD set this according to the 397 expected length of the SFP (i.e., the number of SFs on the SFP), 398 but it MAY set it to a larger value according to local 399 configuration. The maximum TTL value supported in an NSH is 63, 400 and so the practical limit here may also be 63. 402 o When an SFF receives a packet from any component of the SFC system 403 (classifier, SFI, or another SFF) it MUST discard any packets with 404 TTL set to zero. It SHOULD log such occurrences, but MUST apply 405 rate limiting to any such logs. 407 o An SFF MUST decrement the TTL by one each time it performs a 408 lookup to forward a packet to the next SFF. 410 o If an SFF decrements the TTL to zero it MUST NOT send the packet, 411 and MUST discard the packet. It SHOULD log such occurrences, but 412 MUST apply rate limiting to any such logs. 414 o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF 415 unmodified along with the SI (which may have been changed by local 416 re-classification). 418 o If a classifier along the SFP makes any change to the intended 419 path of the packet including for looping, jumping, or branching 420 (see [I-D.ietf-bess-nsh-bgp-control-plane]) it MUST NOT change the 421 SI TTL of the packet. In particular, each component of the SFC 422 system MUST NOT increase the SI TTL value otherwise loops may go 423 undetected. 425 7. MPLS Label Stacking 427 This section describes how the basic unit of MPLS label stack for SFC 428 introduced in Section 5 is used when MPLS label stacking is used to 429 carry information about the SFP and SFs to be executed. The use case 430 scenarios for this approach is introduced in Section 4. 432 As can be seen in Figure 3, the top of the label stack comprises the 433 labels necessary to deliver the packet over the MPLS tunnel between 434 SFFs. Any MPLS encapsulation may be used. 436 An entropy label ([RFC6790]) may also be present as described in 437 Section 11. 439 Under these labels comes one of more instances of the basic unit of 440 MPLS label stack for SFC. In addition to the interpretation of the 441 fields of these label stack entries provided in Section 5 the 442 following meanings are applied: 444 SFC Context Label: The Label field of the SFC Context label stack 445 entry contains a label that delivers SFC context. This label may 446 be used to indicate the SPI encoded as a 20 bit integer using the 447 semantics of the SPI is exactly as defined in [RFC8300] and noting 448 that in this case a system using MPLS representation of the 449 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 450 less than 16. This label may also be used to convey other SFC 451 context-specific semantics such as indicating how to interpret the 452 SF Label or how to forward the packet to the node that offers the 453 SF if so configured and coordinated with the controller that 454 programs the labels for the SFP. 456 SF Label: The Label field of the SF label stack entry contains a 457 value that identifies the next SFI to be actioned for the packet. 458 This label may be scoped globally or within the context of the 459 preceding SFC Context Label and comes from the range 16 ... 2^20 - 460 1. 462 TC: The TC fields are as described in Section 5. 464 S: The S bits are as described in Section 5. 466 TTL: The TTL fields in the SFC Context label stack entry and in the 467 SF label stack entry SHOULD be set to 1 as stated in Section 5, 468 but MAY be set to larger values if the label indicated a 469 forwarding operation towards the node that hosts the SF. 471 ------------------- 472 ~ Tunnel Labels ~ 473 +-------------------+ 474 ~ Optional ~ 475 ~ Entropy Label ~ 476 +-------------------+ - - - 477 | SFC Context Label | 478 +-------------------+ Basic unit of MPLS label stack for SFC 479 | SF Label | 480 +-------------------+ - - - 481 | SFC Context Label | 482 +-------------------+ Basic unit of MPLS label stack for SFC 483 | SF Label | 484 +-------------------+ - - - 485 ~ ~ 486 +-------------------+ - - - 487 | SFC Context Label | 488 +-------------------+ Basic unit of MPLS label stack for SFC 489 | SF Label | 490 +-------------------+ - - - 491 | | 492 ~ Payload ~ 493 | | 494 ------------------- 496 Figure 3: The MPLS SFC Label Stack for Label Stacking 498 The following processing rules apply to the Label fields: 500 o When a classifier inserts a packet onto an SFP it adds a stack 501 comprising one or more instances of the basic unit of MPLS label 502 stack for SFC. Taken together, this stack defines the SFs to be 503 actioned and so defines the SFP that the packet will traverse. 505 o When a component of the SFC system processes a packet it uses the 506 top basic unit of label stack for SFC to determine to which SFI to 507 next deliver the packet. When an SFF receives a packet it 508 examines the top basic unit of MPLS label stack for SFC to 509 determine where to send the packet next. If the next recipient is 510 a local SFI, the SFC strips the basic unit of MPLS label stack for 511 SFC before forwarding the packet. 513 8. Mixed Mode Forwarding 515 The previous sections describe homogeneous networks where SFC 516 forwarding is either all label swapping or all label popping 517 (stacking). This simplification helps to clarify the explanation of 518 the mechanisms. 520 However, as described in Section 4.2, some uses cases may use label 521 swapping and stacking at the same time. Furthermore, it is also 522 possible that different parts of the network utilize swapping or 523 popping such that an end-to-end service chain has to utilize a 524 combination of both techniques. It is also worth noting that a 525 classifier may be content to use an SFP as installed in the network 526 by a control plane or management plane and so would use label 527 swapping, but that there may be a point in the SFP where a choice of 528 SFIs can be made (perhaps for load balancing) and where, in this 529 instance, the classifier wishes to exert control over that choice by 530 use of a specific entry on the label stack as described in 531 Section 4.3. 533 When an SFF receives a packet containing an MPLS label stack, it 534 checks from the context of the incoming interface, and from the SFP 535 indicated by the top label whether it is processing an {SPI, SI} 536 label pair for label swapping or a {context label, SFI index} label 537 pair for label stacking. It then selects the appropriate SFI to 538 which to send the packet. When it receives the packet back from the 539 SFI, it has four cases to consider. 541 o If the current hop requires an {SPI, SI} and the next hop requires 542 an {SPI, SI}, it sets the SPI label according to the SFP to be 543 traversed, selects an instance of the SF to be executed at the 544 next hop, sets the SI label to the SI value of the next hop, and 545 tunnels the packet to the SFF for that SFI. 547 o If the current hop requires an {SPI, SI} and the next hop requires 548 a {context label, SFI label}, it pops the {SPI, SI} from the top 549 of the MPLS label stack and tunnels the packet to the SFF 550 indicated by the context label. 552 o If the current hop requires a {context label, SFI label}, it pops 553 the {context label, SFI label} from the top of the MPLS label 554 stack. 556 * If the new top of the MPLS label stack contains an {SPI, SI} 557 label pair, it selects an SFI to use at the next hop, and 558 tunnels the packet to SFF for that SFI. 560 * If the new top of the MPLS label stack contains a {context 561 label, SFI label}, it tunnels the packet to the SFF indicated 562 by the context label. 564 9. A Note on Service Function Capabilities and SFC Proxies 566 The concept of an "SFC proxy" is introduced in [RFC7665]. An SFC 567 proxy is logically located between an SFF and an SFI that is not 568 "SFC-aware". Such SFIs are not capable of handling the SFC 569 encapsulation (whether that be NSH or MPLS) and need the 570 encapsulation stripped from the packets they are to process. In many 571 cases, legacy SFIs that were once deployed as "bumps in the wire" fit 572 into this category until they have been upgraded to be SFC-aware. 574 The job of an SFC proxy is to remove and then reimpose SFC 575 encapsulation so that the SFF is able to process as though it was 576 communication with an SFC-aware SFI, and so that the SFI is unaware 577 of the SFC encapsulation. In this regard, the job of an SFC proxy is 578 no different when NSH encapsulation is used and when MPLS 579 encapsulation is used as described in this document, although (of 580 course) it is different encapsulation bytes that must be removed and 581 reimposed. 583 It should be noted that the SFC proxy is a logical function. It 584 could be implemented as a separate physical component on the path 585 from the SFF to SFI, but it could be co-resident with the SFF or it 586 could be a component of the SFI. This is purely an implementation 587 choice. 589 Note also that the delivery of metadata (see Section 12) requires 590 specific processing if an SFC proxy is in use. This is also no 591 different when NSH or the MPLS encoding defined in this document is 592 in use, and how it is handled will depend on how (or if) each non- 593 SFC-aware SFI can receive metadata. 595 10. Control Plane Considerations 597 In order that a packet may be forwarded along an SFP several 598 functional elements must be executed. 600 o Discovery/advertisement of SFIs. 602 o Computation of SFP. 604 o Programming of classifiers. 606 o Advertisement of forwarding instructions. 608 Various approaches may be taken. These include a fully centralized 609 model where SFFs report to a central controller the SFIs that they 610 support, the central controller computes the SFP and programs the 611 classifiers, and (if the label swapping approach is taken) the 612 central controller installs forwarding state in the SFFs that lie on 613 the SFP. 615 Alternatively, a dynamic control plane may be used such as that 616 described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the 617 SFFs use the control plane to advertise the SFIs that they support, a 618 central controller computes the SFP and programs the classifiers, and 619 (if the label swapping approach is taken) the central controller uses 620 the control plane to advertise the SFPs so that SFFs that lie on the 621 SFP can install the necessary forwarding state. 623 11. Use of the Entropy Label 625 Entropy is used in ECMP situations to ensure that packets from the 626 same flow travel down the same path, thus avoiding jitter or re- 627 ordering issues within a flow. 629 Entropy is often determined by hashing on specific fields in a packet 630 header such as the "five-tuple" in the IP and transport headers. 631 However, when an MPLS label stack is present, the depth of the stack 632 could be too large for some processors to correctly determine the 633 entropy hash. This problem is addressed by the inclusion of an 634 Entropy Label as described in [RFC6790]. 636 When entropy is desired for packets as they are carried in MPLS 637 tunnels over the underlay network, it is RECOMMENDED that an Entropy 638 Label is included in the label stack immediately after the tunnel 639 labels and before the SFC labels as shown in Figure 2 and Figure 3. 641 If an Entropy Label is present in an MPLS payload, it is RECOMMENDED 642 that the initial classifier use that value in an Entropy Label 643 inserted in the label stack when the packet is forwarded (on the 644 first tunnel) to the first SFF. In this case it is not necessary to 645 remove the Entropy Label from the payload. 647 12. Metadata 649 Metadata is defined in [RFC7665] as providing "the ability to 650 exchange context information between classifiers and SFs, and among 651 SFs." [RFC8300] defines how this context information can be directly 652 encoded in fields that form part of the NSH encapsulation. 654 The next two sections describe how metadata is associated with user 655 data packets, and how metadata may be exchanged between SFC nodes in 656 the network, when using an MPLS encoding of the logical 657 representation of the NSH. 659 It should be noted that the MPLS encoding is less functional than the 660 direct use of the NSH. Both methods support metadata that is "per- 661 SFP" or "per-packet-flow" (see [RFC8393] for definitions of these 662 terms), but "per-packet" metadata (where the metadata must be carried 663 on each packet because it differs from one packet to the next even on 664 the same flow or SFP) is only supported using the NSH and not using 665 the mechanisms defined in this document. 667 12.1. Indicating Metadata in User Data Packets 669 Metadata is achieved in the MPLS realization of the logical NSH by 670 the use of an SFC Metadata Label which uses the Extended Special 671 Purpose Label construct [RFC7274]. Thus, three label stack entries 672 are present as shown in Figure 4: 674 o The Extension Label (value 15) 676 o An extended special purpose label called the Metadata Label 677 Indicator (MLI) (value TBD1 by IANA) 679 o The Metadata Label (ML). 681 ---------------- 682 | Extension = 15 | 683 +----------------+ 684 | MLI | 685 +----------------+ 686 | Metadata Label | 687 --------------- 689 Figure 4: The MPLS SFC Metadata Label 691 The Metadata Label value is an index into a table of metadata that is 692 programmed into the network using in-band or out-of-band mechanisms. 693 Out-of-band mechanisms potentially include management plane and 694 control plane solutions (such as 695 [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this 696 document. The in-band mechanism is described in Section 12.2 698 The SFC Metadata Label (as a set of three labels as indicated in 699 Figure 4) may be present zero, one, or more times in an MPLS SFC 700 packet. For MPLS label swapping, the SFC Metadata Labels are placed 701 immediately after the basic unit of MPLS label stack for SFC as shown 702 in Figure 5. For MPLS label stacking, the SFC Metadata Labels are 703 placed at the bottom of the label stack as shown in Figure 6. 705 ---------------- 706 ~ Tunnel Labels ~ 707 +----------------+ 708 ~ Optional ~ 709 ~ Entropy Label ~ 710 +----------------+ 711 | SPI Label | 712 +----------------+ 713 | SI Label | 714 +----------------+ 715 | Extension = 15 | 716 +----------------+ 717 | MLI | 718 +----------------+ 719 | Metadata Label | 720 +----------------+ 721 ~ Other ~ 722 | Metadata | 723 ~ Label Triples ~ 724 +----------------+ 725 | | 726 ~ Payload ~ 727 | | 728 ---------------- 730 Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata 731 Label 733 ------------------- 734 ~ Tunnel Labels ~ 735 +-------------------+ 736 ~ Optional ~ 737 ~ Entropy Label ~ 738 +-------------------+ 739 | SFC Context Label | 740 +-------------------+ 741 | SF Label | 742 +-------------------+ 743 ~ ~ 744 +-------------------+ 745 | SFC Context Label | 746 +-------------------+ 747 | SF Label | 748 +-------------------+ 749 | Extension = 15 | 750 +-------------------+ 751 | MLI | 752 +-------------------+ 753 | Metadata Label | 754 +-------------------+ 755 ~ Other ~ 756 | Metadata | 757 ~ Label Triples ~ 758 +-------------------+ 759 | | 760 ~ Payload ~ 761 | | 762 ------------------- 764 Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata 765 Label 767 12.2. Inband Programming of Metadata 769 A mechanism for sending metadata associated with an SFP without a 770 payload packet is described in [RFC8393]. The same approach can be 771 used in an MPLS network where the NSH is logically represented by an 772 MPLS label stack. 774 The packet header is formed exactly as previously described in this 775 document so that the packet will follow the SFP through the SFC 776 network. However, instead of payload data, metadata is included 777 after the bottom of the MPLS label stack. An Extended Special 778 Purpose Label is used to indicate that the metadata is present. 779 Thus, three label stack entries are present: 781 o The Extension Label (value 15) 783 o An extended special purpose label called the Metadata Present 784 Indicator (MPI) (value TBD2 by IANA) 786 o The Metadata Label (ML) that is associated with this metadata on 787 this SFP and can be used to indicate the use of the metadata as 788 described in Section 12. 790 The SFC Metadata Present Label, if present, is placed immediately 791 after the last basic unit of MPLS label stack for SFC. The resultant 792 label stacks are shown in Figure 7 for the MPLS label swapping case 793 and Figure 8 for the MPLS label stacking case. 795 --------------- 796 ~ Tunnel Labels ~ 797 +---------------+ 798 ~ Optional ~ 799 ~ Entropy Label ~ 800 +---------------+ 801 | SPI Label | 802 +---------------+ 803 | SI Label | 804 +---------------+ 805 | Extension = 15| 806 +---------------+ 807 | MPI | 808 +---------------+ 809 | Metadata Label| 810 +---------------+ 811 | | 812 ~ Metadata ~ 813 | | 814 --------------- 816 Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying 817 Metadata 819 ------------------- 820 ~ Tunnel Labels ~ 821 +-------------------+ 822 ~ Optional ~ 823 ~ Entropy Label ~ 824 +-------------------+ 825 | SFC Context Label | 826 +-------------------+ 827 | SF Label | 828 +-------------------+ 829 | SFC Context Label | 830 +-------------------+ 831 | SF Label | 832 +-------------------+ 833 ~ ~ 834 +-------------------+ 835 | SFC Context Label | 836 +-------------------+ 837 | SF Label | 838 +-------------------+ 839 | Extension = 15 | 840 +-------------------+ 841 | MPI | 842 +-------------------+ 843 | Metadata Label | 844 +-------------------+ 845 | | 846 ~ Metadata ~ 847 | | 848 ------------------- 850 Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying 851 Metadata 853 In both cases the metadata is formatted as a TLV as shown in 854 Figure 9. 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Length | Metadata Type | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 ~ Metadata ~ 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Figure 9: The Metadata TLV 866 The fields of this TLV are interpreted as follows: 868 Length: The length of the metadata carried in the Metadata field in 869 octets not including any padding. 871 Metadata Type: The type of the metadata present. Values for this 872 field are taken from the "MD Types" registry maintained by IANA 873 and defined in [RFC8300] and encoded with the most significant bit 874 first. 876 Metadata: The actual metadata formatted as described in whatever 877 document defines the metadata. This field is end-padded with zero 878 to three octets of zeroes to take it up to a four octet boundary. 880 12.2.1. Loss of Inband Metadata 882 Note that inband exchange of metadata is vulnerable to packet loss. 883 This is both a risk arising from network faults and an attack 884 vulnerability. 886 If packets that arrive at an SFF use an MLI that does not have an 887 entry in the metadata table, an alarm can be raised and the packet 888 can be discarded or processed without the metadata according to local 889 configuration. This provides some long-term mitigation, but is not 890 an ideal solution. 892 Further mitigation to loss of metadata packets can be achieved by 893 retransmitting them at a configurable interval. This is a relatively 894 cheap, but only partial solution because there may still be a window 895 during which the metadata has not been received. 897 The concern of lost metadata may be particularly important when the 898 metadata applicable to a specific MPI is being changed. This could 899 result in out-of-date metadata being applied to a packet. If this is 900 a concern, it is RECOMMENDED that a new MPI is used to install a new 901 entry in the metadata table, and the packets in the flow should be 902 marked with the equivalent new MLI. 904 Finally, if an application that requires metadata is sensitive to 905 this potential loss or attack, it SHOULD NOT use inband metadata 906 distribution, but SHOULD rely on control plane or management plane 907 mechanisms because these approaches can use a more sophisticated 908 protocol that includes confirmation of delivery, and can perform 909 verification or inspection of entries in the metadata table. 911 13. Worked Examples 913 This section reverts to the simplified descriptions of networks that 914 rely wholly on label swapping or label stacking. As described in 915 Section 4, actual deployment scenarios may depend on the use of both 916 mechanisms and utilize a mixed mode as described in Section 8. 918 Consider the simplistic MPLS SFC overlay network shown in Figure 10. 919 A packet is classified for an SFP that will see it pass through two 920 Service Functions, SFa and SFb, that are accessed through Service 921 Function Forwarders SFFa and SFFb respectively. The packet is 922 ultimately delivered to destination, D. 924 Let us assume that the SFP is computed and assigned the SPI of 239. 925 The forwarding details of the SFP are distributed (perhaps using the 926 mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs 927 are programmed with the necessary forwarding instructions. 929 The packet progresses as follows: 931 a. The classifier assigns the packet to the SFP and imposes two 932 label stack entries comprising a single basic unit of MPLS SFC 933 representation: 935 * The higher label stack entry contains a label carrying the SPI 936 value of 239. 938 * The lower label stack entry contains a label carrying the SI 939 value of 255. 941 Further labels may be imposed to tunnel the packet from the 942 classifier to SFFa. 944 b. When the packet arrives at SFFa it strips any labels associated 945 with the tunnel that runs from the classifier to SFFa. SFFa 946 examines the top labels and matches the SPI/SI to identify that 947 the packet should be forwarded to SFa. The packet is forwarded 948 to SFa unmodified. 950 c. SFa performs its designated function and returns the packet to 951 SFFa. 953 d. SFFa modifies the SI in the lower label stack entry (to 254) and 954 uses the SPI/SI to look up the forwarding instructions. It sends 955 the packet with two label stack entries: 957 * The higher label stack entry contains a label carrying the SPI 958 value of 239. 960 * The lower label stack entry contains a label carrying the SI 961 value of 254. 963 Further labels may be imposed to tunnel the packet from the SFFa 964 to SFFb. 966 e. When the packet arrives at SFFb it strips any labels associated 967 with the tunnel from SFFa. SFFb examines the top labels and 968 matches the SPI/SI to identify that the packet should be 969 forwarded to SFb. The packet is forwarded to SFb unmodified. 971 f. SFb performs its designated function and returns the packet to 972 SFFb. 974 g. SFFb modifies the SI in the lower label stack entry (to 253) and 975 uses the SPI/SI to lookup up the forwarding instructions. It 976 determines that it is the last SFF in the SFP so it strips the 977 two SFC label stack entries and forwards the payload toward D 978 using the payload protocol. 980 +---------------------------------------------------+ 981 | MPLS SFC Network | 982 | | 983 | +---------+ +---------+ | 984 | | SFa | | SFb | | 985 | +----+----+ +----+----+ | 986 | ^ | | ^ | | | 987 | (b)| | |(c) (e)| | |(f) | 988 | (a) | | V (d) | | V (g) | 989 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 990 |Classifier+------+ SFFa +-------+ SFFb +------+ D | 991 +----------+ +---------+ +---------+ +-------+ 992 | | 993 +---------------------------------------------------+ 995 Figure 10: Service Function Chaining in an MPLS Network 997 Alternatively, consider the MPLS SFC overlay network shown in 998 Figure 11. A packet is classified for an SFP that will see it pass 999 through two Service Functions, SFx and SFy, that are accessed through 1000 Service Function Forwarders SFFx and SFFy respectively. The packet 1001 is ultimately delivered to destination, D. 1003 Let us assume that the SFP is computed and assigned the SPI of 239. 1004 However, the forwarding state for the SFP is not distributed and 1005 installed in the network. Instead it will be attached to the 1006 individual packets using the MPLS label stack. 1008 The packet progresses as follows: 1010 1. The classifier assigns the packet to the SFP and imposes two 1011 basic units of MPLS SFC representation to describe the full SFP: 1013 * The top basic unit comprises two label stack entries as 1014 follows: 1016 + The higher label stack entry contains a label carrying the 1017 SFC context. 1019 + The lower label stack entry contains a label carrying the 1020 SF indicator for SFx. 1022 * The lower basic unit comprises two label stack entries as 1023 follows: 1025 + The higher label stack entry contains a label carrying the 1026 SFC context. 1028 + The lower label stack entry contains a label carrying the 1029 SF indicator for SFy. 1031 Further labels may be imposed to tunnel the packet from the 1032 classifier to SFFx. 1034 2. When the packet arrives at SFFx it strips any labels associated 1035 with the tunnel from the classifier. SFFx examines the top 1036 labels and matches the context/SF values to identify that the 1037 packet should be forwarded to SFx. The packet is forwarded to 1038 SFx unmodified. 1040 3. SFx performs its designated function and returns the packet to 1041 SFFx. 1043 4. SFFx strips the top basic unit of MPLS SFC representation 1044 revealing the next basic unit. It then uses the revealed 1045 context/SF values to determine how to route the packet to the 1046 next SFF, SFFy. It sends the packet with just one basic unit of 1047 MPLS SFC representation comprising two label stack entries: 1049 * The higher label stack entry contains a label carrying the SFC 1050 context. 1052 * The lower label stack entry contains a label carrying the SF 1053 indicator for SFy. 1055 Further labels may be imposed to tunnel the packet from the SFFx 1056 to SFFy. 1058 5. When the packet arrives at SFFy it strips any labels associated 1059 with the tunnel from SFFx. SFFy examines the top labels and 1060 matches the context/SF values to identify that the packet should 1061 be forwarded to SFy. The packet is forwarded to SFy unmodified. 1063 6. SFy performs its designated function and returns the packet to 1064 SFFy. 1066 7. SFFy strips the top basic unit of MPLS SFC representation 1067 revealing the payload packet. It forwards the payload toward D 1068 using the payload protocol. 1070 +---------------------------------------------------+ 1071 | MPLS SFC Network | 1072 | | 1073 | +---------+ +---------+ | 1074 | | SFx | | SFy | | 1075 | +----+----+ +----+----+ | 1076 | ^ | | ^ | | | 1077 | (2)| | |(3) (5)| | |(6) | 1078 | (1) | | V (4) | | V (7) | 1079 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 1080 |Classifier+------+ SFFx +-------+ SFFy +------+ D | 1081 +----------+ +---------+ +---------+ +-------+ 1082 | | 1083 +---------------------------------------------------+ 1085 Figure 11: Service Function Chaining Using MPLS Label Stacking 1087 14. Implementation Notes 1089 It is not the job of an IETF specification to describe the internals 1090 of an implementation except where that directly impacts upon the bits 1091 on the wire that change the likelihood of interoperability, or where 1092 the availability of configuration or security options directly affect 1093 the utility of an implementation. 1095 However, in view of the objective of this document to acknowledge 1096 that there may be a need for an interim deployment of SFC 1097 functionality in brownfield MPLS networks, this section provides some 1098 observations about how an SFF might utilize MPLS features that are 1099 available in existing routers. This section is not intended to be 1100 definitive or technically complete, but is indicative. 1102 Consider the mechanism used to indicate to which Virtual Routing and 1103 Forwarding (VRF) an incoming MPLS packet should be routed in a Layer 1104 3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top 1105 MPLS label is an indicator of the VRF that is to be used to route the 1106 payload. 1108 A similar approach can be taken with the label swapping SFC technique 1109 described in Section 6 such that the SFC Context Label identifies a 1110 routing table specific to the SFP. The SF Label can be looked up in 1111 the context of this routing table to determine to which SF to direct 1112 the packet, and how to forward it to the next SFF. 1114 Advanced features (such as metadata) are not inspected by SFFs. The 1115 packets are passed to SFIs that are MPLS-SFC-aware or to SFC proxies, 1116 and those components are responsible for handling all metadata 1117 issues. 1119 Of course, an actual implementation might make considerable 1120 optimizations on this approach, but this section should provide hints 1121 about how MPLS-based SFC might be achieved with relatively small 1122 modifications to deployed MPLS devices. 1124 15. Security Considerations 1126 Discussion of the security properties of SFC networks can be found in 1127 [RFC7665]. Further security discussion for the NSH and its use is 1128 present in [RFC8300]. Those documents provide analysis and present a 1129 set of requirements and recommendations for security and the 1130 normative security requirements from those documents apply to this 1131 specification. However, it should be noted that those documents do 1132 not describe any mechanisms for securing NSH systems. 1134 It is fundamental to the SFC design that the classifier is a fully 1135 trusted element. That is, the classification decision process is not 1136 visible to the other elements and its output is treated as accurate. 1137 As such, the classifier has responsibility for determining the 1138 processing that the packet will be subject to, including, for 1139 example, firewall functions. It is also fundamental to the MPLS 1140 design that packets are routed through the network using the path 1141 specified by the node imposing the labels, and that labels are 1142 swapped or popped correctly. Where an SF is not encapsulation-aware 1143 the encapsulation may be stripped by an SFC proxy such that packet 1144 may exist as a native packet (perhaps IP) on the path between SFC 1145 proxy and SF, however this is an intrinsic part of the SFC design 1146 which needs to define how a packet is protected in that environment. 1148 SFC components are configured and enabled through a management system 1149 or a control plane. This document does not make any assumptions 1150 about what mechanisms are used. Deployments should, however, be 1151 aware that vulnerabilities in the management plane or control plane 1152 of an SFC system imply vulnerabilities in the whole SFC system. 1153 Thus, control plane solutions (such as 1154 [I-D.ietf-bess-nsh-bgp-control-plane]) and management plane 1155 mechanisms must include security measures that can be enable by 1156 operators to protect their SFC systems. 1158 An analysis of the security of MPLS systems is provided in [RFC5920]. 1159 That document notes the MPLS forwarding plane has no built-in 1160 security mechanisms. Some proposals to add encryption to the MPLS 1161 forwarding plane have been suggested 1162 ([I-D.ietf-mpls-opportunistic-encrypt]), but no mechanisms have been 1163 agreed at the time of publication of this document. Additionally, 1164 MPLS does not provide any cryptographic integrity protection on the 1165 MPLS headers. That means that procedures described in this document 1166 rely on three basic principles: 1168 o The MPLS network is often considered to be a closed network such 1169 that insertion, modification, or inspection of packets by an 1170 outside party is not possible. MPLS networks are operated with 1171 closed boundaries so that MPLS encapsulated packets are not 1172 admitted to the network, and MPLS headers are stripped before 1173 packets are forwarded from the network. This is particularly 1174 pertinent in the SFC context because [RFC7665] notes that "The 1175 architecture described herein is assumed to be applicable to a 1176 single network administrative domain." Furthermore, [RFC8300] 1177 states that packets originating outside the SFC-enabled domain 1178 MUST be dropped if they contain an NSH and packets exiting the 1179 SFC-enabled domain MUST be dropped if they contain an NSH. These 1180 constraints apply equally to the use of MPLS to encode a logical 1181 representation of the NSH. 1183 o The underlying transport mechanisms (such as Ethernet) between 1184 adjacent MPLS nodes may offer security mechanisms that can be used 1185 to defend packets "on the wire". 1187 o The SFC-capable devices participating in an SFC system are 1188 responsible for verifying and protecting payload packets and their 1189 contents as well as providing other security capabilities that 1190 might be required in the particular system. 1192 Additionally, where a tunnel is used to link two non-MPLS domains, 1193 the tunnel design needs to specify how the tunnel is secured. 1195 Thus, this design relies on the component underlying technologies to 1196 address the potential security vulnerabilities, and documents the 1197 necessary protections (or risk of their absence) above. It does not 1198 include any native security mechanisms in-band with the MPLS encoding 1199 of the NSH functionality. 1201 Note that configuration elements of this system (such as the 1202 programming of the table of metadata, see Section 12) must also be 1203 adequately secured although such mechanisms are not in scope for this 1204 protocol specification. 1206 No known new security vulnerabilities over the SFC architecture 1207 [RFC7665] and the NSH specification [RFC8300] are introduced by this 1208 design, but if issues are discovered in the future it is expected 1209 that they will be addressed through modifications to control/ 1210 management components of any solution, or through changes to the 1211 underlying technology. 1213 16. IANA Considerations 1215 This document requests IANA to make allocations from the "Extended 1216 Special-Purpose MPLS Label Values" subregistry of the "Special- 1217 Purpose Multiprotocol Label Switching (MPLS) Label Values" registry 1218 as follows: 1220 Value | Description | 1221 -------+-----------------------------------+-------------- 1222 TBD1 | Metadata Label Indicator (MLI) | [This.I-D] 1223 TBD2 | Metadata Present Indicator (MPI) | [This.I-D] 1225 17. Acknowledgements 1227 This document derives ideas and text from 1228 [I-D.ietf-bess-nsh-bgp-control-plane]. 1230 The authors are grateful to all those who contributed to the 1231 discussions that led to this work: Loa Andersson, Andrew G. Malis, 1232 Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart 1233 Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided 1234 helpful review comments. 1236 Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, 1237 and Mach Chen for reviews of this text. Thanks to Russ Mundy for his 1238 Security Directorate review and to S Moonesamy for useful 1239 discussions. Thanks also to Benjamin Kaduk, Alissa Cooper, Eric 1240 Rescorla, Mirja Kuehlewind, Alvaro Retana, and Martin Vigoureux for 1241 comprehensive reviews during IESG evaluation. 1243 The authors would like to be able to thank the authors of 1244 [I-D.xuclad-spring-sr-service-programming] and [RFC8402] whose 1245 original work on service chaining and the identification of services 1246 using SIDs, and conversation with whom helped clarify the application 1247 of MPLS-SR to SFC. 1249 Particular thanks to Loa Andersson for conversations and advice about 1250 working group process. 1252 18. Contributors 1254 The following people contributed text to this document: 1256 Andrew Malis 1257 Email: agmalis@gmail.com 1259 19. References 1261 19.1. Normative References 1263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1264 Requirement Levels", BCP 14, RFC 2119, 1265 DOI 10.17487/RFC2119, March 1997, 1266 . 1268 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1269 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1270 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1271 . 1273 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 1274 and Retiring Special-Purpose MPLS Labels", RFC 7274, 1275 DOI 10.17487/RFC7274, June 2014, 1276 . 1278 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1279 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1280 May 2017, . 1282 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1283 "Network Service Header (NSH)", RFC 8300, 1284 DOI 10.17487/RFC8300, January 2018, 1285 . 1287 [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service 1288 Header (NSH) with Next Protocol "None"", RFC 8393, 1289 DOI 10.17487/RFC8393, May 2018, 1290 . 1292 19.2. Informative References 1294 [I-D.ietf-bess-nsh-bgp-control-plane] 1295 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 1296 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 1297 nsh-bgp-control-plane-09 (work in progress), March 2019. 1299 [I-D.ietf-mpls-opportunistic-encrypt] 1300 Farrel, A. and S. Farrell, "Opportunistic Security in MPLS 1301 Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work 1302 in progress), March 2017. 1304 [I-D.xuclad-spring-sr-service-programming] 1305 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1306 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1307 Henderickx, W., and S. Salsano, "Service Programming with 1308 Segment Routing", draft-xuclad-spring-sr-service- 1309 programming-01 (work in progress), October 2018. 1311 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1312 Label Switching Architecture", RFC 3031, 1313 DOI 10.17487/RFC3031, January 2001, 1314 . 1316 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1317 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1318 2006, . 1320 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1321 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1322 . 1324 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1325 Chaining (SFC) Architecture", RFC 7665, 1326 DOI 10.17487/RFC7665, October 2015, 1327 . 1329 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1330 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1331 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1332 July 2018, . 1334 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1335 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1336 DOI 10.17487/RFC8459, September 2018, 1337 . 1339 Authors' Addresses 1341 Adrian Farrel 1342 Old Dog Consulting 1344 Email: adrian@olddog.co.uk 1346 Stewart Bryant 1347 Huawei 1349 Email: stewart.bryant@gmail.com 1351 John Drake 1352 Juniper Networks 1354 Email: jdrake@juniper.net