RFC 9192

Network Service Header (NSH) Fixed-Length Context Header Allocation

📅 published February 2022, from ietf

RFC 9192: Network Service Header (NSH) Fixed-Length Context Header Allocation 💖

Okay bestie, RFC 9192 is giving Independent Submission 🦋. It's labelled Informational, so it's published for info and isn't a Standards Track spec ✨. It was written by T. Mizrahi (Huawei), I. Yerushalmi, D. Melman (Marvell), and R. Browne (Intel), and it's dated February 2022. The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so no drama there 🙈

Abstract

So the NSH spec gives you two ways to carry metadata: MD Type 0x1 and MD Type 0x2 🧚. MD Type 0x1 uses a fixed-length Context Header, and ngl, the structure and semantics of that Context Header never got standardized 😭. This doc fills that gap by defining the Timestamp Context Header, an NSH fixed-length Context Header that carries the packet's timestamp, a sequence number, and a source interface identifier ⏰.

Even though the IETF hasn't standardized this Context Header, several manufacturers have already built it into silicon, so it's published here to help with interoperability 💅.

Status of This Memo

This document is not an Internet Standards Track specification. It's just published for informational purposes 🌸.

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 💜.

Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc9192 🎀.

Copyright (c) 2022 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 read these carefully, because they describe your rights and restrictions with respect to this document 📜.

Table of Contents

   1.  Introduction
   2.  Terminology
     2.1.  Requirements Language
     2.2.  Abbreviations
   3.  NSH Timestamp Context Header Allocation
   4.  Timestamping Use Cases
     4.1.  Network Analytics
     4.2.  Alternate Marking
     4.3.  Consistent Updates
   5.  Synchronization Considerations
   6.  IANA Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction 🦋

The Network Service Header (NSH), defined in [RFC8300], is an encapsulation header. It's the service encapsulation used in the Service Function Chaining (SFC) architecture [RFC7665] ✨.

To share metadata (MD) along a service path, the NSH spec [RFC8300] gives you two methods: a fixed-length Context Header (MD Type 0x1) and a variable-length Context Header (MD Type 0x2). When you use MD Type 0x1, the NSH carries 16 octets of Context Header fields 💖.

Here's the tea ☕: the NSH spec [RFC8300] never defined the semantics of that 16-octet Context Header, and it doesn't say how NSH-aware Service Functions (SFs), Service Function Forwarders (SFFs), and proxies use it. Several Context Header formats are defined in [NSH-TLV]. Some allocation schemes were proposed in the past for specific use cases, e.g., [NSH-DC-ALLOC], [NSH-BROADBAND-ALLOC], and [RFC8592] 🍓.

This memo presents an allocation for the MD Type 0x1 Context Header, which incorporates the packet's timestamp, a sequence number, and a source interface identifier. Note that other allocation schema for MD Type 0x1 might be specified in the future. Although those schema aren't being standardized by the SFC Working Group right now, a consistent format (allocation schema) should be used in an SFC-enabled domain so that interoperability is possible 🫶.

In a nutshell, packets that enter the SFC-enabled domain get timestamped by a classifier [RFC7665]. So the timestamp, sequence number, and source interface all end up in the NSH Context Header. As discussed in [RFC8300], if reclassification is used, it may result in an update to the NSH metadata. Specifically, when the Timestamp Context Header is used, a reclassifier may either leave it unchanged or update the three fields: Timestamp, Sequence Number, and Source Interface 🔁.

The Timestamp Context Header has three fields that can be used for different things. The Timestamp field may be used for logging, troubleshooting, delay measurement, packet marking for performance monitoring, and timestamp-based policies ⏱️. The source interface identifier tells you which interface the packet came in through at the classifier. That identifier may specify a physical interface or a virtual one 🔌. The sequence numbers can be used by SFs to detect out-of-order delivery or duplicate transmissions 🔢.

Heads up: out-of-order and duplicate packet detection works when packets are received by the same SF. It's not necessarily possible when there are multiple instances of the same SF and packets are spread across those instances 👀. The sequence number is maintained on a per-source-interface basis.

This document presents the Timestamp Context Header but doesn't specify how the SFs that receive it should function. A few possible use cases are described here, but SF behavior and application are outside the scope of this document 🙅‍♀️.

Key Performance Indicator (KPI) stamping [RFC8592] defines an NSH timestamping mechanism that uses the MD Type 0x2 format. This memo defines a compact MD Type 0x1 Context Header that doesn't need the packet to be extended beyond the NSH 📦. Also, the mechanisms described in [RFC8592] and this memo can be used together, as further discussed in Section 4.1 👯‍♀️.

Once again, because it's so important: the definition of the Context Header in this document hasn't been standardized by the IETF, but it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability 💅.

2. Terminology 🧠

2.1. Requirements Language

Okay so here's the vibe 💜. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly as shown here 🎀.

2.2. Abbreviations

Here are the abbreviations used in this document 📚:

   KPI           Key Performance Indicator [RFC8592]

   MD            Metadata [RFC8300]

   NSH           Network Service Header [RFC8300]

   SF            Service Function [RFC7665]

   SFC           Service Function Chaining [RFC7665]

   SFF           Service Function Forwarder [RFC8300]

3. NSH Timestamp Context Header Allocation ✨

okay so this section is where the actual Context Header gets defined, and it's giving very "here is your fixed-length bag of goodies" energy 🎀 this memo defines the following fixed-length Context Header allocation, and you can see the layout in Figure 1 below 💖

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Interface                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: NSH Timestamp Allocation

the NSH Timestamp allocation defined in this memo MUST include the following fields 🌸

Sequence Number: a 32-bit sequence number 🦋 it's maintained on a per-source-interface basis, and sequence numbers can be used by SFs to detect out-of-order delivery or duplicate transmissions 👀 the classifier increments it by 1 for each packet received through the source interface, which means the classifier has to keep a per-source-interface counter 🧮 the sequence number gets initialized to a random number on startup, and after it reaches its maximal value (2^32-1) it wraps around back to zero 🔄

Source Interface: a 32-bit source interface identifier that's assigned by the classifier 💅 the combination of the source interface and the classifier identity is unique within the context of an SFC-enabled domain, so for an SF to use the source interface as a unique identifier, it needs to know the identity of the classifier for each packet 🫶 the source interface is unique in the context of the given classifier, so that's the vibe 🧚

Timestamp: a 64-bit field that specifies the time at which the packet was received by the classifier ⏰ there are two possible timestamp formats that can be used for this field: the two 64-bit recommended formats specified in [RFC8877] 💜 one is based on the timestamp format defined in [IEEE1588], and the other is based on the format defined in [RFC5905] ✨

ngl this is the part where you need to know which format your deployment is using, because mixing them up is not it 💀

the NSH specification [RFC8300] does not specify the possible coexistence of multiple MD Type 0x1 Context Header formats in a single SFC-enabled domain 🙈 it's assumed that the Timestamp Context Header will be deployed in an SFC-enabled domain that uniquely uses this Context Header format, so operators SHOULD ensure that either a consistent Context Header format is used in the SFC-enabled domain, or there is a clear policy that allows SFs to know the Context Header format of each packet 🌈 specifically, operators are expected to ensure the consistent use of a timestamp format across the whole SFC-enabled domain 📣

the two timestamp formats that can be used in the Timestamp field are as follows 🦋

Truncated Timestamp Format [IEEE1588]: this format is specified in Section 4.3 of [RFC8877] 📖 for the reader's convenience, it's illustrated in Figure 2 🌸

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Seconds                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Nanoseconds                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2: Truncated Timestamp Format (IEEE 1588)

NTP 64-bit Timestamp Format [RFC5905]: this format is specified in Section 4.2.1 of [RFC8877] 🎀 for the reader's convenience, it's illustrated in Figure 3 💫

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Seconds                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Fraction                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3: NTP 64-Bit Timestamp Format (RFC 5905)

synchronization aspects of the timestamp format in the context of the NSH Timestamp allocation are discussed in Section 5 🕰️

4. Timestamping Use Cases 🌈

4.1. Network Analytics 📊

per-packet timestamping enables coarse-grained monitoring of network delays along the Service Function Chain 🚀 once a potential problem or bottleneck is detected (for example, when the delay exceeds a certain policy), a highly granular monitoring mechanism can be triggered (for example, using the hop-by-hop measurement data defined in [RFC8592] or [IOAM-DATA]), which allows analysis and localization of the problem 🔍

timestamping is also useful for logging, troubleshooting, and flow analytics 📝 it's often useful to maintain the timestamp of the first and last packet of the flow 🏁 furthermore, traffic mirroring and sampling often require a timestamp to be attached to analyzed packets 🪞 attaching the timestamp to the NSH provides an in-band common time reference that can be used for various network analytics applications, which is seriously iconic 👑

4.2. Alternate Marking 🎨

a possible approach for passive performance monitoring is to use an Alternate-Marking Method [RFC8321] 🦄 this method requires data packets to carry a field that marks (colors) the traffic, and enables passive measurement of packet loss, delay, and delay variation 📉 the value of this marking field is periodically toggled between two values 🔁

when the timestamp is incorporated in the NSH, it can intrinsically be used for Alternate Marking 💖 for example, the least significant bit of the timestamp Seconds field can be used for this purpose, since the value of this bit is inherently toggled every second ⏱️

4.3. Consistent Updates 🔐

the timestamp can be used for making policy decisions, such as 'Perform action A if timestamp>=T_0' 🧠 this can be used for enforcing time-of-day policies or periodic policies in SFs 🌙 furthermore, timestamp-based policies can be used for enforcing consistent network updates, as discussed in [DPT] 🛠️ it should be noted that, as in the case of Alternate Marking, this use case alone does not require a full 64-bit timestamp but could be implemented with a significantly smaller number of bits 🤏

5. Synchronization Considerations ⏰

some of the applications that make use of the timestamp require the classifier and SFs to be synchronized to a common time reference -- for example, using the Network Time Protocol [RFC5905] or the Precision Time Protocol [IEEE1588] 🕒 although it is NOT a requirement to use a clock synchronization mechanism, it is expected that, depending on the applications that use the timestamp, such synchronization mechanisms will be used in most deployments that use the Timestamp allocation 🤝

wait, I need to be precise here: the original text says it is not a requirement to use clock sync, so don't read this as "you must sync" 🙃

6. IANA Considerations 📋

this document has no IANA actions 🌸

7. Security Considerations 🔒

the security considerations for the NSH in general are discussed in [RFC8300] 🛡️ the NSH is typically run within a confined trust domain 🏰 however, if a trust domain is not enough to provide the operator with protection against the timestamp threats as described below, then the operator SHOULD use transport-level protection between SFC processing nodes as described in [RFC8300] 🔐

the security considerations of in-band timestamping in the context of the NSH are discussed in [RFC8592]; this section is based on that discussion 📚

in-band timestamping, as defined in this document and [RFC8592], can be used as a means for network reconnaissance 🕵️‍♀️ by passively eavesdropping on timestamped traffic, an attacker can gather information about network delays and performance bottlenecks 😱 an on-path attacker can maliciously modify timestamps in order to attack applications that use the timestamp values, such as performance-monitoring applications 🚨

since the timestamping mechanism relies on an underlying time synchronization protocol, by attacking the time protocol an attack can potentially compromise the integrity of the NSH Timestamp 💀 a detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC7384] 📖

8. References 📚

8.1. Normative References 🎀

8.2. Informative References 📚

Okay, bestie, these are the extra reads that back up the story. Not strictly required to build the thing, but the receipts are right here 💅

Acknowledgments 🫶

The authors would like to give a huge shoutout to Mohamed Boucadair and Greg Mirsky 🌸 for their thorough reviews and detailed comments. Iconic behaviour, honestly.

Authors' Addresses 🦋

Tal Mizrahi
Huawei
Israel
Email: tal.mizrahi.phd@gmail.com


Ilan Yerushalmi
Marvell
6 Hamada
Yokneam 2066721
Israel
Email: yilan@marvell.com


David Melman
Marvell
6 Hamada
Yokneam 2066721
Israel
Email: davidme@marvell.com


Rory Browne
Intel
Dromore House
Shannon
Co. Clare
Ireland
Email: rory.browne@intel.com
📦 where this page comes from