draft-ietf-idmr-traceroute-ipm-03.txt   draft-ietf-idmr-traceroute-ipm-04.txt 
Internet Engineering Task Force Inter-Domain Multicast Routing Working Group Internet Engineering Task Force Inter-Domain Multicast Routing Working Group
INTERNET-DRAFT W. Fenner INTERNET-DRAFT W. Fenner
draft-ietf-idmr-traceroute-ipm-03.txt Xerox PARC draft-ietf-idmr-traceroute-ipm-04.txt Xerox PARC
S. Casner S. Casner
Precept Software Cisco Systems
August 5, 1998 February 26, 1999
Expires December 1998 Expires August 1999
A "traceroute" facility for IP Multicast. A "traceroute" facility for IP Multicast.
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu- This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working doc- working groups. Note that other groups may also distribute working doc-
uments as Internet-Drafts. uments as Internet-Drafts.
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 material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt.
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), The list of Internet-Draft Shadow Directories can be accessed at
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract Abstract
This draft describes the IGMP multicast traceroute facility. As This draft describes the IGMP multicast traceroute facility. As
the deployment of IP multicast has spread, it has become clear that the deployment of IP multicast has spread, it has become clear that
a method for tracing the route that a multicast IP packet takes a method for tracing the route that a multicast IP packet takes
from a source to a particular receiver is absolutely required. from a source to a particular receiver is absolutely required.
Unlike unicast traceroute, multicast traceroute requires a special Unlike unicast traceroute, multicast traceroute requires a special
skipping to change at page 8, line 12 skipping to change at page 8, line 12
This field describes the routing protocol in use between this This field describes the routing protocol in use between this
router and the previous-hop router. Specified values include: router and the previous-hop router. Specified values include:
1 DVMRP 1 DVMRP
2 MOSPF 2 MOSPF
3 PIM 3 PIM
4 CBT 4 CBT
5 PIM using special routing table 5 PIM using special routing table
6 PIM using a static route 6 PIM using a static route
7 DVMRP using a static route 7 DVMRP using a static route
8 PIM using MBGP (aka BGP4+) route
9 CBT using special routing table
10 CBT using a static route
11 PIM using state created by Assert processing
5.9. FwdTTL: 8 bits 5.9. FwdTTL: 8 bits
This field contains the TTL that a packet is required to have This field contains the TTL that a packet is required to have
before it will be forwarded over the outgoing interface. before it will be forwarded over the outgoing interface.
5.10. MBZ: 1 bit 5.10. MBZ: 1 bit
Must be zeroed on transmission and ignored on reception. Must be zeroed on transmission and ignored on reception.
skipping to change at page 9, line 51 skipping to change at page 10, line 8
TTL remaining and is not addressed to this router. TTL remaining and is not addressed to this router.
6.1. Traceroute Query 6.1. Traceroute Query
A traceroute Query message is a traceroute message with no response A traceroute Query message is a traceroute message with no response
blocks filled in, and uses IGMP type 0x1F. blocks filled in, and uses IGMP type 0x1F.
6.1.1. Packet Verification 6.1.1. Packet Verification
Upon receiving a traceroute Query message, a router must examine Upon receiving a traceroute Query message, a router must examine
the Query to see if it is the proper last-hop router for the the Query to see if it is the proper last-hop router for the desti-
destination address in the packet. It is the proper last-hop nation address in the packet. It is the proper last-hop router if
router if it has a multicast-capable interface on the same subnet it has a multicast-capable interface on the same subnet as the Des-
as the Destination Address and is the router that would forward tination Address and is the router that would forward traffic from
traffic from the given source onto that subnet. the given source onto that subnet.
If the router determines that it is not the proper last-hop router, If the router determines that it is not the proper last-hop router,
or it cannot make that determination, it does one of two things or it cannot make that determination, it does one of two things
depending if the Query was received via multicast or unicast. If depending if the Query was received via multicast or unicast. If
the Query was received via multicast, then it MUST be silently the Query was received via multicast, then it MUST be silently
dropped. If it was received via unicast, a forwarding code of dropped. If it was received via unicast, a forwarding code of
NOT_LAST_HOP is noted and processing continues as in section 7.2. NOT_LAST_HOP is noted and processing continues as in section 6.2.
Duplicate Query messages as identified by the tuple (IP Source, Duplicate Query messages as identified by the tuple (IP Source,
Query ID) SHOULD be ignored. Query ID) SHOULD be ignored.
6.1.2. Normal Processing 6.1.2. Normal Processing
When a router receives a traceroute Query and it determines that it When a router receives a traceroute Query and it determines that it
is the proper last-hop router, it treats it like a traceroute is the proper last-hop router, it treats it like a traceroute
Request and performs the steps listed in section 7.2. Request and performs the steps listed in section 6.2.
6.2. Traceroute Request 6.2. Traceroute Request
A traceroute Request is a traceroute message with some number of A traceroute Request is a traceroute message with some number of
response blocks filled in, and also uses IGMP type 0x1F. Routers response blocks filled in, and also uses IGMP type 0x1F. Routers
can tell the difference between Queries and Requests by checking can tell the difference between Queries and Requests by checking
the length of the packet. the length of the packet.
6.2.1. Packet Verification 6.2.1. Packet Verification
skipping to change at page 13, line 33 skipping to change at page 13, line 41
client, the traceroute Query packet can be sent to the ALL-ROUTERS client, the traceroute Query packet can be sent to the ALL-ROUTERS
multicast group (224.0.0.2). This will ensure that the packet is multicast group (224.0.0.2). This will ensure that the packet is
received by the last-hop router on the subnet. Otherwise, if the received by the last-hop router on the subnet. Otherwise, if the
proper last-hop router is known for the trace destination, the proper last-hop router is known for the trace destination, the
Query could be unicasted to that router. Otherwise, the Query Query could be unicasted to that router. Otherwise, the Query
packet should be multicasted to the group being queried; if the packet should be multicasted to the group being queried; if the
destination of the trace is a member of the group this will get the destination of the trace is a member of the group this will get the
Query to the proper last-hop router. In this final case, the Query to the proper last-hop router. In this final case, the
packet should contain the Router Alert option, to make sure that packet should contain the Router Alert option, to make sure that
routers that are not members of the multicast group notice the routers that are not members of the multicast group notice the
packet. See also section 8.2 on determining the last-hop router. packet. See also section 7.2 on determining the last-hop router.
7.1.2. Determining the Path 7.1.2. Determining the Path
The client could send a small number of Initial Query messages with The client could send a small number of Initial Query messages with
a large "# hops" field, in order to try to trace the full path. If a large "# hops" field, in order to try to trace the full path. If
this attempt fails, one strategy is to perform a linear search (as this attempt fails, one strategy is to perform a linear search (as
the traditional unicast traceroute program does); set the "#hops" the traditional unicast traceroute program does); set the "#hops"
field to 1 and try to get a response, then 2, and so on. If no field to 1 and try to get a response, then 2, and so on. If no
response is received at a certain hop, the hop count can continue response is received at a certain hop, the hop count can continue
past the non-responding hop, in the hopes that further hops may past the non-responding hop, in the hopes that further hops may
respond. These attempts should continue until a user-defined time- respond. These attempts should continue until a user-defined time-
out has occurred. out has occurred.
See also section 8.3 and 8.4 on receiving the results of a trace. See also section 7.3 and 7.4 on receiving the results of a trace.
7.1.3. Collecting Statistics 7.1.3. Collecting Statistics
After a client has determined that it has traced the whole path or After a client has determined that it has traced the whole path or
as much as it can expect to (see section 8.5), it might collect as much as it can expect to (see section 7.5), it might collect
statistics by waiting a short time and performing a second trace. statistics by waiting a short time and performing a second trace.
If the path is the same in the two traces, statistics can be dis- If the path is the same in the two traces, statistics can be dis-
played as described in section 9.3 and 9.4. played as described in section 8.3 and 8.4.
Details of performing a multicast traceroute: Details of performing a multicast traceroute:
7.2. Last hop router 7.2. Last hop router
The traceroute querier may not know which is the last hop router, The traceroute querier may not know which is the last hop router,
or that router may be behind a firewall that blocks unicast packets or that router may be behind a firewall that blocks unicast packets
but passes multicast packets. In these cases, the traceroute but passes multicast packets. In these cases, the traceroute
request should be multicasted to the group being traced (since the request should be multicasted to the group being traced (since the
last hop router listens to that group). All routers except the last hop router listens to that group). All routers except the
skipping to change at page 16, line 17 skipping to change at page 16, line 22
neighbors of the non-responding router. If desired, each of those neighbors of the non-responding router. If desired, each of those
neighbors could be probed to determine the remainder of the path. neighbors could be probed to determine the remainder of the path.
Unfortunately, this heuristic may end up with multiple paths, since Unfortunately, this heuristic may end up with multiple paths, since
there is no way of knowing what the non-responding router's algo- there is no way of knowing what the non-responding router's algo-
rithm for choosing a previous-hop router is. However, if all paths rithm for choosing a previous-hop router is. However, if all paths
but one flow back towards the non-responding router, it is possible but one flow back towards the non-responding router, it is possible
to be sure that this is the correct path. to be sure that this is the correct path.
7.7. Multicast Traceroute and shared-tree routing protocols 7.7. Multicast Traceroute and shared-tree routing protocols
When using shared-tree routing protocols like PIM-SM and CBT, it is When using shared-tree routing protocols like PIM-SM and CBT, a
still possible to use multicast traceroute to determine paths. more advanced client may use multicast traceroute to determine
paths or potential paths.
7.7.1. PIM-SM 7.7.1. PIM-SM
When a multicast traceroute reaches a PIM-SM RP and the RP does not for- When a multicast traceroute reaches a PIM-SM RP and the RP does not for-
ward the trace on, it means that the RP has not performed a source-spe- ward the trace on, it means that the RP has not performed a source-spe-
cific join so there is no more state to trace. However, the path that cific 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 to traced by setting the trace destination to the RP, the trace source to
the traffic source, and the trace group to 0. This trace Query may be the traffic source, and the trace group to 0. This trace Query may be
unicasted to the RP. unicasted to the RP.
skipping to change at page 17, line 8 skipping to change at page 17, line 15
7.7.2.2. Overlapping paths 7.7.2.2. Overlapping paths
If there is a portion of the path that is common to the ends of the If there is a portion of the path that is common to the ends of the
two traces, that portion is removed from both traces. Then, as in two traces, that portion is removed from both traces. Then, as in
the no overlap case, the second trace is reversed and appended to the no overlap case, the second trace is reversed and appended to
the first trace, and the composite trace again contains the full the first trace, and the composite trace again contains the full
path. path.
This algorithm works whether the source has joined the CBT tree or not. This algorithm works whether the source has joined the CBT tree or not.
7.8. Protocol-specific considerations
7.8.1. DVMRP
DVMRP's dominant router election and route exchange guarantees that
DVMRP routers know whether or not they are the last-hop forwarder
for the link and who the previous hop is.
7.8.2. PIM Dense Mode
Routers running PIM Dense Mode do not know the path packets would
take unless traffic is flowing. Without some extra protocol mecha-
nism, this means that in an environment with multiple possible
paths with branch points on shared media, multicast traceroute can
only trace existing paths, not potential paths. When there are
multiple possible paths but the branch points are not on shared
media, the previous hop router is known, but the last hop router
may not know that it is the appropriate last hop.
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
lost an Assert battle) and know who the previous hop is (because it
won an Assert battle). Therefore, multicast traceroute is always
able to follow the proper path when traffic is flowing.
8. Problem Diagnosis 8. Problem Diagnosis
8.1. Forwarding Inconsistencies 8.1. Forwarding Inconsistencies
The forwarding error code can tell if a group is unexpectedly The forwarding error code can tell if a group is unexpectedly
pruned or administratively scoped. pruned or administratively scoped.
8.2. TTL problems 8.2. TTL problems
By taking the maximum of (hops from source + forwarding TTL thresh- By taking the maximum of (hops from source + forwarding TTL thresh-
skipping to change at page 21, line 21 skipping to change at page 21, line 21
Phone: +1 650 812 4816 Phone: +1 650 812 4816
Email: fenner@parc.xerox.com Email: fenner@parc.xerox.com
Stephen L. Casner Stephen L. Casner
Cisco Systems Cisco Systems
1072 Arastradero Road 1072 Arastradero Road
Palo Alto, CA 94304 Palo Alto, CA 94304
Email: casner@precept.com Email: casner@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/