idnits 2.17.1 draft-farrel-mpls-sfc-03.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 (February 1, 2018) is 2276 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 (-22) exists of draft-ietf-spring-segment-routing-mpls-11 == Outdated reference: A later version (-06) exists of draft-farrel-sfc-convent-05 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-02 Summary: 0 errors (**), 0 flaws (~~), 4 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: August 5, 2018 Huawei 6 J. Drake 7 Juniper Networks 8 February 1, 2018 10 An MPLS-Based Forwarding Plane for Service Function Chaining 11 draft-farrel-mpls-sfc-03 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 to identify the forwarding actions to be 25 taken at each hop through a network. Segment Routing is a mechanism 26 that provides a source routing paradigm for steering packets in an 27 MPLS network. 29 This document describes how Service Function Chaining can be achieved 30 in an MPLS network by means of a logical representation of the NSH in 31 an MPLS label stack. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 5, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 69 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 70 4. Basic Unit of Representation . . . . . . . . . . . . . . . . 4 71 5. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 5 72 6. MPLS Segment Routing . . . . . . . . . . . . . . . . . . . . 8 73 7. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 10 74 8. Control Plane Considerations . . . . . . . . . . . . . . . . 11 75 9. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 11 76 10. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Indicating Metadata in User Data Packets . . . . . . . . 12 78 10.2. Inband Programming of Metadata . . . . . . . . . . . . . 14 79 11. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 17 80 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 83 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 85 15.2. Informative References . . . . . . . . . . . . . . . . . 22 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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. 99 This ordered set of SFs is termed a Service Function Path (SFP), and 100 the traffic is passed between Service Function Forwarders (SFFs) that 101 are responsible for delivering the packets to the SFs and for 102 forwarding them onward to the next SFF. 104 In order to steer the selected traffic between SFFs and to the 105 correct SFs the service classifier needs to attach information to 106 each packet. This information indicates the SFP on which the packet 107 is being forwarded and hence the SFs to which it must be delivered. 108 The information also indicates the progress the packet has already 109 made along the SFP. 111 The Network Service Header (NSH) [RFC8300] has been defined to carry 112 the necessary information for Service Function Chaining in packets. 113 The NSH can be inserted into packets and contains various information 114 including a Service Path Indicator (SPI), a Service Index (SI), and a 115 Time To Live (TTL) counter. 117 Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed 118 forwarding technology that uses labels to identify the forwarding 119 actions to be taken at each hop through a network. In many cases, 120 MPLS will be used as a tunneling technology to carry packets through 121 networks between SFFs. 123 Segment Routing [RFC7855] defines a source routing paradigm for use 124 in packet switched networks. The application of Segment Routing in 125 MPLS networks is described in [I-D.ietf-spring-segment-routing-mpls] 126 and is known as MPLS-SR. 128 This document describes how Service Function Chaining can be achieved 129 in an MPLS network by means of a logical representation of the NSH in 130 an MPLS label stack. This approach is applicable to both classical 131 MPLS forwarding (where labels are looked up at each hop, and swapped 132 for the next hop [RFC3031]) and MPLS Segment Routing (where labels 133 are looked up at each hop, and popped to reveal the next label to 134 action [I-D.ietf-spring-segment-routing-mpls]). The mechanisms 135 described in this document are a compromise between the full function 136 that can be achieved using the NSH, and the benefits of reusing the 137 existing MPLS forwarding paradigms. 139 It is assumed that the reader is fully familiar with the terms and 140 concepts introduced in [RFC7665] and [RFC8300]. 142 2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 3. Choice of Data Plane SPI/SI Representation 152 While [RFC8300] defines the NSH that can be used in a number of 153 environments, this document provides a mechanism to handle situations 154 in which the NSH is not ubiquitously deployed. In this case it is 155 possible to use an alternative data plane representation of the SPI/ 156 SI by carrying the identical semantics in MPLS labels. 158 In order to correctly select the mechanism by which SFC information 159 is encoded and carried between SFFs, it may be necessary to configure 160 the capabilities and choices either within the whole Service Function 161 Overlay Network, or on a hop by hop basis. It is a requirement that 162 both ends of a tunnel over the underlay network (i.e., a pair of SFFs 163 adjacent in the SFC) know that the tunnel is used for SFC and know 164 what form of NSH representation is used. A control plane signalling 165 approach to achieve these objectives is provided using BGP in 166 [I-D.ietf-bess-nsh-bgp-control-plane]. 168 Note that the encoding of the SFC information is independent of the 169 choice of tunneling technology used between SFFs. Thus, an MPLS 170 representation of the logical NSH (as defined in this document) may 171 be used even if the tunnel between a pair of SFFs is not an MPLS 172 tunnel. Conversely, MPLS tunnels may be used to carry other 173 encodings of the logical NSH (specifically, the NSH itself). 175 4. Basic Unit of Representation 177 When an MPLS label stack is used to carry a logical NSH, a basic unit 178 of representation is used. This unit comprises two MPLS labels as 179 shown below. The unit may be present one or more times in the label 180 stack as explained in subsequent sections. 182 In order to convey the same information as is present in the NSH, two 183 MPLS label stack entries are used. One carries a label to provide 184 context within the SFC scope (the SFC Context Label), and the other 185 carries a label to show which service function is to be actioned (the 186 SF Label). This two-label unit is shown in Figure 1. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | SFC Context Label | TC |S| TTL | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | SF Label | TC |S| TTL | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1: The Basic Unit of MPLS Label Stack for SFC 198 The fields of these two label stack entries are encoded as follows: 200 Label: The Label fields contain the values of the SFC Context Label 201 and the SF Label encoded as 20 bit integers. The precise 202 semantics of these label fields are dependent on whether the label 203 stack entries are used for MPLS swapping (see Section 5) or MPLS- 204 SR (see Section 6). 206 TC: The TC bits have no meaning. They SHOULD be set to zero in both 207 label stack entries when a packet is sent and MUST be ignored on 208 receipt. 210 S: The bottom of stack bit has its usual meaning in MPLS. It MUST be 211 clear in the SFC Context label stack entry and MAY be set in the 212 SF label stack entry depending on whether the label is the bottom 213 of stack. 215 TTL: The TTL field in the SFC Context label stack entry SHOULD be 216 set to 1. The TTL in SF label stack entry (called the SF TTL) is 217 set according to its use for MPLS swapping (see Section 5) or 218 MPLS-SR (see Section 6 and is used to mitigate packet loops. 220 The sections that follow show how this basic unit of MPLS label stack 221 may be used for SFC in the MPLS label swapping case and in the MPLS- 222 SR case. For simplicity, these sections do not describe the use of 223 metadata: that is covered separately in Section 10. 225 5. MPLS Label Swapping 227 This section describes how the basic unit of MPLS label stack for SFC 228 introduced in Section 4 is used when MPLS label swapping is in use. 229 As can be seen from Figure 2, the top of the label stack comprises 230 the labels necessary to deliver the packet over the MPLS tunnel 231 between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS 232 in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel 233 technology does not need to be MPLS, but that is shown here for 234 simplicity. 236 An entropy label ([RFC6790]) may also be present as described in 237 Section 9 239 Under these labels (or other encapsulation) comes a single instance 240 of the basic unit of MPLS label stack for SFC. In addition to the 241 interpretation of the fields of these label stack entries provided in 242 Section 4 the following meanings are applied: 244 SPI Label: The Label field of the SFC Context label stack entry 245 contains the value of the SPI encoded as a 20 bit integer. The 246 semantics of the SPI is exactly as defined in [RFC8300]. Note 247 that an SPI as defined by [RFC8300] can be encoded in 3 octets 248 (i.e., 24 bits), but that the Label field allows for only 20 bits 249 and reserves the values 0 though 15 as 'special purpose' labels 250 [RFC7274]. Thus, a system using MPLS representation of the 251 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 252 less than 16. 254 SI Label: The Label field of the SF label stack entry contains the 255 value of the SI exactly as defined in [RFC8300]. Since the SI 256 requires only 8 bits, and to avoid overlap with the 'special 257 purpose' label range of 0 through 15 [RFC7274], the SI is carried 258 in the top (most significant) 8 bits of the Label field with the 259 low order 12 bits set to zero. 261 TC: The TC fields are as described in Section 4. 263 S: The S bits are as described in Section 4. 265 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 266 as stated in Section 4. The TTL in SF label stack entry is 267 decremented once for each forwarding hop in the SFP, i.e., for 268 each SFF transited, and so mirrors the TTL field in the NSH. 270 --------------- 271 ~ Tunnel Labels ~ 272 +---------------+ 273 ~ Optional ~ 274 ~ Entropy Label ~ 275 +---------------+ - - - 276 | SPI Label | 277 +---------------+ Basic unit of MPLS label stack for SFC 278 | SI Label | 279 +---------------+ - - - 280 | | 281 ~ Payload ~ 282 | | 283 --------------- 285 Figure 2: The MPLS SFC Label Stack 287 The following processing rules apply to the Label fields: 289 o When a Classifier inserts a packet onto an SFP it sets the SPI 290 Label to indicate the identity of the SFP, and sets the SI Label 291 to indicate the first SF in the path. 293 o When a component of the SFC system processes a packet it uses the 294 SPI Label to identify the SFP and the SI Label to determine to 295 which SFF or SFI to deliver the packet. Under normal 296 circumstances (with the exception of branching and 297 reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the 298 SPI Label value is preserved on all packets. The SI Label value 299 is modified by SFFs and through reclassification to indicate the 300 next hop along the SFP. 302 The following processing rules apply to the TTL field of the SF label 303 stack entry, and are derived from section 2.2 of [RFC8300]: 305 o When a Classifier places a packet onto an SFP it MUST set the TTL 306 to a value between 1 and 255. It SHOULD set this according to the 307 expected length of the SFP (i.e., the number of SFs on the SFP), 308 but it MAY set it to a larger value according to local 309 configuration. The maximum TTL value supported in an NSH is 63, 310 and so the practical limit here may also be 63. 312 o When an SFF receives a packet from any component of the SFC system 313 (Classifier, SFI, or another SFF) it MUST discard any packets with 314 TTL set to zero. It SHOULD log such occurrences, but MUST apply 315 rate limiting to any such logs. 317 o An SFF MUST decrement the TTL by one each time it performs a 318 forwarding lookup. 320 o If an SFF decrements the TTL to zero it MUST NOT send the packet, 321 and MUST discard the packet. It SHOULD log such occurrences, but 322 MUST apply rate limiting to any such logs. 324 o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF 325 unmodified along with the SI (which may have been changed by local 326 reclassification). 328 o If a Classifier along the SFP makes any change to the intended 329 path of the packet including for looping, jumping, or branching 330 (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the 331 SI TTL of the packet. In particular, each component of the SFC 332 system MUST NOT increase the SI TTL value otherwise loops may go 333 undetected. 335 6. MPLS Segment Routing 337 This section describes how the basic unit of MPLS label stack for SFC 338 introduced in Section 4 is used when in an MPLS-SR network. As can 339 be seen Figure 3, the top of the label stack comprises the labels 340 necessary to deliver the packet over the MPLS tunnel between SFFs. 341 Any MPLS encapsulation may be used and the tunnel technology does not 342 need to be MPLS or MPLS-SR, but MPLS-SR is shown here for simplicity. 344 An entropy label ([RFC6790]) may also be present as described in 345 Section 9 347 Under these labels (or other encapsulation) comes one of more 348 instances of the basic unit of MPLS label stack for SFC. In addition 349 to the interpretation of the fields of these label stack entries 350 provided in Section 4 the following meanings are applied: 352 SFC Context Label: The Label field of the SFC Context label stack 353 entry contains a label that delivers SFC context. This label may 354 be used to indicate the SPI encoded as a 20 bit integer using the 355 semantics of the SPI is exactly as defined in [RFC8300] and noting 356 that in this case a system using MPLS representation of the 357 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 358 less than 16. This label may also be used to convey other SFC 359 context-speific semantics such as indicating, perhaps with a node 360 SID (see [I-D.ietf-spring-segment-routing]), how to interpret the 361 SF Label. 363 SF Label: The Label field of the SF label stack entry contains a 364 value that identifies the next SFI to be actioned for the packet. 366 This label may be scoped globally or within the context of the 367 preceding SFC Context Label and comes from the range 16 ... 2^20 - 368 1. 370 TC: The TC fields are as described in Section 4. 372 S: The S bits are as described in Section 4. 374 TTL: The TTL field in the SFC Context label stack entry SHOULD be 375 set to 1 as stated in Section 4. The TTL in SF label stack entry 376 is set according to the norms for MPLS-SR. 378 ------------------- 379 ~ MPLS-SR Labels ~ 380 +-------------------+ 381 ~ Optional ~ 382 ~ Entropy Label ~ 383 +-------------------+ - - - 384 | SFC Context Label | 385 +-------------------+ Basic unit of MPLS label stack for SFC 386 | SF Label | 387 +-------------------+ - - - 388 | SFC Context Label | 389 +-------------------+ Basic unit of MPLS label stack for SFC 390 | SF Label | 391 +-------------------+ - - - 392 ~ ~ 393 +-------------------+ - - - 394 | SFC Context Label | 395 +-------------------+ Basic unit of MPLS label stack for SFC 396 | SF Label | 397 +-------------------+ - - - 398 | | 399 ~ Payload ~ 400 | | 401 ------------------- 403 Figure 3: The MPLS SFC Label Stack for Segment Routing 405 The following processing rules apply to the Label fields: 407 o When a Classifier inserts a packet onto an SFP it adds a stack 408 comprising one or more instances of the basic unit of MPLS label 409 stack for SFC. Taken together, this stack defines the SFs to be 410 actioned and so defines the SFP that the packet will traverse. 412 o When a component of the SFC system processes a packet it uses the 413 top basic unit of label stack for SFC to determine to which SFI to 414 next deliver the packet. When an SFF receives a packet it 415 examines the top basic unit of MPLS label stack for SFC to 416 determine where to send the packet next. If the next recipient is 417 a local SFI, the SFC strips the basic unit of MPLS label stack for 418 SFC before forwarding the packet. 420 7. Mixed Mode Forwarding 422 The previous sections describe homogeneous networks where SFC 423 forwarding is either all label swapping or all label popping. But it 424 is also possible that different parts of the network utilize swapping 425 or popping for different purposes. 427 When an SFF receives a packet containing an MPLS label stack, it 428 checks whether it is processing an {SFP, SI} label pair for label 429 swapping or a {context label, SFI index} label pair for MPLS-SR. It 430 then selects the appropriate SFI to which to send the packet. When 431 it receives the packet back from the SFI, it has four cases to 432 consider. 434 o If the current hop requires an {SFP, SI} and the next hop requires 435 an {SFP, SI}, it sets the SI label to the SI value of the current 436 hop, selects an instance of the SF to be executed at the next hop, 437 and tunnels the packet to the SFF for that SFI. 439 o If the current hop requires an {SFP, SI} and the next hop requires 440 a {context label, SFI label}, it pops the {SFP, SI} from the top 441 of the MPLS label stack and tunnels the packet to the SFF 442 indicated by the context label. 444 o If the current hop requires a {context label, SFI label}, it pops 445 the {context label, SFI label} from the top of the MPLS label 446 stack. 448 * If the new top of the MPLS label stack contains an {SFP, SI} 449 label pair, it selects an SFI to use at the next hop, and 450 tunnels the packet to SFF for that SFI. 452 * If the top of the MPLS label stack contains a {context label, 453 SFI label}, it tunnels the packet to the SFF indicated by the 454 context label. 456 8. Control Plane Considerations 458 In order that a packet may be forwarded along an SFP several 459 functional elements must be executed. 461 o Discovery/advertisement of SFIs. 463 o Computation of SFP. 465 o Programming of Classifiers. 467 o Advertisement of forwarding instructions. 469 Various approaches may be taken. These include a fully centralized 470 model where SFFs report to a central controller the SFIs that they 471 support, the central controller computes the SFP and programs the 472 Classifiers, and (if the label swapping approach is taken) the 473 central controller installs forwarding state in the SFFs that lie on 474 the SFP. 476 Alternatively, a dynamic control plane may be used such as that 477 described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the 478 SFFs use the control plane to advertise the SFIs that they support, a 479 central controller computes the SFP and programs the Classifiers, and 480 (if the label swapping approach is taken) the central controller uses 481 the control plane to advertise the SFPs so that SFFs that lie on the 482 SFP can install the necessary forwarding state. 484 9. Use of the Entropy Label 486 Entropy is used in ECMP situations to ensure that packets from the 487 same flow travel down the same path, thus avoiding jitter or re- 488 ordering issues within a flow. 490 Entropy is often determined by hashing on specific fields in a packet 491 header such as the "five-tuple" in the IP and transport headers. 492 However, when an MPLS label stack is present, the depth of the stack 493 could be too large for some processors to correctly determine the 494 entropy hash. This problem is addressed by the inclusion of an 495 Entropy Label as described in [RFC6790]. 497 When entropy is desired for packets as they are carried in MPLS 498 tunnels over the underlay network, it is RECOMMENDED that an Entropy 499 Label is included in the label stack immediately after the tunnel 500 labels and before the SFC labels as shown in Figure 2 and Figure 3. 502 If an Entropy Label is present in a packet received by an SR-capabale 503 node (at the end of a tunnel across the underlay network), it is 504 RECOMMENDED that the value of that label is preserved and used in an 505 Entropy Label inserted in the label stack when the packet is 506 forwarded (on the next tunnel) to the next SFF. 508 If an Entropy Label is present in an MPLS payload, it is RECOMMENDED 509 that the initial Classifier use that value in an Entropy Label 510 inserted in the label stack when the packet is forwarded (on the 511 first tunnel) to the first SFF. In this case it is not necessary to 512 remove the Entropy Label from the payload. 514 10. Metadata 516 Metadata is defined in [RFC7665] as providing "the ability to 517 exchange context information between classifiers and SFs, and among 518 SFs." [RFC8300] defines how this context information can be directly 519 encoded in fields that form part of the NSH encapsulation. 521 The next two sections describe how metadata is associated with user 522 data packets, and how metadata may is exchanged between SFC nodes in 523 the network, when using an MPLS encoding of the logical 524 representation of the NSH. 526 10.1. Indicating Metadata in User Data Packets 528 Metadata is achieved in the MPLS realization of the logical NSH by 529 the use of an SFC Metadata Label which uses the Extended Special 530 Purpose Label construct [RFC7274]. Thus, three label stack entries 531 are present as shown in Figure 4: 533 o The Extension Label (value 15) 535 o An extended special purpose label called the Metadata Label 536 Indicator (MLI) (value TBD1 by IANA) 538 o The Metadata Label (ML). 540 ---------------- 541 | Extension = 15 | 542 +----------------+ 543 | MLI | 544 +----------------+ 545 | Metadata Label | 546 --------------- 548 Figure 4: The MPLS SFC Metadata Label 550 The Metadata Label value is an index into a table of metadata that is 551 programmed into the network using in-band or out-of-band mechanisms. 552 Out-of-band mechanisms potentially include management plane and 553 control plane solutions (such as 554 [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this 555 document. The in-band mechanism is described in Section 10.2 557 The SFC Metadata Label (as a set of three labels as indicated in 558 Figure 4) may be present zero, one, or more times in an MPLS SFC 559 packet. For MPLS label swapping, the SFC Metadata Labels are placed 560 immediately after the basic unit of MPLS label stack for SFC as shown 561 in Figure 5. For MPLS-SR, the SFC Metadata Labels can be present 562 zero, one, or more times and are placed at the bottom of the label 563 stack as shown in Figure 6. 565 ---------------- 566 ~ Tunnel Labels ~ 567 +----------------+ 568 ~ Optional ~ 569 ~ Entropy Label ~ 570 +----------------+ 571 | SPI Label | 572 +----------------+ 573 | SI Label | 574 +----------------+ 575 | Extension = 15 | 576 +----------------+ 577 | MLI | 578 +----------------+ 579 | Metadata Label | 580 +----------------+ 581 ~ Other ~ 582 | Metadata | 583 ~ Label Triples ~ 584 +----------------+ 585 | | 586 ~ Payload ~ 587 | | 588 ---------------- 590 Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata 591 Label 593 ------------------- 594 ~ MPLS-SR Labels ~ 595 +-------------------+ 596 ~ Optional ~ 597 ~ Entropy Label ~ 598 +-------------------+ 599 | SFC Context Label | 600 +-------------------+ 601 | SF Label | 602 +-------------------+ 603 ~ ~ 604 +-------------------+ 605 | SFC Context Label | 606 +-------------------+ 607 | SF Label | 608 +-------------------+ 609 | Extension = 15 | 610 +-------------------+ 611 | MLI | 612 +-------------------+ 613 | Metadata Label | 614 +-------------------+ 615 ~ Other ~ 616 | Metadata | 617 ~ Label Triples ~ 618 +-------------------+ 619 | | 620 ~ Payload ~ 621 | | 622 ------------------- 624 Figure 6: The MPLS SFC Label Stack for MPLS-SR with Metadata Label 626 10.2. Inband Programming of Metadata 628 A mechanism for sending metadata associated with an SFP without a 629 payload packet is described in [I-D.farrel-sfc-convent]. The same 630 approach can be used in an MPLS network where the NSH is logically 631 represented by an MPLS label stack. 633 The packet header is formed exactly as previously described in this 634 document so that the packet will follow the SFP through the SFC 635 network. However, instead of payload data, metadata is included 636 after the bottom of the MPLS label stack. An Extended Special 637 Purpose Label is used to indicate that the metadata is present. 638 Thus, three label stack entries are present: 640 o The Extension Label (value 15) 642 o An extended special purpose label called the Metadata Present 643 Indicator (MPI) (value TBD2 by IANA) 645 o The Metadata Label (ML) that is associated with this metadata on 646 this SFP and can be used to indicate the use of the metadata as 647 described in Section 10. 649 The SFC Metadata Present Label, if present, is placed immediately 650 after the last basic unit of MPLS label stack for SFC. The resultant 651 label stacks are shown in Figure 7 for the MPLS label swapping case 652 and Figure 8 for the MPLS-SR case. 654 --------------- 655 ~ Tunnel Labels ~ 656 +---------------+ 657 ~ Optional ~ 658 ~ Entropy Label ~ 659 +---------------+ 660 | SPI Label | 661 +---------------+ 662 | SI Label | 663 +---------------+ 664 | Extension = 15| 665 +---------------+ 666 | MPI | 667 +---------------+ 668 | Metadata Label| 669 +---------------+ 670 | | 671 ~ Metadata ~ 672 | | 673 --------------- 675 Figure 7: The MPLS SFC Label Stack Carrying Metadata 677 ------------------- 678 ~ MPLS-SR Labels ~ 679 +-------------------+ 680 ~ Optional ~ 681 ~ Entropy Label ~ 682 +-------------------+ 683 | SFC Context Label | 684 +-------------------+ 685 | SF Label | 686 +-------------------+ 687 | SFC Context Label | 688 +-------------------+ 689 | SF Label | 690 +-------------------+ 691 ~ ~ 692 +-------------------+ 693 | SFC Context Label | 694 +-------------------+ 695 | SF Label | 696 +-------------------+ 697 | Extension = 15 | 698 +-------------------+ 699 | MPI | 700 +-------------------+ 701 | Metadata Label | 702 +-------------------+ 703 | | 704 ~ Metadata ~ 705 | | 706 ------------------- 708 Figure 8: The MPLS SFC Label Stack for MPLS-SR Carrying Metadata 710 In both cases the metadata is formatted as a TLV as shown in 711 Figure 9. 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Length | Metadata Type | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 ~ Metadata ~ 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Figure 9: The Metadata TLV 723 The fields of this TLV are interpreted as follows: 725 Length: The length of the metadata carried in the Metadata field in 726 octets not including any padding. 728 Metadata Type: The type of the metadata present. Values for this 729 field are taken from the "MD Types" registry maintained by IANA 730 and defined in [RFC8300]. 732 Metadata: The actual metadata formatted as described in whatever 733 document defines the metadata. This field is end-padded with zero 734 to three octets of zeroes to take it up to a four octet boundary. 736 11. Worked Examples 738 Consider the simplistic MPLS SFC overlay network shown in Figure 10. 739 A packet is classified for an SFP that will see it pass through two 740 Service Functions, SFa and SFb, that are accessed through Service 741 Function Forwarders SFFa and SFFb respectively. The packet is 742 ultimately delivered to destination, D. 744 Let us assume that the SFP is computed and assigned the SPI of 239. 745 The forwarding details of the SFP are distributed (perhaps using the 746 mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs 747 are programmed with the necessary forwarding instructions. 749 The packet progresses as follows: 751 a. The Classifier assigns the packet to the SFP and imposes two 752 label stack entries comprising a single basic unit of MPLS SFC 753 representation: 755 * The higher label stack entry contains a label carrying the SPI 756 value of 239. 758 * The lower label stack entry contains a label carrying the SI 759 value of 255. 761 Further labels may be imposed to tunnel the packet from the 762 Classifier to SFFa. 764 b. When the packet arrives at SFFa it strips any labels associated 765 with the tunnel that runs from the Classifier to SFFa. SFFa 766 examines the top labels and matches the SPI/SI to identify that 767 the packet should be forwarded to SFa. The packet is forwarded 768 to SFa unmodified. 770 c. SFa performs its designated function and returns the packet to 771 SFFa. 773 d. SFFa modifies the SI in the lower label stack entry (to 254) and 774 uses the SPI/SI to look up the forwarding instructions. It sends 775 the packet with two label stack entries: 777 * The higher label stack entry contains a label carrying the SPI 778 value of 239. 780 * The lower label stack entry contains a label carrying the SI 781 value of 254. 783 Further labels may be imposed to tunnel the packet from the SFFa 784 to SFFb. 786 e. When the packet arrives at SFFb it strips any labels associated 787 with the tunnel from SFFa. SFFb examines the top labels and 788 matches the SPI/SI to identify that the packet should be 789 forwarded to SFb. The packet is forwarded to SFb unmodified. 791 f. SFb performs its designated function and returns the packet to 792 SFFb. 794 g. SFFb modifies the SI in the lower label stack entry (to 253) and 795 uses the SPI/SI to lookup up the forwarding instructions. It 796 determines that it is the last SFF in the SFP so it strips the 797 two SFC label stack entries and forwards the payload toward D 798 using the payload protocol. 800 +---------------------------------------------------+ 801 | MPLS SFC Network | 802 | | 803 | +---------+ +---------+ | 804 | | SFa | | SFb | | 805 | +----+----+ +----+----+ | 806 | ^ | | ^ | | | 807 | (b)| | |(c) (e)| | |(f) | 808 | (a) | | V (d) | | V (g) | 809 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 810 |Classifier+------+ SFFa +-------+ SFFb +------+ D | 811 +----------+ +---------+ +---------+ +-------+ 812 | | 813 +---------------------------------------------------+ 815 Figure 10: Service Function Chaining in an MPLS Network 817 Alternatively, consider the MPLS SFC overlay network shown in 818 Figure 11. A packet is classified for an SFP that will see it pass 819 through two Service Functions, SFx and SFy, that are accessed through 820 Service Function Forwarders SFFx and SFFy respectively. The packet 821 is ultimately delivered to destination, D. 823 Let us assume that the SFP is computed and assigned the SPI of 239. 824 However, the forwarding state for the SFP is not distributed and 825 installed in the network. Instead it will be attached to the 826 individual packets using MPLS-SR. 828 The packet progresses as follows: 830 1. The Classifier assigns the packet to the SFP and imposes two 831 basic units of MPLS SFC representation to describe the full SFP: 833 * The top basic unit comprises two label stack entries as 834 follows: 836 + The higher label stack entry contains a label carrying the 837 SFC context. 839 + The lower label stack entry contains a label carrying the 840 SF indicator for SFx. 842 * The lower basic unit comprises two label stack entries as 843 follows: 845 + The higher label stack entry contains a label carrying the 846 SFC context. 848 + The lower label stack entry contains a label carrying the 849 SF indicator for SFy. 851 Further labels may be imposed to tunnel the packet from the 852 Classifier to SFFx. 854 2. When the packet arrives at SFFx it strips any labels associated 855 with the tunnel from the Classifier. SFFx examines the top 856 labels and matches the context/SF values to identify that the 857 packet should be forwarded to SFx. The packet is forwarded to 858 SFx unmodified. 860 3. SFx performs its designated function and returns the packet to 861 SFFx. 863 4. SFFx strips the top basic unit of MPLS SFC representation 864 revealing the next basic unit. It then uses the revealed 865 context/SF values to determine how to route the packet to the 866 next SFF, SFFy. It sends the packet with just one basic unit of 867 MPLS SFC representation comprising two label stack entries: 869 * The higher label stack entry contains a label carrying the SFC 870 context. 872 * The lower label stack entry contains a label carrying the SF 873 indicator for SFy. 875 Further labels may be imposed to tunnel the packet from the SFFx 876 to SFFy. 878 5. When the packet arrives at SFFy it strips any labels associated 879 with the tunnel from SFFx. SFFy examines the top labels and 880 matches the context/SF values to identify that the packet should 881 be forwarded to SFy. The packet is forwarded to SFy unmodified. 883 6. SFy performs its designated function and returns the packet to 884 SFFy. 886 7. SFFy strips the top basic unit of MPLS SFC representation 887 revealing the payload packet. It forwards the payload toward D 888 using the payload protocol. 890 +---------------------------------------------------+ 891 | MPLS-SR SFC Network | 892 | | 893 | +---------+ +---------+ | 894 | | SFx | | SFy | | 895 | +----+----+ +----+----+ | 896 | ^ | | ^ | | | 897 | (2)| | |(3) (5)| | |(6) | 898 | (1) | | V (4) | | V (7) | 899 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 900 |Classifier+------+ SFFx +-------+ SFFy +------+ D | 901 +----------+ +---------+ +---------+ +-------+ 902 | | 903 +---------------------------------------------------+ 905 Figure 11: Service Function Chaining in an MPLS-SR Network 907 12. Security Considerations 909 Discussion of the security properties of SFC networks can be found in 910 [RFC7665]. Further security discussion for the NSH and its use is 911 present in [RFC8300]. 913 It is fundamental to the SFC design that the classifier is a trusted 914 resource which determines the processing that the packet will be 915 subject to, including for example the firewall. It is also 916 fundamental to the Segment Routing design that packets are routed 917 through the network using the path specified by the node imposing the 918 SIDs. Where an SF is not encapsulation aware the packet may exist as 919 an IP packet, however this is an intrinsic part of the SFC design 920 which needs to define how a packet is protected in that environment. 921 Where a tunnel is used to link two non-MPLS domains, the tunnel 922 design needs to specify how it is secured. Thus the security 923 vulnerabilities are addressed in the underlying technologies used by 924 this design, which itself does not introduce any new security 925 vulnerabilities. 927 13. IANA Considerations 929 This document requests IANA to make allocations from the "Extended 930 Special-Purpose MPLS Label Values" subregistry of the "Special- 931 Purpose Multiprotocol Label Switching (MPLS) Label Values" registry 932 as follows: 934 Value | Description | 935 -------+-----------------------------------+-------------- 936 TBD1 | Metadata Label Indicator (MLI) | [This.I-D] 937 TBD2 | Metadata Present Indicator (MPI) | [This.I-D] 939 14. Acknowledgements 941 This document derives ideas and text from 942 [I-D.ietf-bess-nsh-bgp-control-plane]. 944 The authors are grateful to all those who contributed to the 945 discussions that led to this work: Loa Andersson, Andrew G. Malis, 946 Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart 947 Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided 948 helpful review comments. 950 15. References 952 15.1. Normative References 954 [I-D.ietf-spring-segment-routing-mpls] 955 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 956 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 957 data plane", draft-ietf-spring-segment-routing-mpls-11 958 (work in progress), October 2017. 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, 962 DOI 10.17487/RFC2119, March 1997, 963 . 965 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 966 and Retiring Special-Purpose MPLS Labels", RFC 7274, 967 DOI 10.17487/RFC7274, June 2014, 968 . 970 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 971 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 972 May 2017, . 974 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 975 "Network Service Header (NSH)", RFC 8300, 976 DOI 10.17487/RFC8300, January 2018, 977 . 979 15.2. Informative References 981 [I-D.farrel-sfc-convent] 982 Farrel, A. and J. Drake, "Operating the Network Service 983 Header (NSH) with Next Protocol "None"", draft-farrel-sfc- 984 convent-05 (work in progress), December 2017. 986 [I-D.ietf-bess-nsh-bgp-control-plane] 987 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 988 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 989 nsh-bgp-control-plane-02 (work in progress), October 2017. 991 [I-D.ietf-spring-segment-routing] 992 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 993 Litkowski, S., and R. Shakir, "Segment Routing 994 Architecture", draft-ietf-spring-segment-routing-15 (work 995 in progress), January 2018. 997 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 998 Label Switching Architecture", RFC 3031, 999 DOI 10.17487/RFC3031, January 2001, 1000 . 1002 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1003 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1004 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1005 . 1007 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1008 Chaining (SFC) Architecture", RFC 7665, 1009 DOI 10.17487/RFC7665, October 2015, 1010 . 1012 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1013 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1014 Packet Routing in Networking (SPRING) Problem Statement 1015 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1016 2016, . 1018 Authors' Addresses 1020 Adrian Farrel 1021 Juniper Networks 1023 Email: afarrel@juniper.net 1025 Stewart Bryant 1026 Huawei 1028 Email: stewart.bryant@gmail.com 1030 John Drake 1031 Juniper Networks 1033 Email: jdrake@juniper.net