Internet DRAFT - draft-wang-ippm-ipv6-distribted-flow-measurement

draft-wang-ippm-ipv6-distribted-flow-measurement



IPPM Working Group                                               H. Wang
Internet Draft                                                   S. Weng
Intended status: Informational                              China Mobile
Expires: August 28, 2022                                          C. Lin
                                                    New H3C Technologies
                                                           March 4, 2022



                   Distributed Flow Measurement in IPv6
            draft-wang-ippm-ipv6-distribted-flow-measurement-00


Abstract

   Flow measurement based on Alternate-Marking method for IPv6 network 
   requires the controller to collect statistical data, calculate and 
   present the results. This document proposes a distributed method for 
   in-situ flow measurement, which is indpendent of the controller.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 28 2022.







Wang, et al.               Expire August, 2022                  [Page 1]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


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



Table of Contents


   1. Introduction ................................................ 3
      1.1. Requirements Language .................................. 3
   2. Requirement scenarios ....................................... 3
   3. End-to-end measurement ...................................... 5
   4. Hop-by-hop measurement ...................................... 5
   5. Extension to the Flow Monitor Option ........................ 6
      5.1. Previous cycle count bit (bit1) ........................ 6
      5.2. Packet time stamp bit (bit2) ........................... 6
   6. Measurement information and result notification ............. 7
      6.1. Data format ............................................ 7
         6.1.1. Base data structure ............................... 8
         6.1.2. Packet count TLV .................................. 8
         6.1.3. Time Stamp TLV .................................... 9
         6.1.4. Packet loss TLV .................................. 10
         6.1.5. Packet delay TLV ................................. 11
         6.1.6. Average Packet loss TLV .......................... 11
         6.1.7. Average Packet delay TLV ......................... 12
      6.2. Transport channel ..................................... 13
         6.2.1. Independent control protocol ..................... 13
         6.2.2. Extend BGP Protocol .............................. 14
         6.2.3. Reverse traffic .................................. 14
   7. Application of measurement results ......................... 14
   8. IANA Considerations ........................................ 15
   9. Security Considerations .................................... 15
   10. References ................................................ 16
      10.1. Normative References ................................. 16
   Authors' Addresses ............................................ 17


Wang, et al.              Expire August, 2022                   [Page 2]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


1. Introduction

   [draft-wang-ippm-ipv6-flow-measurement] describes how to measure the
   network by carrying the detection data in the traffic in the IPv6
   network based on Alternate-Marking.

   The nodes participating in the measurement need to collect message
   statistics, timestamp and other information, report the collected
   data to the controller through telemetry and other methods, and the
   controller calculates the packet loss and delay of each flow.

   Based on the basic method of [draft-wang-ippm-ipv6-flow-
   measurement], this document proposes a flow measurement without the
   participation of the controller. The nodes involved in the
   measurement calculate the network metrics such as packet loss and
   delay Distributed.

1.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. Requirement scenarios

   The method described in [draft-wang-ippm-ipv6-flow-measurement]
   requires the controller to summarize the data collected by each node
   and then calculate the final measurement result. In some practical
   scenarios, this method could not meet the requirements of
   measurement well.

   o Scenario1:

   For the customers who have high requirements for SLA such as banks
   and finance, this method cannot meet the customers well. Firstly,
   each participating measuring node reports to the controller, and
   then the centralized controller calculates the path quality, and
   then the controller notifies the source node to schedule the path of
   traffic. The whole processing path is too long and it is difficult
   to guarantee the SLA requirements of customers in this way

   o Scenario2:

   For the transport network with multiple AS and multi-level
   controllers, one inter-as controller is deployed and one intra-as
   controller is deployed for each AS typically.

Wang, et al.               Expire August, 2022                  [Page 3]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


   Inter-as controller programs end-to-end paths, but do not manage
   network devices. Each intra-as controller only manages devices in
   its own AS and is not aware of the entire end-to-end path.

   Therefore, the measurement data will be reported to the intra-as
   controller by the measurement node, but the final data needs to be
   summarized, calculated and presented on the centralized inter-as
   controller. This will cause the interaction between different levels
   of controllers to be too complex.

                                 +-------+
           inter-as controller-->|       |
                                 +-------+
                                 /       \
                                /         \
                               /           \
                              /             \
   Intra-as      +------+    /               \    +-------+
   controller -->|      |---+                 +---|       |
                 +------+                         +-------+
                /   |   \                          /  |   \
               /    :    \                        /   :    \
              /     |     \                      /    |     \
     +-----------------------------+    +----------------------------+
     |      /       |      \       |    |      /      |       \      |
     | +----+     +----+   +----+  |    | +----+    +----+    +----+ |
     | |    +-----+    +---+    +- -------+    +----+    +----+    | |
     | +----+     +----+   +----+  |    | +----+    +----+    +----+ |
     +-----------------------------+    +----------------------------+
                 AS100                              AS200
           Figure 1: reference topology of multiple level controller


   o Scenario3:

   For some networks may not have the conditions or requirements to
   deploy controllers, but they also hope to use the technology of flow
   measurement to measure and present the quality of traffic forwarding
   path.



   In order to meet the requirement of these scenarios, this document
   proposes a distributed flow measurement, which does not depend on
   the controller. All the nodes participating in the measurement
   complete the measurement, and finally the measurement results can be
   used on the source node for fast intelligent routing, simplifying
   operation and maintenance, and optimize the experience.

Wang, et al.               Expire August, 2022                  [Page 4]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


3. End-to-end measurement

   For end-to-end measurement, there are two working models, which are
   suitable for different scenarios.

   o Source node model:

   The source node completes the summary and calculation of statistical
   data.

   The source node inserts the required flow measurement data into the
   specified traffic, and marks the traffic according to [draft-wang-
   ippm-ipv6-flow-measurement]. The end node collects the statistical
   data and time stamp, the collected information is periodically
   notified to the source node, which completes the calculation of the
   measurement results.

   In this model, the source node undertakes the work of the controller
   and can count the data measured by the traffic through source node.

   o End node model:

   The end node is responsible for calculating measurement result. In
   addition to marking the traffic, the source node also needs to carry
   additional information through the flow monitor option. For example,
   in order to measure packet loss, the traffic count of the source
   node in the previous cycle need to be carried in the flow monitor
   option, packet delay measurement requires the source node to carry a
   timestamp when marking the D bit.

   Through this information, the end node could calculate the packet
   loss and delay stream on the flow. Furthermore, the average packet
   loss and delay could be calculated. All the result could be send to
   the corresponding source node.

   This model is suitable for the scenario of one source node vs
   multiple end nodes, such as multicast. It can reduce the calculation
   pressure of the source node and transfer the workload to each end
   node

4. Hop-by-hop measurement

   Hop-by-hop measurement requires that intermediate nodes also
   participate in data collection, so only the source node model should
   be used.




Wang, et al.               Expire August, 2022                  [Page 5]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


5. Extension to the Flow Monitor Option

   Refer to [draft-wang-ippm-ipv6-flow-measurement], the additional
   information required by the end node model can be carried by
   extending Ext FM type

   Define the corresponding bit and data format for the packet count of
   previous cycle and time stamp.

                      0 1 2 3 4 5 6 7 8 9          15
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |0|1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 2: Ext FM type extension


5.1. Previous cycle count bit (bit1)

   This bit indicates the flow monitor option carries the packet count
   of the source node in the previous cycle. The end node can calculate
   the packet loss data according to this value in combination with the
   locally recorded count.

   The data format is shown below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      PacketCount(64bits)                      +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 3: PacketCount data format


   o packetCount 64bits Packet count of the previous cycle of the
      source node.



5.2. Packet time stamp bit (bit2)

   This bit indicates the flow monitor option carries the timestamp set
   by the source node, which is the time when the source node receives
   the packet. The end node could calculate the packet delay according
   to this value in combination with the packet receiving time of end
   node.


Wang, et al.              Expire August, 2022                   [Page 6]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


   The data format is shown below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      TimestampSecond(64bit)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      TimestampNanoSecond(64bit)               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 4: timestamp data format


   o TimestampSecond: 64bits, Integer value of the second part from
      1970 to the time when the message is received.

   o TimestampNanoSecond:64bits, Integer value of the nanosecond part
      from 1970 to the time of receiving the message.



6. Measurement information and result notification

   For the source node model, the measurement data of the intermediate
   node and the end node need to be sent to the corresponding source
   node.

   For the end node model, the end node needs to send the calculated
   measurement results to the corresponding source node

   The address of the original node is obtained through the outer
   encapsulation source address of the packet carrying the monitor
   data. The notification cycle of collection data or results can be
   according to the measurement cycle or the configured cycle.



6.1. Data format

   The notification data structure includes a base data structure and
   multiple data structures defined through TLV.





Wang, et al.               Expire August, 2022                  [Page 7]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


6.1.1. Base data structure



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              NodeMonID                |        Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 5: Base data format


   The fields are defined as following:

   o NodeMonID: A 20 bits field, which is consistent with the
      definition in flow monitor option.

   o Length: A 12 bits field, Length of the notification data in 4-
      octet units, not including the first 4 octets



6.1.2. Packet count TLV

   This TLV is used to notify packet count to source node and is used
   in the source node model. The tlv is defined as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Flags     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               FlowMonID               |       RESERVED        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          PeriodID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      PacketCount(64bit)                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 6: packet count TLV


   o Type: A one-octet field. Value 1 will be register in IANA.

   o Flags: A one-octet field.



Wang, et al.               Expire August, 2022                  [Page 8]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


   o Length: A two-octet field equal to the length of the Value field
      in octets.

   o FlowMonID: A 20 bits field, which is consistent with the
      definition in flow monitor option.

   o PeriodID: A 4 Octets period ID of the packet count

   o PacketCount: A 8 Octets packet count in the period received by
      node.



6.1.3. Time Stamp TLV

   This TLV is used to notify time stamp to source node and is used in
   the source node model. The tlv is defined as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Flags     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               FlowMonID               |       RESERVED        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         PeriodID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      TimestampSecond(64bit)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     TimestampNanoSecond(64bit)                +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7: time stamp TLV

   o Type: A one-octet field. Value 2 will be register in IANA.

   o Flags: A one-octet field.

   o Length: A two-octet field equal to the length of the Value field
      in octets.

   o FlowMonID: A 20 bits field, which is consistent with the
      definition in flow monitor option.


Wang, et al.               Expire August, 2022                  [Page 9]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


   o PeriodID: A 4 Octets period ID of the packet count

   o TimestampSecond: 64bits, Integer value of the second part from
      1970 to the time when the message is received.

   o TimestampNanoSecond:64bits, Integer value of the nanosecond part
      from 1970 to the time of receiving the message.



6.1.4. Packet loss TLV

   This TLV is used to notify measurement of packet loss to source node
   and is used in the end node model. The tlv is defined as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Flags     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              FlowMonID                |       RESERVED        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         PeriodID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      PacketLoss(64bit)                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 8: packet count TLV


   o Type: A one-octet field. Value 3 will be register in IANA.

   o Flags: A one-octet field.

   o Length: A two-octet field equal to the length of the Value field
      in octets.

   o FlowMonID: A 20 bits field, which is consistent with the
      definition in flow monitor option.

   o PeriodID: A 4 Octets period ID of the packet count

   o PacketLoss: A 8 Octets count of packet loss in the period
      specified by periodID.




Wang, et al.               Expire August, 2022                 [Page 10]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


6.1.5. Packet delay TLV

   This TLV is used to notify measurement of packet delay to source
   node and is used in the end node model. The tlv is defined as
   follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Flags     |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               FlowMonID               |       RESERVED        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          PeriodID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      packetDelay(64bit )                      +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 9: time stamp TLV

   o Type: A one-octet field. Value 4 will be register in IANA.

   o Flags: A one-octet field.

   o Length: A two-octet field equal to the length of the Value field
      in octets.

   o FlowMonID: A 20 bits field, which is consistent with the
      definition in flow monitor option.

   o PeriodID: A 4 Octets period ID of the packet count

   o packetDelay: 64bits field of nanosecond, which is the packet
      delay in the period specified by peroidID.



6.1.6. Average Packet loss TLV

   This TLV is used to notify measurement of average packet loss to
   source node and is used in the end node model. The tlv is defined as
   follows:





Wang, et al.               Expire August, 2022                 [Page 11]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Flags     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              FlowMonID                |        Periods        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     AveragePacketLoss(64bit)                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 10: Average packet loss TLV


   o Type: A one-octet field. Value 3 will be register in IANA.

   o Flags: A one-octet field.

   o Length: A two-octet field equal to the length of the Value field
      in octets.

   o FlowMonID: A 20 bits field, which is consistent with the
      definition in flow monitor option.

   o Periods A 12 bits field, which identifies the number of periods
      used to calculate the average packet loss

   o AveragePacketLoss: A 8 Octets count of packet loss in the period
      specified by periodID.



6.1.7. Average Packet delay TLV

   This TLV is used to notify measurement of average packet delay to
   source node and is used in the end node model. The tlv is defined as
   follows:











Wang, et al.               Expire August, 2022                 [Page 12]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Flags     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              FlowMonID                |        Periods        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    AveragePacketDelay(64bit )                 +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 11: Average packet delay TLV


   o Type: A one-octet field. Value 5 will be register in IANA.

   o Flags: A one-octet field.

   o Length: A two-octet field equal to the length of the Value field
      in octets.

   o FlowMonID: A 20 bits field, which is consistent with the
      definition in flow monitor option.

   o Periods A 12 bits field, which identifies the number of periods
      used to calculate the average packet delay. The number of periods
      used to calculate the average value could base on the capacity or
      configuration of the end node

   o AveragePacketDelay: 64bits field of nanosecond, which is the
      Average Packet delay in the past periods.



6.2. Transport channel

   The following methods can be considered for the channel of data and
   result notification:

6.2.1. Independent control protocol

   Notify the source node of the statistical results or collection data
   through an independent controller protocol. This document considers
   using UDP as the transport layer.

   A Specific UDP port will be registered in IANA in the future for
   distributed flow measurement, or the UDP port number can be


Wang, et al.               Expire August, 2022                 [Page 13]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


   distributed on each node through configuration, Such as CLI and
   NETCONF.



6.2.2. Extend BGP Protocol

   For end-to-end measurement type, only source and end nodes are
   involved. In the scenario where BGP is deployed, the collection data
   or result can be carried by extending BGP protocol.

   This method requires a new definition of BGP measurement address
   family, which is used to publish measurement data and measurement
   results. This method will be discussed in detail in subsequent
   versions of this document.

6.2.3. Reverse traffic

   This method is only applicable to end-to-end measurement type too.
   The end node could carry the collection data and results to the
   source node through reverse data flow.

   This method will be discussed in detail in subsequent versions of
   this document.

7. Application of measurement results

   Using the distributed flow measurement method described in this
   document, the source node can obtain the quality result of the
   actual traffic forwarding path faster. According to different actual
   needs, the source node could present the measurement results and
   optimize the path based on the measurement results, and more other
   application.

   As illustrated in the figure below, in the srv6 scenario, the
   traffic from CE1 to CE2 requires the SLA of low delay. There are two
   paths on PE1 to form a primary-slave relationship,

   Path1: PE1->P1->P2->P3->CE2

   Path2: PE1->P4->P5->P6->CE2

   Path1 is the primary path.






Wang, et al.               Expire August, 2022                 [Page 14]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


               * * * * * * * * * * * * * * * * * * *
               *                                   *
               *       +----+    +----+       +----+
               *  +----+ P1 +----+ P2 +-------+ P3 +........
               *  |    +----+    +----+       +----+       :
               *  |                                *       :
               *  |                                *       :
               *  |                                *       :
    +----+     +----+                              *     +----+
    + CE1+.....+ PE1+                              *     + CE2+
    +----+     +----+                              *     +----+
               *  |                                *       :
               *  |    +----+      +----+      +----+      :
               *  +----+ P4 +------+ P5 +------+ P6 +......:
               *       +----+      +----+      +----+
               *                                   *
               * * * * * * SRv6 domain * * * * * * *
                     Figure 12: reference topology


   The distributed flow measurement function can be deployed to measure
   the quality of the path. PE1, as the source node of the measurement,
   adopts the tail node mode. The end nodes P3 and P6 complete the
   calculation of the measurement results and notify PE1

   When PE1 finds out that the delay of path 1 exceeds the threshold,
   it can immediately start the switching between the primary and
   standby paths, switch the traffic to the standby path, and send an
   alarm message.



   More kinds of applications based on measure results on source nodes
   are not in the scope of this document



8. IANA Considerations

   TBD

9. Security Considerations

   The potential security threats of Alternate-Marking method have been
   described in detail in Section 9 of [RFC8321].  The performance
   measurement method described in this document does not introduce
   additional new security issues


Wang, et al.               Expire August, 2022                 [Page 15]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


10. References

10.1. Normative References

   [I-D.wang-ippm-ipv6-flow-measurement]Wang, H.,Liu, Y., Lin, C.,
             Xiao, M., "Flow Measurement in IPv6 Network", draft-wang-
             ippm-ipv6-flow-measurement-00(work in progress), October
             2021.

   [I-D.ietf-6man-ipv6-alt-mark]Fioccola, G., Zhou, T., Cociglio, M.,
             Qin, F., and R.Pang, "IPv6 Application of the Alternate
             Marking Method",draft-ietf-6man-ipv6-alt-mark-08 (work in
             progress), January 2022.

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

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
























Wang, et al.               Expire August, 2022                 [Page 16]

Internet-Draft   Distributed flow measurement In IPv6         March 2022


Authors' Addresses

   Haojie Wang
   China Mobile
   Beijing
   Email: wanghaojie@chinamobile.com
   CN


   Sijun Weng
   China Mobile
   Beijing
   CN

   Email: wengsijun@chinamobile.com


   Changwang Lin
   New H3C Corporation
   Beijing
   China

   Email: linchangwang.04414@h3c.com





















Wang, et al.               Expire August, 2022                 [Page 17]

Internet-Draft   Distributed flow measurement In IPv6         March 2022