Network Working Group T. Mizrahi
Internet-Draft Huawei
Intended status: Informational I. Yerushalmi
Expires: August 21, 2021 D. Melman
Marvell
R. Browne
Intel
February 17, 2021
Network Service Header (NSH) Context Header Allocation: Timestamp
draft-mymb-sfc-nsh-allocation-timestamp-08
Abstract
The 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 presents an allocation for the Context
Headers of NSH, which incorporates the packet's timestamp, a sequence
number, and a source interface identifier.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 21, 2021.
Copyright Notice
Copyright (c) 2021 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
Mizrahi, et al. Expires August 21, 2021 [Page 1]
Internet-Draft NSH Timestamp February 2021
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. NSH Context Header Allocation . . . . . . . . . . . . . . . . 3
4. Timestamping Use Cases . . . . . . . . . . . . . . . . . . . 5
4.1. Network Analytics . . . . . . . . . . . . . . . . . . . . 5
4.2. Alternate Marking . . . . . . . . . . . . . . . . . . . . 6
4.3. Consistent Updates . . . . . . . . . . . . . . . . . . . 6
5. Synchronization Considerations . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Network Service Header (NSH), defined in [RFC8300], is an
encapsulation header that is used in Service Function Chains (SFC).
The NSH specification [RFC8300] supports two possible methods of
including metadata in the NSH; MD Type 0x1 and MD Type 0x2. When
using MD Type 0x1 the NSH includes 16 octets of Context Header
fields.
The current memo defines an allocation for the MD Type 0x1 Context
Headers, which incorporates the timestamp of the packet, a sequence
number, and a source interface identifier. It is noted that other MD
Type 0x1 allocations might be specified in the future. Although MD
Type 0x1 allocations are currently not being standardized by the SFC
working group, a consistent format (allocation) should be used in an
SFC domain in order to allow interoperability.
In a nutshell, packets that enter the SFC-Enabled Domain are
timestamped. The timestamp is measured by the Classifier [RFC7665],
and incorporated in the NSH. The timestamp may be used for various
different purposes, including delay measurement, packet marking for
Mizrahi, et al. Expires August 21, 2021 [Page 2]
Internet-Draft NSH Timestamp February 2021
passive performance monitoring, and timestamp-based policies.
Notably, the timestamp does not increase the packet length, since it
is incorporated in the MD Type 0x1 Mandatory Context Headers.
The source interface identifier indicates the interface through which
the packet was received at the classifier. This identifer may
specify a physical or a virtual interface. The sequence numbers can
be used by Service Functions (SFs) to detect out-of-order delivery or
duplicate transmissions. The sequence number is maintained on a per-
source-interface basis.
KPI-stamping [RFC8592] defines an NSH timestamping mechanism that
uses the MD Type 0x2 format. The current memo defines a compact MD
Type 0x1 Context Header that does not require the packet to be
extended beyond the NSH header. Furthermore, the two timestamping
mechanisms can be used in concert, as further discussed below.
2. Terminology
2.1. Requirements Language
The 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Abbreviations
The following abbreviations are used in this document:
KPI Key Performance Indicators [RFC8592]
NSH Network Service Header [RFC8300]
MD Metadata [RFC8300]
SF Service Function [RFC7665]
SFC Service Function Chaining [RFC7665]
3. NSH Context Header Allocation
This memo defines the following Context Header allocation, as
presented in Figure 1.
Mizrahi, et al. Expires August 21, 2021 [Page 3]
Internet-Draft NSH Timestamp February 2021
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 that is defined in this memo MUST
include the following fields:
o 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 (2^32-1) the sequence
number wraps around back to zero.
o Source Interface - a 32-bit source interface identifier that is
assigned by the Classifier.
o Timestamp - this field is 8 octets long, and 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 [RFC8877]. One of the formats is
based on the [IEEE1588] timestamp format, and the other is based
on the [RFC5905] format. Consistent use of one format or the
other is necessary to ensure correct understanding of the
Timestamp field. Operators SHOULD ensure the consistent use of a
timestamp format across the whole SFC domain.
The two timestamp formats that can be used in the timestamp field
are:
o IEEE 1588 Truncated Timestamp Format: as specified in Section 4.3
of [RFC8877]. This format is illustrated in Figure 2.
Mizrahi, et al. Expires August 21, 2021 [Page 4]
Internet-Draft NSH Timestamp February 2021
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: IEEE 1588 Truncated Timestamp Format [IEEE1588].
o NTP [RFC5905] 64-bit Timestamp Format: as specified in
Section 4.2.1 of [RFC8877]. This format is 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 [RFC5905] 64-bit Timestamp Format
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 the
network delay 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 hop-by-hop monitoring mechanism,
such as [RFC8592] or [I-D.ietf-ippm-ioam-data], can be triggered,
allowing to analyze and localize the problem.
Timestamping is also useful for logging and for 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 requires a timestamp to be attached to analyzed packets.
Attaching the timestamp to the NSH Context Header provides an in-band
common time reference that can be used for various network analytics
applications.
Mizrahi, et al. Expires August 21, 2021 [Page 5]
Internet-Draft NSH Timestamp February 2021
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 Context Header, it can
natively 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 taking 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 service functions.
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
Classifer 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.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
The security considerations of NSH in general are discussed in
[RFC8300]. NSH is typically run within a confined trust domain.
However, if a trust domain is not enough to provide the operator with
the protection against the timestamp threats described below, then
the operator SHOULD use transport-level protection between SFC
processing nodes as described in [RFC8300].
Mizrahi, et al. Expires August 21, 2021 [Page 6]
Internet-Draft NSH Timestamp February 2021
The security considerations of in-band timestamping in the context of
NSH is discussed in [RFC8592], and the current section is based on
that discussion.
The use of in-band timestamping, as defined in this document, can be
used as a means for network reconnaissance. By passively
eavesdropping to timestamped traffic, an attacker can gather
information about network delays and performance bottlenecks. A man-
in-the-middle 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", RFC 8877,
DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/info/rfc8877>.
Mizrahi, et al. Expires August 21, 2021 [Page 7]
Internet-Draft NSH Timestamp February 2021
8.2. Informative References
[DPT] Mizrahi, T., Moses, Y., "The Case for Data Plane
Timestamping in SDN", IEEE INFOCOM Workshop on Software-
Driven Flexible and Agile Networking (SWFAN), 2016.
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in
progress), November 2020.
[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,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8592] Browne, R., Chilikin, A., and T. Mizrahi, "Key Performance
Indicator (KPI) Stamping for the Network Service Header
(NSH)", RFC 8592, DOI 10.17487/RFC8592, May 2019,
<https://www.rfc-editor.org/info/rfc8592>.
Authors' Addresses
Tal Mizrahi
Huawei
Israel
Email: tal.mizrahi.phd@gmail.com
Mizrahi, et al. Expires August 21, 2021 [Page 8]
Internet-Draft NSH Timestamp February 2021
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
Mizrahi, et al. Expires August 21, 2021 [Page 9]