idnits 2.17.1 draft-farrel-mpls-sfc-02.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 (October 30, 2017) is 2364 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-27 == 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-03 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 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: May 3, 2018 Huawei 6 J. Drake 7 Juniper Networks 8 October 30, 2017 10 An MPLS-Based Forwarding Plane for Service Function Chaining 11 draft-farrel-mpls-sfc-02 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 https://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 May 3, 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . 8 78 6. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 10 79 7. Control Plane Considerations . . . . . . . . . . . . . . . . 11 80 8. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 11 81 9. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Indicating Metadata in User Data Packets . . . . . . . . 12 83 9.2. Inband Programming of Metadata . . . . . . . . . . . . . 14 84 10. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 17 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 90 14.2. Informative References . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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) [I-D.ietf-sfc-nsh] has been defined 116 to carry the necessary information for Service Function Chaining in 117 packets. The NSH can be inserted into packets and contains various 118 information including a Service Path Indicator (SPI), a Service Index 119 (SI), and a Time To Live (TTL) counter. 121 Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed 122 forwarding technology that uses labels to identify the forwarding 123 actions to be taken at each hop through a network. In many cases, 124 MPLS will be used as a tunneling technology to carry packets through 125 networks between SFFs. 127 Segment Routing [RFC7855] introduces a source routing paradigm into 128 packet switched networks. The application of Segment Routing in MPLS 129 networks is described in [I-D.ietf-spring-segment-routing-mpls] and 130 is known as MPLS-SR. 132 This document describes how Service Function Chaining can be achieved 133 in an MPLS network by means of a logical representation of the NSH in 134 an MPLS label stack. This approach is applicable to both classical 135 MPLS forwarding (where labels are looked up at each hop, and swapped 136 for the next hop [RFC3031]) and MPLS Segment Routing (where labels 137 are looked up at each hop, and popped to reveal the next label to 138 action [I-D.ietf-spring-segment-routing-mpls]). The mechanisms 139 described in this document are a compromise between the full function 140 that can be achieved using the NSH, and the benefits of reusing the 141 existing MPLS forwarding paradigms. 143 It is assumed that the reader is fully familiar with the terms and 144 concepts introduced in [RFC7665] and [I-D.ietf-sfc-nsh]. 146 2. Choice of Data Plane SPI/SI Representation 148 While [I-D.ietf-sfc-nsh] defines the NSH that can be used in a number 149 of environments, this document provides a mechanism to handle 150 situations in which the NSH is not ubiquitously deployed. In this 151 case it is possible to use an alternative data plane representation 152 of the SPI/SI by carrying the identical semantics in MPLS labels. 154 In order to correctly select the mechanism by which SFC information 155 is encoded and carried between SFFs, it may be necessary to configure 156 the capabilities and choices either within the whole Service Function 157 Overlay Network, or on a hop by hop basis. It is a requirement that 158 both ends of a tunnel over the underlay network know that the tunnel 159 is used for SFC and know what form of NSH representation is used. A 160 control plane signalling approach to achieve these objectives is 161 provided using BGP in [I-D.ietf-bess-nsh-bgp-control-plane]. 163 Note that the encoding of the SFC information is independent of the 164 choice of tunneling technology used between SFFs. Thus, an MPLS 165 representation of the logical NSH (as defined in this document) may 166 be used even if the tunnel between a pair of SFFs is not an MPLS 167 tunnel. Conversely, MPLS tunnels may be used to carry other 168 encodings of the logical NSH (specifically, the NSH itself). 170 3. Basic Unit of Representation 172 When an MPLS label stack is used to carry a logical NSH, a basic unit 173 of representation is used. This unit comprises two MPLS labels as 174 shown below. The unit may be present one or more times in the label 175 stack as explained in subsequent sections. 177 In order to convey the same information as is present in the NSH, two 178 MPLS label stack entries are used. One carries a label to provide 179 context within the SFC scope (the SFC Context Label), and the other 180 carries a label to show which service function is to be actioned (the 181 SF Label). This two-label unit is shown in Figure 1. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | SFC Context Label | TC |S| TTL | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SF Label | TC |S| TTL | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: The Basic Unit of MPLS Label Stack for SFC 193 The fields of these two label stack entries are encoded as follows: 195 Label: The Label fields contain the values of the SFC Context Label 196 and the SF Label encoded as 20 bit integers. The precise 197 semantics of these label fields are dependent on whether the label 198 stack entries are used for MPLS swapping (see Section 4) or MPLS- 199 SR (see Section 5). 201 TC: The TC bits have no meaning. They SHOULD be set to zero in both 202 label stack entries and MUST be ignored. 204 S: The bottom of stack flag has its usual meaning in MPLS. It MUST 205 be clear in the SFC Context label stack entry and MAY be set in 206 the SF label stack entry depending on whether the label is the 207 bottom of stack. 209 TTL: The TTL field in the SFC Context label stack entry SHOULD be 210 set to 1. The TTL in SF label stack entry (called the SF TTL) is 211 set according to its use for MPLS swapping (see Section 4) or 212 MPLS-SR (see Section 5 and is used to mitigate packet loops. 214 The sections that follow show how this basic unit of MPLS label stack 215 may be used for SFC in the MPLS label swapping case and in the MPLS- 216 SR case. For simplicity, these sections do not describe the use of 217 metadata: that is covered separately in Section 9. 219 4. MPLS Label Swapping 221 This section describes how the basic unit of MPLS label stack for SFC 222 introduced in Section 3 is used when MPLS label swapping is in use. 223 As can be seen from Figure 2, the top of the label stack comprises 224 the labels necessary to deliver the packet over the MPLS tunnel 225 between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS 226 in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel 227 technology does not need to be MPLS, but that is shown here for 228 simplicity. 230 An entropy label ([RFC6790]) may also be present as described in 231 Section 8 233 Under these labels (or other encapsulation) comes a single instance 234 of the basic unit of MPLS label stack for SFC. In addition to the 235 interpretation of the fields of these label stack entries provided in 236 Section 3 the following meanings are applied: 238 SPI Label: The Label field of the SFC Context label stack entry 239 contains the value of the SPI encoded as a 20 bit integer. The 240 semantics of the SPI is exactly as defined in [I-D.ietf-sfc-nsh]. 241 Note that an SPI as defined by [I-D.ietf-sfc-nsh] can be encoded 242 in 3 octets (i.e., 24 bits), but that the Label field allows for 243 only 20 bits and reserves the values 0 though 15 as 'special 244 purpose' labels [RFC7274]. Thus, a system using MPLS 245 representation of the logical NSH MUST NOT assign SPI values 246 greater than 2^20 - 1 or less than 16. 248 SI Label: The Label field of the SF label stack entry contains the 249 value of the SI exactly as defined in [I-D.ietf-sfc-nsh]. Since 250 the SI requires only 8 bits, and to avoid overlap with the 251 'special purpose' label range of 0 through 15 [RFC7274], the SI is 252 carried in the top (most significant) 8 bits of the Label field 253 with the low order 12 bits set to zero. 255 TC: The TC fields are as described in Section 3. 257 S: The S fields are as described in Section 3. 259 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 260 as stated in Section 3. The TTL in SF label stack entry is 261 decremented once for each forwarding hop in the SFP, i.e., for 262 each SFF transited, and so mirrors the TTL field in the NSH. 264 --------------- 265 ~ Tunnel Labels ~ 266 +---------------+ 267 ~ Optional ~ 268 ~ Entropy Label ~ 269 +---------------+ - - - 270 | SPI Label | 271 +---------------+ Basic unit of MPLS label stack for SFC 272 | SI Label | 273 +---------------+ - - - 274 | | 275 ~ Payload ~ 276 | | 277 --------------- 279 Figure 2: The MPLS SFC Label Stack 281 The following processing rules apply to the Label fields: 283 o When a Classifier inserts a packet onto an SFP it sets the SPI 284 Label to indicate the identity of the SFP, and sets the SI Label 285 to indicate the first SF in the path. 287 o When a component of the SFC system processes a packet it uses the 288 SPI Label to identify the SFP and the SI Label to determine to 289 which SFF or SFI to deliver the packet. Under normal 290 circumstances (with the exception of branching and 291 reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the 292 SPI Label value is preserved on all packets. The SI Label value 293 is modified by SFFs and through reclassification to indicate the 294 next hop along the SFP. 296 The following processing rules apply to the TTL field of the SF label 297 stack entry, and are derived from section 2.2 of [I-D.ietf-sfc-nsh]: 299 o When a Classifier places a packet onto an SFP it MUST set the TTL 300 to a value between 1 and 255. It SHOULD set this according to the 301 expected length of the SFP (i.e., the number of SFs on the SFP), 302 but it MAY set it to a larger value according to local 303 configuration. The maximum TTL value supported in an NSH is 63, 304 and so the practical limit here may also be 63. 306 o When an SFF receives a packet from any component of the SFC system 307 (Classifier, SFI, or another SFF) it MUST discard any packets with 308 TTL set to zero. It SHOULD log such occurrences, but MUST apply 309 rate limiting to any such logs. 311 o An SFF MUST decrement the TTL by one each time it performs a 312 forwarding lookup. 314 o If an SFF decrements the TTL to zero it MUST NOT send the packet, 315 and MUST discard the packet. It SHOULD log such occurrences, but 316 MUST apply rate limiting to any such logs. 318 o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF 319 unmodified along with the SI (which may have been changed by local 320 reclassification). 322 o If a Classifier along the SFP makes any change to the intended 323 path of the packet including for looping, jumping, or branching 324 (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the 325 SI TTL of the packet. In particular, each component of the SFC 326 system MUST NOT increase the SI TTL value otherwise loops may go 327 undetected. 329 5. MPLS Segment Routing 331 This section describes how the basic unit of MPLS label stack for SFC 332 introduced in Section 3 is used when in an MPLS-SR network. As can 333 be seen Figure 3, the top of the label stack comprises the labels 334 necessary to deliver the packet over the MPLS tunnel between SFFs. 335 Any MPLS encapsulation may be used and the tunnel technology does not 336 need to be MPLS or MPLS-SR, but MPLS-SR is shown here for simplicity. 338 An entropy label ([RFC6790]) may also be present as described in 339 Section 8 341 Under these labels (or other encapsulation) comes one of more 342 instances of the basic unit of MPLS label stack for SFC. In addition 343 to the interpretation of the fields of these label stack entries 344 provided in Section 3 the following meanings are applied: 346 SFC Context Label: The Label field of the SFC Context label stack 347 entry contains a label that delivers SFC context. This label may 348 be used to indicate the SPI encoded as a 20 bit integer using the 349 semantics of the SPI is exactly as defined in [I-D.ietf-sfc-nsh] 350 and noting that in this case a system using MPLS representation of 351 the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 352 or less than 16. This label may also be used to convey other SFC 353 context-speific semantics such as indicating, perhaps with a node 354 SID (see [I-D.ietf-spring-segment-routing]), how to interpret the 355 SF Label. 357 SF Label: The Label field of the SF label stack entry contains a 358 value that identifies the next SFI to be actioned for the packet. 360 This label may be scoped globally or within the context of the 361 preceding SFC Context Label and comes from the range 16 ... 2^20 - 362 1. 364 TC: The TC fields are as described in Section 3. 366 S: The S fields are as described in Section 3. 368 TTL: The TTL field in the SFC Context label stack entry SHOULD be 369 set to 1 as stated in Section 3. The TTL in SF label stack entry 370 is set according to the norms for MPLS-SR. 372 ------------------- 373 ~ MPLS-SR Labels ~ 374 +-------------------+ 375 ~ Optional ~ 376 ~ Entropy Label ~ 377 +-------------------+ - - - 378 | SFC Context Label | 379 +-------------------+ Basic unit of MPLS label stack for SFC 380 | SF Label | 381 +-------------------+ - - - 382 | SFC Context Label | 383 +-------------------+ Basic unit of MPLS label stack for SFC 384 | SF Label | 385 +-------------------+ - - - 386 ~ ~ 387 +-------------------+ - - - 388 | SFC Context Label | 389 +-------------------+ Basic unit of MPLS label stack for SFC 390 | SF Label | 391 +-------------------+ - - - 392 | | 393 ~ Payload ~ 394 | | 395 ------------------- 397 Figure 3: The MPLS SFC Label Stack for Segment Routing 399 The following processing rules apply to the Label fields: 401 o When a Classifier inserts a packet onto an SFP it adds a stack 402 comprising one or more instances of the basic unit of MPLS label 403 stack for SFC. Taken together, this stack defines the SFs to be 404 actioned and so defines the SFP that the packet will traverse. 406 o When a component of the SFC system processes a packet it uses the 407 top basic unit of label stack for SFC to determine to which SFI to 408 next deliver the packet. When an SFF receives a packet it 409 examines the top basic unit of MPLS label stack for SFC to 410 determine where to send the packet next. If the next recipient is 411 a local SFI, the SFC strips the basic unit of MPLS label stack for 412 SFC before forwarding the packet. 414 6. Mixed Mode Forwarding 416 The previous sections describe homogeneous networks where SFC 417 forwarding is either all label swapping or all label popping. But it 418 is also possible that different parts of the network utilize swapping 419 or popping for different purposes. 421 When an SFF receives a packet containing an MPLS label stack, it 422 checks whether it is processing an {SFP, SI} label pair for label 423 swapping or a {context label, SFI index} label pair for MPLS-SR. It 424 then selects the appropriate SFI to which to send the packet. When 425 it receives the packet back from the SFI, it has four cases to 426 consider. 428 o If the current hop requires an {SFP, SI} and the next hop requires 429 an {SFP, SI}, it sets the SI label to the SI value of the current 430 hop, selects an instance of the SF to be executed at the next hop, 431 and tunnels the packet to the SFF for that SFI. 433 o If the current hop requires an {SFP, SI} and the next hop requires 434 a {context label, SFI label}, it pops the {SFP, SI} from the top 435 of the MPLS label stack and tunnels the packet to the SFF 436 indicated by the context label. 438 o If the current hop requires a {context label, SFI label}, it pops 439 the {context label, SFI label} from the top of the MPLS label 440 stack. 442 * If the new top of the MPLS label stack contains an {SFP, SI} 443 label pair, it selects an SFI to use at the next hop, and 444 tunnels the packet to SFF for that SFI. 446 * If the top of the MPLS label stack contains a {context label, 447 SFI label}, it tunnels the packet to the SFF indicated by the 448 context label. 450 7. Control Plane Considerations 452 In order that a packet may be forwarded along an SFP several 453 functional elements must be executed. 455 o Discovery/advertisement of SFIs. 457 o Computation of SFP. 459 o Programming of Classifiers. 461 o Advertisement of forwarding instructions. 463 Various approaches may be taken. These include a fully centralized 464 model where SFFs report to a central controller the SFIs that they 465 support, the central controller computes the SFP and programs the 466 Classifiers, and (if the label swapping approach is taken) the 467 central controller installs forwarding state in the SFFs that lie on 468 the SFP. 470 Alternatively, a dynamic control plane may be used such as that 471 described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the 472 SFFs use the control plane to advertise the SFIs that they support, a 473 central controller computes the SFP and programs the Classifiers, and 474 (if the label swapping approach is taken) the central controller uses 475 the control plane to advertise the SFPs so that SFFs that lie on the 476 SFP can install the necessary forwarding state. 478 8. Use of the Entropy Label 480 Entropy is used in ECMP situations to ensure that packets from the 481 same flow travel down the same path, thus avoiding jitter or re- 482 ordering issues within a flow. 484 Entropy is often determined by hashing on specific fields in a packet 485 header such as the "five-tuple" in the IP and transport headers. 486 However, when an MPLS label stack is present, the depth of the stack 487 could be too large for some processors to correctly determine the 488 entropy hash. This problem is addressed by the inclusion of an 489 Entropy Label as described in [RFC6790]. 491 When entropy is desired for packets as they are carried in MPLS 492 tunnels over the underlay network, it is RECOMMENDED that an Entropy 493 Label is included in the label stack immediately after the tunnel 494 labels and before the SFC labels as shown in Figure 2 and Figure 3. 496 If an Entropy Label is present in a packet received by an SR-capabale 497 node (at the end of a tunnel across the underlay network), it is 498 RECOMMENDED that the value of that label is preserved and used in an 499 Entropy Label inserted in the label stack when the packet is 500 forwarded (on the next tunnel) to the next SFF. 502 If an Entropy Label is present in an MPLS payload, it is RECOMMENDED 503 that the initial Classifier use that value in an Entropy Label 504 inserted in the label stack when the packet is forwarded (on the 505 first tunnel) to the first SFF. In this case it is not necessary to 506 remove the Entropy Label from the payload. 508 9. Metadata 510 Metadata is defined in [RFC7665] as providing "the ability to 511 exchange context information between classifiers and SFs, and among 512 SFs." [I-D.ietf-sfc-nsh] defines how this context information can be 513 directly encoded in fields that form part of the NSH encapsulation. 515 The next two sections describe how metadata is associated with user 516 data packets, and how metadata may is exchanged between SFC nodes in 517 the network, when using an MPLS encoding of the logical 518 representation of the NSH. 520 9.1. Indicating Metadata in User Data Packets 522 Metadata is achieved in the MPLS realization of the logical NSH by 523 the use of an SFC Metadata Label which uses the Extended Special 524 Purpose Label construct [RFC7274]. Thus, three label stack entries 525 are present as shown in Figure 4: 527 o The Extension Label (value 15) 529 o An extended special purpose label called the Metadata Label 530 Indicator (MLI) (value TBD1 by IANA) 532 o The Metadata Label (ML). 534 ---------------- 535 | Extension = 15 | 536 +----------------+ 537 | MLI | 538 +----------------+ 539 | Metadata Label | 540 --------------- 542 Figure 4: The MPLS SFC Metadata Label 544 The Metadata Label value is an index into a table of metadata that is 545 programmed into the network using in-band or out-of-band mechanisms. 546 Out-of-band mechanisms potentially include management plane and 547 control plane solutions (such as 548 [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this 549 document. The in-band mechanism is described in Section 9.2 551 The SFC Metadata Label (as a set of three labels as indicated in 552 Figure 4) may be present zero, one, or more times in an MPLS SFC 553 packet. For MPLS label swapping, the SFC Metadata Labels are placed 554 immediately after the basic unit of MPLS label stack for SFC as shown 555 in Figure 5. For MPLS-SR, the SFC Metadata Labels can be present 556 zero, one, or more times and are placed at the bottom of the label 557 stack as shown in Figure 6. 559 ---------------- 560 ~ Tunnel Labels ~ 561 +----------------+ 562 ~ Optional ~ 563 ~ Entropy Label ~ 564 +----------------+ 565 | SPI Label | 566 +----------------+ 567 | SI Label | 568 +----------------+ 569 | Extension = 15 | 570 +----------------+ 571 | MLI | 572 +----------------+ 573 | Metadata Label | 574 +----------------+ 575 ~ Other ~ 576 | Metadata | 577 ~ Labels ~ 578 +----------------+ 579 | | 580 ~ Payload ~ 581 | | 582 ---------------- 584 Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata 585 Label 587 ------------------- 588 ~ MPLS-SR Labels ~ 589 +-------------------+ 590 ~ Optional ~ 591 ~ Entropy Label ~ 592 +-------------------+ 593 | SFC Context Label | 594 +-------------------+ 595 | SF Label | 596 +-------------------+ 597 ~ ~ 598 +-------------------+ 599 | SFC Context Label | 600 +-------------------+ 601 | SF Label | 602 +-------------------+ 603 | Extension = 15 | 604 +-------------------+ 605 | MLI | 606 +-------------------+ 607 | Metadata Label | 608 +-------------------+ 609 ~ Other ~ 610 | Metadata | 611 ~ Labels ~ 612 +-------------------+ 613 | | 614 ~ Payload ~ 615 | | 616 ------------------- 618 Figure 6: The MPLS SFC Label Stack for MPLS-SR with Metadata Label 620 9.2. Inband Programming of Metadata 622 A mechanism for sending metadata associated with an SFP without a 623 payload packet is described in [I-D.farrel-sfc-convent]. The same 624 approach can be used in an MPLS network where the NSH is logically 625 represented by an MPLS label stack. 627 The packet header is formed exactly as previously described in this 628 document so that the packet will follow the SFP through the SFC 629 network. However, instead of payload data, metadata is included 630 after the bottom of the MPLS label stack. An Extended Special 631 Purpose Label is used to indicate that the metadata is present. 632 Thus, three label stack entries are present: 634 o The Extension Label (value 15) 636 o An extended special purpose label called the Metadata Present 637 Indicator (MPI) (value TBD2 by IANA) 639 o The Metadata Label (ML) that is associated with this metadata on 640 this SFP and can be used to indicate the use of the metadata as 641 described in Section 9. 643 The SFC Metadata Present Label, if present, is placed immediately 644 after the last basic unit of MPLS label stack for SFC. The resultant 645 label stacks are shown in Figure 7 for the MPLS label swapping case 646 and Figure 8 for the MPLS-SR case. 648 --------------- 649 ~ Tunnel Labels ~ 650 +---------------+ 651 ~ Optional ~ 652 ~ Entropy Label ~ 653 +---------------+ 654 | SPI Label | 655 +---------------+ 656 | SI Label | 657 +---------------+ 658 | Extension = 15| 659 +---------------+ 660 | MPI | 661 +---------------+ 662 | Metadata Label| 663 +---------------+ 664 | | 665 ~ Metadata ~ 666 | | 667 --------------- 669 Figure 7: The MPLS SFC Label Stack Carrying Metadata 671 ------------------- 672 ~ MPLS-SR Labels ~ 673 +-------------------+ 674 ~ Optional ~ 675 ~ Entropy Label ~ 676 +-------------------+ 677 | SFC Context Label | 678 +-------------------+ 679 | SF Label | 680 +-------------------+ 681 | SFC Context Label | 682 +-------------------+ 683 | SF Label | 684 +-------------------+ 685 ~ ~ 686 +-------------------+ 687 | SFC Context Label | 688 +-------------------+ 689 | SF Label | 690 +-------------------+ 691 | Extension = 15 | 692 +-------------------+ 693 | MPI | 694 +-------------------+ 695 | Metadata Label | 696 +-------------------+ 697 | | 698 ~ Metadata ~ 699 | | 700 ------------------- 702 Figure 8: The MPLS SFC Label Stack for MPLS-SR Carrying Metadata 704 In both cases the metadata is formatted as a TLV as shown in 705 Figure 9. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Length | Metadata Type | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 ~ Metadata ~ 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 9: The Metadata TLV 717 The fields of this TLV are interpreted as follows: 719 Length: The length of the metadata carried in the Metadata field in 720 octets not including any padding. 722 Metadata Type: The type of the metadata present. Values for this 723 field are taken from the "MD Types" registry maintained by IANA 724 and defined in [I-D.ietf-sfc-nsh]. 726 Metadata: The actual metadata formatted as described in whatever 727 document defines the metadata. This field is end-padded with zero 728 to three octets of zeroes to take it up to a four octet boundary. 730 10. Worked Examples 732 Consider the simplistic MPLS SFC overlay network shown in Figure 10. 733 A packet is classified for an SFP that will see it pass through two 734 Service Functions, SFa and SFb, that are accessed through Service 735 Function Forwarders SFFa and SFFb respectively. The packet is 736 ultimately delivered to destination, D. 738 Let us assume that the SFP is computed and assigned the SPI of 239. 739 The forwarding details of the SFP are distributed (perhaps using the 740 mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs 741 are programmed with the necessary forwarding instructions. 743 The packet progresses as follows: 745 a. The Classifier assigns the packet to the SFP and imposes two 746 label stack entries comprising a single basic unit of MPLS SFC 747 representation: 749 * The higher label stack entry contains a label carrying the SPI 750 value of 239. 752 * The lower label stack entry contains a label carrying the SI 753 value of 255. 755 Further labels may be imposed to tunnel the packet from the 756 Classifier to SFFa. 758 b. When the packet arrives at SFFa it strips any labels associated 759 with the tunnel that runs from the Classifier to SFFa. SFFa 760 examines the top labels and matches the SPI/SI to identify that 761 the packet should be forwarded to SFa. The packet is forwarded 762 to SFa unmodified. 764 c. SFa performs its designated function and returns the packet to 765 SFFa. 767 d. SFFa modifies the SI in the lower label stack entry (to 254) and 768 uses the SPI/SI to look up the forwarding instructions. It sends 769 the packet with two label stack entries: 771 * The higher label stack entry contains a label carrying the SPI 772 value of 239. 774 * The lower label stack entry contains a label carrying the SI 775 value of 254. 777 Further labels may be imposed to tunnel the packet from the SFFa 778 to SFFb. 780 e. When the packet arrives at SFFb it strips any labels associated 781 with the tunnel from SFFa. SFFb examines the top labels and 782 matches the SPI/SI to identify that the packet should be 783 forwarded to SFb. The packet is forwarded to SFb unmodified. 785 f. SFb performs its designated function and returns the packet to 786 SFFb. 788 g. SFFb modifies the SI in the lower label stack entry (to 253) and 789 uses the SPI/SI to lookup up the forwarding instructions. It 790 determines that it is the last SFF in the SFP so it strips the 791 two SFC label stack entries and forwards the payload toward D 792 using the payload protocol. 794 +---------------------------------------------------+ 795 | MPLS SFC Network | 796 | | 797 | +---------+ +---------+ | 798 | | SFa | | SFb | | 799 | +----+----+ +----+----+ | 800 | ^ | | ^ | | | 801 | (b)| | |(c) (e)| | |(f) | 802 | (a) | | V (d) | | V (g) | 803 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 804 |Classifier+------+ SFFa +-------+ SFFb +------+ D | 805 +----------+ +---------+ +---------+ +-------+ 806 | | 807 +---------------------------------------------------+ 809 Figure 10: Service Function Chaining in an MPLS Network 811 Alternatively, consider the MPLS SFC overlay network shown in 812 Figure 11. A packet is classified for an SFP that will see it pass 813 through two Service Functions, SF1 and SF2, that are accessed through 814 Service Function Forwarders SFF1 and SFF2 respectively. The packet 815 is ultimately delivered to destination, D. 817 Let us assume that the SFP is computed and assigned the SPI of 239. 818 However, the forwarding state for the SFP is not distributed and 819 installed in the network. Instead it will be attached to the 820 individual packets using MPLS-SR. 822 The packet progresses as follows: 824 1. The Classifier assigns the packet to the SFP and imposes two 825 basic units of MPLS SFC representation to describe the full SFP: 827 * The top basic unit comprises two label stack entries as 828 follows: 830 + The higher label stack entry contains a label carrying the 831 SFC context. 833 + The lower label stack entry contains a label carrying the 834 SF indicator for SF1. 836 * The lower basic unit comprises two label stack entries as 837 follows: 839 + The higher label stack entry contains a label carrying the 840 SFC context. 842 + The lower label stack entry contains a label carrying the 843 SF indicator for SF2. 845 Further labels may be imposed to tunnel the packet from the 846 Classifier to SFF1. 848 2. When the packet arrives at SFF1 it strips any labels associated 849 with the tunnel from the Classifier. SFF1 examines the top 850 labels and matches the context/SF values to identify that the 851 packet should be forwarded to SF1. The packet is forwarded to 852 SF1 unmodified. 854 3. SF1 performs its designated function and returns the packet to 855 SFF1. 857 4. SFF1 strips the top basic unit of MPLS SFC representation 858 revealing the next basic unit. It then uses the revealed 859 context/SF values to determine how to route the packet to the 860 next SFF, SFF2. It sends the packet with just one basic unit of 861 MPLS SFC representation comprising two label stack entries: 863 * The higher label stack entry contains a label carrying the SFC 864 context. 866 * The lower label stack entry contains a label carrying the SF 867 indicator for SF2. 869 Further labels may be imposed to tunnel the packet from the SFF1 870 to SFF2. 872 5. When the packet arrives at SFF2 it strips any labels associated 873 with the tunnel from SFF1. SFF2 examines the top labels and 874 matches the context/SF values to identify that the packet should 875 be forwarded to SF2. The packet is forwarded to SF2 unmodified. 877 6. SF2 performs its designated function and returns the packet to 878 SFF2. 880 7. SFF2 strips the top basic unit of MPLS SFC representation 881 revealing the payload packet. It forwards the payload toward D 882 using the payload protocol. 884 +---------------------------------------------------+ 885 | MPLS-SR SFC Network | 886 | | 887 | +---------+ +---------+ | 888 | | SF1 | | SF2 | | 889 | +----+----+ +----+----+ | 890 | ^ | | ^ | | | 891 | (2)| | |(3) (5)| | |(6) | 892 | (1) | | V (4) | | V (7) | 893 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 894 |Classifier+------+ SFF1 +-------+ SFF2 +------+ D | 895 +----------+ +---------+ +---------+ +-------+ 896 | | 897 +---------------------------------------------------+ 899 Figure 11: Service Function Chaining in an MPLS-SR Network 901 11. Security Considerations 903 Discussion of the security properties of SFC networks can be found in 904 [RFC7665]. Further security discussion for the NSH and its use is 905 present in [I-D.ietf-sfc-nsh]. 907 It is fundamental to the SFC design that the classifier is a trusted 908 resource which determines the processing that the packet will be 909 subject to, including for example the firewall. It is also 910 fundamental to the Segment Routing design that packets are routed 911 through the network using the path specified by the node imposing the 912 SIDs. Where an SF is not encapsulation aware the packet may exist as 913 an IP packet, however this is an intrinsic part of the SFC design 914 which needs to define how a packet is protected in that environment. 915 Where a tunnel is used to link two non-MPLS domains, the tunnel 916 design needs to specify how it is secured. Thus the security 917 vulnerabilities are addressed in the underlying technologies used by 918 this design, which itself does not introduce any new security 919 vulnerabilities. 921 12. IANA Considerations 923 This document requests IANA to make allocations from the "Extended 924 Special-Purpose MPLS Label Values" subregistry of the "Special- 925 Purpose Multiprotocol Label Switching (MPLS) Label Values" registry 926 as follows: 928 Value | Description | 929 -------+-----------------------------------+-------------- 930 TBD1 | Metadata Label Indicator (MLI) | [This.I-D] 931 TBD2 | Metadata Present Indicator (MPI) | [This.I-D] 933 13. Acknowledgements 935 This document derives ideas and text from 936 [I-D.ietf-bess-nsh-bgp-control-plane]. 938 The authors are grateful to all those who contributed to the 939 discussions that led to this work: Loa Andersson, Andrew G. Malis, 940 Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart 941 Mackie, Keyur Patel, and Jim Guichard. 943 14. References 945 14.1. Normative References 947 [I-D.ietf-sfc-nsh] 948 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 949 Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress), 950 October 2017. 952 [I-D.ietf-spring-segment-routing-mpls] 953 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 954 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 955 data plane", draft-ietf-spring-segment-routing-mpls-10 956 (work in progress), June 2017. 958 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 959 Requirement Levels", BCP 14, RFC 2119, 960 DOI 10.17487/RFC2119, March 1997, 961 . 963 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 964 and Retiring Special-Purpose MPLS Labels", RFC 7274, 965 DOI 10.17487/RFC7274, June 2014, 966 . 968 14.2. Informative References 970 [I-D.farrel-sfc-convent] 971 Farrel, A. and J. Drake, "Operating the Network Service 972 Header (NSH) with Next Protocol "None"", draft-farrel-sfc- 973 convent-03 (work in progress), October 2017. 975 [I-D.ietf-bess-nsh-bgp-control-plane] 976 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 977 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 978 nsh-bgp-control-plane-01 (work in progress), September 979 2017. 981 [I-D.ietf-spring-segment-routing] 982 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 983 Litkowski, S., and R. Shakir, "Segment Routing 984 Architecture", draft-ietf-spring-segment-routing-13 (work 985 in progress), October 2017. 987 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 988 Label Switching Architecture", RFC 3031, 989 DOI 10.17487/RFC3031, January 2001, 990 . 992 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 993 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 994 RFC 6790, DOI 10.17487/RFC6790, November 2012, 995 . 997 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 998 Chaining (SFC) Architecture", RFC 7665, 999 DOI 10.17487/RFC7665, October 2015, 1000 . 1002 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1003 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1004 Packet Routing in Networking (SPRING) Problem Statement 1005 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1006 2016, . 1008 Authors' Addresses 1010 Adrian Farrel 1011 Juniper Networks 1013 Email: afarrel@juniper.net 1015 Stewart Bryant 1016 Huawei 1018 Email: stewart.bryant@gmail.com 1020 John Drake 1021 Juniper Networks 1023 Email: jdrake@juniper.net