Network Service Header (NSH) Context Header Allocation: Timestamp
draft-mymb-sfc-nsh-allocation-timestamp-08

Document Type Active Internet-Draft (individual)
Authors Tal Mizrahi  , Ilan Yerushalmi  , David Melman  , Rory Browne 
Last updated 2021-03-02 (latest revision 2021-02-17)
Stream Independent Submission
Intended RFC status Informational
Formats plain text pdf htmlized (tools) htmlized bibtex
Stream ISE state Response to Review Needed
Revised I-D Needed
Consensus Boilerplate Unknown
Document shepherd Adrian Farrel
IESG IESG state I-D Exists::Revised I-D Needed
Telechat date
Responsible AD (None)
Send notices to rfc-ise@rfc-editor.org
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]