[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                         T. Mizrahi
Internet-Draft                                             I. Yerushalmi
Intended status: Informational                                 D. Melman
Expires: August 24, 2018                                         Marvell
                                                               R. Browne
                                                                   Intel
                                                       February 20, 2018


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

Abstract

   This memo defines an allocation for the Context Headers of the
   Network Service Header (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 24, 2018.

Copyright Notice

   Copyright (c) 2018 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
   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 August 24, 2018                [Page 1]


Internet-Draft                NSH Timestamp                February 2018


   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  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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 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 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
   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 August 24, 2018                [Page 2]


Internet-Draft                NSH Timestamp                February 2018


   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

   The following abbreviations are used in this document:

   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

   This memo defines the following Context Header allocation, as
   presented in Figure 1.














Mizrahi, et al.          Expires August 24, 2018                [Page 3]


Internet-Draft                NSH Timestamp                February 2018


       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 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  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 [I-D.ietf-ntp-packet-timestamps].
      One of the formats is based on the [IEEE1588] timestamp format,
      and the other is based on the [RFC5905] format.  It is assumed
      that in a given administrative domain only one of the formats will
      be used, and that the control plane determines which timestamp
      format is used.

   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 [I-D.ietf-ntp-packet-timestamps].  This timestamp format uses
      the 64 least significant bits of the IEEE 1588-2008 Precision Time
      Protocol format [IEEE1588], and consists of a 32-bit seconds field
      followed by a 32-bit nanoseconds field.










Mizrahi, et al.          Expires August 24, 2018                [Page 4]


Internet-Draft                NSH Timestamp                February 2018


       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 [I-D.ietf-ntp-packet-timestamps].  This format
      consists of a 32-bit seconds field followed by a 32-bit fractional
      second field.


       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 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 [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 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 24, 2018                [Page 5]


Internet-Draft                NSH Timestamp                February 2018


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 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 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
   [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 August 24, 2018                [Page 6]


Internet-Draft                NSH Timestamp                February 2018


   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., Elzur, U., and C. Pignataro, "Network Service
              Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
              November 2017.

   [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>.

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., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields
              for In-situ OAM", draft-brockners-inband-oam-data-07 (work
              in progress), July 2017.

   [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-02
              (work in progress), August 2017.









Mizrahi, et al.          Expires August 24, 2018                [Page 7]


Internet-Draft                NSH Timestamp                February 2018


   [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 and hybrid
              performance monitoring", draft-ietf-ippm-alt-mark-14 (work
              in progress), December 2017.

   [I-D.ietf-ntp-packet-timestamps]
              Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
              Defining Packet Timestamps", draft-ietf-ntp-packet-
              timestamps-00 (work in progress), October 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,
              <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>.

   [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>.

Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada
   Yokneam  2066721
   Israel

   Email: talmi@marvell.com











Mizrahi, et al.          Expires August 24, 2018                [Page 8]


Internet-Draft                NSH Timestamp                February 2018


   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 24, 2018                [Page 9]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/