rfc9630v1.txt | rfc9630.txt | |||
---|---|---|---|---|
skipping to change at line 69 ¶ | skipping to change at line 69 ¶ | |||
1. Introduction | 1. Introduction | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
2. Requirements for Multicast Traffic Telemetry | 2. Requirements for Multicast Traffic Telemetry | |||
3. Issues of Existing Techniques | 3. Issues of Existing Techniques | |||
4. Modifications and Extensions Based on Existing Solutions | 4. Modifications and Extensions Based on Existing Solutions | |||
4.1. Per-Hop Postcard Using IOAM DEX | 4.1. Per-Hop Postcard Using IOAM DEX | |||
4.2. Per-Section Postcard for IOAM Trace | 4.2. Per-Section Postcard for IOAM Trace | |||
5. Application Considerations for Multicast Protocols | 5. Application Considerations for Multicast Protocols | |||
5.1. Mtrace Version 2 | 5.1. Mtrace Version 2 | |||
5.2. Application in PIM | 5.2. Application in PIM | |||
5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute | 5.3. Application of MVPN PMSI Tunnel Attribute | |||
6. Security Considerations | 6. Security Considerations | |||
7. IANA Considerations | 7. IANA Considerations | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
8.2. Informative References | 8.2. Informative References | |||
Acknowledgments | Acknowledgments | |||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
skipping to change at line 111 ¶ | skipping to change at line 111 ¶ | |||
It is essential to monitor the performance of multicast traffic. New | It is essential to monitor the performance of multicast traffic. New | |||
on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct | on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct | |||
Export (DEX) [RFC9326], IOAM Postkcard-Based Telemetry - Marking | Export (DEX) [RFC9326], IOAM Postkcard-Based Telemetry - Marking | |||
(PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS) | (PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS) | |||
[HYBRID-TWO-STEP], complement existing active OAM performance | [HYBRID-TWO-STEP], complement existing active OAM performance | |||
monitoring methods like ICMP ping [RFC0792]. However, multicast | monitoring methods like ICMP ping [RFC0792]. However, multicast | |||
traffic's unique characteristics present challenges in applying these | traffic's unique characteristics present challenges in applying these | |||
techniques efficiently. | techniques efficiently. | |||
The IP multicast packet data for a particular (S, G) state remains | The IP multicast packet data for a particular (S,G) state remains | |||
identical across different branches to multiple receivers. When IOAM | identical across different branches to multiple receivers [RFC4601]. | |||
trace data is added to multicast packets, each replicated packet | When IOAM trace data is added to multicast packets, each replicated | |||
retains telemetry data for its entire forwarding path. This results | packet retains telemetry data for its entire forwarding path. This | |||
in redundant data collection for common path segments, unnecessarily | results in redundant data collection for common path segments, | |||
consuming extra network bandwidth. For large multicast trees, this | unnecessarily consuming extra network bandwidth. For large multicast | |||
redundancy is substantial. Using solutions like IOAM DEX could be | trees, this redundancy is substantial. Using solutions like IOAM DEX | |||
more efficient by eliminating data redundancy, but IOAM DEX lacks a | could be more efficient by eliminating data redundancy, but IOAM DEX | |||
branch identifier, complicating telemetry data correlation and | lacks a branch identifier, complicating telemetry data correlation | |||
multicast tree reconstruction. | and multicast tree reconstruction. | |||
This document provides two solutions to the IOAM data-redundancy | This document provides two solutions to the IOAM data-redundancy | |||
problem based on the IOAM standards. The requirements for multicast | problem based on the IOAM standards. The requirements for multicast | |||
traffic telemetry are discussed along with the issues of the existing | traffic telemetry are discussed along with the issues of the existing | |||
on-path telemetry techniques. We propose modifications and | on-path telemetry techniques. We propose modifications and | |||
extensions to make these techniques adapt to multicast in order for | extensions to make these techniques adapt to multicast in order for | |||
the original multicast tree to be correctly reconstructed while | the original multicast tree to be correctly reconstructed while | |||
eliminating redundant data. This document does not cover the | eliminating redundant data. This document does not cover the | |||
operational considerations such as how to enable the telemetry on a | operational considerations such as how to enable the telemetry on a | |||
subset of the traffic to avoid overloading the network or the data | subset of the traffic to avoid overloading the network or the data | |||
skipping to change at line 405 ¶ | skipping to change at line 405 ¶ | |||
forward multicast UDP data packets. PIM utilizes network-based | forward multicast UDP data packets. PIM utilizes network-based | |||
source discovery. PIM-SSM, however, utilizes application-based | source discovery. PIM-SSM, however, utilizes application-based | |||
source discovery. IP multicast packets fall within the range of | source discovery. IP multicast packets fall within the range of | |||
224.0.0.0 through 239.255.255.255 for IPv4 and ff00::/8 for IPv6. | 224.0.0.0 through 239.255.255.255 for IPv4 and ff00::/8 for IPv6. | |||
The telemetry solution will need to work within these IP address | The telemetry solution will need to work within these IP address | |||
ranges and provide telemetry data for this UDP traffic. | ranges and provide telemetry data for this UDP traffic. | |||
A proposed solution for encapsulating the telemetry instruction | A proposed solution for encapsulating the telemetry instruction | |||
header and metadata in IPv6 packets is described in [RFC9486]. | header and metadata in IPv6 packets is described in [RFC9486]. | |||
5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute | 5.3. Application of MVPN PMSI Tunnel Attribute | |||
IOAM, and the recommendations of this document, are equally | IOAM, and the recommendations of this document, are equally | |||
applicable to multicast MPLS forwarded packets. Multipoint Label | applicable to multicast MPLS forwarded packets as described in | |||
Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress Replication (IR), | [RFC6514]. Multipoint Label Distribution Protocol (mLDP), P2MP RSVP- | |||
and PIM Multicast Distribution Tree (MDT) SAFI with GRE Transport are | TE, Ingress Replication (IR), and PIM Multicast Distribution Tree | |||
all commonly used within a Multicast VPN (MVPN) environment utilizing | (MDT) SAFI with GRE Transport are all commonly used within a | |||
MVPN procedures such as multicast in MPLS/BGP IP VPNs [RFC6513] and | Multicast VPN (MVPN) environment utilizing MVPN procedures such as | |||
BGP encoding and procedures for multicast in MPLS/BGP IP VPNs | multicast in MPLS/BGP IP VPNs [RFC6513] and BGP encoding and | |||
[RFC6514]. mLDP LDP extensions for P2MP and multipoint-to-multipoint | procedures for multicast in MPLS/BGP IP VPNs [RFC6514]. mLDP LDP | |||
(MP2MP) label switched paths (LSPs) [RFC6388] provide extensions to | extensions for P2MP and multipoint-to-multipoint (MP2MP) label | |||
LDP to establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS | switched paths (LSPs) [RFC6388] provide extensions to LDP to | |||
networks. The telemetry solution will need to be able to follow | establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS networks. | |||
these P2MP and MP2MP paths. The telemetry instruction header and | The telemetry solution will need to be able to follow these P2MP and | |||
data should be encapsulated into MPLS packets on P2MP and MP2MP | MP2MP paths. The telemetry instruction header and data should be | |||
paths. | encapsulated into MPLS packets on P2MP and MP2MP paths. | |||
6. Security Considerations | 6. Security Considerations | |||
The schemes discussed in this document share the same security | The schemes discussed in this document share the same security | |||
considerations for the IOAM trace option [RFC9197] and the IOAM DEX | considerations for the IOAM trace option [RFC9197] and the IOAM DEX | |||
option [RFC9326]. In particular, since multicast has a built-in | option [RFC9326]. In particular, since multicast has a built-in | |||
nature for packet amplification, the possible amplification risk for | nature for packet amplification, the possible amplification risk for | |||
the DEX-based scheme is greater than the case of unicast. Hence, | the DEX-based scheme is greater than the case of unicast. Hence, | |||
stricter mechanisms for protections need to be applied. In addition | stricter mechanisms for protections need to be applied. In addition | |||
to selecting packets to enable DEX and to limit the exported traffic | to selecting packets to enable DEX and to limit the exported traffic | |||
skipping to change at line 540 ¶ | skipping to change at line 540 ¶ | |||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
RFC 792, DOI 10.17487/RFC0792, September 1981, | RFC 792, DOI 10.17487/RFC0792, September 1981, | |||
<https://www.rfc-editor.org/info/rfc792>. | <https://www.rfc-editor.org/info/rfc792>. | |||
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute | [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute | |||
in Session Description Protocol (SDP)", RFC 3605, | in Session Description Protocol (SDP)", RFC 3605, | |||
DOI 10.17487/RFC3605, October 2003, | DOI 10.17487/RFC3605, October 2003, | |||
<https://www.rfc-editor.org/info/rfc3605>. | <https://www.rfc-editor.org/info/rfc3605>. | |||
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, | ||||
"Protocol Independent Multicast - Sparse Mode (PIM-SM): | ||||
Protocol Specification (Revised)", RFC 4601, | ||||
DOI 10.17487/RFC4601, August 2006, | ||||
<https://www.rfc-editor.org/info/rfc4601>. | ||||
[RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450, | [RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450, | |||
DOI 10.17487/RFC6450, December 2011, | DOI 10.17487/RFC6450, December 2011, | |||
<https://www.rfc-editor.org/info/rfc6450>. | <https://www.rfc-editor.org/info/rfc6450>. | |||
[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2: | [RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2: | |||
Traceroute Facility for IP Multicast", RFC 8487, | Traceroute Facility for IP Multicast", RFC 8487, | |||
DOI 10.17487/RFC8487, October 2018, | DOI 10.17487/RFC8487, October 2018, | |||
<https://www.rfc-editor.org/info/rfc8487>. | <https://www.rfc-editor.org/info/rfc8487>. | |||
[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for | [RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for | |||
End of changes. 5 change blocks. | ||||
25 lines changed or deleted | 31 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |