draft-ietf-mboned-mtrace-v2-15.txt   draft-ietf-mboned-mtrace-v2-16.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track K. Meyer Intended status: Standards Track K. Meyer
Expires: February 14, 2017 Cisco Expires: May 4, 2017 Cisco
W. Lee, Ed. W. Lee, Ed.
August 13, 2016 October 31, 2016
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-15 draft-ietf-mboned-mtrace-v2-16
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 37 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 February 14, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 7 3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 7
3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10
3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10
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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28
6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . 31 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 31
8.2. UDP Destination Port . . . . . . . . . . . . . . . . . . 31 8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 31
8.3. 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. Filtering of Clients . . . . . . . . . . . . . . . . . . 31 9.2. Filtering of Clients . . . . . . . . . . . . . . . . . . 31
9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32
9.4. Characteristics of Multicast Channel . . . . . . . . . . 32 9.4. Characteristics of Multicast Channel . . . . . . . . . . 32
9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 32 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 32
9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 32 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 32
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
skipping to change at page 3, line 48 skipping to change at page 3, line 49
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
multicast tree the receiver lies. This means that we have to flood multicast tree the receiver lies. This means that we have to flood
the whole tree to find the path from a source to a receiver. On the the whole tree to find the path from a source to a receiver. On the
other hand, walking up the tree from a receiver to a source is easy, other hand, walking up the tree from a receiver to a source is easy,
as most existing multicast routing protocols know the upstream router as most existing multicast routing protocols know the upstream router
for each source. Tracing from a receiver to a source can involve for each source. Tracing from a receiver to a source can involve
only the routers on the direct path. only the routers on the direct path.
This document specifies the multicast traceroute facility named This document specifies the multicast traceroute facility named
Mtrace version 2 or Mtrace2 which allows the tracing of an IP Mtrace version 2 or Mtrace2 which allows the tracing of an IP
multicast routing path. Mtrace2 is usually initiated from a Mtrace2 multicast routing path. Mtrace2 is usually initiated from an Mtrace2
client towards a specified source, or a Rendezvous Point (RP) if no client by sending an Mtrace2 Query to a Last Hop Router (LHR) or to a
source address is specified. RP is a special router where the source Rendezvous Point (RP). The RP is a special router where sources and
and receiver meet in PIM-SM [5]. Moreover, Mtrace2 provides receivers meet in PIM-SM [5]. From the LHR/RP receiving the query,
additional information such as the packet rates and losses, as well the tracing is directed towards a specified source if a source
as other diagnosis information. Especially, Mtrace2 can be used for address is specified and source specific state exists on the
the following purposes: receiving router. If no source address is specified or if no source
specific state exists on a receiving LHR, the tracing is directed
toward the RP for the specified group address. Moreover, Mtrace2
provides additional information such as the packet rates and losses,
as well as other diagnostic information. Mtrace2 is primarily
intended for the following purposes:
o To trace the path that a packet would take from a source to a o To trace the path that a packet would take from a source to a
receiver. receiver.
o To isolate packet loss problems (e.g., congestion). o To isolate packet loss problems (e.g., congestion).
o To isolate configuration problems (e.g., TTL threshold). o To isolate configuration problems (e.g., TTL threshold).
Figure 1 shows a typical case on how Mtrace2 is used. FHR represents Figure 1 shows a typical case on how Mtrace2 is used. FHR represents
the first-hop router, LHR represents the last-hop router, and the the first-hop router, LHR represents the last-hop router, and the
arrow lines represent the Mtrace2 messages that are sent from one arrow lines represent the Mtrace2 messages that are sent from one
node to another. The numbers before the Mtrace2 messages represent node to another. The numbers before the Mtrace2 messages represent
the sequence of the messages that would happen. Source, Receiver and the sequence of the messages that would happen. Source, Receiver and
Mtrace2 client are typically a host on the Internet. Mtrace2 client are typically hosts.
2. Request 2. Request 2. Request 2. Request
+----+ +----+ +----+ +----+
| | | | | | | |
v | v | v | v |
+--------+ +-----+ +-----+ +----------+ +--------+ +-----+ +-----+ +----------+
| Source |----| FHR |----- The Internet -----| LHR |----| Receiver | | Source |----| FHR |----- The Internet -----| LHR |----| Receiver |
+--------+ +-----+ | +-----+ +----------+ +--------+ +-----+ | +-----+ +----------+
\ | ^ \ | ^
\ | / \ | /
skipping to change at page 4, line 43 skipping to change at page 4, line 49
3. Reply \ | / 1. Query 3. Reply \ | / 1. Query
\ | / \ | /
\ | / \ | /
\ +---------+ / \ +---------+ /
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, it sends an
Internet, it sends an Mtrace2 Query packet to the LHR or RP for a Mtrace2 Query packet to the LHR or RP for a multicast group and,
multicast group and a source address. The LHR/RP turns the Query optionally, a source address. The LHR/RP turns the Query packet into
packet into a Request, appends a standard response block containing a Request. The Request message type enables each of the upstream
its interface addresses and packet statistics to the Request packet, routers processing the message to apply different packet and message
then forwards the packet towards the source. The Request packet is validation rules than those required for handling of a Query message.
either unicasted to its upstream router towards the source, or 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. The Request packet is
either unicasted to its upstream router towards the source/RP, or
multicasted to the group if the upstream router's IP address is not multicasted to the group if the upstream router's IP address is not
known. In a similar fashion, each router along the path to the known. In a similar fashion, each router along the path to the
source appends a standard response block to the end of the Request source/RP appends a standard response block to the end of the Request
packet before forwarding it to its upstream router. When the FHR packet before forwarding it to its upstream router. When the FHR
receives the Request packet, it appends its own standard response receives the Request packet, it appends its own standard response
block, turns the Request packet into a Reply, and unicasts the Reply block, turns the Request packet into a Reply, and unicasts the Reply
back to the 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 under some
reaches the RP first, or a fatal error condition such as "no route" circumstances. This can happen if a Request packet is received at an
is encountered along the path, or the hop count is exceeded. RP or gateway, or when any of several types of error or exception
conditions occur which prevent sending of a request to the next
upstream router.
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
repeat the process until it receives an Mtrace2 Reply message. The repeat the process until it receives an Mtrace2 Reply message. The
details are Mtrace2 client specific, and it is outside the scope of details are Mtrace2 client specific, and it is outside the scope of
this document. this document.
skipping to change at page 6, line 6 skipping to change at page 6, line 16
Since Mtrace2 Queries and Requests flow in the opposite direction to Since Mtrace2 Queries and Requests flow in the opposite direction to
the data flow, we refer to "upstream" and "downstream" with respect the data flow, we refer to "upstream" and "downstream" with respect
to data, unless explicitly specified. to data, unless explicitly specified.
Incoming interface Incoming interface
The interface on which data is expected to arrive from the The interface on which data is expected to arrive from the
specified source and group. specified source and group.
Outgoing interface Outgoing interface
The interface to which data from the source or RP is expected to This is one of the interfaces to which data from the source or RP
transmit for the specified source and group. It is also the is expected to be transmitted for the specified source and group.
interface on which the Mtrace2 Request will be received. It is also the interface on which the Mtrace2 Request was
received.
Upstream router Upstream router
The router, connecting to the Incoming interface of the current The router, connecting to the Incoming interface of the current
router, which is responsible for forwarding data for the specified router, which is responsible for forwarding data for the specified
source and group to the current router. source and group to the current router.
First-hop router (FHR) First-hop router (FHR)
The router that is directly connected to the source the Mtrace2 The router that is directly connected to the source the Mtrace2
Query specifies. Query specifies.
Last-hop router (LHR) Last-hop router (LHR)
The router that is directly connected to the receivers. It is A router that is directly connected to a receiver. It is also the
also the router that receives the Mtrace2 Query from an Mtrace2 router that receives the Mtrace2 Query from an Mtrace2 client.
client.
Group state Group state
It is the state a shared-tree protocol, such as PIM-SM [5], uses It is the state a shared-tree protocol, such as PIM-SM [5], uses
to choose the upstream router towards the RP for the specified to choose the upstream router towards the RP for the specified
group. In this state, source-specific state is not available for group. In this state, source-specific state is not available for
the corresponding group address on the router. the corresponding group address on the router.
Source-specific state Source-specific state
It is the state that is used to choose the path towards the source It is the state that is used to choose the path towards the source
for the specified source and group. for the specified source and group.
skipping to change at page 6, line 46 skipping to change at page 7, line 10
communicate with their adjacent routers that are running the same communicate with their adjacent routers that are running the same
routing protocol. For instance, the address of ALL-PIM- routing protocol. For instance, the address of ALL-PIM-
ROUTERS.MCAST.NET [5] is '224.0.0.13' for IPv4 and 'ff02::d' for ROUTERS.MCAST.NET [5] is '224.0.0.13' for IPv4 and 'ff02::d' for
IPv6. IPv6.
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).
an implementation receives an unknown TLV, it SHOULD ignore and The first TLV of a message is a message header TLV specifying the
silently discard the unknown TLV. If the length of a TLV exceeds the type of message and additional context information required for
length specified in the TLV, the TLV SHOULD be accepted; however, any processing of the message and for parsing of subsequent TLVs in the
additional data after the specified TLV length SHOULD be ignored. message. Subsequent TLVs in a message, referred to as Blocks, are
appended after the header TLV to provide additional information
associated with the message. If an implementation receives an
unknown TLV type for the first TLV in a message, it SHOULD ignore and
silently discard the TLV and any subsequent TLVs in the packet
containing the TLV. If an implementation receives an unknown TLV
type for a subsequent TLV within a message, it SHOULD ignore and
silently discard the TLV. If the length of a TLV exceeds the
available space in the containing packet, the implementation MUST
ignore and silently discard the TLV and any remaining portion of the
containing packet. Any data in the packet after the specified TLV
length is considered to be outside the boundary of the TLV and MUST
be ignored during processing of the TLV.
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 7, line 34 skipping to change at page 8, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 8 bits Type: 8 bits
Describes the format of the Value field. For all the available Describes the format of the Value field. For all the available
types, please see Section 3.2 types, please see Section 3.2
Length: 16 bits Length: 16 bits
Length of Type, Length, and Value fields in octets. Minimum Length of Type, Length, and Value fields in octets. Minimum
length required is 6 octets. The maximum TLV length is not length required is 3 octets. The maximum TLV length is not
defined; however the entire Mtrace2 packet length should not defined; however the entire Mtrace2 packet length SHOULD NOT
exceed the available MTU. exceed the available MTU.
Value: variable length Value: variable length
The format is based on the Type value. The length of the value The format is based on the Type value. The length of the value
field is Length field minus 3. All reserved fields in the Value field is Length field minus 3. All reserved fields in the Value
field MUST be transmitted as zeros and ignored on receipt. field MUST be transmitted as zeros and ignored on receipt.
3.2. Defined TLVs 3.2. Defined TLVs
skipping to change at page 11, line 41 skipping to change at page 11, line 41
| | | |
. Total number of packets for this source-group pair . . Total number of packets for this source-group pair .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtg Protocol | Multicast Rtg Protocol | | Rtg Protocol | Multicast Rtg Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fwd TTL | MBZ |S| Src Mask |Forwarding Code| | Fwd TTL | MBZ |S| Src Mask |Forwarding Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ: 8 bits MBZ: 8 bits
This field must be zeroed on transmission and ignored on This field MUST be zeroed on transmission and ignored on
reception. reception.
Query Arrival Time: 32 bits Query Arrival Time: 32 bits
The Query Arrival Time is a 32-bit NTP timestamp specifying the The Query Arrival Time is a 32-bit NTP timestamp specifying the
arrival time of the Mtrace2 Query or Request packet at this arrival time of the Mtrace2 Query or Request packet at this
router. The 32-bit form of an NTP timestamp consists of the router. The 32-bit form of an NTP timestamp consists of the
middle 32 bits of the full 64-bit form; that is, the low 16 bits middle 32 bits of the full 64-bit form; that is, the low 16 bits
of the integer part and the high 16 bits of the fractional part. of the integer part and the high 16 bits of the fractional part.
The following formula converts from a UNIX timeval to a 32-bit NTP The following formula converts from a UNIX timeval to a 32-bit NTP
skipping to change at page 13, line 47 skipping to change at page 13, line 47
source-group pair is for the source network, as determined by source-group pair is for the source network, as determined by
masking the source address with the Src Mask field. masking the source address with the Src Mask field.
Src Mask: 7 bits Src Mask: 7 bits
This field contains the number of 1's in the netmask the router This field contains the number of 1's in the netmask the router
has for the source (i.e. a value of 24 means the netmask is has for the source (i.e. a value of 24 means the netmask is
0xffffff00). If the router is forwarding solely on group state, 0xffffff00). If the router is forwarding solely on group state,
this field is set to 127 (0x7f). this field is set to 127 (0x7f).
Forwarding Code: 8 bits Forwarding Code: 8 bits
This field contains a forwarding information/error code. This field contains a forwarding information/error code. Values
Section 4.1 and Section 4.2 will explain how and when the with the high order bit set (0x80-0xff) are intended for use as
Forwarding Code is filled. Defined values are as follows: error or exception codes. Section 4.1 and Section 4.2 explain how
and when the Forwarding Code is filled. Defined values are as
follows:
Value Name Description Value Name Description
----- -------------- ---------------------------------------------- ----- -------------- ----------------------------------------------
0x00 NO_ERROR No error 0x00 NO_ERROR No error
0x01 WRONG_IF Mtrace2 Request arrived on an interface 0x01 WRONG_IF Mtrace2 Request arrived on an interface
to which this router would not forward for to which this router would not forward for
the specified group towards the source or RP. the specified group towards the source or RP.
0x02 PRUNE_SENT This router has sent a prune upstream which 0x02 PRUNE_SENT This router has sent a prune upstream which
applies to the source and group in the applies to the source and group in the
Mtrace2 Request. Mtrace2 Request.
skipping to change at page 15, line 42 skipping to change at page 15, line 42
| | | |
. Total number of packets for this source-group pair . . Total number of packets for this source-group pair .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtg Protocol | Multicast Rtg Protocol | | Rtg Protocol | Multicast Rtg Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ 2 |S|Src Prefix Len |Forwarding Code| | MBZ 2 |S|Src Prefix Len |Forwarding Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ: 8 bits MBZ: 8 bits
This field must be zeroed on transmission and ignored on This field MUST be zeroed on transmission and ignored on
reception. reception.
Query Arrival Time: 32 bits Query Arrival Time: 32 bits
Same definition as in IPv4. Same definition as in IPv4.
Incoming Interface ID: 32 bits Incoming Interface ID: 32 bits
This field specifies the interface ID on which packets from the This field specifies the interface ID on which packets from the
source or RP are expected to arrive, or 0 if unknown. This ID source or RP are expected to arrive, or 0 if unknown. This ID
should be the value taken from InterfaceIndex of the IF-MIB [10] should be the value taken from InterfaceIndex of the IF-MIB [10]
for this interface. for this interface.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
the same value as ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] the same value as ipMcastRoutePkts from the IPMROUTE-STD-MIB [11]
for this forwarding entry. for this forwarding entry.
Rtg Protocol: 16 bits Rtg Protocol: 16 bits
Same definition as in IPv4. Same definition as in IPv4.
Multicast Rtg Protocol: 16 bits Multicast Rtg Protocol: 16 bits
Same definition as in IPv4. Same definition as in IPv4.
MBZ 2: 15 bits MBZ 2: 15 bits
This field must be zeroed on transmission and ignored on This field MUST be zeroed on transmission and ignored on
reception. reception.
S: 1 bit S: 1 bit
Same definition as in IPv4, except the Src Prefix Len field is Same definition as in IPv4, except the Src Prefix Len field is
used to mask the source address. used to mask the source address.
Src Prefix Len: 8 bits Src Prefix Len: 8 bits
This field contains the prefix length this router has for the This field contains the prefix length this router has for the
source. If the router is forwarding solely on group state, this source. If the router is forwarding solely on group state, this
field is set to 255 (0xff). field is set to 255 (0xff).
skipping to change at page 17, line 41 skipping to change at page 17, line 41
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ | | Type | Length | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Augmented Response Type | Value .... | | Augmented Response Type | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ: 8 bits MBZ: 8 bits
This field must be zeroed on transmission and ignored on This field MUST be zeroed on transmission and ignored on
reception. reception.
Augmented Response Type: 16 bits Augmented Response Type: 16 bits
This field specifies the type of various responses from a This field specifies the type of various responses from a
multicast router that might need to communicate back to the multicast router that might need to communicate back to the
Mtrace2 client as well as the multicast routers on the traced Mtrace2 client as well as the multicast routers on the traced
path. path.
The Augmented Response Type is defined as follows: The Augmented Response Type is defined as follows:
skipping to change at page 19, line 6 skipping to change at page 19, line 6
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ |T| | Type | Length | MBZ |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Query Type | Value .... | | Extended Query Type | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ: 7 bits MBZ: 7 bits
This field must be zeroed on transmission and ignored on This field MUST be zeroed on transmission and ignored on
reception. reception.
T-bit (Transitive Attribute): 1 bit T-bit (Transitive Attribute): 1 bit
If the TLV type is unrecognized by the receiving router, then this If the TLV type is unrecognized by the receiving router, then this
TLV is either discarded or forwarded along with the Query, TLV is either discarded or forwarded along with the Query,
depending on the value of this bit. If this bit is set, then the depending on the value of this bit. If this bit is set, then the
router MUST forward this TLV. If this bit is clear, the router router MUST forward this TLV. If this bit is clear, the router
MUST send an Mtrace2 Reply with an UNKNOWN_QUERY error. MUST send an Mtrace2 Reply with an UNKNOWN_QUERY error.
Extended Query Type: 16 bits Extended Query Type: 16 bits
skipping to change at page 20, line 26 skipping to change at page 20, line 26
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
a cache of previously processed queries keyed by the Mtrace2 Client a cache of previously processed queries keyed by the Mtrace2 Client
Address and Query ID pair. The duration of the cached entries is Address and Query ID pair. The duration of the cached entries is
implementation specific. Duplicate Request messages MUST NOT be implementation specific. Duplicate Request messages MUST NOT be
ignored in this manner. ignored in this manner.
4.1.2. Query Normal Processing 4.1.2. Query Normal Processing
When a router receives an Mtrace2 Query and it determines that it is When a router receives an Mtrace2 Query and it determines that it is
the proper LHR, it turns the Query to a Request by changing the TLV the proper LHR/RP, it turns the Query to a Request by changing the
type from 0x01 to 0x02, and performs the steps listed in Section 4.2. TLV type from 0x01 to 0x02, and performs the steps listed in
Section 4.2.
4.2. Receiving Mtrace2 Request 4.2. Receiving Mtrace2 Request
An Mtrace2 Request is an Mtrace2 message that uses TLV type of 0x02. An Mtrace2 Request is an Mtrace2 message that uses TLV type of 0x02.
With the exception of the LHR, whose Request was just converted from With the exception of the LHR, whose Request was just converted from
a Query, each Request received by a router should have at least one a Query, each Request received by a router should have at least one
Standard Response Block filled in. Standard Response Block filled in.
4.2.1. Request Packet Verification 4.2.1. Request Packet Verification
If the Mtrace2 Request does not come from an adjacent router, or if If the Mtrace2 Request does not come from an adjacent router, or if
the Request is not addressed to this router, or if the Request is the Request is not addressed to this router, or if the Request is
addressed to a multicast group which is not a link-scoped group (i.e. addressed to a multicast group which is not a link-scoped group (i.e.
224/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be silently 224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be silently
ignored. GTSM [12] SHOULD be used by the router to determine whether ignored. GTSM [12] SHOULD be used by the router to determine whether
the router is adjacent or not. the router is adjacent or not.
If the sum of the number of the Standard Response Blocks in the If the sum of the number of the Standard Response Blocks in the
received Mtrace2 Request and the value of the Augmented Response Type received Mtrace2 Request and the value of the Augmented Response Type
of 0x01, if any, is equal or more than the # Hops in the Mtrace2 of 0x01, if any, is equal or more than the # Hops in the Mtrace2
Request, it MUST be silently ignored. Request, it MUST be silently ignored.
4.2.2. Request Normal Processing 4.2.2. Request Normal Processing
When a router receives an Mtrace2 Request message, it performs the When a router receives an Mtrace2 Request message, it performs the
following steps. Note that it is possible to have multiple following steps. Note that it is possible to have multiple
situations covered by the Forwarding Codes. The first one situations covered by the Forwarding Codes. The first one
encountered is the one that is reported, i.e. all "note Forwarding encountered is the one that is reported, i.e. all "note Forwarding
Code N" should be interpreted as "if Forwarding Code is not already Code N" should be interpreted as "if Forwarding Code is not already
set, set Forwarding Code to N". set, set Forwarding Code to N". Note that in the steps described
below the "Outgoing Interface" is the one on which the Mtrace2
Request message arrives.
1. Prepare a Standard Response Block to be appended to the packet 1. Prepare a Standard Response Block to be appended to the packet,
and fill in the Query Arrival Time, Outgoing Interface Address setting all fields to an initial default value of zero.
(for IPv4) or Outgoing Interface ID (for IPv6), Output Packet
Count, and Fwd TTL (for IPv4). Note that the Outgoing Interface
is the one on which the Mtrace2 Request message arrives.
2. Attempt to determine the forwarding information for the 2. If Mtrace2 is administratively prohibited, note the Forwarding
Code of ADMIN_PROHIB and skip to step 4.
3. In the Standard Response Block, fill in the Query Arrival Time,
Outgoing Interface Address (for IPv4) or Outgoing Interface ID
(for IPv6), Output Packet Count, and Fwd TTL (for IPv4).
4. Attempt to determine the forwarding information for the
specified source and group, using the same mechanisms as would specified source and group, using the same mechanisms as would
be used when a packet is received from the source destined for be used when a packet is received from the source destined for
the group. A state need not be instantiated, it can be a the group. A state need not be instantiated, it can be a
"phantom" state created only for the purpose of the trace, such "phantom" state created only for the purpose of the trace, such
as "dry-run." as "dry-run."
If using a shared-tree protocol and there is no source-specific If using a shared-tree protocol and there is no source-specific
state, or if no source-specific information is desired (i.e., state, or if no source-specific information is desired (i.e.,
all 1's for IPv4 or unspecified address (::) for IPv6), group all 1's for IPv4 or unspecified address (::) for IPv6), group
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 5. 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 (or Incoming Interface ID 6. If a Forwarding Code of ADMIN_PROHIB has been set, skip to step
and Local Address for IPv6), Upstream Router Address (or Remote 7. Otherwise, fill in the Incoming Interface Address (or
Address for IPv6), Input Packet Count, Total Number of Packets, Incoming Interface ID and Local Address for IPv6), Upstream
Routing Protocol, S, and Src Mask (or Src Prefix Len for IPv6) Router Address (or Remote Address for IPv6), Input Packet Count,
using the forwarding information determined by the step 2. Total Number of Packets, Routing Protocol, S, and Src Mask (or
Src Prefix Len for IPv6) using the forwarding information
5. If Mtrace2 is administratively prohibited, note the Forwarding determined in step 4.
Code of ADMIN_PROHIB. If Mtrace2 is administratively prohibited
and any of the fields as filled in the step 4 are considered
private information, zero out the applicable fields.
6. If the Outgoing interface is not enabled for multicast, note 7. 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 8. 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 for a non-source-specific 9. If this router is the RP for the group for a non-source-specific
query, note a Forwarding Code of REACHED_RP. The router will query, note a Forwarding Code of REACHED_RP. The router will
send an Mtrace2 Reply and terminate the trace. send an Mtrace2 Reply and terminate the trace.
9. If this router is directly connected to the specified source or 10. If this router is directly connected to the specified source or
source network on the Incoming interface, it sets the Upstream source network on the Incoming interface, it sets the Upstream
Router Address (for IPv4) or the Remote Address (for IPv6) of Router Address (for IPv4) or the Remote Address (for IPv6) of
the response block to zero. The router will send an Mtrace2 the response block to zero. The router will send an Mtrace2
Reply and terminate the trace. Reply and terminate the trace.
10. If this router has sent a prune upstream which applies to the 11. 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 a 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 a 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 a Forwarding Code of NOT_FORWARDING.
11. If this router is a gateway (e.g., a NAT or firewall) that hides 12. 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 a Forwarding Code of REACHED_GW. The router continues the
processing as described in Section 4.5. processing as described in Section 4.5.
12. If the total number of the Standard Response Blocks, including 13. 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.
4.3.1. Destination Address 4.3.1. Destination Address
If the upstream router for the Mtrace2 Request is known for this If the upstream router for the Mtrace2 Request is known for this
request, the Mtrace2 Request is sent to that router. If the Incoming request, the Mtrace2 Request is sent to that router. If the Incoming
interface is known but the upstream router is not, the Mtrace2 interface is known but the upstream router is not, the Mtrace2
Request is sent to an appropriate multicast address on the Incoming Request is sent to an appropriate multicast address on the Incoming
interface. The multicast address SHOULD depend on the multicast interface. The multicast address SHOULD depend on the multicast
routing protocol in use, such as ALL-[protocol]-ROUTERS.MCAST.NET. routing protocol in use, such as ALL-[protocol]-ROUTERS.MCAST.NET.
It MUST be a link-scoped group (i.e. 224/24 for IPv4, FF02::/16 for It MUST be a link-scoped group (i.e. 224.0.0.0/24 for IPv4, FF02::/16
IPv6), and MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and for IPv6), and MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4
All Nodes Address (FF02::1) for IPv6. It MAY also be ALL- and All Nodes Address (FF02::1) for IPv6. It MAY also be ALL-
ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address
(FF02::2) for IPv6 if the routing protocol in use does not define a (FF02::2) for IPv6 if the routing protocol in use does not define a
more appropriate multicast address. more appropriate multicast address.
4.3.2. Source Address 4.3.2. Source Address
An Mtrace2 Request should be sent with the address of the Incoming An Mtrace2 Request should be sent with the address of the Incoming
interface. However, if the Incoming interface is unnumbered, the interface. However, if the Incoming interface is unnumbered, the
router can use one of its numbered interface address as the source router can use one of its numbered interface addresses as the source
address. address.
4.3.3. Appending Standard Response Block 4.3.3. Appending Standard Response Block
An Mtrace2 Request MUST be sent upstream towards the source or the RP An Mtrace2 Request MUST be sent upstream towards the source or the RP
after appending a Standard Response Block to the end of the received after appending a Standard Response Block to the end of the received
Mtrace2 Request. The Standard Response Block includes the multicast Mtrace2 Request. The Standard Response Block includes the multicast
states and statistics information of the router described in states and statistics information of the router described in
Section 3.2.4. Section 3.2.4.
skipping to change at page 24, line 22 skipping to change at page 24, line 22
4.4.1. Destination Address 4.4.1. Destination Address
An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2 An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2
Client Address field in the Mtrace2 Request. Client Address field in the Mtrace2 Request.
4.4.2. Source Address 4.4.2. Source Address
An Mtrace2 Reply SHOULD be sent with the address of the router's An Mtrace2 Reply SHOULD be sent with the address of the router's
Outgoing interface. However, if the Outgoing interface address is Outgoing interface. However, if the Outgoing interface address is
unnumbered, the router can use one of its numbered interface address unnumbered, the router can use one of its numbered interface
as the source address. addresses as the source address.
4.4.3. Appending Standard Response Block 4.4.3. Appending Standard Response Block
An Mtrace2 Reply MUST be sent with the prepared Standard Response An Mtrace2 Reply MUST be sent with the prepared Standard Response
Block appended at the end of the received Mtrace2 Request except in Block appended at the end of the received Mtrace2 Request except in
the case of NO_SPACE forwarding code. the case of NO_SPACE forwarding code.
4.5. Proxying Mtrace2 Query 4.5. Proxying Mtrace2 Query
When a gateway (e.g., a NAT or firewall), which needs to block When a gateway (e.g., a NAT or firewall), which needs to block
unicast packets to the Mtrace2 client, or hide information between unicast packets to the Mtrace2 client, or hide information between
the gateway and the Mtrace2 client, receives an Mtrace2 Query from an the gateway and the Mtrace2 client, receives an Mtrace2 Query from an
adjacent host or Mtrace2 Request from an adjacent router, it appends adjacent host or Mtrace2 Request from an adjacent router, it appends
a Standard Response Block with REACHED_GW as the Forwarding Code, and a Standard Response Block with REACHED_GW as the Forwarding Code. It
turns the Query or Request as a Reply, and sends the Reply back to turns the Query or Request into a Reply, and sends the Reply back to
the client. the client.
At the same time, the gateway originates a new Mtrace2 Query message At the same time, the gateway originates a new Mtrace2 Query message
by copying the original Mtrace2 header (the Query or Request without by copying the original Mtrace2 header (the Query or Request without
any of the response blocks), and makes the changes as follows: any of the response blocks), and makes the changes as follows:
o sets the RPF interface's address as the Mtrace2 Client Address; o sets the RPF interface's address as the Mtrace2 Client Address;
o uses its own port number as the Client Port #; and, o uses its own port number as the Client Port #; and,
o decreases # Hops by the number of the Standard Response Block that o decreases # Hops by ((number of the Standard Response Blocks that
was just returned as a Reply. were just returned in a Reply) - 1). The "-1" in this expression
accounts for the additional Standard Response Block appended by
the gateway router.
The new Mtrace2 Query message is then sent to the upstream router or The new Mtrace2 Query message is then sent to the upstream router or
to an appropriate multicast address on the RPF interface. to an appropriate multicast address on the RPF interface.
When the gateway receives an Mtrace2 Reply whose Query ID matches the When the gateway receives an Mtrace2 Reply whose Query ID matches the
one in the original Mtrace2 header, it MUST relay the Mtrace2 Reply one in the original Mtrace2 header, it MUST relay the Mtrace2 Reply
back to the Mtrace2 client by replacing the Reply's header with the back to the Mtrace2 client by replacing the Reply's header with the
original Mtrace2 header. If the gateway does not receive the original Mtrace2 header. If the gateway does not receive the
corresponding Mtrace2 Reply within the [Mtrace Reply Timeout] period corresponding Mtrace2 Reply within the [Mtrace Reply Timeout] period
(see Section 5.8.4), then it silently discards the original Mtrace2 (see Section 5.8.4), then it silently discards the original Mtrace2
skipping to change at page 28, line 29 skipping to change at page 28, line 29
router. If desired, each of those neighbors could be probed to router. If desired, each of those neighbors could be probed to
determine the remainder of the path. Unfortunately, this heuristic determine the remainder of the path. Unfortunately, this heuristic
may end up with multiple paths, since there is no way of knowing what may end up with multiple paths, since there is no way of knowing what
the non-responding router's algorithm for choosing an upstream router the non-responding router's algorithm for choosing an upstream router
is. However, if all paths but one flow back towards the non- is. However, if all paths but one flow back towards the non-
responding router, it is possible to be sure that this is the correct responding router, it is possible to be sure that this is the correct
path. path.
6. Protocol-Specific Considerations 6. Protocol-Specific Considerations
This section describes the Mtrace2 behavior with the present of This section describes the Mtrace2 behavior with the presence of
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
skipping to change at page 31, line 9 skipping to change at page 31, line 9
7.5. Time Delay 7.5. Time Delay
If the routers have synchronized clocks, it is possible to estimate If the routers have synchronized clocks, it is possible to estimate
propagation and queuing delay from the differences between the propagation and queuing delay from the differences between the
timestamps at successive hops. However, this delay includes control timestamps at successive hops. However, this delay includes control
processing overhead, so is not necessarily indicative of the delay processing overhead, so is not necessarily indicative of the delay
that data traffic would experience. that data traffic would experience.
8. IANA Considerations 8. IANA Considerations
The following new assignments can only be made via a Standards Action The following new registries are to be created and maintained under
as specified in [4]. the "RFC Required" registry policy as specified in [4].
8.1. Forwarding Codes 8.1. "Mtrace2 Forwarding Codes" Registry
New Forwarding Codes must only be created by an RFC that modifies This is an integer in the range 0-255. Assignment of a Forwarding
this document's Section 3.2.4 and Section 3.2.5, fully describing the Code requires specification of a value and a name for the Forwarding
conditions under which the new Forwarding Code is used. The IANA may Code. Initial values for the forwarding codes are given in the table
act as a central repository so that there is a single place to look at the end of Section 3.2.4. Additional values (specific to IPv6)
up Forwarding Codes and the document in which they are defined. may also be specified at the end of Section 3.2.5. Any additions to
this registry are required to fully describe the conditions under
which the new Forwarding Code is used.
8.2. UDP Destination Port 8.2. "Mtrace2 TLV Types" registry
The IANA should allocate UDP destination port for Mtrace2 upon Assignment of a TLV Type requires specification of an integer value
publication of the first RFC. "Code" in the range 0-255 and a name ("Type"). Initial values for
the TLV Types are given in the table at the beginning of Section 3.2.
8.3. UDP Destination Port
The Mtrace2 UDP destination port is [TBD].
9. Security Considerations 9. Security Considerations
This section addresses some of the security considerations related to This section addresses some of the security considerations related to
Mtrace2. Mtrace2.
9.1. Addresses in Mtrace2 Header 9.1. Addresses in Mtrace2 Header
An Mtrace2 header includes three addresses, source address, multicast An Mtrace2 header includes three addresses, source address, multicast
address, and Mtrace2 client address. These addresses MUST be address, and Mtrace2 client address. These addresses MUST be
skipping to change at page 32, line 47 skipping to change at page 32, line 50
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 Kebler, Heidi Ou, Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, John
Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, Kristoff, Heidi Ou, Pekka Savola, Shinsuke Suzuki, Dave Thaler,
Stig Venaas, and Cao Wei. Achmad Husni Thamrin, 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.
 End of changes. 51 change blocks. 
106 lines changed or deleted 144 lines changed or added

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