--- 1/draft-ietf-mpls-sfc-00.txt 2018-05-15 03:13:10.275914791 -0700 +++ 2/draft-ietf-mpls-sfc-01.txt 2018-05-15 03:13:10.331916188 -0700 @@ -1,21 +1,21 @@ MPLS Working Group A. Farrel Internet-Draft Juniper Networks Intended status: Standards Track S. Bryant -Expires: September 29, 2018 Huawei +Expires: November 16, 2018 Huawei J. Drake Juniper Networks - March 28, 2018 + May 15, 2018 An MPLS-Based Forwarding Plane for Service Function Chaining - draft-ietf-mpls-sfc-00 + draft-ietf-mpls-sfc-01 Abstract Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in RFC7665. The Network Service Header (NSH) can be inserted into packets to steer them along a specific path to realize a Service Function Chain. @@ -42,21 +42,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 29, 2018. + This Internet-Draft will expire on November 16, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,38 +64,45 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 - 4. Basic Unit of Representation . . . . . . . . . . . . . . . . 4 - 5. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 6 - 6. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 8 - 7. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 10 - 8. A Note on Service Function Capabilities and SFC Proxies . . . 11 - 9. Control Plane Considerations . . . . . . . . . . . . . . . . 11 - 10. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 12 - 11. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.1. Indicating Metadata in User Data Packets . . . . . . . . 13 - 11.2. Inband Programming of Metadata . . . . . . . . . . . . . 15 - 12. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 18 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 16.2. Informative References . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5 + 4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5 + 4.3. Fine Control of Service Function Instances . . . . . . . 5 + 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6 + 4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6 + 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 + 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7 + 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 + 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12 + 9. A Note on Service Function Capabilities and SFC Proxies . . . 13 + 10. Control Plane Considerations . . . . . . . . . . . . . . . . 13 + 11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14 + 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15 + 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17 + 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20 + 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 18.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 18.2. Informative References . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in [RFC7665]. When applying a particular Service Function Chain to the traffic selected by a service classifier, the traffic needs to be steered @@ -132,29 +139,34 @@ in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. This approach is applicable to all forms of MPLS forwarding (where labels are looked up at each hop, and swapped or popped [RFC3031]). It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. The mechanisms described in this document are a compromise between the full function that can be achieved using the NSH, and the benefits of reusing the existing MPLS forwarding paradigms. + Section 4 provides a short overview of several use case scenarios + that help to explain the relationship between the MPLS label + operations (swapping, popping, stacking) and the MPLS encoding of the + logical NSH described in this document). + It is assumed that the reader is fully familiar with the terms and concepts introduced in [RFC7665] and [RFC8300]. Note that one of the features of the SFC architecture described in [RFC7665] is the "SFC proxy" that exists to include legacy SFs that are not able to process NSH-encapsulated packets. This issue is equally applicable to the use of MPLS-encapsulated packets that encode a logical representation of an NSH. It is discussed further - in Section 8. + in Section 9. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Choice of Data Plane SPI/SI Representation @@ -175,21 +187,98 @@ approach to achieve these objectives is provided using BGP in [I-D.ietf-bess-nsh-bgp-control-plane]. Note that the encoding of the SFC information is independent of the choice of tunneling technology used between SFFs. Thus, an MPLS representation of the logical NSH (as defined in this document) may be used even if the tunnel between a pair of SFFs is not an MPLS tunnel. Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH itself). -4. Basic Unit of Representation +4. Use Case Scenarios + + There are five scenarios that can be considered for the use of an + MPLS encoding in support of SFC. These are set out in the following + sub-sections. + +4.1. Label Swapping for Logical NSH + + The primary use case for SFC is described in [RFC7665] and delivered + using the NSH which, as described in [RFC8300], uses an encapsulation + with a position indicator that is modified at each SFC hop along the + chain to indicate the next hop. + + The label swapping use case scenario effectively replaces the NSH + with an MPLS encapsulation as described in Section 6. The MPLS + labels encode the same information as the NSH to form a logical NSH. + The labels are modified (swapped per [RFC3031]) at each SFC hop along + the chain to indicate the next hop. The processing and forwarding + state for a chain (i.e., the actions to take on a received label) are + programmed in to the network using a control plane or management + plane. + +4.2. Hierarchical Encapsulation + + [I-D.ietf-sfc-hierarchical] describes an architecture for + hierarchical encapsulation using the NSH. It facilitates + partitioning of SFC domains for administrative reasons, and allows + concatenation of service function chains under the control of a + service classifier. + + The same function can be achieved in an MPLS network using an MPLS + encoding of the logical NSH, and label stacking as defined in + [RFC3031] and described in Section 7. In this model, swapping is + used per Section 4.1 to navigate one chain, and when the end of the + chain is reached, the final label is popped revealing the label for + another chain. Thus, the primary mode is swapping, but stacking is + used to enable the ingress classifier to control concatenation of + service function chains. + +4.3. Fine Control of Service Function Instances + + It may be that a service function chain (as described in Section 4.1 + allows some leeway in the choice of service function instances along + the chain. However, it may be that a service classifier wishes to + constrain the choice and this can be achieved using chain + concatenation so that the first chain ends at the point of choice, + the next label in the stack indicates the specific service function + instance to be executed, and the next label in the stack starts a new + chain. Thus, a mixture of label swapping and stacking is used. + +4.4. Micro Chains and Label Stacking + + The scenario in Section 4.2 may be extended to its logical extreme by + making each concatenated chain as short as it can be: one service + function. Each label in the stack indicates the next service + function to be executed, and the network is programmed through the + control plane or management plane to know how to route to the next + (i.e., first) hop in each chain just as it would be to support the + scenarios in Section 4.1 and Section 4.2. + +4.5. SFC and Segment Routing + + Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a + stack of MPLS labels to encode information about the path and network + functions that a packet should traverse. MPLS-SR is achieved by + applying control plane and management plane techniques to program the + MPLS forwarding plane, and by imposing labels on packets at the + entrance to the MPLS-SR network. + + The application of SR to SFC was considered in early versions of the + SR architecture [I-D.ietf-spring-segment-routing] and the MPLS-SR + specification [I-D.ietf-spring-segment-routing-mpls], but has since + been moved out of those documents. An implementation proposal for + achieving SFC using MPLS-SR can be found in + [I-D.xuclad-spring-sr-service-chaining] and is not discussed further + in this document. + +5. Basic Unit of Representation When an MPLS label stack is used to carry a logical NSH, a basic unit of representation is used. This unit comprises two MPLS labels as shown below. The unit may be present one or more times in the label stack as explained in subsequent sections. In order to convey the same information as is present in the NSH, two MPLS label stack entries are used. One carries a label to provide context within the SFC scope (the SFC Context Label), and the other carries a label to show which service function is to be actioned (the @@ -203,85 +292,87 @@ | SF Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The Basic Unit of MPLS Label Stack for SFC The fields of these two label stack entries are encoded as follows: Label: The Label fields contain the values of the SFC Context Label and the SF Label encoded as 20 bit integers. The precise semantics of these label fields are dependent on whether the label - stack entries are used for MPLS label swapping (see Section 5) or - MPLS label stacking (see Section 6). + stack entries are used for MPLS label swapping (see Section 6) or + MPLS label stacking (see Section 7). TC: The TC bits have no meaning. They SHOULD be set to zero in both label stack entries when a packet is sent and MUST be ignored on receipt. S: The bottom of stack bit has its usual meaning in MPLS. It MUST be clear in the SFC Context label stack entry and MAY be set in the SF label stack entry depending on whether the label is the bottom of stack. TTL: The TTL field in the SFC Context label stack entry SHOULD be set to 1. The TTL in SF label stack entry (called the SF TTL) is - set according to its use for MPLS label swapping (see Section 5) - or MPLS label stacking (see Section 6 and is used to mitigate + set according to its use for MPLS label swapping (see Section 6) + or MPLS label stacking (see Section 7 and is used to mitigate packet loops. The sections that follow show how this basic unit of MPLS label stack may be used for SFC in the MPLS label swapping case and in the MPLS label stacking. For simplicity, these sections do not describe the - use of metadata: that is covered separately in Section 11. + use of metadata: that is covered separately in Section 12. -5. MPLS Label Swapping +6. MPLS Label Swapping This section describes how the basic unit of MPLS label stack for SFC - introduced in Section 4 is used when MPLS label swapping is in use. + introduced in Section 5 is used when MPLS label swapping is in use. + The use case scenario for this approach is introduced in Section 4.1. + As can be seen from Figure 2, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel technology does not need to be MPLS, but that is shown here for simplicity. An entropy label ([RFC6790]) may also be present as described in - Section 10 + Section 11 Under these labels (or other encapsulation) comes a single instance of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries provided in - Section 4 the following meanings are applied: + Section 5 the following meanings are applied: SPI Label: The Label field of the SFC Context label stack entry contains the value of the SPI encoded as a 20 bit integer. The semantics of the SPI is exactly as defined in [RFC8300]. Note that an SPI as defined by [RFC8300] can be encoded in 3 octets (i.e., 24 bits), but that the Label field allows for only 20 bits and reserves the values 0 though 15 as 'special purpose' labels [RFC7274]. Thus, a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. SI Label: The Label field of the SF label stack entry contains the value of the SI exactly as defined in [RFC8300]. Since the SI requires only 8 bits, and to avoid overlap with the 'special purpose' label range of 0 through 15 [RFC7274], the SI is carried in the top (most significant) 8 bits of the Label field with the low order 12 bits set to zero. - TC: The TC fields are as described in Section 4. + TC: The TC fields are as described in Section 5. - S: The S bits are as described in Section 4. + S: The S bits are as described in Section 5. TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 - as stated in Section 4. The TTL in SF label stack entry is + as stated in Section 5. The TTL in SF label stack entry is decremented once for each forwarding hop in the SFP, i.e., for each SFF transited, and so mirrors the TTL field in the NSH. --------------- ~ Tunnel Labels ~ +---------------+ ~ Optional ~ ~ Entropy Label ~ +---------------+ - - - | SPI Label | @@ -290,81 +381,83 @@ +---------------+ - - - | | ~ Payload ~ | | --------------- Figure 2: The MPLS SFC Label Stack The following processing rules apply to the Label fields: - o When a Classifier inserts a packet onto an SFP it sets the SPI + o When a classifier inserts a packet onto an SFP it sets the SPI Label to indicate the identity of the SFP, and sets the SI Label to indicate the first SF in the path. o When a component of the SFC system processes a packet it uses the SPI Label to identify the SFP and the SI Label to determine to which SFF or instance of an SF (an SFI) to deliver the packet. Under normal circumstances (with the exception of branching and reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the SPI Label value is preserved on all packets. The SI Label value is modified by SFFs and through reclassification to indicate the next hop along the SFP. The following processing rules apply to the TTL field of the SF label stack entry, and are derived from section 2.2 of [RFC8300]: - o When a Classifier places a packet onto an SFP it MUST set the TTL + o When a classifier places a packet onto an SFP it MUST set the TTL to a value between 1 and 255. It SHOULD set this according to the expected length of the SFP (i.e., the number of SFs on the SFP), but it MAY set it to a larger value according to local configuration. The maximum TTL value supported in an NSH is 63, and so the practical limit here may also be 63. o When an SFF receives a packet from any component of the SFC system - (Classifier, SFI, or another SFF) it MUST discard any packets with + (classifier, SFI, or another SFF) it MUST discard any packets with TTL set to zero. It SHOULD log such occurrences, but MUST apply rate limiting to any such logs. o An SFF MUST decrement the TTL by one each time it performs a forwarding lookup. o If an SFF decrements the TTL to zero it MUST NOT send the packet, and MUST discard the packet. It SHOULD log such occurrences, but MUST apply rate limiting to any such logs. o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF unmodified along with the SI (which may have been changed by local reclassification). - o If a Classifier along the SFP makes any change to the intended + o If a classifier along the SFP makes any change to the intended path of the packet including for looping, jumping, or branching (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the SI TTL of the packet. In particular, each component of the SFC system MUST NOT increase the SI TTL value otherwise loops may go undetected. -6. MPLS Label Stacking +7. MPLS Label Stacking This section describes how the basic unit of MPLS label stack for SFC - introduced in Section 4 is used when MPLS label stacking is used to - carry information about the SFP and SFs to be executed. As can be - seen in Figure 3, the top of the label stack comprises the labels - necessary to deliver the packet over the MPLS tunnel between SFFs. - Any MPLS encapsulation may be used. + introduced in Section 5 is used when MPLS label stacking is used to + carry information about the SFP and SFs to be executed. The use case + scenarios for this approach is introduced in Section 4. + + As can be seen in Figure 3, the top of the label stack comprises the + labels necessary to deliver the packet over the MPLS tunnel between + SFFs. Any MPLS encapsulation may be used. An entropy label ([RFC6790]) may also be present as described in - Section 10 + Section 11 Under these labels comes one of more instances of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the - fields of these label stack entries provided in Section 4 the + fields of these label stack entries provided in Section 5 the following meanings are applied: SFC Context Label: The Label field of the SFC Context label stack entry contains a label that delivers SFC context. This label may be used to indicate the SPI encoded as a 20 bit integer using the semantics of the SPI is exactly as defined in [RFC8300] and noting that in this case a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. This label may also be used to convey other SFC context-speific semantics such as indicating how to interpret the @@ -366,31 +459,30 @@ semantics of the SPI is exactly as defined in [RFC8300] and noting that in this case a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. This label may also be used to convey other SFC context-speific semantics such as indicating how to interpret the SF Label or how to forward the packet to the node that offers the SF. SF Label: The Label field of the SF label stack entry contains a value that identifies the next SFI to be actioned for the packet. - This label may be scoped globally or within the context of the preceding SFC Context Label and comes from the range 16 ... 2^20 - 1. - TC: The TC fields are as described in Section 4. + TC: The TC fields are as described in Section 5. - S: The S bits are as described in Section 4. + S: The S bits are as described in Section 5. TTL: The TTL fields in the SFC Context label stack entry SF label - stack entry SHOULD be set to 1 as stated in Section 4, but MAY be + stack entry SHOULD be set to 1 as stated in Section 5, but MAY be set to larger values if the label indicated a forwarding operation towards the node that hosts the SF. ------------------- ~ Tunnel Labels ~ +-------------------+ ~ Optional ~ ~ Entropy Label ~ +-------------------+ - - - | SFC Context Label | @@ -409,45 +501,52 @@ +-------------------+ - - - | | ~ Payload ~ | | ------------------- Figure 3: The MPLS SFC Label Stack for Label Stacking The following processing rules apply to the Label fields: - o When a Classifier inserts a packet onto an SFP it adds a stack + o When a classifier inserts a packet onto an SFP it adds a stack comprising one or more instances of the basic unit of MPLS label stack for SFC. Taken together, this stack defines the SFs to be actioned and so defines the SFP that the packet will traverse. o When a component of the SFC system processes a packet it uses the top basic unit of label stack for SFC to determine to which SFI to next deliver the packet. When an SFF receives a packet it examines the top basic unit of MPLS label stack for SFC to determine where to send the packet next. If the next recipient is a local SFI, the SFC strips the basic unit of MPLS label stack for SFC before forwarding the packet. -7. Mixed Mode Forwarding +8. Mixed Mode Forwarding The previous sections describe homogeneous networks where SFC forwarding is either all label swapping or all label popping - (stacking). But it is also possible that different parts of the - network utilize swapping or popping. It is also worth noting that a - Classifier may be content to use an SFP as installed in the network + (stacking). This simplification helps to clarify the explanation of + the mechanisms. + + However, as described in Section 4.2, some uses cases may use label + swapping and stacking at the same time. Furthermore, it is also + possible that different parts of the network utilize swapping or + popping such that an end-to-end service chain has to utilize a + combination of both techniques. It is also worth noting that a + classifier may be content to use an SFP as installed in the network by a control plane or management plane and so would use label swapping, but that there may be a point in the SFP where a choice of SFIs can be made (perhaps for load balancing) and where, in this - instance, the Classifier wishes to exert control over that choice by - use of a specific entry on the label stack. + instance, the classifier wishes to exert control over that choice by + use of a specific entry on the label stack as described in + Section 4.3. When an SFF receives a packet containing an MPLS label stack, it checks whether it is processing an {SFP, SI} label pair for label swapping or a {context label, SFI index} label pair for label stacking. It then selects the appropriate SFI to which to send the packet. When it receives the packet back from the SFI, it has four cases to consider. o If the current hop requires an {SFP, SI} and the next hop requires an {SFP, SI}, it sets the SI label to the SI value of the current @@ -464,124 +563,124 @@ stack. * If the new top of the MPLS label stack contains an {SFP, SI} label pair, it selects an SFI to use at the next hop, and tunnels the packet to SFF for that SFI. * If the top of the MPLS label stack contains a {context label, SFI label}, it tunnels the packet to the SFF indicated by the context label. -8. A Note on Service Function Capabilities and SFC Proxies +9. A Note on Service Function Capabilities and SFC Proxies - The concept of an "SFC Proxy" is introduced in [RFC7665]. An SFC - Proxy is logically located between an SFF and an SFI that is not + The concept of an "SFC proxy" is introduced in [RFC7665]. An SFC + proxy is logically located between an SFF and an SFI that is not "SFC-aware". Such SFIs are not capable of handling the SFC encapsulation (whether that be NSH or MPLS) and need the encapsulation stripped from the packets they are to process. In many cases, legacy SFIs that were once deployed as "bumps in the wire" fit into this category until they have been upgraded to be SFC-aware. - The job of an SFC Proxy is to remove and then reimpose SFC + The job of an SFC proxy is to remove and then reimpose SFC encapsulation so that the SFF is able to process as though it was communication with an SFC-aware SFI, and so that the SFI is unaware - of the SFC encapsulation. In this regard, the job of an SFC Proxy is + of the SFC encapsulation. In this regard, the job of an SFC proxy is no different when NSH encapsulation is used and when MPLS encapsulation is used as described in this document, although (of course) it is different encapsulation bytes that must be removed and reimposed. - It should be noted that the SFC Proxy is a logical function. It + It should be noted that the SFC proxy is a logical function. It could be implemented as a separate physical component on the path from the SFF to SFI, but it could be coresident with the SFF or it could be a component of the SFI. This is purely an implementation choice. - Note also that the delivery of metadata (see Section 11) requires - specific processing if an SFC Proxy is in use. This is also no + Note also that the delivery of metadata (see Section 12) requires + specific processing if an SFC proxy is in use. This is also no different when NSH or the MPLS encoding defined in this document is in use, and how it is handled will depend on how (or if) each non- SFC-aware SFI can receive metadata. -9. Control Plane Considerations +10. Control Plane Considerations In order that a packet may be forwarded along an SFP several functional elements must be executed. o Discovery/advertisement of SFIs. o Computation of SFP. - o Programming of Classifiers. + o Programming of classifiers. o Advertisement of forwarding instructions. Various approaches may be taken. These include a fully centralized model where SFFs report to a central controller the SFIs that they support, the central controller computes the SFP and programs the - Classifiers, and (if the label swapping approach is taken) the + classifiers, and (if the label swapping approach is taken) the central controller installs forwarding state in the SFFs that lie on the SFP. Alternatively, a dynamic control plane may be used such as that described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the SFFs use the control plane to advertise the SFIs that they support, a - central controller computes the SFP and programs the Classifiers, and + central controller computes the SFP and programs the classifiers, and (if the label swapping approach is taken) the central controller uses the control plane to advertise the SFPs so that SFFs that lie on the SFP can install the necessary forwarding state. -10. Use of the Entropy Label +11. Use of the Entropy Label Entropy is used in ECMP situations to ensure that packets from the same flow travel down the same path, thus avoiding jitter or re- ordering issues within a flow. Entropy is often determined by hashing on specific fields in a packet header such as the "five-tuple" in the IP and transport headers. However, when an MPLS label stack is present, the depth of the stack could be too large for some processors to correctly determine the entropy hash. This problem is addressed by the inclusion of an Entropy Label as described in [RFC6790]. When entropy is desired for packets as they are carried in MPLS tunnels over the underlay network, it is RECOMMENDED that an Entropy Label is included in the label stack immediately after the tunnel labels and before the SFC labels as shown in Figure 2 and Figure 3. If an Entropy Label is present in an MPLS payload, it is RECOMMENDED - that the initial Classifier use that value in an Entropy Label + that the initial classifier use that value in an Entropy Label inserted in the label stack when the packet is forwarded (on the first tunnel) to the first SFF. In this case it is not necessary to remove the Entropy Label from the payload. -11. Metadata +12. Metadata Metadata is defined in [RFC7665] as providing "the ability to exchange context information between classifiers and SFs, and among SFs." [RFC8300] defines how this context information can be directly encoded in fields that form part of the NSH encapsulation. The next two sections describe how metadata is associated with user data packets, and how metadata may be exchanged between SFC nodes in the network, when using an MPLS encoding of the logical representation of the NSH. It should be noted that the MPLS encoding is slightly less functional than the direct use of the NSH. Both methods support metadata that - is "per-SFP" or "per-packet-flow" (see [I-D.farrel-sfc-convent] for - definitions of these terms), but "per-packet" metadata (where the - metadata must be carried on each packet because it differs from one - packet to the next even on the same flow or SFP) is only supported - using the NSH and not using the mechanisms defined in this document. + is "per-SFP" or "per-packet-flow" (see [RFC8393] for definitions of + these terms), but "per-packet" metadata (where the metadata must be + carried on each packet because it differs from one packet to the next + even on the same flow or SFP) is only supported using the NSH and not + using the mechanisms defined in this document. -11.1. Indicating Metadata in User Data Packets +12.1. Indicating Metadata in User Data Packets Metadata is achieved in the MPLS realization of the logical NSH by the use of an SFC Metadata Label which uses the Extended Special Purpose Label construct [RFC7274]. Thus, three label stack entries are present as shown in Figure 4: o The Extension Label (value 15) o An extended special purpose label called the Metadata Label Indicator (MLI) (value TBD1 by IANA) @@ -593,24 +692,25 @@ +----------------+ | MLI | +----------------+ | Metadata Label | --------------- Figure 4: The MPLS SFC Metadata Label The Metadata Label value is an index into a table of metadata that is programmed into the network using in-band or out-of-band mechanisms. + Out-of-band mechanisms potentially include management plane and control plane solutions (such as [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this - document. The in-band mechanism is described in Section 11.2 + document. The in-band mechanism is described in Section 12.2 The SFC Metadata Label (as a set of three labels as indicated in Figure 4) may be present zero, one, or more times in an MPLS SFC packet. For MPLS label swapping, the SFC Metadata Labels are placed immediately after the basic unit of MPLS label stack for SFC as shown in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be present zero, one, or more times and are placed at the bottom of the label stack as shown in Figure 6. ---------------- @@ -668,42 +768,42 @@ ~ Label Triples ~ +-------------------+ | | ~ Payload ~ | | ------------------- Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata Label -11.2. Inband Programming of Metadata +12.2. Inband Programming of Metadata A mechanism for sending metadata associated with an SFP without a - payload packet is described in [I-D.farrel-sfc-convent]. The same - approach can be used in an MPLS network where the NSH is logically - represented by an MPLS label stack. + payload packet is described in [RFC8393]. The same approach can be + used in an MPLS network where the NSH is logically represented by an + MPLS label stack. The packet header is formed exactly as previously described in this document so that the packet will follow the SFP through the SFC network. However, instead of payload data, metadata is included after the bottom of the MPLS label stack. An Extended Special Purpose Label is used to indicate that the metadata is present. Thus, three label stack entries are present: o The Extension Label (value 15) o An extended special purpose label called the Metadata Present Indicator (MPI) (value TBD2 by IANA) o The Metadata Label (ML) that is associated with this metadata on this SFP and can be used to indicate the use of the metadata as - described in Section 11. + described in Section 12. The SFC Metadata Present Label, if present, is placed immediately after the last basic unit of MPLS label stack for SFC. The resultant label stacks are shown in Figure 7 for the MPLS label swapping case and Figure 8 for the MPLS label stacking case. --------------- ~ Tunnel Labels ~ +---------------+ ~ Optional ~ @@ -780,50 +880,55 @@ octets not including any padding. Metadata Type: The type of the metadata present. Values for this field are taken from the "MD Types" registry maintained by IANA and defined in [RFC8300]. Metadata: The actual metadata formatted as described in whatever document defines the metadata. This field is end-padded with zero to three octets of zeroes to take it up to a four octet boundary. -12. Worked Examples +13. Worked Examples + + This section reverts to the simplified descriptions of networks that + rely wholly on label swapping or label stacking. As described in + Section 4, actual deployment scenarios may depend on the use of both + mechanisms and utilize a mixed mode as described in Section 8. Consider the simplistic MPLS SFC overlay network shown in Figure 10. A packet is classified for an SFP that will see it pass through two Service Functions, SFa and SFb, that are accessed through Service Function Forwarders SFFa and SFFb respectively. The packet is ultimately delivered to destination, D. Let us assume that the SFP is computed and assigned the SPI of 239. The forwarding details of the SFP are distributed (perhaps using the mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs are programmed with the necessary forwarding instructions. The packet progresses as follows: - a. The Classifier assigns the packet to the SFP and imposes two + a. The classifier assigns the packet to the SFP and imposes two label stack entries comprising a single basic unit of MPLS SFC representation: * The higher label stack entry contains a label carrying the SPI value of 239. * The lower label stack entry contains a label carrying the SI value of 255. Further labels may be imposed to tunnel the packet from the - Classifier to SFFa. + classifier to SFFa. b. When the packet arrives at SFFa it strips any labels associated - with the tunnel that runs from the Classifier to SFFa. SFFa + with the tunnel that runs from the classifier to SFFa. SFFa examines the top labels and matches the SPI/SI to identify that the packet should be forwarded to SFa. The packet is forwarded to SFa unmodified. c. SFa performs its designated function and returns the packet to SFFa. d. SFFa modifies the SI in the lower label stack entry (to 254) and uses the SPI/SI to look up the forwarding instructions. It sends the packet with two label stack entries: @@ -874,21 +979,21 @@ Service Function Forwarders SFFx and SFFy respectively. The packet is ultimately delivered to destination, D. Let us assume that the SFP is computed and assigned the SPI of 239. However, the forwarding state for the SFP is not distributed and installed in the network. Instead it will be attached to the individual packets using the MPLS label stack. The packet progresses as follows: - 1. The Classifier assigns the packet to the SFP and imposes two + 1. The classifier assigns the packet to the SFP and imposes two basic units of MPLS SFC representation to describe the full SFP: * The top basic unit comprises two label stack entries as follows: + The higher label stack entry contains a label carrying the SFC context. + The lower label stack entry contains a label carrying the SF indicator for SFx. @@ -896,24 +1001,24 @@ * The lower basic unit comprises two label stack entries as follows: + The higher label stack entry contains a label carrying the SFC context. + The lower label stack entry contains a label carrying the SF indicator for SFy. Further labels may be imposed to tunnel the packet from the - Classifier to SFFx. + classifier to SFFx. 2. When the packet arrives at SFFx it strips any labels associated - with the tunnel from the Classifier. SFFx examines the top + with the tunnel from the classifier. SFFx examines the top labels and matches the context/SF values to identify that the packet should be forwarded to SFx. The packet is forwarded to SFx unmodified. 3. SFx performs its designated function and returns the packet to SFFx. 4. SFFx strips the top basic unit of MPLS SFC representation revealing the next basic unit. It then uses the revealed context/SF values to determine how to route the packet to the @@ -951,21 +1056,58 @@ | (2)| | |(3) (5)| | |(6) | | (1) | | V (4) | | V (7) | +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ |Classifier+------+ SFFx +-------+ SFFy +------+ D | +----------+ +---------+ +---------+ +-------+ | | +---------------------------------------------------+ Figure 11: Service Function Chaining Using MPLS Label Stacking -13. Security Considerations +14. Implementation Notes + + It is not the job of an IETF specification to describe the internals + of an implementation except where that directly impacts upon the bits + on the wire that change the likelihood of interoperability, or where + the availability of configuration or security options directly affect + the utility of an implementation. + + However, in view of the objective of this document to acknowledge + that there may be a need for an interim deployment of SFC + functionality in brownfield MPLS networks, this section provides some + observations about how an SFF might utilize MPLS features that are + available in existing routers. This section is not intended to be + definitive or technically complete, but is indicative. + + Consider the mechanism used to indicate to which Virtual Routing and + Forwarding (VRF) an incoming MPLS packet should be routed in a Layer + 3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top + MPLS label is an indicator of the VRF that is to be used to route the + payload. + + A similar approach can be taken with the label swapping SFC technique + described in Section 6 such that the SFC Context Label identifies a + routing table specific to the SFP. The SF Label can be looked up in + the context of this routing table to determine to which SF to direct + the packet, and how to forward it to the next SFF. + + Advanced features (such as metadata) are not inspected by SFFs. The + packets are passed to SFIs that are MPLS-SFC-aware or to SFC proxies, + and those components are responsible for handling all metadata + issues. + + Of course, an actual implementation might make considerable + optimizations on this approach, but this section should provide hints + about how MPLS-based SFC might be achieved with relatively small + modifications to deployed MPLS devices. + +15. Security Considerations Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is present in [RFC8300]. It is fundamental to the SFC design that the classifier is a trusted resource which determines the processing that the packet will be subject to, including for example the firewall. It is also fundamental to the MPLS design that packets are routed through the network using the path specified by the node imposing the labels, and @@ -976,86 +1118,124 @@ the SFC design which needs to define how a packet is protected in that environment. Additionally, where a tunnel is used to link two non-MPLS domains, the tunnel design needs to specify how the tunnel is secured. Thus the security vulnerabilities are addressed (or should be addressed) in all the underlying technologies used by this design, which itself does not introduce any new security vulnerabilities. -14. IANA Considerations +16. IANA Considerations This document requests IANA to make allocations from the "Extended Special-Purpose MPLS Label Values" subregistry of the "Special- Purpose Multiprotocol Label Switching (MPLS) Label Values" registry as follows: Value | Description | -------+-----------------------------------+-------------- TBD1 | Metadata Label Indicator (MLI) | [This.I-D] TBD2 | Metadata Present Indicator (MPI) | [This.I-D] -15. Acknowledgements +17. Acknowledgements This document derives ideas and text from [I-D.ietf-bess-nsh-bgp-control-plane]. The authors are grateful to all those who contributed to the discussions that led to this work: Loa Andersson, Andrew G. Malis, Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments. - Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, and Mach Chen - for reviews of this text. + Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, + and Mach Chen for reviews of this text. -16. References + The authors would like to be able to thank the authors of + [I-D.xuclad-spring-sr-service-chaining] and + [I-D.ietf-spring-segment-routing] whose original work on service + chaining and the identification of services using SIDs, and + conversation with whom helped clarify the application of MPLS-SR to + SFC. -16.1. Normative References + Particular thanks to Loa Andersson for conversations and advice about + working group process. - [I-D.farrel-sfc-convent] - Farrel, A. and J. Drake, "Operating the Network Service - Header (NSH) with Next Protocol "None"", draft-farrel-sfc- - convent-06 (work in progress), February 2018. +18. References + +18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . -16.2. Informative References + [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service + Header (NSH) with Next Protocol "None"", RFC 8393, + DOI 10.17487/RFC8393, May 2018, + . + +18.2. Informative References [I-D.ietf-bess-nsh-bgp-control-plane] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- nsh-bgp-control-plane-03 (work in progress), March 2018. + [I-D.ietf-sfc-hierarchical] + Dolson, D., Homma, S., Lopez, D., and M. Boucadair, + "Hierarchical Service Function Chaining (hSFC)", draft- + ietf-sfc-hierarchical-08 (work in progress), April 2018. + + [I-D.ietf-spring-segment-routing] + Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., + Litkowski, S., and R. Shakir, "Segment Routing + Architecture", draft-ietf-spring-segment-routing-15 (work + in progress), January 2018. + + [I-D.ietf-spring-segment-routing-mpls] + Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., + Litkowski, S., and R. Shakir, "Segment Routing with MPLS + data plane", draft-ietf-spring-segment-routing-mpls-13 + (work in progress), April 2018. + + [I-D.xuclad-spring-sr-service-chaining] + Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, + d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., + Henderickx, W., and S. Salsano, "Segment Routing for + Service Chaining", draft-xuclad-spring-sr-service- + chaining-01 (work in progress), March 2018. + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February + 2006, . + [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, .