draft-ietf-mboned-mtrace-v2-06.txt   draft-ietf-mboned-mtrace-v2-07.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track T. Jinmei Intended status: Standards Track T. Jinmei
Expires: July 27, 2010 ISC Expires: January 13, 2011 ISC
W. Fenner W. Fenner
Arastra, Inc. Arastra, Inc.
S. Casner S. Casner
Packet Design, Inc. Packet Design, Inc.
January 23, 2010 July 12, 2010
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-06 draft-ietf-mboned-mtrace-v2-07
Abstract Abstract
This document describes the IP multicast traceroute facility. Unlike This document describes the IP multicast traceroute facility. Unlike
unicast traceroute, multicast traceroute requires special unicast traceroute, multicast traceroute requires special
implementations on the part of routers. This specification describes implementations on the part of routers. This specification describes
the required functionality in multicast routers, as well as how the required functionality in multicast routers, as well as how
management applications can use the router functionality. management applications can use the router functionality.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . . 9 4.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . . 10
4.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . 10
5. Mtrace2 Query Header . . . . . . . . . . . . . . . . . . . . . 10 5. Mtrace2 Query Header . . . . . . . . . . . . . . . . . . . . . 11
5.1. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 10 5.1. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 10 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 11
5.3. Source Address . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Source Address . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Destination Address . . . . . . . . . . . . . . . . . . . 11 5.4. Destination Address . . . . . . . . . . . . . . . . . . . 12
5.5. Query ID: 16 bits . . . . . . . . . . . . . . . . . . . . 11 5.5. Query ID: 16 bits . . . . . . . . . . . . . . . . . . . . 12
5.6. Client Port # . . . . . . . . . . . . . . . . . . . . . . 11 5.6. Client Port # . . . . . . . . . . . . . . . . . . . . . . 12
6. IPv4 Mtrace2 Standard Response Block . . . . . . . . . . . . . 12 6. IPv4 Mtrace2 Standard Response Block . . . . . . . . . . . . . 13
6.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 12 6.1. MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Incoming Interface Address: 32 bits . . . . . . . . . . . 13 6.2. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 13
6.3. Outgoing Interface Address: 32 bits . . . . . . . . . . . 13 6.3. Incoming Interface Address: 32 bits . . . . . . . . . . . 14
6.4. Previous-Hop Router Address: 32 bits . . . . . . . . . . . 13 6.4. Outgoing Interface Address: 32 bits . . . . . . . . . . . 14
6.5. Input packet count on incoming interface: 64 bits . . . . 13 6.5. Previous-Hop Router Address: 32 bits . . . . . . . . . . . 14
6.6. Output packet count on incoming interface: 64 bits . . . . 13 6.6. Input packet count on incoming interface: 64 bits . . . . 14
6.7. Total number of packets for this source-group pair: 64 6.7. Output packet count on incoming interface: 64 bits . . . . 14
bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.8. Total number of packets for this source-group pair: 64
6.8. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 14 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.9. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 14 6.9. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 15
6.10. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 14 6.10. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 15
6.11. MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 14 6.11. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 15
6.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.13. Src Mask: 7 bits . . . . . . . . . . . . . . . . . . . . . 14 6.13. Src Mask: 7 bits . . . . . . . . . . . . . . . . . . . . . 15
6.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 14 6.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 16
7. IPv6 Mtrace2 Standard Response Block . . . . . . . . . . . . . 17 7. IPv6 Mtrace2 Standard Response Block . . . . . . . . . . . . . 18
7.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 17 7.1. MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 17 7.2. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 19
7.3. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 18 7.3. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 19
7.4. Local Address . . . . . . . . . . . . . . . . . . . . . . 18 7.4. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 19
7.5. Remote Address . . . . . . . . . . . . . . . . . . . . . . 18 7.5. Local Address . . . . . . . . . . . . . . . . . . . . . . 19
7.6. Input packet count on incoming interface . . . . . . . . . 18 7.6. Remote Address . . . . . . . . . . . . . . . . . . . . . . 19
7.7. Output packet count on incoming interface . . . . . . . . 18 7.7. Input packet count on incoming interface . . . . . . . . . 19
7.8. Total number of packets for this source-group pair . . . . 18 7.8. Output packet count on incoming interface . . . . . . . . 20
7.9. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 19 7.9. Total number of packets for this source-group pair . . . . 20
7.10. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 19 7.10. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 20
7.11. MBZ: 15 bits . . . . . . . . . . . . . . . . . . . . . . . 19 7.11. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 20
7.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 19 7.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 20
7.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 19 7.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 20
8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 20 8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 21
9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 21 9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 22
9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 21 9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 22
9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 21 9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 22
9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 21 9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 22
9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 22 9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 23
9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 22 9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 23
9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 24 9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 25
9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 24 9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 25
9.4.1. Destination Address . . . . . . . . . . . . . . . . . 24 9.4.1. Destination Address . . . . . . . . . . . . . . . . . 25
9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 24 9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 25
9.5. Proxying Mtrace2 Queries . . . . . . . . . . . . . . . . . 24 9.5. Proxying Mtrace2 Queries . . . . . . . . . . . . . . . . . 25
9.6. Hiding Information . . . . . . . . . . . . . . . . . . . . 25 9.6. Hiding Information . . . . . . . . . . . . . . . . . . . . 26
10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 26 10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Sending Mtrace2 Queries . . . . . . . . . . . . . . . . . 26 10.1. Sending Mtrace2 Queries . . . . . . . . . . . . . . . . . 27
10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 26 10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 27
10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 26 10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 27
10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 26 10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 27
10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 27 10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 28
10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 27 10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 28
10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27 10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 28
10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 27 10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 28
10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 27 10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 28
10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 27 10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 28
10.7.4. Traceroute shorter than requested . . . . . . . . . . 28 10.7.4. Traceroute shorter than requested . . . . . . . . . . 28
10.8. Continuing after an error . . . . . . . . . . . . . . . . 28 10.8. Continuing after an error . . . . . . . . . . . . . . . . 29
11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 29 11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 30
11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 29 11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 30
11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 29 11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 30
11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31 12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 31 12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 32
12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31 12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32
12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31 12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32
12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 32 12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 33
12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 32 12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 33
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 33 13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 34
13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 33 13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 34
14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 14. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 34 14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 35
14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 34 14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 35
14.3. Limiting Query/Request Rates . . . . . . . . . . . . . . . 34 14.3. Limiting Query/Request Rates . . . . . . . . . . . . . . . 35
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The unicast "traceroute" program allows the tracing of a path from This document specifies the multicast traceroute facility named
one machine to another. The key mechanism for unicast traceroute is mtrace version 2 or mtrace2. Mtrace2 allows the tracing of an IP
the ICMP TTL exceeded message, which is specifically precluded as a multicast routing paths. Mtrace2 provides additional information
response to multicast packets. On the other hand, the multicast about packet rates and losses, or other diagnosis information. For
traceroute facility allows the tracing of an IP multicast routing instance, mtrace2 is used for the following purposes.
paths. In this document, we specify the multicast "traceroute"
facility to be implemented in multicast routers and accessed by
diagnostic programs. The multicast traceroute described in this
document named as mtrace version 2 or mtrace2 provides additional
information about packet rates and losses that the unicast traceroute
cannot, and generally requires fewer packets to be sent.
o To be able to trace the path that a packet would take from some o To trace the path that a packet would take from some source to
source to some destination. some destination.
o To be able to isolate packet loss problems (e.g., congestion). o To isolate packet loss problems (e.g., congestion).
o To be able to isolate configuration problems (e.g., TTL o To isolate configuration problems (e.g., TTL threshold).
threshold).
o To minimize packets sent (e.g. no flooding, no implosion). Mtrace2 consists of the client and router programs. The mtrace2
client program is invoked from somewhere in the multicast tree, on a
host, router, or proxy such as IGMP/MLD proxy Section 9.5. The node
invoking the program is called the mtrace2 client.
This document supports both IPv4 and IPv6 multicast traceroute The mtrace2 client program creates the mtrace2 Query message, which
includes a source and multicast address specified by the client, and
forwards the message to its neighbor router or proxy. This initiates
a trace of a multicast routing path from the client toward the
specified source, or if no source address is specified, toward a core
router. In the case of PIM-SM [6], the core router is an RP
maintaining the specified multicast address.
When a router or proxy receives an mtrace2 Query message and has the
corresponding routing state regarding the source and multicast
addresses specified in the Query, the router or proxy invokes the
mtrace2 router program. The mtrace2 router program creates an
mtrace2 Request message corresponding to the query and forwards the
Request toward the specified source or the core router.
When a first-hop router or proxy (a single hop from the source
specified in the request) or the core router receives an mtrace2
Query or Request message, the router or proxy invokes the mtrace2
router program. The mtrace2 router program creates an mtrace2
Response message. The Response message is forwarded to the mtrace2
client, thus completing the mtrace2 request.
The mtrace2 client program waits for the mtrace2 Response message and
displays the results. When an mtrace2 Response message does not come
due to network congestion, a broken router (see Section 10.6) or a
non-responding router (see Section 10.8), the mtrace2 client program
can resend an mtrace2 Query with the lower hop count and repeat the
process until it receives an mtrace2 Response message.
The mtrace2 client should also be aware that the mtrace2 Query may
follow the control path on the routers. It happens when the last-hop
or intermediate router's control plane and forwarding plane are not
synchronized. In this case, mtrace2 Requests will be forwarded
toward the specified source or the core router because the router
does not have any forwarding state for the query.
The mtrace2 supports both IPv4 and IPv6 multicast traceroute
facility. The protocol design, concept, and program behavior are facility. The protocol design, concept, and program behavior are
same between IPv4 and IPv6 mtrace2. While the original IPv4 same between IPv4 and IPv6 mtrace2. While the original IPv4
multicast traceroute, mtrace, the query and response messages are multicast traceroute, mtrace, the query and response messages are
implemented as IGMP messages [12], all mtrace2 messages are carried implemented as IGMP messages [10], all mtrace2 messages are carried
on UDP. The packet formats of IPv4 and IPv6 mtrace2 are different on UDP. The packet formats of IPv4 and IPv6 mtrace2 are different
because of the different address families, but the syntax is similar. because of the different address families, but the syntax is similar.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1]. this document are to be interpreted as described in RFC 2119 [1].
Since multicast traceroutes flow in the opposite direction to the Since multicast traceroutes flow in the opposite direction to the
skipping to change at page 7, line 30 skipping to change at page 8, line 30
The interface on which traffic is forwarded from the specified source The interface on which traffic is forwarded from the specified source
and group toward the destination. It is the interface on which the and group toward the destination. It is the interface on which the
multicast traceroute Request was received. multicast traceroute Request was received.
Previous-hop router: Previous-hop router:
The router that is on the link attached to the Incoming Interface and The router that is on the link attached to the Incoming Interface and
is responsible for forwarding traffic for the specified source and is responsible for forwarding traffic for the specified source and
group. group.
Group state: Group state:
It is the state in which a shared-tree protocol (e.g., PIM-SM [8]) It is the state in which a shared-tree protocol (e.g., PIM-SM [6])
running on a router chooses the previous-hop router toward the core running on a router chooses the previous-hop router toward the core
router or Rendezvous Point (RP) as its parent router. In this state, router or Rendezvous Point (RP) as its parent router. In this state,
source-specific state is not available for the corresponding source-specific state is not available for the corresponding
multicast address on the router. multicast address on the router.
Source-specific state: Source-specific state:
It is the state in which a routing protocol running on a router It is the state in which a routing protocol running on a router
chooses the path that would be followed for a source-specific join. chooses the path that would be followed for a source-specific join.
ALL-[protocol]-ROUTERS.MCAST.NET: ALL-[protocol]-ROUTERS.MCAST.NET:
skipping to change at page 8, line 17 skipping to change at page 9, line 17
Given a multicast distribution tree, tracing from a source to a Given a multicast distribution tree, tracing from a source to a
multicast destination is hard, since you don't know down which branch multicast destination is hard, since you don't know down which branch
of the multicast tree the destination lies. This means that you have of the multicast tree the destination lies. This means that you have
to flood the whole tree to find the path from one source to one to flood the whole tree to find the path from one source to one
destination. However, walking up the tree from destination to source destination. However, walking up the tree from destination to source
is easy, as most existing multicast routing protocols know the is easy, as most existing multicast routing protocols know the
previous hop for each source. Tracing from destination to source can previous hop for each source. Tracing from destination to source can
involve only routers on the direct path. involve only routers on the direct path.
The party requesting the traceroute sends a traceroute Query packet The party requesting the traceroute sends a traceroute Query packet
to the last-hop multicast router for the given destination. The to the last-hop multicast router for the given multicast address.
last-hop router turns the Query into a Request packet by adding a The last-hop router turns the Query into a Request packet by adding a
response data block containing its interface addresses and packet response data block containing its interface addresses and packet
statistics, and then forwards the Request packet via unicast to the statistics, and then forwards the Request packet via unicast to the
router that it believes is the proper previous hop for the given router that it believes is the proper previous hop for the given
source and group. Each hop adds its response data to the end of the source and group. Each hop adds its response data to the end of the
Request packet, then unicast forwards it to the previous hop. The Request packet, then unicast forwards it to the previous hop. The
first hop router (the router that believes that packets from the first-hop router (the router that believes that packets from the
source originate on one of its directly connected networks) changes source originate on one of its directly connected networks) changes
the packet type to indicate a Response packet and sends the completed the packet type to indicate a Response packet and sends the completed
response to the response destination address. The response may be response to the response destination address. The response may be
returned before reaching the first hop router if a fatal error returned before reaching the first-hop router if a fatal error
condition such as "no route" is encountered along the path. condition such as "no route" is encountered along the path.
Multicast traceroute uses any information available to it in the Multicast traceroute uses any information available to it in the
router to attempt to determine a previous hop to forward the trace router to attempt to determine a previous hop to forward the trace
towards. Multicast routing protocols vary in the type and amount of towards. Multicast routing protocols vary in the type and amount of
state they keep; multicast traceroute endeavors to work with all of state they keep; multicast traceroute endeavors to work with all of
them by using whatever is available. For example, if a PIM-SM router them by using whatever is available. For example, if a PIM-SM router
is on the (*,G) tree, it chooses the parent towards the RP as the is on the (*,G) tree, it chooses the parent towards the RP as the
previous hop. In these cases, no source/group-specific state is previous hop. In these cases, no source/group-specific state is
available, but the path may still be traced. available, but the path may still be traced.
skipping to change at page 9, line 33 skipping to change at page 10, line 33
Value (variable length) Value (variable length)
4.2. Defined TLVs 4.2. Defined TLVs
The following TLV Types are defined: The following TLV Types are defined:
Code Type Code Type
====== ====================================== ====== ======================================
1 Mtrace2 Query 1 Mtrace2 Query
2 Mtrace2 Response 2 Mtrace2 Request
3 Mtrace2 Standard Response Block 3 Mtrace2 Response
4 Mtrace2 Augmented Response Block 4 Mtrace2 Standard Response Block
5 Mtrace2 Augmented Response Block
An mtrace2 message MUST contain one Mtrace2 Query or Response. An An mtrace2 message MUST contain one Mtrace2 Query header. A
mtrace2 message MAY contain one or multiple Mtrace2 Standard and multicast router that sends an mtrace2 Request or Response message
Augmented Responses. A multicast router that sends mtrace2 request MAY add one mtrace2 Standard Response block to given mtrace2 message
MUST NOT contain multiple Mtrace2 Standard blocks but MAY contain but MUST NOT add multiple mtrace2 Standard Response blocks to it. A
multiple Augmented Response blocks. multicast router that adds one mtrace2 Standard Response block to
given mtrace2 message MAY append one or multiple Augmented Response
blocks.
The type field is defined to be "0x1" for mtrace2 queries and The type field is defined to be "0x1" and "0x2" for mtrace2 Queries
requests. The type field is changed to "0x2" when the packet is and Requests, respectively. The type field is changed to "0x3" when
completed and sent as a response from the first hop router to the the packet is completed and sent as a response from the first-hop
querier. Two codes are required so that multicast routers will not router to the querier.
attempt to process a completed response in those cases where the
initial query was issued from a router.
5. Mtrace2 Query Header 5. Mtrace2 Query Header
The mtrace2 message is carried as a UDP packet. The UDP source port The mtrace2 message is carried as a UDP packet. The UDP source port
is uniquely selected by the local host operating system. The UDP is uniquely selected by the local host operating system. The UDP
destination port is the IANA reserved mtrace2 port number (see destination port is the IANA reserved mtrace2 port number (see
Section 13). The UDP checksum MUST be valid in mtrace2 messages. Section 13). The UDP checksum MUST be valid in mtrace2 messages.
The mtrace2 message includes the common mtrace2 Query header as The mtrace2 message includes the common mtrace2 Query header as
follows. The header is only filled in by the originator of the follows. The header is only filled in by the originator of the
skipping to change at page 10, line 41 skipping to change at page 11, line 41
| Destination Address | | Destination Address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query ID | Client Port # | | Query ID | Client Port # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
5.1. # hops: 8 bits 5.1. # hops: 8 bits
This field specifies the maximum number of hops that the requester This field specifies the maximum number of hops that the mtrace2
wants to trace. If there is some error condition in the middle of client wants to trace. If there is some error condition in the
the path that keeps the mtrace2 request from reaching the first-hop middle of the path that keeps the mtrace2 request from reaching the
router, this field can be used to perform an expanding-ring search to first-hop router, this field can be used to perform an expanding-ring
trace the path to just before the problem. search to trace the path to just before the problem.
5.2. Multicast Address 5.2. Multicast Address
This field specifies the 32 bits length IPv4 or 128 bits length IPv6 This field specifies the 32 bits length IPv4 or 128 bits length IPv6
multicast address to be traced, or is filled with "all 1" in case of multicast address to be traced, or is filled with "all 1" in case of
IPv4 or with the unspecified address (::) in case of IPv6 if no IPv4 or with the unspecified address (::) in case of IPv6 if no
group-specific information is desired. Note that non-group-specific group-specific information is desired. Note that non-group-specific
mtrace2 MUST specify source address. mtrace2 MUST specify source address.
5.3. Source Address 5.3. Source Address
This field specifies the 32 bits length IPv4 or 128 bits length IPv6 This field specifies the 32 bits length IPv4 or 128 bits length IPv6
address of the multicast source for the path being traced, or is address of the multicast source for the path being traced, or is
filled with "all 1" in case of IPv4 or with the unspecified address filled with "all 1" in case of IPv4 or with the unspecified address
(::) in case of IPv6 if no source-specific information is desired. (::) in case of IPv6 if no source-specific information such as a
Note that non-source-specific traceroutes may not be possible with trace for RPT in PIM-SM is desired. Note that non-source-specific
certain multicast routing protocols. traceroutes may not be possible with certain multicast routing
protocols.
5.4. Destination Address 5.4. Destination Address
This field specifies the 32 bits length IPv4 or 128 bits length IPv6 This field specifies the 32 bits length IPv4 or 128 bits length IPv6
address of the multicast receiver for the path being traced. The address of the mtrace2 client. The trace starts at this destination
trace starts at this destination and proceeds toward the traffic and proceeds toward the traffic source.
source.
5.5. Query ID: 16 bits 5.5. Query ID: 16 bits
This field is used as a unique identifier for this traceroute request This field is used as a unique identifier for this traceroute request
so that duplicate or delayed responses may be detected and to so that duplicate or delayed responses may be detected.
minimize collisions when a multicast response address is used.
5.6. Client Port # 5.6. Client Port #
Mtrace2 response is sent back to the address specified in a Mtrace2 response is sent back to the address specified in a
Destination Address field. This field specifies the UDP port number Destination Address field. This field specifies the UDP port number
the router will send Mtrace2 Response. This client port number MUST the router will send Mtrace2 Response. This client port number MUST
NOT be changed by any router. NOT be changed by any router.
6. IPv4 Mtrace2 Standard Response Block 6. IPv4 Mtrace2 Standard Response Block
Each intermediate IPv4 router in a trace path appends "response data Each intermediate IPv4 router in a trace path appends "response data
block" to the forwarded trace packet. The standard response data block" to the forwarded trace packet. The standard response data
block looks as follows. block looks as follows.
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
+-+-+-+-+-+-+-+-+
| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Arrival Time | | Query Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address | | Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address | | Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous-Hop Router Address | | Previous-Hop Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 12, line 39 skipping to change at page 13, 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1. Query Arrival Time: 32 bits 6.1. MBZ: 8 bit
Must be zeroed on transmission and ignored on reception.
6.2. 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 traceroute request packet at this router. The arrival time of the traceroute request packet at this router. The
32-bit form of an NTP timestamp consists of the middle 32 bits of 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 of the integer part and full 64-bit form; that is, the low 16 bits of the integer part and
the high 16 bits of the fractional part. 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
timestamp: timestamp:
query_arrival_time query_arrival_time
= (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625) = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625)
The constant 32384 is the number of seconds from Jan 1, 1900 to Jan The constant 32384 is the number of seconds from Jan 1, 1900 to Jan
1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a
reduction of ((tv.tv_usec / 100000000) << 16). reduction of ((tv.tv_usec / 100000000) << 16).
6.2. Incoming Interface Address: 32 bits 6.3. Incoming Interface Address: 32 bits
This field specifies the address of the interface on which packets This field specifies the address of the interface on which packets
from this source and group are expected to arrive, or 0 if unknown or from this source and group are expected to arrive, or 0 if unknown or
unnumbered. unnumbered.
6.3. Outgoing Interface Address: 32 bits 6.4. Outgoing Interface Address: 32 bits
This field specifies the address of the interface on which packets This field specifies the address of the interface on which packets
from this source and group flow to the specified destination, or 0 if from this source and group flow to the specified destination, or 0 if
unknown or unnumbered. unknown or unnumbered.
6.4. Previous-Hop Router Address: 32 bits 6.5. Previous-Hop Router Address: 32 bits
This field specifies the router from which this router expects This field specifies the router from which this router expects
packets from this source. This may be a multicast group (e.g. ALL- packets from this source. This may be a multicast group (e.g. ALL-
[protocol]-ROUTERS.MCAST.NET) if the previous hop is not known [protocol]-ROUTERS.MCAST.NET) if the previous hop is not known
because of the workings of the multicast routing protocol. However, because of the workings of the multicast routing protocol. However,
it should be 0 if the incoming interface address is unknown or it should be 0 if the incoming interface address is unknown or
unnumbered. unnumbered.
6.5. Input packet count on incoming interface: 64 bits 6.6. Input packet count on incoming interface: 64 bits
This field contains the number of multicast packets received for all This field contains the number of multicast packets received for all
groups and sources on the incoming interface, or "all 1" if no count groups and sources on the incoming interface, or "all 1" if no count
can be reported. This counter may have the same value as can be reported. This counter may have the same value as
ifHCInMulticastPkts from the IF-MIB [14] for this interface. ifHCInMulticastPkts from the IF-MIB [12] for this interface.
6.6. Output packet count on incoming interface: 64 bits 6.7. Output packet count on incoming interface: 64 bits
This field contains the number of multicast packets that have been This field contains the number of multicast packets that have been
transmitted or queued for transmission for all groups and sources on transmitted or queued for transmission for all groups and sources on
the outgoing interface, or "all 1" if no count can be reported. This the outgoing interface, or "all 1" if no count can be reported. This
counter may have the same value as ifHCOutMulticastPkts from the IF- counter may have the same value as ifHCOutMulticastPkts from the IF-
MIB for this interface. MIB for this interface.
6.7. Total number of packets for this source-group pair: 64 bits 6.8. 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 this router to the specified group, or "all 1" if no forwarded by this router to the specified group, or "all 1" if no
count can be reported. If the S bit is set, the count is for the count can be reported. If the S bit is set, the count is for the
source network, as specified by the Src Mask field. If the S bit is source network, as specified by the Src Mask field. If the S bit is
set and the Src Mask field is 63, indicating no source-specific set and the Src Mask field is 63, indicating no source-specific
state, the count is for all sources sending to this group. This state, the count is for all sources sending to this group. This
counter should have the same value as ipMcastRoutePkts from the counter should have the same value as ipMcastRoutePkts from the
IPMROUTE-STD-MIB [15] for this forwarding entry. IPMROUTE-STD-MIB [13] for this forwarding entry.
6.8. Rtg Protocol: 16 bits 6.9. Rtg Protocol: 16 bits
This field describes the routing protocol used to decide an RPF This field describes the routing protocol used to decide an RPF
interface for the requested source. This value should have the same interface for the requested source. This value should have the same
value as ipMcastRouteRtProtocol from the IPMROUTE-STD-MIB [15] for value as ipMcastRouteRtProtocol from the IPMROUTE-STD-MIB [13] for
this entry. If the router does not able to obtain this value, "all this entry. If the router does not able to obtain this value, "all
0" must be specified. 0" must be specified.
6.9. Multicast Rtg Protocol: 16 bits 6.10. Multicast Rtg Protocol: 16 bits
This field describes the multicast routing protocol in use between This field describes the multicast routing protocol in use between
this router and the previous-hop router. This value should have the this router and the previous-hop router. This value should have the
same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [15] for same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [13] for
this entry. If the router does not able to obtain this value, "all this entry. If the router does not able to obtain this value, "all
0" must be specified. 0" must be specified.
6.10. Fwd TTL: 8 bits 6.11. Fwd TTL: 8 bits
This field contains the TTL that a packet is required to have before This field contains the TTL that a packet is required to have before
it will be forwarded over the outgoing interface. it will be forwarded over the outgoing interface.
6.11. MBZ: 8 bit
Must be zeroed on transmission and ignored on reception.
6.12. S: 1 bit 6.12. S: 1 bit
This S bit indicates that the packet count for the source-group pair This S bit indicates that the packet count for the source-group pair
is for the source network, as determined by masking the source is for the source network, as determined by masking the source
address with the Src Mask field. address with the Src Mask field.
6.13. Src Mask: 7 bits 6.13. Src Mask: 7 bits
This field contains the number of 1's in the netmask this router has This field contains the number of 1's in the netmask this router has
for the source (i.e. a value of 24 means the netmask is 0xffffff00). for the source (i.e. a value of 24 means the netmask is 0xffffff00).
skipping to change at page 16, line 16 skipping to change at page 17, line 24
mtrace2 requests. mtrace2 requests.
0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited. 0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited.
Note that if a router discovers there is not enough room in a packet Note that if a router discovers there is not enough room in a packet
to insert its response, it puts the NO_SPACE error code in the to insert its response, it puts the NO_SPACE error code in the
previous router's Forwarding Code field, overwriting any error the previous router's Forwarding Code field, overwriting any error the
previous router placed there. After the router sends the response to previous router placed there. After the router sends the response to
the Destination Address in the header, the router continues the the Destination Address in the header, the router continues the
mtrace2 query by sending an mtrace2 request containing the same mtrace2 query by sending an mtrace2 request containing the same
mtrace2 query header. Section 9.3 and Section 10.8 include the mtrace2 Query header. Section 9.3 and Section 10.8 include the
details. details.
The 0x80 bit of the Forwarding Code is used to indicate a fatal The 0x80 bit of the Forwarding Code is used to indicate a fatal
error. A fatal error is one where the router may know the previous error. A fatal error is one where the router may know the previous
hop but cannot forward the message to it. hop but cannot forward the message to it.
7. IPv6 Mtrace2 Standard Response Block 7. IPv6 Mtrace2 Standard Response Block
Each intermediate IPv6 router in a trace path appends "response data Each intermediate IPv6 router in a trace path appends "response data
block" to the forwarded trace packet. The standard response data block" to the forwarded trace packet. The standard response data
block looks as follows. block looks as follows.
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
+-+-+-+-+-+-+-+-+
| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Arrival Time | | Query Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface ID | | Incoming Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface ID | | Outgoing Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
* Local Address * * Local Address *
| | | |
skipping to change at page 17, line 45 skipping to change at page 18, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. 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 |S|Src Prefix Len |Forwarding Code| | MBZ |S|Src Prefix Len |Forwarding Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.1. Query Arrival Time: 32 bits 7.1. MBZ: 8 bit
Same definition described in Section 6.1 Must be zeroed on transmission and ignored on reception.
7.2. Incoming Interface ID: 32 bits 7.2. Query Arrival Time: 32 bits
Same definition described in Section 6.2
7.3. Incoming Interface ID: 32 bits
This field specifies the interface ID on which packets from this This field specifies the interface ID on which packets from this
source and group are expected to arrive, or 0 if unknown. This ID source and group are expected to arrive, or 0 if unknown. This ID
should be the value taken from InterfaceIndex of the IF-MIB [14] for should be the value taken from InterfaceIndex of the IF-MIB [12] for
this interface. This field is carried in network byte order. this interface. This field is carried in network byte order.
7.3. Outgoing Interface ID: 32 bits 7.4. Outgoing Interface ID: 32 bits
This field specifies the interface ID on which packets from this This field specifies the interface ID on which packets from this
source and group flow to the specified destination, or 0 if unknown. source and group flow to the specified destination, or 0 if unknown.
This ID should be the value taken from InterfaceIndex of the IF-MIB This ID should be the value taken from InterfaceIndex of the IF-MIB
for this interface. This field is carried in network byte order. for this interface. This field is carried in network byte order.
7.4. Local Address 7.5. Local Address
This field specifies a global IPv6 address that uniquely identifies This field specifies a global IPv6 address that uniquely identifies
the router. A unique local unicast address [13] SHOULD NOT be used the router. A unique local unicast address [11] SHOULD NOT be used
unless the router is only assigned link-local and unique local unless the router is only assigned link-local and unique local
addresses. If the router is only assigned link-local addresses, its addresses. If the router is only assigned link-local addresses, its
link-local address can be specified in this field. link-local address can be specified in this field.
7.5. Remote Address 7.6. Remote Address
This field specifies the address of the previous-hop router, which, This field specifies the address of the previous-hop router, which,
in most cases, is a link-local unicast address for the queried source in most cases, is a link-local unicast address for the queried source
and destination addresses. and destination addresses.
Although a link-local address does not have enough information to Although a link-local address does not have enough information to
identify a node, it is possible to detect the previous-hop router identify a node, it is possible to detect the previous-hop router
with the assistance of Incoming Interface ID and the current router with the assistance of Incoming Interface ID and the current router
address (i.e., Local Address). address (i.e., Local Address).
This may be a multicast group (e.g., ALL-[protocol]- This may be a multicast group (e.g., ALL-[protocol]-
ROUTERS.MCAST.NET) if the previous hop is not known because of the ROUTERS.MCAST.NET) if the previous hop is not known because of the
workings of the multicast routing protocol. However, it should be workings of the multicast routing protocol. However, it should be
the unspecified address (::) if the incoming interface address is the unspecified address (::) if the incoming interface address is
unknown. unknown.
7.6. Input packet count on incoming interface 7.7. Input packet count on incoming interface
Same definition described in Section 6.5 Same definition described in Section 6.6
7.7. Output packet count on incoming interface 7.8. Output packet count on incoming interface
Same definition described in Section 6.6 Same definition described in Section 6.7
7.8. Total number of packets for this source-group pair 7.9. Total number of packets for this source-group pair
This field counts the number of packets from the specified source This field counts the number of packets from the specified source
forwarded by this router to the specified group, or "all 1" if no forwarded by this router to the specified group, or "all 1" if no
count can be reported. If the S bit is set, the count is for the count can be reported. If the S bit is set, the count is for the
source network, as specified by the Src Prefix Len field. If the S source network, as specified by the Src Prefix Len field. If the S
bit is set and the Src Prefix Len field is 255, indicating no source- bit is set and the Src Prefix Len field is 255, indicating no source-
specific state, the count is for all sources sending to this group. specific state, the count is for all sources sending to this group.
This counter should have the same value as ipMcastRoutePkts from the This counter should have the same value as ipMcastRoutePkts from the
IPMROUTE-STD-MIB for this forwarding entry. IPMROUTE-STD-MIB for this forwarding entry.
7.9. Rtg Protocol: 16 bits 7.10. Rtg Protocol: 16 bits
Same definition described in Section 6.8
7.10. Multicast Rtg Protocol: 16 bits
Same definition described in Section 6.9 Same definition described in Section 6.9
7.11. MBZ: 15 bits 7.11. Multicast Rtg Protocol: 16 bits
Must be zeroed on transmission and ignored on reception. Same definition described in Section 6.10
7.12. S: 1 bit 7.12. S: 1 bit
This S bit indicates that the packet count for the source-group pair This S bit indicates that the packet count for the source-group pair
is for the source network, as determined by masking the source is for the source network, as determined by masking the source
address with the Src Prefix Len field. address with the Src Prefix Len field.
7.13. Src Prefix Len: 8 bits 7.13. Src Prefix Len: 8 bits
This field contains the prefix length this router has for the source. This field contains the prefix length this router has for the source.
skipping to change at page 22, line 11 skipping to change at page 23, line 11
response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6
mtrace2. Routers can tell the difference between Queries and mtrace2. Routers can tell the difference between Queries and
Requests by checking the length of the packet. Requests by checking the length of the packet.
9.2.1. Packet Verification 9.2.1. Packet Verification
If the mtrace2 Request does not come from an adjacent host or router, If the mtrace2 Request does not come from an adjacent host or router,
it MUST be silently ignored. If the mtrace2 Request is not addressed it MUST be silently ignored. If the mtrace2 Request is not addressed
to this router, or if the Request is addressed to a multicast group to this router, or if the Request is addressed to a multicast group
which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3] which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3]
for IPv6), it MUST be silently ignored. GTSM [16] SHOULD be used by for IPv6), it MUST be silently ignored. GTSM [14] SHOULD be used by
the router to determine whether the host or router is adjacent or the router to determine whether the host or router is adjacent or
not. not.
9.2.2. Normal Processing 9.2.2. Normal Processing
When a router receives an mtrace2 Request, it performs the following When a router receives an mtrace2 Request, it performs the following
steps. Note that it is possible to have multiple situations covered steps. Note that it is possible to have multiple situations covered
by the Forwarding Codes. The first one encountered is the one that by the Forwarding Codes. The first one encountered is the one that
is reported, i.e. all "note forwarding code N" should be interpreted is reported, i.e. all "note forwarding code N" should be interpreted
as "if forwarding code is not already set, set forwarding code to N". as "if forwarding code is not already set, set forwarding code to N".
skipping to change at page 23, line 8 skipping to change at page 24, line 8
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. If this router is the Core or RP and no source- should be used. If this router is the Core or RP and no source-
specific state is available (e.g., this router has been specific state is available (e.g., this router has been
receiving PIM Register messages from the first-hop router), note receiving PIM Register messages from the first-hop router), note
a code of REACHED_RP. a code of REACHED_RP.
3. If no forwarding information can be determined, the router notes 3. If no forwarding information can be determined, the router notes
an error code of NO_ROUTE, sets the remaining fields that have an error code of NO_ROUTE, sets the remaining fields that have
not yet been filled in to zero, and then forwards the packet to not yet been filled in to zero, and then forwards the packet to
the requester as described in Section 9.3. the mtrace2 client as described in Section 9.3.
4. Fill in the Incoming Interface Address, Previous-Hop Router 4. Fill in the Incoming Interface Address, Previous-Hop Router
Address, Input Packet Count, Total Number of Packets, Routing Address, Input Packet Count, Total Number of Packets, Routing
Protocol, S, and Src Mask from the forwarding information that Protocol, S, and Src Mask from the forwarding information that
was determined. was determined.
5. If mtrace2 is administratively prohibited or the previous hop 5. If mtrace2 is administratively prohibited or the previous hop
router does not understand mtrace2 requests, note the router does not understand mtrace2 requests, note the
appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If
mtrace2 is administratively prohibited and any of the fields as mtrace2 is administratively prohibited and any of the fields as
filled in step 4 are considered private information, zero out filled in step 4 are considered private information, zero out
the applicable fields. Then the packet is forwarded to the the applicable fields. Then the packet is forwarded to the
requester as described in Section 9.3. mtrace2 client as described in Section 9.3.
6. If the reception interface is not enabled for multicast, note 6. If the reception interface is not enabled for multicast, note
forwarding code NO_MULTICAST. If the reception interface is the forwarding code NO_MULTICAST. If the reception interface is the
interface from which the router would expect data to arrive from interface from which the router would expect data to arrive from
the source, note forwarding code RPF_IF. Otherwise, if the the source, note forwarding code RPF_IF. Otherwise, if the
reception interface is not one to which the router would forward reception interface is not one to which the router would forward
data from the source to the group, a forwarding code of WRONG_IF data from the source to the group, a forwarding code of WRONG_IF
is noted. is noted.
7. If the group is subject to administrative scoping on either the 7. If the group is subject to administrative scoping on either the
skipping to change at page 24, line 9 skipping to change at page 25, line 9
the information between this router and the mtrace2 querier, it the information between this router and the mtrace2 querier, it
notes forwarding code REACHED_GW. notes forwarding code REACHED_GW.
11. The packet is then sent on to the previous hop or the 11. The packet is then sent on to the previous hop or the
Destination Address as described in Section 9.3. Destination Address as described in Section 9.3.
9.3. Forwarding Mtrace2 Requests 9.3. Forwarding Mtrace2 Requests
If the Previous-hop router is known for this request and the number If the Previous-hop router is known for this request and the number
of response blocks is less than the number requested (i.e., the "# of response blocks is less than the number requested (i.e., the "#
hops" field in mtrace2 header), the packet is sent to that router. hops" field in mtrace2 Query header), the packet is sent to that
If the Incoming Interface is known but the Previous-hop router is not router. If the Incoming Interface is known but the Previous-hop
known, the packet is sent to an appropriate multicast address on the router is not known, the packet is sent to an appropriate multicast
Incoming Interface. The appropriate multicast address may depend on address on the Incoming Interface. The appropriate multicast address
the routing protocol in use, MUST be a link-scoped group (i.e. 224/24 may depend on the routing protocol in use, MUST be a link-scoped
for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET group (i.e. 224/24 for IPv4, FF02::/16 for IPv6), MUST NOT be ALL-
(224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6, and SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and All Nodes Address
MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers (FF02::1) for IPv6, and MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for
Address (FF02::2) for IPv6 if the routing protocol in use does not IPv4 or All Routers Address (FF02::2) for IPv6 if the routing
define a more appropriate group. Otherwise, it is sent to the protocol in use does not define a more appropriate group. Otherwise,
Destination Address in the header. it is sent to the Destination Address in the header.
When the REACHED_GW code is noted, the router sends back the mtrace2 When the REACHED_GW code is noted, the router sends back the mtrace2
response as in Section 9.4. In addition to that, it must continue response as in Section 9.4. In addition to that, it must continue
the mtrace2 query by proxying the original querier as in Section 9.5. the mtrace2 query by proxying the original querier as in Section 9.5.
When the NO_SPACE error occurs, the router sends back the mtrace2 When the NO_SPACE error occurs, the router sends back the mtrace2
response with contained data and the NO_SPACE error code as in response with contained data and the NO_SPACE error code as in
Section 9.4, and continues the mtrace2 query by sending an mtrace2 Section 9.4, and continues the mtrace2 query by sending an mtrace2
request containing the same mtrace2 query header and its standard and request containing the same mtrace2 Query header and its standard and
augmented response blocks. The corresponding augmented response augmented response blocks. The corresponding augmented response
block type is "# Mtrace2 Response Blocks Returned" described in block type is "# Mtrace2 Response Blocks Returned" described in
Section 8. Section 8.
9.4. Sending Mtrace2 Responses 9.4. Sending Mtrace2 Responses
9.4.1. Destination Address 9.4.1. Destination Address
An mtrace2 Response must be sent to the address specified in the An mtrace2 Response must be sent to the address specified in the
Destination Address field in the mtrace2 query header. Destination Address field in the mtrace2 Query header.
9.4.2. Source Address 9.4.2. Source Address
An mtrace2 Response must be sent with the address of the router's An mtrace2 Response must be sent with the address of the router's
reception interface. reception interface.
9.5. Proxying Mtrace2 Queries 9.5. Proxying Mtrace2 Queries
When a gateway (e.g., a NAT or firewall) that needs to block unicast When a gateway (e.g., a NAT or firewall) that needs to block unicast
packets to the mtrace2 querier or hide information between the packets to the mtrace2 querier or hide information between the
gateway and the mtrace2 querier receives mtrace2 query from an gateway and the mtrace2 querier receives mtrace2 query from an
adjacent host or mtrace2 request from an adjacent router, it sends adjacent host or mtrace2 request from an adjacent router, it sends
back the mtrace2 response with contained data and the REACHED_GW code back the mtrace2 response with contained data and the REACHED_GW code
to the address specified in the Destination Address field in the to the address specified in the Destination Address field in the
mtrace2 query header. mtrace2 Query header.
At the same time, the gateway prepares a new mtrace2 query message. At the same time, the gateway prepares a new mtrace2 query message.
The gateway uses the original mtrace2 query header as the base for The gateway uses the original mtrace2 Query header as the base for
the new mtrace2 query; it sets the Destination Address to its the new mtrace2 query; it sets the Destination Address to its
Incoming Interface address and the Client Port # to its own port Incoming Interface address and the Client Port # to its own port
(which may be the same as the mtrace2 port as the gateway is (which may be the same as the mtrace2 port as the gateway is
listening on that port), and decreases # hops according to the number listening on that port), and decreases # hops according to the number
of standard response blocks in the returned mtrace2 response from the of standard response blocks in the returned mtrace2 response from the
gateway. The mtrace2 query message is sent to the previous-hop gateway. The mtrace2 query message is sent to the previous-hop
router or to an appropriate multicast address on the Incoming router or to an appropriate multicast address on the Incoming
Interface. Interface.
When the gateway receives the mtrace2 response from the first-hop When the gateway receives the mtrace2 response from the first-hop
router or any intermediate router, it MUST forward the mtrace2 router or any intermediate router, it MUST forward the mtrace2
response back to the mtrace2 querier with the original mtrace2 query response back to the mtrace2 querier with the original mtrace2 Query
header. header.
9.6. Hiding Information 9.6. Hiding Information
Information about a domain's topology and connectivity may be hidden Information about a domain's topology and connectivity may be hidden
from multicast traceroute requests. The INFO_HIDDEN forwarding code from multicast traceroute requests. The INFO_HIDDEN forwarding code
may be used to note that, for example, the incoming interface address may be used to note that, for example, the incoming interface address
and packet count are for the entrance to the domain and the outgoing and packet count are for the entrance to the domain and the outgoing
interface address and packet count are the exit from the domain. The interface address and packet count are the exit from the domain. The
source-group packet count may be from either router or not specified source-group packet count may be from either router or not specified
skipping to change at page 26, line 44 skipping to change at page 27, line 44
10.3. Collecting Statistics 10.3. Collecting Statistics
After a client has determined that it has traced the whole path or as After a client has determined that it has traced the whole path or as
much as it can expect to (see Section 10.7), it might collect much as it can expect to (see Section 10.7), it might collect
statistics by waiting a short time and performing a second trace. If statistics by waiting a short time and performing a second trace. If
the path is the same in the two traces, statistics can be displayed the path is the same in the two traces, statistics can be displayed
as described in Section 12.3 and Section 12.4. as described in Section 12.3 and Section 12.4.
10.4. Last Hop Router 10.4. Last Hop Router
The mtrace2 querier may not know which is the last hop router, or The mtrace2 querier may not know which is the last-hop router, or
that router may be behind a firewall that blocks unicast packets but that router may be behind a firewall that blocks unicast packets but
passes multicast packets. In these cases, the mtrace2 request should passes multicast packets. In these cases, the mtrace2 request should
be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All
Routers Address (FF02::2) for IPv6. All routers except the correct Routers Address (FF02::2) for IPv6. All routers except the correct
last hop router should ignore any mtrace2 request received via last-hop router should ignore any mtrace2 request received via
multicast. Mtrace2 requests which are multicasted to the group being multicast.
traced must include the Router Alert option[6][7].
Another alternative is to unicast to the trace destination. Mtrace2
requests which are unicasted to the trace destination must include
the Router Alert option, in order that the last-hop router is aware
of the packet.
10.5. First Hop Router 10.5. First Hop Router
The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default
multicast group for IPv4 mtrace responses, in order to support mtrace multicast group for IPv4 mtrace responses, in order to support mtrace
queriers that are not unicast reachable from the first hop router. queriers that are not unicast reachable from the first-hop router.
However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses
for mtrace2 responses. Every mtrace2 response is sent to the unicast for mtrace2 responses. Every mtrace2 response is sent to the unicast
address specified in the Destination Address field of the mtrace2 address specified in the Destination Address field of the mtrace2
query header. Query header.
10.6. Broken Intermediate Router 10.6. Broken Intermediate Router
A broken intermediate router might simply not understand mtrace2 A broken intermediate router might simply not understand mtrace2
packets, and drop them. The querier would then get no response at packets, and drop them. The querier would then get no response at
all from its mtrace2 requests. It should then perform a hop-by-hop all from its mtrace2 requests. It should then perform a hop-by-hop
search by setting the number of responses field until it gets a search by setting the number of responses field until it gets a
response (both linear and binary search are options, but binary is response (both linear and binary search are options, but binary is
likely to be slower because a failure requires waiting for a likely to be slower because a failure requires waiting for a
timeout). timeout).
10.7. Mtrace2 Termination 10.7. Mtrace2 Termination
When performing an expanding hop-by-hop trace, it is necessary to When performing an expanding hop-by-hop trace, it is necessary to
determine when to stop expanding. determine when to stop expanding.
10.7.1. Arriving at source 10.7.1. Arriving at source
A trace can be determined to have arrived at the source if the A trace can be determined to have arrived at the source if the
Incoming Interface of the last router in the trace is non-zero, but Incoming Interface of the last router in the trace is non-zero, but
the Previous Hop router is zero. the Previous-hop router is zero.
10.7.2. Fatal error 10.7.2. Fatal error
A trace has encountered a fatal error if the last Forwarding Error in A trace has encountered a fatal error if the last Forwarding Error in
the trace has the 0x80 bit set. the trace has the 0x80 bit set.
10.7.3. No previous hop 10.7.3. No previous hop
A trace can not continue if the last Previous Hop in the trace is set A trace can not continue if the last Previous-hop in the trace is set
to 0. to 0.
10.7.4. Traceroute shorter than requested 10.7.4. Traceroute shorter than requested
If the trace that is returned is shorter than requested (i.e. the If the trace that is returned is shorter than requested (i.e. the
number of response blocks is smaller than the "# hops" field), the number of response blocks is smaller than the "# hops" field), the
trace encountered an error and could not continue. trace encountered an error and could not continue.
10.8. Continuing after an error 10.8. Continuing after an error
When the NO_SPACE error occurs, as described in Section 9.3, the When the NO_SPACE error occurs, as described in Section 9.3, the
multicast routers sends back the mtrace2 response to the address multicast routers sends back the mtrace2 Response to the address
specified in the Destination Address field in the mtrace2 query specified in the Destination Address field in the mtrace2 Query
header. In this case, the mtrace2 client may receive multiple header. In this case, the mtrace2 client may receive multiple
mtrace2 responses from different routers (along the path). After the mtrace2 responses from different routers (along the path). After the
client receives multiple mtrace2 response messages, it integrates client receives multiple mtrace2 Response messages, it integrates
(i.e. constructs) them as a single mtrace2 response message. (i.e. constructs) them as a single mtrace2 Response message.
If a trace times out, it is likely to be because a router in the If a trace times out, it is likely to be because a router in the
middle of the path does not support multicast traceroute. That middle of the path does not support mtrace2. That router's address
router's address will be in the Previous Hop field of the last entry will be in the Previous-hop router field of the last entry in the
in the last response packet received. A client may be able to last response packet received. A client may be able to determine
determine (via mrinfo or SNMP [13][15]) a list of neighbors of the (via mrinfo or SNMP [11][13]) a list of neighbors of the non-
non-responding router. If desired, each of those neighbors could be responding router. If desired, each of those neighbors could be
probed to determine the remainder of the path. Unfortunately, this probed to determine the remainder of the path. Unfortunately, this
heuristic may end up with multiple paths, since there is no way of heuristic may end up with multiple paths, since there is no way of
knowing what the non-responding router's algorithm for choosing a knowing what the non-responding router's algorithm for choosing a
previous-hop router is. However, if all paths but one flow back previous-hop router is. However, if all paths but one flow back
towards the non-responding router, it is possible to be sure that towards the non-responding router, it is possible to be sure that
this is the correct path. this is the correct path.
11. Protocol-Specific Considerations 11. Protocol-Specific Considerations
11.1. PIM-SM 11.1. PIM-SM
When a multicast traceroute reaches a PIM-SM RP and the RP does not When an mtrace2 reaches a PIM-SM RP and the RP does not forward the
forward the trace on, it means that the RP has not performed a trace on, it means that the RP has not performed a source-specific
source-specific join so there is no more state to trace. However, join so there is no more state to trace. However, the path that
the path that traffic would use if the RP did perform a source- traffic would use if the RP did perform a source-specific join can be
specific join can be traced by setting the trace destination to the traced by setting the trace destination to the RP, the trace source
RP, the trace source to the traffic source, and the trace group to 0. to the traffic source, and the trace group to 0. This trace Query
This trace Query may be unicasted to the RP. may be unicasted to the RP.
11.2. Bi-Directional PIM 11.2. Bi-Directional PIM
Bi-directional PIM [9] is a variant of PIM-SM that builds bi- Bi-directional PIM [7] 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 sources to the RPA (Rendezvous Point Address) and from forwarded from sources to the RPA (Rendezvous Point Address) and from
the RPA to receivers without requiring source-specific state. In the RPA to receivers without requiring source-specific state. In
contrast to PIM-SM, RP always has the state to trace. contrast to PIM-SM, RP always has the state to trace.
A Designated Forwarder (DF) for a given RPA is in charge of A Designated Forwarder (DF) for a given RPA is in charge of
forwarding downstream traffic onto its link, and forwarding upstream forwarding downstream traffic onto its link, and forwarding upstream
traffic from its link towards the RPL (Rendezvous Point Link) that traffic from its link towards the RPL (Rendezvous Point Link) that
the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along
the path. the path.
11.3. PIM-DM 11.3. PIM-DM
Routers running PIM Dense Mode do not know the path packets would Routers running PIM Dense Mode do not know the path packets would
take unless traffic is flowing. Without some extra protocol take unless traffic is flowing. Without some extra protocol
mechanism, this means that in an environment with multiple possible mechanism, this means that in an environment with multiple possible
paths with branch points on shared media, multicast traceroute can paths with branch points on shared media, mtrace2 can only trace
only trace existing paths, not potential paths. When there are existing paths, not potential paths. When there are multiple
multiple possible paths but the branch points are not on shared possible paths but the branch points are not on shared media, the
media, the previous hop router is known, but the last hop router may previous hop router is known, but the last-hop router may not know
not know that it is the appropriate last hop. that it is the appropriate last hop.
When traffic is flowing, PIM Dense Mode routers know whether or not When traffic is flowing, PIM Dense Mode routers know whether or not
they are the last-hop forwarder for the link (because they won or they are the last-hop forwarder for the link (because they won or
lost an Assert battle) and know who the previous hop is (because it lost an Assert battle) and know who the previous hop is (because it
won an Assert battle). Therefore, multicast traceroute is always won an Assert battle). Therefore, mtrace2 is always able to follow
able to follow the proper path when traffic is flowing. the proper path when traffic is flowing.
11.4. IGMP/MLD Proxy 11.4. IGMP/MLD Proxy
When a mtrace2 Query packet reaches an incoming interface of IGMP/MLD When an mtrace2 Query packet reaches an incoming interface of IGMP/
Proxy [10], it puts a WRONG_IF (0x01) value in Forwarding Code of MLD Proxy [8], it puts a WRONG_IF (0x01) value in Forwarding Code of
mtrace2 standard response block (as in Section 6.14) and sends the mtrace2 standard response block (as in Section 6.14) and sends the
mtrace2 response back to the Destination Address. When a mtrace2 mtrace2 response back to the Destination Address. When an mtrace2
Query packet reaches an outgoing interface of IGMP/MLD proxy, it is Query packet reaches an outgoing interface of IGMP/MLD proxy, it is
forwarded through its incoming interface towards the upstream router. forwarded through its incoming interface towards the upstream router.
11.5. AMT 11.5. AMT
AMT [11] provides the multicast connectivity to the unicast-only AMT [9] provides the multicast connectivity to the unicast-only
inter-network. To do this, multicast packets being sent to or from a inter-network. To do this, multicast packets being sent to or from a
site are encapsulated in unicast packets. When a mtrace2 query site are encapsulated in unicast packets. When an mtrace2 query
packet reaches an AMT pseudo-interface of an AMT gateway, the AMT packet reaches an AMT pseudo-interface of an AMT gateway, the AMT
gateway encapsulats it to a particular AMT relay reachable across the gateway encapsulats it to a particular AMT relay reachable across the
unicast-only infrastructure. Then the AMT relay decapsulates the unicast-only infrastructure. Then the AMT relay decapsulates the
mtrace2 query packet and forwards the mtrace2 request to the mtrace2 query packet and forwards the mtrace2 request to the
appropriate multicast router. appropriate multicast router.
12. Problem Diagnosis 12. Problem Diagnosis
12.1. Forwarding Inconsistencies 12.1. Forwarding Inconsistencies
skipping to change at page 35, line 14 skipping to change at page 36, line 14
15. Acknowledgements 15. 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. by Ajit Thyagarajan, Steve Casner and Bill Fenner.
The idea of unicasting a multicast traceroute Query to the The idea of the "S" bit to allow statistics for a source subnet is
destination of the trace with Router Alert set is due to Tony due to Tom Pusateri.
Ballardie. The idea of the "S" bit to allow statistics for a source
subnet is due to Tom Pusateri.
For the mtrace version 2 specification, extensive comments were For the mtrace version 2 specification, extensive comments were
received from Yiqun Cai, Liu Hui, Bharat Joshi, Pekka Savola, received from Ronald Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Pekka
Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, and Cao Wei. Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, and Cao
Wei.
16. References 16. References
16.1. Normative References 16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement [1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
[5] Braden, B., Borman, D., and C. Partridge, "Computing the [5] Braden, B., Borman, D., and C. Partridge, "Computing the
Internet Checksum", RFC 1071, September 1988. Internet Checksum", RFC 1071, September 1988.
[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [6] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
[7] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[8] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[9] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [7] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-PIM)", "Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
RFC 5015, October 2007. RFC 5015, October 2007.
[10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet [8] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006. RFC 4605, August 2006.
[11] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. [9] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in (AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in
progress), October 2007. progress), October 2007.
16.2. Informative References 16.2. Informative References
[12] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [10] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[13] Draves, R. and D. Thaler, "Default Router Preferences and More- [11] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005. Specific Routes", RFC 4191, November 2005.
[14] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", [12] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000. RFC 2863, June 2000.
[15] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", [13] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB",
RFC 5132, December 2007. RFC 5132, December 2007.
[16] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, [14] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro,
"The Generalized TTL Security Mechanism (GTSM)", RFC 5082, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082,
October 2007. October 2007.
Authors' Addresses Authors' Addresses
Hitoshi Asaeda Hitoshi Asaeda
Keio University Keio University
Graduate School of Media and Governance Graduate School of Media and Governance
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
skipping to change at page 38, line 28 skipping to change at page 39, line 28
Redwood City, CA 94063 Redwood City, CA 94063
US US
Email: Jinmei_Tatuya@isc.org Email: Jinmei_Tatuya@isc.org
William C. Fenner William C. Fenner
Arastra, Inc. Arastra, Inc.
Menlo Park, CA 94025 Menlo Park, CA 94025
US US
Email: fenner@fenron.com Email: fenner@fenron.net
Stephen L. Casner Stephen L. Casner
Packet Design, Inc. Packet Design, Inc.
Palo Alto, CA 94304 Palo Alto, CA 94304
US US
Email: casner@packetdesign.com Email: casner@packetdesign.com
 End of changes. 100 change blocks. 
280 lines changed or deleted 298 lines changed or added

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