draft-ietf-mboned-mtrace-v2-11.txt   draft-ietf-mboned-mtrace-v2-12.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track W. Lee, Ed. Intended status: Standards Track K. Meyer
Expires: April 29, 2015 Expires: April 11, 2016 Cisco
October 26, 2014 W. Lee, Ed.
October 9, 2015
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-11 draft-ietf-mboned-mtrace-v2-12
Abstract Abstract
This document describes the IP multicast traceroute facility, named This document describes the IP multicast traceroute facility, named
Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2
requires special implementations on the part of routers. This requires special implementations on the part of routers. This
specification describes the required functionality in multicast specification describes the required functionality in multicast
routers, as well as how an Mtrace2 client invokes a query and routers, as well as how an Mtrace2 client invokes a query and
receives a reply. receives a reply.
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 29, 2015. This Internet-Draft will expire on April 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 2, line 28 skipping to change at page 2, line 29
3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11
3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 14 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 14
3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 17 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 17
3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 18 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 18
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 19 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 19
4.1.1. Query Packet Verification . . . . . . . . . . . . . . 19 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 19
4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 20 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 20
4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 20 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 20
4.2.1. Request Packet Verification . . . . . . . . . . . . . 20 4.2.1. Request Packet Verification . . . . . . . . . . . . . 20
4.2.2. Request Normal Processing . . . . . . . . . . . . . . 20 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 21
4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 22 4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 22
4.3.1. Destination Address . . . . . . . . . . . . . . . . . 22 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 23
4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 23 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 23
4.3.3. Appending Standard Response Block . . . . . . . . . . 23 4.3.3. Appending Standard Response Block . . . . . . . . . . 23
4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 23 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 24
4.4.1. Destination Address . . . . . . . . . . . . . . . . . 23 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 24
4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 23 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 24
4.4.3. Appending Standard Response Block . . . . . . . . . . 24 4.4.3. Appending Standard Response Block . . . . . . . . . . 24
4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 24 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 24
4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 24 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 25
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25
5.1.1. Destination Address . . . . . . . . . . . . . . . . . 25 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 25
5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 25 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 25
5.2. Determining the Path . . . . . . . . . . . . . . . . . . 25 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 26
5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 25 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 26
5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 26 5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 26
5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 26 5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 26
5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 26 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 26
5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 26 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 27
5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27
5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 27 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 27
5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 27 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 27
5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 27 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 27
5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 27 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 27
5.9. Continuing after an Error . . . . . . . . . . . . . . . . 27 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 28
6. Protocol-Specific Considerations . . . . . . . . . . . . . . 28 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 28
6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28
6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 29 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 29
7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 29 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 29 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 29
7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 29 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 29
7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 29 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 30
7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 30 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 30
7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . 30 8.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . 31
8.2. UDP Destination Port . . . . . . . . . . . . . . . . . . 31 8.2. UDP Destination Port . . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 31 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 31
9.2. Topology Discovery . . . . . . . . . . . . . . . . . . . 31 9.2. Topology Discovery . . . . . . . . . . . . . . . . . . . 31
9.3. Characteristics of Multicast Channel . . . . . . . . . . 31 9.3. Characteristics of Multicast Channel . . . . . . . . . . 31
9.4. Limiting Query/Request Rates . . . . . . . . . . . . . . 31 9.4. Limiting Query/Request Rates . . . . . . . . . . . . . . 32
9.5. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 31 9.5. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 32
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Given a multicast distribution tree, tracing from a multicast source Given a multicast distribution tree, tracing from a multicast source
to a receiver is difficult, since we do not know which branch of the to a receiver is difficult, since we do not know which branch of the
skipping to change at page 4, line 43 skipping to change at page 4, line 43
\ | / \ | /
\ | / \ | /
\ +---------+ / \ +---------+ /
v | Mtrace2 |/ v | Mtrace2 |/
| client | | client |
+---------+ +---------+
Figure 1 Figure 1
When an Mtrace2 client initiates a multicast trace anywhere on the When an Mtrace2 client initiates a multicast trace anywhere on the
Internet, it sends an Mtrace2 Query packet to the LHR for a multicast Internet, it sends an Mtrace2 Query packet to the LHR or RP for a
group and a source address. The LHR turns the Query packet into a multicast group and a source address. The LHR/RP turns the Query
Request, appends a standard response block containing its interface packet into a Request, appends a standard response block containing
addresses and packet statistics to the Request packet, then forwards its interface addresses and packet statistics to the Request packet,
the packet towards the source. The Request packet is either then forwards the packet towards the source. The Request packet is
unicasted to its upstream router towards the source, or multicasted either unicasted to its upstream router towards the source, or
to the group if the upstream router's IP address is not known. In a multicasted to the group if the upstream router's IP address is not
similar fashion, each router along the path to the source appends a known. In a similar fashion, each router along the path to the
standard response block to the end of the Request packet before source appends a standard response block to the end of the Request
forwarding it to its upstream router. When the FHR receives the packet before forwarding it to its upstream router. When the FHR
Request packet, it appends its own standard response block, turns the receives the Request packet, it appends its own standard response
Request packet into a Reply, and unicasts the Reply back to the block, turns the Request packet into a Reply, and unicasts the Reply
Mtrace2 client. back to the Mtrace2 client.
The Mtrace2 Reply may be returned before reaching the FHR if it The Mtrace2 Reply may be returned before reaching the FHR if it
reaches the RP first, or a fatal error condition such as "no route" reaches the RP first, or a fatal error condition such as "no route"
is encountered along the path, or the hop count is exceeded. is encountered along the path, or the hop count is exceeded.
The Mtrace2 client waits for the Mtrace2 Reply message and displays The Mtrace2 client waits for the Mtrace2 Reply message and displays
the results. When not receiving an Mtrace2 Reply message due to the results. When not receiving an Mtrace2 Reply message due to
network congestion, a broken router (see Section 5.6), or a non- network congestion, a broken router (see Section 5.6), or a non-
responding router (see Section 5.7), the Mtrace2 client may resend responding router (see Section 5.7), the Mtrace2 client may resend
another Mtrace2 Query with a lower hop count (see Section 3.2.1), and another Mtrace2 Query with a lower hop count (see Section 3.2.1), and
skipping to change at page 6, line 48 skipping to change at page 6, line 48
3. Packet Formats 3. Packet Formats
This section describes the details of the packet formats for Mtrace2 This section describes the details of the packet formats for Mtrace2
messages. messages.
All Mtrace2 messages are encoded in TLV format (see Section 3.1). If All Mtrace2 messages are encoded in TLV format (see Section 3.1). If
an implementation receives an unknown TLV, it SHOULD ignored and an implementation receives an unknown TLV, it SHOULD ignored and
silently discarded the unknown TLV. If the length of a TLV exceeds silently discarded the unknown TLV. If the length of a TLV exceeds
the length specified in the TLV, the TLV SHOULD be accepted; however, the length specified in the TLV, the TLV SHOULD be accepted; however,
any additional data after the TLV SHOULD be ignored. any additional data after the specified TLV length SHOULD be ignored.
All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and
Request messages MUST NOT be fragmented. For IPv6, the packet size Request messages MUST NOT be fragmented. For IPv6, the packet size
for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the
smallest MTU for an IPv6 interface [2]. The source port is uniquely smallest MTU for an IPv6 interface [2]. The source port is uniquely
selected by the local host operating system. The destination port is selected by the local host operating system. The destination port is
the IANA reserved Mtrace2 port number (see Section 8). All Mtrace2 the IANA reserved Mtrace2 port number (see Section 8). All Mtrace2
messages MUST have a valid UDP checksum. messages MUST have a valid UDP checksum.
Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed. Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
Each Mtrace2 message MUST begin with either a Query, Request or Reply Each Mtrace2 message MUST begin with either a Query, Request or Reply
TLV. The first TLV determines the type of each Mtrace2 message. TLV. The first TLV determines the type of each Mtrace2 message.
Following a Query TLV, there can be a sequence of optional Extended Following a Query TLV, there can be a sequence of optional Extended
Query Blocks. In the case of a Request or a Reply TLV, it is then Query Blocks. In the case of a Request or a Reply TLV, it is then
followed by a sequence of Standard Response Blocks, each from a followed by a sequence of Standard Response Blocks, each from a
multicast router on the path towards the source or the RP. In the multicast router on the path towards the source or the RP. In the
case more information is needed, a Standard Response Block can be case more information is needed, a Standard Response Block can be
followed by one or multiple Augmented Response Blocks. followed by one or multiple Augmented Response Blocks.
We will describe each message type in details in the next few We will describe each message type in detail in the next few
sections. sections.
3.2.1. Mtrace2 Query 3.2.1. Mtrace2 Query
An Mtrace2 Query is usually originated by an Mtrace2 client which An Mtrace2 Query is usually originated by an Mtrace2 client which
sends an Mtrace2 Query message to the LHR. When tracing towards the sends an Mtrace2 Query message to the LHR. When tracing towards the
source or the RP, the intermediate routers MUST NOT modify the Query source or the RP, the intermediate routers MUST NOT modify the Query
message except the Type field. message except the Type field.
An Mtrace2 Query message is shown as follows: An Mtrace2 Query message is shown as follows:
skipping to change at page 9, line 31 skipping to change at page 9, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query ID | Client Port # | | Query ID | Client Port # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
# Hops: 8 bits # Hops: 8 bits
This field specifies the maximum number of hops that the Mtrace2 This field specifies the maximum number of hops that the Mtrace2
client wants to trace. If there are some error conditions in the client wants to trace. If there are some error conditions in the
middle of the path that prevent an Mtrace2 Reply from being middle of the path that prevent an Mtrace2 Reply from being
received by the client, the client MAY issues another Mtrace2 received by the client, the client MAY issue another Mtrace2 Query
Query with the lower number of hops until it receives a Reply. with a lower number of hops until it receives a Reply.
Multicast Address: 32 bits or 128 bits Multicast Address: 32 bits or 128 bits
This field specifies an IPv4 or IPv6 address, which can be either: This field specifies an IPv4 or IPv6 address, which can be either:
m-1: a multicast group address to be traced; or, m-1: a multicast group address to be traced; or,
m-2: all 1's in case of IPv4 or the unspecified address (::) in m-2: all 1's in case of IPv4 or the unspecified address (::) in
case of IPv6 if no group-specific information is desired. case of IPv6 if no group-specific information is desired.
Source Address: 32 bits or 128 bits Source Address: 32 bits or 128 bits
skipping to change at page 13, line 10 skipping to change at page 13, line 10
transmitted or queued for transmission for all groups and sources transmitted or queued for transmission for all groups and sources
on the outgoing interface, or all 1's if no count can be reported. on the outgoing interface, or all 1's if no count can be reported.
This counter may have the same value as ifHCOutMulticastPkts from This counter may have the same value as ifHCOutMulticastPkts from
the IF-MIB [10] for this interface. the IF-MIB [10] for this interface.
Total number of packets for this source-group pair: 64 bits Total number of packets for this source-group pair: 64 bits
This field counts the number of packets from the specified source This field counts the number of packets from the specified source
forwarded by the router to the specified group, or all 1's if no forwarded by the router to the specified group, or all 1's if no
count can be reported. If the S bit is set (see below), the count count can be reported. If the S bit is set (see below), the count
is for the source network, as specified by the Src Mask field (see is for the source network, as specified by the Src Mask field (see
below). If the S bit is set and the Src Mask field is 63, below). If the S bit is set and the Src Mask field is 127,
indicating no source-specific state, the count is for all sources indicating no source-specific state, the count is for all sources
sending to this group. This counter should have the same value as sending to this group. This counter should have the same value as
ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] for this ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] for this
forwarding entry. forwarding entry.
Rtg Protocol: 16 bits Rtg Protocol: 16 bits
This field describes the unicast routing protocol running between This field describes the unicast routing protocol running between
this router and the upstream router, and it is used to determine this router and the upstream router, and it is used to determine
the RPF interface for the specified source or RP. This value the RPF interface for the specified source or RP. This value
should have the same value as ipMcastRouteRtProtocol from the should have the same value as ipMcastRouteRtProtocol from the
skipping to change at page 19, line 25 skipping to change at page 19, line 25
Extended Query Type: 16 bits Extended Query Type: 16 bits
This field specifies the type of the Extended Query Block. This field specifies the type of the Extended Query Block.
Value: 16 bits Value: 16 bits
This field specifies the value of this Extended Query. This field specifies the value of this Extended Query.
4. Router Behavior 4. Router Behavior
This section describes the router behavior in the context of Mtrace2 This section describes the router behavior in the context of Mtrace2
in details. in detail.
4.1. Receiving Mtrace2 Query 4.1. Receiving Mtrace2 Query
An Mtrace2 Query message is an Mtrace2 message with no response An Mtrace2 Query message is an Mtrace2 message with no response
blocks filled in, and uses TLV type of 0x01. blocks filled in, and uses TLV type of 0x01.
4.1.1. Query Packet Verification 4.1.1. Query Packet Verification
Upon receiving an Mtrace2 Query message, a router MUST examine Upon receiving an Mtrace2 Query message, a router MUST examine
whether the Multicast Address and the Source Address are a valid whether the Multicast Address and the Source Address are a valid
combination as specified in Section 3.2.1, and whether the Mtrace2 combination as specified in Section 3.2.1, and whether the Mtrace2
Client Address is a valid IP unicast address. If either one is Client Address is a valid IP unicast address. If either one is
invalid, the Query MUST be silently ignored. invalid, the Query MUST be silently ignored.
Mtrace2 supports non-local client to the LHR. It is up to the Mtrace2 supports a non-local client to the LHR/RP. It is up to the
implementation to filter out such queries. implementation to filter out such queries.
In the case when it is a local client, the router must then examine In the case where a local LHR client is required, the router must
the Query to see if it is the proper LHR for the destination address then examine the Query to see if it is the proper LHR/RP for the
in the packet. It is the proper LHR if it has a multicast-capable destination address in the packet. It is the proper local LHR if it
interface on the same subnet as the Mtrace2 Client Address and is the has a multicast-capable interface on the same subnet as the Mtrace2
router that would forward traffic from the given (S,G) or (*,G) onto Client Address and is the router that would forward traffic from the
that subnet. given (S,G) or (*,G) onto that subnet. It is the proper RP if the
multicast group address specified in the query is 0 and if the IP
header destination address is a valid RP address on this router.
If the router determines that it is not the proper LHR, or it cannot If the router determines that it is not the proper LHR/RP, or it
make that determination, it does one of two things depending on cannot make that determination, it does one of two things depending
whether the Query was received via multicast or unicast. If the on whether the Query was received via multicast or unicast. If the
Query was received via multicast, then it MUST be silently discarded. Query was received via multicast, then it MUST be silently discarded.
If it was received via unicast, the router turns the Query into a If it was received via unicast, the router turns the Query into a
Reply message by changing the TLV type to 0x03 and appending a Reply message by changing the TLV type to 0x03 and appending a
Standard Response Block with a Forwarding Code of WRONG_LAST_HOP. Standard Response Block with a Forwarding Code of WRONG_LAST_HOP.
The rest of the fields in the Standard Response Block MUST be zeroed. The rest of the fields in the Standard Response Block MUST be zeroed.
The router then sends the Reply message to the Mtrace2 Client Address The router then sends the Reply message to the Mtrace2 Client Address
on the Client Port # as specified in the Mtrace2 Query. on the Client Port # as specified in the Mtrace2 Query.
Duplicate Query messages as identified by the tuple (Mtrace2 Client Duplicate Query messages as identified by the tuple (Mtrace2 Client
Address, Query ID) SHOULD be ignored. This MAY be implemented using Address, Query ID) SHOULD be ignored. This MAY be implemented using
skipping to change at page 21, line 33 skipping to change at page 21, line 40
state should be used. If there is no group state or no group- state should be used. If there is no group state or no group-
specific information is desired, potential source state (i.e., specific information is desired, potential source state (i.e.,
the path that would be followed for a source-specific Join) the path that would be followed for a source-specific Join)
should be used. should be used.
3. If no forwarding information can be determined, the router notes 3. If no forwarding information can be determined, the router notes
a Forwarding Code of NO_ROUTE, sets the remaining fields that a Forwarding Code of NO_ROUTE, sets the remaining fields that
have not yet been filled in to zero, and then sends an Mtrace2 have not yet been filled in to zero, and then sends an Mtrace2
Reply back to the Mtrace2 client. Reply back to the Mtrace2 client.
4. Fill in the Incoming Interface Address, Upstream Router Address, 4. Fill in the Incoming Interface Address (or Incoming Interface ID
Input Packet Count, Total Number of Packets, Routing Protocol, and Local Address for IPv6), Upstream Router Address (or Remote
S, and Src Mask (or Src Prefix Len for IPv6) using the Address for IPv6), Input Packet Count, Total Number of Packets,
forwarding information determined by the step 2. Routing Protocol, S, and Src Mask (or Src Prefix Len for IPv6)
using the forwarding information determined by the step 2.
5. If Mtrace2 is administratively prohibited, note the Forwarding 5. If Mtrace2 is administratively prohibited, note the Forwarding
Code of ADMIN_PROHIB. If Mtrace2 is administratively prohibited Code of ADMIN_PROHIB. If Mtrace2 is administratively prohibited
and any of the fields as filled in the step 4 are considered and any of the fields as filled in the step 4 are considered
private information, zero out the applicable fields. private information, zero out the applicable fields.
6. If the Outgoing interface is not enabled for multicast, note 6. If the Outgoing interface is not enabled for multicast, note
Forwarding Code of NO_MULTICAST. If the Outgoing interface is Forwarding Code of NO_MULTICAST. If the Outgoing interface is
the interface from which the router would expect data to arrive the interface from which the router would expect data to arrive
from the source, note forwarding code RPF_IF. If the Outgoing from the source, note forwarding code RPF_IF. If the Outgoing
interface is not one to which the router would forward data from interface is not one to which the router would forward data from
the source or RP to the group, a Forwarding code of WRONG_IF is the source or RP to the group, a Forwarding code of WRONG_IF is
noted. In the above three cases, the router will return an noted. In the above three cases, the router will return an
Mtrace2 Reply and terminate the trace. Mtrace2 Reply and terminate the trace.
7. If the group is subject to administrative scoping on either the 7. If the group is subject to administrative scoping on either the
Outgoing or Incoming interfaces, a Forwarding Code of SCOPED is Outgoing or Incoming interfaces, a Forwarding Code of SCOPED is
noted. noted.
8. If this router is the RP for the group, note a Forwarding Code 8. If this router is the RP for the group for a non-source-specific
of REACHED_RP. The router will send an Mtrace2 Reply and query, note a Forwarding Code of REACHED_RP. The router will
terminate the trace. send an Mtrace2 Reply and terminate the trace.
9. If this router has sent a prune upstream which applies to the 9. If this router is directly connected to the specified source or
source network on the Incoming interface, it sets the Upstream
Router Address (for IPv4) or the Remote Address (for IPv6) of
the response block to zero. The router will send an Mtrace2
Reply and terminate the trace.
10. If this router has sent a prune upstream which applies to the
source and group in the Mtrace2 Request, it notes Forwarding source and group in the Mtrace2 Request, it notes Forwarding
Code of PRUNE_SENT. If the router has stopped forwarding Code of PRUNE_SENT. If the router has stopped forwarding
downstream in response to a prune sent by the downstream router, downstream in response to a prune sent by the downstream router,
it notes Forwarding Code of PRUNE_RCVD. If the router should it notes Forwarding Code of PRUNE_RCVD. If the router should
normally forward traffic downstream for this source and group normally forward traffic downstream for this source and group
but is not, it notes Forwarding Code of NOT_FORWARDING. but is not, it notes Forwarding Code of NOT_FORWARDING.
10. If this router is a gateway (e.g., a NAT or firewall) that hides 11. If this router is a gateway (e.g., a NAT or firewall) that hides
the information between this router and the Mtrace2 client, it the information between this router and the Mtrace2 client, it
notes Forwarding Code of REACHED_GW. The router continues the notes Forwarding Code of REACHED_GW. The router continues the
processing as described in Section 4.5. processing as described in Section 4.5.
11. If the total number of the Standard Response Blocks, including 12. If the total number of the Standard Response Blocks, including
the newly prepared one, and the value of the Augmented Response the newly prepared one, and the value of the Augmented Response
Type of 0x01, if any, is less than the # Hops in the Request, Type of 0x01, if any, is less than the # Hops in the Request,
the packet is then forwarded to the upstream router as described the packet is then forwarded to the upstream router as described
in Section 4.3; otherwise, the packet is sent as an Mtrace2 in Section 4.3; otherwise, the packet is sent as an Mtrace2
Reply to the Mtrace2 client as described in Section 4.4. Reply to the Mtrace2 client as described in Section 4.4.
4.3. Forwarding Mtrace2 Request 4.3. Forwarding Mtrace2 Request
This section describes how an Mtrace2 Request should be forwarded. This section describes how an Mtrace2 Request should be forwarded.
skipping to change at page 25, line 7 skipping to change at page 25, line 29
from the Mtrace2 Requests. The Forwarding Code of INFO_HIDDEN may be from the Mtrace2 Requests. The Forwarding Code of INFO_HIDDEN may be
used to note that. For example, the incoming interface address and used to note that. For example, the incoming interface address and
packet count on the ingress router of a domain, and the outgoing packet count on the ingress router of a domain, and the outgoing
interface address and packet count on the egress router of the domain interface address and packet count on the egress router of the domain
can be specified as all 1's. Additionally, the source-group packet can be specified as all 1's. Additionally, the source-group packet
count (see Section 3.2.4 and Section 3.2.5) within the domain may be count (see Section 3.2.4 and Section 3.2.5) within the domain may be
all 1's if it is hidden. all 1's if it is hidden.
5. Client Behavior 5. Client Behavior
This section describes the behavior of an Mtrace2 client in details. This section describes the behavior of an Mtrace2 client in detail.
5.1. Sending Mtrace2 Query 5.1. Sending Mtrace2 Query
An Mtrace2 client initiates an Mtrace2 Query by sending the Query to An Mtrace2 client initiates an Mtrace2 Query by sending the Query to
the LHR of interest. the LHR of interest.
5.1.1. Destination Address 5.1.1. Destination Address
If an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2 If an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2
Query packet to that router; otherwise, it MAY send the Mtrace2 Query Query packet to that router; otherwise, it MAY send the Mtrace2 Query
skipping to change at page 28, line 20 skipping to change at page 28, line 40
different multicast protocols. different multicast protocols.
6.1. PIM-SM 6.1. PIM-SM
When an Mtrace2 reaches a PIM-SM RP, and the RP does not forward the When an Mtrace2 reaches a PIM-SM RP, and the RP does not forward the
trace on, it means that the RP has not performed a source-specific trace on, it means that the RP has not performed a source-specific
join so there is no more state to trace. However, the path that join so there is no more state to trace. However, the path that
traffic would use if the RP did perform a source-specific join can be traffic would use if the RP did perform a source-specific join can be
traced by setting the trace destination to the RP, the trace source traced by setting the trace destination to the RP, the trace source
to the traffic source, and the trace group to 0. This Mtrace2 Query to the traffic source, and the trace group to 0. This Mtrace2 Query
may be unicasted to the RP. may be unicasted to the RP, and the RP takes the same actions as an
LHR.
6.2. Bi-Directional PIM 6.2. Bi-Directional PIM
Bi-directional PIM [6] is a variant of PIM-SM that builds bi- Bi-directional PIM [6] is a variant of PIM-SM that builds bi-
directional shared trees connecting multicast sources and receivers. directional shared trees connecting multicast sources and receivers.
Along the bi-directional shared trees, multicast data is natively Along the bi-directional shared trees, multicast data is natively
forwarded from the sources to the Rendezvous Point Link (RPL), and forwarded from the sources to the Rendezvous Point Link (RPL), and
from which, to receivers without requiring source-specific state. In from which, to receivers without requiring source-specific state. In
contrast to PIM-SM, Bi-directional PIM always has the state to trace. contrast to PIM-SM, Bi-directional PIM always has the state to trace.
skipping to change at page 31, line 50 skipping to change at page 32, line 17
A router may limit Mtrace2 Queries and Requests by ignoring some of A router may limit Mtrace2 Queries and Requests by ignoring some of
the consecutive messages. The router MAY randomly ignore the the consecutive messages. The router MAY randomly ignore the
received messages to minimize the processing overhead, i.e., to keep received messages to minimize the processing overhead, i.e., to keep
fairness in processing queries, or prevent traffic amplification. fairness in processing queries, or prevent traffic amplification.
The rate limit is left to the router's implementation. The rate limit is left to the router's implementation.
9.5. Limiting Reply Rates 9.5. Limiting Reply Rates
The proxying and NO_SPACE behaviors may result in one Query returning The proxying and NO_SPACE behaviors may result in one Query returning
multiple Reply messages. In order to prevent abuse, the routers in multiple Reply messages. In order to prevent abuse, the routers in
the traced MAY need to rate-limit the Replies. The rate limit the traced path MAY need to rate-limit the Replies. The rate limit
function is left to the router's implementation. function is left to the router's implementation.
10. Acknowledgements 10. Acknowledgements
This specification started largely as a transcription of Van This specification started largely as a transcription of Van
Jacobson's slides from the 30th IETF, and the implementation in Jacobson's slides from the 30th IETF, and the implementation in
mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve
Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original
multicast traceroute client, mtrace (version 1), has been implemented multicast traceroute client, mtrace (version 1), has been implemented
by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the
"S" bit to allow statistics for a source subnet is due to Tom "S" bit to allow statistics for a source subnet is due to Tom
Pusateri. Pusateri.
For the Mtrace version 2 specification, the authors would like to For the Mtrace version 2 specification, the authors would like to
give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner. give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner.
Also, extensive comments were received from David L. Black, Ronald Also, extensive comments were received from David L. Black, Ronald
Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert W. Kebler, Heidi Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, Heidi Ou,
Ou, Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin,
and Cao Wei. Stig Venaas, and Cao Wei.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate [1] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997. requirement levels", RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
skipping to change at page 33, line 37 skipping to change at page 34, line 4
Authors' Addresses Authors' Addresses
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795 Koganei, Tokyo 184-8795
Japan Japan
Email: asaeda@nict.go.jp Email: asaeda@nict.go.jp
Kerry Meyer
Cisco Systems, Inc.
510 McCarthy Blvd.
Milpitas, CA 95035
USA
Email: kerrymey@cisco.com
WeeSan Lee (editor) WeeSan Lee (editor)
Email: weesan@weesan.com
 End of changes. 35 change blocks. 
67 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/