rfc9192.original   rfc9192.txt 
Network Working Group T. Mizrahi Independent Submission T. Mizrahi
Internet-Draft Huawei Request for Comments: 9192 Huawei
Intended status: Informational I.Y. Yerushalmi Category: Informational I. Yerushalmi
Expires: 23 June 2022 D.M. Melman ISSN: 2070-1721 D. Melman
Marvell Marvell
R.B. Browne R. Browne
Intel Intel
20 December 2021 February 2022
Network Service Header (NSH) Fixed-Length Context Header Allocation: Network Service Header (NSH) Fixed-Length Context Header Allocation
Timestamp
draft-mymb-sfc-nsh-allocation-timestamp-12
Abstract Abstract
The Network Service Header (NSH) specification defines two possible The Network Service Header (NSH) specification defines two possible
methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD 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 Type 0x1 uses a fixed-length Context Header. The allocation of this
Context Header, i.e., its structure and semantics, has not been Context Header, i.e., its structure and semantics, has not been
standardized. This memo presents an allocation for the fixed Context standardized. This memo defines the Timestamp Context Header, which
Headers of NSH, which incorporates the packet's timestamp, a sequence is an NSH fixed-length Context Header that incorporates the packet's
number, and a source interface identifier. timestamp, a sequence number, and a source interface identifier.
Although the allocation that is presented in this document has not Although the definition of the Context Header presented in this
been standardized by the IETF it has been implemented in silicon by document has not been standardized by the IETF, it has been
several manufacturers and is published here to allow other implemented in silicon by several manufacturers and is published here
interoperable implementations and to facilitate debugging if it is to facilitate interoperability.
seen in the network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 23 June 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9192.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations
3. NSH Timestamp Context Header Allocation . . . . . . . . . . . 4 3. NSH Timestamp Context Header Allocation
4. Timestamping Use Cases . . . . . . . . . . . . . . . . . . . 6 4. Timestamping Use Cases
4.1. Network Analytics . . . . . . . . . . . . . . . . . . . . 7 4.1. Network Analytics
4.2. Alternate Marking . . . . . . . . . . . . . . . . . . . . 7 4.2. Alternate Marking
4.3. Consistent Updates . . . . . . . . . . . . . . . . . . . 7 4.3. Consistent Updates
5. Synchronization Considerations . . . . . . . . . . . . . . . 8 5. Synchronization Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
1. Introduction 1. Introduction
The Network Service Header (NSH), defined in [RFC8300], is an The Network Service Header (NSH), defined in [RFC8300], is an
encapsulation header that is used as the service encapsulation in the encapsulation header that is used as the service encapsulation in the
Service Function Chains (SFC) architecture [RFC7665]. Service Function Chaining (SFC) architecture [RFC7665].
In order to share metadata along a service path, the NSH In order to share metadata (MD) along a service path, the NSH
specification [RFC8300] supports two methods: a fixed-length Context specification [RFC8300] supports two methods: a fixed-length Context
Header (MD Type 0x1) and a variable-length Context Header (MD Type 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 0x2). When using MD Type 0x1, the NSH includes 16 octets of Context
Header fields. Header fields.
The NSH specification [RFC8300] has not defined the semantics of the The NSH specification [RFC8300] has not defined the semantics of the
16-octet Context Header, nor how it is used by NSH-aware service 16-octet Context Header, nor does it specify how the Context Header
functions, SFFs and proxies. Several context header formats are is used by NSH-aware Service Functions (SFs), Service Function
defined in [I-D.ietf-sfc-nsh-tlv]. Furthermore, some allocation Forwarders (SFFs), and proxies. Several Context Header formats are
schemes were proposed in the past to acoommodate specific use cases, defined in [NSH-TLV]. Furthermore, some allocation schemes were
e.g., [I-D.ietf-sfc-nsh-dc-allocation], proposed in the past to accommodate specific use cases, e.g.,
[I-D.ietf-sfc-nsh-broadband-allocation], and [RFC8592]. [NSH-DC-ALLOC], [NSH-BROADBAND-ALLOC], and [RFC8592].
This memo presents an allocation for the MD Type 0x1 Context Header, This memo presents an allocation for the MD Type 0x1 Context Header,
which incorporates the timestamp of the packet, a sequence number, which incorporates the timestamp of the packet, a sequence number,
and a source interface identifier. It is noted that other MD Type and a source interface identifier. Note that other allocation schema
0x1 allocations might be specified in the future. Although MD Type for MD Type 0x1 might be specified in the future. Although such
0x1 allocations are currently not being standardized by the SFC schema are currently not being standardized by the SFC Working Group,
working group, a consistent format (allocation) should be used in an a consistent format (allocation schema) should be used in an SFC-
SFC-enabled domain in order to allow interoperability. enabled domain in order to allow interoperability.
In a nutshell, packets that enter the SFC-enabled domain are In a nutshell, packets that enter the SFC-enabled domain are
timestamped by a Classifier [RFC7665]. Thus, the timestamp, sequence timestamped by a classifier [RFC7665]. Thus, the timestamp, sequence
number and source interface are incorporated in the NSH Context number, and source interface are incorporated in the NSH Context
Header. As defined in [RFC8300], if reclassification is used, it may Header. As discussed in [RFC8300], if reclassification is used, it
result in an update to the NSH metadata. Specifically, when the may result in an update to the NSH metadata. Specifically, when the
Timestamp Context Header is used, a reclassifier may either leave it Timestamp Context Header is used, a reclassifier may either leave it
unchanged, or update the three fields: timestamp, sequence number and unchanged or update the three fields: Timestamp, Sequence Number, and
source interface. Source Interface.
The Timestamp Context Header includes three fields that may be used The Timestamp Context Header includes three fields that may be used
for various purposes. The timestamp field may be used for logging, for various purposes. The Timestamp field may be used for logging,
troubleshooting, delay measurement, packet marking for performance troubleshooting, delay measurement, packet marking for performance
monitoring, and timestamp-based policies. The source interface monitoring, and timestamp-based policies. The source interface
identifier indicates the interface through which the packet was identifier indicates the interface through which the packet was
received at the classifier. This identifier may specify a physical received at the classifier. This identifier may specify a physical
or a virtual interface. The sequence numbers can be used by Service interface or a virtual interface. The sequence numbers can be used
Functions (SFs) to detect out-of-order delivery or duplicate by SFs to detect out-of-order delivery or duplicate transmissions.
transmissions. Note that out-of-order and duplicate packet detection Note that out-of-order and duplicate packet detection is possible
is possible when packets are received by the same SF, but is not when packets are received by the same SF but is not necessarily
necessarily possible when there are multiple instances of the same SF possible when there are multiple instances of the same SF and
and multiple packets are spread across different instances of the SF. multiple packets are spread across different instances of the SF.
The sequence number is maintained on a per-source-interface basis. The sequence number is maintained on a per-source-interface basis.
This document presents the Timestamp Context Header, but does not This document presents the Timestamp Context Header but does not
specify the functionality of the SFs that receive the Context Header. specify the functionality of the SFs that receive the Context Header.
Although a few possible use cases are described in the document, the Although a few possible use cases are described in this document, the
SF behavior and application are outside the scope of this document. SF behavior and application are outside the scope of this document.
KPI-stamping [RFC8592] defines an NSH timestamping mechanism that Key Performance Indicator (KPI) stamping [RFC8592] defines an NSH
uses the MD Type 0x2 format. The current memo defines a compact MD timestamping mechanism that uses the MD Type 0x2 format. This memo
Type 0x1 Context Header that does not require the packet to be defines a compact MD Type 0x1 Context Header that does not require
extended beyond the NSH header. Furthermore, the mechanisms of the packet to be extended beyond the NSH. Furthermore, the
[RFC8592] and of this memo can be used in concert, as further mechanisms described in [RFC8592] and this memo can be used in
discussed in Section 4.1. concert, as further discussed in Section 4.1.
Although the allocation that is presented in this document has not Although the definition of the Context Header presented in this
been standardized by the IETF it has been implemented in silicon by document has not been standardized by the IETF, it has been
several manufacturers and is published here to allow other implemented in silicon by several manufacturers and is published here
interoperable implementations and to facilitate debugging if it is to facilitate interoperability.
seen in the network.
2. Terminology 2. Terminology
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
KPI Key Performance Indicators [RFC8592] KPI Key Performance Indicator [RFC8592]
NSH Network Service Header [RFC8300]
MD Metadata [RFC8300] MD Metadata [RFC8300]
NSH Network Service Header [RFC8300]
SF Service Function [RFC7665] SF Service Function [RFC7665]
SFC Service Function Chaining [RFC7665] SFC Service Function Chaining [RFC7665]
SFF Service Function Forwarder [RFC8300]
3. NSH Timestamp Context Header Allocation 3. NSH Timestamp Context Header Allocation
This memo defines the following fixed-length Context Header This memo defines the following fixed-length Context Header
allocation, as presented in Figure 1. allocation, as presented in Figure 1.
0 1 2 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 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 | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Interface | | Source Interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NSH Timestamp Allocation. Figure 1: NSH Timestamp Allocation
The NSH Timestamp Allocation that is defined in this memo MUST The NSH Timestamp allocation defined in this memo MUST include the
include the following fields: following fields:
* Sequence Number - a 32-bit sequence number. The sequence number Sequence Number: A 32-bit sequence number. The sequence number is
is maintained on a per-source-interface basis. Sequence numbers maintained on a per-source-interface basis. Sequence numbers can
can be used by SFs to detect out-of-order delivery, or duplicate be used by SFs to detect out-of-order delivery or duplicate
transmissions. The Classifier increments the sequence number by 1 transmissions. The classifier increments the sequence number by 1
for each packet received through the source interface. This for each packet received through the source interface. This
requires the classifier to maintain a per-source-interface requires the classifier to maintain a per-source-interface
counter. The sequence number is initialized to a random number on counter. The sequence number is initialized to a random number on
startup. After it reaches its maximal value (2^32-1) the sequence startup. After it reaches its maximal value (2^32-1), the
number wraps around back to zero. sequence number wraps around back to zero.
* Source Interface - a 32-bit source interface identifier that is Source Interface: A 32-bit source interface identifier that is
assigned by the Classifier. The combination of the source assigned by the classifier. The combination of the source
interface and the classifier identity is unique within the context 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 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 use the source interface as a unique identifier, the identity of
the classifier needs to be known for each packet. The source the classifier needs to be known for each packet. The source
interface is unique in the context of the given classifier. interface is unique in the context of the given classifier.
* Timestamp - this field is 64 bits long, and specifies the time at Timestamp: A 64-bit field that specifies the time at which the
which the packet was received by the Classifier. Two possible packet was received by the classifier. Two possible timestamp
timestamp formats can be used for this field: the two 64-bit formats can be used for this field: the two 64-bit recommended
recommended formats specified in [RFC8877]. One of the formats is formats specified in [RFC8877]. One of the formats is based on
based on the [IEEE1588] timestamp format, and the other is based the timestamp format defined in [IEEE1588], and the other is based
on the [RFC5905] format. on the format defined in [RFC5905].
The NSH specification [RFC8300] does not specify the possible The NSH specification [RFC8300] does not specify the possible
coexistence of multiple MD Type 0x1 Context Header formats in a coexistence of multiple MD Type 0x1 Context Header formats in a
single SFC-enabled domain. It is assumed that the Timestamp Context single SFC-enabled domain. It is assumed that the Timestamp Context
Header will be deployed in an SFC-enabled domain that uniquely uses Header will be deployed in an SFC-enabled domain that uniquely uses
this Context Header format. Thus, operators SHOULD ensure that this Context Header format. Thus, operators SHOULD ensure that
either a consistent Context Header format is used in the SFC-enabled either a consistent Context Header format is used in the SFC-enabled
domain, or that there is a clear policy that allows SFs to know the domain or there is a clear policy that allows SFs to know the Context
Context Header format of each packet. Specifically, operators are Header format of each packet. Specifically, operators are expected
expected to ensure the consistent use of a timestamp format across to ensure the consistent use of a timestamp format across the whole
the whole SFC-enabled domain. SFC-enabled domain.
The two timestamp formats that can be used in the timestamp field The two timestamp formats that can be used in the Timestamp field are
are: as follows:
* IEEE 1588 Truncated Timestamp Format: this format is specified in Truncated Timestamp Format [IEEE1588]: This format is specified in
Section 4.3 of [RFC8877]. For the reader's convenience this Section 4.3 of [RFC8877]. For the reader's convenience, this
format is illustrated in Figure 2. format is illustrated in Figure 2.
0 1 2 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 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 | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nanoseconds | | Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IEEE 1588 Truncated Timestamp Format [IEEE1588]. Figure 2: Truncated Timestamp Format (IEEE 1588)
* NTP [RFC5905] 64-bit Timestamp Format: this format is specified in NTP 64-bit Timestamp Format [RFC5905]: This format is specified in
Section 4.4 of [RFC8877]. For the reader's convenience this Section 4.2.1 of [RFC8877]. For the reader's convenience, this
format is illustrated in Figure 3. format is illustrated in Figure 3.
0 1 2 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 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 | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP [RFC5905] 64-bit Timestamp Format Figure 3: NTP 64-Bit Timestamp Format (RFC 5905)
Synchronization aspects of the timestamp format in the context of the Synchronization aspects of the timestamp format in the context of the
NSH timestamp allocation are discussed in Section 5. NSH Timestamp allocation are discussed in Section 5.
4. Timestamping Use Cases 4. Timestamping Use Cases
4.1. Network Analytics 4.1. Network Analytics
Per-packet timestamping enables coarse-grained monitoring of the Per-packet timestamping enables coarse-grained monitoring of network
network delay along the Service Function Chain. Once a potential delays along the Service Function Chain. Once a potential problem or
problem or bottleneck is detected, for example when the delay exceeds bottleneck is detected (for example, when the delay exceeds a certain
a certain policy, a highly-granular monitoring mechanism can be policy), a highly granular monitoring mechanism can be triggered (for
triggered, for example using the hop-by-hop measurement data of example, using the hop-by-hop measurement data defined in [RFC8592]
[RFC8592] or [I-D.ietf-ippm-ioam-data], allowing to analyze and or [IOAM-DATA]), allowing analysis and localization of the problem.
localize the problem.
Timestamping is also useful for logging, troubleshooting and for flow Timestamping is also useful for logging, troubleshooting, and flow
analytics. It is often useful to maintain the timestamp of the first analytics. It is often useful to maintain the timestamp of the first
and last packet of the flow. Furthermore, traffic mirroring and and last packet of the flow. Furthermore, traffic mirroring and
sampling often requires a timestamp to be attached to analyzed sampling often require a timestamp to be attached to analyzed
packets. Attaching the timestamp to the NSH provides an in-band packets. Attaching the timestamp to the NSH provides an in-band
common time reference that can be used for various network analytics common time reference that can be used for various network analytics
applications. applications.
4.2. Alternate Marking 4.2. Alternate Marking
A possible approach for passive performance monitoring is to use an A possible approach for passive performance monitoring is to use an
alternate marking method [RFC8321]. This method requires data Alternate-Marking Method [RFC8321]. This method requires data
packets to carry a field that marks (colors) the traffic, and enables packets to carry a field that marks (colors) the traffic, and enables
passive measurement of packet loss, delay, and delay variation. The passive measurement of packet loss, delay, and delay variation. The
value of this marking field is periodically toggled between two value of this marking field is periodically toggled between two
values. values.
When the timestamp is incorporated in the NSH, it can natively be When the timestamp is incorporated in the NSH, it can intrinsically
used for alternate marking. For example, the least significant bit be used for Alternate Marking. For example, the least significant
of the timestamp Seconds field can be used for this purpose, since bit of the timestamp Seconds field can be used for this purpose,
the value of this bit is inherently toggled every second. since the value of this bit is inherently toggled every second.
4.3. Consistent Updates 4.3. Consistent Updates
The timestamp can be used for taking policy decisions such as The timestamp can be used for making policy decisions, such as
'Perform action A if timestamp>=T_0'. This can be used for enforcing 'Perform action A if timestamp>=T_0'. This can be used for enforcing
time-of-day policies or periodic policies in service functions. time-of-day policies or periodic policies in SFs. Furthermore,
Furthermore, timestamp-based policies can be used for enforcing timestamp-based policies can be used for enforcing consistent network
consistent network updates, as discussed in [DPT]. It should be updates, as discussed in [DPT]. It should be noted that, as in the
noted that, as in the case of Alternate Marking, this use case alone case of Alternate Marking, this use case alone does not require a
does not require a full 64-bit timestamp, but could be implemented full 64-bit timestamp but could be implemented with a significantly
with a significantly smaller number of bits. smaller number of bits.
5. Synchronization Considerations 5. Synchronization Considerations
Some of the applications that make use of the timestamp require the Some of the applications that make use of the timestamp require the
Classifier and SFs to be synchronized to a common time reference, for classifier and SFs to be synchronized to a common time reference --
example using the Network Time Protocol [RFC5905] or the Precision for example, using the Network Time Protocol [RFC5905] or the
Time Protocol [IEEE1588]. Although it is not a requirement to use a Precision Time Protocol [IEEE1588]. Although it is not a requirement
clock synchronization mechanism, it is expected that depending on the to use a clock synchronization mechanism, it is expected that,
applications that use the timestamp, such synchronization mechanisms depending on the applications that use the timestamp, such
will be used in most deployments that use the timestamp allocation. synchronization mechanisms will be used in most deployments that use
the Timestamp allocation.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
7. Security Considerations 7. Security Considerations
The security considerations of NSH in general are discussed in The security considerations for the NSH in general are discussed in
[RFC8300]. NSH is typically run within a confined trust domain. [RFC8300]. The NSH is typically run within a confined trust domain.
However, if a trust domain is not enough to provide the operator with However, if a trust domain is not enough to provide the operator with
the protection against the timestamp threats described below, then protection against the timestamp threats as described below, then the
the operator SHOULD use transport-level protection between SFC operator SHOULD use transport-level protection between SFC processing
processing nodes as described in [RFC8300]. nodes as described in [RFC8300].
The security considerations of in-band timestamping in the context of The security considerations of in-band timestamping in the context of
NSH is discussed in [RFC8592], and the current section is based on the NSH are discussed in [RFC8592]; this section is based on that
that discussion. discussion.
The use of in-band timestamping, as defined in this document, can be In-band timestamping, as defined in this document and [RFC8592], can
used as a means for network reconnaissance. By passively be used as a means for network reconnaissance. By passively
eavesdropping to timestamped traffic, an attacker can gather eavesdropping on timestamped traffic, an attacker can gather
information about network delays and performance bottlenecks. A man- information about network delays and performance bottlenecks. An on-
in-the-middle attacker can maliciously modify timestamps in order to path attacker can maliciously modify timestamps in order to attack
attack applications that use the timestamp values, such as applications that use the timestamp values, such as performance-
performance monitoring applications. monitoring applications.
Since the timestamping mechanism relies on an underlying time Since the timestamping mechanism relies on an underlying time
synchronization protocol, by attacking the time protocol an attack synchronization protocol, by attacking the time protocol an attack
can potentially compromise the integrity of the NSH timestamp. A can potentially compromise the integrity of the NSH Timestamp. A
detailed discussion about the threats against time protocols and how detailed discussion about the threats against time protocols and how
to mitigate them is presented in [RFC7384]. to mitigate them is presented in [RFC7384].
8. Acknowledgments 8. References
The authors thank Mohamed Boucadair and Greg Mirsky for their
thorough reviews and detailed comments.
9. References 8.1. Normative References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
skipping to change at page 9, line 30 skipping to change at line 375
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", RFC 8877, Defining Packet Timestamps", RFC 8877,
DOI 10.17487/RFC8877, September 2020, DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/info/rfc8877>. <https://www.rfc-editor.org/info/rfc8877>.
9.2. Informative References 8.2. Informative References
[DPT] Mizrahi, T., Moses, Y., "The Case for Data Plane [DPT] Mizrahi, T. and Y. Moses, "The Case for Data Plane
Timestamping in SDN", IEEE INFOCOM Workshop on Software- Timestamping in SDN", IEEE INFOCOM Workshop on Software-
Driven Flexible and Agile Networking (SWFAN), 2016. Driven Flexible and Agile Networking (SWFAN), DOI 10.1109/
INFCOMW.2016.7562197, 2016,
<https://ieeexplore.ieee.org/abstract/document/7562197>.
[I-D.ietf-ippm-ioam-data] [IEEE1588] IEEE, "IEEE 1588-2008 - IEEE Standard for a Precision
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Clock Synchronization Protocol for Networked Measurement
for In-situ OAM", Work in Progress, Internet-Draft, draft- and Control Systems",
ietf-ippm-ioam-data-17, 13 December 2021, <https://standards.ieee.org/standard/1588-2008.html>.
<https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
data-17.txt>.
[I-D.ietf-sfc-nsh-broadband-allocation] [IOAM-DATA]
Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In-situ OAM", Work in Progress,
Internet-Draft, draft-ietf-ippm-ioam-data-17, 13 December
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
ippm-ioam-data-17>.
[NSH-BROADBAND-ALLOC]
Napper, J., Kumar, S., Muley, P., Hendericks, W., and M. Napper, J., Kumar, S., Muley, P., Hendericks, W., and M.
Boucadair, "NSH Context Header Allocation for Broadband", Boucadair, "NSH Context Header Allocation for Broadband",
Work in Progress, Internet-Draft, draft-ietf-sfc-nsh- Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-
broadband-allocation-01, 19 June 2018, broadband-allocation-01, 19 June 2018,
<https://www.ietf.org/archive/id/draft-ietf-sfc-nsh- <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-
broadband-allocation-01.txt>. broadband-allocation-01>.
[I-D.ietf-sfc-nsh-dc-allocation] [NSH-DC-ALLOC]
Guichard, J., Smith, M., Kumar, S., Majee, S., and T. Guichard, J., Ed., Smith, M., Kumar, S., Majee, S., and T.
Mizrahi, "Network Service Header (NSH) MD Type 1: Context Mizrahi, "Network Service Header (NSH) MD Type 1: Context
Header Allocation (Data Center)", Work in Progress, Header Allocation (Data Center)", Work in Progress,
Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25 Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25
September 2018, <https://www.ietf.org/archive/id/draft- September 2018, <https://datatracker.ietf.org/doc/html/
ietf-sfc-nsh-dc-allocation-02.txt>. draft-ietf-sfc-nsh-dc-allocation-02>.
[I-D.ietf-sfc-nsh-tlv] [NSH-TLV] Wei, Y., Ed., Elzur, U., Majee, S., Pignataro, C., and D.
Wei, Y., Elzur, U., Majee, S., Pignataro, C., and D. E.
Eastlake, "Network Service Header Metadata Type 2 Eastlake, "Network Service Header Metadata Type 2
Variable-Length Context Headers", Work in Progress, Variable-Length Context Headers", Work in Progress,
Internet-Draft, draft-ietf-sfc-nsh-tlv-10, 3 December Internet-Draft, draft-ietf-sfc-nsh-tlv-13, 26 January
2021, <https://www.ietf.org/archive/id/draft-ietf-sfc-nsh- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
tlv-10.txt>. sfc-nsh-tlv-13>.
[IEEE1588] IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems Version 2", 2008.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
skipping to change at page 10, line 45 skipping to change at line 438
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8592] Browne, R., Chilikin, A., and T. Mizrahi, "Key Performance [RFC8592] Browne, R., Chilikin, A., and T. Mizrahi, "Key Performance
Indicator (KPI) Stamping for the Network Service Header Indicator (KPI) Stamping for the Network Service Header
(NSH)", RFC 8592, DOI 10.17487/RFC8592, May 2019, (NSH)", RFC 8592, DOI 10.17487/RFC8592, May 2019,
<https://www.rfc-editor.org/info/rfc8592>. <https://www.rfc-editor.org/info/rfc8592>.
Acknowledgments
The authors thank Mohamed Boucadair and Greg Mirsky for their
thorough reviews and detailed comments.
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Huawei Huawei
Israel Israel
Email: tal.mizrahi.phd@gmail.com Email: tal.mizrahi.phd@gmail.com
Ilan Yerushalmi Ilan Yerushalmi
Marvell Marvell
6 Hamada 6 Hamada
Yokneam 2066721 Yokneam 2066721
Israel Israel
Email: yilan@marvell.com Email: yilan@marvell.com
David Melman David Melman
Marvell Marvell
6 Hamada 6 Hamada
Yokneam 2066721 Yokneam 2066721
Israel Israel
Email: davidme@marvell.com Email: davidme@marvell.com
Rory Browne Rory Browne
Intel Intel
Dromore House Dromore House
Shannon, Co.Clare Shannon
Co. Clare
Ireland Ireland
Email: rory.browne@intel.com Email: rory.browne@intel.com
 End of changes. 72 change blocks. 
204 lines changed or deleted 205 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/