RFC 8393

Operating the Network Service Header (NSH) with Next Protocol "None"

📅 published May 2018, from ietf

RFC 8393 💖 Operating the Network Service Header (NSH) with Next Protocol "None"

Okay bestie, so RFC 8393 is titled Operating the Network Service Header (NSH) with Next Protocol "None" 🎀. It was written by A. Farrel and J. Drake, both at Juniper Networks, and it's an Internet Standards Track document, which means it's a real spec, not just a vibe. It was published in May 2018 and sits under ISSN 2070-1721 🧚. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Abstract ✨

This doc describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data, carrying only metadata 🍓. The trick is defining a brand new NSH "Next Protocol" value of "None" 💅.

The doc shows off some of the things this mechanism may achieve or improve, but it's not a full list of use cases, and it's not trying to be the final word on any of them 🦋. Other documents are expected to dig into specific use cases and define the protocol mechanics for each one 🫶.

Status of This Memo 📜

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🌈. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more about Internet Standards, check Section 2 of RFC 7841 🌸.

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8393 💜.

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) as they stand on the publication date 🧾. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
3.  The Network Service Header  . . . . . . . . . . . . . . . . .   4
  3.1.  Next Protocol "None"  . . . . . . . . . . . . . . . . . .   4
4.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .   4
5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .   5
6.  Overview of Use Cases . . . . . . . . . . . . . . . . . . . .   6
  6.1.  Per-SFP Metadata  . . . . . . . . . . . . . . . . . . . .   6
  6.2.  Per-Flow Metadata . . . . . . . . . . . . . . . . . . . .   7
  6.3.  Coordination between SFC-Aware SFIs . . . . . . . . . . .   7
  6.4.  Operations, Administration, and Maintenance (OAM) . . . .   8
  6.5.  Control-Plane and Management-Plane Uses . . . . . . . . .   8
  6.6.  Non-applicable Use Cases  . . . . . . . . . . . . . . . .   9
7.  Management and Congestion Control Considerations  . . . . . .   9
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
  10.2.  Informative References . . . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

So the SFC architecture is laid out in [RFC7665] 🌸. It lets packets get forwarded along Service Function Paths (SFPs) so they can pass through different Service Functions (SFs) that act on them 💅. Each packet gets wrapped in a Network Service Header (NSH) [RFC8300] 🎀. The NSH says which SFP the packet is on (that's the Service Path Identifier, or SPI) and where it is along that path (that's the Service Index, or SI, which points at the next SF to run) 🧚. Both the SPI and the SI are fields encoded in the NSH 🔥.

Classifiers at the SFC network ingress boundaries (Section 4.4 of [RFC7665]) sort packets and apply an NSH to them 🦋. Those packets then get passed between Service Function Forwarders (SFFs) through tunnels over the underlay network, and each SFF can hand the packet to one or more Service Function Instances (SFIs), depending on how the SFP is defined 🍓.

The SFC classifier or any SFC-aware SFI might want to share info (maybe state info) about the SFP, the traffic flow, or one specific packet 🫶. They can do that by adding metadata to the packet as part of the NSH 💜. That metadata can help SFC-aware SFs do their job better, let SFIs coordinate and swap data, or help a network operator diagnose and monitor an SFP 👑. What the metadata actually is depends on the implementation and the deployment 🌈.

This document defines a way to carry metadata on an SFP without needing any payload data ⭐. That's how you get diagnosis and monitoring of SFPs, plus coordination between SFC-aware SFIs 🎀. You can do it without traffic flowing at all. And if traffic is flowing, you don't have to cram possibly huge amounts of metadata into data packets, which can be expensive on some hardware 🙈.

Here's how it works: a new value for the NSH "Next Protocol" field, "None", signals that there's no payload 💖. Just like any other NSH packet, these stay inside the SFC-enabled domain 🧚.

This document also illustrates some of the functions this mechanism may achieve or enhance, but it's not an exhaustive list and it's not definitive about what it describes (see Section 6) ✨.

This document uses the terms defined in [RFC7665] and [RFC8300] 📜.

2. Requirements Language 🔑

Here's the deal with the keywords: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as BCP 14 [RFC2119] [RFC8174] says, but only when they show up in all capitals, exactly like this 💅. Lowercase versions are just regular English 🦋.

3. The Network Service Header 🎀

The NSH has a field called "Next Protocol" 🧚. Its job is to say what kind of payload data comes right after the NSH 🌸. Anything that processes the NSH can use it (for example, to figure out how to interpret and parse the payload) 🔥. The end nodes of the SFP that strip the NSH and forward the payload also use it 💜.

3.1. Next Protocol "None" 🌈

This doc defines a new value, 0x00, for the "Next Protocol" field, which means the next protocol is "None" 🍓. In plain terms, that means there's no user or payload data after the NSH ✨.

Even when the next protocol is "None", the rest of the NSH still matters 💖. The metadata in the NSH can still be there. A packet with "Next Protocol" set to "None" is not meant to be sent with no metadata (see Section 4) 🙈. So an SFC-aware node SHOULD NOT create a packet with "Next Protocol" set to 0x00, Metadata Type set to 0x2, and an NSH Length of 0x2 💀.

4. Processing Rules ⚙️

A packet with no payload data can be inserted at the head end of an SFP (like at a classifier) 🦋. An SFF or SFI on the SFP can forward it pretty easily, using the processing rules in [RFC8300] 🫶.

An SFC-aware SFI can also generate a packet with no payload as a result of processing an incoming packet 🎀. That means it's triggered by something that happens while handling a normal NSH packet with a payload 🔥. In that case, the SPI/SI can either be inherited from the original packet or set using info supplied in one of three ways 👑:

  • through the control plane,
  • through the management plane, or
  • through information carried in the metadata of the data packet.

This document doesn't go any further on what triggers an NSH packet with "Next Protocol" set to "None" 🙈.

Now, if an SFC-aware node wants to send metadata without a data packet (in other words, a node that follows this spec) 💖:

  • It MUST create a packet carrying an NSH and the desired metadata.
  • It MUST set the "Next Protocol" field to 0x00.
  • It SHOULD ensure that there are no bytes following the end of the NSH (meaning there's no payload data) 🌈.
  • It MUST encapsulate and send the packet as normal for tunneling to the next hop on the SFP, same as for any NSH packet (in other words, the same as a data packet following the SFP) 🧚.

A transit node (SFF, SFI, or classifier) that follows this spec and gets a packet with "Next Protocol" indicating "None" MUST NOT try to parse or process anything past the end of the NSH 😭. It SHOULD still process the NSH and the metadata as normal ✨. Nodes that don't support "Next Protocol" set to "None" are covered in Section 5 📜. Heads up though: an intermediate node told to strip all metadata from packets will end up with a packet that has an NSH but no metadata and no payload 🙈. Those packets SHOULD NOT keep going along the SFP 🛑.

The egress node of an SFP would normally strip the NSH and forward the payload based on the "Next Protocol" field 🎀. But these nodes MUST NOT forward packets with "Next Protocol" indicating "None", even if some bytes come after the NSH 💅.

If you're in a deployment where "None" isn't wanted, administrators SHOULD tell SFC-aware nodes not to create these packets, and to discard any packets with next protocol "None" 💀.

5. Backward Compatibility 🔄

SFC-aware nodes that don't understand what a value in the NSH "Next Protocol" field means can't parse the payload 🙃. These nodes quietly drop packets with unknown "Next Protocol" values, unless they've been explicitly configured to forward them (Section 2.2 of [RFC8300]) 🌸.

So legacy SFC-aware nodes that don't know what the "Next Protocol" value "None" means will act like this 👇:

  • SFFs can be configured to forward the packets.
  • SFC proxies will drop the packets.
  • SFIs will most likely drop the packets.
  • Classifiers (in other words, nodes doing reclassification) will most likely drop the packets.

SFC-aware nodes at the end of an SFP might forward packets without knowing anything about the payload 🧚. This is the "pop and forward" style: the NSH gets removed, the packet is put on an interface, and the payload protocol is already known a priori (or assumed) 🦋. There's also a general rule for all packet forwarding engines: they should not try to send packets with zero length 🙈. Packets with the NSH "Next Protocol" field set to "None" are expected to have zero payload length, so they should not get forwarded once the NSH is stripped 💖. And either way, as Section 4 said, SFC-aware nodes at the end of an SFP do not forward packets with "Next Protocol" set to "None" 🫶.

6. Overview of Use Cases 👑

6.1. Per-SFP Metadata ✨

okay so per-SFP metadata is metadata that applies to an SFP and every data packet riding on that SFP 🛣️ it doesn't have to be sent with every single packet 🙅‍♀️ instead it can be installed at the points of consumption (like at SFIs) and then applied to all the packets on the SFP as they pass through that spot 💅 it could get installed by putting it in the NSH of a data packet sent on the SFP through out-of-band control- or management-plane mechanisms 📦 or by sending separate metadata-only packets that use "Next Protocol" set to "None", which is what this document is all about 🦋

per-SFP metadata-only packets can be sent along an SFP's path just by setting the right SPI in the NSH and setting the SI to the right value for the hop where the metadata should get introduced 🧚 SFC-aware nodes (like classifiers) know which SI values to use from info given to them by the control or management plane, same as with NSH packets that carry payload data 🫶

6.2. Per-Flow Metadata 🌸

per-flow metadata is metadata that applies to just a subset of the packets on an SFP 🎀 like packets matching one particular 5-tuple of source address, destination address, source port, destination port, and payload protocol 💜 and again, this metadata doesn't need to ride along with every packet, but it can be installed at the SFIs on the SFP and applied to the packets that match the flow description ✨

if there's only one flow on an SFP, then per-flow metadata and per-SFP metadata (from Section 6.1) are basically the same thing 🙈

in normal processing, you can figure out which flow the per-flow metadata is for by looking at the payload data in the context of the "Next Protocol" value 🔍 but when "Next Protocol" says "None", you can't do that anymore 💀 so in this case the flow's identity gets carried inside the metadata itself 🫠

6.3. Coordination between SFC-Aware SFIs 🤝

a pair of SFC-aware SFIs (adjacent or not) on an SFP may want to coordinate state, and they can do that by sending info encoded in metadata 💌

to do this using the mechanisms defined in this document:

  • there must be an SFP that passes through the two SFIs in the direction from sender to receiver 🛣️
  • the sender must know the correct SPI to use 🔑
  • the sender must know the correct SI to use for the point where it sits on the SFP 📍
  • ideally, the receiver will know to pull the packet off the SFP and not forward it any further 🙌 because otherwise this might share metadata wider than desirable and create unnecessary packets in the network 😬 note, however, that continued forwarding of such packets would not be substantially harmful in its own right 🤷‍♀️

note that technically (according to the SFC architecture) inserting a packet into an SFP is done by a classifier 🧠 but a classifier can be co-resident with an SFI, so an SF implementation may also be able to generate NSH packets as described in this document 💅

also, a system with SFIs that need to coordinate with each other may be set up with a specific, dedicated SFP between those service functions that's used only for this purpose 👑 that way, such an SFI doesn't need to insert NSH packets onto SFPs that carry payload data, and it can use (and know the SPI of) this special, dedicated SFP 🌈

6.4. Operations, Administration, and Maintenance (OAM) 🛠️

requirements for Operations, Administration, and Maintenance (OAM) in SFC networks are discussed in [SFC-OAM-FRAME] 📚 and the NSH definition in [RFC8300] includes an O bit that indicates the packet contains OAM information 🚩

if OAM info is carried in packets that also include payload data, that info might sit between the NSH and the payload 🥪 so the mechanism in this document can also be used to carry OAM info independently of payload data ✨

sending OAM separately from (but interleaved with) packets that carry payload data can have a bunch of perks, including:

  • sending OAM when there's no other traffic flowing 🌙
  • sending OAM at predictable intervals 🗓️
  • measuring path qualities separately from how SFIs behave 📏
  • sending OAM without needing to rewrite payload data buffers 🙅‍♀️
  • keeping OAM processing components separate from other processing components 🧹

mechanisms for providing active OAM [RFC7799] in an SFC network have been proposed [OAM-SFC] 🔬 this use case isn't meant to define another mechanism for active OAM, but it does show a further option for the working group to discuss 💬

6.5. Control-Plane and Management-Plane Uses 🎛️

as described in Section 6.3, SFPs can be set up specifically to carry metadata-only packets 🛤️ and as described in Section 6.1, metadata-only packets can be sent down existing SFPs 🏃‍♀️ this means metadata-only packets can carry control-plane and management-plane messages used to control and manage the SFC network 🫶

basically, SFPs can be established to serve as a Data Control Network (DCN) or a Management Control Network (MCN) 🌐 further details of this process are out of scope for this document, but it should be understood that, just like for OAM, an essential feature of using a control channel is that the various speakers get assigned identifiers (i.e., addresses) 🪪 in this case, those identifiers could be SPI/SI pairs or they could be IP addresses, as used in the normal control and management plane of the SFC network 🧩

6.6. Non-applicable Use Cases 🚫

per-packet metadata is metadata that applies specifically to a single payload packet 🎯 it tells an SFI how to handle that payload packet and doesn't apply to any other packet 💅

the mechanisms described in this document aren't applicable to per-packet metadata because, by definition, if "Next Protocol" says "None", then there's no packet following the NSH for the metadata to be associated with 🙃

7. Management and Congestion Control Considerations ✨

the mechanisms described in this document let SFC-aware nodes in an SFC network generate additional packets 📨 these aren't meant to be sent frequently for any flow, but there's still a risk they could flood the network 🌊 for example, if someone tries to use this mechanism for "per-packet metadata" (see Section 6.6), then this might double the number of packets in the network 😱 similarly, if this mechanism is used for a form of aliveness detection OAM that needs very frequent test messages, then the number of additional messages may be very high 📈 those extra messages risk causing congestion in the network 🚦

the underlay network (that is, the tunnels across the underlay between SFC nodes) won't tell apart data-carrying packets from packets with "Next Protocol" set to "None" 🫥 all packets get treated the same and need to fall within the capabilities of the underlay network to process and forward them 📦

nodes in the SFC overlay network will need to do special processing on the additional packets, depending on their roles and on the application for the metadata 🧑‍💻 for example, an SFF will likely only have to forward per-SFP metadata, while an SF will need to extract it and process it the same way it would if the metadata were carried in a packet with user data 🍰 on the other hand, metadata might also be used to cause actions at all nodes (see Sections 6.3, 6.4, and 6.5), and that could increase the processing load 🏋️‍♀️

with all these potential issues in mind, all implementations SHOULD implement rate limits on the generation of per-SFP packets with "Next Protocol" set to "None" 🚧 furthermore, these rate limits SHOULD be configurable and applied per SFP and per application, so that one application on one SFP doesn't weigh down a different application on this or a different SFP 🙅‍♀️ when an implementation finds it can't generate or send a packet, it SHOULD increment a counter that's accessible by the operator, and it MAY raise an alert (although such alerts SHOULD, themselves, be rate limited) 🔔

additionally, an SFC node needs to protect itself against another node in the network that isn't applying suitable rate limits 🛡️ so implementations SHOULD apply incoming rate limits for SFC packets with "Next Protocol" set to "None" 📥 such rate limits MAY be application aware, per SFC or per interface, and SHOULD be configurable 🎚️ but implementations MAY be more subtle if they're aware of internal processing loads and have access to queues/buffers 🧠 in any case, when an implementation drops a received packet because of these rate limits, it SHOULD increment a counter that's accessible by the operator, and it MAY raise an alert (although such alerts SHOULD, themselves, be rate limited) 📉

suitable default rate limits will restrict an SFC node to not sending more than one packet with "Next Protocol" set to "None" per ten data packets on any flow, in a unit of time equal to the end-to-end delivery time on the flow ⏱️

8. Security Considerations 🔐

metadata-only packets enabled by this document provide a covert channel 🕵️‍♀️ but this is only different from the metadata feature in the normal NSH in that it can be sent without a data flow being present 🫣

metadata may, of course, contain sensitive data, and it may also contain info used to control the behavior of SFIs in the network 🎭 as such, this data needs to be protected according to its value and according to the perceived vulnerabilities of the network 🔒 protection of metadata may be achieved by using encrypted transport between SFC entities, or by encrypting the metadata itself and authenticating the sender of the metadata 🗝️ the need to protect the metadata isn't changed by this document and is part of the NSH definition found in [RFC8300] 💜

the mechanism described in this document might be used to introduce packets into the SFC overlay network, and it might be used to illegitimately introduce false metadata to the nodes on an SFC 🚨 this is serious bestie, no cap.

therefore, measures SHOULD be taken to ensure authorization of sources of such packets, and tunneling of such packets into the network SHOULD be prevented 🙅‍♀️🚫 the number of packets with "Next Protocol" set to "None" on an SFP SHOULD be rate limited at each point on the SFP for additional network security 🧱

further discussion of NSH security is presented in [RFC8300] 📖

9. IANA Considerations 📝

IANA maintains a registry called "Network Service Header (NSH) Parameters" with a sub-registry called "NSH Next Protocol" 🗂️ IANA has allocated a new value to the sub-registry as follows:

Next Protocol  |  Description  | Reference
---------------+---------------+-------------
0x00           |  None         | RFC 8393

10. References 📚

10.1. Normative References 🌷

10.2. Informative References 📚✨

Okay bestie, these are the bonus reads that back up the vibe, so you can go deeper whenever you want 💅

[OAM-SFC]  Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi-
           Layer Active OAM for Service Function Chains in Networks",
           Work in Progress, draft-wang-sfc-multi-layer-oam-10,
           September 2017.

[RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
           Chaining (SFC) Architecture", RFC 7665,
           DOI 10.17487/RFC7665, October 2015,
           <https://www.rfc-editor.org/info/rfc7665>.

[RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
           Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
           May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[SFC-OAM-FRAME]
           Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan,
           R., and A. Ghanwani, "Service Function Chaining (SFC)
           Operation, Administration and Maintenance (OAM)
           Framework", Work in Progress, draft-ietf-sfc-oam-
           framework-04, March 2018.

Acknowledgements 🫶

Huge thank-yous to everyone at the SFC interim meeting in Westford, Massachusetts, back in January 2017 🌸 Those conversations are literally why this document exists, so they deserve all the flowers.

Also a massive shoutout to Eric Rosen, Med Boucadair, Greg Mirsky, Dave Dolson, Tal Mizrahi, and Mirja Kuehlewind for reviewing the draft and leaving comments that actually made it better 💖

Contributors 🧚

Lucy Yong
Retired

Authors' Addresses 🎀

Adrian Farrel
Juniper Networks

Email: afarrel@juniper.net


John Drake
Juniper Networks

Email: jdrake@juniper.net

That's the whole thing, bestie! 🌈💜

📦 where this page comes from