idnits 2.17.1 draft-farrel-mpls-sfc-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 (March 22, 2018) is 2226 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-03 Summary: 0 errors (**), 0 flaws (~~), 2 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 Juniper Networks 4 Intended status: Standards Track S. Bryant 5 Expires: September 23, 2018 Huawei 6 J. Drake 7 Juniper Networks 8 March 22, 2018 10 An MPLS-Based Forwarding Plane for Service Function Chaining 11 draft-farrel-mpls-sfc-05 13 Abstract 15 Service Function Chaining (SFC) is the process of directing packets 16 through a network so that they can be acted on by an ordered set of 17 abstract service functions before being delivered to the intended 18 destination. An architecture for SFC is defined in RFC7665. 20 The Network Service Header (NSH) can be inserted into packets to 21 steer them along a specific path to realize a Service Function Chain. 23 Multiprotocol Label Switching (MPLS) is a widely deployed forwarding 24 technology that uses labels placed in a packet in a label stack to 25 identify the forwarding actions to be taken at each hop through a 26 network. Actions may include swapping or popping the labels as well, 27 as using the labels to determine the next hop for forwarding the 28 packet. Labels may also be used to establish the context under which 29 the packet is forwarded. 31 This document describes how Service Function Chaining can be achieved 32 in an MPLS network by means of a logical representation of the NSH in 33 an MPLS label stack. It does not deprecate or replace the NSH, but 34 acknowledges that there may be a need for an interim deployment of 35 SFC functionality in brownfield networks. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 23, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 73 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 74 4. Basic Unit of Representation . . . . . . . . . . . . . . . . 4 75 5. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 6 76 6. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 8 77 7. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 10 78 8. A Note on Service Function Capabilities and SFC Proxies . . . 11 79 9. Control Plane Considerations . . . . . . . . . . . . . . . . 11 80 10. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 12 81 11. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 11.1. Indicating Metadata in User Data Packets . . . . . . . . 13 83 11.2. Inband Programming of Metadata . . . . . . . . . . . . . 15 84 12. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 18 85 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 16.2. Informative References . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 Service Function Chaining (SFC) is the process of directing packets 96 through a network so that they can be acted on by an ordered set of 97 abstract service functions before being delivered to the intended 98 destination. An architecture for SFC is defined in [RFC7665]. 100 When applying a particular Service Function Chain to the traffic 101 selected by a service classifier, the traffic needs to be steered 102 through an ordered set of Service Functions (SFs) in the network. 103 This ordered set of SFs is termed a Service Function Path (SFP), and 104 the traffic is passed between Service Function Forwarders (SFFs) that 105 are responsible for delivering the packets to the SFs and for 106 forwarding them onward to the next SFF. 108 In order to steer the selected traffic between SFFs and to the 109 correct SFs the service classifier needs to attach information to 110 each packet. This information indicates the SFP on which the packet 111 is being forwarded and hence the SFs to which it must be delivered. 112 The information also indicates the progress the packet has already 113 made along the SFP. 115 The Network Service Header (NSH) [RFC8300] has been defined to carry 116 the necessary information for Service Function Chaining in packets. 117 The NSH can be inserted into packets and contains various information 118 including a Service Path Indicator (SPI), a Service Index (SI), and a 119 Time To Live (TTL) counter. 121 Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed 122 forwarding technology that uses labels placed in a packet in a label 123 stack to identify the forwarding actions to be taken at each hop 124 through a network. Actions may include swapping or popping the 125 labels as well, as using the labels to determine the next hop for 126 forwarding the packet. Labels may also be used to establish the 127 context under which the packet is forwarded. In many cases, MPLS 128 will be used as a tunneling technology to carry packets through 129 networks between SFFs. 131 This document describes how Service Function Chaining can be achieved 132 in an MPLS network by means of a logical representation of the NSH in 133 an MPLS label stack. This approach is applicable to all forms of 134 MPLS forwarding (where labels are looked up at each hop, and swapped 135 or popped [RFC3031]). It does not deprecate or replace the NSH, but 136 acknowledges that there may be a need for an interim deployment of 137 SFC functionality in brownfield networks. The mechanisms described 138 in this document are a compromise between the full function that can 139 be achieved using the NSH, and the benefits of reusing the existing 140 MPLS forwarding paradigms. 142 It is assumed that the reader is fully familiar with the terms and 143 concepts introduced in [RFC7665] and [RFC8300]. 145 Note that one of the features of the SFC architecture described in 146 [RFC7665] is the "SFC proxy" that exists to include legacy SFs that 147 are not able to process NSH-encapsulated packets. This issue is 148 equally applicable to the use of MPLS-encapsulated packets that 149 encode a logical representation of an NSH. It is discussed further 150 in Section 8. 152 2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. Choice of Data Plane SPI/SI Representation 162 While [RFC8300] defines the NSH that can be used in a number of 163 environments, this document provides a mechanism to handle situations 164 in which the NSH is not ubiquitously deployed. In this case it is 165 possible to use an alternative data plane representation of the SPI/ 166 SI by carrying the identical semantics in MPLS labels. 168 In order to correctly select the mechanism by which SFC information 169 is encoded and carried between SFFs, it may be necessary to configure 170 the capabilities and choices either within the whole Service Function 171 Overlay Network, or on a hop by hop basis. It is a requirement that 172 both ends of a tunnel over the underlay network (i.e., a pair of SFFs 173 adjacent in the SFC) know that the tunnel is used for SFC and know 174 what form of NSH representation is used. A control plane signalling 175 approach to achieve these objectives is provided using BGP in 176 [I-D.ietf-bess-nsh-bgp-control-plane]. 178 Note that the encoding of the SFC information is independent of the 179 choice of tunneling technology used between SFFs. Thus, an MPLS 180 representation of the logical NSH (as defined in this document) may 181 be used even if the tunnel between a pair of SFFs is not an MPLS 182 tunnel. Conversely, MPLS tunnels may be used to carry other 183 encodings of the logical NSH (specifically, the NSH itself). 185 4. Basic Unit of Representation 187 When an MPLS label stack is used to carry a logical NSH, a basic unit 188 of representation is used. This unit comprises two MPLS labels as 189 shown below. The unit may be present one or more times in the label 190 stack as explained in subsequent sections. 192 In order to convey the same information as is present in the NSH, two 193 MPLS label stack entries are used. One carries a label to provide 194 context within the SFC scope (the SFC Context Label), and the other 195 carries a label to show which service function is to be actioned (the 196 SF Label). This two-label unit is shown in Figure 1. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | SFC Context Label | TC |S| TTL | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | SF Label | TC |S| TTL | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 1: The Basic Unit of MPLS Label Stack for SFC 208 The fields of these two label stack entries are encoded as follows: 210 Label: The Label fields contain the values of the SFC Context Label 211 and the SF Label encoded as 20 bit integers. The precise 212 semantics of these label fields are dependent on whether the label 213 stack entries are used for MPLS label swapping (see Section 5) or 214 MPLS label stacking (see Section 6). 216 TC: The TC bits have no meaning. They SHOULD be set to zero in both 217 label stack entries when a packet is sent and MUST be ignored on 218 receipt. 220 S: The bottom of stack bit has its usual meaning in MPLS. It MUST be 221 clear in the SFC Context label stack entry and MAY be set in the 222 SF label stack entry depending on whether the label is the bottom 223 of stack. 225 TTL: The TTL field in the SFC Context label stack entry SHOULD be 226 set to 1. The TTL in SF label stack entry (called the SF TTL) is 227 set according to its use for MPLS label swapping (see Section 5) 228 or MPLS label stacking (see Section 6 and is used to mitigate 229 packet loops. 231 The sections that follow show how this basic unit of MPLS label stack 232 may be used for SFC in the MPLS label swapping case and in the MPLS 233 label stacking. For simplicity, these sections do not describe the 234 use of metadata: that is covered separately in Section 11. 236 5. MPLS Label Swapping 238 This section describes how the basic unit of MPLS label stack for SFC 239 introduced in Section 4 is used when MPLS label swapping is in use. 240 As can be seen from Figure 2, the top of the label stack comprises 241 the labels necessary to deliver the packet over the MPLS tunnel 242 between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS 243 in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel 244 technology does not need to be MPLS, but that is shown here for 245 simplicity. 247 An entropy label ([RFC6790]) may also be present as described in 248 Section 10 250 Under these labels (or other encapsulation) comes a single instance 251 of the basic unit of MPLS label stack for SFC. In addition to the 252 interpretation of the fields of these label stack entries provided in 253 Section 4 the following meanings are applied: 255 SPI Label: The Label field of the SFC Context label stack entry 256 contains the value of the SPI encoded as a 20 bit integer. The 257 semantics of the SPI is exactly as defined in [RFC8300]. Note 258 that an SPI as defined by [RFC8300] can be encoded in 3 octets 259 (i.e., 24 bits), but that the Label field allows for only 20 bits 260 and reserves the values 0 though 15 as 'special purpose' labels 261 [RFC7274]. Thus, a system using MPLS representation of the 262 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 263 less than 16. 265 SI Label: The Label field of the SF label stack entry contains the 266 value of the SI exactly as defined in [RFC8300]. Since the SI 267 requires only 8 bits, and to avoid overlap with the 'special 268 purpose' label range of 0 through 15 [RFC7274], the SI is carried 269 in the top (most significant) 8 bits of the Label field with the 270 low order 12 bits set to zero. 272 TC: The TC fields are as described in Section 4. 274 S: The S bits are as described in Section 4. 276 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 277 as stated in Section 4. The TTL in SF label stack entry is 278 decremented once for each forwarding hop in the SFP, i.e., for 279 each SFF transited, and so mirrors the TTL field in the NSH. 281 --------------- 282 ~ Tunnel Labels ~ 283 +---------------+ 284 ~ Optional ~ 285 ~ Entropy Label ~ 286 +---------------+ - - - 287 | SPI Label | 288 +---------------+ Basic unit of MPLS label stack for SFC 289 | SI Label | 290 +---------------+ - - - 291 | | 292 ~ Payload ~ 293 | | 294 --------------- 296 Figure 2: The MPLS SFC Label Stack 298 The following processing rules apply to the Label fields: 300 o When a Classifier inserts a packet onto an SFP it sets the SPI 301 Label to indicate the identity of the SFP, and sets the SI Label 302 to indicate the first SF in the path. 304 o When a component of the SFC system processes a packet it uses the 305 SPI Label to identify the SFP and the SI Label to determine to 306 which SFF or instance of an SF (an SFI) to deliver the packet. 307 Under normal circumstances (with the exception of branching and 308 reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the 309 SPI Label value is preserved on all packets. The SI Label value 310 is modified by SFFs and through reclassification to indicate the 311 next hop along the SFP. 313 The following processing rules apply to the TTL field of the SF label 314 stack entry, and are derived from section 2.2 of [RFC8300]: 316 o When a Classifier places a packet onto an SFP it MUST set the TTL 317 to a value between 1 and 255. It SHOULD set this according to the 318 expected length of the SFP (i.e., the number of SFs on the SFP), 319 but it MAY set it to a larger value according to local 320 configuration. The maximum TTL value supported in an NSH is 63, 321 and so the practical limit here may also be 63. 323 o When an SFF receives a packet from any component of the SFC system 324 (Classifier, SFI, or another SFF) it MUST discard any packets with 325 TTL set to zero. It SHOULD log such occurrences, but MUST apply 326 rate limiting to any such logs. 328 o An SFF MUST decrement the TTL by one each time it performs a 329 forwarding lookup. 331 o If an SFF decrements the TTL to zero it MUST NOT send the packet, 332 and MUST discard the packet. It SHOULD log such occurrences, but 333 MUST apply rate limiting to any such logs. 335 o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF 336 unmodified along with the SI (which may have been changed by local 337 reclassification). 339 o If a Classifier along the SFP makes any change to the intended 340 path of the packet including for looping, jumping, or branching 341 (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the 342 SI TTL of the packet. In particular, each component of the SFC 343 system MUST NOT increase the SI TTL value otherwise loops may go 344 undetected. 346 6. MPLS Label Stacking 348 This section describes how the basic unit of MPLS label stack for SFC 349 introduced in Section 4 is used when MPLS label stacking is used to 350 carry information about the SFP and SFs to be executed. As can be 351 seen in Figure 3, the top of the label stack comprises the labels 352 necessary to deliver the packet over the MPLS tunnel between SFFs. 353 Any MPLS encapsulation may be used. 355 An entropy label ([RFC6790]) may also be present as described in 356 Section 10 358 Under these labels comes one of more instances of the basic unit of 359 MPLS label stack for SFC. In addition to the interpretation of the 360 fields of these label stack entries provided in Section 4 the 361 following meanings are applied: 363 SFC Context Label: The Label field of the SFC Context label stack 364 entry contains a label that delivers SFC context. This label may 365 be used to indicate the SPI encoded as a 20 bit integer using the 366 semantics of the SPI is exactly as defined in [RFC8300] and noting 367 that in this case a system using MPLS representation of the 368 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 369 less than 16. This label may also be used to convey other SFC 370 context-speific semantics such as indicating how to interpret the 371 SF Label or how to forward the packet to the node that offers the 372 SF. 374 SF Label: The Label field of the SF label stack entry contains a 375 value that identifies the next SFI to be actioned for the packet. 377 This label may be scoped globally or within the context of the 378 preceding SFC Context Label and comes from the range 16 ... 2^20 - 379 1. 381 TC: The TC fields are as described in Section 4. 383 S: The S bits are as described in Section 4. 385 TTL: The TTL fields in the SFC Context label stack entry SF label 386 stack entry SHOULD be set to 1 as stated in Section 4, but MAY be 387 set to larger values if the label indicated a forwarding operation 388 towards the node that hosts the SF. 390 ------------------- 391 ~ Tunnel Labels ~ 392 +-------------------+ 393 ~ Optional ~ 394 ~ Entropy Label ~ 395 +-------------------+ - - - 396 | SFC Context Label | 397 +-------------------+ Basic unit of MPLS label stack for SFC 398 | SF Label | 399 +-------------------+ - - - 400 | SFC Context Label | 401 +-------------------+ Basic unit of MPLS label stack for SFC 402 | SF Label | 403 +-------------------+ - - - 404 ~ ~ 405 +-------------------+ - - - 406 | SFC Context Label | 407 +-------------------+ Basic unit of MPLS label stack for SFC 408 | SF Label | 409 +-------------------+ - - - 410 | | 411 ~ Payload ~ 412 | | 413 ------------------- 415 Figure 3: The MPLS SFC Label Stack for Label Stacking 417 The following processing rules apply to the Label fields: 419 o When a Classifier inserts a packet onto an SFP it adds a stack 420 comprising one or more instances of the basic unit of MPLS label 421 stack for SFC. Taken together, this stack defines the SFs to be 422 actioned and so defines the SFP that the packet will traverse. 424 o When a component of the SFC system processes a packet it uses the 425 top basic unit of label stack for SFC to determine to which SFI to 426 next deliver the packet. When an SFF receives a packet it 427 examines the top basic unit of MPLS label stack for SFC to 428 determine where to send the packet next. If the next recipient is 429 a local SFI, the SFC strips the basic unit of MPLS label stack for 430 SFC before forwarding the packet. 432 7. Mixed Mode Forwarding 434 The previous sections describe homogeneous networks where SFC 435 forwarding is either all label swapping or all label popping 436 (stacking). But it is also possible that different parts of the 437 network utilize swapping or popping. It is also worth noting that a 438 Classifier may be content to use an SFP as installed in the network 439 by a control plane or management plane and so would use label 440 swapping, but that there may be a point in the SFP where a choice of 441 SFIs can be made (perhaps for load balancing) and where, in this 442 instance, the Classifier wishes to exert control over that choice by 443 use of a specific entry on the label stack. 445 When an SFF receives a packet containing an MPLS label stack, it 446 checks whether it is processing an {SFP, SI} label pair for label 447 swapping or a {context label, SFI index} label pair for label 448 stacking. It then selects the appropriate SFI to which to send the 449 packet. When it receives the packet back from the SFI, it has four 450 cases to consider. 452 o If the current hop requires an {SFP, SI} and the next hop requires 453 an {SFP, SI}, it sets the SI label to the SI value of the current 454 hop, selects an instance of the SF to be executed at the next hop, 455 and tunnels the packet to the SFF for that SFI. 457 o If the current hop requires an {SFP, SI} and the next hop requires 458 a {context label, SFI label}, it pops the {SFP, SI} from the top 459 of the MPLS label stack and tunnels the packet to the SFF 460 indicated by the context label. 462 o If the current hop requires a {context label, SFI label}, it pops 463 the {context label, SFI label} from the top of the MPLS label 464 stack. 466 * If the new top of the MPLS label stack contains an {SFP, SI} 467 label pair, it selects an SFI to use at the next hop, and 468 tunnels the packet to SFF for that SFI. 470 * If the top of the MPLS label stack contains a {context label, 471 SFI label}, it tunnels the packet to the SFF indicated by the 472 context label. 474 8. A Note on Service Function Capabilities and SFC Proxies 476 The concept of an "SFC Proxy" is introduced in [RFC7665]. An SFC 477 Proxy is logically located between an SFF and an SFI that is not 478 "SFC-aware". Such SFIs are not capable of handling the SFC 479 encapsulation (whether that be NSH or MPLS) and need the 480 encapsulation stripped from the packets they are to process. In many 481 cases, legacy SFIs that were once deployed as "bumps in the wire" fit 482 into this category until they have been upgraded to be SFC-aware. 484 The job of an SFC Proxy is to remove and then reimpose SFC 485 encapsulation so that the SFF is able to process as though it was 486 communication with an SFC-aware SFI, and so that the SFI is unaware 487 of the SFC encapsulation. In this regard, the job of an SFC Proxy is 488 no different when NSH encapsulation is used and when MPLS 489 encapsulation is used as described in this document, although (of 490 course) it is different encapsulation bytes that must be removed and 491 reimposed. 493 It should be noted that the SFC Proxy is a logical function. It 494 could be implemented as a separate physical component on the path 495 from the SFF to SFI, but it could be coresident with the SFF or it 496 could be a component of the SFI. This is purely an implementation 497 choice. 499 Note also that the delivery of metadata (see Section 11) requires 500 specific processing if an SFC Proxy is in use. This is also no 501 different when NSH or the MPLS encoding defined in this document is 502 in use, and how it is handled will depend on how (or if) each non- 503 SFC-aware SFI can receive metadata. 505 9. Control Plane Considerations 507 In order that a packet may be forwarded along an SFP several 508 functional elements must be executed. 510 o Discovery/advertisement of SFIs. 512 o Computation of SFP. 514 o Programming of Classifiers. 516 o Advertisement of forwarding instructions. 518 Various approaches may be taken. These include a fully centralized 519 model where SFFs report to a central controller the SFIs that they 520 support, the central controller computes the SFP and programs the 521 Classifiers, and (if the label swapping approach is taken) the 522 central controller installs forwarding state in the SFFs that lie on 523 the SFP. 525 Alternatively, a dynamic control plane may be used such as that 526 described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the 527 SFFs use the control plane to advertise the SFIs that they support, a 528 central controller computes the SFP and programs the Classifiers, and 529 (if the label swapping approach is taken) the central controller uses 530 the control plane to advertise the SFPs so that SFFs that lie on the 531 SFP can install the necessary forwarding state. 533 10. Use of the Entropy Label 535 Entropy is used in ECMP situations to ensure that packets from the 536 same flow travel down the same path, thus avoiding jitter or re- 537 ordering issues within a flow. 539 Entropy is often determined by hashing on specific fields in a packet 540 header such as the "five-tuple" in the IP and transport headers. 541 However, when an MPLS label stack is present, the depth of the stack 542 could be too large for some processors to correctly determine the 543 entropy hash. This problem is addressed by the inclusion of an 544 Entropy Label as described in [RFC6790]. 546 When entropy is desired for packets as they are carried in MPLS 547 tunnels over the underlay network, it is RECOMMENDED that an Entropy 548 Label is included in the label stack immediately after the tunnel 549 labels and before the SFC labels as shown in Figure 2 and Figure 3. 551 If an Entropy Label is present in an MPLS payload, it is RECOMMENDED 552 that the initial Classifier use that value in an Entropy Label 553 inserted in the label stack when the packet is forwarded (on the 554 first tunnel) to the first SFF. In this case it is not necessary to 555 remove the Entropy Label from the payload. 557 11. Metadata 559 Metadata is defined in [RFC7665] as providing "the ability to 560 exchange context information between classifiers and SFs, and among 561 SFs." [RFC8300] defines how this context information can be directly 562 encoded in fields that form part of the NSH encapsulation. 564 The next two sections describe how metadata is associated with user 565 data packets, and how metadata may be exchanged between SFC nodes in 566 the network, when using an MPLS encoding of the logical 567 representation of the NSH. 569 It should be noted that the MPLS encoding is slightly less functional 570 than the direct use of the NSH. Both methods support metadata that 571 is "per-SFP" or "per-packet-flow" (see [I-D.farrel-sfc-convent] for 572 definitions of these terms), but "per-packet" metadata (where the 573 metadata must be carried on each packet because it differs from one 574 packet to the next even on the same flow or SFP) is only supported 575 using the NSH and not using the mechanisms defined in this document. 577 11.1. Indicating Metadata in User Data Packets 579 Metadata is achieved in the MPLS realization of the logical NSH by 580 the use of an SFC Metadata Label which uses the Extended Special 581 Purpose Label construct [RFC7274]. Thus, three label stack entries 582 are present as shown in Figure 4: 584 o The Extension Label (value 15) 586 o An extended special purpose label called the Metadata Label 587 Indicator (MLI) (value TBD1 by IANA) 589 o The Metadata Label (ML). 591 ---------------- 592 | Extension = 15 | 593 +----------------+ 594 | MLI | 595 +----------------+ 596 | Metadata Label | 597 --------------- 599 Figure 4: The MPLS SFC Metadata Label 601 The Metadata Label value is an index into a table of metadata that is 602 programmed into the network using in-band or out-of-band mechanisms. 603 Out-of-band mechanisms potentially include management plane and 604 control plane solutions (such as 605 [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this 606 document. The in-band mechanism is described in Section 11.2 608 The SFC Metadata Label (as a set of three labels as indicated in 609 Figure 4) may be present zero, one, or more times in an MPLS SFC 610 packet. For MPLS label swapping, the SFC Metadata Labels are placed 611 immediately after the basic unit of MPLS label stack for SFC as shown 612 in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be 613 present zero, one, or more times and are placed at the bottom of the 614 label stack as shown in Figure 6. 616 ---------------- 617 ~ Tunnel Labels ~ 618 +----------------+ 619 ~ Optional ~ 620 ~ Entropy Label ~ 621 +----------------+ 622 | SPI Label | 623 +----------------+ 624 | SI Label | 625 +----------------+ 626 | Extension = 15 | 627 +----------------+ 628 | MLI | 629 +----------------+ 630 | Metadata Label | 631 +----------------+ 632 ~ Other ~ 633 | Metadata | 634 ~ Label Triples ~ 635 +----------------+ 636 | | 637 ~ Payload ~ 638 | | 639 ---------------- 641 Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata 642 Label 644 ------------------- 645 ~ Tunnel Labels ~ 646 +-------------------+ 647 ~ Optional ~ 648 ~ Entropy Label ~ 649 +-------------------+ 650 | SFC Context Label | 651 +-------------------+ 652 | SF Label | 653 +-------------------+ 654 ~ ~ 655 +-------------------+ 656 | SFC Context Label | 657 +-------------------+ 658 | SF Label | 659 +-------------------+ 660 | Extension = 15 | 661 +-------------------+ 662 | MLI | 663 +-------------------+ 664 | Metadata Label | 665 +-------------------+ 666 ~ Other ~ 667 | Metadata | 668 ~ Label Triples ~ 669 +-------------------+ 670 | | 671 ~ Payload ~ 672 | | 673 ------------------- 675 Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata 676 Label 678 11.2. Inband Programming of Metadata 680 A mechanism for sending metadata associated with an SFP without a 681 payload packet is described in [I-D.farrel-sfc-convent]. The same 682 approach can be used in an MPLS network where the NSH is logically 683 represented by an MPLS label stack. 685 The packet header is formed exactly as previously described in this 686 document so that the packet will follow the SFP through the SFC 687 network. However, instead of payload data, metadata is included 688 after the bottom of the MPLS label stack. An Extended Special 689 Purpose Label is used to indicate that the metadata is present. 690 Thus, three label stack entries are present: 692 o The Extension Label (value 15) 694 o An extended special purpose label called the Metadata Present 695 Indicator (MPI) (value TBD2 by IANA) 697 o The Metadata Label (ML) that is associated with this metadata on 698 this SFP and can be used to indicate the use of the metadata as 699 described in Section 11. 701 The SFC Metadata Present Label, if present, is placed immediately 702 after the last basic unit of MPLS label stack for SFC. The resultant 703 label stacks are shown in Figure 7 for the MPLS label swapping case 704 and Figure 8 for the MPLS label stacking case. 706 --------------- 707 ~ Tunnel Labels ~ 708 +---------------+ 709 ~ Optional ~ 710 ~ Entropy Label ~ 711 +---------------+ 712 | SPI Label | 713 +---------------+ 714 | SI Label | 715 +---------------+ 716 | Extension = 15| 717 +---------------+ 718 | MPI | 719 +---------------+ 720 | Metadata Label| 721 +---------------+ 722 | | 723 ~ Metadata ~ 724 | | 725 --------------- 727 Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying 728 Metadata 730 ------------------- 731 ~ Tunnel Labels ~ 732 +-------------------+ 733 ~ Optional ~ 734 ~ Entropy Label ~ 735 +-------------------+ 736 | SFC Context Label | 737 +-------------------+ 738 | SF Label | 739 +-------------------+ 740 | SFC Context Label | 741 +-------------------+ 742 | SF Label | 743 +-------------------+ 744 ~ ~ 745 +-------------------+ 746 | SFC Context Label | 747 +-------------------+ 748 | SF Label | 749 +-------------------+ 750 | Extension = 15 | 751 +-------------------+ 752 | MPI | 753 +-------------------+ 754 | Metadata Label | 755 +-------------------+ 756 | | 757 ~ Metadata ~ 758 | | 759 ------------------- 761 Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying 762 Metadata 764 In both cases the metadata is formatted as a TLV as shown in 765 Figure 9. 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Length | Metadata Type | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 ~ Metadata ~ 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Figure 9: The Metadata TLV 777 The fields of this TLV are interpreted as follows: 779 Length: The length of the metadata carried in the Metadata field in 780 octets not including any padding. 782 Metadata Type: The type of the metadata present. Values for this 783 field are taken from the "MD Types" registry maintained by IANA 784 and defined in [RFC8300]. 786 Metadata: The actual metadata formatted as described in whatever 787 document defines the metadata. This field is end-padded with zero 788 to three octets of zeroes to take it up to a four octet boundary. 790 12. Worked Examples 792 Consider the simplistic MPLS SFC overlay network shown in Figure 10. 793 A packet is classified for an SFP that will see it pass through two 794 Service Functions, SFa and SFb, that are accessed through Service 795 Function Forwarders SFFa and SFFb respectively. The packet is 796 ultimately delivered to destination, D. 798 Let us assume that the SFP is computed and assigned the SPI of 239. 799 The forwarding details of the SFP are distributed (perhaps using the 800 mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs 801 are programmed with the necessary forwarding instructions. 803 The packet progresses as follows: 805 a. The Classifier assigns the packet to the SFP and imposes two 806 label stack entries comprising a single basic unit of MPLS SFC 807 representation: 809 * The higher label stack entry contains a label carrying the SPI 810 value of 239. 812 * The lower label stack entry contains a label carrying the SI 813 value of 255. 815 Further labels may be imposed to tunnel the packet from the 816 Classifier to SFFa. 818 b. When the packet arrives at SFFa it strips any labels associated 819 with the tunnel that runs from the Classifier to SFFa. SFFa 820 examines the top labels and matches the SPI/SI to identify that 821 the packet should be forwarded to SFa. The packet is forwarded 822 to SFa unmodified. 824 c. SFa performs its designated function and returns the packet to 825 SFFa. 827 d. SFFa modifies the SI in the lower label stack entry (to 254) and 828 uses the SPI/SI to look up the forwarding instructions. It sends 829 the packet with two label stack entries: 831 * The higher label stack entry contains a label carrying the SPI 832 value of 239. 834 * The lower label stack entry contains a label carrying the SI 835 value of 254. 837 Further labels may be imposed to tunnel the packet from the SFFa 838 to SFFb. 840 e. When the packet arrives at SFFb it strips any labels associated 841 with the tunnel from SFFa. SFFb examines the top labels and 842 matches the SPI/SI to identify that the packet should be 843 forwarded to SFb. The packet is forwarded to SFb unmodified. 845 f. SFb performs its designated function and returns the packet to 846 SFFb. 848 g. SFFb modifies the SI in the lower label stack entry (to 253) and 849 uses the SPI/SI to lookup up the forwarding instructions. It 850 determines that it is the last SFF in the SFP so it strips the 851 two SFC label stack entries and forwards the payload toward D 852 using the payload protocol. 854 +---------------------------------------------------+ 855 | MPLS SFC Network | 856 | | 857 | +---------+ +---------+ | 858 | | SFa | | SFb | | 859 | +----+----+ +----+----+ | 860 | ^ | | ^ | | | 861 | (b)| | |(c) (e)| | |(f) | 862 | (a) | | V (d) | | V (g) | 863 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 864 |Classifier+------+ SFFa +-------+ SFFb +------+ D | 865 +----------+ +---------+ +---------+ +-------+ 866 | | 867 +---------------------------------------------------+ 869 Figure 10: Service Function Chaining in an MPLS Network 871 Alternatively, consider the MPLS SFC overlay network shown in 872 Figure 11. A packet is classified for an SFP that will see it pass 873 through two Service Functions, SFx and SFy, that are accessed through 874 Service Function Forwarders SFFx and SFFy respectively. The packet 875 is ultimately delivered to destination, D. 877 Let us assume that the SFP is computed and assigned the SPI of 239. 878 However, the forwarding state for the SFP is not distributed and 879 installed in the network. Instead it will be attached to the 880 individual packets using the MPLS label stack. 882 The packet progresses as follows: 884 1. The Classifier assigns the packet to the SFP and imposes two 885 basic units of MPLS SFC representation to describe the full SFP: 887 * The top basic unit comprises two label stack entries as 888 follows: 890 + The higher label stack entry contains a label carrying the 891 SFC context. 893 + The lower label stack entry contains a label carrying the 894 SF indicator for SFx. 896 * The lower basic unit comprises two label stack entries as 897 follows: 899 + The higher label stack entry contains a label carrying the 900 SFC context. 902 + The lower label stack entry contains a label carrying the 903 SF indicator for SFy. 905 Further labels may be imposed to tunnel the packet from the 906 Classifier to SFFx. 908 2. When the packet arrives at SFFx it strips any labels associated 909 with the tunnel from the Classifier. SFFx examines the top 910 labels and matches the context/SF values to identify that the 911 packet should be forwarded to SFx. The packet is forwarded to 912 SFx unmodified. 914 3. SFx performs its designated function and returns the packet to 915 SFFx. 917 4. SFFx strips the top basic unit of MPLS SFC representation 918 revealing the next basic unit. It then uses the revealed 919 context/SF values to determine how to route the packet to the 920 next SFF, SFFy. It sends the packet with just one basic unit of 921 MPLS SFC representation comprising two label stack entries: 923 * The higher label stack entry contains a label carrying the SFC 924 context. 926 * The lower label stack entry contains a label carrying the SF 927 indicator for SFy. 929 Further labels may be imposed to tunnel the packet from the SFFx 930 to SFFy. 932 5. When the packet arrives at SFFy it strips any labels associated 933 with the tunnel from SFFx. SFFy examines the top labels and 934 matches the context/SF values to identify that the packet should 935 be forwarded to SFy. The packet is forwarded to SFy unmodified. 937 6. SFy performs its designated function and returns the packet to 938 SFFy. 940 7. SFFy strips the top basic unit of MPLS SFC representation 941 revealing the payload packet. It forwards the payload toward D 942 using the payload protocol. 944 +---------------------------------------------------+ 945 | MPLS SFC Network | 946 | | 947 | +---------+ +---------+ | 948 | | SFx | | SFy | | 949 | +----+----+ +----+----+ | 950 | ^ | | ^ | | | 951 | (2)| | |(3) (5)| | |(6) | 952 | (1) | | V (4) | | V (7) | 953 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 954 |Classifier+------+ SFFx +-------+ SFFy +------+ D | 955 +----------+ +---------+ +---------+ +-------+ 956 | | 957 +---------------------------------------------------+ 959 Figure 11: Service Function Chaining Using MPLS Label Stacking 961 13. Security Considerations 963 Discussion of the security properties of SFC networks can be found in 964 [RFC7665]. Further security discussion for the NSH and its use is 965 present in [RFC8300]. 967 It is fundamental to the SFC design that the classifier is a trusted 968 resource which determines the processing that the packet will be 969 subject to, including for example the firewall. It is also 970 fundamental to the MPLS design that packets are routed through the 971 network using the path specified by the node imposing the labels, and 972 that labels are swapped or popped correctly. Where an SF is not 973 encapsulation aware the encapsulation may be stripped by an SFC proxy 974 such that packet may exist as a native packet (perhaps IP) on the 975 path between SFC proxy and SF, however this is an intrinsic part of 976 the SFC design which needs to define how a packet is protected in 977 that environment. 979 Additionally, where a tunnel is used to link two non-MPLS domains, 980 the tunnel design needs to specify how the tunnel is secured. 982 Thus the security vulnerabilities are addressed (or should be 983 addressed) in all the underlying technologies used by this design, 984 which itself does not introduce any new security vulnerabilities. 986 14. IANA Considerations 988 This document requests IANA to make allocations from the "Extended 989 Special-Purpose MPLS Label Values" subregistry of the "Special- 990 Purpose Multiprotocol Label Switching (MPLS) Label Values" registry 991 as follows: 993 Value | Description | 994 -------+-----------------------------------+-------------- 995 TBD1 | Metadata Label Indicator (MLI) | [This.I-D] 996 TBD2 | Metadata Present Indicator (MPI) | [This.I-D] 998 15. Acknowledgements 1000 This document derives ideas and text from 1001 [I-D.ietf-bess-nsh-bgp-control-plane]. 1003 The authors are grateful to all those who contributed to the 1004 discussions that led to this work: Loa Andersson, Andrew G. Malis, 1005 Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart 1006 Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided 1007 helpful review comments. 1009 Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, and Mach Chen 1010 for reviews of this text. 1012 16. References 1014 16.1. Normative References 1016 [I-D.farrel-sfc-convent] 1017 Farrel, A. and J. Drake, "Operating the Network Service 1018 Header (NSH) with Next Protocol "None"", draft-farrel-sfc- 1019 convent-06 (work in progress), February 2018. 1021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", BCP 14, RFC 2119, 1023 DOI 10.17487/RFC2119, March 1997, 1024 . 1026 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 1027 and Retiring Special-Purpose MPLS Labels", RFC 7274, 1028 DOI 10.17487/RFC7274, June 2014, 1029 . 1031 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1032 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1033 May 2017, . 1035 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1036 "Network Service Header (NSH)", RFC 8300, 1037 DOI 10.17487/RFC8300, January 2018, 1038 . 1040 16.2. Informative References 1042 [I-D.ietf-bess-nsh-bgp-control-plane] 1043 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 1044 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 1045 nsh-bgp-control-plane-03 (work in progress), March 2018. 1047 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1048 Label Switching Architecture", RFC 3031, 1049 DOI 10.17487/RFC3031, January 2001, 1050 . 1052 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1053 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1054 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1055 . 1057 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1058 Chaining (SFC) Architecture", RFC 7665, 1059 DOI 10.17487/RFC7665, October 2015, 1060 . 1062 Authors' Addresses 1064 Adrian Farrel 1065 Juniper Networks 1067 Email: afarrel@juniper.net 1069 Stewart Bryant 1070 Huawei 1072 Email: stewart.bryant@gmail.com 1074 John Drake 1075 Juniper Networks 1077 Email: jdrake@juniper.net