Network Service Header (NSH) Context Header Allocation: Timestamp
draft-mymb-sfc-nsh-allocation-timestamp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9192.
|
|
|---|---|---|---|
| Authors | Tal Mizrahi , Ilan Yerushalmi , David T. Melman , Rory Browne | ||
| Last updated | 2017-01-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| IETF conflict review | conflict-review-mymb-sfc-nsh-allocation-timestamp, conflict-review-mymb-sfc-nsh-allocation-timestamp, conflict-review-mymb-sfc-nsh-allocation-timestamp, conflict-review-mymb-sfc-nsh-allocation-timestamp, conflict-review-mymb-sfc-nsh-allocation-timestamp, conflict-review-mymb-sfc-nsh-allocation-timestamp | ||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 9192 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mymb-sfc-nsh-allocation-timestamp-00
Network Working Group T. Mizrahi
Internet-Draft I. Yerushalmi
Intended status: Informational D. Melman
Expires: July 16, 2017 Marvell
R. Browne
Intel
January 12, 2017
Network Service Header (NSH) Context Header Allocation: Timestamp
draft-mymb-sfc-nsh-allocation-timestamp-00
Abstract
This memo defines an allocation for the Context Headers of the
Network Service Header (NSH), which incorporates the packet's ingress
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 http://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 July 16, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Mizrahi, et al. Expires July 16, 2017 [Page 1]
Internet-Draft NSH Ingress Timestamp January 2017
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 Allocation . . . . . . . . . . 3
4. Ingress Timestamping Use Cases . . . . . . . . . . . . . . . 4
4.1. Network Analytics . . . . . . . . . . . . . . . . . . . . 4
4.2. Alternate Marking . . . . . . . . . . . . . . . . . . . . 5
4.3. Consistent Updates . . . . . . . . . . . . . . . . . . . 5
5. Synchronization Considerations . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The Network Service Header (NSH), defined in [I-D.ietf-sfc-nsh], is
an encapsulation header that is used in Service Function Chains
(SFC).
The NSH specification [I-D.ietf-sfc-nsh] 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 proposes an allocation for the MD
Type 0x1 Context Headers, which incorporates the ingress timestamp of
the packet, a sequence number, and a source interface identifier.
In a nutshell, packets that enter the SFC-Enabled Domain are
timestamped. The ingress timestamp is measured by the Classifier
[RFC7665], and incorporated in the NSH. The ingress timestamp may be
used for various different purposes, including delay measurement,
packet marking for 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
Mizrahi, et al. Expires July 16, 2017 [Page 2]
Internet-Draft NSH Ingress Timestamp January 2017
duplicate transmissions. The sequence number is maintained on a per-
source-interface basis.
KPI-stamping [I-D.browne-sfc-nsh-kpi-stamp] 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Abbreviations
KPI Key Performance Indicators [I-D.browne-sfc-nsh-kpi-stamp]
NSH Network Service Header [I-D.ietf-sfc-nsh]
MD Metadata [I-D.ietf-sfc-nsh]
SF Service Function [RFC7665]
SFC Service Function Chaining [RFC7665]
3. NSH Context Header Allocation Allocation
This memo defines the following Context Header allocation, as
presented in Figure 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NSH Ingress Timestamp Allocation.
Mizrahi, et al. Expires July 16, 2017 [Page 3]
Internet-Draft NSH Ingress Timestamp January 2017
The NSH Timestamp Allocation includes the following fields:
o Sequence Number - a 32-bit sequence number. The sequence number
is maintained on a per-source-interface basis. The sequence
numbers can be used by SFs to detect out-of-order delivery, or
duplicate transmissions.
o Source Interface - a 32-bit source interface identifier that is
assigned by the Classifier.
o Ingress Timestamp - this field is 8 octets long, and specifies the
time at which the packet was received by the Classifier. The
format of this field uses the 64 least significant bits of the
IEEE 1588-2008 Precision Time Protocol format [IEEE1588]. This
truncated format consists of a 32-bit seconds field followed by a
32-bit nanoseconds field. As defined in [IEEE1588], the timestamp
specifies the number of seconds elapsed since 1 January 1970
00:00:00 according to the International Atomic Time (TAI).
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].
4. Ingress 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 [I-D.browne-sfc-nsh-kpi-stamp] or
[I-D.brockners-inband-oam-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 ingress timestamp to the NSH Context Header provides an
Mizrahi, et al. Expires July 16, 2017 [Page 4]
Internet-Draft NSH Ingress Timestamp January 2017
in-band common time reference that can be used for various network
analytics applications.
4.2. Alternate Marking
A possible approach for passive performance monitoring is to use an
alternate marking method [I-D.ietf-ippm-alt-mark]. 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 ingress 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].
5. Synchronization Considerations
Some of the applications that make use of the ingress 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].
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
The security considerations of NSH in general are discussed in
[I-D.ietf-sfc-nsh]. The security considerations of in-band
timestamping in the context of NSH is discussed in
[I-D.browne-sfc-nsh-kpi-stamp], 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
Mizrahi, et al. Expires July 16, 2017 [Page 5]
Internet-Draft NSH Ingress Timestamp January 2017
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
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-10 (work in progress), September 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
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.brockners-inband-oam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., and R. <>, "Data Formats for In-situ OAM", draft-
brockners-inband-oam-data-02 (work in progress), October
2016.
[I-D.browne-sfc-nsh-kpi-stamp]
Browne, R., Chilikin, A., and T. Mizrahi, "Network Service
Header KPI Stamping", draft-browne-sfc-nsh-kpi-stamp-00
(work in progress), October 2016.
[I-D.ietf-ippm-alt-mark]
Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate Marking method for passive performance
monitoring", draft-ietf-ippm-alt-mark-02 (work in
progress), October 2016.
Mizrahi, et al. Expires July 16, 2017 [Page 6]
Internet-Draft NSH Ingress Timestamp January 2017
[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,
<http://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, <http://www.rfc-editor.org/info/rfc7384>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Tal Mizrahi
Marvell
6 Hamada
Yokneam 2066721
Israel
Email: talmi@marvell.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
Mizrahi, et al. Expires July 16, 2017 [Page 7]
Internet-Draft NSH Ingress Timestamp January 2017
Rory Browne
Intel
Dromore House
Shannon, Co.Clare
Ireland
Email: rory.browne@intel.com
Mizrahi, et al. Expires July 16, 2017 [Page 8]