idnits 2.17.1 draft-farrel-mpls-sfc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (September 5, 2017) is 2425 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 (-28) exists of draft-ietf-sfc-nsh-20 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 == Outdated reference: A later version (-06) exists of draft-farrel-sfc-convent-02 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-00 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 Summary: 0 errors (**), 0 flaws (~~), 6 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: March 9, 2018 Huawei 6 J. Drake 7 Juniper Networks 8 September 5, 2017 10 An MPLS-Based Forwarding Plane for Service Function Chaining 11 draft-farrel-mpls-sfc-01 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 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on March 9, 2018. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 75 3. Basic Unit of Representation . . . . . . . . . . . . . . . . 4 76 4. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 5 77 5. MPLS Segment Routing . . . . . . . . . . . . . . . . . . . . 7 78 6. Control Plane Considerations . . . . . . . . . . . . . . . . 9 79 7. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 10 80 8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Indicating Metadata in User Data Packets . . . . . . . . 11 82 8.2. Inband Programming of Metadata . . . . . . . . . . . . . 13 83 9. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 16 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 13.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 Service Function Chaining (SFC) is the process of directing packets 95 through a network so that they can be acted on by an ordered set of 96 abstract service functions before being delivered to the intended 97 destination. An architecture for SFC is defined in [RFC7665]. 99 When applying a particular Service Function Chain to the traffic 100 selected by a service classifier, the traffic needs to be steered 101 through an ordered set of Service Functions (SF) in the network. 102 This ordered set of SFs is termed a Service Function Path (SFP), and 103 the traffic is passed between Service Function Forwarders (SFFs) that 104 are responsible for delivering the packets to the SFs and for 105 forwarding it onward to the next SFF. 107 In order to steer the selected traffic between SFFs and to the 108 correct SFs the service classifier needs to attach information to 109 each packet. This information indicates the SFP on which packet is 110 being forwarded and hence the SFs to which it must be delivered. The 111 information also indicates the progress the packet has already made 112 along the SFP. 114 The Network Service Header (NSH) [I-D.ietf-sfc-nsh] has been defined 115 to carry the necessary information for Service Function Chaining in 116 packets. The NHS can be inserted into packets and contains various 117 information including a Service Path Indicator (SPI), a Service Index 118 (SI), and a Time To Live (TTL) counter. 120 Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed 121 forwarding technology that uses labels to identify the forwarding 122 actions to be taken at each hop through a network. In many cases, 123 MPLS will be used as a tunneling technology to carry packets through 124 networks between SFFs. 126 Segment Routing [RFC7855] introduces a source routing paradigm into 127 packet switched networks. The application of Segment Routing in MPLS 128 networks is described in [I-D.ietf-spring-segment-routing-mpls]. 130 This document describes how Service Function Chaining can be achieved 131 in an MPLS network by means of a logical representation of the NSH in 132 an MPLS label stack. This approach is applicable to both classical 133 MPLS forwarding (where labels are looked up at each hop, and swapped 134 for the next hop [RFC3031]) and MPLS Segment Routing (where labels 135 are looked up at each hop, and popped to reveal the next label to 136 action [I-D.ietf-spring-segment-routing-mpls]). The mechanisms 137 described in this document are a compromise between the full function 138 that can be achieved using the NSH, and the benefits of reusing thee 139 existing MPLS forwarding paradigms. 141 It is assumed that the reader is fully familiar with the terms and 142 concepts introduced in [RFC7665] and [I-D.ietf-sfc-nsh]. 144 2. Choice of Data Plane SPI/SI Representation 146 While [I-D.ietf-sfc-nsh] defines the NSH that can be used in a number 147 of environments, this document provides a mechanism to handle 148 situations in which the NSH is not ubiquitously deployed. In this 149 case it is possible to use alternative data plane representations of 150 the SPI/SI by carrying the identical semantics in MPLS labels. 152 In order to correctly select the mechanism by which SFC information 153 is encoded, it may be necessary to configure the capabilities and 154 choices either within the whole Service Function Overlay Network, or 155 on a hop by hop basis. It is a requirement that both ends of a 156 tunnel over the underlay network know that the tunnel is used for SFC 157 and know what form of NSH representation is used. A control plane 158 signalling approach to achieve these objectives is provided using BGP 159 in [I-D.ietf-bess-nsh-bgp-control-plane]. 161 Note that the encoding of the SFC information is independent of the 162 choice of tunneling technology used between SFFs. Thus, an MPLS 163 representation of the logical NSH (as defined in this document) may 164 be used even if the tunnel between a pair of SFFs is not an MPLS 165 tunnel. Conversely, MPLS tunnels may be used to carry other 166 encodings of the logical NSH (specifically, the NSH itself). 168 3. Basic Unit of Representation 170 When an MPLS label stack is used to carry a logical NSH, a basic unit 171 of representation is used. This unit comprises two MPLS labels as 172 shown below. The unit may be present one or more times in the label 173 stack as explained in subsequent sections. 175 In order to convey the same information as is present in the NSH, two 176 MPLS label stack entries are used. One carries a label to provide 177 context within the SFC scope (the SFC Context Label), and the other 178 carries a label to show which service function is to be actioned (the 179 SF Label). This two-label unit is shown in Figure 1. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | SFC Context Label | TC |S| TTL | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | SF Label | TC |S| TTL | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 1: The Basic Unit of MPLS Label Stack for SFC 191 The fields of these two label stack entries are encoded as follows: 193 Label: The Label fields contain the values of the SFC Context Label 194 and the SF Label encoded as 20 bit integers. The precise 195 semantics of these label fields are dependent on whether the label 196 stack entries are used for MPLS swapping (see Section 4) or MPLS- 197 SR (see Section 5). 199 TC: The TC bits have no meaning. They SHOULD be set to zero in both 200 label stack entries and MUST be ignored. 202 S: The bottom of stack flag has its usual meaning in MPLS. It MUST 203 be clear in the SFC Context label stack entry and MAY be set in 204 the SF label stack entry depending on whether the label is the 205 bottom of stack. 207 TTL: The TTL field in the SFC Context label stack entry SHOULD be 208 set to 1. The TTL in SF label stack entry (called the SF TTL) is 209 set according to its use for MPLS swapping (see Section 4) or 210 MPLS-SR (see Section 5 and is used to mitigate packet loops. 212 The sections that follow show how this basic unit of MPLS label stack 213 may be used for SFC in the MPLS label swapping case and in the MPLS- 214 SR case. For simplicity, these sections do not describe the use of 215 metadata: that is covered separately in Section 8. 217 4. MPLS Label Swapping 219 This section describes how the basic unit of MPLS label stack for SFC 220 introduced in Section 3 is used when MPLS label swapping is in use. 221 As can be seen from Figure 2, the top of the label stack comprises 222 the labels necessary to deliver the packet over the MPLS tunnel 223 between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS 224 in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel 225 technology does not need to be MPLS, but that is shown here for 226 simplicity. 228 An entropy label ([RFC6790]) may also be present as described in 229 Section 7 231 Under these labels (or other encapsulation) comes a single instance 232 of the basic unit of MPLS label stack for SFC. In addition to the 233 interpretation of the fields of these label stack entries provided in 234 Section 3 the following meanings are applied: 236 SPI Label: The Label field of the SFC Context label stack entry 237 contains the value of the SPI encoded as a 20 bit integer. The 238 semantics of the SPI is exactly as defined in [I-D.ietf-sfc-nsh]. 240 Note that an SPI as defined by [I-D.ietf-sfc-nsh] can be encoded 241 in 3 octets (i.e., 24 bits), but that the Label field allows for 242 only 20 bits and reserves the values 0 though 15 as 'special 243 purpose' labels [RFC7274]. Thus, a system using MPLS 244 representation of the logical NSH MUST NOT assign SPI values 245 greater than 2^20 - 1 or less than 16. 247 SI Label: The Label field of the SF label stack entry contains the 248 value of the SI exactly as defined in [I-D.ietf-sfc-nsh]. Since 249 the SI requires only 8 bits, and to avoid overlap with the 250 'special purpose' label range of 0 through 15 [RFC7274], The SI is 251 carried in the top (most significant) 8 bits of the Label field 252 with the low order 12 bits set to zero. 254 TC: The TC field is as described in Section 3. 256 S: The S field is as described in Section 3. 258 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 259 as stated in Section 3. The TTL in SF label stack entry is 260 decremented once for each hop in the SFP, i.e., for each SFI 261 executed, and so mirrors the TTL field in the NSH. 263 The following processing rules apply to the Label fields: 265 o When a Classifier inserts a packet onto an SFP it sets the SPI 266 Label to indicate the identity of the SFP, and sets the SI Label 267 to indicate the first SF in the path. 269 o When a component of the SFC system processes a packet it uses the 270 SPI Label to identify the SFP and the SI Label to determine to 271 which SFF or SFI to deliver the packet. Under normal 272 circumstances (with the exception of branching and 273 reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the 274 SPI Label value is preserved on all packets. The SI Label value 275 is modified by and SFFs and through reclassification to indicate 276 the next hop along the SFP. 278 The following processing rules apply to the TTL field of the SF label 279 stack entry: 281 o When a Classifier places a packet onto an SFP it MUST set the TTL 282 to a value between 1 and 255. It SHOULD set this according to the 283 expected length of the SFP (i.e., the number of SFs on the SFP), 284 but it MAY set it to a larger value according to local 285 configuration. 287 o When an SFF receives a packet from any component of the SFC system 288 (Classifier, SFI, or another SFF) it MUST discard any packets with 289 TTL set to zero. It SHOULD log such occurrences, but MUST apply 290 rate limiting to any such logs. 292 o An SFF MUST decrement the TTL by one each time it sends the packet 293 to an SFI (local or remote), but not when it sends the packet to 294 another SFF. 296 o If an SFF decrements the TTL to zero it MUST NOT send the packet, 297 and MUST discard the packet. It SHOULD log such occurrences, but 298 MUST apply rate limiting to any such logs. 300 o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF 301 unmodified along with the SI (which may have been changed by local 302 reclassification). 304 o If a Classifier along the SFP makes any change to the intended 305 path of the packet including for looping, jumping, or branching 306 (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the 307 SI TTL of the packet. In particular, every component of the SFC 308 system MUST NOT increase the SI TTL value. 310 --------------- 311 ~ Tunnel Labels ~ 312 +---------------+ 313 ~ Optional ~ 314 ~ Entropy Label ~ 315 +---------------+ - - - 316 | SPI Label | 317 +---------------+ Basic unit of MPLS label stack for SFC 318 | SI Label | 319 +---------------+ - - - 320 | | 321 ~ Payload ~ 322 | | 323 --------------- 325 Figure 2: The MPLS SFC Label Stack 327 5. MPLS Segment Routing 329 This section describes how the basic unit of MPLS label stack for SFC 330 introduced in Section 3 is used when MPLS-SR. As can be seen 331 Figure 3, the top of the label stack comprises the labels necessary 332 to deliver the packet over the MPLS tunnel between SFFs. Any MPLS 333 encapsulation may be used and the tunnel technology does not need to 334 be MPLS or MPLS-SR, but MPLS-SR is shown here for simplicity. 336 An entropy label ([RFC6790]) may also be present as described in 337 Section 7 339 Under these labels (or other encapsulation) comes one of more 340 instances of the basic unit of MPLS label stack for SFC. In addition 341 to the interpretation of the fields of these label stack entries 342 provided in Section 3 the following meanings are applied: 344 SFC Context Label: The Label field of the SFC Context label stack 345 entry contains a label that delivers SFC context. This label may 346 be used to indicate the SPI encoded as a 20 bit integer using the 347 semantics of the SPI is exactly as defined in [I-D.ietf-sfc-nsh] 348 and noting that in this case a system using MPLS representation of 349 the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 350 or less than 16. This label may also be used to convey other 351 context-speific semantics. Alternatively this label may be used 352 to provide other SFC context such as indicating, perhaps with a 353 node SID (see [I-D.ietf-spring-segment-routing]), how to interpret 354 the SF Label. 356 SF Label: The Label field of the SF label stack entry contains a 357 value that identifies the next SFI to be actioned for the packet. 358 This label may be scoped globally or within the context of the 359 preceding SFC Context Label and comes from the range 16 ... 2^20 - 360 1. 362 TC: The TC field is as described in Section 3. 364 S: The S field is as described in Section 3. 366 TTL: The TTL field in the SFC Context label stack entry SHOULD be 367 set to 1 as stated in Section 3. The TTL in SF label stack entry 368 is set according to the norms for MPLS-SR. 370 The following processing rules apply to the Label fields: 372 o When a Classifier inserts a packet onto an SFP it adds a stack 373 comprising one or more instances of the basic unit of MPLS label 374 stack for SFC. Taken together, this stack defines the SFs to be 375 actioned and so defines the SFP that the packet will traverse. 377 o When a component of the SFC system processes a packet it uses the 378 top basic unit of label stack for SFC to determine to which SFI to 379 next deliver the packet. When an SFF receives a packet it 380 examines the top basic unit of MPLS label stack for SFC to 381 determine where to send the packet next. If the next recipient is 382 a local SFI, the SFC strips the basic unit of MPLS label stack for 383 SFC before forwarding the packet. 385 ------------------- 386 ~ MPLS-SR Labels ~ 387 +-------------------+ 388 ~ Optional ~ 389 ~ Entropy Label ~ 390 +-------------------+ - - - 391 | SFC Context Label | 392 +-------------------+ Basic unit of MPLS label stack for SFC 393 | SF Label | 394 +-------------------+ - - - 395 | SFC Context Label | 396 +-------------------+ Basic unit of MPLS label stack for SFC 397 | SF Label | 398 +-------------------+ - - - 399 ~ ~ 400 +-------------------+ - - - 401 | SFC Context Label | 402 +-------------------+ Basic unit of MPLS label stack for SFC 403 | SF Label | 404 +-------------------+ - - - 405 | | 406 ~ Payload ~ 407 | | 408 ------------------- 410 Figure 3: The MPLS SFC Label Stack for Segment Routing 412 6. Control Plane Considerations 414 In order that a packet may be forwarded along an SFP several 415 functional elements must be executed. 417 o Discovery/advertisement of SFIs. 419 o Computation of SFP. 421 o Programming of Classifiers. 423 o Advertisement of forwarding instructions. 425 Various approaches may be taken. These include a fully centralized 426 model where SFFs report to a central controller the SFIs that they 427 support, the central controller computes the SFP and programs the 428 Classifiers, and (if the label swapping approach is taken) the 429 central controller installs forwarding state in the SFFs that lie on 430 the SFP. 432 Alternatively, a dynamic control plane may be used such as that 433 described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the 434 SFFs use the control plane to advertise the SFIs that they support, a 435 central controller computes the SFP and programs the Classifiers, and 436 (if the label swapping approach is taken) the central controller uses 437 the control plane to advertise the SFPs so that SFFs that lie on the 438 SFP can install the necessary forwarding state. 440 7. Use of the Entropy Label 442 Entropy is used in ECMP situations to ensure that packets from the 443 same flow travel down the same path, thus avoiding jitter or re- 444 ordering issues in a flow. 446 Entropy is often determined by hashing on specific fields in a packet 447 header such as the "five-tuple" in the IP and transport headers. 448 However, when an MPLS label stack is present, the depth of the stack 449 could be too large for some processors to correctly determine the 450 entropy hash. This problem is addressed by the inclusion of an 451 Entropy Label as described in [RFC6790]. 453 When entropy is desired for packets as they are carried in MPLS 454 tunnels over the underlay network, it is RECOMMENDED that an Entropy 455 Label is included in the label stack immediately after the tunnel 456 labels and before the SFC labels as shown in Figure 2 and Figure 3. 458 If an Entropy Label is present in a packet received by an SR-capabale 459 node (at the end of a tunnel across the underlay network), it is 460 RECOMMENDED that the value of that label is preserved and used in an 461 Entropy Label inserted in the label stack when the packet is 462 forwarded (on the next tunnel) to the next SFF. 464 If an Entropy Label is present in an MPLS payload, it is RECOMMENDED 465 that the initial Classifier use that value in an Entropy Label 466 inserted in the label stack when the packet is forwarded (on the 467 first tunnel) to the first SFF. In this case it is not necessary to 468 remove the Entropy Label from the payload. 470 8. Metadata 472 Metadata is defined in [RFC7665] as providing "the ability to 473 exchange context information between classifiers and SFs, and among 474 SFs." [I-D.ietf-sfc-nsh] defines how the context information can be 475 directly encoded in fields that form part of the NSH encapsulation. 477 The next two sections describe how metadata is associated with user 478 data packets, and how metadata may is exchanged between SFC nodes in 479 the network. 481 8.1. Indicating Metadata in User Data Packets 483 Metadata is achieved in the MPLS realization of the logical NSH by 484 the use of an SFC Metadata Label which uses the Extended Special 485 Purpose Label construct [RFC7274]. Thus, three label stack entries 486 are present as shown in Figure 4: 488 o The Extension Label (value 15) 490 o An extended special purpose label called the Metadata Label 491 Indicator (MLI) (value TBD1 by IANA) 493 o The Metadata Label (ML). 495 ---------------- 496 | Extension = 15 | 497 +----------------+ 498 | MLI | 499 +----------------+ 500 | Metadata Label | 501 --------------- 503 Figure 4: The MPLS SFC Metadata Label 505 The Metadata Label value is an index into a table of metadata that is 506 programmed into the network using in-band or out-of-band mechanisms. 507 Out-of-band mechanisms potentially include management plane and 508 control plane solutions (such as 509 [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this 510 document. The in-band mechanism is described in Section 8.2 512 The SFC Metadata Label (as a set of three labels as indicated in 513 Figure 4) may be present zero, one, or more times in an MPLS SFC 514 packet. For MPLS label swapping, the SFC Metadata Labels are placed 515 immediately after the basic unit of MPLS label stack for SFC as shown 516 in Figure 5. For MPLS-SR, the SFC Metadata can be present zero, one, 517 or more times and are placed at the bottom of the label stack as 518 shown in Figure 6. 520 ---------------- 521 ~ Tunnel Labels ~ 522 +----------------+ 523 ~ Optional ~ 524 ~ Entropy Label ~ 525 +----------------+ 526 | SPI Label | 527 +----------------+ 528 | SI Label | 529 +----------------+ 530 | Extension = 15 | 531 +----------------+ 532 | MLI | 533 +----------------+ 534 | Metadata Label | 535 +----------------+ 536 ~ Other ~ 537 | Metadata | 538 ~ Labels ~ 539 +----------------+ 540 | | 541 ~ Payload ~ 542 | | 543 ---------------- 545 Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata 546 Label 548 ------------------- 549 ~ MPLS-SR Labels ~ 550 +-------------------+ 551 ~ Optional ~ 552 ~ Entropy Label ~ 553 +-------------------+ 554 | SFC Context Label | 555 +-------------------+ 556 | SF Label | 557 +-------------------+ 558 ~ ~ 559 +-------------------+ 560 | SFC Context Label | 561 +-------------------+ 562 | SF Label | 563 +-------------------+ 564 | Extension = 15 | 565 +-------------------+ 566 | MLI | 567 +-------------------+ 568 | Metadata Label | 569 +-------------------+ 570 ~ Other ~ 571 | Metadata | 572 ~ Labels ~ 573 +-------------------+ 574 | | 575 ~ Payload ~ 576 | | 577 ------------------- 579 Figure 6: The MPLS SFC Label Stack for MPLS-SR with Metadata Label 581 8.2. Inband Programming of Metadata 583 A mechanism for sending metadata associated with an SFP without a 584 payload packet is described in [I-D.farrel-sfc-convent]. The same 585 approach can be used in an MPLS network where the NSH is logically 586 represented by an MPLS label stack. 588 The packet header is formed exactly as previously described in this 589 document so that the packet will follow the SFP through the SFC 590 network. An Extended Special Purpose Label is used to indicate that 591 metadata is present. Thus, three label stack entries are present: 593 o The Extension Label (value 15) 594 o An extended special purpose label called the Metadata Present 595 Indicator (MPI) (value TBD2 by IANA) 597 o The Metadata Label (ML) that is associated with this metadata on 598 this SFP and can be used to indicate the use of the metadata as 599 described in Section 8. 601 The SFC Metadata Present Label, if present, is placed immediately 602 after the last basic unit of MPLS label stack for SFC. The resultant 603 label stacks are shown in Figure 7 for the MPLS label swapping case 604 and Figure 8 for the MPLS-SR case. 606 --------------- 607 ~ Tunnel Labels ~ 608 +---------------+ 609 ~ Optional ~ 610 ~ Entropy Label ~ 611 +---------------+ 612 | SPI Label | 613 +---------------+ 614 | SI Label | 615 +---------------+ 616 | Extension = 15| 617 +---------------+ 618 | MPI | 619 +---------------+ 620 | Metadata Label| 621 +---------------+ 622 | | 623 ~ Metadata ~ 624 | | 625 --------------- 627 Figure 7: The MPLS SFC Label Stack Carrying Metadata 629 ------------------- 630 ~ MPLS-SR Labels ~ 631 +-------------------+ 632 ~ Optional ~ 633 ~ Entropy Label ~ 634 +-------------------+ 635 | SFC Context Label | 636 +-------------------+ 637 | SF Label | 638 +-------------------+ 639 | SFC Context Label | 640 +-------------------+ 641 | SF Label | 642 +-------------------+ 643 ~ ~ 644 +-------------------+ 645 | SFC Context Label | 646 +-------------------+ 647 | SF Label | 648 +-------------------+ 649 | Extension = 15 | 650 +-------------------+ 651 | MPI | 652 +-------------------+ 653 | Metadata Label | 654 +-------------------+ 655 | | 656 ~ Metadata ~ 657 | | 658 ------------------- 660 Figure 8: The MPLS SFC Label Stack for MPLS-SR Carrying Metadata 662 In both cases the metadata is formatted as a TLV as shown in 663 Figure 9. 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Length | Metadata Type | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 ~ Metadata ~ 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Figure 9: The Metadata TLV 675 The fields of this TLV are interpreted as follows: 677 Length: The length of the metadata carried the Metadata field in 678 octets not including any padding. 680 Metadata Type: The type of the metadata present. Values for this 681 field are taken from the "MD Types" registry maintained by IANA 682 and defined in [I-D.ietf-sfc-nsh]. 684 Metadata: The actual metadata formatted as described in whatever 685 document defines the metadata. This field is end-padded with zero 686 to three octets of zeroes to take it up to a four octet boundary. 688 9. Worked Examples 690 Consider the simplistic MPLS SFC overlay network shown in Figure 10. 691 A packet is classified for an SFP that will see it pass through two 692 Service Functions, SFa and SFb, that are accessed through Service 693 Function Forwarders SFFa and SFFb respectively. The packet is 694 ultimately delivered to destination, D. 696 Let us assume that the SFP is computed and assigned the SPI of 239. 697 The forwarding details of the SFP are distributed (perhaps using the 698 mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs 699 are programmed with the necessary forwarding instructions. 701 The packet progresses as follows: 703 a. The Classifier assigns the packet to the SFP and imposes two 704 label stack entries comprising a single basic unit of MPLS SFC 705 representation: 707 * The higher label stack entry contains a label carrying the SPI 708 value of 239. 710 * The lower label stack entry contains a label carrying the SI 711 value of 255. 713 Further labels may be imposed to tunnel the packet from the 714 Classifier to SFFa. 716 b. When the packet arrives at SFFa it strips any labels associated 717 with the tunnel from the Classifier. SFFa examines the top 718 labels and matches the SPI/SI to identify that the packet should 719 be forwarded to SFa. The packet is forwarded to SFa unmodified. 721 c. SFa performs its designated function and returns the packet to 722 SFFa. 724 d. SFFa modifies the SI in the lower label stack entry (to 254) and 725 uses the SPI/SI to look up the forwarding instructions. It sends 726 the packet with two label stack entries: 728 * The higher label stack entry contains a label carrying the SPI 729 value of 239. 731 * The lower label stack entry contains a label carrying the SI 732 value of 254. 734 Further labels may be imposed to tunnel the packet from the SFFa 735 to SFFb. 737 e. When the packet arrives at SFFb it strips any labels associated 738 with the tunnel from SFFa. SFFb examines the top labels and 739 matches the SPI/SI to identify that the packet should be 740 forwarded to SFb. The packet is forwarded to SFb unmodified. 742 f. SFb performs its designated function and returns the packet to 743 SFFb. 745 g. SFFb modifies the SI in the lower label stack entry (to 253) and 746 uses the SPI/SI to lookup up the forwarding instructions. It 747 determines that it is the last SFF in the SFP so it strips the 748 two SFC label stack entries and forwards the payload toward D 749 using the payload protocol. 751 +---------------------------------------------------+ 752 | MPLS SFC Network | 753 | | 754 | +---------+ +---------+ | 755 | | SFa | | SFb | | 756 | +----+----+ +----+----+ | 757 | ^ | | ^ | | | 758 | (b)| | |(c) (e)| | |(f) | 759 | (a) | | V (d) | | V (g) | 760 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 761 |Classifier+------+ SFFa +-------+ SFFb +------+ D | 762 +----+-----+ +---------+ +---------+ +---+---+ 763 | | 764 +---------------------------------------------------+ 766 Figure 10: Service Function Chaining in an MPLS Network 768 Alternatively, consider the MPLS SFC overlay network shown in 769 Figure 11. A packet is classified for an SFP that will see it pass 770 through two Service Functions, SF1 and SF2, that are accessed through 771 Service Function Forwarders SFF1 and SFF2 respectively. The packet 772 is ultimately delivered to destination, D. 774 Let us assume that the SFP is computed and assigned the SPI of 239. 775 However, the forwarding state for the SFP is not distributed and 776 installed in the network. Instead it will be attached to the 777 individual packets using MPLS-SR. 779 The packet progresses as follows: 781 1. The Classifier assigns the packet to the SFP and imposes two 782 basic units of MPLS SFC representation to describe the full SFP: 784 * The top basic unit comprises two label stack entries as 785 follows: 787 + The higher label stack entry contains a label carrying the 788 SFC context. 790 + The lower label stack entry contains a label carrying the 791 SF indicator for SF1. 793 * The lower basic unit comprises two label stack entries as 794 follows: 796 + The higher label stack entry contains a label carrying the 797 SFC context. 799 + The lower label stack entry contains a label carrying the 800 SF indicator for SF2. 802 Further labels may be imposed to tunnel the packet from the 803 Classifier to SFF1. 805 2. When the packet arrives at SFF1 it strips any labels associated 806 with the tunnel from the Classifier. SFF1 examines the top 807 labels and matches the context/SF values to identify that the 808 packet should be forwarded to SF1. The packet is forwarded to 809 SF1 unmodified. 811 3. SF1 performs its designated function and returns the packet to 812 SFF1. 814 4. SFF1 strips the top basic unit of MPLS SFC representation 815 revealing the next basic unit. It then uses the revealed 816 context/SF values to determine how to route the packet to the 817 next SFF, SFF2. It sends the packet with just one basic unit of 818 MPLS SFC representation comprising two label stack entries: 820 * The higher label stack entry contains a label carrying the SFC 821 context. 823 * The lower label stack entry contains a label carrying the SF 824 indicator for SF2. 826 Further labels may be imposed to tunnel the packet from the SFF1 827 to SFF2. 829 5. When the packet arrives at SFF2 it strips any labels associated 830 with the tunnel from SFF1. SFF2 examines the top labels and 831 matches the context/SF values to identify that the packet should 832 be forwarded to SF2. The packet is forwarded to SF2 unmodified. 834 6. SF2 performs its designated function and returns the packet to 835 SFF2. 837 7. SFF2 strips the top basic unit of MPLS SFC representation 838 revealing the payload packet. It forwards the payload toward D 839 using the payload protocol. 841 +---------------------------------------------------+ 842 | MPLS-SR SFC Network | 843 | | 844 | +---------+ +---------+ | 845 | | SF1 | | SF2 | | 846 | +----+----+ +----+----+ | 847 | ^ | | ^ | | | 848 | (2)| | |(3) (5)| | |(6) | 849 | (1) | | V (4) | | V (7) | 850 +----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+ 851 |Classifier+------+ SFF1 +-------+ SFF2 +------+ D | 852 +----+-----+ +---------+ +---------+ +---+---+ 853 | | 854 +---------------------------------------------------+ 856 Figure 11: Service Function Chaining in an MPLS-SR Network 858 10. Security Considerations 860 Discussion of the security properties of SFC networks can be found in 861 [RFC7665]. Further security discussion for the NSH and its use is 862 present in [I-D.ietf-sfc-nsh]. 864 It is fundamental to the SFC design that the classifier is a trusted 865 resource which determines the processing that the packet will be 866 subject to, including for example the firewall. It is also 867 fundamental to the Segment Routing design that packets are routed 868 through the network using the path specified by the node imposing the 869 SIDs. Where an SF is not encapsulation aware the packet may exist as 870 an IP packet, however this is an intrinsic part of the SFC design 871 which needs to define how a packet is protected in that environment. 872 Where a tunnel is used to link two non-MPLS domains, the tunnel 873 design needs to specify how it is secured. Thus the security 874 vulnerabilities are addressed in the underlying technologies used by 875 this design, which itself does not introduce any new security 876 vulnerabilities. 878 11. IANA Considerations 880 This document requests IANA to make allocations from the "Extended 881 Special-Purpose MPLS Label Values" subregistry of the "Special- 882 Purpose Multiprotocol Label Switching (MPLS) Label Values" registry 883 as follows: 885 Value | Description | 886 -------+-----------------------------------+-------------- 887 TBD1 | Metadata Label Indicator (MLI) | [This.I-D] 888 TBD2 | Metadata Present Indicator (MPI) | [This.I-D] 890 12. Acknowledgements 892 This document derives ideas and text from 893 [I-D.ietf-bess-nsh-bgp-control-plane]. 895 The authors are grateful to all those who contributed to the 896 discussions that led to this work: Loa Andersson, Andrew G. Malis, 897 Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart 898 Mackie, Keyur Patel, and Jim Guichard. 900 13. References 902 13.1. Normative References 904 [I-D.ietf-sfc-nsh] 905 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 906 Header (NSH)", draft-ietf-sfc-nsh-20 (work in progress), 907 September 2017. 909 [I-D.ietf-spring-segment-routing-mpls] 910 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 911 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 912 data plane", draft-ietf-spring-segment-routing-mpls-10 913 (work in progress), June 2017. 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, 917 DOI 10.17487/RFC2119, March 1997, 918 . 920 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 921 and Retiring Special-Purpose MPLS Labels", RFC 7274, 922 DOI 10.17487/RFC7274, June 2014, 923 . 925 13.2. Informative References 927 [I-D.farrel-sfc-convent] 928 Farrel, A. and J. Drake, "Operating the Network Service 929 Header (NSH) with Next Protocol "None"", draft-farrel-sfc- 930 convent-02 (work in progress), June 2017. 932 [I-D.ietf-bess-nsh-bgp-control-plane] 933 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 934 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 935 nsh-bgp-control-plane-00 (work in progress), March 2017. 937 [I-D.ietf-spring-segment-routing] 938 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 939 and R. Shakir, "Segment Routing Architecture", draft-ietf- 940 spring-segment-routing-12 (work in progress), June 2017. 942 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 943 Label Switching Architecture", RFC 3031, 944 DOI 10.17487/RFC3031, January 2001, 945 . 947 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 948 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 949 RFC 6790, DOI 10.17487/RFC6790, November 2012, 950 . 952 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 953 Chaining (SFC) Architecture", RFC 7665, 954 DOI 10.17487/RFC7665, October 2015, 955 . 957 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 958 Litkowski, S., Horneffer, M., and R. Shakir, "Source 959 Packet Routing in Networking (SPRING) Problem Statement 960 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 961 2016, . 963 Authors' Addresses 965 Adrian Farrel 966 Juniper Networks 968 Email: afarrel@juniper.net 970 Stewart Bryant 971 Huawei 973 Email: stewart.bryant@gmail.com 975 John Drake 976 Juniper Networks 978 Email: jdrake@juniper.net