| < draft-mirsky-ippm-hybrid-two-step-12.txt | draft-mirsky-ippm-hybrid-two-step-13.txt > | |||
|---|---|---|---|---|
| IPPM Working Group G. Mirsky | IPPM Working Group G. Mirsky | |||
| Internet-Draft Ericsson | Internet-Draft Ericsson | |||
| Intended status: Standards Track W. Lingqiang | Intended status: Standards Track W. Lingqiang | |||
| Expires: 30 July 2022 G. Zhui | Expires: 27 October 2022 G. Zhui | |||
| ZTE Corporation | ZTE Corporation | |||
| H. Song | H. Song | |||
| Futurewei Technologies | Futurewei Technologies | |||
| 26 January 2022 | P. Thubert | |||
| Cisco Systems, Inc | ||||
| 25 April 2022 | ||||
| Hybrid Two-Step Performance Measurement Method | Hybrid Two-Step Performance Measurement Method | |||
| draft-mirsky-ippm-hybrid-two-step-12 | draft-mirsky-ippm-hybrid-two-step-13 | |||
| Abstract | Abstract | |||
| Development of, and advancements in, automation of network operations | Development of, and advancements in, automation of network operations | |||
| brought new requirements for measurement methodology. Among them is | brought new requirements for measurement methodology. Among them is | |||
| the ability to collect instant network state as the packet being | the ability to collect instant network state as the packet being | |||
| processed by the networking elements along its path through the | processed by the networking elements along its path through the | |||
| domain. This document introduces a new hybrid measurement method, | domain. This document introduces a new hybrid measurement method, | |||
| referred to as hybrid two-step, as it separates the act of measuring | referred to as hybrid two-step, as it separates the act of measuring | |||
| and/or calculating the performance metric from the act of collecting | and/or calculating the performance metric from the act of collecting | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 43 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 30 July 2022. | This Internet-Draft will expire on 27 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 38 ¶ | skipping to change at page 2, line 38 ¶ | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 13 | 6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 13 | |||
| 6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 13 | 6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 14 | 6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 14 | |||
| 6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 15 | 6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 15 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 17 | 9.2. Informative References . . . . . . . . . . . . . . . . . 17 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 1. Introduction | 1. Introduction | |||
| Successful resolution of challenges of automated network operation, | Successful resolution of challenges of automated network operation, | |||
| as part of, for example, overall service orchestration or data center | as part of, for example, overall service orchestration or data center | |||
| operation, relies on a timely collection of accurate information that | operation, relies on a timely collection of accurate information that | |||
| reflects the state of network elements on an unprecedented scale. | reflects the state of network elements on an unprecedented scale. | |||
| Because performing the analysis and act upon the collected | Because performing the analysis and act upon the collected | |||
| information requires considerable computing and storage resources, | information requires considerable computing and storage resources, | |||
| the network state information is unlikely to be processed by the | the network state information is unlikely to be processed by the | |||
| skipping to change at page 5, line 31 ¶ | skipping to change at page 5, line 31 ¶ | |||
| data for the part, most probably the latter part, of the path. | data for the part, most probably the latter part, of the path. | |||
| In some networks, for example, wireless that are in the scope of | In some networks, for example, wireless that are in the scope of | |||
| [I-D.ietf-raw-use-cases], it is beneficial to collect the telemetry, | [I-D.ietf-raw-use-cases], it is beneficial to collect the telemetry, | |||
| including the calculated performance metrics, that reflects | including the calculated performance metrics, that reflects | |||
| conditions experienced by the monitored flow at a node, other than | conditions experienced by the monitored flow at a node, other than | |||
| the egress. For example, a head-end can optimize path selection | the egress. For example, a head-end can optimize path selection | |||
| based on the compounded information that reflects network conditions, | based on the compounded information that reflects network conditions, | |||
| resource utilization. This mode is referred to as the upstream | resource utilization. This mode is referred to as the upstream | |||
| collection and the other - downstream collection to differentiate | collection and the other - downstream collection to differentiate | |||
| between two modes of telemetry collection.. | between two modes of telemetry collection. | |||
| 4. Theory of Operation | 4. Theory of Operation | |||
| The HTS method consists of two phases: | The HTS method consists of two phases: | |||
| * performing a measurement and/or obtaining network state | * performing a measurement and/or obtaining network state | |||
| information on a node; | information on a node; | |||
| * collecting and transporting the measurement and/or the telemetry | * collecting and transporting the measurement and/or the telemetry | |||
| information. | information. | |||
| HTS may use an HTS Trigger carried in a data packet or a specially | HTS may use an HTS Trigger carried in a data packet or a specially | |||
| constructed test packet. For example, an HTS Trigger could be a | constructed test packet. For example, an HTS Trigger could be a | |||
| packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step | packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step | |||
| Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The | Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The | |||
| HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type | HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type | |||
| information [I-D.ietf-ippm-ioam-data]. A packet in the flow to which | information s defined in Section 5.3 and Section 5.4.1 | |||
| the Alternate-Marking method [RFC8321] is applied can be used as an | [I-D.ietf-ippm-ioam-data] respectively (shown in Figure 1). A packet | |||
| HTS Trigger. The nature of the HTS Trigger is a transport network | in the flow to which the Alternate-Marking method, defined in | |||
| layer-specific, and its description is outside the scope of this | [RFC8321] and [RFC8889], is applied can be used as an HTS Trigger. | |||
| document. The packet that includes the HTS Trigger in this document | ||||
| is also referred to as the trigger packet. | The nature of the HTS Trigger is a transport network layer-specific, | |||
| and its description is outside the scope of this document. The | ||||
| packet that includes the HTS Trigger in this document is also | ||||
| referred to as the trigger packet. | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Namespace-ID | Reserved | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | IOAM-Trace-Type | Reserved | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 1: Hybrid Two-Step Trace IOAM Header | ||||
| The HTS method uses the HTS Follow-up packet, referred to as the | The HTS method uses the HTS Follow-up packet, referred to as the | |||
| follow-up packet, to collect measurement and network state data from | follow-up packet, to collect measurement and network state data from | |||
| the nodes. The node that creates the HTS Trigger also generates the | the nodes. The node that creates the HTS Trigger also generates the | |||
| HTS Follow-up packet. In some use cases, e.g., when HTS is used to | HTS Follow-up packet. In some use cases, e.g., when HTS is used to | |||
| collect the telemetry, including performance metrics, calculated | collect the telemetry, including performance metrics, calculated | |||
| based on a series of measurements, an HTS follow-up packet can be | based on a series of measurements, an HTS follow-up packet can be | |||
| originated without using the HTS Trigger. The follow-up packet | originated without using the HTS Trigger. The follow-up packet | |||
| contains characteristic information sufficient for participating HTS | contains characteristic information sufficient for participating HTS | |||
| nodes to associate it with the monitored data flow. The | nodes to associate it with the monitored data flow. The | |||
| skipping to change at page 7, line 18 ¶ | skipping to change at page 7, line 22 ¶ | |||
| the exception that the HTS Trigger packet does not precede the HTS | the exception that the HTS Trigger packet does not precede the HTS | |||
| Follow-up packet. | Follow-up packet. | |||
| 4.1. Operation of the HTS Ingress Node | 4.1. Operation of the HTS Ingress Node | |||
| A node that originates the HTS Trigger is referred to as the HTS | A node that originates the HTS Trigger is referred to as the HTS | |||
| ingress node. As stated, the ingress node originates the follow-up | ingress node. As stated, the ingress node originates the follow-up | |||
| packet. The follow-up packet has the transport network encapsulation | packet. The follow-up packet has the transport network encapsulation | |||
| identical with the trigger packet followed by the HTS shim and one or | identical with the trigger packet followed by the HTS shim and one or | |||
| more telemetry information elements encoded as Type-Length-Value | more telemetry information elements encoded as Type-Length-Value | |||
| {TLV}. Figure 1 displays an example of the follow-up packet format. | {TLV}. Figure 2 displays an example of the follow-up packet format. | |||
| 0 1 2 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| ~ Transport Network ~ | ~ Transport Network ~ | |||
| | Encapsulation | | | Encapsulation | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Ver|HTS Shim L | Flags |Sequence Number| Reserved | | |Ver|HTS Shim L | Flags |Sequence Number| Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | HTS Max Length | | | HTS Max Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Telemetry Data Profile | | | Telemetry Data Profile | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| ~ Telemetry Data TLVs ~ | ~ Telemetry Data TLVs ~ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: Follow-up Packet Format | Figure 2: Follow-up Packet Format | |||
| Fields of the HTS shim are as follows: | Fields of the HTS shim are as follows: | |||
| Version (Ver) is the two-bits long field. It specifies the | Version (Ver) is the two-bits long field. It specifies the | |||
| version of the HTS shim format. This document defines the format | version of the HTS shim format. This document defines the format | |||
| for the 0b00 value of the field. | for the 0b00 value of the field. | |||
| HTS Shim Length is the six bits-long field. It defines the length | HTS Shim Length is the six bits-long field. It defines the length | |||
| of the HTS shim in octets. The minimal value of the field is | of the HTS shim in octets. The minimal value of the field is | |||
| eight octets. | eight octets. | |||
| 0 | 0 | |||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |F| Reserved | | |F| Reserved | | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| Figure 2: Flags Field Format | Figure 3: Flags Field Format | |||
| Flags is eight-bits long. The format of the Flags field displayed | Flags is eight-bits long. The format of the Flags field displayed | |||
| in Figure 2. | in Figure 3. | |||
| - Full (F) flag MUST be set to zero by the node originating the | - Full (F) flag MUST be set to zero by the node originating the | |||
| HTS follow-up packet and MUST be set to one by the node that | HTS follow-up packet and MUST be set to one by the node that | |||
| does not add its telemetry data to avoid exceeding MTU size. | does not add its telemetry data to avoid exceeding MTU size. | |||
| - The node originating the follow-up packet MUST zero the | - The node originating the follow-up packet MUST zero the | |||
| Reserved field and ignore it on the receipt. | Reserved field and ignore it on the receipt. | |||
| Sequence Number is one octet-long field. The zero-based value of | Sequence Number is one octet-long field. The zero-based value of | |||
| the field reflects the place of the HTS follow-up packet in the | the field reflects the place of the HTS follow-up packet in the | |||
| skipping to change at page 9, line 4 ¶ | skipping to change at page 9, line 12 ¶ | |||
| [I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data | [I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data | |||
| Profile field. | Profile field. | |||
| 0 1 2 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 | 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 | Reserved | Length | | | Type | Reserved | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ Value ~ | ~ Value ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 3: Telemetry Data TLV Format | ||||
| Figure 4: Telemetry Data TLV Format | ||||
| Telemetry Data TLV is a variable-length field. Multiple TLVs MAY | Telemetry Data TLV is a variable-length field. Multiple TLVs MAY | |||
| be placed in an HTS packet. Additional TLVs may be enclosed | be placed in an HTS packet. Additional TLVs may be enclosed | |||
| within a given TLV, subject to the semantics of the (outer) TLV in | within a given TLV, subject to the semantics of the (outer) TLV in | |||
| question. Figure 3 presents the format of a Telemetry Data TLV, | question. Figure 4 presents the format of a Telemetry Data TLV, | |||
| where fields are defined as the following: | where fields are defined as the following: | |||
| - Type - a one-octet-long field that characterizes the | - Type - a one-octet-long field that characterizes the | |||
| interpretation of the Value field. | interpretation of the Value field. | |||
| - Reserved - one-octet-long field. | - Reserved - one-octet-long field. | |||
| - Length - two-octet-long field equal to the length of the Value | - Length - two-octet-long field equal to the length of the Value | |||
| field in octets. | field in octets. | |||
| skipping to change at page 12, line 14 ¶ | skipping to change at page 12, line 17 ¶ | |||
| 5. Authentication in HTS | 5. Authentication in HTS | |||
| Telemetry information may be used to drive network operation, closing | Telemetry information may be used to drive network operation, closing | |||
| the control loop for self-driving, self-healing networks. Thus it is | the control loop for self-driving, self-healing networks. Thus it is | |||
| critical to provide a mechanism to protect the telemetry information | critical to provide a mechanism to protect the telemetry information | |||
| collected using the HTS method. This document defines an optional | collected using the HTS method. This document defines an optional | |||
| authentication of a Telemetry Data TLV that protects the collected | authentication of a Telemetry Data TLV that protects the collected | |||
| information's integrity. | information's integrity. | |||
| The format of the Authentication sub-TLV is displayed in Figure 4. | The format of the Authentication sub-TLV is displayed in Figure 5. | |||
| 0 1 2 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Authentic. Type| HMAC Type | Length | | |Authentic. Type| HMAC Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| | Digest | | | Digest | | |||
| | | | | | | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 4: HMAC sub-TLV | Figure 5: HMAC sub-TLV | |||
| where fields are defined as follows: | where fields are defined as follows: | |||
| * Authentication Type - is a one-octet-long field, value TBA2 | * Authentication Type - is a one-octet-long field, value TBA2 | |||
| allocated by IANA Section 6.2. | allocated by IANA Section 6.2. | |||
| * Length - two-octet-long field, set equal to the length of the | * Length - two-octet-long field, set equal to the length of the | |||
| Digest field in octets. | Digest field in octets. | |||
| * HMAC Type - is a one-octet-long field that identifies the type of | * HMAC Type - is a one-octet-long field that identifies the type of | |||
| skipping to change at page 12, line 49 ¶ | skipping to change at page 13, line 5 ¶ | |||
| according to the HTS HMAC Type sub-registry (see Section 6.4). | according to the HTS HMAC Type sub-registry (see Section 6.4). | |||
| * Digest - is a variable-length field that carries HMAC digest of | * Digest - is a variable-length field that carries HMAC digest of | |||
| the text that includes the encompassing TLV. | the text that includes the encompassing TLV. | |||
| This specification defines the use of HMAC-SHA-256 truncated to 128 | This specification defines the use of HMAC-SHA-256 truncated to 128 | |||
| bits ([RFC4868]) in HTS. Future specifications may define the use in | bits ([RFC4868]) in HTS. Future specifications may define the use in | |||
| HTS of more advanced cryptographic algorithms or the use of digest of | HTS of more advanced cryptographic algorithms or the use of digest of | |||
| a different length. HMAC is calculated as defined in [RFC2104] over | a different length. HMAC is calculated as defined in [RFC2104] over | |||
| text as the concatenation of the Sequence Number field of the follow- | text as the concatenation of the Sequence Number field of the follow- | |||
| up packet (see Figure 1) and the preceding data collected in the | up packet (see Figure 2) and the preceding data collected in the | |||
| Telemetry Data TLV. The digest then MUST be truncated to 128 bits | Telemetry Data TLV. The digest then MUST be truncated to 128 bits | |||
| and written into the Digest field. Distribution and management of | and written into the Digest field. Distribution and management of | |||
| shared keys are outside the scope of this document. In the HTS | shared keys are outside the scope of this document. In the HTS | |||
| authenticated mode, the Authentication sub-TLV MUST be present in | authenticated mode, the Authentication sub-TLV MUST be present in | |||
| each Telemetry Data TLV. HMAC MUST be verified before using any data | each Telemetry Data TLV. HMAC MUST be verified before using any data | |||
| in the included Telemetry Data TLV. If HMAC verification fails, the | in the included Telemetry Data TLV. If HMAC verification fails, the | |||
| system MUST stop processing corresponding Telemetry Data TLV and | system MUST stop processing corresponding Telemetry Data TLV and | |||
| notify an operator. Specification of the notification mechanism is | notify an operator. Specification of the notification mechanism is | |||
| outside the scope of this document. | outside the scope of this document. | |||
| skipping to change at page 17, line 32 ¶ | skipping to change at page 17, line 32 ¶ | |||
| [I-D.ietf-ippm-ioam-direct-export] | [I-D.ietf-ippm-ioam-direct-export] | |||
| Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., | Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., | |||
| Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ | Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ | |||
| OAM Direct Exporting", Work in Progress, Internet-Draft, | OAM Direct Exporting", Work in Progress, Internet-Draft, | |||
| draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, | draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-ippm- | <https://datatracker.ietf.org/doc/html/draft-ietf-ippm- | |||
| ioam-direct-export-07>. | ioam-direct-export-07>. | |||
| [I-D.ietf-raw-use-cases] | [I-D.ietf-raw-use-cases] | |||
| Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. | Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. | |||
| Bernardos, "RAW use cases", Work in Progress, Internet- | Theoleyre, "RAW use-cases", Work in Progress, Internet- | |||
| Draft, draft-ietf-raw-use-cases-03, 20 October 2021, | Draft, draft-ietf-raw-use-cases-05, 23 February 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- | <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- | |||
| cases-03>. | cases-05>. | |||
| [I-D.song-ippm-postcard-based-telemetry] | [I-D.song-ippm-postcard-based-telemetry] | |||
| Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, | Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, | |||
| T., Li, Z., Shin, J., and K. Lee, "In-Situ OAM Marking- | T., Li, Z., Shin, J., and K. Lee, "In-Situ OAM Marking- | |||
| based Direct Export", Work in Progress, Internet-Draft, | based Direct Export", Work in Progress, Internet-Draft, | |||
| draft-song-ippm-postcard-based-telemetry-11, 15 November | draft-song-ippm-postcard-based-telemetry-11, 15 November | |||
| 2021, <https://datatracker.ietf.org/doc/html/draft-song- | 2021, <https://datatracker.ietf.org/doc/html/draft-song- | |||
| ippm-postcard-based-telemetry-11>. | ippm-postcard-based-telemetry-11>. | |||
| [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, | [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, | |||
| skipping to change at page 18, line 46 ¶ | skipping to change at page 18, line 46 ¶ | |||
| L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, | L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, | |||
| "Alternate-Marking Method for Passive and Hybrid | "Alternate-Marking Method for Passive and Hybrid | |||
| Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, | Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, | |||
| January 2018, <https://www.rfc-editor.org/info/rfc8321>. | January 2018, <https://www.rfc-editor.org/info/rfc8321>. | |||
| [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | |||
| Decraene, B., Litkowski, S., and R. Shakir, "Segment | Decraene, B., Litkowski, S., and R. Shakir, "Segment | |||
| Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | |||
| July 2018, <https://www.rfc-editor.org/info/rfc8402>. | July 2018, <https://www.rfc-editor.org/info/rfc8402>. | |||
| [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, | ||||
| "Multipoint Alternate-Marking Method for Passive and | ||||
| Hybrid Performance Monitoring", RFC 8889, | ||||
| DOI 10.17487/RFC8889, August 2020, | ||||
| <https://www.rfc-editor.org/info/rfc8889>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Greg Mirsky | Greg Mirsky | |||
| Ericsson | Ericsson | |||
| Email: gregimirsky@gmail.com | Email: gregimirsky@gmail.com | |||
| Wang Lingqiang | Wang Lingqiang | |||
| ZTE Corporation | ZTE Corporation | |||
| No 19 ,East Huayuan Road | No 19 ,East Huayuan Road | |||
| Beijing | Beijing | |||
| Phone: +86 10 82963945 | Phone: +86 10 82963945 | |||
| Email: wang.lingqiang@zte.com.cn | Email: wang.lingqiang@zte.com.cn | |||
| Guo Zhui | Guo Zhui | |||
| ZTE Corporation | ZTE Corporation | |||
| No 19 ,East Huayuan Road | No 19 ,East Huayuan Road | |||
| Beijing | Beijing | |||
| Phone: +86 10 82963945 | Phone: +86 10 82963945 | |||
| Email: guo.zhui@zte.com.cn | Email: guo.zhui@zte.com.cn | |||
| Haoyu Song | Haoyu Song | |||
| Futurewei Technologies | Futurewei Technologies | |||
| 2330 Central Expressway | 2330 Central Expressway | |||
| Santa Clara, | Santa Clara, | |||
| United States of America | United States of America | |||
| Email: hsong@futurewei.com | Email: hsong@futurewei.com | |||
| Pascal Thubert | ||||
| Cisco Systems, Inc | ||||
| Building D | ||||
| 45 Allee des Ormes - BP1200 | ||||
| 06254 MOUGINS - Sophia Antipolis | ||||
| France | ||||
| Phone: +33 497 23 26 34 | ||||
| Email: pthubert@cisco.com | ||||
| End of changes. 25 change blocks. | ||||
| 29 lines changed or deleted | 48 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||