rfc9779v1.txt   rfc9779.txt 
skipping to change at line 134 skipping to change at line 134
[RFC9341] defines the Alternate-Marking Method using Block Numbers as [RFC9341] defines the Alternate-Marking Method using Block Numbers as
a data correlation mechanism for packet loss measurement. a data correlation mechanism for packet loss measurement.
This document utilizes the mechanisms from [RFC6374], [RFC7876], and This document utilizes the mechanisms from [RFC6374], [RFC7876], and
[RFC9341] for delay and loss measurements in SR-MPLS networks. This [RFC9341] for delay and loss measurements in SR-MPLS networks. This
includes coverage of links and end-to-end SR-MPLS paths, as well as includes coverage of links and end-to-end SR-MPLS paths, as well as
SR Policies. SR Policies.
This document extends [RFC6374] by defining Return Path and Block This document extends [RFC6374] by defining Return Path and Block
Number TLVs (see Section 6) for delay and loss measurement in SR-MPLS Number TLVs (see Section 6) for delay and loss measurement in SR-MPLS
networks. These TLVs also apply to MPLS Label Switched Paths (LSPs) networks. These TLVs can also be used in MPLS Label Switched Paths
[RFC3031]. However, the procedure for delay and loss measurement of (LSPs) [RFC3031]. However, the procedure for delay and loss
MPLS LSPs is outside the scope of this document. measurement of MPLS LSPs is outside the scope of this document.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at line 303 skipping to change at line 303
The fields 0001, Version, Reserved, and Channel Type shown in The fields 0001, Version, Reserved, and Channel Type shown in
Figure 2 are specified in [RFC5586]. Figure 2 are specified in [RFC5586].
The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS
Policy with an Implicit NULL label. Policy with an Implicit NULL label.
For an SR-MPLS Policy, to ensure that the query message is processed For an SR-MPLS Policy, to ensure that the query message is processed
by the intended responder, the Destination Address TLV (Type 129) by the intended responder, the Destination Address TLV (Type 129)
[RFC6374] containing an address of the responder can be sent in the [RFC6374] containing an address of the responder can be sent in the
query messages. The responder that supports this TLV MUST return query messages. The responder that supports this TLV MUST return
Success in "Control Code" [RFC6374] if it is the intended destination Control Code 0x1 (Success) [RFC6374] if it is the intended
for the query. Otherwise, it MUST return Error 0x15: Invalid destination for the query. Otherwise, it MUST return Error 0x15:
Destination Node Identifier [RFC6374]. Invalid Destination Node Identifier [RFC6374].
4.2. Response Message for Links and SR-MPLS Policies 4.2. Response Message for Links and SR-MPLS Policies
4.2.1. One-Way Measurement Mode 4.2.1. One-Way Measurement Mode
In the one-way measurement mode defined in Section 2.4 of [RFC6374], In the one-way measurement mode defined in Section 2.4 of [RFC6374],
the querier can receive out-of-band response messages with an IP/UDP the querier can receive response messages with an IP/UDP header "out-
header by properly setting the UDP Return Object (URO) TLV in the of-band" by properly setting the UDP Return Object (URO) TLV in the
query message. The URO TLV (Type 131) is defined in [RFC7876] and query message. The URO TLV (Type 131) is defined in [RFC7876] and
includes the UDP-Destination-Port and IP address. When the querier includes the UDP-Destination-Port and IP address. When the querier
sets an IP address and a UDP port in the URO TLV, the response sets an IP address and a UDP port in the URO TLV, the response
message MUST be sent to that IP address as the destination address message MUST be sent to that IP address, with that IP address as the
and UDP port as the destination port. In addition, the Control Code destination address and the UDP port as the destination port. In
in the query message MUST be set to Out-of-Band Response Requested addition, the Control Code in the query message MUST be set to Out-
[RFC6374]. of-band Response Requested [RFC6374].
4.2.2. Two-Way Measurement Mode 4.2.2. Two-Way Measurement Mode
In the two-way measurement mode defined in Section 2.4 of [RFC6374], In the two-way measurement mode defined in Section 2.4 of [RFC6374],
the response messages SHOULD be sent back in-band on the same link or the response messages SHOULD be sent back one of two ways: either
the same end-to-end SR-MPLS path (same set of links and nodes) in the they are sent back in-band on the same link, or they are sent back on
reverse direction to the querier, in order to perform accurate two- the same end-to-end SR-MPLS path (i.e., the same set of links and
way delay measurement. nodes) in the reverse direction to the querier. This is done in
order to perform accurate two- way delay measurement.
For links, the response message as defined in [RFC6374] is sent back For links, the response message as defined in [RFC6374] is sent back
on the same incoming link where the query message is received. In on the same incoming link where the query message is received. In
this case, the Control Code in the query message MUST be set to In- this case, the Control Code in the query message MUST be set to In-
band Response Requested [RFC6374]. band Response Requested [RFC6374].
For end-to-end SR-MPLS paths, the responder transmits the response For end-to-end SR-MPLS paths, the responder transmits the response
message (see the example as shown in Figure 2) on a specific return message (see the example as shown in Figure 2) on a specific return
SR-MPLS path. The querier can request in the query message for the SR-MPLS path. In the query message, the querier can request that the
responder to send the response message back on a given return path responder send the response message back on a given return path using
using the MPLS Label Stack Sub-TLV in the Return Path TLV defined in the MPLS Label Stack Sub-TLV in the Return Path TLV defined in this
this document. document.
4.2.3. Loopback Measurement Mode 4.2.3. Loopback Measurement Mode
The loopback measurement mode defined in Section 2.8 of [RFC6374] is The loopback measurement mode defined in Section 2.8 of [RFC6374] is
used to measure round-trip delay for a bidirectional circular path used to measure round-trip delay for a bidirectional circular path
[RFC6374] in SR-MPLS networks. In this mode for SR-MPLS, the [RFC6374] in SR-MPLS networks. In this mode for SR-MPLS, the
received query messages are not punted out of the fast path in received query messages are not punted out of the fast path in
forwarding (i.e., to the slow path or control plane) at the forwarding (i.e., to the slow path or control plane) at the
responder. In other words, the responder does not process the responder. In other words, the responder does not process the
payload or generate response messages. The loopback function simply payload or generate response messages. The loopback function simply
skipping to change at line 392 skipping to change at line 393
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example Query Message Header for an End-to-End SR-MPLS Figure 3: Example Query Message Header for an End-to-End SR-MPLS
Policy in the Loopback Measurement Mode Policy in the Loopback Measurement Mode
5. Delay and Loss Measurement 5. Delay and Loss Measurement
5.1. Delay Measurement Message 5.1. Delay Measurement Message
As defined in [RFC6374], MPLS Delay Measurement (DM) query and As defined in [RFC6374], MPLS Delay Measurement (DM) query and
response messages use the Associated Channel Header (ACH) (value response messages use the Associated Channel Header (ACH) (with the
0x000C for delay measurement) [RFC6374], which identifies the message value 0x000C for delay measurement). This value identifies the
type and the message payload as defined in Section 3.2 of [RFC6374] message type and message payload that follow the ACH, as defined in
following the ACH. For delay measurement, the same ACH value is used Section 3.2 of [RFC6374]. For delay measurement, the same ACH value
for both links and end-to-end SR-MPLS Policies. is used for both links and end-to-end SR-MPLS Policies.
5.2. Loss Measurement Message 5.2. Loss Measurement Message
The Loss Measurement (LM) protocol can perform two distinct kinds of The Loss Measurement (LM) protocol can perform two distinct kinds of
loss measurement as described in Section 2.9.8 of [RFC6374]. loss measurement as described in Section 2.9.8 of [RFC6374].
* In the inferred mode, LM will measure the loss of specially * In the inferred mode, LM will measure the loss of specially
generated test messages to infer the approximate data plane loss generated test messages to infer the approximate data plane loss
level. Inferred mode LM provides only approximate loss level. Inferred mode LM provides only approximate loss
accounting. accounting.
* In the direct mode, LM will directly measure data plane packet * In the direct mode, LM will directly measure data plane packet
loss. Direct mode LM provides perfect loss accounting but may loss. Direct mode LM provides perfect loss accounting but may
require hardware support. require hardware support.
As defined in [RFC6374], MPLS LM query and response messages use the As defined in [RFC6374], MPLS LM query and response messages use the
ACH (value 0x000A for direct loss measurement or value 0x000B for ACH (with the value 0x000A for direct loss measurement or value
inferred loss measurement), which identifies the message type and the 0x000B for inferred loss measurement). This value identifies the
message payload defined in Section 3.1 of [RFC6374] following the message type and message payload that follow the ACH, as defined in
ACH. For loss measurement, the same ACH value is used for both links Section 3.1 of [RFC6374]. For loss measurement, the same ACH value
and end-to-end SR-MPLS Policies. is used for both links and end-to-end SR-MPLS Policies.
5.3. Combined Loss/Delay Measurement Message 5.3. Combined Loss/Delay Measurement Message
As defined in [RFC6374], combined DM+LM query and response messages As defined in [RFC6374], combined LM/DM query and response messages
use the ACH (value 0x000D for direct loss and delay measurement or use the ACH (with the value 0x000D for direct loss and delay
value 0x000E for inferred loss and delay measurement), which measurement or the value 0x000E for inferred loss and delay
identifies the message type and the message payload defined in measurement). The value identies the message type and the message
Section 3.3 of [RFC6374] following the ACH. For combined loss and payload that follows the ACH, as defined in Section 3.3 of [RFC6374].
delay measurement, the same ACH value is used for both links and end- For combined loss and delay measurement, the same ACH value is used
to-end SR-MPLS Policies. for both links and end-to-end SR-MPLS Policies.
5.4. Counters 5.4. Counters
The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the
received data packet for the traffic flow under measurement, in order received data packet for the traffic flow under measurement, in order
to account for received traffic on the egress node of the SR-MPLS to account for received traffic on the egress node of the SR-MPLS
Policy. In the direct mode, the PSID in the received query message Policy. In the direct mode, the PSID in the received query message
(as shown in Figure 4) can be used to associate the received traffic (as shown in Figure 4) can be used to associate the received traffic
counter on the responder to detect the transmit packet loss for the counter on the responder to detect the transmit packet loss for the
end-to-end SR-MPLS Policy. end-to-end SR-MPLS Policy.
skipping to change at line 508 skipping to change at line 509
each block based on the marking in the received data packets. The each block based on the marking in the received data packets. The
querier and responder maintain separate sets of transmit and receive querier and responder maintain separate sets of transmit and receive
counters for each marking. The marking can be used as a block counters for each marking. The marking can be used as a block
number, or a separate block number can be incremented when the number, or a separate block number can be incremented when the
marking changes. Other methods can be defined for alternate marking marking changes. Other methods can be defined for alternate marking
of the data packets of the traffic flow under measurement to assign a of the data packets of the traffic flow under measurement to assign a
block number for the counters. block number for the counters.
The LM query and response messages defined in [RFC6374] are used to The LM query and response messages defined in [RFC6374] are used to
measure packet loss for the block of data packets transmitted with measure packet loss for the block of data packets transmitted with
the previous marking while data packets carry alternate marking. the previous marking, whereas data packets carry alternate marking.
Specifically, LM query and response messages carry the transmit and Specifically, LM query and response messages carry the transmit and
receive counters (which are currently not incrementing) along with receive counters (which are currently not incrementing) along with
their block number to correlate for loss measurement. their block number to correlate for loss measurement.
Section 4.3 of [RFC9341] specifies that: "The assumption of this BN Section 4.3 of [RFC9341] specifies that: "The assumption of this BN
mechanism is that the measurement nodes are time synchronized." mechanism is that the measurement nodes are time synchronized."
However, this is not necessary, as the block number on the responder However, this is not necessary, as the block number on the responder
can be synchronized based on the received LM query messages. can be synchronized based on the received LM query messages.
6. TLV Extensions 6. TLV Extensions
skipping to change at line 592 skipping to change at line 593
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |1| TTL | | Label(n) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MPLS Label Stack Sub-TLV in the Return Path TLV Figure 6: MPLS Label Stack Sub-TLV in the Return Path TLV
The MPLS Label Stack contains a list of 32-bit LSE that includes a The MPLS label stack contains a list of 32-bit LSEs that includes a
20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit
EOS (S) field. An MPLS Label Stack Sub-TLV may carry a stack of End of Stack (S) field. An MPLS Label Stack Sub-TLV may carry a
labels or a Binding SID label [RFC8402] of the Return SR-MPLS Policy. stack of labels or a Binding SID label [RFC8402] of the Return SR-
MPLS Policy.
The Length is a one-byte field and is equal to the length of the The Length is a one-byte field and is equal to the length of the
label stack field and the Reserved field in bytes. The Length MUST label stack field and the Reserved field in bytes. The Length MUST
NOT be 0 or 1. NOT be 0 or 1.
The Return Path TLV MUST carry only one Return Path Sub-TLV. The The Return Path TLV MUST carry only one Return Path Sub-TLV. The
MPLS Label Stack in the Return Path Sub-TLV MUST contain at least one MPLS Label Stack in the Return Path Sub-TLV MUST contain at least one
MPLS Label. The responder that supports this Sub-TLV MUST only MPLS Label. The responder that supports this Sub-TLV MUST only
process the first Return Path Sub-TLV and ignore the other Return process the first Return Path Sub-TLV and ignore the other Return
Path Sub-TLVs if present. The responder that supports this Sub-TLV Path Sub-TLVs if present. The responder that supports this Sub-TLV
skipping to change at line 652 skipping to change at line 654
and Counter 2, and set in the response message for the Block Number and Counter 2, and set in the response message for the Block Number
associated with Counter 3 and Counter 4. associated with Counter 3 and Counter 4.
The Reserved field MUST be set to 0 and MUST be ignored on the The Reserved field MUST be set to 0 and MUST be ignored on the
receive side. receive side.
7. ECMP for SR-MPLS Policies 7. ECMP for SR-MPLS Policies
The SLs of an SR-MPLS Policy can have ECMPs between the source and The SLs of an SR-MPLS Policy can have ECMPs between the source and
transit nodes, between transit nodes, and between transit and transit nodes, between transit nodes, and between transit and
destination nodes. Usage of a node SID [RFC8402] by the SLs of an destination nodes. Usage of a node-SID [RFC8402] by the SLs of an
SR-MPLS Policy can result in ECMP paths. In addition, usage of an SR-MPLS Policy can result in ECMP paths. In addition, usage of an
Anycast SID [RFC8402] by the SLs of an SR-MPLS Policy can result in Anycast-SID [RFC8402] by the SLs of an SR-MPLS Policy can result in
ECMP paths via transit nodes that are part of that anycast group. ECMP paths via transit nodes that are part of that anycast group.
The query and response messages are sent to traverse different ECMP The query and response messages are sent to traverse different ECMP
paths to measure the delay of each ECMP path of an SL. paths to measure the delay of each ECMP path of an SL.
The forwarding plane has various hashing functions available to The forwarding plane has various hashing functions available to
forward packets on specific ECMP paths. For end-to-end SR-MPLS forward packets on specific ECMP paths. For end-to-end SR-MPLS
Policy delay measurement, different entropy label values [RFC6790] Policy delay measurement, different entropy label values [RFC6790]
can be used in query and response messages to take advantage of the can be used in query and response messages to take advantage of the
hashing function in the forwarding plane to influence the ECMP path hashing function in the forwarding plane to influence the ECMP path
taken by them. taken by them.
skipping to change at line 746 skipping to change at line 748
+------+--------------+-----------+ +------+--------------+-----------+
| 6 | Block Number | RFC 9779 | | 6 | Block Number | RFC 9779 |
+------+--------------+-----------+ +------+--------------+-----------+
Table 1: MPLS Loss/Delay Table 1: MPLS Loss/Delay
Measurement TLV Types Measurement TLV Types
The Block Number TLV is carried in the query and response messages, The Block Number TLV is carried in the query and response messages,
and the Return Path TLV is carried in the query messages. and the Return Path TLV is carried in the query messages.
IANA has created the "Return Path Sub-TLV Type" registry. All code IANA has created the "Return Path Sub-TLV Types" registry. All code
points in the range 0 through 175 in this registry shall be allocated points are allocated per the registration policies shown in Table 2
according to the "IETF Review" procedure as specified in [RFC8126]. (see [RFC8126]).
Code points in the range 176 through 239 in this registry shall be
allocated according to the "First Come First Served" procedure as
specified in [RFC8126]. Remaining code points are allocated
according to Table 2:
+===========+=========================+===========+ +===========+=========================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+===========+=========================+===========+ +===========+=========================+===========+
| 1 - 175 | IETF Review | RFC 9779 | | 1 - 175 | IETF Review | RFC 9779 |
+-----------+-------------------------+-----------+ +-----------+-------------------------+-----------+
| 176 - 239 | First Come First Served | RFC 9779 | | 176 - 239 | First Come First Served | RFC 9779 |
+-----------+-------------------------+-----------+ +-----------+-------------------------+-----------+
| 240 - 251 | Experimental Use | RFC 9779 | | 240 - 251 | Experimental Use | RFC 9779 |
+-----------+-------------------------+-----------+ +-----------+-------------------------+-----------+
skipping to change at line 896 skipping to change at line 894
February 2024, <https://www.rfc-editor.org/info/rfc9545>. February 2024, <https://www.rfc-editor.org/info/rfc9545>.
[RFC9714] Cheng, W., Ed., Min, X., Ed., Zhou, T., Dai, J., and Y. [RFC9714] Cheng, W., Ed., Min, X., Ed., Zhou, T., Dai, J., and Y.
Peleg, "Encapsulation for MPLS Performance Measurement Peleg, "Encapsulation for MPLS Performance Measurement
with the Alternate-Marking Method", RFC 9714, with the Alternate-Marking Method", RFC 9714,
DOI 10.17487/RFC9714, February 2025, DOI 10.17487/RFC9714, February 2025,
<https://www.rfc-editor.org/info/rfc9714>. <https://www.rfc-editor.org/info/rfc9714>.
[IEEE802.1AX] [IEEE802.1AX]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Link Aggregation", IEEE Std 802.1AX-2008, Networks - Link Aggregation", IEEE Std 802.1AX-2020,
November 2008. DOI 10.1109/IEEESTD.2020.9105034, May 2020,
<https://doi.org/10.1109/IEEESTD.2020.9105034>.
Acknowledgments Acknowledgments
The authors would like to thank Thierry Couture and Ianik Semco for The authors would like to thank Thierry Couture and Ianik Semco for
the discussions on the use cases for performance measurement in the discussions on the use cases for performance measurement in
segment routing networks. The authors would like to thank Patrick segment routing networks. The authors would like to thank Patrick
Khordoc, Ruby Lin, and Haowei Shi for implementing the mechanisms Khordoc, Ruby Lin, and Haowei Shi for implementing the mechanisms
defined in this document. The authors would like to thank Greg defined in this document. The authors would like to thank Greg
Mirsky and Xiao Min for providing many useful comments and Mirsky and Xiao Min for providing many useful comments and
suggestions. The authors would also like to thank Stewart Bryant, suggestions. The authors would also like to thank Stewart Bryant,
Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments. Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments.
Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for the MPLS-RT Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for the MPLS expert
expert review; Zhaohui Zhang for the RTGDIR early review; Tony Li for review; Zhaohui Zhang for the RTGDIR early review; Tony Li for
shepherd's review; Ned Smith for the SECDIR review; Roni Even for the shepherd's review; Ned Smith for the SECDIR review; Roni Even for the
Gen-ART review; Marcus Ihlar for the TSV-ART review; Dhruv Dhody for Gen-ART review; Marcus Ihlar for the TSV-ART review; Dhruv Dhody for
the OPSDIR review; and Gunter Van de Velde, Paul Wouters, Éric the OPSDIR review; and Gunter Van de Velde, Paul Wouters, Éric
Vyncke, Murray Kucherawy, John Scudder, and Roman Danyliw for the Vyncke, Murray Kucherawy, John Scudder, and Roman Danyliw for the
IESG review. IESG review.
Contributors Contributors
Sagar Soni Sagar Soni
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 17 change blocks. 
54 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.48.