RFC 8596

MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)

📅 published June 2019, from ietf

RFC 8596 🎀 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)

Okay bestie, this is RFC 8596 from the Internet Engineering Task Force (IETF) 🌸 It came out in June 2019 and is marked Category: Informational, with ISSN 2070-1721. The authors are A. Malis and S. Bryant (both Futurewei), J. Halpern (Ericsson), and W. Henderickx (Nokia). The title block doesn't list anything this document obsoletes or updates, so it's standing on its own ✨

Abstract 💜

Okay so the big idea is this. The doc explains how to use an SFF Label (kinda like a pseudowire label or VPN label) to flag that an SFC Network Service Header (NSH) is sitting between an MPLS label stack and the original NSH packet/frame 🦋 That lets SFC packets carrying an NSH get forwarded between SFFs over an MPLS network. The label also helps pick which SFF to use when the destination MPLS node has more than one. It's giving efficient 💅

Status of This Memo 📜

Real talk, this one is not an Internet Standards Track spec. It's published for informational purposes 🧚

It's a product of the IETF and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the deets 🌈

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8596.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License ⚖️

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. MPLS Encapsulation Using an SFF Label ...........................3
      2.1. MPLS Label Stack Construction at the Sending Node ..........4
      2.2. SFF Label Processing at the Destination Node ...............5
   3. Equal-Cost Multipath (ECMP) Considerations ......................5
   4. Operations, Administration, and Maintenance (OAM)
      Considerations ..................................................6
   5. IANA Considerations .............................................6
   6. Security Considerations .........................................6
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................8
   Acknowledgements ...................................................9
   Authors' Addresses .................................................9

1. Introduction ✨

As discussed in [RFC8300], a bunch of transport encapsulations for the SFC Network Service Header (NSH) already exist, like Ethernet, UDP, GRE, and more 🍓

This doc describes an MPLS transport encapsulation for the NSH, plus how to use a Service Function Forwarder (SFF) [RFC7665] Label to signal that the NSH is in the MPLS packet payload 💜 It lets SFC packets carrying an NSH get forwarded between SFFs in an MPLS transport network, where MPLS is what connects the network nodes holding one or more SFFs. The label also selects among multiple SFFs in the destination MPLS node. Main character energy 👑

From an SFC point of view, this encapsulation is equivalent to the other transport encapsulations for NSH packets. You can see it by adding one more row to the next-hop SPI / SI-to-network ("SPI" and "SI" stand for "Service Path Identifier" and "Service Index") overlay network locator mapping in Table 1 of [RFC8300] 🦋

     +------+------+---------------------+-------------------------+
     | SPI  | SI   | Next Hop(s)         | Transport Encapsulation |
     +------+------+---------------------+-------------------------+
     | 25   | 220  | Label 5467          | MPLS                    |
     +------+------+---------------------+-------------------------+

                 Table 1: Extension to Table 1 in RFC 8300

SFF Labels are like the other service labels sitting at the bottom of an MPLS label stack. They say the MPLS payload is something other than a normally routed IP packet, such as a Layer 2 pseudowire, an IP packet routed in a VPN context with a private address, or an Ethernet virtual private wire service 🎀

This informational doc follows well-established MPLS procedures. It doesn't need any actions from IANA, and it doesn't add any new protocol extensions ✨

Also, using the MPLS label stack as a replacement for the SFC NSH, for use cases that don't need per-packet metadata, is covered in [RFC8595] 💅

1.1. Terminology 📖

Here's the vibe check on the key words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like this 🫶

2. MPLS Encapsulation Using an SFF Label 💖

The encapsulation is a standard MPLS label stack [RFC3032]. It has an SFF Label at the bottom, followed by an NSH as defined by [RFC8300], and then the NSH original packet/frame 🌈

Much like a pseudowire label, an SFF Label MUST be allocated by the downstream receiver of the NSH from its per-platform label space 🔥 The reason is that the meaning of the label stays the same no matter which incoming interface it arrives on [RFC3031].

If a receiving node supports more than one SFF (aka more than one SFC forwarding instance), the SFF Label can be used to pick the right SFF. The receiving node does this by advertising more than one SFF Label to its upstream sending nodes, as appropriate 👑

How the downstream receiving node advertises SFF Labels to the upstream sending node is out of scope for this doc. There are a bunch of options, though, like a protocol exchange, or a controller managing both the sender and the receiver with the Network Configuration Protocol (NETCONF) / YANG, BGP, the Path Computation Element Communication Protocol (PCEP), and so on. One BGP-based method is already defined in [BGP-NSH-SFC]. None of this stops anyone from defining other advertisement methods later 🧚

While the SFF Label usually sits at the bottom of the label stack, there can be extra label stack entries underneath it. For example, when an Associated Channel Header (ACH) is carried that applies to the SFF, a Generic Associated Channel Label (GAL) [RFC5586] ends up in the label stack below the SFF. Similarly, an Entropy Label Indicator / Entropy Label (ELI/EL) [RFC6790] can be carried below the SFF. This is the same situation you get with VPN labels 💜

This doc doesn't define how to set the Traffic Class (TC) field [RFC5462] in the SFF Label. (The TC field used to be called the Experimental Use (EXP) bits [RFC3032].) 🍓

2.1. MPLS Label Stack Construction at the Sending Node 🚀

When one SFF wants to send an SFC packet with an NSH to another SFF over an MPLS transport network, the MPLS node holding the sending SFF has to build a label stack. That stack gets the packet to the destination MPLS node holding the receiving SFF. Here's how the stack gets built 🦋

  1. Push zero or more labels that the destination MPLS node interprets onto the packet, such as the GAL [RFC5586] (see Section 4). The TTL for these labels is set according to the relevant standards that define those labels.
  2. Push the SFF Label to identify the desired SFF in the receiving MPLS node. The TTL for this MPLS label MUST be set to 1 to avoid mis-forwarding 🙈
  3. Push zero or more additional labels so that (a) the resulting label stack gets the packet transported to the destination MPLS node, and (b) when the packet arrives at the destination node, either:
    • the SFF Label is at the top of the label stack (this is typically the case when penultimate hop popping is used at the penultimate node), or
    • as part of normal MPLS processing, the SFF Label becomes the top label in the stack before the packet is forwarded to another node and before it gets dispatched to a higher layer.

The TTL for these labels is set by configuration, or set to the defaults for normal MPLS operation in the network 💖

3. Equal-Cost Multipath (ECMP) Considerations ✨

okay so ECMP is a whole conversation, bestie, and [RFC4928] and [RFC7325] both talk about it for payloads carried by MPLS 💅

Here's the tea: lots of existing routers like to do deep packet inspection 🕵️‍♀️ on the payload of an MPLS packet. If the first nibble of the payload is equal to 0x4 or 0x6, these routers (sometimes incorrectly, as discussed in [RFC4928]) assume the payload is IPv4 or IPv6, respectively. And then, as a result, they do ECMP load balancing based on (presumed) information in the IP/TCP/UDP payload headers, or in a combination of the MPLS label stack and (presumed) IP/TCP/UDP payload headers in the packet. Wild, right? 😭

For SFC, ECMP may or may not be desirable, so it depends on the vibe 🎀 To stop ECMP when nobody wants it, the NSH Base Header was carefully built so the NSH could not look like IPv4 or IPv6 based on its first nibble. See Section 2.2 of [RFC8300] for further details 🦋 So the default behavior for MPLS-encapsulated SFC is to not use ECMP other than by using entropy derived from the MPLS label stack. This results in all packets going to the same SF and taking the same path, regardless of whether ECMP is used in the network. Iconic consistency, honestly 👑

If ECMP is desired when SFC is used with an MPLS transport network, there are two possible options: entropy labels [RFC6790] and flow-aware transport [RFC6391] labels. A recommendation about choosing between these options, and where they go in the label stack, is left for future study 🌸

4. Operations, Administration, and Maintenance (OAM) Considerations 🧚

OAM at the SFC layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms such as the GAL [RFC5586] may be used at the transport label layer. Okay, that's a whole plan 💜

5. IANA Considerations 🍓

This document has no IANA actions. Nothing to register, bestie 💅

6. Security Considerations 🔥

⚠️ Read this part carefully, it's serious business! 💀

This document describes a method for transporting SFC packets using the NSH over an MPLS transport network. It follows well-established MPLS procedures in widespread operational use. It does not define any new protocol elements or allocate any new code points, and it is no more or less secure than carrying any other protocol over MPLS. To the MPLS network, the NSH and its contents are simply an opaque payload 🔒

In addition, the security considerations in [RFC8595] also apply to this document. So go read those too, no skipping 🙈

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

The authors would like to thank Jim Guichard, Eric Rosen, Med Boucadair, Alexander (Sasha) Vainshtein, Jeff Tantsura, Anoop Ghanwani, John Drake, Loa Andersson, Carlos Pignataro, Christian Hopps, and Benjamin Kaduk for their reviews and comments. Literal legends, all of them ✨

Authors' Addresses 💌

Andrew G. Malis Futurewei

Email: agmalis@gmail.com

Stewart Bryant Futurewei

Email: stewart.bryant@gmail.com

Joel M. Halpern Ericsson

Email: joel.halpern@ericsson.com

Wim Henderickx Nokia

Email: wim.henderickx@nokia.com

📦 where this page comes from