Network Service Header (NSH) Fixed-Length Context Header AllocationHuaweiIsraeltal.mizrahi.phd@gmail.comMarvell6 HamadaYokneam2066721Israelyilan@marvell.comMarvell6 HamadaYokneam2066721Israeldavidme@marvell.comIntelDromore HouseShannonCo. ClareIrelandrory.browne@intel.comNSHContext HeadertimestampThe Network Service Header (NSH) specification defines two possible
methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type
0x1 uses a fixed-length Context Header. The allocation of this Context
Header, i.e., its structure and semantics, has not been standardized.
This memo defines the Timestamp Context Header, which is an
NSH fixed-length Context Header that incorporates the packet's
timestamp, a sequence number, and a source interface identifier.Although the definition of the Context Header presented
in this document has not been standardized by the IETF, it has been
implemented in silicon by several manufacturers and is published
here to facilitate interoperability.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
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
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. Terminology
. Requirements Language
. Abbreviations
. NSH Timestamp Context Header Allocation
. Timestamping Use Cases
. Network Analytics
. Alternate Marking
. Consistent Updates
. Synchronization Considerations
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
IntroductionThe Network Service Header (NSH), defined in ,
is an encapsulation header that is used as the
service encapsulation in the Service Function Chaining (SFC) architecture
.In order to share metadata (MD) along a service path, the NSH
specification supports two methods: a
fixed-length Context Header (MD Type 0x1) and a variable-length Context
Header (MD Type 0x2). When using MD Type 0x1, the NSH includes 16 octets
of Context Header fields.The NSH specification has not defined the
semantics of the 16-octet Context Header, nor does it specify how the Context Header is used by
NSH-aware Service Functions (SFs), Service Function Forwarders (SFFs), and proxies. Several Context Header
formats are defined in .
Furthermore, some allocation schemes were proposed in the past to
accommodate specific use cases, e.g., ,
,
and .This memo presents an allocation for the MD Type 0x1 Context Header,
which incorporates the timestamp of the packet, a sequence number, and a
source interface identifier. Note that other allocation schema for MD Type 0x1
might be specified in the future. Although such schema are currently not being
standardized by the SFC Working Group, a consistent format (allocation schema)
should be used in an SFC-enabled domain in order to allow interoperability.In a nutshell, packets that enter the SFC-enabled domain are
timestamped by a classifier . Thus, the
timestamp, sequence number, and source interface are incorporated in the
NSH Context Header. As discussed in , 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 includes three fields that may be used
for various purposes. The Timestamp field may be used for logging,
troubleshooting, delay measurement, packet marking for performance
monitoring, and timestamp-based policies. The source interface
identifier indicates the interface through which the packet was received
at the classifier. This identifier may specify a physical interface or a virtual
interface. The sequence numbers can be used by SFs
to detect out-of-order delivery or duplicate transmissions. Note that
out-of-order and duplicate packet detection is possible when packets are
received by the same SF but is not necessarily possible when there are
multiple instances of the same SF and multiple packets are spread across
different instances of the SF. The sequence number is maintained on a
per-source-interface basis.This document presents the Timestamp Context Header but does not
specify the functionality of the SFs that receive the Context Header.
Although a few possible use cases are described in this document, the SF
behavior and application are outside the scope of this document.Key Performance Indicator (KPI) stamping defines an NSH timestamping
mechanism that uses the MD Type 0x2 format. This memo defines a
compact MD Type 0x1 Context Header that does not require the packet to
be extended beyond the NSH. Furthermore, the mechanisms described in
and this memo can be used in concert, as further
discussed in .Although the definition of the Context Header presented
in this document has not been standardized by the IETF, it has been
implemented in silicon by several manufacturers and is published
here to facilitate interoperability.TerminologyRequirements LanguageThe 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
when, and only
when, they appear in all capitals, as shown here.AbbreviationsThe following abbreviations are used in this document:
KPI
Key Performance Indicator
MD
Metadata
NSH
Network Service Header
SF
Service Function
SFC
Service Function Chaining
SFF
Service Function Forwarder
NSH Timestamp Context Header AllocationThis memo defines the following fixed-length Context Header
allocation, as presented in .The NSH Timestamp allocation defined in this memo MUST
include the following fields:
Sequence Number:
A 32-bit sequence number. The sequence number
is maintained on a per-source-interface basis. Sequence numbers can
be used by SFs to detect out-of-order delivery or duplicate
transmissions. The classifier increments the sequence number by 1
for each packet received through the source interface. This requires
the classifier to maintain a per-source-interface counter. The
sequence number is initialized to a random number on startup. After
it reaches its maximal value (232-1), the sequence number wraps
around back to zero.
Source Interface:
A 32-bit source interface identifier that is
assigned by the classifier. The combination of the source interface
and the classifier identity is unique within the context of an
SFC-enabled domain. Thus, in order for an SF to be able to use the
source interface as a unique identifier, the identity of the
classifier needs to be known for each packet. The source interface
is unique in the context of the given classifier.
Timestamp:
A 64-bit field that specifies the time at
which the packet was received by the classifier. Two possible
timestamp formats can be used for this field: the two 64-bit
recommended formats specified in . One of
the formats is based on the timestamp format defined in , and
the other is based on the format defined in .
The NSH specification does not specify the
possible coexistence of multiple MD Type 0x1 Context Header formats in a
single SFC-enabled domain. It is assumed that the Timestamp Context
Header will be deployed in an SFC-enabled domain that uniquely uses this
Context Header format. Thus, 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 :
This format is specified in
. For the reader's
convenience, this format is illustrated in .
NTP 64-bit Timestamp Format :
This format
is specified in .
For the reader's convenience, this format is illustrated in
.
Synchronization aspects of the timestamp format in the context of the
NSH Timestamp allocation are discussed in .Timestamping Use CasesNetwork AnalyticsPer-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
or ),
allowing analysis and localization of the problem.Timestamping is also useful for logging, troubleshooting, and
flow analytics. It is 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.Alternate MarkingA possible approach for passive performance monitoring is to use an
Alternate-Marking Method . 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.Consistent UpdatesThe 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 . 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.Synchronization ConsiderationsSome 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 or the
Precision Time Protocol . 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.IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThe security considerations for the NSH in general are discussed in . 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 .The security considerations of in-band timestamping in the context of the
NSH are discussed in ; this section is
based on that discussion.In-band timestamping, as defined in this document and , 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 .ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Service Function Chaining (SFC) ArchitectureThis document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Network Service Header (NSH)This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).Guidelines for Defining Packet TimestampsVarious network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.Informative ReferencesThe Case for Data Plane Timestamping in SDNIEEE INFOCOM Workshop on Software-Driven Flexible and Agile Networking (SWFAN)IEEE 1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control SystemsIEEEData Fields for In-situ OAMWork in ProgressNSH Context Header Allocation for BroadbandCisco Systems, Inc.Individual ContributorNokiaNokiaOrangeWork in ProgressNetwork Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)Work in ProgressNetwork Service Header Metadata Type 2 Variable-Length Context HeadersZTE CorporationIntelIndividual contributorCiscoFuturewei TechnologiesWork in ProgressNetwork Time Protocol Version 4: Protocol and Algorithms SpecificationThe Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]Security Requirements of Time Protocols in Packet Switched NetworksAs time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.Alternate-Marking Method for Passive and Hybrid Performance MonitoringThis document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on an Alternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH)This document describes methods of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.AcknowledgmentsThe authors thank and for their thorough reviews and detailed comments.Authors' AddressesHuaweiIsraeltal.mizrahi.phd@gmail.comMarvell6 HamadaYokneam2066721Israelyilan@marvell.comMarvell6 HamadaYokneam2066721Israeldavidme@marvell.comIntelDromore HouseShannonCo. ClareIrelandrory.browne@intel.com