draft-ietf-idmr-traceroute-ipm-02.txt		draft-ietf-idmr-traceroute-ipm-03.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-02.txt Xerox PARC		draft-ietf-idmr-traceroute-ipm-03.txt Xerox PARC
	S. Casner		S. Casner
	Precept Software		Precept Software
	November 21, 1997		August 5, 1998
	Expires April 1998		Expires December 1998
	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		This document is an Internet-Draft. Internet-Drafts are working docu-
	documents of the Internet Engineering Task Force (IETF), its Areas, and		ments of the Internet Engineering Task Force (IETF), its areas, and its
	its Working Groups. Note that other groups may also distribute working		working groups. Note that other groups may also distribute working doc-
	documents 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
	Internet Drafts may be updated, replaced, or obsoleted by other		and may be updated, replaced, or obsoleted by other documents at any
	documents at any time. It is not appropriate to use Internet Drafts as		time. It is inappropriate to use Internet- Drafts as reference material
	reference material or to cite them other than as a "working draft" or		or to cite them other than as "work in progress."
	"work in progress."
	To learn the current status of any Internet-Draft, please check the		To view the entire list of current Internet-Drafts, please check the
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or		ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
	ftp.isi.edu (US West Coast).		ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
	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
	packet type and implementation on the part of routers. This		packet type and implementation on the part of routers. This speci-
	specification describes the required functionality.		fication describes the required functionality.
	This document is a product of the Inter-Domain Multicast Routing working		This document is a product of the Inter-Domain Multicast Routing working
	group within the Internet Engineering Task Force. Comments are		group within the Internet Engineering Task Force. Comments are
	solicited and should be addressed to the working group's mailing list at		solicited and should be addressed to the working group's mailing list at
	idmr@cs.ucl.ac.uk and/or the author(s).		idmr@cs.ucl.ac.uk and/or the author(s).
	1. Key Words		Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in RFC 2119		document are to be interpreted as described in RFC 2119 [Bradner97].
	[Bradner97].
	2. Introduction		1. Introduction
	The unicast "traceroute" program allows the tracing of a path from one		The unicast "traceroute" program allows the tracing of a path from one
	machine to another, using a mechanism that already existed in IP.		machine to another, using a mechanism that already existed in IP.
	Unfortunately, no such existing mechanism can be applied to IP multicast		Unfortunately, no such existing mechanism can be applied to IP multicast
	paths. The key mechanism for unicast traceroute is the ICMP TTL exceeded		paths. The key mechanism for unicast traceroute is the ICMP TTL
	message, which is specifically precluded as a response to multicast		exceeded message, which is specifically precluded as a response to mul-
	packets. Thus, we specify the multicast "traceroute" facility to be		ticast packets. Thus, we specify the multicast "traceroute" facility to
	implemented in multicast routers and accessed by diagnostic programs.		be implemented in multicast routers and accessed by diagnostic programs.
	While it is a disadvantage that a new mechanism is required, the		While it is a disadvantage that a new mechanism is required, the multi-
	multicast traceroute facility can provide additional information about		cast traceroute facility can provide additional information about packet
	packet rates and losses that the unicast traceroute cannot, and		rates and losses that the unicast traceroute cannot, and generally
	generally requires fewer packets to be sent.		requires fewer packets to be sent.
	Goals:		Goals:
	+ To be able to trace the path that a packet would take from some		o To be able to trace the path that a packet would take from some
	source to some destination.		source to some destination.
	+ To be able to isolate packet loss problems (e.g., congestion).		o To be able to isolate packet loss problems (e.g., congestion).
	+ To be able to isolate configuration problems (e.g., TTL threshold).		o To be able to isolate configuration problems (e.g., TTL threshold).
	+ To minimize packets sent (e.g. no flooding, no implosion).		o To minimize packets sent (e.g. no flooding, no implosion).
	3. Overview		2. Overview
	Tracing from a source to a multicast destination is hard, since you		Given a multicast distribution tree, tracing from a source to a multi-
	don't know down which branch of the multicast tree the destination lies.		cast destination is hard, since you don't know down which branch of the
	This means that you have to flood the whole tree to find the path from		multicast tree the destination lies. This means that you have to flood
	one source to one destination. However, walking up the tree from		the whole tree to find the path from one source to one destination.
	destination to source is easy, as all existing multicast routing		However, walking up the tree from destination to source is easy, as most
	protocols know the previous hop for each source. Tracing from		existing multicast routing protocols know the previous hop for each
	destination to source can involve only routers on the direct path.		source. Tracing from destination to source can involve only routers on
			the direct path.
	The party requesting the traceroute (which need be neither the source		The party requesting the traceroute (which need be neither the source
	nor the destination) sends a traceroute Query packet to the last-hop		nor the destination) sends a traceroute Query packet to the last-hop
	multicast router for the given destination. The last-hop router turns		multicast router for the given destination. The last-hop router turns
	the Query into a Request packet by adding a response data block		the Query into a Request packet by adding a response data block contain-
	containing its interface addresses and packet statistics, and then		ing its interface addresses and packet statistics, and then forwards the
	forwards the Request packet via unicast to the router that it believes		Request packet via unicast to the router that it believes is the proper
	is the proper previous hop for the given source and group. Each hop		previous hop for the given source and group. Each hop adds its response
	adds its response data to the end of the Request packet, then unicast		data to the end of the Request packet, then unicast forwards it to the
	forwards it to the previous hop. The first hop router (the router that		previous hop. The first hop router (the router that believes that pack-
	believes that packets from the source originate on one of its directly		ets from the source originate on one of its directly connected networks)
	connected networks) changes the packet type to indicate a Response		changes the packet type to indicate a Response packet and sends the com-
	packet and sends the completed response to the response destination		pleted response to the response destination address. The response may
	address. The response may be returned before reaching the first hop		be returned before reaching the first hop router if a fatal error condi-
	router if a fatal error condition such as "no route" is encountered		tion such as "no route" is encountered along the path.
	along the path.
	Multicast traceroute uses any information available to it in the router		Multicast traceroute uses any information available to it in the router
	to attempt to determine a previous hop to forward the trace towards.		to attempt to determine a previous hop to forward the trace towards.
	Multicast routing protocols vary in the type and amount of state they		Multicast routing protocols vary in the type and amount of state they
	keep; multicast traceroute endeavors to work with all of them by using		keep; multicast traceroute endeavors to work with all of them by using
	whatever is available. For example, if a DVMRP router has no active		whatever is available. For example, if a DVMRP router has no active
	state for a particular source but does have a DVMRP route, it chooses		state for a particular source but does have a DVMRP route, it chooses
	the parent of the DVMRP route as the previous hop. If a PIM-SM router		the parent of the DVMRP route as the previous hop. 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 previ-
	previous hop. In these cases, no source/group-specific state is		ous hop. In these cases, no source/group-specific state is available,
	available, but the path may still be traced.		but the path may still be traced.
	4. Multicast Traceroute header		3. Multicast Traceroute header
	The header for all multicast traceroute packets is as follows:		The header for all multicast traceroute packets is 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IGMP Type | # hops | checksum |		| IGMP Type | # hops | checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Multicast Group Address |		| Multicast Group Address |
	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+		+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
	| Source Address |		| Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Destination Address |		| Destination Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Response Address |		| Response Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| resp ttl | Query ID |		| resp ttl | Query ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	4.1. IGMP Type: 8 bits		3.1. IGMP Type: 8 bits
	The IGMP type field is defined to be 0x1F for traceroute queries		The IGMP type field is defined to be 0x1F for traceroute queries
	and requests. The IGMP type field is changed to 0x1E when the		and requests. The IGMP type field is changed to 0x1E when the
	packet is completed and sent as a response from the first hop		packet is completed and sent as a response from the first hop
	router to the querier. Two codes are required so that multicast		router to the querier. Two codes are required so that multicast
	routers won't attempt to process a completed response in those		routers won't attempt to process a completed response in those
	cases where the initial query was issued from a router or the		cases where the initial query was issued from a router or the
	response is sent via multicast.		response is sent via multicast.
	4.2. # hops: 8 bits		3.2. # hops: 8 bits
	This field specifies the maximum number of hops that the requester		This field specifies the maximum number of hops that the requester
	wants to trace. If there is some error condition in the middle of		wants to trace. If there is some error condition in the middle of
	the path that keeps the traceroute request from reaching the		the path that keeps the traceroute request from reaching the first-
	first-hop router, this field can be used to perform an expanding-		hop router, this field can be used to perform an expanding-length
	length search to trace the path to just before the problem.		search to trace the path to just before the problem.
	4.3. Checksum: 16 bits		3.3. Checksum: 16 bits
	The checksum is the 16-bit one's complement of the one's complement		The checksum is the 16-bit one's complement of the one's complement
	sum of the whole IGMP message (the entire IP payload). For		sum of the whole IGMP message (the entire IP payload)[Brad88].
	computing the checksum, the checksum field is set to zero. When		When computing the checksum, the checksum field is set to zero.
	transmitting packets, the checksum MUST be computed and inserted		When transmitting packets, the checksum MUST be computed and
	into this field. When receiving packets, the checksum MUST be		inserted into this field. When receiving packets, the checksum
	verified before processing a packet.		MUST be verified before processing a packet.
	4.4. Group address		3.4. Group address
	This field specifies the group address to be traced, or zero if no		This field specifies the group address to be traced, or zero if no
	group-specific information is desired. Note that non-group-		group-specific information is desired. Note that non-group-spe-
	specific traceroutes may not be possible with certain multicast		cific traceroutes may not be possible with certain multicast rout-
	routing protocols.		ing protocols.
	4.5. Source address		3.5. Source address
	This field specifies the IP address of the multicast source for the		This field specifies the IP address of the multicast source for the
	path being traced, or 0xFFFFFFFF if no source-specific information		path being traced, or 0xFFFFFFFF if no source-specific information
	is desired. Note that non-source-specific traceroutes may not be		is desired. Note that non-source-specific traceroutes may not be
	possible with certain multicast routing protocols.		possible with certain multicast routing protocols.
	4.6. Destination address		3.6. Destination address
	This field specifies the IP address of the multicast receiver for		This field specifies the IP address of the multicast receiver for
	the path being traced. The trace starts at this destination and		the path being traced. The trace starts at this destination and
	proceeds toward the traffic source.		proceeds toward the traffic source.
	4.7. Response Address		3.7. Response Address
	This field specifies where the completed traceroute response packet		This field specifies where the completed traceroute response packet
	gets sent. It can be a unicast address or a multicast address, as		gets sent. It can be a unicast address or a multicast address, as
	explained in section 6.2.		explained in section 6.2.
	4.8. resp ttl: 8 bits		3.8. resp ttl: 8 bits
	This field specifies the TTL at which to multicast the response, if		This field specifies the TTL at which to multicast the response, if
	the response address is a multicast address.		the response address is a multicast address.
	4.9. Query ID: 24 bits		3.9. Query ID: 24 bits
	This field is used as a unique identifier for this traceroute		This field is used as a unique identifier for this traceroute
	request so that duplicate or delayed responses may be detected and		request so that duplicate or delayed responses may be detected and
	to minimize collisions when a multicast response address is used.		to minimize collisions when a multicast response address is used.
	5. Definitions		4. Definitions
	Since multicast traceroutes flow in the opposite direction to the data		Since multicast traceroutes flow in the opposite direction to the data
	flow, we always refer to "upstream" and "downstream" with respect to		flow, we always refer to "upstream" and "downstream" with respect to
	data, unless explicitly specified.		data, unless explicitly specified.
	Incoming Interface		Incoming Interface
	The interface on which traffic is expected from the specified		The interface on which traffic is expected from the specified
	source and group.		source and group.
	Outgoing Interface		Outgoing Interface
	The interface on which traffic is forwarded from the specified		The interface on which traffic is forwarded from the specified
	source and group towards the destination. Also called the		source and group towards the destination. Also called the "Recep-
	"Reception Interface", since it is the interface on which the		tion Interface", since it is the interface on which the multicast
	multicast traceroute Request was received.		traceroute Request was received.
	Previous-Hop Router		Previous-Hop Router
	The router, on the Incoming Interface, which is responsible for		The router, on the Incoming Interface, which is responsible for
	forwarding traffic for the specified source and group.		forwarding traffic for the specified source and group.
	6. Response data		5. Response data
	Each router adds a "response data" segment to the traceroute packet be-		Each router adds a "response data" segment to the traceroute packet
	fore it forwards it on. The response data looks like this:		before it forwards it on. The response data looks like this:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Query Arrival Time |		| Query Arrival Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Incoming Interface Address |		| Incoming Interface Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Outgoing Interface Address |		| Outgoing Interface Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 32		skipping to change at page 6, line 32
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Output packet count on outgoing interface |		| Output packet count on outgoing interface |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Total number of packets for this source-group pair |		| Total number of packets for this source-group pair |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | |M| | | |		| | |M| | | |
	| Rtg Protocol | FwdTTL |B|S| Src Mask |Forwarding Code|		| Rtg Protocol | FwdTTL |B|S| Src Mask |Forwarding Code|
	| | |Z| | | |		| | |Z| | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	6.1. Query Arrival Time		5.1. Query Arrival Time
	The Query Arrival Time is a 32-bit NTP timestamp specifying		The Query Arrival Time is a 32-bit NTP timestamp specifying the
	the arrival time of the traceroute request packet at this		arrival time of the traceroute request packet at this router. The
	router. The 32-bit form of an NTP timestamp consists of the		32-bit form of an NTP timestamp consists of the middle 32 bits of
	middle 32 bits of the full 64-bit form; that is, the low 16		the full 64-bit form; that is, the low 16 bits of the integer part
	bits of the integer part and the high 16 bits of the		and the high 16 bits of the fractional part.
	fractional part.
	The following formula converts from a UNIX timeval to a 32-bit		The following formula converts from a UNIX timeval to a 32-bit NTP
	NTP timestamp:		timestamp:
	query_arrival_time = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec		query_arrival_time = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec <<
	<< 10) / 15625)		10) / 15625)
	The constant 32384 is the number of seconds from Jan 1, 1900		The constant 32384 is the number of seconds from Jan 1, 1900 to Jan
	to Jan 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) /		1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a
	15625) is a reduction of ((tv.tv_usec / 100000000) << 16).		reduction of ((tv.tv_usec / 100000000) << 16).
	6.2. Incoming Interface Address		5.2. Incoming Interface Address
	This field specifies the address of the interface on which		This field specifies the address of the interface on which packets
	packets from this source and group are expected to arrive, or		from this source and group are expected to arrive, or 0 if unknown.
	0 if unknown.
	6.3. Outgoing Interface Address		5.3. Outgoing Interface Address
	This field specifies the address of the interface on which		This field specifies the address of the interface on which packets
	packets from this source and group flow to the specified		from this source and group flow to the specified destination, or 0
	destination, or 0 if unknown.		if unknown.
	6.4. Previous-Hop Router Address		5.4. Previous-Hop Router Address
	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 if		packets from this source. This may be a multicast group if the
	the previous hop is not known because of the workings of the		previous hop is not known because of the workings of the multicast
	multicast routing protocol. However, it should be 0 if the		routing protocol. However, it should be 0 if the incoming inter-
	incoming interface address is unknown.		face address is unknown.
	6.5. Input packet count on incoming interface		5.5. Input packet count on incoming interface
	This field contains the number of multicast packets received		This field contains the number of multicast packets received for
	for all groups and sources on the incoming interface, or		all groups and sources on the incoming interface, or 0xffffffff if
	0xffffffff if no count can be reported.		no count can be reported.
	6.6. Output packet count on outgoing interface		5.6. Output packet count on outgoing interface
	This field contains the number of multicast packets that have		This field contains the number of multicast packets that have been
	been transmitted for all groups and sources on the outgoing		transmitted for all groups and sources on the outgoing interface,
	interface, or 0xffffffff if no count can be reported.		or 0xffffffff if no count can be reported.
	6.7. Total number of packets for this source-group pair		5.7. Total number of packets for this source-group pair
	This field counts the number of packets from the specified		This field counts the number of packets from the specified source
	source forwarded by this router to the specified group, or		forwarded by this router to the specified group, or 0xffffffff if
	0xffffffff if no count can be reported. If the S bit is set,		no count can be reported. If the S bit is set, the count is for
	the count is for the source network, as specified by the Src		the source network, as specified by the Src Mask field. If the S
	Mask field. If the S bit is set and the Src Mask field is 63,		bit is set and the Src Mask field is 63, indicating no source-spe-
	indicating no source-specific state, the count is for all		cific state, the count is for all sources sending to this group.
	sources sending to this group.
	6.8. Rtg Protocol: 8 bits		5.8. Rtg Protocol: 8 bits
	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
	6.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.
	6.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.
	6.11. S: 1 bit		5.11. S: 1 bit
	If this bit is set, it indicates that the packet count for the		If this bit is set, it indicates that the packet count for the
	source-group pair is for the source network, as determined by		source-group pair is for the source network, as determined by mask-
	masking the source address with the Src Mask field.		ing the source address with the Src Mask field.
	6.12. Src Mask: 6 bits		5.12. Src Mask: 6 bits
	This field contains the number of 1's in the netmask this		This field contains the number of 1's in the netmask this router
	router has for the source (i.e. a value of 24 means the		has for the source (i.e. a value of 24 means the netmask is
	netmask is 0xffffff00). If the router is forwarding solely on		0xffffff00). If the router is forwarding solely on group state,
	group state, this field is set to 63 (0x2f).		this field is set to 63 (0x3f).
	6.13. Forwarding Code: 8 bits		5.13. Forwarding Code: 8 bits
	This field contains a forwarding information/error code.		This field contains a forwarding information/error code. Defined
	Defined values include:		values include:
	0x00 No error		Value Name Description
	0x01		--------------------------------------------------------------------
	Traceroute request arrived on an interface to		0x00 NO_ERROR No error
			0x01 WRONG_IF Traceroute request arrived on an interface to
	which this router would not forward for this		which this router would not forward for this
	source,group,destination.		source,group,destination.
	0x02		0x02 PRUNE_SENT This router has sent a prune upstream which
	This router has sent a prune upstream which		applies to the source and group in the tracer-
	applies to the source and group in the traceroute		oute request.
	request.
	0x03
	This router has stopped forwarding for this source
	and group in response to a request from the next
	hop router.
	0x04		0x03 PRUNE_RCVD This router has stopped forwarding for this
	The group is subject to administrative scoping at		source and group in response to a request from
	this hop.		the next hop router.
	0x05 This router has no route for the source.		0x04 SCOPED The group is subject to administrative scoping
	0x06 This router is not the proper last-hop router.		at this hop.
	0x07		0x05 NO_ROUTE This router has no route for the source.
	This router is not forwarding this source,group		0x06 WRONG_LAST_HOP This router is not the proper last-hop router.
	for an unspecified reason.		0x07 NOT_FORWARDING This router is not forwarding this
	0x08 Reached Rendez-vous Point or Core		source,group for an unspecified reason.
	0x09		0x08 REACHED_RP Reached Rendez-vous Point or Core
	Traceroute request arrived on the expected RPF		0x09 RPF_IF Traceroute request arrived on the expected RPF
	interface for this source,group.		interface for this source,group.
	0x0A		0x0A NO_MULTICAST Traceroute request arrived on an interface
	Traceroute request arrived on an interface which		which is not enabled for multicast.
	is not enabled for multicast.		0x81 NO_SPACE There was not enough room to insert another
	0x81
	There was not enough room to insert another
	response data block in the packet.		response data block in the packet.
	0x82		0x82 OLD_ROUTER The previous hop router does not understand
	The previous hop router does not understand
	traceroute requests.		traceroute requests.
	0x83 Traceroute is administratively prohibited.		0x83 ADMIN_PROHIB Traceroute is administratively prohibited.
	Note that if a router discovers there is not enough room in a		Note that if a router discovers there is not enough room in a
	packet to insert its response, it puts the 0x81 error code in		packet to insert its response, it puts the 0x81 error code in the
	the previous router's Forwarding Code field, overwriting any		previous router's Forwarding Code field, overwriting any error the
	error the previous router placed there. It is expected that a		previous router placed there. It is expected that a multicast
	multicast traceroute client, upon receiving this error, will		traceroute client, upon receiving this error, will restart the
	restart the trace at the last hop listed in the packet.		trace at the last hop listed in the packet.
	The 0x80 bit of the Forwarding Code is used to indicate a		The 0x80 bit of the Forwarding Code is used to indicate a fatal
	fatal error. A fatal error is one where the router may know		error. A fatal error is one where the router may know the previous
	the previous hop but cannot forward the message to it.		hop but cannot forward the message to it.
	7. Router Behavior		6. Router Behavior
	All of these actions are performed in addition to (NOT instead of)		All of these actions are performed in addition to (NOT instead of) for-
	forwarding the packet, if applicable. E.g. a multicast packet that		warding the packet, if applicable. E.g. a multicast packet that has TTL
	has TTL remaining MUST be forwarded normally, as should a unicast		remaining MUST be forwarded normally, as MUST a unicast packet that has
	packet that has TTL remaining and is not addressed to this router.		TTL remaining and is not addressed to this router.
	7.1. Traceroute Query		6.1. Traceroute Query
	A traceroute Query message is a traceroute message with no		A traceroute Query message is a traceroute message with no response
	response blocks filled in, and uses IGMP type 0x1F.		blocks filled in, and uses IGMP type 0x1F.
	7.1.1. Packet Verification		6.1.1. Packet Verification
	Upon receiving a traceroute Query message, a router must		Upon receiving a traceroute Query message, a router must examine
	examine the Query to see if it is the proper last-hop router		the Query to see if it is the proper last-hop router for the
	for the destination address in the packet. It is the proper		destination address in the packet. It is the proper last-hop
	last-hop router if it has a multicast-capable interface on the		router if it has a multicast-capable interface on the same subnet
	same subnet as the Destination Address and is the router that		as the Destination Address and is the router that would forward
	would forward traffic from the given source onto that subnet.		traffic from the given source onto that subnet.
	A router may receive a traceroute Query message via either		If the router determines that it is not the proper last-hop router,
	unicast or multicast. If received via multicast and it		or it cannot make that determination, it does one of two things
	determines that it is not the proper last-hop router, the		depending if the Query was received via multicast or unicast. If
	packet MUST be silently dropped. If received via unicast and		the Query was received via multicast, then it MUST be silently
	the packet was addressed to this router, an error code of 0x06		dropped. If it was received via unicast, a forwarding code of
	should be noted and normal processing should occur.		NOT_LAST_HOP is noted and processing continues as in section 7.2.
	Duplicate Query messages as identified by the tuple (IP		Duplicate Query messages as identified by the tuple (IP Source,
	Source, Query ID) SHOULD be ignored.		Query ID) SHOULD be ignored.
	7.1.2. Normal Processing		6.1.2. Normal Processing
	When a router receives a traceroute Query and it determines		When a router receives a traceroute Query and it determines that it
	that it is the proper last-hop router, it treats it like a		is the proper last-hop router, it treats it like a traceroute
	traceroute Request and performs the steps listed under Normal		Request and performs the steps listed in section 7.2.
	Processing of a Traceroute Request, below.
	7.2. Traceroute Request		6.2. Traceroute Request
	A traceroute Request is a traceroute message with some number		A traceroute Request is a traceroute message with some number of
	of response blocks filled in, and also uses IGMP type 0x1F.		response blocks filled in, and also uses IGMP type 0x1F. Routers
	Routers can tell the difference between Queries and Requests		can tell the difference between Queries and Requests by checking
	by checking the length of the packet.		the length of the packet.
	7.2.1. Packet Verification		6.2.1. Packet Verification
	If the traceroute Request is not addressed to this router, or		If the traceroute Request is not addressed to this router, or if
	if the Request is addressed to a multicast group which is not		the Request is addressed to a multicast group which is not a link-
	a link-scoped group (e.g. 224.0.0.x), it MUST be silently		scoped group (e.g. 224.0.0.x), it MUST be silently ignored.
	ignored.
	7.2.2. Normal Processing		6.2.2. Normal Processing
	When a router receives a traceroute Request, it performs the		When a router receives a traceroute Request, it performs the fol-
	following steps. Note that it is possible to have multiple		lowing steps. Note that it is possible to have multiple situations
	situations covered by the Forwarding Codes. The first one		covered by the Forwarding Codes. The first one encountered is the
	encountered is the one that is reported, i.e. all "note		one that is reported, i.e. all "note forwarding code N" should be
	forwarding code N" should be interpreted as "if forwarding		interpreted as "if forwarding code is not already set, set forward-
	code is not already set, set forwarding code to N".		ing code to N".
	1. Insert a new response block into the packet and fill in		1. Insert a new response block into the packet and fill in the
	the Query Arrival Time, Outgoing Interface Address,		Query Arrival Time, Outgoing Interface Address, Output Packet
	Output Packet Count, and FwdTTL.		Count, and FwdTTL.
	2. Attempt to determine the forwarding information for the		2. Attempt to determine the forwarding information for the source
	source and group specified, using the same mechanisms as		and group specified, using the same mechanisms as would be used
	would be used when a packet is received from the source		when a packet is received from the source destined for the
	destined for the group. State need not be instantiated,		group. State need not be instantiated, it can be "phantom"
	it can be "phantom" state created only for the purpose of		state created only for the purpose of the trace.
	the trace.
	3. If no forwarding information can be determined, an error		3. If no forwarding information can be determined, an error code
	code of 0x05 is inserted in the Forwarding Code field,		of NO_ROUTE is inserted in the Forwarding Code field, the
	the remaining fields that have not yet been filled in are		remaining fields that have not yet been filled in are set to
	set to zero, and the packet is forwarded to the requester		zero, and the packet is forwarded to the requester as described
			in "Forwarding Traceroute Requests".
			4. Fill in the Incoming Interface Address, Previous-Hop Router
			Address, Input Packet Count, Total Number of Packets, Routing
			Protocol, S, and Src Mask from the forwarding information that
			was determined.
			5. If traceroute is administratively prohibited or the previous
			hop router does not understand traceroute requests, note the
			appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If
			traceroute is administratively prohibited and any of the fields
			as filled in step 4 are considered private information, zero
			out the applicable fields. Then the packet is forwarded to the
			requester as described in "Forwarding Traceroute Requests".
			6. If the reception interface is not enabled for multicast, note
			forwarding code NO_MULTICAST. If the reception interface is
			the interface from which the router would expect data to arrive
			from the source, a forwarding code of RPF_IF is noted. Other-
			wise, if the reception interface is not one to which the router
			would forward data from the source, a forwarding code of
			WRONG_IF is noted.
			7. If the group is subject to administrative scoping on either the
			Outgoing or Incoming interfaces, a forwarding code of SCOPED is
			noted.
			8. If this router is the Rendez-vous Point or Core for the group,
			a forwarding code of REACHED_RP is noted.
			9. If this router has sent a prune upstream which applies to the
			source and group in the traceroute Request, it notes forwarding
			code PRUNE_SENT. If the router has stopped forwarding down-
			stream in response to a prune sent by the next hop router, it
			notes forwarding code PRUNE_RCVD. If the router should nor-
			mally forward traffic for this source and group downstream but
			is not, it notes forwarding code NOT_FORWARDING.
			10. The packet is then sent on to the previous hop or the requester
	as described in "Forwarding Traceroute Requests".		as described in "Forwarding Traceroute Requests".
	4. Fill in the Incoming Interface Address, Previous-Hop		6.3. Traceroute response
	Router Address, Input Packet Count, Total Number of
	Packets, Routing Protocol, S, and Src Mask from the
	forwarding information that was determined.
	5. If traceroute is administratively prohibited or the		A router must forward all traceroute response packets normally,
	previous hop router does not understand traceroute		with no special processing. If a router has initiated a traceroute
	requests, note the appropriate forwarding code. If		with a Query or Request message, it may listen for Responses to
	traceroute is administratively prohibited and any of the		that traceroute but MUST still forward them as well.
	fields as filled in step 4 is considered private
	information, zero out the applicable fields. Then the
	packet is forwarded to the requester as described in
	"Forwarding Traceroute Requests".
	6. If the reception interface is not enabled for multicast,		6.4. Forwarding Traceroute Requests
	note forwarding code 0xA. If the reception interface is
	the interface from which the router would expect data to
	arrive from the source, a forwarding code of 0x9 is
	noted. Otherwise, if the reception interface is not one
	to which the router would forward data from the source, a
	forwarding code of 0x1 is noted.
	7. If the group is subject to administrative scoping on		If the Previous-hop router is known for the source and group (or,
	either the Outgoing or Incoming interfaces, a forwarding		if no group is specified, the previous-hop router for the source,
	code of 0x4 is noted.		or if no source is specified, the previous-hop router for the
			group) and the number of response blocks is less than the number
			requested, the packet is sent to that router. If the Incoming
			Interface is known but the Previous-hop router is not known, the
			packet is sent to an appropriate multicast address on the Incoming
			Interface. The appropriate multicast address may depend on the
			routing protocol in use, MUST be a link-scoped group (i.e.
			224.0.0.x), MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) and may
			be ALL-ROUTERS.MCAST.NET (224.0.0.2) if the routing protocol in use
			does not define a more appropriate group. Otherwise, it is sent to
			the Response Address in the header, as described in "Sending
			Traceroute Responses".
	8. If this router is the Rendez-vous Point or Core for the		6.5. Sending Traceroute Responses
	group, a forwarding code of 0x8 is noted. (NOTE: should
	this be earlier?)
	9. If this router has sent a prune upstream which applies to		6.5.1. Destination Address
	the source and group in the traceroute Request, it notes
	forwarding code 0x2. If the router has stopped
	forwarding downstream in response to a prune sent by the
	next hop router, it notes forwarding code 0x3. If the
	router should normally forward traffic for this source
	and group downstream but is not, it notes forwarding code
	0x7.
	10. The packet is then sent on to the previous hop or the		A traceroute response must be sent to the Response Address in the
	requester as described in "Forwarding Traceroute		traceroute header.
	Requests".
	7.3. Traceroute response		6.5.2. TTL
	A router must forward all traceroute response packets		If the Response Address is unicast, the router inserts its normal
	normally, with no special processing. If a router has		unicast TTL in the IP header. If the Response Address is multi-
	initiated a traceroute with a Query or Request message, it may		cast, the router copies the Response TTL from the traceroute header
	listen for Responses to that traceroute but MUST still forward		into the IP header.
	them as well.
	7.4. Forwarding Traceroute Requests		6.5.3. Source Address
	If the Previous-hop router is known for the source and group		If the Response Address is unicast, the router may use any of its
	(or, if no group is specified, the previous-hop router for the		interface addresses as the source address. Since some multicast
	source, or if no source is specified, the previous-hop router		routing protocols forward based on source address, if the Response
	for the group) and the number of response blocks is less than		Address is multicast, the router MUST use an address that is known
	the number requested, the packet is sent to that router. If		in the multicast routing table if it can make that determination.
	the Incoming Interface is known but the Previous-hop router is
	not known, the packet is sent to an appropriate multicast
	address on the Incoming Interface. The appropriate multicast
	address may depend on the routing protocol in use, MUST be a
	link-scoped group (i.e. 224.0.0.x), MUST NOT be ALL-
	SYSTEMS.MCAST.NET (224.0.0.1) and may be ALL-ROUTERS.MCAST.NET
	(224.0.0.2) if the routing protocol in use does not define a
	more appropriate group. Otherwise, it is sent to the Response
	Address in the header, as described in "Sending Traceroute
	Responses".
	7.5. Sending Traceroute Responses		6.5.4. Sourcing Multicast Responses
	7.5.1. Destination Address		When a router sources a multicast response, the response packet
			MUST be sent on a single interface, then forwarded as if it were
			received on that interface. It MUST NOT source the response packet
			individually on each interface, since that causes duplicate pack-
			ets.
	A traceroute response must be sent to the Response Address in		7. Using multicast traceroute
	the traceroute header.
	7.5.2. TTL		7.1. Sample Client
	If the Response Address is unicast, the router inserts its		This section describes the behavior of an example multicast traceroute
	normal unicast TTL in the IP header. If the Response Address		client.
	is multicast, the router copies the Response TTL from the
	traceroute header into the IP header.
	7.5.3. Source Address		7.1.1. Sending Initial Query
	If the Response Address is unicast, the router may use any of		When the destination of the trace is the machine running the
	its interface addresses as the source address. Since some		client, the traceroute Query packet can be sent to the ALL-ROUTERS
	multicast routing protocols forward based on source address,		multicast group (224.0.0.2). This will ensure that the packet is
	if the Response Address is multicast, the router MUST use an		received by the last-hop router on the subnet. Otherwise, if the
	address that is known in the multicast routing table if it can		proper last-hop router is known for the trace destination, the
	make that determination.		Query could be unicasted to that router. Otherwise, the Query
			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
			Query to the proper last-hop router. In this final case, the
			packet should contain the Router Alert option, to make sure that
			routers that are not members of the multicast group notice the
			packet. See also section 8.2 on determining the last-hop router.
	7.5.4. Sourcing Multicast Responses		7.1.2. Determining the Path
	When a router sources a multicast response, the response		The client could send a small number of Initial Query messages with
	packet MUST be sent on a single interface, then forwarded as		a large "# hops" field, in order to try to trace the full path. If
	if it were received on that interface. It MUST NOT source the		this attempt fails, one strategy is to perform a linear search (as
	response packet individually on each interface, since that		the traditional unicast traceroute program does); set the "#hops"
	causes duplicate packets.		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
			past the non-responding hop, in the hopes that further hops may
			respond. These attempts should continue until a user-defined time-
			out has occurred.
	8. Using multicast traceroute		See also section 8.3 and 8.4 on receiving the results of a trace.
	<<Need a section on expected client behavior (one or two attempts		7.1.3. Collecting Statistics
	with high hop count, then a search of some kind, then statistics
	later)>> Several problems may arise when attempting to use
	multicast traceroute.
	8.1. Last hop router		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
			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-
			played as described in section 9.3 and 9.4.
	The traceroute querier may not know which is the last hop		Details of performing a multicast traceroute:
	router, or that router may be behind a firewall that blocks
	unicast packets but passes multicast packets. In these cases,		7.2. Last hop router
	the traceroute request should be multicasted to the group
	being traced (since the last hop router listens to that		The traceroute querier may not know which is the last hop router,
	group). All routers except the correct last hop router should		or that router may be behind a firewall that blocks unicast packets
	ignore any multicast traceroute request received via		but passes multicast packets. In these cases, the traceroute
	multicast. Traceroute requests which are multicasted to the		request should be multicasted to the group being traced (since the
	group being traced must include the Router Alert IP option		last hop router listens to that group). All routers except the
	[Katz97].		correct last hop router should ignore any multicast traceroute
			request received via multicast. Traceroute requests which are mul-
			ticasted to the group being traced must include the Router Alert IP
			option [Katz97].
	Another alternative is to unicast to the trace destination.		Another alternative is to unicast to the trace destination.
	Traceroute requests which are unicasted to the trace		Traceroute requests which are unicasted to the trace destination
	destination must include the Router Alert IP option [Katz97],		must include the Router Alert IP option [Katz97], in order that the
	in order that the last-hop router is aware of the packet.		last-hop router is aware of the packet.
	If the traceroute querier is attached to the same router as		If the traceroute querier is attached to the same router as the
	the destination of the request, the traceroute request may be		destination of the request, the traceroute request may be multicas-
	multicasted to 224.0.0.2 (ALL-ROUTERS.MCAST.NET) if the last-		ted to 224.0.0.2 (ALL-ROUTERS.MCAST.NET) if the last-hop router is
	hop router is not known.		not known.
	8.2. First hop router		7.3. First hop router
	The traceroute querier may not be unicast reachable from the		The traceroute querier may not be unicast reachable from the first
	first hop router. In this case, the querier should set the		hop router. In this case, the querier should set the traceroute
	traceroute response address to a multicast address, and should		response address to a multicast address, and should set the
	set the response TTL to a value sufficient for the response		response TTL to a value sufficient for the response from the first
	from the first hop router to reach the querier. It may be		hop router to reach the querier. It may be appropriate to start
	appropriate to start with a small TTL and increase in		with a small TTL and increase in subsequent attempts until a suffi-
	subsequent attempts until a sufficient TTL is reached, up to		cient TTL is reached, up to an appropriate maximum (such as 192).
	an appropriate maximum (such as 192).
	The IANA has assigned 224.0.1.32, MTRACE.MCAST.NET, as the		The IANA has assigned 224.0.1.32, MTRACE.MCAST.NET, as the default
	default multicast group for multicast traceroute responses.		multicast group for multicast traceroute responses. Other groups
	Other groups may be used if needed, e.g. when using mtrace to		may be used if needed, e.g. when using mtrace to diagnose problems
	diagnose problems with the IANA-assigned group.		with the IANA-assigned group.
	8.3. Broken intermediate router		7.4. Broken intermediate router
	A broken intermediate router might simply not understand		A broken intermediate router might simply not understand traceroute
	traceroute packets, and drop them. The querier would then get		packets, and drop them. The querier would then get no response at
	no response at all from its traceroute requests. It should		all from its traceroute requests. It should then perform a hop-by-
	then perform a hop-by-hop search by setting the number of		hop search by setting the number of responses field until it gets a
	responses field until it gets a response (both linear and		response (both linear and binary search are options, but binary is
	binary search are options, but binary is likely to be slower		likely to be slower because a failure requires waiting for a time-
	because a failure requires waiting for a timeout).		out).
	8.4. Trace termination		7.5. Trace termination
	When performing an expanding hop-by-hop trace, it is necessary		When performing an expanding hop-by-hop trace, it is necessary to
	to determine when to stop expanding.		determine when to stop expanding.
	8.4.1. Arriving at source		7.5.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-		Incoming Interface of the last router in the trace is non-zero, but
	zero, but the Previous Hop router is zero. (XXX Need to		the Previous Hop router is zero.
	actually check if this heuristic really works) <<Maybe a
	"previous hop" of 0xffffffff needs to mean "arrived at
	source">> <<or just a forwarding code>>
	8.4.2. Fatal Error		7.5.2. Fatal Error
	A trace has encountered a fatal error if the last Forwarding		A trace has encountered a fatal error if the last Forwarding Error
	Error in the trace has the 0x80 bit set.		in the trace has the 0x80 bit set.
	8.4.3. No Previous Hop		7.5.3. No Previous Hop
	A trace can not continue if the last Previous Hop in the trace		A trace can not continue if the last Previous Hop in the trace is
	is set to 0.		set to 0.
	9. Problem Diagnosis		7.5.4. Trace shorter than requested
	9.1. Forwarding Inconsistencies		If the trace that is returned is shorter than requested (i.e. the
			number of Response blocks is smaller than the "# hops" field), the
			trace encountered an error and could not continue.
			7.6. Continuing after an error
			When the NO_SPACE error occurs, the client might try to continue
			the trace by starting it at the last hop in the trace. It can do
			this by unicasting to this router's outgoing interface address,
			keeping all fields the same. If this results in a single hop and a
			"WRONG_IF" error, the client may try setting the trace destination
			to the same outgoing interface address.
			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
			router's address will be in the Previous Hop field of the last
			entry in the last reply packet received. A client may be able to
			determine (via mrinfo[Pusa98] or SNMP[Thal98a,Thal98b]) a list of
			neighbors of the non-responding router. If desired, each of those
			neighbors could be probed to determine the remainder of the path.
			Unfortunately, this heuristic may end up with multiple paths, since
			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
			but one flow back towards the non-responding router, it is possible
			to be sure that this is the correct path.
			7.7. Multicast Traceroute and shared-tree routing protocols
			When using shared-tree routing protocols like PIM-SM and CBT, it is
			still possible to use multicast traceroute to determine paths.
			7.7.1. PIM-SM
			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-
			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
			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
			unicasted to the RP.
			7.7.2. CBT
			When a multicast traceroute reaches a CBT Core, it must simply stop
			since CBT does not have source-specific state. However, a second trace
			can be performed, setting the trace destination to the traffic source,
			the trace group to the group being traced, and the trace source to the
			Core (or to 0, since CBT does not have source-specific state). This
			trace Query may be unicasted to the Core. There are two possibilities
			when combining the two traces:
			7.7.2.1. No overlap
			If there is no overlap between the two traces, the second trace can
			be reversed and appended to the first trace. This composite trace
			shows the full path from the source to the destination.
			7.7.2.2. Overlapping paths
			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
			the no overlap case, the second trace is reversed and appended to
			the first trace, and the composite trace again contains the full
			path.
			This algorithm works whether the source has joined the CBT tree or not.
			8. Problem Diagnosis
			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.
	9.2. TTL problems		8.2. TTL problems
	By taking the maximum of (hops from source + forwarding TTL		By taking the maximum of (hops from source + forwarding TTL thresh-
	threshold) over all hops, you can discover the TTL required		old) over all hops, you can discover the TTL required for the
	for the source to reach the destination.		source to reach the destination.
	9.3. Congestion		8.3. Congestion
	By taking two traces, you can find packet loss information by		By taking two traces, you can find packet loss information by com-
	comparing the difference in input packet counts to the		paring the difference in input packet counts to the difference in
	difference in output packet counts at the previous hop. On a		output packet counts at the previous hop. On a point-to-point
	point-to-point link, any difference in these numbers implies		link, any difference in these numbers implies packet loss. Since
	packet loss. Since the packet counts may be changing as the		the packet counts may be changing as the trace query is propagat-
	trace query is propagating, there may be small errors (off by		ing, there may be small errors (off by 1 or 2) in these statistics.
	1 or 2) in these statistics. However, these errors will not		However, these errors will not accumulate if multiple traces are
	accumulate if multiple traces are taken to expand the		taken to expand the measurement period. On a shared link, the
	measurement period. On a shared link, the count of input		count of input packets can be larger than the number of output
	packets can be larger than the number of output packets at the		packets at the previous hop, due to other routers or hosts on the
	previous hop, due to other routers or hosts on the link		link injecting packets. This appears as "negative loss" which may
	injecting packets. This appears as "negative loss" which may
	mask real packet loss.		mask real packet loss.
	In addition to the counts of input and output packets for all		In addition to the counts of input and output packets for all mul-
	multicast traffic on the interfaces, the response data		ticast traffic on the interfaces, the response data includes a
	includes a count of the packets forwarded by a node for the		count of the packets forwarded by a node for the specified source-
	specified source-group pair. Taking the difference in this		group pair. Taking the difference in this count between two traces
	count between two traces and then comparing those differences		and then comparing those differences between two hops gives a mea-
	between two hops gives a measure of packet loss just for		sure of packet loss just for traffic from the specified source to
	traffic from the specified source to the specified receiver		the specified receiver via the specified group. This measure is
	via the specified group. This measure is not affected by		not affected by shared links.
	shared links.
	On a point-to-point link that is a multicast tunnel, packet		On a point-to-point link that is a multicast tunnel, packet loss is
	loss is usually due to congestion in unicast routers along the		usually due to congestion in unicast routers along the path of that
	path of that tunnel. On native multicast links, loss is more		tunnel. On native multicast links, loss is more likely in the out-
	likely in the output queue of one hop, perhaps due to priority		put queue of one hop, perhaps due to priority dropping, or in the
	dropping, or in the input queue at the next hop. The counters		input queue at the next hop. The counters in the response data do
	in the response data do not allow these cases to be		not allow these cases to be distinguished. Differences in packet
	distinguished. Differences in packet counts between the		counts between the incoming and outgoing interfaces on one node
	incoming and outgoing interfaces on one node cannot generally		cannot generally be used to measure queue overflow in the node
	be used to measure queue overflow in the node because some		because some packets may be routed only to or from other interfaces
	packets may be routed only to or from other interfaces on that		on that node.
	node.
	In the multicast extensions for SunOS 4.1.x from Xerox PARC,		In the multicast extensions for SunOS 4.1.x from Xerox PARC, both
	both the output packet count and the packet forwarding count		the output packet count and the packet forwarding count for the
	for the source-group pair are incremented before priority		source-group pair are incremented before priority dropping for rate
	dropping for rate limiting occurs and before the packets are		limiting occurs and before the packets are put onto the interface
	put onto the interface output queue which may overflow. These		output queue which may overflow. These drops will appear as (posi-
	drops will appear as (positive) loss on the link even though		tive) loss on the link even though they occur within the router.
	they occur within the router.
	In release 3.3/3.4 of the UNIX multicast extensions, a		In release 3.3/3.4 of the UNIX multicast extensions, a multicast
	multicast packet generated on a router will be counted as		packet generated on a router will be counted as having come in an
	having come in an interface even though it did not. This can		interface even though it did not. This can create the appearance
	create the appearance of negative loss even on a point-to-		of negative loss even on a point-to-point link.
	point link.
	In releases up through 3.5/3.6, packets were not counted as		In releases up through 3.5/3.6, packets were not counted as input
	input on an interface if the reverse-path forwarding check		on an interface if the reverse-path forwarding check decided that
	decided that the packets should be dropped. That causes the		the packets should be dropped. That causes the packets to appear
	packets to appear as lost on the link if they were output by		as lost on the link if they were output by the upstream hop. This
	the upstream hop. This situation can arise when two routers		situation can arise when two routers on the path for the group
	on the path for the group being traced are connected by a		being traced are connected by a shared link, and the path for some
	shared link, and the path for some other group does not flow		other group does not flow between those two routers because the
	between those two routers because the downstream router		downstream router receives packets for the other group on another
	receives packets for the other group on another interface, but		interface, but the upstream router is the elected forwarder to
	the upstream router is the elected forwarder to other routers		other routers or hosts on the shared link.
	or hosts on the shared link.
	9.4. Link Utilization		8.4. Link Utilization
	Again, with two traces, you can divide the difference in the		Again, with two traces, you can divide the difference in the input
	input or output packet counts at some hop by the difference in		or output packet counts at some hop by the difference in time
	time stamps from the same hop to obtain the packet rate over		stamps from the same hop to obtain the packet rate over the link.
	the link. If the average packet size is known, then the link		If the average packet size is known, then the link utilization can
	utilization can also be estimated to see whether packet loss		also be estimated to see whether packet loss may be due to the rate
	may be due to the rate limit or the physical capacity on a		limit or the physical capacity on a particular link being exceeded.
	particular link being exceeded.
	9.5. Time delay		8.5. Time delay
	If the routers have synchronized clocks, it is possible to		If the routers have synchronized clocks, it is possible to estimate
	estimate propagation and queueing delay from the differences		propagation and queueing delay from the differences between the
	between the timestamps at successive hops.		timestamps at successive hops.
	10. Acknowledgments		9. Acknowledgments
	This specification started largely as a transcription of Van		This specification started largely as a transcription of Van Jacobson's
	Jacobson's slides from the 30th IETF, and the implementation in		slides from the 30th IETF, and the implementation in mrouted 3.3 by Ajit
	mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit		Thyagarajan. Van's original slides credit Steve Casner, Steve Deering,
	Steve Casner, Steve Deering, Dino Farinacci and Deb Agrawal. A		Dino Farinacci and Deb Agrawal. A multicast traceroute client, mtrace,
	multicast traceroute client, mtrace, has been implemented by Ajit
	Thyagarajan, Steve Casner and Bill Fenner.
	The idea of unicasting a multicast traceroute Query to the		has been implemented by Ajit Thyagarajan, Steve Casner and Bill Fenner.
	destination of the trace with RA set is due to Tony Ballardie. The
	idea of the "S" bit to allow statistics for a source subnet is due
	to Tom Pusateri.
	11. IANA Considerations		The idea of unicasting a multicast traceroute Query to the destination
			of the trace with Router Alert set is due to Tony Ballardie. The idea
			of the "S" bit to allow statistics for a source subnet is due to Tom
			Pusateri.
	11.1. Routing Protocols		10. IANA Considerations
	Should the IANA be responsible for allocating new Routing		10.1. Routing Protocols
	Protocol codes?
	11.2. Forwarding Codes		The IANA is responsible for allocating new Routing Protocol codes.
			The Routing Protocol code is somewhat problematic, since in the
			case of protocols like CBT and PIM it must encode both a unicast
			routing algorithm and a multicast tree-building protocol. The
			space was not divided into two fields because it was already small
			and some combinations (e.g. DVMRP) would be wasted.
	Should the IANA be responsible for allocating new Forwarding		Routing Protocol codes should be allocated for any combination of
	Codes?		protocols that are in common use in the Internet.
	12. Security Considerations		10.2. Forwarding Codes
	12.1. Topology discovery		New Forwarding codes must only be created by an RFC that modifies
			this document's section 7, fully describing the conditions under
			which the new forwarding code is used. The IANA may act as a cen-
			tral repository so that there is a single place to look up forward-
			ing codes and the document in which they are defined.
	mtrace can be used to discover any actively-used topology. If		11. Security Considerations
	your network topology is a secret, you should restrict mtrace
	at the border of your domain.
	12.2. Traffic rates		11.1. Topology discovery
	mtrace can be used to discover what sources are sending to		mtrace can be used to discover any actively-used topology. If your
	what groups and at what rates. If this information is a		network topology is a secret, mtrace may be restricted at the bor-
	secret, you should restrict mtrace at the border of your		der of your domain, using the ADMIN_PROHIB forwarding code.
	domain.
	...more...		11.2. Traffic rates
	13. References		mtrace can be used to discover what sources are sending to what
			groups and at what rates. If this information is a secret, mtrace
			may be restricted at the border of your domain, using the
			ADMIN_PROHIB forwarding code.
			11.3. Unicast replies
			The "Response address" field may be used to send a single packet
			(the traceroute Reply packet) to an arbitrary unicast address. It
			is possible to use this facility as a packet amplifier, as a small
			multicast traceroute Query may turn into a large Reply packet.
			12. References
			Brad88 Braden, B., D. Borman, C. Partridge, "Computing the
			Internet Checksum", RFC 1071, ISI, September 1988.
	Bradner97 Bradner, S., "Key words for use in RFCs to Indicate		Bradner97 Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119/BCP 14, Harvard		Requirement Levels", RFC 2119/BCP 14, Harvard University,
	University, March 1997.		March 1997.
	Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco		Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco Sys-
	Systems, February 1997.		tems, February 1997.
	14. Authors' Addresses		13. Authors' Addresses
	William C. Fenner		William C. Fenner
	Xerox PARC		Xerox PARC
	3333 Coyote Hill Road		3333 Coyote Hill Road
	Palo Alto, CA 94304		Palo Alto, CA 94304
	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
	Precept Software, Inc.		Cisco Systems
	1072 Arastradero Road		1072 Arastradero Road
	Palo Alto, CA 94304		Palo Alto, CA 94304
	Email: casner@precept.com		Email: casner@precept.com
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/