rfc9714v1.txt | rfc9714.txt | |||
---|---|---|---|---|
skipping to change at line 12 ¶ | skipping to change at line 12 ¶ | |||
Internet Engineering Task Force (IETF) W. Cheng, Ed. | Internet Engineering Task Force (IETF) W. Cheng, Ed. | |||
Request for Comments: 9714 China Mobile | Request for Comments: 9714 China Mobile | |||
Category: Standards Track X. Min, Ed. | Category: Standards Track X. Min, Ed. | |||
ISSN: 2070-1721 ZTE Corp. | ISSN: 2070-1721 ZTE Corp. | |||
T. Zhou | T. Zhou | |||
Huawei | Huawei | |||
J. Dai | J. Dai | |||
FiberHome | FiberHome | |||
Y. Peleg | Y. Peleg | |||
Broadcom | Broadcom | |||
January 2025 | February 2025 | |||
Encapsulation for MPLS Performance Measurement with the Alternate- | Encapsulation for MPLS Performance Measurement with the Alternate- | |||
Marking Method | Marking Method | |||
Abstract | Abstract | |||
This document defines the encapsulation for MPLS performance | This document defines the encapsulation for MPLS performance | |||
measurement with the Alternate-Marking Method, which performs flow- | measurement with the Alternate-Marking Method, which performs flow- | |||
based packet loss, delay, and jitter measurements on MPLS traffic. | based packet loss, delay, and jitter measurements on MPLS traffic. | |||
skipping to change at line 97 ¶ | skipping to change at line 97 ¶ | |||
flows. | flows. | |||
This document defines the encapsulation for MPLS performance | This document defines the encapsulation for MPLS performance | |||
measurement with the Alternate-Marking Method, which performs flow- | measurement with the Alternate-Marking Method, which performs flow- | |||
based packet loss, delay, and jitter measurements on the MPLS | based packet loss, delay, and jitter measurements on the MPLS | |||
traffic. The encapsulation defined in this document supports | traffic. The encapsulation defined in this document supports | |||
performance monitoring at the intermediate nodes and MPLS flow | performance monitoring at the intermediate nodes and MPLS flow | |||
identification at both transport and service layers. | identification at both transport and service layers. | |||
Note that in parallel to the work of this document, there is ongoing | Note that in parallel to the work of this document, there is ongoing | |||
work on MPLS Network Actions (MNA) [RFC9613]. The MPLS performance | work on MPLS Network Actions (MNAs) [RFC9613]. The MPLS performance | |||
measurement with the Alternate-Marking Method can also be achieved by | measurement with the Alternate-Marking Method can also be achieved by | |||
MNA encapsulation. In addition, MNA will provide a broader use-case | MNA encapsulation. In addition, MNA will provide a broader use-case | |||
applicability. That means the MNA encapsulation is expected to | applicability. That means the MNA encapsulation is expected to | |||
provide a more advanced solution, when published as an RFC and it is | provide a more advanced solution. Once published as an RFC, it is | |||
agreed that this document will be made Historic at that time. | agreed that this document will be made Historic. | |||
2. Conventions Used in This Document | 2. Conventions Used in This Document | |||
2.1. Abbreviations | 2.1. Abbreviations | |||
ACL: Access Control List | ACL: Access Control List | |||
BoS: Bottom of Stack | BoS: Bottom of Stack | |||
cSPL: Composite Special Purpose Label, the combination of the | cSPL: Composite Special Purpose Label, the combination of the | |||
Extension Label (value 15) and an Extended Special Purpose Label | Extension Label (value 15) and an Extended Special Purpose Label | |||
DSCP: Differentiated Services Code Point | DSCP: Differentiated Services Code Point | |||
ECMP: Equal-Cost Multipath | ||||
ELC: Entropy Label Capability | ELC: Entropy Label Capability | |||
ERLD: Entropy Readable Label Depth | ERLD: Entropy Readable Label Depth | |||
eSPL: Extended Special Purpose Label, a special-purpose label that | eSPL: Extended Special Purpose Label, a special-purpose label that | |||
is placed in the label stack after the Extension Label (value 15) | is placed in the label stack after the Extension Label (value 15) | |||
FL: Flow-ID Label | FL: Flow-ID Label | |||
FLC: Flow-ID Label Capability | FLC: Flow-ID Label Capability | |||
skipping to change at line 148 ¶ | skipping to change at line 146 ¶ | |||
LSR: Label Switching Router | LSR: Label Switching Router | |||
MPLS: Multi-Protocol Label Switching | MPLS: Multi-Protocol Label Switching | |||
NMS: Network Management System | NMS: Network Management System | |||
PHP: Penultimate Hop Popping | PHP: Penultimate Hop Popping | |||
PM: Performance Measurement | PM: Performance Measurement | |||
PW: PseudoWire | PW: Pseudowire | |||
SFL: Synonymous Flow Label | SFL: Synonymous Flow Label | |||
SID: Segment ID | SID: Segment ID | |||
SR: Segment Routing | SR: Segment Routing | |||
TC: Traffic Class | TC: Traffic Class | |||
TTL: Time to Live | TTL: Time to Live | |||
skipping to change at line 205 ¶ | skipping to change at line 203 ¶ | |||
[RFC9017]. The FLI is defined in this document as value 18. | [RFC9017]. The FLI is defined in this document as value 18. | |||
The Traffic Class (TC) and Time To Live (TTL) fields of the XL and | The Traffic Class (TC) and Time To Live (TTL) fields of the XL and | |||
FLI MUST use the same values of the label immediately preceding the | FLI MUST use the same values of the label immediately preceding the | |||
XL. The Bottom of the Stack (BoS) bit [RFC3032] for the XL and FLI | XL. The Bottom of the Stack (BoS) bit [RFC3032] for the XL and FLI | |||
MUST be zero. If any XL or FLI processed by a node has the BoS bit | MUST be zero. If any XL or FLI processed by a node has the BoS bit | |||
set, the node MUST discard the packet and MAY log an error. | set, the node MUST discard the packet and MAY log an error. | |||
The Flow-ID Label (FL) is used as an MPLS flow identification | The Flow-ID Label (FL) is used as an MPLS flow identification | |||
[RFC8372]. Its value MUST be unique within the administrative | [RFC8372]. Its value MUST be unique within the administrative | |||
domain. The Flow-ID Label values MAY be allocated by an external NMS | domain. The FL values MAY be allocated by an external NMS or | |||
or controller based on the measurement object instances (such as LSP | controller based on the measurement object instances (such as LSP or | |||
or PW). There is a one-to-one mapping between a Flow-ID and a flow. | PW). There is a one-to-one mapping between a Flow-ID and a flow. | |||
The specific method on how to allocate the Flow-ID Label values is | The specific method on how to allocate the FL values is described in | |||
described in Section 5. | Section 5. | |||
The FL, preceded by a cSPL, can be placed either at the bottom or in | The FL, preceded by a cSPL, can be placed either at the bottom or in | |||
the middle, but not at the top, of the MPLS label stack, and it MAY | the middle, but not at the top, of the MPLS label stack, and it MAY | |||
appear multiple times within a label stack. Section 3.1 of this | appear multiple times within a label stack. Section 3.1 of this | |||
document provides several examples to illustrate the application of | document provides several examples to illustrate the application of | |||
FL in a label stack. The TTL for the FL MUST be zero to ensure that | FL in a label stack. The TTL for the FL MUST be zero to ensure that | |||
it is not used inadvertently for forwarding. The BoS bit for the FL | it is not used inadvertently for forwarding. The BoS bit for the FL | |||
depends on whether the FL is placed at the bottom of the MPLS label | depends on whether the FL is placed at the bottom of the MPLS label | |||
stack, i.e., the BoS bit for the FL is set only when the FL is placed | stack, i.e., the BoS bit for the FL is set only when the FL is placed | |||
at the bottom of the MPLS label stack. | at the bottom of the MPLS label stack. | |||
skipping to change at line 243 ¶ | skipping to change at line 241 ¶ | |||
* T(ype) bit is used to indicate the measurement type. When the T | * T(ype) bit is used to indicate the measurement type. When the T | |||
bit is set to 1, that means edge-to-edge performance measurement. | bit is set to 1, that means edge-to-edge performance measurement. | |||
When the T bit is set to 0, that means hop-by-hop performance | When the T bit is set to 0, that means hop-by-hop performance | |||
measurement. | measurement. | |||
Considering the FL is not used as a forwarding label, the repurposing | Considering the FL is not used as a forwarding label, the repurposing | |||
of the TC for the FL is feasible and viable. | of the TC for the FL is feasible and viable. | |||
3.1. Examples for Applying Flow-ID Label in a Label Stack | 3.1. Examples for Applying Flow-ID Label in a Label Stack | |||
Three examples of different layouts of the Flow-ID label (4 octets) | Three examples of different layouts of the FL (4 octets) are | |||
are illustrated as follows. Note that more examples may exist. | illustrated as follows. Note that more examples may exist. | |||
3.1.1. Layout of the Flow-ID Label when Applied to MPLS Transport | 3.1.1. Layout of the Flow-ID Label when Applied to MPLS Transport | |||
+----------------------+ | +----------------------+ | |||
| LSP | | | LSP | | |||
| Label | | | Label | | |||
+----------------------+ <--+ | +----------------------+ <--+ | |||
| Extension | | | | Extension | | | |||
| Label | | | | Label | | | |||
+----------------------+ |--- cSPL | +----------------------+ |--- cSPL | |||
skipping to change at line 286 ¶ | skipping to change at line 284 ¶ | |||
forwarding label", which implies that the penultimate Label Switching | forwarding label", which implies that the penultimate Label Switching | |||
Router (LSR) needs to follow the requirement of Section 4 in order to | Router (LSR) needs to follow the requirement of Section 4 in order to | |||
support this specification. If this is done, the egress LSR is | support this specification. If this is done, the egress LSR is | |||
excluded from the performance measurement. Therefore, when this | excluded from the performance measurement. Therefore, when this | |||
specification is in use, PHP should be disabled, unless the | specification is in use, PHP should be disabled, unless the | |||
penultimate LSR is known to have the necessary support and unless | penultimate LSR is known to have the necessary support and unless | |||
it's acceptable to exclude the egress LSR. | it's acceptable to exclude the egress LSR. | |||
Also note that in other examples of applying Flow-ID to MPLS | Also note that in other examples of applying Flow-ID to MPLS | |||
transport, one LSP label can be substituted by multiple SID labels in | transport, one LSP label can be substituted by multiple SID labels in | |||
the case of using SR Policy, and the combination of cSPL and Flow-ID | the case of using SR Policy, and the combination of cSPL and FL can | |||
label can be placed between SID labels, as specified in Section 6. | be placed between SID labels, as specified in Section 6. | |||
3.1.2. Layout of the Flow-ID Label when Applied to MPLS Service | 3.1.2. Layout of the Flow-ID Label when Applied to MPLS Service | |||
+----------------------+ | +----------------------+ | |||
| LSP | | | LSP | | |||
| Label | | | Label | | |||
+----------------------+ | +----------------------+ | |||
| Application | | | Application | | |||
| Label | | | Label | | |||
+----------------------+ <--+ | +----------------------+ <--+ | |||
skipping to change at line 353 ¶ | skipping to change at line 351 ¶ | |||
| Flow-ID | | | Flow-ID | | |||
| Label | | | Label | | |||
+----------------------+ <= Bottom of stack | +----------------------+ <= Bottom of stack | |||
| | | | | | |||
| Payload | | | Payload | | |||
| | | | | | |||
+----------------------+ | +----------------------+ | |||
Figure 4: Applying Flow-ID to both MPLS Transport and MPLS Service | Figure 4: Applying Flow-ID to both MPLS Transport and MPLS Service | |||
Note that for this example, the two Flow-ID Label values appearing in | Note that for this example, the two FL values appearing in a label | |||
a label stack must be different. In other words, the Flow-ID label | stack must be different. In other words, the FL applied to the MPLS | |||
applied to the MPLS transport and the Flow-ID label applied to the | transport and the FL applied to the MPLS service must be different. | |||
MPLS service must be different. Also, note that the two Flow-ID | Also, note that the two FL values are independent of each other. For | |||
label values are independent of each other. For example, two packets | example, two packets can belong to the same VPN flow but different | |||
can belong to the same VPN flow but different LSP flows, or two | LSP flows, or two packets can belong to different VPN flows but the | |||
packets can belong to different VPN flows but the same LSP flow. | same LSP flow. | |||
4. Procedures of Encapsulation, Look-Up, and Decapsulation | 4. Procedures of Encapsulation, Look-Up, and Decapsulation | |||
The procedures for Flow-ID label encapsulation, look-up, and | The procedures for FL encapsulation, look-up, and decapsulation are | |||
decapsulation are summarized as follows: | summarized as follows: | |||
* The MPLS ingress node [RFC3031] inserts the XL, FLI, and FL into | * The MPLS ingress node [RFC3031] inserts the XL, FLI, and FL into | |||
the MPLS label stack. At the same time, the ingress node sets the | the MPLS label stack. At the same time, the ingress node sets the | |||
Flow-ID Label value, the two color-marking bits, and the T bit, as | FL value, the two color-marking bits, and the T bit, as defined in | |||
defined in Section 3. | Section 3. | |||
* If edge-to-edge measurement is applied, i.e., the T bit is set to | * If edge-to-edge measurement is applied, i.e., the T bit is set to | |||
1, then only the MPLS ingress/egress node [RFC3031] is the | 1, then only the MPLS ingress/egress node [RFC3031] is the | |||
processing node; otherwise, all the MPLS nodes along the LSP are | processing node; otherwise, all the MPLS nodes along the LSP are | |||
the processing nodes. The processing node looks up the FL with | the processing nodes. The processing node looks up the FL with | |||
the help of the XL and FLI, and exports the collected data (such | the help of the XL and FLI, and exports the collected data (such | |||
as the Flow-ID, block counters, and timestamps) to an external | as the Flow-ID, block counters, and timestamps) to an external | |||
NMS/controller, referring to the Alternate-Marking Method. | NMS/controller, referring to the Alternate-Marking Method. | |||
Section 6 of [ALT-MARK] describes protocols for collected data | Section 6 of [ALT-MARK] describes protocols for collected data | |||
export; the details on how to export the collected data are | export; the details on how to export the collected data are | |||
outside the scope of this document. Note that while looking up | outside the scope of this document. Note that while looking up | |||
the Flow-ID label, the transit node needs to perform some deep | the FL, the transit node needs to inspect beyond the label at the | |||
labels inspection beyond the label (at the top of the label stack) | top of the label stack used to make forwarding decisions. | |||
used to make forwarding decisions. | ||||
* The processing node MUST pop the XL, FLI, and FL from the MPLS | * The processing node MUST pop the XL, FLI, and FL from the MPLS | |||
label stack when it needs to pop the preceding forwarding label. | label stack when it needs to pop the preceding forwarding label. | |||
The egress node MUST pop the whole MPLS label stack. This | The egress node MUST pop the whole MPLS label stack. This | |||
document doesn't introduce any new process to the decapsulated | document doesn't introduce any new process to the decapsulated | |||
packet. | packet. | |||
5. Procedures of Flow-ID Allocation | 5. Procedures of Flow-ID Allocation | |||
There are at least two ways of allocating Flow-ID. One way is to | There are at least two ways of allocating Flow-ID. One way is to | |||
skipping to change at line 466 ¶ | skipping to change at line 463 ¶ | |||
within an appropriate FRLD. To overcome this potential challenge, an | within an appropriate FRLD. To overcome this potential challenge, an | |||
implementation MAY allow the ingress node to place FL between SID | implementation MAY allow the ingress node to place FL between SID | |||
labels. This means that multiple identical FLs at different depths | labels. This means that multiple identical FLs at different depths | |||
MAY be interleaved with SID labels. When this occurs, sophisticated | MAY be interleaved with SID labels. When this occurs, sophisticated | |||
network planning may be needed, which is beyond the scope of this | network planning may be needed, which is beyond the scope of this | |||
document. | document. | |||
7. Equal-Cost Multipath Considerations | 7. Equal-Cost Multipath Considerations | |||
Analogous to what's described in Section 5 of [RFC8957], under | Analogous to what's described in Section 5 of [RFC8957], under | |||
conditions of Equal-Cost Multipath (ECMP), the introduction of the FL | conditions of equal-cost multipath, the introduction of the FL may | |||
may lead to the same problem that is caused by the Synonymous Flow | lead to the same problem that is caused by the Synonymous Flow Label | |||
Label (SFL) [RFC8957]. The two solutions proposed for SFL also apply | (SFL) [RFC8957]. The two solutions proposed for SFL also apply here. | |||
here. Specifically, adding FL to an existing flow may cause that | Specifically, adding FL to an existing flow may cause that flow to | |||
flow to take a different path. If the operator expects to resolve | take a different path. If the operator expects to resolve this | |||
this problem, they can choose to apply entropy labels [RFC6790] or | problem, they can choose to apply entropy labels [RFC6790] or add FL | |||
add FL to all flows. | to all flows. | |||
8. Security Considerations | 8. Security Considerations | |||
As specified in Section 7.1 of [RFC9341], "for security reasons, the | As specified in Section 7.1 of [RFC9341], "for security reasons, the | |||
Alternate-Marking Method MUST only be applied to controlled domains." | Alternate-Marking Method MUST only be applied to controlled domains." | |||
This requirement applies when the MPLS performance measurement with | This requirement applies when the MPLS performance measurement with | |||
Alternate-Marking Method is taken into account, which means the MPLS | Alternate-Marking Method is taken into account, which means the MPLS | |||
encapsulation and related procedures defined in this document MUST | encapsulation and related procedures defined in this document MUST | |||
only be applied to controlled domains; otherwise, the potential | only be applied to controlled domains; otherwise, the potential | |||
attacks discussed in Section 10 of [RFC9341] may be applied to the | attacks discussed in Section 10 of [RFC9341] may be applied to the | |||
deployed MPLS networks. | deployed MPLS networks. | |||
As specified in Section 3, the value of a Flow-ID label MUST be | As specified in Section 3, the value of an FL MUST be unique within | |||
unique within the administrative domain. In other words, the | the administrative domain. In other words, the administrative domain | |||
administrative domain is the scope of a Flow-ID label. The method | is the scope of an FL. The method for achieving multi-domain | |||
for achieving multi-domain performance measurement with the same | performance measurement with the same FL is outside the scope of this | |||
Flow-ID label is outside the scope of this document. The Flow-ID | document. The FL MUST NOT be signaled and distributed outside the | |||
label MUST NOT be signaled and distributed outside the administrative | administrative domain. Improper configuration that allows the FL to | |||
domain. Improper configuration that allows the Flow-ID label to be | be passed from one administrative domain to another would result in | |||
passed from one administrative domain to another would result in | ||||
Flow-ID conflicts. | Flow-ID conflicts. | |||
To prevent packets carrying Flow-ID labels from leaking from one | To prevent packets carrying FLs from leaking from one domain to | |||
domain to another, domain boundary nodes MUST deploy policies (e.g., | another, domain boundary nodes MUST deploy policies (e.g., ACL) to | |||
ACL) to filter out these packets. Specifically, at the sending edge, | filter out these packets. Specifically, at the sending edge, the | |||
the domain boundary node MUST filter out the packets that carry the | domain boundary node MUST filter out the packets that carry the FLI | |||
Flow-ID Label Indicator and are sent to other domains. At the | and are sent to other domains. At the receiving edge, the domain | |||
receiving edge, the domain boundary node MUST drop the packets that | boundary node MUST drop the packets that carry the FLI and are from | |||
carry the Flow-ID Label Indicator and are from other domains. Note | other domains. Note that packet leakage is neither breaching privacy | |||
that packet leakage is neither breaching privacy nor a source of DoS. | nor a source of DoS. | |||
9. IANA Considerations | 9. IANA Considerations | |||
IANA has assigned the following value in the "Extended Special- | IANA has assigned the following value in the "Extended Special- | |||
Purpose MPLS Label Values" registry within the "Special-Purpose | Purpose MPLS Label Values" registry within the "Special-Purpose | |||
Multiprotocol Label Switching (MPLS) Label Values" registry group: | Multiprotocol Label Switching (MPLS) Label Values" registry group: | |||
+=======+===============================+===========+ | +=======+===============================+===========+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+=======+===============================+===========+ | +=======+===============================+===========+ | |||
skipping to change at line 605 ¶ | skipping to change at line 601 ¶ | |||
RFC 9613, DOI 10.17487/RFC9613, August 2024, | RFC 9613, DOI 10.17487/RFC9613, August 2024, | |||
<https://www.rfc-editor.org/info/rfc9613>. | <https://www.rfc-editor.org/info/rfc9613>. | |||
Acknowledgements | Acknowledgements | |||
The authors acknowledge Loa Andersson, Tarek Saad, Stewart Bryant, | The authors acknowledge Loa Andersson, Tarek Saad, Stewart Bryant, | |||
Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping Zhan, Ming Ke, Wei | Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping Zhan, Ming Ke, Wei | |||
He, Ximing Dong, Darren Dukes, Tony Li, James Guichard, Daniele | He, Ximing Dong, Darren Dukes, Tony Li, James Guichard, Daniele | |||
Ceccarelli, Eric Vyncke, John Scudder, Gunter van de Velde, Roman | Ceccarelli, Eric Vyncke, John Scudder, Gunter van de Velde, Roman | |||
Danyliw, Warren Kumari, Murray Kucherawy, Deb Cooley, Zaheduzzaman | Danyliw, Warren Kumari, Murray Kucherawy, Deb Cooley, Zaheduzzaman | |||
Sarker, and Deboraha Brungard for their careful review and very | Sarker, and Deborah Brungard for their careful review and very | |||
helpful comments. | helpful comments. | |||
They also acknowledge Italo Busi and Chandrasekar Ramachandran for | They also acknowledge Italo Busi and Chandrasekar Ramachandran for | |||
their insightful MPLS-RT review and constructive comments. | their insightful MPLS-RT review and constructive comments. | |||
Additionally, the authors thank Dhruv Dhody for the English grammar | Additionally, the authors thank Dhruv Dhody for the English grammar | |||
review. | review. | |||
Contributors | Contributors | |||
End of changes. 16 change blocks. | ||||
54 lines changed or deleted | 50 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |