Hybrid Two-Step Performance Measurement MethodZTE Corp.gregimirsky@gmail.comZTE CorporationNo 19 ,East Huayuan RoadBeijing 100191P.R.China+86 10 82963945 wang.lingqiang@zte.com.cn ZTE CorporationNo 19 ,East Huayuan RoadBeijing 100191P.R.China+86 10 82963945 guo.zhui@zte.com.cn Futurewei Technologies2330 Central ExpresswaySanta ClaraUSAhsong@futurewei.com
Transport
IPPM Working GroupInternet-DraftIPPMHybrid OAM
Development of, and advancements in, automation of network operations brought new requirements
for measurement methodology. Among them is the ability to collect instant network state as the packet
being processed by the networking elements along its path through the domain. This document
introduces a new hybrid measurement method, 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 transporting network state.
Successful resolution of challenges of automated network operation, as part of, for example, overall service orchestration
or data center operation,
relies on a timely collection of accurate information that reflects the state of network elements on an unprecedented
scale. Because performing the analysis and act upon the collected information requires considerable computing and storage
resources, the network state information is unlikely to be processed by the network elements themselves
but will be relayed into the data storage facilities, e.g., data lakes. The process of producing, collecting network state information
also referred to in this document as network telemetry, and transporting it for post-processing
should work equally well with data flows or injected in the network test packets. RFC 7799
describes a combination of elements of passive and active measurement as a hybrid measurement.
Several technical methods have been proposed to enable the collection of network state information
instantaneous to the packet processing, among them and
. The instantaneous, i.e., in the data packet itself, collection
of telemetry information simplifies the process of attribution of telemetry information to the particular monitored flow.
On the other hand, this collection method impacts the data packets, potentially changing their treatment by the networking nodes.
Also, the amount of information the instantaneous method collects might be incomplete because of the limited space it can be allotted.
Other proposals defined methods to collect telemetry information in a separate packet from
each node traversed by the monitored data flow. Examples of
this approach to collecting telemetry information are
and .
These methods allow data collection from any arbitrary path and avoid directly impacting data packets.
On the other hand, the correlation of data and the monitored flow requires that each packet with telemetry information also includes
characteristic information about the monitored flow.
This document introduces Hybrid Two-Step (HTS) as a new method of telemetry collection that improvers
accuracy of a measurement by separating the act of
measuring or calculating the performance metric from the collecting and transporting this information while minimizing the overhead
of the generated load in a network.
HTS method extends the two-step mode of Residence Time Measurement (RTM) defined in to on-path network state
collection and transport. HTS allows the collection of telemetry information from any arbitrary path, does not change data packets of the monitored flow
and makes the process of attribution of telemetry to the data flow simple.
RTM Residence Time MeasurementECMP Equal Cost MultipathMTU Maximum Transmission UnitHTS Hybrid Two-StepHMAC Hashed Message Authentication CodeNetwork telemetry - the process of collecting and reporting of network state
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
when, and only when, they appear in all capitals, as shown here.
Performance measurements are meant to provide data that characterize conditions experienced by traffic flows in the network
and possibly trigger operational changes (e.g., re-route of flows, or changes in resource allocations). Modifications to a network
are determined based on the performance metric information available when a change is to be made.
The correctness of this determination is based on the quality of the collected metrics data. The quality of collected
measurement data is defined by:
the resolution and accuracy of each measurement;predictability of both the time at which each measurement is made and the timeliness of measurement collection data delivery for use.
Consider the case of delay measurement that relies on collecting time
of packet arrival at the ingress interface and time of the packet transmission at the egress interface.
The method includes recording a local clock value on receiving the first octet of an affected message
at the device ingress, and again recording the clock value on transmitting the first byte of the same message
at the device egress. In this ideal case, the difference between the two recorded clock times corresponds
to the time that the message spent in traversing the device. In practice, the time recorded can differ
from the ideal case by any fixed amount. A correction can be applied to compute the same time
difference taking into account the known fixed time associated with the actual measurement.
In this way, the resulting time difference reflects any variable delay associated with queuing.
Depending on the implementation, it may be a challenge to
compute the difference between message arrival and departure times and - on the
fly - add the necessary residence time information to the same message.
And that task may become even more challenging
if the packet is encrypted.
Recording the departure of a packet time
in the same packet may be decremental to the accuracy of the measurement because
the departure time includes the variable time component (such as that associated with buffering
and queuing of the packet). A similar problem may lower the quality of, for example, information
that characterizes utilization of the egress interface. If unable to obtain the data consistently, without
variable delays for additional processing, information may not accurately reflect the egress interface state.
To mitigate this problem defined an RTM two-step mode.
Another challenge associated with methods that collect network state information into the actual data packet is the risk to exceed the
Maximum Transmission Unit (MTU) size, especially if the packet traverses overlay domains or VPNs. Since the fragmentation
is not available at the transport network, operators may have to reduce MTU size advertised to the client layer or risk
missing network state data for the part, most probably the latter part, of the path.
The HTS method consists of two phases:
performing a measurement or obtaining network state information, one or more than one type, on a node;collecting and transporting the measurement.
HTS uses HTS Trigger carried in a data packet or a specially
constructed test packet. For example, an HTS Trigger could be a packet that has
IOAM Option-Type set to the "IOAM Hybrid Two-Step Option-Type"
value (TBA1) allocated by IANA (see ).
The HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type information
. A packet in the flow to which
the Alternate-Marking method is applied can be used as an HTS Trigger.
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.
The HTS method uses the HTS Follow-up packet, referred to
as the follow-up packet, to collect measurement and network state data from the nodes.
The node that creates the HTS Trigger also generates the HTS Follow-up packet.
The follow-up packet contains characteristic information, copied from the trigger packet,
sufficient for participating HTS nodes to associate it with the original
packet. The exact composition of the
characteristic information is specific for each transport network, and its definition is
outside the scope of this document. The follow-up packet also uses the same
encapsulation as the data packet. If not payload but only network information used to load-balance flows in
equal cost multipath (ECMP), use of the network encapsulation identical
to the trigger packet should guarantee that the follow-up
packet remains in-band, i.e., traverses the same set of network
elements, with the original data packet with the HTS Trigger.
Only one outstanding follow-up packet MUST be on the node for the given path.
That means that if the node receives an HTS Trigger
for the flow on which it still waits for the follow-up packet to the previous HTS Trigger, the node will
originate the follow-up packet to transport the former set of the
network state data and transmit it before it sends the follow-up
packet with the latest collection of network state information.
A node that originates the HTS Trigger is referred to as the HTS ingress node.
As stated, the ingress node originates the follow-up packet. The follow-up
packet has the transport network encapsulation identical with the trigger packet
followed by the HTS shim and one or more telemetry information elements
encoded as Type-Length-Value {TLV}. displays an example of the follow-up
packet format.
Fields of the HTS shim are as follows:
Version (Ver) is the two-bits long field. It specifies the version of the HTS shim format.
This document defines the format for the 0b00 value of the field.
HTS Shim Length is the six bits-long field. It defines the length of
the HTS shim in bytes. The minimal value of the field is four bytes.
Flags is eight-bits long. The format of the Flags field displayed in .
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 does not add its telemetry data to avoid exceeding MTU size.
The node originating the follow-up packet MUST zero the Reserved field and ignore it on the receipt.
Sequence Number is 16 bits-long field. The zero-based value of the field reflects the place of
the HTS follow-up packet in the sequence of the HTS follow-up packets that originated in
response to the same HTS trigger. The ingress node MUST set the value of the field to
zero.
Telemetry Data Profile is the optional variable-length field of bit-size flags.
Each flag indicates the requested type of telemetry data to be collected at each HTS node.
The increment of the field is four bytes with a minimum length of zero. For example,
IOAM-Trace-Type information defined in can be used
in the Telemetry Data Profile field.
Telemetry Data TLV is a variable-length field. Multiple TLVs MAY be placed
in an HTS packet. Additional TLVs may be enclosed within a given TLV, subject to the semantics of the (outer) TLV in question.
presents the format of a Telemetry Data TLV, where fields are defined as the following:
Type - a one-octet-long field that characterizes the interpretation of the Value field.
Reserved - one-octet-long field.
Length - two-octet-long field equal to the length of the Value field in octets.
Value - a variable-length field. The value of the Type field determines its interpretation and encoding.
IOAM data fields, defined in , MAY be carried in the Value field.
All multibyte fields defined in this specification are in network byte order.
Upon receiving the trigger packet, the HTS intermediate node MUST:
copy the transport information;
start the HTS Follow-up Timer for the obtained flow.
Upon receiving the follow-up packet, the HTS intermediate node MUST:
verify that the matching transport information exists and the Full flag is cleared,
then stop the associated HTS Follow-up timer;
collect telemetry data requested in the Telemetry Data
Profile field or defined by the local HTS policy;
if adding the collected telemetry would not exceed MTU,
then append data as a new Telemetry Data TLV
and transmit the follow-up packet;
otherwise, set the value of the Full flag to one and transmit
the received a follow-up packet;
originate the new follow-up packet using the same transport information.
The value of the Sequence Number field in the HTS shim MUST be set
to the value of the field in the received follow-up packet incremented by one;
copy collected telemetry data into the first Telemetry Data TLV's Value field
and then transmit the packet.
If the HTS Follow-up Timer expires, the intermediate node MUST:
originate the follow-up packet using transport information associated with the expired timer;
initialize the HTS shim by setting Version field to 0b00 and Sequence Number field to 0.
Values of HTS Shim Length and Telemetry Data Profile fields
MAY be set according to the local policy.
copy telemetry information into Telemetry Data TLV's Value field and transmit the packet.
If the intermediate node receives a "late" follow-up packet,
i.e., a packet to which the node has no associated HTS Follow-up timer,
the node MUST forward the "late" packet.
Upon receiving the trigger packet, the HTS egress node MUST:
copy the transport information;
start the HTS Collection timer for the obtained flow.
When the egress node receives the follow-up packet for the known flow,
i.e., the flow to which the Collection timer is running, the node for each of Telemetry Data TLVs MUST:
if HTS is used in the authenticated mode, verify the authentication of the Telemetry Data TLV using the Authentication sub-TLV (see );
copy telemetry information from the Value field;
restart the corresponding Collection timer.
When the Collection timer expires, the egress relays the
collected telemetry information for processing and analysis
to a local or remote agent.
This specification defines two timers - HTS Follow-up and HTS Collection.
For the particular flow, there MUST be no more than one HTS Trigger,
values of HTS timers bounded by the rate of the trigger generation for that flow.
Previous sections discussed the operation of HTS in a unicast network. Multicast services are important,
and the ability to collect telemetry information is invaluable in delivering a high quality of experience.
While the replication of data packets is necessary, replication of HTS follow-up packets is not.
Replication of multicast data packets down a multicast tree may be set based on multicast routing information
or explicit information included in the special header, as, for example, in Bit-Indexed Explicit Replication
. A replicating node
processes the HTS packet as defined below:
the first transmitted multicast packet MUST be followed
by the received corresponding HTS packet as described in ;each consecutively transmitted copy of the original multicast packet MUST be followed by the new HTS packet
originated by the replicating node that acts as an intermediate HTS node when the HTS Follow-up timer expired.
As a result, there are no duplicate copies of Telemetry Data TLV
for the same pair of ingress and egress interfaces. At the same time,
all ingress/egress pairs traversed by the given multicast packet reflected in their respective Telemetry Data TLV.
Consequently, a centralized controller would reconstruct and analyze the state
of the particular multicast distribution tree based on HTS packets collected from egress nodes.
Telemetry information may be used to drive network operation, closing the control loop for self-driving, self-healing networks.
Thus it is critical to provide a mechanism to protect the telemetry information collected using the HTS method. This document
defines an optional authentication of a Telemetry Data TLV that protects the collected information's integrity.
The format of the Authentication sub-TLV is displayed in .
where fields are defined as follows:
Authentication Type - is a one-octet-long field, value TBA2 allocated by IANA .Length - two-octet-long field, set equal to the length of the Digest field in octets.
HMAC Type - is a one-octet-long field that identifies the type of the HMAC and the length of the digest
and the length of the digest according to the HTS HMAC Type sub-registry (see ).
Digest - is a variable-length field that carries HMAC digest of the text that includes the encompassing TLV.
This specification defines the use of HMAC-SHA-256 truncated to 128 bits () in HTS.
Future specifications may define the use in HTS of more advanced cryptographic algorithms or the use of digest of a different length.
HMAC is calculated as defined in over text as the concatenation of
the Sequence Number field of the follow-up packet (see ) and the
preceding data collected in the Telemetry Data TLV. The digest then MUST be truncated to 128 bits and written into the Digest field.
Distribution and management of shared keys are outside the scope of this document.
In the HTS authenticated mode, the Authentication sub-TLV MUST be present
in each Telemetry Data TLV.
HMAC MUST be verified before using any data in the included Telemetry Data TLV.
If HMAC verification fails, the system MUST stop processing corresponding Telemetry Data TLV and notify an operator.
Specification of the notification mechanism is outside the scope of this document.
The IOAM Option-Type registry is requested in . IANA is requested
to allocate a new code point as listed in .
ValueDescriptionReferenceTBA1IOAM Hybrid Two-Step Option-TypeThis document
IANA is requested to create the HTS TLV Type registry.
All code points in the range 1 through 175 in this registry shall be allocated
according to the "IETF Review" procedure specified in .
Code points in the range
176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure
specified in .
The remaining code points are allocated according to :
ValueDescriptionReference0ReservedThis document1- 175UnassignedThis document176 - 239UnassignedThis document240 - 251ExperimentalThis document252 - 254Private UseThis document255ReservedThis document
IANA is requested to create the HTS sub-TLV Type sub-registry as part of the HTS TLV Type registry.
All code points in the range 1 through 175 in this registry shall be allocated
according to the "IETF Review" procedure specified in .
Code points in the range
176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure
specified in .
The remaining code points are allocated according to :
ValueDescriptionReference0ReservedThis document1- 175UnassignedThis document176 - 239UnassignedThis document240 - 251ExperimentalThis document252 - 254Private UseThis document255ReservedThis documentThis document defines the following new values in the IETF Review range of the HTS sub-TLV Type sub-registry:ValueDescriptionTLV UsedReferenceTBA2HMACAnyThis document
IANA is requested to create the HMAC Type sub-registry as part of the HTS TLV Type registry.
All code points in the range 1 through 127 in this registry shall be allocated
according to the "IETF Review" procedure specified in .
Code points in the range
128 through 239 in this registry shall be allocated according to the "First Come First Served" procedure
specified in .
The remaining code points are allocated according to :
ValueDescriptionReference0ReservedThis document1- 127UnassignedThis document128 - 239UnassignedThis document240 - 249ExperimentalThis document250 - 254Private UseThis document255ReservedThis document This document defines the following new values in the HMAC Type sub-registry:ValueDescriptionReference1HMAC-SHA-256 16 octets longThis document
Nodes that practice the HTS method are presumed to share a trust model that depends on the existence of a trusted
relationship among nodes. This is necessary as these nodes are expected to
correctly modify the specific content of the data in the follow-up packet, and the
degree to which HTS measurement is useful for network operation depends on this ability. In
practice, this means either confidentiality or integrity protection
cannot cover those portions of messages that contain the network state data. Though
there are methods that make it possible in theory to provide either
or both such protections and still allow for intermediate nodes to
make detectable yet authenticated modifications, such methods do not
seem practical at present, particularly for protocols that used to
measure latency and/or jitter.
This document defines the use of authentication () to protect the integrity of
the telemetry information collected using the HTS method. Privacy protection can be achieved by, for example, sharing
the IPsec tunnel with a data flow that generates information that is collected using HTS.
While it is possible for a supposed compromised node to intercept and
modify the network state information in the follow-up packet;
this is an issue that exists for nodes in
general - for all data that to be carried over the particular networking
technology - and is therefore the basis for an additional presumed trust model
associated with an existing network.
Authors express their gratitude and appreciation to Joel Halpern
for the most helpful and insightful discussion on the applicability of
HTS in a Service Function Chaining domain.
In-band Network Telemetry (INT)