Network Working Group T. Nandy
Internet Draft Hewlett-Packard Enterprise
Intended status: Proposed Standard Chethan, C R
Expires: December 2024 Hewlett-Packard Enterprise
M. Subramanian
Hewlett-Packard Enterprise
June 22, 2024
Mtrace2 L2 Extensions: Traceroute Facility for Layer 2 Multicast
draft-nandy-chethan-subramanian-mtrace-layer2-00
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Tathagata, et al. Expires December 21, 2024 [Page 1]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document describes extensions to IP multicast traceroute
facility, named Mtrace2 version 2 (Mtrace2), to include
traced path for Layer 2 multicast. Mtrace2 allows tracing the path
from Last-Hop Router (LHR) to a source. Tracing the Layer 2 path
from LHR till the actual receivers requires special implementations
on the part of switches in the Layer 2 path. This specification
describes the required functionality in multicast routers and
switches. This feature functions along with the Layer 2 multicast
protocols like IGMP (Internet Group Management Protocol) Snooping
and MLD(Multicast Listener Discovery) Snooping.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
2.1. Definitions.................................................3
3. Overview.......................................................4
4. Specification..................................................6
4.1. Receiving an Mtrace2 Query on LHR.........................6
4.2. Sending Layer 2 Mtrace2 request...........................6
4.2.1. Destination Address..................................7
4.3. Receiving Layer 2 Mtrace2 request.........................7
4.3.1. Snooping disabled switch.............................8
4.3.2. Non supported device.................................8
4.4. Sending L2 Mtrace2 reply to LHR...........................9
4.5. Receiving Mtrace2 reply on LHR............................9
5. Packet Format.................................................10
6. Reply Timeout.................................................10
7. Security Considerations.......................................10
8. IANA Considerations...........................................11
9. References....................................................11
9.1. Normative References.....................................11
9.2. Informative References...................................11
10. Acknowledgments..............................................11
Tathagata, et al. Expires December 21, 2024 [Page 2]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
1. Introduction
This document provides extensions to Mtrace2 facility described in
RFC 8487[RFC8487] to include the layer 2 multicast path details. This
path begins from LHR and includes the layer 2 switches that are in
the path to subscribed hosts.
IP hosts will subscribe to a given group by sending IGMP/MLD
membership reports. The membership reports are forwarded by the
switches to Querier, PIM routers in the LAN segment which then
eventually reaches the LHR. On LHR, multicast traffic is forwarded to
the ports where joins are received. The membership information
maintained in each of these switches is used to construct the layer 2
traced path. The specification describes methods to trace the layer 2
path. Mtrace2 request packets are forwarded to the ports where
membership reports are received. Every switch in the traced path
appends the path details to Mtrace2 request packet and then forwards
the packet to the next switch from which a join is received. The
process stops when the joined port is directly connected to a client.
The switch that is directly connected to the client will append the
client details and send the Mtrace2 reply to LHR. LHR will receive
multiple such response packets each of which carries the path
information from LHR to an L2 switch. Additional information can be
included by the switches which can help in troubleshooting problems.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
2.1. Definitions
First-Hop Router (FHR):
The router that is directly connected to the source that the
Mtrace2 Query specifies.
Last-Hop Router (LHR):
Tathagata, et al. Expires December 21, 2024 [Page 3]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
A router that is directly connected to a receiver. It is also the
router that receives the Mtrace2 Query from an Mtrace2 client.
Upstream router:
The router, connecting to the Incoming Interface of the current
router, is responsible for forwarding data for the specified
source and group to the current router.
3. Overview
Mtrace2 allows tracing the path from Last-Hop Router (LHR) to a
source. In a multicast distribution tree, once the LHR routes the
packet to a LAN segment, the packets are forwarded towards the
clients based on the layer 2 forwarding rules governed by IGMP/MLD
snooping. If IGMP/MLD snooping is not enabled, the switch will
broadcast the packets to all ports in the LAN segment. The details
specific to building layer 2 distribution tree using IGMP[RFC3376]
or IGMP snooping[RFC4541] are outside the scope of this document.
It is important to note that there can be multiple receivers
subscribed to the same group and multiple switches between LHR and
the actual receivers. For a given receiver, the path taken by the
multicast packets depends on the port where IGMP/MLD Querier is
reachable as the joins are forwarded towards Querier. This document
specifies methods to populate and visualize the layer 2 multicast
distribution tree using Mtrace2 utility. This will enable network
administrator to inspect the multicast packet path for a given
source, group from source to actual receivers.
As per Mtrace2 specifications, when an Mtrace2 client initiates a
multicast trace, it sends an Mtrace2 Query packet to an LHR or RP
for a multicast group and, optionally, a source address. The LHR/RP
turns the Query packet into a Request. The LHR/RP then appends a
Standard Response Block containing its interface addresses and
packet statistics to the Request packet, then forwards the packet
towards the source/RP.
This document specifies additional steps on LHR/RP before forwarding
the packet to its upstream neighbor. Note that on RP, layer 2 tree
may not be present, in which case the RP must simply continue tracing
the layer 3 path. Upon receiving a Mtrace2 query, LHR will initiate
layer 2 tracing. LHR must start a timer whose value is set to Mtrace2
Request Response Interval (default 2 seconds). LHR should then send
layer 2 Multicast Mtrace2 request to the subscribed ports and wait
for Mtrace2 responses from snooping switches. Upon timer expiry, LHR
should consolidate the responses from different switches and append
Tathagata, et al. Expires December 21, 2024 [Page 4]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
this information in Augmented Response Blocks (ARB). The response
includes the switch details, port identifier from every switch in the
path and the client details. Additional information like statistics
may be included for troubleshooting purposes. This completes the
layer 2 tracing and LHR proceeds with layer 3 tracing by forwarding
the packet to its upstream neighbor.
| Mtrace2 query
|
v
+---+----+
+------+ LHR +-----------+
| | | |
| +---+-+--+ |
| Mtrace2| |request |
| | | |
+----------+ +---+----+ | | +----+---+
| Receiver +--------+L2Switch+<----+ +-------->+L2Switch|
+----------+ +---+--+-+ --+--+---+
| | | |
| | Mtrace2 request | |
| v | |
+---+--+-+ +-v--+---+
|L2Switch| |L2Switch|
+---+----+ +----+---+
| |
+---+-----+ +----+---+
|Receiver | |Receiver|
+---------+ +--------+
Layer 2 Mtrace request flow
+---+----+
Tathagata, et al. Expires December 21, 2024 [Page 5]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
+------+ LHR +-----------+
| | | |
| ++---+--++ |
| ^ ^ ^ Mtrace2 L2 |
| | | | Response |
+----------+ +---+----+ | | | +----+---+
| Receiver +--------+L2Switch+--+ | | |L2Switch|
+----------+ +---+----+ | | +----+---+
| | | |
| | | |
+---+----+ | | +-v--+---+
|L2Switch+------+ +-------+L2Switch|
+---+----+ +----+---+
| |
+---+-----+ +----+---+
|Receiver | |Receiver|
+---------+ +--------+
Layer 2 Mtrace response flow
4. Specification
This section describes the LHR router and snooping switches behavior
in the context of layer 2 Mtrace2 in detail.
4.1. Receiving an Mtrace2 Query on LHR
Mtrace2 operation starts when a Mtrace2 client invokes query towards
LHR/RP. There are no additional changes specific to layer 2 tracing.
Packet format remains the same for both layer 2 and layer 3 Mtrace2
Query. When LHR receives the Mtrace2 Query, it should invoke both
layer 2 and layer 3 tracing, if supported.
4.2. Sending Layer 2 Mtrace2 request
Upon receiving an Mtrace2 Query message and validating the Query
message, LHR should initiate layer 2 tracing process. LHR should
convert the message type from query to request. Based on the
membership reports, LHR may be routing the incoming multicast packets
to several interfaces.
Tathagata, et al. Expires December 21, 2024 [Page 6]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
For every interface in outgoing interface list, LHR maintains the
membership state information on a per port and per group basis. LHR
should use this information and replicate the request packet to every
port where a join is received. If LHR does not have snooping enabled,
then the multicast data packets are flooded on all the ports in the
LAN segment. LHR should send the layer 2 Mtrace2 request on all the
ports in the LAN segment if snooping is disabled. Before sending the
request packet, LHR should append a new ARB which contains the system
MAC address of the switch. The new ARB should have type code set to
0x0002. Section 6 describes the new type codes introduced for layer 2
tracing. One more ARB which includes the joined port identifier
should be appended. Joined Port Identifier ARB should have type code
set to 0x0004.
Layer 2 switches downstream may not have a valid IP address
configured on the snooping enabled interfaces. Additionally, there
can be multiple recipients for the flow. So, it is not possible to
send the layer 2 Mtrace2 request as an unicast packet. The
destination address is set to multicast address as described in the
below section.
4.2.1. Destination Address
Layer 2 Mtrace2 request packets are destined to all layer 2 snooping
switches in the LAN segment. The IP destination address is set to the
All-Snoopers multicast address.
RFC 4286[RFC4286] also uses All-Snoopers destination IP for Multicast
Router Discovery(MRD). MRD uses IGMP/MLD packets with All-Snoopers
destination IP. Switches should differentiate the packets based on
the payload. Layer 2 Mtrace2 messages are UDP based.
4.3. Receiving Layer 2 Mtrace2 request
Snooping switches that are directly connected to the LHR will receive
the layer 2 Mtrace2 request packets sent by the LHR. The switch MUST
verify the following:
o The request packet is originated from a multicast router that it
has learnt already via PIM Hello messages.
o The checksum is correct and the IP destination address is the
All-Snoopers multicast address. TTL of the packet should be set to 1.
o For IPv6, the IP source address MUST be a link-local address.
Tathagata, et al. Expires December 21, 2024 [Page 7]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
Request packets that do not meet the above requirements MUST be
silently discarded and may be logged in a rate-limited manner.
Destination IP in the packet along with the destination UDP port
number is used to identify the packet as a layer 2 Mtrace2 packet.
The receiving switch should append a new ARB which contains the
system MAC of the switch. The new ARB should have type set code set
to 0x0002. Section 6 describes the new type codes introduced for
layer 2 tracing. System MAC ARB MUST be the first ARB in the request
packet. The switch should then read the multicast forwarding table
for the given group to get a list of ports where joins are received.
For every port in this list, the request packet is replicated, and a
new ARB is appended which includes the joined port identifier. The
new ARB should have type code set to 0x0004. Additional ARBs like up
time, expiry time, system name can be optionally included in the
trace request packet. If the joined port is connected to another
switch, then the packet is sent out of the port to the next switch in
the path. Using the capabilities learnt from LLDP neighbor discovery,
the switch could identify if the device connected to a port is an
end host or not. If it's connected to end host, the Mtrace2 request
should be terminated and a new ARB with type code 0x0003 containing
the MAC address of the end client is appended to the packet.
Additional information like the hostname of the client, type of
device etc. can be optionally included in the packet. After appending
the ARBs, the Mtrace2 request packet is converted to MTrace2 response
packet and is sent back to LHR as a unicast message.
4.3.1. Snooping disabled switch
If IGMP/MLD snooping is not enabled on the switch, the incoming data
packets are flooded on all the ports in the LAN segment. In this
case, the switch may forward the layer 2 request packets to all the
ports after appending ARBs with switch's information and port
identifier. Mtrace2 request should be terminated if the ports are
connected to end hosts.
4.3.2. Non supported device
If the switch does not support Mtrace2, it may flood the incoming
Mtrace2 request packets without any modifications to the incoming
request. In this case, the traced path will not include the switch
details. Since LHR does not get any response in this case, it should
complete the layer 2 trace after the Mtrace2 request response timer
expiry.
Tathagata, et al. Expires December 21, 2024 [Page 8]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
4.4. Sending L2 Mtrace2 reply to LHR
When the switch terminates the layer 2 Mtrace2 request, it should
change the request packet into a reply, and unicast the reply to the
LHR. LHR's IP will be present in the source IP of the request packet.
It should be used as the destination IP in the reply packet. If the
switch does not have a valid IP address, then it may use the all-
zeros IP Source-Address to send the reply to LHR. LHR must not
discard the Mtrace2 reply packets received by the snooping switch
with all-zeros IP Source-Address. If appending the ARB makes the
total packet size to exceed the MTU of the incoming interface, the
snooping switch must change the Forwarding Code in the last Standard
Response Block of the received Mtrace2 Request into NO_SPACE and send
it to LHR. The traced path will include all the switches till the
NO_SPACE error is encountered.
4.5. Receiving Mtrace2 reply on LHR
LHR receives Mtrace2 replies from the snooping switches. LHR MUST
verify that the checksum is correct and TTL of the packet should be
set to 1. LHR must not discard the Mtrace2 reply packets received by
the snooping switch with all-zeros IP Source-Address. Multiple reply
packets will reach LHR. LHR should process all the reply packets till
Mtrace2 request response timer expiry. LHR should discard the reply
packets that arrive after the timer expiry. Every reply packet
contains several ARBs which includes the traced path from LHR to a
given receiver. Total number of ARBs that contains code 0x002
indicate number of switches in the path. LHR uses switch MAC ARB to
identify beginning of a new switch, since every switch appends switch
MAC as first ARB (code = 0x0002) in the request packet. Type code
0x0003 is used to identify the MAC of an end client device. Section 6
describes the ARB types introduced for layer 2 tracing.
LHR should process the reply packet and cache the path details. The
reply cache should be kept till the Mtrace2 request response timer
expiry. Upon timer expiry, LHR should consolidate the information
cached from multiple reply packets. Consolidated information can be
visualized as the layer 2 distribution tree for the given group. A
new Mtrace2 request packet should be formed and LHR should append a
SRB with its own details for layer 3 tracing. Consolidated layer 2
path details are then appended into the request packet using one or
multiple Augmented Response Blocks. Once this packet is formed, layer
2 tracing process is complete and regular layer 3 tracing begins. The
new Mtrace2 request packet should be forwarded to its upstream l3
neighbor to continue with the regular l3 tracing. When the tracing is
complete and Mtrace2 client receives a reply, the packet will include
Tathagata, et al. Expires December 21, 2024 [Page 9]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
the path from FHR to LHR and the layer 2 tree details from LHR till
the last switch that is connected to a receiver.
5. Packet Format
Layer 2 tracing uses the Augmented Response Block. The format of the
packet remains the same. New types are introduced for the 'Augmented
Response Type' column to include layer 2 path specific details.
New types added to the Augmented Response Type are listed below:
Code Type
====== ========================
0x0002 System MAC address
0x0003 Client MAC address
0x0004 Joined Port Identifier
0x0005 System name (Optional)
0x0006 Up Time (Seconds since epoch, Optional)
0x0007 Expiry Time (In seconds, Optional)
0x0008 Client Hostname (Optional)
0x0009 Client Device Type (Optional)
6. Reply Timeout
Mtrace2 defines the [Mtrace2 Reply Timeout] value to time out an
Mtrace2 reply(default 10 seconds). This document defines [Mtrace2
Request Response Interval] on LHR to time out the layer 2 tracing. By
default, this is set to 2 seconds. It can be administratively changed
on LHR.
7. Security Considerations
All the security considerations listed for Mtrace2 applies for layer
2 tracing as well.
Tathagata, et al. Expires December 21, 2024 [Page 10]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
8. IANA Considerations
This document does not contain any IANA actions.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997
[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace2 Version 2:
Traceroute Facility for IP Multicast", RFC 8487, DOI
0.17487/RFC8487, October 2018.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, DOI 10.17487/RFC4286, December 2005.
9.2. Informative References
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006.
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Tathagata, et al. Expires December 21, 2024 [Page 11]
Internet-Draft Mtrace2 for Layer 2 Multicast June 2024
Authors' Addresses
Tathagata Nandy
Hewlett Packard Enterprise
Mahadevapura, Bangalore 560048
Email: tathagata.nandy@gmail.com
Chethan C R
Hewlett Packard Enterprise
Mahadevapura, Bangalore 560048
Email: chethu123@gmail.com
Subramanian Muthukumar
Hewlett Packard Enterprise
Mahadevapura, Bangalore 560048
Email: subu690@gmail.com
Tathagata, et al. Expires December 21, 2024 [Page 12]