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

Versions: (draft-fioccola-v6ops-ipv6-alt-mark) 00

6MAN Working Group                                           G. Fioccola
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                                  Huawei
Expires: January 23, 2020                                    M. Cociglio
                                                          Telecom Italia
                                                           July 22, 2019


            IPv6 Application of the Alternate Marking Method
                     draft-fz-6man-ipv6-alt-mark-00

Abstract

   This document describes how the alternate marking method in [RFC8321]
   and [I-D.ietf-ippm-multipoint-alt-mark] can be used as the passive
   performance measurement method in an IPv6 domain and reports
   implementation considerations.  It proposes how to define a new
   encapsulation header to encode alternate marking technique.

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

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 January 23, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Fioccola, et al.        Expires January 23, 2020                [Page 1]


Internet-Draft                IPv6 with AMM                    July 2019


   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IPv6 application of Alternate Marking . . . . . . . . . . . .   3
   3.  IPv6 Extension Headers as Marking Field . . . . . . . . . . .   3
     3.1.  Definition of the AltMark Extension Header  . . . . . . .   3
       3.1.1.  Data Fields Format  . . . . . . . . . . . . . . . . .   4
       3.1.2.  AltMark: Destination Option and Hop-by-Hop Option . .   5
   4.  Alternate Marking Method Operation  . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe passive
   performance measurement method, which can be used to measure packet
   loss, latency and jitter on live traffic.  Since this method is based
   on marking consecutive batches of packets, the method often referred
   as Alternate Marking Method.

   This document defines how the alternate marking method can be used to
   measure packet loss and delay metrics of IPv6 and SRv6.

   The IPv6 Header Format defined in [RFC8200] introduces the format of
   the IPv6 addresses, the Extension Headers in the base IPv6 Header and
   the availability of a 20-bit flow label, that can be considered for
   the application of the Alternate Marking methodology.  In this
   respect, [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the
   possible implementation options for the application of the alternate
   marking method in an IPv6 domain.

   [I-D.zhou-ippm-enhanced-alternate-marking] defines the data field for
   the alternate marking in order to generalize its application.  More



Fioccola, et al.        Expires January 23, 2020                [Page 2]


Internet-Draft                IPv6 with AMM                    July 2019


   information can be considered within the alternate marking field to
   facilitate the efficiency and ease the deployment.

   For the overall application of the methodology
   [I-D.song-ippm-postcard-based-telemetry] introduces a new approach
   named Postcard-Based Telemetry (PBT).  It includes alternative ways
   which can collect the same data of In-band OAM
   ([I-D.ietf-ippm-ioam-data]) but avoid or mitigate the In-band OAM
   issues.  There are two variations of PBT: PBT-M and PBT-I.  PBT-M
   marks the user packets (set one bit) or configure the flow filter to
   invoke the data collection.  At each PBT-aware node, if the mark is
   detected, a postcard is generated and sent to a collector.  Instead,
   PBT-I can be seen as a trade-off between IOAM and PBT-M.  It needs to
   add a fixed length instruction header to user packets for OAM data
   collection, called Per-Hop Postcard (PHP), but, unlike IOAM, data are
   exported through dedicated postcards.

   Both PBT-M and PBT-I variations can allow the implementation of
   [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] and this is also
   discussed in [I-D.zhou-ippm-enhanced-alternate-marking].

2.  IPv6 application of Alternate Marking

   The application of the alternate marking requires a marking field.
   Several alternatives have been analysed in
   [I-D.fioccola-v6ops-ipv6-alt-mark] (Extension Header, IPv6 Address,
   Flow Label).  Anyway the best choice would be the use of an Extension
   Header (EH).

3.  IPv6 Extension Headers as Marking Field

   A new type of EH can be defined for this scope.  In this way there is
   enough space to implement and optimize the deployment of the
   Alternate Marking method.

   A possibility can be to use a Destination or a Hop-By-Hop(HBH)
   Extension Header(EH).  The assumption is that an EH with an alternate
   marking measurement option can be defined.  The router processing can
   be easily optimized to handle this use case.

3.1.  Definition of the AltMark Extension Header

   The desired choice is to define a new Extension Header.
   [I-D.zhou-ippm-enhanced-alternate-marking] generalizes the data
   fields for the alternate marking method and inspired the layout.






Fioccola, et al.        Expires January 23, 2020                [Page 3]


Internet-Draft                IPv6 with AMM                    July 2019


3.1.1.  Data Fields Format

   The following figure shows the data fields format for enhanced
   alternate marking.  This data is expected to be encapsulated to
   specific transports, in this case the IPv6 Option Header named
   AltMark.

    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                FlowID                 |L|D|M|     Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   o  Option Type - 8 bit identifier of the type of option.  It needs to
      be allocated.

   o  Opt Data Len - 8 bit unsigned integer.  Length of the Option Data
      field of this option, in octets.

   o  FlowID - 20 bits unsigned integer.  Flow identifier field is to
      uniquely identify a monitored flow within the measurement domain.
      The field is set at the ingress node.  The FlowID can be uniformly
      assigned by the central controller or algorithmically generated by
      the ingress node.  The latter approach cannot guarantee the
      uniqueness of FlowID, yet the conflict probability is small due to
      the large FlowID space.

   o  L - Loss flag as defined in [RFC8321];

   o  D - Delay flag as defined in [RFC8321];

   o  M - Marking bit as defined in PBT-M
      [I-D.song-ippm-postcard-based-telemetry];

   o  Reserved - is reserved for further use.  These bits MUST be set to
      zero.

   Note that PBT-I [I-D.song-ippm-postcard-based-telemetry] can also be
   used and the marking fields, in this case, are included in the PHP
   Header Format as described in
   [I-D.song-ippm-postcard-based-telemetry].






Fioccola, et al.        Expires January 23, 2020                [Page 4]


Internet-Draft                IPv6 with AMM                    July 2019


3.1.2.  AltMark: Destination Option and Hop-by-Hop Option

   Using a new EH assumes that all routers in the domain support this
   type of headers, but, beyond backward compatibility, the new AltMark
   Option Layout seems the best way to implement the Alternate Marking
   method.

   It is important to highlight that the Option Layout can be used both
   as Destination Option and as Hop-By-Hop Option depending on the Use
   Cases.  In general, it is needed to perform end-to-end or hop-by-hop
   measurements, and the alternate marking methodology in [RFC8321]
   allows, by definition, both end-to-end and hop-by-hop performance
   measurements.

4.  Alternate Marking Method Operation

   [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe in detail
   the methodology.

5.  Security Considerations

   tbc

6.  IANA Considerations

   The option type should be assigned in IANA's "Destination Options and
   Hop-by-Hop Options" registry.

7.  Acknowledgements

   tbc

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

8.2.  Informative References

   [I-D.fioccola-v6ops-ipv6-alt-mark]
              Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6
              Performance Measurement with Alternate Marking Method",
              draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),
              June 2018.



Fioccola, et al.        Expires January 23, 2020                [Page 5]


Internet-Draft                IPv6 with AMM                    July 2019


   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
              "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
              data-06 (work in progress), July 2019.

   [I-D.ietf-ippm-multipoint-alt-mark]
              Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
              "Multipoint Alternate Marking method for passive and
              hybrid performance monitoring", draft-ietf-ippm-
              multipoint-alt-mark-02 (work in progress), July 2019.

   [I-D.song-ippm-postcard-based-telemetry]
              Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee,
              "Postcard-based On-Path Flow Data Telemetry", draft-song-
              ippm-postcard-based-telemetry-04 (work in progress), June
              2019.

   [I-D.zhou-ippm-enhanced-alternate-marking]
              Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and
              Z. Li, "Enhanced Alternate Marking Method", draft-zhou-
              ippm-enhanced-alternate-marking-03 (work in progress),
              July 2019.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

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

Authors' Addresses

   Giuseppe Fioccola
   Huawei
   Riesstrasse, 25
   Munich  80992
   Germany

   Email: giuseppe.fioccola@huawei.com






Fioccola, et al.        Expires January 23, 2020                [Page 6]


Internet-Draft                IPv6 with AMM                    July 2019


   Tianran Zhou
   Huawei
   156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhoutianran@huawei.com


   Mauro Cociglio
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148
   Italy

   Email: mauro.cociglio@telecomitalia.it



































Fioccola, et al.        Expires January 23, 2020                [Page 7]


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