draft-ietf-idmr-traceroute-ipm-05.txt   draft-ietf-idmr-traceroute-ipm-06.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-05.txt AT&T Research draft-ietf-idmr-traceroute-ipm-06.txt AT&T Research
S. Casner S. Casner
Cisco Systems Cisco Systems
June 25, 1999 March 10, 2000
Expires December 1999 Expires August 2000
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 and is in full conformance with all This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet Drafts are working docu- 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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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.
the deployment of IP multicast has spread, it has become clear that
a method for tracing the route that a multicast IP packet takes
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 speci- packet type and implementation on the part of routers. This speci-
fication describes the required functionality. fication describes the required functionality in multicast routers,
as well as how management applications can use the new router func-
tionality.
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).
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 7, line 24 skipping to change at page 7, line 24
if unknown. if unknown.
5.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 the packets from this source. This may be a multicast group if the
previous hop is not known because of the workings of the multicast previous hop is not known because of the workings of the multicast
routing protocol. However, it should be 0 if the incoming inter- routing protocol. However, it should be 0 if the incoming inter-
face address is unknown. face address is unknown.
5.5. Input packet count on incoming interface 5.5. Packet counts
Note that these packet counts SHOULD be as up to date as possible.
If packet counts are not being maintained on the processor that
handles the traceroute request in a multi-processor router archi-
tecture, the packet SHOULD be delayed while the counters are gath-
ered from the remote processor(s). If this occurs, the Query
Arrival Time should be updated to reflect the time at which the
packet counts were learned.
5.6. Input packet count on incoming interface
This field contains the number of multicast packets received for This field contains the number of multicast packets received for
all groups and sources on the incoming interface, or 0xffffffff if all groups and sources on the incoming interface, or 0xffffffff if
no count can be reported. no count can be reported. This counter should have the same value
as ifInMulticastPkts from the IF-MIB for this interface.
5.6. Output packet count on outgoing interface 5.7. Output packet count on outgoing interface
This field contains the number of multicast packets that have been This field contains the number of multicast packets that have been
transmitted for all groups and sources on the outgoing interface, transmitted or queued for transmission for all groups and sources
or 0xffffffff if no count can be reported. on the outgoing interface, or 0xffffffff if no count can be
reported. This counter should have the same value as ifOutMulti-
castPkts from the IF-MIB for this interface.
5.7. Total number of packets for this source-group pair 5.8. 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 0xffffffff if forwarded by this router to the specified group, or 0xffffffff if
no count can be reported. If the S bit is set, the count is for no 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 the 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-spe- bit is set and the Src Mask field is 63, indicating no source-spe-
cific state, the count is for all sources sending to this group. cific state, the count is for all sources sending to this group.
This counter should have the same value as ipMRoutePkts from the
IPMROUTE-STD-MIB for this forwarding entry.
5.8. Rtg Protocol: 8 bits 5.9. 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 l l. 1 DVMRP 2 MOSPF 3 PIM 4 CBT 5 PIM using spe-
2 MOSPF cial routing table 6 PIM using a static route 7 DVMRP using a
3 PIM static route 8 PIM using MBGP (aka BGP4+) route 9 CBT using
4 CBT special routing table 10 CBT using a static route 11 PIM using
5 PIM using special routing table state created by Assert processing
6 PIM 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.10. 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.11. MBZ: 1 bit
Must be zeroed on transmission and ignored on reception. Must be zeroed on transmission and ignored on reception.
5.11. S: 1 bit 5.12. 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 mask- source-group pair is for the source network, as determined by mask-
ing the source address with the Src Mask field. ing the source address with the Src Mask field.
5.12. Src Mask: 6 bits 5.13. Src Mask: 6 bits
This field contains the number of 1's in the netmask this router 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 has for the source (i.e. a value of 24 means the netmask is
0xffffff00). If the router is forwarding solely on group state, 0xffffff00). If the router is forwarding solely on group state,
this field is set to 63 (0x3f). this field is set to 63 (0x3f).
5.13. Forwarding Code: 8 bits 5.14. Forwarding Code: 8 bits
This field contains a forwarding information/error code. Defined This field contains a forwarding information/error code. Defined
values include: values include:
Value Name Description expand; l l lw(3i) . Value Name Description _
-------------------------------------------------------------------- 0x00 NO_ERROR No error 0x01 WRONG_IF T{ Traceroute request
0x00 NO_ERROR No error arrived on an interface to which this router would not forward for
0x01 WRONG_IF Traceroute request arrived on an interface to this source,group,destination. T} 0x02 PRUNE_SENT T{ This
which this router would not forward for this router has sent a prune upstream which applies to the source and
source,group,destination. group in the traceroute request. T} 0x03 PRUNE_RCVD T{ This
router has stopped forwarding for this source and group in response
0x02 PRUNE_SENT This router has sent a prune upstream which to a request from the next hop router. T} 0x04 SCOPED T{ The
applies to the source and group in the tracer- group is subject to administrative scoping at this hop. T}
oute request. 0x05 NO_ROUTE T{ This router has no route for the source or group
0x03 PRUNE_RCVD This router has stopped forwarding for this and no way to determine a potential route. T}
source and group in response to a request from
the next hop router.
0x04 SCOPED The group is subject to administrative scoping
at this hop.
0x05 NO_ROUTE This router has no route for the source or
group and no way to determine a potential
route.
0x06 WRONG_LAST_HOP This router is not the proper last-hop router. 0x06 WRONG_LAST_HOP This router is not the proper last-hop router.
0x07 NOT_FORWARDING This router is not forwarding this 0x07 NOT_FORWARDING T{ This router is not forwarding this
source,group out the outgoing interface for an source,group out the outgoing interface for an unspecified reason.
unspecified reason. T} 0x08 REACHED_RP Reached Rendez-vous Point or Core
0x08 REACHED_RP Reached Rendez-vous Point or Core 0x09 RPF_IF T{ Traceroute request arrived on the expected RPF
0x09 RPF_IF Traceroute request arrived on the expected RPF interface for this source,group. T} 0x0A NO_MULTICAST T{ Tracer-
interface for this source,group. oute request arrived on an interface which is not enabled for mul-
0x0A NO_MULTICAST Traceroute request arrived on an interface ticast. T} 0x0B INFO_HIDDEN T{ One or more hops have been hid-
which is not enabled for multicast. den from this trace. T} 0x81 NO_SPACE T{ There was not enough
0x0B INFO_HIDDEN One or more hops have been hidden from this room to insert another response data block in the packet. T}
trace. 0x82 OLD_ROUTER T{ The previous hop router does not understand
0x81 NO_SPACE There was not enough room to insert another traceroute requests. T} 0x83 ADMIN_PROHIB Traceroute is adminis-
response data block in the packet. tratively prohibited.
0x82 OLD_ROUTER The previous hop router does not understand
traceroute requests.
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 the packet to insert its response, it puts the 0x81 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. It is expected that a multicast previous router placed there. A multicast traceroute client, upon
traceroute client, upon receiving this error, will restart the receiving this error, MAY restart the trace at the last hop listed
trace at the last hop listed in the packet. in the packet.
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.
6. Router Behavior 6. Router Behavior
All of these actions are performed in addition to (NOT instead of) for- All of these actions are performed in addition to (NOT instead of) for-
warding the packet, if applicable. E.g. a multicast packet that has TTL warding the packet, if applicable. E.g. a multicast packet that has TTL
remaining MUST be forwarded normally, as MUST a unicast packet that has remaining MUST be forwarded normally, as MUST a unicast packet that has
skipping to change at page 10, line 27 skipping to change at page 10, line 22
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
WRONG_LAST_HOP is noted and processing continues as in section 6.2. WRONG_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. This MAY be implemented using a sim-
ple 1-back cache (i.e. remembering the IP source and Query ID of
the previous Query message that was processed, and ignoring future
messages with the same IP Source and Query ID). Duplicate Request
messages MUST NOT be ignored in this manner.
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 6.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
skipping to change at page 11, line 8 skipping to change at page 11, line 7
6.2.2. Normal Processing 6.2.2. Normal Processing
When a router receives a traceroute Request, it performs the fol- When a router receives a traceroute Request, it performs the fol-
lowing steps. Note that it is possible to have multiple situations lowing steps. Note that it is possible to have multiple situations
covered by the Forwarding Codes. The first one encountered is the covered by the Forwarding Codes. The first one encountered is the
one that is reported, i.e. all "note forwarding code N" should be one that is reported, i.e. all "note forwarding code N" should be
interpreted as "if forwarding code is not already set, set forward- interpreted as "if forwarding code is not already set, set forward-
ing code to N". ing code to N".
1. Insert a new response block into the packet and fill in the 1. If there is room in the current buffer (or the router can effi-
Query Arrival Time, Outgoing Interface Address, Output Packet ciently allocate more space to use), insert a new response
Count, and FwdTTL. block into the packet and fill in the Query Arrival Time, Out-
going Interface Address, Output Packet Count, and FwdTTL. If
there was no room, fill in the response code "NO_SPACE" in the
*previous* hop's response block, and forward the packet to the
requester as described in "Forwarding Traceroute Requests".
2. Attempt to determine the forwarding information for the source 2. Attempt to determine the forwarding information for the source
and group specified, using the same mechanisms as would be used and group specified, using the same mechanisms as would be used
when a packet is received from the source destined for the when a packet is received from the source destined for the
group. State need not be instantiated, it can be "phantom" group. State need not be instantiated, it can be "phantom"
state created only for the purpose of the trace. state created only for the purpose of the trace.
If using a shared-tree protocol and there is no source-specific If using a shared-tree protocol and there is no source-specific
state, or if the source is specified as 0xFFFFFFFF, group state state, or if the source is specified as 0xFFFFFFFF, group state
should be used. If there is no group state or the group is should be used. If there is no group state or the group is
skipping to change at page 12, line 32 skipping to change at page 12, line 35
6.3. Traceroute response 6.3. Traceroute response
A router must forward all traceroute response packets normally, A router must forward all traceroute response packets normally,
with no special processing. If a router has initiated a traceroute with no special processing. If a router has initiated a traceroute
with a Query or Request message, it may listen for Responses to with a Query or Request message, it may listen for Responses to
that traceroute but MUST still forward them as well. that traceroute but MUST still forward them as well.
6.4. Forwarding Traceroute Requests 6.4. Forwarding Traceroute Requests
If the Previous-hop router is known for the source and group (or, If the Previous-hop router is known for this request and the number
if no group is specified, the previous-hop router for the source, of response blocks is less than the number requested, the packet is
or if no source is specified, the previous-hop router for the sent to that router. If the Incoming Interface is known but the
group) and the number of response blocks is less than the number Previous-hop router is not known, the packet is sent to an appro-
requested, the packet is sent to that router. If the Incoming priate multicast address on the Incoming Interface. The appropri-
Interface is known but the Previous-hop router is not known, the ate multicast address may depend on the routing protocol in use,
packet is sent to an appropriate multicast address on the Incoming MUST be a link-scoped group (i.e. 224.0.0.x), MUST NOT be ALL-SYS-
Interface. The appropriate multicast address may depend on the TEMS.MCAST.NET (224.0.0.1) and MAY be ALL-ROUTERS.MCAST.NET
routing protocol in use, MUST be a link-scoped group (i.e. (224.0.0.2) if the routing protocol in use does not define a more
224.0.0.x), MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) and may appropriate group. Otherwise, it is sent to the Response Address
be ALL-ROUTERS.MCAST.NET (224.0.0.2) if the routing protocol in use in the header, as described in "Sending Traceroute Responses".
does not define a more appropriate group. Otherwise, it is sent to Note that it is not an error for the number of response blocks to
the Response Address in the header, as described in "Sending be greater than the number requested; such a packet should simply
Traceroute Responses". be forwarded to the requester as described in "Sending Traceroute
Responses".
6.5. Sending Traceroute Responses 6.5. Sending Traceroute Responses
6.5.1. Destination Address 6.5.1. Destination Address
A traceroute response must be sent to the Response Address in the A traceroute response must be sent to the Response Address in the
traceroute header. traceroute header.
6.5.2. TTL 6.5.2. TTL
skipping to change at page 13, line 25 skipping to change at page 13, line 32
interface addresses as the source address. Since some multicast interface addresses as the source address. Since some multicast
routing protocols forward based on source address, if the Response routing protocols forward based on source address, if the Response
Address is multicast, the router MUST use an address that is known Address is multicast, the router MUST use an address that is known
in the multicast routing table if it can make that determination. in the multicast routing table if it can make that determination.
6.5.4. Sourcing Multicast Responses 6.5.4. Sourcing Multicast Responses
When a router sources a multicast response, the response packet When a router sources a multicast response, the response packet
MUST be sent on a single interface, then forwarded as if it were MUST be sent on a single interface, then forwarded as if it were
received on that interface. It MUST NOT source the response packet received on that interface. It MUST NOT source the response packet
individually on each interface, since that causes duplicate pack- individually on each interface, in order to avoid duplicate pack-
ets. ets.
6.6. Hiding information 6.6. Hiding information
Information about a domain's topology and connectivity may be hid- Information about a domain's topology and connectivity may be hid-
den from multicast traceroute requests. The exact mechanism is not den from multicast traceroute requests. The exact mechanism is not
specified here; however, the INFO_HIDDEN forwarding code may be specified here; however, the INFO_HIDDEN forwarding code may be
used to note that, for example, the incoming interface address and used to note that, for example, the incoming interface address and
packet count are for the entrance to the domain and the outgoing packet count are for the entrance to the domain and the outgoing
interface address and packet count are the exit from the domain. interface address and packet count are the exit from the domain.
skipping to change at page 14, line 45 skipping to change at page 14, line 52
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
correct last hop router should ignore any multicast traceroute correct last hop router should ignore any multicast traceroute
request received via multicast. Traceroute requests which are mul- request received via multicast. Traceroute requests which are
ticasted to the group being traced must include the Router Alert IP multicasted to the group being traced must include the Router Alert
option [Katz97]. 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 destination Traceroute requests which are unicasted to the trace destination
must include the Router Alert IP option [Katz97], in order that the must include the Router Alert IP option [Katz97], 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 the If the traceroute querier is attached to the same router as the
destination of the request, the traceroute request may be multicas- destination of the request, the traceroute request may be multicas-
ted to 224.0.0.2 (ALL-ROUTERS.MCAST.NET) if the last-hop router is ted to 224.0.0.2 (ALL-ROUTERS.MCAST.NET) if the last-hop router is
not known. not known.
skipping to change at page 16, line 47 skipping to change at page 16, line 52
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, a When using shared-tree routing protocols like PIM-SM and CBT, a
more advanced client may use multicast traceroute to determine more advanced client may use multicast traceroute to determine
paths or potential paths. 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-
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 specific join so there is no more state to trace. However, the path
traced by setting the trace destination to the RP, the trace source to that traffic would use if the RP did perform a source-specific join can
the traffic source, and the trace group to 0. This trace Query may be be traced by setting the trace destination to the RP, the trace source
unicasted to the RP. to the traffic source, and the trace group to 0. This trace Query may
be unicasted to the RP.
7.7.2. CBT 7.7.2. CBT
When a multicast traceroute reaches a CBT Core, it must simply stop When a multicast traceroute reaches a CBT Core, it must simply stop
since CBT does not have source-specific state. However, a second trace since CBT does not have source-specific state. However, a second trace
can be performed, setting the trace destination to the traffic source, 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 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 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 trace Query may be unicasted to the Core. There are two possibilities
when combining the two traces: when combining the two traces:
skipping to change at page 18, line 20 skipping to change at page 18, line 26
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-
old) over all hops, you can discover the TTL required for the old) over all hops, you can discover the TTL required for the
source to reach the destination. source to reach the destination.
8.3. Congestion 8.3. Packet Loss
By taking two traces, you can find packet loss information by com- By taking two traces, you can find packet loss information by com-
paring the difference in input packet counts to the difference in paring the difference in input packet counts to the difference in
output packet counts at the previous hop. On a point-to-point output packet counts at the previous hop. On a point-to-point
link, any difference in these numbers implies packet loss. Since link, any difference in these numbers implies packet loss. Since
the packet counts may be changing as the trace query is propagat- the packet counts may be changing as the trace query is propagat-
ing, there may be small errors (off by 1 or 2) in these statistics. ing, there may be small errors (off by 1 or 2) in these statistics.
However, these errors will not accumulate if multiple traces are However, these errors will not accumulate if multiple traces are
taken to expand the measurement period. On a shared link, the taken to expand the measurement period. On a shared link, the
count of input packets can be larger than the number of output count of input packets can be larger than the number of output
skipping to change at page 18, line 51 skipping to change at page 19, line 9
the specified receiver via the specified group. This measure is the specified receiver via the specified group. This measure is
not affected by shared links. not affected by shared links.
On a point-to-point link that is a multicast tunnel, packet loss is On a point-to-point link that is a multicast tunnel, packet loss is
usually due to congestion in unicast routers along the path of that usually due to congestion in unicast routers along the path of that
tunnel. On native multicast links, loss is more likely in the out- tunnel. On native multicast links, loss is more likely in the out-
put queue of one hop, perhaps due to priority dropping, or in the put queue of one hop, perhaps due to priority dropping, or in the
input queue at the next hop. The counters in the response data do input queue at the next hop. The counters in the response data do
not allow these cases to be distinguished. Differences in packet not allow these cases to be distinguished. Differences in packet
counts between the incoming and outgoing interfaces on one node counts between the incoming and outgoing interfaces on one node
cannot generally be used to measure queue overflow in the node cannot generally be used to measure queue overflow in the node.
because some packets may be routed only to or from other interfaces
on that node.
In the multicast extensions for SunOS 4.1.x from Xerox PARC, both
the output packet count and the packet forwarding count for the
source-group pair are incremented before priority dropping for rate
limiting occurs and before the packets are put onto the interface
output queue which may overflow. These drops will appear as (posi-
tive) loss on the link even though they occur within the router.
In release 3.3/3.4 of the UNIX multicast extensions, a multicast
packet generated on a router will be counted as having come in an
interface even though it did not. This can create the appearance
of negative loss even on a point-to-point link.
In releases up through 3.5/3.6, packets were not counted as input
on an interface if the reverse-path forwarding check decided that
the packets should be dropped. That causes the packets to appear
as lost on the link if they were output by the upstream hop. This
situation can arise when two routers on the path for the group
being traced are connected by a shared link, and the path for some
other group does not flow between those two routers because the
downstream router receives packets for the other group on another
interface, but the upstream router is the elected forwarder to
other routers or hosts on the shared link.
8.4. Link Utilization 8.4. Link Utilization
Again, with two traces, you can divide the difference in the input Again, with two traces, you can divide the difference in the input
or output packet counts at some hop by the difference in time or output packet counts at some hop by the difference in time
stamps from the same hop to obtain the packet rate over the link. stamps from the same hop to obtain the packet rate over the link.
If the average packet size is known, then the link utilization can If the average packet size is known, then the link utilization can
also be estimated to see whether packet loss may be due to the rate also be estimated to see whether packet loss may be due to the rate
limit or the physical capacity on a particular link being exceeded. limit or the physical capacity on a particular link being exceeded.
8.5. Time delay 8.5. Time delay
If the routers have synchronized clocks, it is possible to estimate If the routers have synchronized clocks, it is possible to estimate
propagation and queueing delay from the differences between the propagation and queuing delay from the differences between the
timestamps at successive hops. timestamps at successive hops. However, this delay includes con-
trol processing overhead, so is not necessarily indicative of the
delay that data traffic would experience.
9. Acknowledgments 9. Implementation-specific Caveats
Some routers with distributed forwarding architectures may not update
the main processor's packet counts often enough for the packet counters
to be meaningful on a small time scale. This can be recognized during a
periodic trace by seeing positive loss in one trace and negative loss in
the next, with no (or small) net loss over a longer interval. The sug-
gested solution to this problem is to simply collect statistics over a
longer interval.
In the multicast extensions for SunOS 4.1.x from Xerox PARC, which are
the basis for many UNIX-based multicast routers, both the output packet
count and the packet forwarding count for the source-group pair are
incremented before priority dropping for rate limiting occurs and before
the packets are put onto the interface output queue which may overflow.
These drops will appear as (positive) loss on the link even though they
occur within the router.
In release 3.3/3.4 of the UNIX multicast extensions, a multicast packet
generated on a router will be counted as having come in an interface
even though it did not. This can create the appearance of negative loss
even on a point-to-point link.
In releases up through 3.5/3.6, packets were not counted as input on an
interface if the reverse-path forwarding check decided that the packets
should be dropped. That causes the packets to appear as lost on the
link if they were output by the upstream hop. This situation can arise
when two routers on the path for the group being traced are connected by
a shared link, and the path for some other group does not flow between
those two routers because the downstream router receives packets for the
other group on another interface, but the upstream router is the elected
forwarder to other routers or hosts on the shared link.
10. Acknowledgments
This specification started largely as a transcription of Van Jacobson's This specification started largely as a transcription of Van Jacobson's
slides from the 30th IETF, and the implementation in mrouted 3.3 by Ajit slides from the 30th IETF, and the implementation in mrouted 3.3 by Ajit
Thyagarajan. Van's original slides credit Steve Casner, Steve Deering, Thyagarajan. Van's original slides credit Steve Casner, Steve Deering,
Dino Farinacci and Deb Agrawal. A multicast traceroute client, mtrace, Dino Farinacci and Deb Agrawal. A multicast traceroute client, mtrace,
has been implemented by Ajit Thyagarajan, Steve Casner and Bill Fenner. has been implemented by Ajit Thyagarajan, Steve Casner and Bill Fenner.
The idea of unicasting a multicast traceroute Query to the destination 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 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 of the "S" bit to allow statistics for a source subnet is due to Tom
Pusateri. Pusateri.
10. IANA Considerations 11. IANA Considerations
10.1. Routing Protocols 11.1. Routing Protocols
The IANA is responsible for allocating new Routing Protocol codes. The IANA is responsible for allocating new Routing Protocol codes.
The Routing Protocol code is somewhat problematic, since in the The Routing Protocol code is somewhat problematic, since in the
case of protocols like CBT and PIM it must encode both a unicast case of protocols like CBT and PIM it must encode both a unicast
routing algorithm and a multicast tree-building protocol. The routing algorithm and a multicast tree-building protocol. The
space was not divided into two fields because it was already small space was not divided into two fields because it was already small
and some combinations (e.g. DVMRP) would be wasted. and some combinations (e.g. DVMRP) would be wasted.
Routing Protocol codes should be allocated for any combination of Routing Protocol codes should be allocated for any combination of
protocols that are in common use in the Internet. protocols that are in common use in the Internet.
10.2. Forwarding Codes 11.2. Forwarding Codes
New Forwarding codes must only be created by an RFC that modifies New Forwarding codes must only be created by an RFC that modifies
this document's section 7, fully describing the conditions under this document's section 7, fully describing the conditions under
which the new forwarding code is used. The IANA may act as a cen- 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- tral repository so that there is a single place to look up forward-
ing codes and the document in which they are defined. ing codes and the document in which they are defined.
11. Security Considerations 12. Security Considerations
11.1. Topology discovery 12.1. Topology discovery
mtrace can be used to discover any actively-used topology. If your mtrace can be used to discover any actively-used topology. If your
network topology is a secret, mtrace may be restricted at the bor- network topology is a secret, mtrace may be restricted at the bor-
der of your domain, using the ADMIN_PROHIB forwarding code. der of your domain, using the ADMIN_PROHIB forwarding code.
11.2. Traffic rates 12.2. Traffic rates
mtrace can be used to discover what sources are sending to what mtrace can be used to discover what sources are sending to what
groups and at what rates. If this information is a secret, mtrace groups and at what rates. If this information is a secret, mtrace
may be restricted at the border of your domain, using the may be restricted at the border of your domain, using the
ADMIN_PROHIB forwarding code. ADMIN_PROHIB forwarding code.
11.3. Unicast replies 12.3. Unicast replies
The "Response address" field may be used to send a single packet The "Response address" field may be used to send a single packet
(the traceroute Reply packet) to an arbitrary unicast address. It (the traceroute Reply packet) to an arbitrary unicast address. It
is possible to use this facility as a packet amplifier, as a small is possible to use this facility as a packet amplifier, as a small
multicast traceroute Query may turn into a large Reply packet. multicast traceroute Query may turn into a large Reply packet.
12. References 13. References
Brad88 Braden, B., D. Borman, C. Partridge, "Computing the Brad88 Braden, B., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC 1071, ISI, September 1988. Internet Checksum", RFC 1071, ISI, September 1988.
Brad97 Bradner, S., "Key words for use in RFCs to Indicate Brad97 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119/BCP 14, Harvard University, Requirement Levels", RFC 2119/BCP 14, Harvard University,
March 1997. March 1997.
Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco Sys- Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco Sys-
tems, February 1997. tems, February 1997.
Pusa99 Pusateri, T., "DVMRP Version 3", work in progress, June Pusa99 Pusateri, T., "DVMRP Version 3", work in progress, June
1999. 1999.
Thal99a Thaler, D., "PIM MIB", work in progress, June 1999. Thal99a Thaler, D., "PIM MIB", work in progress, June 1999.
Thal99b Thaler, D., "DVMRP MIB", work in progress, May 1998. Thal99b Thaler, D., "DVMRP MIB", work in progress, May 1998.
13. Authors' Addresses 14. Authors' Addresses
William C. Fenner William C. Fenner
AT&T Labs -- Research AT&T Labs -- Research
75 Willow Rd. 75 Willow Rd.
Menlo Park, CA 94025 Menlo Park, CA 94025
United States United States
Email: fenner@research.att.com Email: fenner@research.att.com
Stephen L. Casner Stephen L. Casner
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: casner@cisco.com Email: casner@cisco.com
15. Changes from the last revision:
- Changes section added.
- Updated abstract
- Added mention of up-to-date packet counts, in particular allowing
the delay of an mtrace packet while the counts are fetched in a
distributed architecture.
- Added mention of ifInMulticastPkts, ifOutMulticastPkts, and ipM-
RoutePkts for clarification of what counts should be used.
- Note that the dropping of duplicate Queries MAY be a 1-back cache
and that duplicate Requests MUST NOT be dropped
- Add no-space processing rule
- Note that it's not an error for there to be more blocks than
requested, just send it back after adding yours.
- Clean up some of section 8 - move implementation-specific stuff to
a separate section, rename "Congestion" to "Packet Loss", note that
time delay isn't actually that useful.
 End of changes. 

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