< draft-gandhi-spring-twamp-srpm-00.txt | draft-gandhi-spring-twamp-srpm-01.txt > | |||
---|---|---|---|---|
SPRING Working Group R. Gandhi, Ed. | SPRING Working Group R. Gandhi, Ed. | |||
Internet-Draft C. Filsfils | Internet-Draft C. Filsfils | |||
Intended Status: Standards Track Cisco Systems, Inc. | Intended Status: Standards Track Cisco Systems, Inc. | |||
Expires: August 13, 2019 D. Voyer | Expires: November 16, 2019 D. Voyer | |||
Bell Canada | Bell Canada | |||
February 9, 2019 | M. Chen | |||
Huawei | ||||
May 15, 2019 | ||||
In-band Performance Measurement Using TWAMP | Performance Measurement Using TWAMP | |||
for Segment Routing Networks | for Segment Routing Networks | |||
draft-gandhi-spring-twamp-srpm-00 | draft-gandhi-spring-twamp-srpm-01 | |||
Abstract | Abstract | |||
Segment Routing (SR) is applicable to both Multiprotocol Label | Segment Routing (SR) is applicable to both Multiprotocol Label | |||
Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document | Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document | |||
specifies procedures for sending and processing in-band probe query | specifies procedures for sending and processing synthetic probe query | |||
and response messages for Performance Measurement. The procedure | and response messages for Performance Measurement (PM). The | |||
uses the mechanisms defined in RFC 5357 (Two-Way Active Measurement | procedure uses the mechanisms defined in RFC 5357 (Two-Way Active | |||
Protocol (TWAMP)) for Delay Measurement, and also uses the mechanisms | Measurement Protocol (TWAMP)) for Delay Measurement, and also uses | |||
for direct-mode loss measurement defined in this document. The | the mechanisms specified in this document for direct-mode Loss | |||
procedure specified is applicable to SR-MPLS and SRv6 data planes for | Measurement. The procedure specified is applicable to SR-MPLS and | |||
both links and end-to-end measurement for SR Policies. | SRv6 data planes for both links and end-to-end measurement for SR | |||
Policies. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
skipping to change at page 2, line 14 ¶ | skipping to change at page 2, line 17 ¶ | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | |||
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 | 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Reference Topology . . . . . . . . . . . . . . . . . . . . 4 | 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . . 4 | |||
2.4. In-band Probe Messages . . . . . . . . . . . . . . . . . . 5 | ||||
3. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 5 | 3.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 5 | |||
3.1.1. Delay Measurement Probe Query Message . . . . . . . . 5 | 3.1.1. Delay Measurement Probe Query Message . . . . . . . . 6 | |||
3.1.2. Loss Measurement Probe Query Message . . . . . . . . . 6 | 3.1.1.1. Delay Measurement Message Checksum Complement . . 6 | |||
3.1.1.2. Delay Measurement Authentication Mode . . . . . . 7 | ||||
3.1.2. Loss Measurement Probe Query Message . . . . . . . . . 7 | ||||
3.1.2.1. Loss Measurement Message Checksum Complement . . . 10 | ||||
3.1.2.2. Loss Measurement Authentication Mode . . . . . . . 10 | ||||
3.1.3. Probe Query for SR Links . . . . . . . . . . . . . . . 10 | 3.1.3. Probe Query for SR Links . . . . . . . . . . . . . . . 10 | |||
3.1.4. Probe Query for End-to-end Measurement for SR Policy . 11 | 3.1.4. Probe Query for End-to-end Measurement for SR Policy . 10 | |||
3.1.4.1. Probe Query Message for SR-MPLS Policy . . . . . . 11 | 3.1.4.1. Probe Query Message for SR-MPLS Policy . . . . . . 10 | |||
3.1.4.2. Probe Query Message for SRv6 Policy . . . . . . . 11 | 3.1.4.2. Probe Query Message for SRv6 Policy . . . . . . . 11 | |||
3.2. Probe Response Message . . . . . . . . . . . . . . . . . . 12 | 3.2. Probe Response Message . . . . . . . . . . . . . . . . . . 12 | |||
3.2.1. One-way Measurement . . . . . . . . . . . . . . . . . 12 | 3.2.1. One-way Measurement Mode . . . . . . . . . . . . . . . 14 | |||
3.2.2. Two-way Measurement . . . . . . . . . . . . . . . . . 12 | 3.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . . 15 | |||
3.2.2.1. Probe Response Message for SR-MPLS Policy . . . . 13 | 3.2.2.1. Return Path TLV . . . . . . . . . . . . . . . . . 15 | |||
3.2.2.2. Probe Response Message for SRv6 Policy . . . . . . 13 | 3.2.2.2. Probe Response Message for SR-MPLS Policy . . . . 16 | |||
4. Packet Loss Calculation . . . . . . . . . . . . . . . . . . . 13 | 3.2.2.3. Probe Response Message for SRv6 Policy . . . . . . 17 | |||
5. Performance Measurement for P2MP SR Policies . . . . . . . . . 14 | 3.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 17 | |||
6. ECMP Support . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 4. Packet Loss Calculation . . . . . . . . . . . . . . . . . . . 17 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 5. Performance Measurement for P2MP SR Policies . . . . . . . . . 18 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 6. ECMP Support for SR Policies . . . . . . . . . . . . . . . . . 18 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
1. Introduction | 1. Introduction | |||
Segment Routing (SR) technology greatly simplifies network operations | Segment Routing (SR) technology greatly simplifies network operations | |||
for Software Defined Networks (SDNs). SR is applicable to both | for Software Defined Networks (SDNs). SR is applicable to both | |||
Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. | Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. | |||
SR takes advantage of the Equal-Cost Multipaths (ECMPs) between | SR takes advantage of the Equal-Cost Multipaths (ECMPs) between | |||
source, transit and destination nodes. SR Policies as defined in | source, transit and destination nodes. SR Policies as defined in | |||
[I-D.spring-segment-routing-policy] are used to steer traffic through | [I-D.spring-segment-routing-policy] are used to steer traffic through | |||
a specific, user-defined path using a stack of Segments. Built-in SR | a specific, user-defined path using a stack of Segments. Built-in SR | |||
Performance Measurement (PM) is one of the essential requirements to | Performance Measurement (PM) is one of the essential requirements to | |||
provide Service Level Agreements (SLAs). | provide Service Level Agreements (SLAs). | |||
The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] | The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] | |||
and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] | and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] | |||
provide capabilities for the measurement of various performance | provide capabilities for the measurement of various performance | |||
skipping to change at page 3, line 15 ¶ | skipping to change at page 3, line 20 ¶ | |||
SR takes advantage of the Equal-Cost Multipaths (ECMPs) between | SR takes advantage of the Equal-Cost Multipaths (ECMPs) between | |||
source, transit and destination nodes. SR Policies as defined in | source, transit and destination nodes. SR Policies as defined in | |||
[I-D.spring-segment-routing-policy] are used to steer traffic through | [I-D.spring-segment-routing-policy] are used to steer traffic through | |||
a specific, user-defined path using a stack of Segments. Built-in SR | a specific, user-defined path using a stack of Segments. Built-in SR | |||
Performance Measurement (PM) is one of the essential requirements to | Performance Measurement (PM) is one of the essential requirements to | |||
provide Service Level Agreements (SLAs). | provide Service Level Agreements (SLAs). | |||
The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] | The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] | |||
and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] | and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] | |||
provide capabilities for the measurement of various performance | provide capabilities for the measurement of various performance | |||
metrics in IP networks. These protocols rely on control channel | metrics in IP networks using synthetic probe messages. These | |||
signaling to establish a test channel over an UDP path. These | protocols rely on control channel signaling to establish a test | |||
protocols lack support for direct-mode Loss Measurement (LM) to | channel over an UDP path. These protocols lack support for | |||
detect actual data traffic loss which is required in SR networks. | direct-mode Loss Measurement (LM) to detect actual data traffic loss | |||
The Simple Two-way Active Measurement Protocol (STAMP) | which is required in SR networks. The Simple Two-way Active | |||
[I-D.ippm-stamp] alleviates the control channel signaling by using | Measurement Protocol (STAMP) [I-D.ippm-stamp] alleviates the control | |||
configuration data model to provision test channels and required UDP | channel signaling by using configuration data model to provision test | |||
ports. The TWAMP Light from broadband forum [BBF.TR-390] provides | channels and UDP ports. The TWAMP Light from broadband forum | |||
simplified mechanisms for active performance measurement in Customer | [BBF.TR-390] provides simplified mechanisms for active performance | |||
Edge IP networks. | measurement in Customer Edge IP networks. | |||
This document specifies procedures for sending and processing in-band | This document specifies procedures for sending and processing | |||
probe query and response messages for Performance Measurement. The | synthetic probe query and response messages for Performance | |||
procedure uses the mechanisms defined in RFC 5357 (Two-Way Active | Measurement. The procedure uses the mechanisms defined in RFC 5357 | |||
Measurement Protocol (TWAMP)) for Delay Measurement, and also uses | (Two-Way Active Measurement Protocol (TWAMP)) for Delay Measurement | |||
the mechanisms for direct-mode loss measurement defined in this | (DM), and also uses the mechanisms specified in this document for | |||
document. The procedure specified is applicable to SR-MPLS and SRv6 | direct-mode Loss Measurement (LM). The procedure specified is | |||
data planes for both links and end-to-end measurement for SR | applicable to SR-MPLS and SRv6 data planes for both links and | |||
Policies. For SR Policies, there are ECMPs between the source and | end-to-end measurement for SR Policies. For SR Policies, there are | |||
transit nodes, between transit nodes and between transit and | Equal Cost Multi-Paths (ECMP) between the source and transit nodes, | |||
destination nodes. This document also defines mechanisms for | between transit nodes and between transit and destination nodes. | |||
handling ECMPs of SR Policies for performance delay measurement. | This document also defines mechanisms for handling ECMPs of SR | |||
Policies for performance delay measurement. | ||||
2. Conventions Used in This Document | 2. Conventions Used in This Document | |||
2.1. Requirements Language | 2.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119] [RFC8174] | document are to be interpreted as described in [RFC2119] [RFC8174] | |||
when, and only when, they appear in all capitals, as shown here. | when, and only when, they appear in all capitals, as shown here. | |||
skipping to change at page 5, line 13 ¶ | skipping to change at page 5, line 16 ¶ | |||
leaf nodes [I-D.spring-sr-p2mp-policy]. | leaf nodes [I-D.spring-sr-p2mp-policy]. | |||
+-------+ Query +-------+ | +-------+ Query +-------+ | |||
| | - - - - - - - - - ->| | | | | - - - - - - - - - ->| | | |||
| R1 |---------------------| R5 | | | R1 |---------------------| R5 | | |||
| |<- - - - - - - - - - | | | | |<- - - - - - - - - - | | | |||
+-------+ Response +-------+ | +-------+ Response +-------+ | |||
Reference Topology | Reference Topology | |||
Both Delay and Loss performance measurement is performed in-band for | For delay and loss measurements, for both links and end-to-end SR | |||
the traffic traversing between node R1 and node R5. One-way delay | Policies, no PM session is created on the responder node R5. One-way | |||
and two-way delay measurements are defined in [RFC4656] and | delay and two-way delay measurements are defined in [RFC4656] and | |||
[RFC5357], respectively. One-way loss measurement provides receive | [RFC5357], respectively. One-way loss measurement provides receive | |||
packet loss whereas two-way loss measurement provides both transmit | packet loss whereas two-way loss measurement provides both transmit | |||
and receive packet loss. | and receive packet loss. | |||
2.4. In-band Probe Messages | For Performance Measurement, synthetic probe query and response | |||
messages are used as following: | ||||
For both Delay and Loss measurements for links and SR Policies, no PM | o For Delay Measurement, the probe messages are sent on the | |||
session is created on the responder node. The probe messages for | congruent path of the data traffic by the querier node, and are | |||
Delay measurement are sent in-band by the querier node to measure the | used to measure the delay experienced by the actual data traffic | |||
delay experienced by the actual traffic flowing on the links and SR | flowing on the links and SR Policies. | |||
Policies. For Loss measurement, in-band probe messages are used to | ||||
collect the traffic counter for the incoming link or incoming SID on | o For Loss Measurement, the probe messages are sent on the congruent | |||
which the probe query message is received at the responder node R5 as | path of the data traffic by the querier node, and are used to | |||
it has no PM session state present on the node. The performance | collect the receive traffic counters for the incoming link or | |||
measurement for Delay and Loss using out-of-band probe query messages | incoming SID where the probe query messages are received at the | |||
are outside the scope of this document. | responder node (incoming link or incoming SID used as the | |||
responder node has no PM session state present). | ||||
The In-Situ Operations, Administration, and Maintenance (IOAM) | ||||
mechanisms for SR-MPLS defined in [I-D.spring-ioam-sr-mpls] and for | ||||
SRv6 defined in [I-D.spring-srv6-oam] are used to carry PM | ||||
information in-band as part of the data traffic, and are outside the | ||||
scope of this document. | ||||
3. Probe Messages | 3. Probe Messages | |||
3.1. Probe Query Message | 3.1. Probe Query Message | |||
In this document, procedures using [RFC5357] is used for Delay and | In this document, the probe messages defined in [RFC5357] are used | |||
Loss measurements for SR links and end-to-end SR Policies. A | for Delay and Loss measurements for SR links and end-to-end SR | |||
user-configured UDP port is used for identifying PM probe packets | Policies. The user-configured UDP ports (separate UDP port for each | |||
that does not require to bootstrap PM sessions. A UDP port number | message format) are used for identifying the PM probe packets and to | |||
from the Dynamic and/or Private Ports range 49152-65535 is used as | avoid signaling to bootstrap PM sessions. This approach is similar | |||
the destination UDP port. This approach is similar to the one | to the one defined in STAMP protocol [I-D.ippm-stamp]. The IPv4 TTL | |||
defined in STAMP protocol [I-D.ippm-stamp]. The IPv4 TTL or IPv6 Hop | or IPv6 Hop Limit field of the IP header MUST be set to 255. | |||
Limit field of the IP header MUST be set to 255. | ||||
3.1.1. Delay Measurement Probe Query Message | 3.1.1. Delay Measurement Probe Query Message | |||
The message content for Delay Measurement probe query message using | The message content for Delay Measurement probe query message using | |||
UDP header [RFC768] is shown in Figure 1. The DM probe query message | UDP header [RFC768] is shown in Figure 1. The DM probe query message | |||
is sent with user-configured Destination UDP port number [I-D.ippm- | is sent with user-configured Destination UDP port number for DM. The | |||
stamp]. The Source UDP port is set to the same value for two-way | Destination UDP port cannot be used as Source port, since the message | |||
delay measurement. The DM probe query message contains the payload | does not have any indication to distinguish between query and | |||
for delay measurement defined in Section 4.2.1 of [RFC5357] for TWAMP | response. The DM probe query message contains the payload for delay | |||
or in Section 4.1.2 of [RFC4656] for OWAMP. | measurement defined in Section 4.1.2 of OWAMP [RFC4656]. As an | |||
alternative, the DM probe query message contains the payload defined | ||||
in Section 4.2.1 of TWAMP [RFC5357]. | ||||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| IP Header | | | IP Header | | |||
. Source IP Address = Querier IPv4 or IPv6 Address . | . Source IP Address = Querier IPv4 or IPv6 Address . | |||
. Destination IP Address = Responder IPv4 or IPv6 Address . | . Destination IP Address = Responder IPv4 or IPv6 Address . | |||
. Protocol = UDP . | . Protocol = UDP . | |||
. Router Alert Option Not Set . | . Router Alert Option Not Set . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| UDP Header | | | UDP Header | | |||
skipping to change at page 6, line 28 ¶ | skipping to change at page 6, line 43 ¶ | |||
. Destination Port = User-configured Port for Delay Measurement. | . Destination Port = User-configured Port for Delay Measurement. | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| Payload = Message as specified in Section 4.2.1 of RFC 5357 | | | Payload = Message as specified in Section 4.2.1 of RFC 5357 | | |||
| | Payload = Message as specified in Section 4.1.2 of RFC 4656 | | | | Payload = Message as specified in Section 4.1.2 of RFC 4656 | | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 1: DM Probe Query Message | Figure 1: DM Probe Query Message | |||
Timestamp field is eight bytes and by default uses the IEEE 1588v2 | Timestamp field is eight bytes. It is recommended to use the IEEE | |||
Precision Time Protocol (PTP) truncated 64-bit timestamp format | 1588v2 Precision Time Protocol (PTP) truncated 64-bit timestamp | |||
[IEEE1588]. | format [IEEE1588] using the procedure defined in [RFC8186]. | |||
3.1.2. Loss Measurement Probe Query Message | 3.1.1.1. Delay Measurement Message Checksum Complement | |||
The message content for Loss Measurement probe query message using | The Checksum Complement shown in Figure 3 for OWAMP in [RFC7820] and | |||
UDP header [RFC768] is shown in Figure 2. The LM probe query message | Figure 4 for TWAMP in [RFC7820] for delay measurement message format | |||
is sent with user-configured Destination UDP port number [I-D.ippm- | follows the procedure defined in [RFC7820] and can be used optionally | |||
stamp]. The Source UDP port is set to the same value for two-way | with the procedures defined in this document. | |||
loss measurement. The LM probe query message contains the payload | ||||
for loss measurement defined below. | ||||
+---------------------------------------------------------------+ | 3.1.1.2. Delay Measurement Authentication Mode | |||
| IP Header | | ||||
. Source IP Address = Querier IPv4 or IPv6 Address . | ||||
. Destination IP Address = Responder IPv4 or IPv6 Address . | ||||
. Protocol = UDP . | ||||
. Router Alert Option Not Set . | ||||
. . | ||||
+---------------------------------------------------------------+ | ||||
| UDP Header | | ||||
. Source Port = As chosen by Querier . | ||||
. Destination Port = User-configured Port for Loss Measurement . | When using the authenticated mode for delay measurement, the matching | |||
. . | authentication type (e.g. HMAC-SHA-256) and key are user-configured | |||
+---------------------------------------------------------------+ | on both the querier and responder nodes. A different user-configured | |||
| Sequence Number | | destination UDP port is required for the delay measurement in | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authentication mode due to the different probe message format. | |||
| Transmit Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Receive Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender TTL | Block Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Padding | | ||||
. . | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 2A: LM Probe Query Message for TWAMP | 3.1.2. Loss Measurement Probe Query Message | |||
+---------------------------------------------------------------+ | The message content for Loss Measurement probe query message using | |||
| IP Header | | UDP header [RFC768] is shown in Figure 2. The LM probe query message | |||
. Source IP Address = Querier IPv4 or IPv6 Address . | is sent with user-configured Destination UDP port number for LM. | |||
. Destination IP Address = Responder IPv4 or IPv6 Address . | Different Destination UDP ports are used for direct-mode and | |||
. Protocol = UDP . | inferred-mode loss measurements. The Destination UDP port cannot be | |||
. Router Alert Option Not Set . | used as Source port, since the message does not have any indication | |||
. . | to distinguish between query and response. The LM probe query | |||
+---------------------------------------------------------------+ | message contains the payload for loss measurement as defined in | |||
| UDP Header | | Figure 2. An alternative, the LM probe query message contains the | |||
. Source Port = As chosen by Querier . | payload defined in Figure 8. | |||
. Destination Port = User-configured Port for Loss Measurement . | ||||
. . | ||||
+---------------------------------------------------------------+ | ||||
| Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (12 octets) | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Transmit Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (8 octets) | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Receive Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (8 octets) | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (12 octets) | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (8 octets) | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender TTL | Block Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (12 octets) | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| HMAC (16 octets) | | ||||
| | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Padding | | ||||
. . | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 2B: LM Probe Query Message for TWAMP - Authenticated Mode | Both of these LM message formats define fixed locations for the | |||
counters in the payload and are easy to implement in hardware. In | ||||
addition, new LM messages do not require any backwards compatibility | ||||
or support for the existing DM message formats in [RFC5357]. | ||||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| IP Header | | | IP Header | | |||
. Source IP Address = Querier IPv4 or IPv6 Address . | . Source IP Address = Querier IPv4 or IPv6 Address . | |||
. Destination IP Address = Responder IPv4 or IPv6 Address . | . Destination IP Address = Responder IPv4 or IPv6 Address . | |||
. Protocol = UDP . | . Protocol = UDP . | |||
. Router Alert Option Not Set . | . Router Alert Option Not Set . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| UDP Header | | | UDP Header | | |||
skipping to change at page 9, line 4 ¶ | skipping to change at page 7, line 42 ¶ | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| IP Header | | | IP Header | | |||
. Source IP Address = Querier IPv4 or IPv6 Address . | . Source IP Address = Querier IPv4 or IPv6 Address . | |||
. Destination IP Address = Responder IPv4 or IPv6 Address . | . Destination IP Address = Responder IPv4 or IPv6 Address . | |||
. Protocol = UDP . | . Protocol = UDP . | |||
. Router Alert Option Not Set . | . Router Alert Option Not Set . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| UDP Header | | | UDP Header | | |||
. Source Port = As chosen by Querier . | . Source Port = As chosen by Querier . | |||
. Destination Port = User-configured Port for Loss Measurement . | . Destination Port = User-configured Port for Loss Measurement . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| Sequence Number | | | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Transmit Counter | | | Transmit Counter | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Sender TTL | Block Number | | | Sender TTL |X|B|0|0|0|0|0|0| Block Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Padding | | | | | |||
. Packet Padding . | ||||
. . | . . | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Checksum Complement | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2C: LM Probe Query Message for OWAMP | Figure 2A: LM Probe Query Message for OWAMP | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| IP Header | | | IP Header | | |||
. Source IP Address = Querier IPv4 or IPv6 Address . | . Source IP Address = Querier IPv4 or IPv6 Address . | |||
. Destination IP Address = Responder IPv4 or IPv6 Address . | . Destination IP Address = Responder IPv4 or IPv6 Address . | |||
. Protocol = UDP . | . Protocol = UDP . | |||
. Router Alert Option Not Set . | . Router Alert Option Not Set . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| UDP Header | | | UDP Header | | |||
skipping to change at page 9, line 46 ¶ | skipping to change at page 8, line 39 ¶ | |||
| MBZ (12 octets) | | | MBZ (12 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Transmit Counter | | | Transmit Counter | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MBZ (8 octets) | | | MBZ (8 octets) | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Sender TTL | Block Number | | | Sender TTL |X|B|0|0|0|0|0|0| Block Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MBZ (12 octets) | | | MBZ (12 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| HMAC (16 octets) | | | HMAC (16 octets) | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Padding | | | | | |||
. Packet Padding . | ||||
. . | . . | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Checksum Complement | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2D: LM Probe Query Message for OWAMP - Authenticated Mode | Figure 2B: LM Probe Query Message for OWAMP - Authenticated Mode | |||
Sequence Number (32-bit): As defined in [RFC5357]. | Sequence Number (32-bit): As defined in [RFC5357]. | |||
Transmit Counter (64-bit): The number of packets sent by the querier | Transmit Counter (64-bit): The number of packets sent by the querier | |||
node in the query message and by the responder node in the response | node in the query message and by the responder node in the response | |||
message. The counter is always written at fixed location in the | message. The counter is always written at the fixed location in the | |||
probe query and response messages. | probe query and response messages. | |||
Receive Counter (64-bit): The number of packets received at the | Receive Counter (64-bit): The number of packets received at the | |||
responder node. It is written by the responder node in the probe | responder node. It is written by the responder node in the probe | |||
response message. | response message. | |||
Sender Counter (64-bit): This is the exact copy of the transmit | Sender Counter (64-bit): This is the exact copy of the transmit | |||
counter from the received query message. It is written by the | counter from the received query message. It is written by the | |||
responder node in the probe response message. | responder node in the probe response message. | |||
Sender Sequence Number (32-bit): As defined in [RFC5357]. | Sender Sequence Number (32-bit): As defined in [RFC5357]. | |||
Sender TTL: As defined in [RFC5357]. | Sender TTL: As defined in [RFC5357]. | |||
Block Number (24-bit): The Loss Measurement using Alternate-Marking | Flag: The meanings of the Flag bits are: | |||
X: Extended counter format indicator. Indicates the use of | ||||
extended (64-bit) counter values. Initialized to 1 upon creation | ||||
(and prior to transmission) of an LM Query and copied from an LM | ||||
Query to an LM response. Set to 0 when the LM message is | ||||
transmitted or received over an interface that writes 32-bit | ||||
counter values. | ||||
B: Octet (byte) count. When set to 1, indicates that the Counter | ||||
1-4 fields represent octet counts. The octet count applies to all | ||||
packets within the LM scope, and the octet count of a packet sent | ||||
or received over a channel includes the total length of that | ||||
packet (but excludes headers, labels, or framing of the channel | ||||
itself). When set to 0, indicates that the Counter fields | ||||
represent packet counts. | ||||
0: Set to 0. | ||||
Block Number (16-bit): The Loss Measurement using Alternate-Marking | ||||
method defined in [RFC8321] requires to identify the Block Number (or | method defined in [RFC8321] requires to identify the Block Number (or | |||
color) of the traffic counters. The probe query and response | color) of the traffic counters. The probe query and response | |||
messages carry Block Number for the traffic counters for loss | messages carry Block Number for the traffic counters for loss | |||
measurement. In both probe query and response messages, the counters | measurement. In both probe query and response messages, the counters | |||
MUST belong to the same Block Number. | MUST belong to the same Block Number. | |||
The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of | HMAC: The PM probe packet in authenticated mode includes a key Hashed | |||
the SR-MPLS Policy is used for accounting received traffic on the | Message Authentication Code (HMAC) ([RFC2104]) hash. Each probe | |||
egress node for loss measurement. | query and response messages are authenticated by adding Sequence | |||
Number with Hashed Message Authentication Code (HMAC) TLV. It can | ||||
use HMAC-SHA-256 truncated to 128 bits (similarly to the use of it in | ||||
IPSec defined in [RFC4868]); hence the length of the HMAC field is 16 | ||||
octets. | ||||
HMAC uses own key and the definition of the mechanism to distribute | ||||
the HMAC key is outside the scope of this document. | ||||
In authenticated mode, only the sequence number is encrypted, and the | ||||
other payload fields are sent in clear text. The probe packet MAY | ||||
include Comp.MBZ (Must Be Zero) variable length field to align the | ||||
packet on 16 octets boundary. | ||||
3.1.2.1. Loss Measurement Message Checksum Complement | ||||
The Checksum Complement shown in Figure 2 for loss measurement | ||||
message format follows the procedure defined in [RFC7820] and can be | ||||
used optionally with the procedures defined in this document. | ||||
3.1.2.2. Loss Measurement Authentication Mode | ||||
When using the authenticated mode for loss measurement, the matching | ||||
authentication type (e.g. HMAC-SHA-256) and key are user-configured | ||||
on both the querier and responder nodes. A different user-configured | ||||
destination UDP port is required for the loss measurement in | ||||
authentication mode due to the different message format. | ||||
3.1.3. Probe Query for SR Links | 3.1.3. Probe Query for SR Links | |||
The probe query message as defined in Figure 1 is sent in-band for | The probe query message as defined in Figure 1 is sent on the | |||
Delay measurement. The probe query message as defined in Figure 2 is | congruent path of the data traffic for Delay measurement. The probe | |||
sent in-band for Loss measurement. | query message as defined in Figure 2 is sent on the congruent path of | |||
the data traffic for Loss measurement. | ||||
3.1.4. Probe Query for End-to-end Measurement for SR Policy | 3.1.4. Probe Query for End-to-end Measurement for SR Policy | |||
3.1.4.1. Probe Query Message for SR-MPLS Policy | 3.1.4.1. Probe Query Message for SR-MPLS Policy | |||
The message content for in-band probe query message using UDP header | The message content for the probe query message using UDP header for | |||
for end-to-end performance measurement of SR-MPLS Policy is shown in | end-to-end performance measurement of SR-MPLS Policy is shown in | |||
Figure 3. | Figure 3. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Segment List(0) | TC |S| TTL | | | Segment List(1) | TC |S| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Segment List(n) | TC |S| TTL | | | Segment List(n) | TC |S| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| PSID | TC |S| TTL | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Message as shown in Figure 1 for DM or Figure 2 for LM | | | Message as shown in Figure 1 for DM or Figure 2 for LM | | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 3: Probe Query Message for SR-MPLS Policy | Figure 3: Probe Query Message for SR-MPLS Policy | |||
The Segment List (SL) can be empty to indicate Implicit NULL label | The Segment List (SL) can be empty to indicate Implicit NULL label | |||
case. | case. | |||
The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of | ||||
the SR-MPLS Policy is used for accounting received traffic on the | ||||
egress node for loss measurement. The PSID is not required for | ||||
end-to-end SR Policy delay measurement. | ||||
3.1.4.2. Probe Query Message for SRv6 Policy | 3.1.4.2. Probe Query Message for SRv6 Policy | |||
The in-band probe query messages using UDP header for end-to-end | An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and | |||
performance measurement of an SRv6 Policy is sent using SRv6 Segment | a Segment List as defined in [I-D.6man-segment-routing-header]. The | |||
Routing Header (SRH) and Segment List of the SRv6 Policy as defined | probe query messages using UDP header for end-to-end performance | |||
in [I-D.6man-segment-routing-header] and is shown in Figure 4. | measurement of an SRv6 Policy is sent using its SRv6 Segment Routing | |||
Header (SRH) and Segment List as shown in Figure 4. | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SRH | | | SRH | | |||
. END.OTP (DM) or END.OP (LM) with Target SRv6 SID . | . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message as shown in Figure 1 for DM or Figure 2 for LM | | | Message as shown in Figure 1 for DM or Figure 2 for LM | | |||
. (Using IPv6 Addresses) . | . (Using IPv6 Addresses) . | |||
skipping to change at page 11, line 50 ¶ | skipping to change at page 12, line 4 ¶ | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SRH | | | SRH | | |||
. END.OTP (DM) or END.OP (LM) with Target SRv6 SID . | . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message as shown in Figure 1 for DM or Figure 2 for LM | | | Message as shown in Figure 1 for DM or Figure 2 for LM | | |||
. (Using IPv6 Addresses) . | . (Using IPv6 Addresses) . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 4: Probe Query Message for SRv6 Policy | Figure 4: Probe Query Message for SRv6 Policy | |||
For delay measurement of SRv6 Policy, END function END.OTP | For delay measurement of SRv6 Policy using SRH, END function END.OTP | |||
[I-D.spring-srv6-oam] is used with the target SRv6 SID to punt probe | [I-D.spring-srv6-oam] is used with the target SRv6 SID to punt probe | |||
messages on the target node, as shown in Figure 4. Similarly, for | messages on the target node, as shown in Figure 4. Similarly, for | |||
loss measurement of SRv6 Policy, END function END.OP | loss measurement of SRv6 Policy, END function END.OP | |||
[I-D.spring-srv6-oam] is used with target SRv6 SID to punt probe | [I-D.spring-srv6-oam] is used with target SRv6 SID to punt probe | |||
messages on the target node. | messages on the target node. | |||
3.2. Probe Response Message | 3.2. Probe Response Message | |||
The probe response message is sent using the IP/UDP information from | The probe response message is sent using the IP/UDP information from | |||
the probe query message. The content of the probe response message | the probe query message. The content of the probe response message | |||
skipping to change at page 12, line 31 ¶ | skipping to change at page 12, line 35 ¶ | |||
. Destination IP Address = Source IP Address from Query . | . Destination IP Address = Source IP Address from Query . | |||
. Protocol = UDP . | . Protocol = UDP . | |||
. Router Alert Option Not Set . | . Router Alert Option Not Set . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| UDP Header | | | UDP Header | | |||
. Source Port = As chosen by Responder . | . Source Port = As chosen by Responder . | |||
. Destination Port = Source Port from Query . | . Destination Port = Source Port from Query . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| Payload as specified in Section 4.2.1 of RFC 5357, or | | | DM Payload as specified in Section 4.2.1 of RFC 5357, or | | |||
. Payload as specified in Figure 2 in this document . | . LM Payload as specified in Figure 8 in this document . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 5: Probe Response Message | Figure 5: Probe Response Message | |||
3.2.1. One-way Measurement | +---------------------------------------------------------------+ | |||
| IP Header | | ||||
. Source IP Address = Querier IPv4 or IPv6 Address . | ||||
. Destination IP Address = Responder IPv4 or IPv6 Address . | ||||
. Protocol = UDP . | ||||
. Router Alert Option Not Set . | ||||
. . | ||||
+---------------------------------------------------------------+ | ||||
| UDP Header | | ||||
. Source Port = As chosen by Querier . | ||||
For one-way performance measurement, the probe response message as | . Destination Port = User-configured Port for Loss Measurement . | |||
defined in Figure 5 is sent for both SR links and SR Policies. | . . | |||
+---------------------------------------------------------------+ | ||||
| Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Transmit Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Receive Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender TTL |X|B|0|0|0|0|0|0| Block Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | ||||
. . | ||||
. Packet Padding . | ||||
. . | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Checksum Complement | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.2.2. Two-way Measurement | Figure 8A: LM Probe Response Message for TWAMP | |||
For two-way performance measurement, when using a bidirectional | +---------------------------------------------------------------+ | |||
channel, the probe response message as defined in Figure 5 is sent | | IP Header | | |||
back in-band to the querier node. | . Source IP Address = Querier IPv4 or IPv6 Address . | |||
. Destination IP Address = Responder IPv4 or IPv6 Address . | ||||
. Protocol = UDP . | ||||
. Router Alert Option Not Set . | ||||
. . | ||||
+---------------------------------------------------------------+ | ||||
| UDP Header | | ||||
. Source Port = As chosen by Querier . | ||||
. Destination Port = User-configured Port for Loss Measurement . | ||||
. . | ||||
+---------------------------------------------------------------+ | ||||
| Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (12 octets) | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Transmit Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (8 octets) | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Receive Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (8 octets) | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (12 octets) | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender Counter | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (8 octets) | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender TTL |X|B|0|0|0|0|0|0| Block Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| MBZ (12 octets) | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| HMAC (16 octets) | | ||||
| | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | ||||
. . | ||||
. Packet Padding . | ||||
. . | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Checksum Complement | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of | Figure 8B: LM Probe Response Message for TWAMP - Authenticated Mode | |||
the forward SR Policy can be used to find the reverse SR Policy to | ||||
send the probe response message for two-way measurement of SR Policy. | ||||
3.2.2.1. Probe Response Message for SR-MPLS Policy | 3.2.1. One-way Measurement Mode | |||
In one-way performance measurement mode, the probe response message | ||||
as defined in Figure 5 is sent for both SR links and SR Policies. | ||||
The message content for sending probe response message in-band using | 3.2.2. Two-way Measurement Mode | |||
UDP header for two-way end-to-end performance measurement of an | ||||
SR-MPLS Policy is shown in Figure 6. | In two-way performance measurement mode, when using a bidirectional | |||
path, the probe response message as defined in Figure 5 is sent back | ||||
on the congruent path of the data traffic to the querier node. | ||||
3.2.2.1. Return Path TLV | ||||
For two-way performance measurement, the responder node needs to send | ||||
the probe response message on a specific reverse SR path. This way | ||||
the destination node does not require any additional SR Policy state. | ||||
The querier node can request in the probe query message to the | ||||
responder node to send a response back on a given reverse path | ||||
(typically co-routed path for two-way measurement). | ||||
[I-D.ippm-stamp-option-tlv] defines STAMP probe query messages that | ||||
can include one or more optional TLVs. New TLV Type (TBA1) is | ||||
defined in this document for Return Path to carry reverse SR path for | ||||
probe response messages (in the payload of the message). The format | ||||
of the Return Path TLV is shown in Figure 8A and 8B: | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Segment List(0) | TC |S| TTL | | | Type = TBA1 | Length | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Return Path Sub-TLVs | | ||||
. . | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 8A: Return Path TLV | ||||
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 | Length | Reserved | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Segment List(1) | | ||||
. . | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
. . | ||||
. . | ||||
. . | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Segment List(n) | | ||||
. . | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 8B: Segment List Sub-TLV in Return Path TLV | ||||
The Sub-TLV in the Return Path TLV can be one of the following Types: | ||||
o Type (value 1): SR-MPLS Label Stack of the Reverse SR Policy | ||||
o Type (value 2): SR-MPLS Binding SID [I-D.pce-binding-label-sid] of | ||||
the Reverse SR Policy | ||||
o Type (value 3): SRv6 Segment List of the Reverse SR Policy | ||||
o Type (value 4): SRv6 Binding SID [I-D.pce-binding-label-sid] of | ||||
the Reverse SR Policy | ||||
With sub-TLV Type 1, the Segment List(1) can be used by the responder | ||||
node to compute the next-hop IP address and outgoing interface to | ||||
send the probe response messages. | ||||
The Return Path TLV is optional. The PM querier node MUST only | ||||
insert one Return Path TLV in the probe query message and the | ||||
responder node MUST only process the first Return Path TLV in the | ||||
probe query message and ignore other Return Path TLVs if present. | ||||
The responder node MUST send probe response message back on the | ||||
reverse path specified in the Return Path TLV and MUST NOT add Return | ||||
Path TLV in the probe response message. | ||||
3.2.2.2. Probe Response Message for SR-MPLS Policy | ||||
The message content for sending probe response message using the UDP | ||||
header for two-way end-to-end performance measurement of an SR-MPLS | ||||
Policy is shown in Figure 6. | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Segment List(1) | TC |S| TTL | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Segment List(n) | TC |S| TTL | | | Segment List(n) | TC |S| TTL | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message as shown in Figure 5 | | | Message as shown in Figure 5 | | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 6: Probe Response Message for SR-MPLS Policy | Figure 6: Probe Response Message for SR-MPLS Policy | |||
3.2.2.2. Probe Response Message for SRv6 Policy | The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of | |||
the forward SR Policy can be used to find the reverse SR Policy to | ||||
send the probe response message for two-way measurement of SR Policy. | ||||
The message content for sending probe response message in-band using | 3.2.2.3. Probe Response Message for SRv6 Policy | |||
UDP header for two-way end-to-end performance measurement of an SRv6 | ||||
Policy is shown in Figure 7. | The message content for sending probe response message on the | |||
congruent path of the data traffic using UDP header for two-way | ||||
end-to-end performance measurement of an SRv6 Policy with SRH is | ||||
shown in Figure 7. | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SRH | | | SRH | | |||
. END.OTP (DM) or END.OP (LM) with Target SRv6 SID . | . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message as shown in Figure 5 (with IPv6 Addresses) | | | Message as shown in Figure 5 (with IPv6 Addresses) | | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 7: Probe Response Message for SRv6 Policy | Figure 7: Probe Response Message for SRv6 Policy | |||
3.2.3. Loopback Measurement Mode | ||||
The Loopback measurement mode can be used to measure round-trip delay | ||||
for a bidirectional Path. The probe query messages in this case | ||||
either carry the reverse Path information as part of the SR header or | ||||
set the querier address as the destination address in the IP header. | ||||
The responder node does not process the PM probe messages and | ||||
generate response messages. | ||||
4. Packet Loss Calculation | 4. Packet Loss Calculation | |||
The formula for calculating the one-way packet loss using counters | The formula for calculating the one-way packet loss using packet | |||
for a given block number is as following: | counters for a given block number is as following: | |||
o One-way Packet_Loss[n-1, n] = (Sender_Counter[n] - | One-way Packet_Loss[n-1, n] | |||
Sender_Counter[n-1]) - (Receive_Counter[n] - Receive_Counter[n-1]) | = (Sender_Counter[n] - Sender_Counter[n-1]) | |||
- (Receive_Counter[n] - Receive_Counter[n-1]) | ||||
5. Performance Measurement for P2MP SR Policies | 5. Performance Measurement for P2MP SR Policies | |||
The procedures for delay and loss measurement described in this | The procedures for delay and loss measurement described in this | |||
document for Point-to-Point (P2P) SR-MPLS Policies are also equally | document for Point-to-Point (P2P) SR Policies | |||
applicable to the Point-to-Multipoint (P2MP) SR Policies. | [I-D.spring-segment-routing-policy] are also equally applicable to | |||
the Point-to-Multipoint (P2MP) SR Policies | ||||
[I-D.spring-sr-p2mp-policy] as following: | ||||
6. ECMP Support | o The querier root node sends probe query messages using the either | |||
Spray P2MP segment or TreeSID P2MP segment defined in | ||||
[I-D.spring-sr-p2mp-policy] over the P2MP SR Policy. | ||||
o Each responder leaf node sends its IP address in the Source | ||||
Address of the probe response messages. This allows the querier | ||||
root node to identify the responder leaf nodes of the P2MP SR | ||||
Policy. | ||||
o The P2MP root node measures the end-to-end delay and loss | ||||
performance for each P2MP leaf node. | ||||
6. ECMP Support for SR Policies | ||||
An SR Policy can have ECMPs between the source and transit nodes, | An SR Policy can have ECMPs between the source and transit nodes, | |||
between transit nodes and between transit and destination nodes. | between transit nodes and between transit and destination nodes. | |||
Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP | Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP | |||
paths via transit nodes part of that Anycast group. The PM probe | paths via transit nodes part of that Anycast group. The PM probe | |||
messages need to be sent to traverse different ECMP paths to measure | messages need to be sent to traverse different ECMP paths to measure | |||
performance delay of an SR Policy. | performance delay of an SR Policy. | |||
Forwarding plane has various hashing functions available to forward | Forwarding plane has various hashing functions available to forward | |||
packets on specific ECMP paths. Following mechanisms can be used in | packets on specific ECMP paths. Following mechanisms can be used in | |||
PM probe messages to take advantage of the hashing function in | PM probe messages to take advantage of the hashing function in | |||
forwarding plane to influence the path taken by them. | forwarding plane to influence the path taken by them. | |||
o The mechanisms described in [RFC8029] [RFC5884] for handling ECMPs | o The mechanisms described in [RFC8029] and [RFC5884] for handling | |||
are also applicable to the performance measurement. In the IP/UDP | ECMPs are also applicable to the performance measurement. In the | |||
header of the PM probe messages, Destination Addresses in 127/8 | IP/UDP header of the PM probe messages, Destination Addresses in | |||
range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can be | 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can | |||
used to exercise a particular ECMP path. As specified in | be used to exercise a particular ECMP path. As specified in | |||
[RFC6437], 3-tuple of Flow Label, Source Address and Destination | [RFC6437], 3-tuple of Flow Label, Source Address and Destination | |||
Address fields in the IPv6 header can also be used. | Address fields in the IPv6 header can also be used. | |||
o For SR-MPLS, entropy label [RFC6790] in the PM probe messages can | o For SR-MPLS Policy, entropy label [RFC6790] can be used in the PM | |||
be used. | probe messages. | |||
o For SRv6, Flow Label in SRH [I-D.6man-segment-routing-header] of | o For SRv6 Policy using SRH, Flow Label in the SRH | |||
the PM probe messages can be used. | [I-D.6man-segment-routing-header] of the PM probe messages can be | |||
used. | ||||
7. Security Considerations | 7. Security Considerations | |||
The performance measurement is intended for deployment in | The performance measurement is intended for deployment in | |||
well-managed private and service provider networks. As such, it | well-managed private and service provider networks. As such, it | |||
assumes that a node involved in a measurement operation has | assumes that a node involved in a measurement operation has | |||
previously verified the integrity of the path and the identity of the | previously verified the integrity of the path and the identity of the | |||
far end responder node. | far end responder node. | |||
If desired, attacks can be mitigated by performing basic validation | If desired, attacks can be mitigated by performing basic validation | |||
and sanity checks, at the querier, of the counter or timestamp fields | and sanity checks, at the querier, of the counter or timestamp fields | |||
in received measurement response messages. The minimal state | in received measurement response messages. The minimal state | |||
associated with these protocols also limits the extent of measurement | associated with these protocols also limits the extent of measurement | |||
disruption that can be caused by a corrupt or invalid message to a | disruption that can be caused by a corrupt or invalid message to a | |||
single query/response cycle. | single query/response cycle. | |||
Use of HMAC-SHA-256 in the authenticated mode defined in this | Use of HMAC-SHA-256 in the authenticated mode protects the data | |||
document protects the data integrity of the probe messages. SRv6 has | integrity of the probe messages. SRv6 has HMAC protection | |||
HMAC protection authentication defined for SRH | authentication defined for SRH [I-D.6man-segment-routing-header]. | |||
[I-D.6man-segment-routing-header]. Hence, PM probe messages for SRv6 | Hence, PM probe messages for SRv6 may not need authentication mode. | |||
may not need authentication mode. Cryptographic measures may be | Cryptographic measures may be enhanced by the correct configuration | |||
enhanced by the correct configuration of access-control lists and | of access-control lists and firewalls. | |||
firewalls. | ||||
8. IANA Considerations | 8. IANA Considerations | |||
This document does not require any IANA actions. | IANA is requested to allocate values for the following Return Path | |||
TLV Type for [I-D.ippm-stamp-option-tlv] to be carried in PM probe | ||||
query messages: | ||||
o Type TBA1: Return Path TLV | ||||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
August 1980. | August 1980. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, March 1997. | Requirement Levels", RFC 2119, March 1997. | |||
skipping to change at page 15, line 47 ¶ | skipping to change at page 20, line 19 ¶ | |||
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | |||
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | |||
RFC 5357, October 2008. | RFC 5357, October 2008. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", RFC 8174, May 2017. | 2119 Key Words", RFC 8174, May 2017. | |||
[I-D.spring-srv6-oam] Ali, Z., et al., "Operations, Administration, | [I-D.spring-srv6-oam] Ali, Z., et al., "Operations, Administration, | |||
and Maintenance (OAM) in Segment Routing Networks with | and Maintenance (OAM) in Segment Routing Networks with | |||
IPv6 Data plane (SRv6)", draft-ali-spring-srv6-oam. | IPv6 Data plane (SRv6)", draft-ali-spring-srv6-oam, work | |||
in progress. | ||||
[I-D.ippm-stamp-option-tlv] Mirsky, G., et al., "Simple Two-way | ||||
Active Measurement Protocol Optional Extensions", | ||||
draft-mirsky-ippm-stamp-option-tlv, work in progress. | ||||
9.2. Informative References | 9.2. Informative References | |||
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock | [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock | |||
Synchronization Protocol for Networked Measurement and | Synchronization Protocol for Networked Measurement and | |||
Control Systems", March 2008. | Control Systems", March 2008. | |||
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, | [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, | |||
"Bidirectional Forwarding Detection (BFD) for MPLS Label | "Bidirectional Forwarding Detection (BFD) for MPLS Label | |||
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, | Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, | |||
June 2010. | June 2010. | |||
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, | [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, | |||
"IPv6 Flow Label Specification", RFC 6437, November 2011. | "IPv6 Flow Label Specification", RFC 6437, November 2011. | |||
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | |||
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | |||
RFC 6790, November 2012. | RFC 6790, November 2012. | |||
[RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way | ||||
Active Measurement Protocol (OWAMP) and Two-Way Active | ||||
Measurement Protocol (TWAMP)", RFC 7820, March 2016. | ||||
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar, N., | [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar, N., | |||
Aldrin, S. and M. Chen, "Detecting Multiprotocol Label | Aldrin, S. and M. Chen, "Detecting Multiprotocol Label | |||
Switched (MPLS) Data-Plane Failures", RFC 8029, March | Switched (MPLS) Data-Plane Failures", RFC 8029, March | |||
2017. | 2017. | |||
[RFC8186] Mirsky, G., and I. Meilik, "Support of the IEEE 1588 | ||||
Timestamp Format in a Two-Way Active Measurement Protocol | ||||
(TWAMP)", RFC 8186, June 2017. | ||||
[RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive | [RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive | |||
and Hybrid Performance Monitoring", RFC 8321, January | and Hybrid Performance Monitoring", RFC 8321, January | |||
2018. | 2018. | |||
[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>. | |||
[I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment | [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment | |||
Routing Policy Architecture", | Routing Policy Architecture", | |||
draft-ietf-spring-segment-routing-policy, work in | draft-ietf-spring-segment-routing-policy, work in | |||
progress. | progress. | |||
[I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication | [I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication | |||
Policy for P2MP Service Delivery", | Policy for P2MP Service Delivery", | |||
draft-voyer-spring-sr-p2mp-policy, work in progress. | draft-voyer-spring-sr-p2mp-policy, work in progress. | |||
[I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in | [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in | |||
MPLS Based Segment Routing Network", draft-cheng-spring- | MPLS Based Segment Routing Network", | |||
mpls-path-segment, work in progress. | draft-ietf-spring-mpls-path-segment, work in progress. | |||
[I-D.6man-segment-routing-header] Filsfils, C., et al., "IPv6 | [I-D.6man-segment-routing-header] Filsfils, C., et al., "IPv6 | |||
Segment Routing Header (SRH)", | Segment Routing Header (SRH)", | |||
draft-ietf-6man-segment-routing-header, work in progress. | draft-ietf-6man-segment-routing-header, work in progress. | |||
[I-D.ippm-stamp] Mirsky, G. et al. "Simple Two-way Active | [I-D.ippm-stamp] Mirsky, G. et al. "Simple Two-way Active | |||
Measurement Protocol", draft-ietf-ippm-stamp, work in | Measurement Protocol", draft-ietf-ippm-stamp, work in | |||
progress. | progress. | |||
[I-D.pce-binding-label-sid] Filsfils, C., et al., "Carrying Binding | ||||
Label Segment-ID in PCE-based Networks", | ||||
draft-sivabalan-pce-binding-label-sid, work in progress. | ||||
[BBF.TR-390] "Performance Measurement from IP Edge to Customer | [BBF.TR-390] "Performance Measurement from IP Edge to Customer | |||
Equipment using TWAMP Light", BBF TR-390, May 2017. | Equipment using TWAMP Light", BBF TR-390, May 2017. | |||
[I-D.spring-ioam-sr-mpls] Gandhi, R. Ed., et al., "Segment Routing | ||||
with MPLS Data Plane Encapsulation for In-situ OAM Data", | ||||
draft-gandhi-spring-ioam-sr-mpls, work in progress. | ||||
[RFC2104] Krawczyk, H., Bell-are, M., and R. Canetti, "HMAC: Keyed- | ||||
Hashing for Message Authentication", RFC 2104, February | ||||
1997. | ||||
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | ||||
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. | ||||
Acknowledgments | Acknowledgments | |||
TBA | The authors would like to thank Thierry Couture for various | |||
discussions on the use-cases for TWAMP in segment routing. The | ||||
authors would also like to thank Greg Mirsky for reviewing this | ||||
document and providing useful comments and suggestions. | ||||
Authors' Addresses | Authors' Addresses | |||
Rakesh Gandhi (editor) | Rakesh Gandhi (editor) | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
Canada | Canada | |||
Email: rgandhi@cisco.com | Email: rgandhi@cisco.com | |||
Clarence Filsfils | Clarence Filsfils | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
Email: cfilsfil@cisco.com | Email: cfilsfil@cisco.com | |||
Daniel Voyer | Daniel Voyer | |||
Bell Canada | Bell Canada | |||
Email: daniel.voyer@bell.ca | Email: daniel.voyer@bell.ca | |||
Mach(Guoyi) Chen | ||||
Huawei | ||||
Email: mach.chen@huawei.com | ||||
End of changes. 76 change blocks. | ||||
253 lines changed or deleted | 489 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |