draft-ietf-idmr-traceroute-ipm-06.txt | draft-ietf-idmr-traceroute-ipm-07.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-06.txt AT&T Research | draft-ietf-idmr-traceroute-ipm-07.txt AT&T Research | |||
S. Casner | S. Casner | |||
Cisco Systems | Cisco Systems | |||
March 10, 2000 | July 14, 2000 | |||
Expires August 2000 | Expires January 2001 | |||
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 7, line 19 | skipping to change at page 7, line 19 | |||
5.3. Outgoing Interface Address | 5.3. Outgoing Interface Address | |||
This field specifies the address of the interface on which packets | This field specifies the address of the interface on which packets | |||
from this source and group flow to the specified destination, or 0 | from this source and group flow to the specified destination, or 0 | |||
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 (e.g. | |||
previous hop is not known because of the workings of the multicast | ALL-[protocol]-ROUTERS.MCAST.NET) if the previous hop is not known | |||
routing protocol. However, it should be 0 if the incoming inter- | because of the workings of the multicast routing protocol. How- | |||
face address is unknown. | ever, it should be 0 if the incoming interface address is unknown. | |||
5.5. Packet counts | 5.5. Packet counts | |||
Note that these packet counts SHOULD be as up to date as possible. | Note that these packet counts SHOULD be as up to date as possible. | |||
If packet counts are not being maintained on the processor that | If packet counts are not being maintained on the processor that | |||
handles the traceroute request in a multi-processor router archi- | handles the traceroute request in a multi-processor router archi- | |||
tecture, the packet SHOULD be delayed while the counters are gath- | tecture, the packet SHOULD be delayed while the counters are gath- | |||
ered from the remote processor(s). If this occurs, the Query | ered from the remote processor(s). If this occurs, the Query | |||
Arrival Time should be updated to reflect the time at which the | Arrival Time should be updated to reflect the time at which the | |||
packet counts were learned. | packet counts were learned. | |||
skipping to change at page 8, line 16 | skipping to change at page 8, line 16 | |||
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 | This counter should have the same value as ipMRoutePkts from the | |||
IPMROUTE-STD-MIB for this forwarding entry. | IPMROUTE-STD-MIB for this forwarding entry. | |||
5.9. 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: | |||
l l. 1 DVMRP 2 MOSPF 3 PIM 4 CBT 5 PIM using spe- | 1 DVMRP | |||
cial routing table 6 PIM using a static route 7 DVMRP using a | 2 MOSPF | |||
static route 8 PIM using MBGP (aka BGP4+) route 9 CBT using | 3 PIM | |||
special routing table 10 CBT using a static route 11 PIM using | 4 CBT | |||
state created by Assert processing | 5 PIM using special routing table | |||
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.10. 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.11. 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. | |||
skipping to change at page 8, line 49 | skipping to change at page 9, line 10 | |||
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.14. 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: | |||
expand; l l lw(3i) . Value Name Description _ | Value Name Description | |||
0x00 NO_ERROR No error 0x01 WRONG_IF T{ Traceroute request | -------------------------------------------------------------------- | |||
arrived on an interface to which this router would not forward for | 0x00 NO_ERROR No error | |||
this source,group,destination. T} 0x02 PRUNE_SENT T{ This | 0x01 WRONG_IF Traceroute request arrived on an interface to | |||
router has sent a prune upstream which applies to the source and | which this router would not forward for this | |||
group in the traceroute request. T} 0x03 PRUNE_RCVD T{ This | source,group,destination. | |||
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 T{ This router is not forwarding this | 0x07 NOT_FORWARDING This router is not forwarding this | |||
source,group out the outgoing interface for an unspecified reason. | source,group out the outgoing interface for an | |||
T} 0x08 REACHED_RP Reached Rendez-vous Point or Core | unspecified reason. | |||
0x09 RPF_IF T{ Traceroute request arrived on the expected RPF | 0x08 REACHED_RP Reached Rendez-vous Point or Core | |||
interface for this source,group. T} 0x0A NO_MULTICAST T{ Tracer- | 0x09 RPF_IF Traceroute request arrived on the expected RPF | |||
oute request arrived on an interface which is not enabled for mul- | interface for this source,group. | |||
ticast. T} 0x0B INFO_HIDDEN T{ One or more hops have been hid- | 0x0A NO_MULTICAST Traceroute request arrived on an interface | |||
den from this trace. T} 0x81 NO_SPACE T{ There was not enough | which is not enabled for multicast. | |||
room to insert another response data block in the packet. T} | 0x0B INFO_HIDDEN One or more hops have been hidden from this | |||
0x82 OLD_ROUTER T{ The previous hop router does not understand | trace. | |||
traceroute requests. T} 0x83 ADMIN_PROHIB Traceroute is adminis- | 0x81 NO_SPACE There was not enough room to insert another | |||
tratively prohibited. | response data block in the packet. | |||
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. A multicast traceroute client, upon | previous router placed there. A multicast traceroute client, upon | |||
receiving this error, MAY restart the trace at the last hop listed | receiving this error, MAY restart the 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 | |||
skipping to change at page 14, line 52 | skipping to change at page 15, line 23 | |||
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 | request received via multicast. Traceroute requests which are mul- | |||
multicasted to the group being traced must include the Router Alert | ticasted to the group being traced must include the Router Alert IP | |||
IP option [Katz97]. | 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 34 | skipping to change at page 17, line 6 | |||
the trace by starting it at the last hop in the trace. It can do | 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, | this by unicasting to this router's outgoing interface address, | |||
keeping all fields the same. If this results in a single hop and a | 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 | "WRONG_IF" error, the client may try setting the trace destination | |||
to the same outgoing interface address. | to the same outgoing interface address. | |||
If a trace times out, it is likely to be because a router in the | If a trace times out, it is likely to be because a router in the | |||
middle of the path does not support multicast traceroute. That | middle of the path does not support multicast traceroute. That | |||
router's address will be in the Previous Hop field of the last | 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 | entry in the last reply packet received. A client may be able to | |||
determine (via mrinfo[Pusa99] or SNMP[Thal99a,Thal99b]) a list of | determine (via mrinfo[Pusa99] or SNMP[Thal99,Thal00]) a list of | |||
neighbors of the non-responding router. If desired, each of those | neighbors of the non-responding router. If desired, each of those | |||
neighbors could be probed to determine the remainder of the path. | neighbors could be probed to determine the remainder of the path. | |||
Unfortunately, this heuristic may end up with multiple paths, since | Unfortunately, this heuristic may end up with multiple paths, since | |||
there is no way of knowing what the non-responding router's algo- | there is no way of knowing what the non-responding router's algo- | |||
rithm for choosing a previous-hop router is. However, if all paths | rithm for choosing a previous-hop router is. However, if all paths | |||
but one flow back towards the non-responding router, it is possible | but one flow back towards the non-responding router, it is possible | |||
to be sure that this is the correct path. | to be sure that this is the correct path. | |||
7.7. Multicast Traceroute and shared-tree routing protocols | 7.7. Multicast Traceroute and shared-tree routing protocols | |||
When using shared-tree routing protocols like PIM-SM and CBT, 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 | |||
ward the trace on, it means that the RP has not performed a source- | forward the trace on, it means that the RP has not performed a | |||
source-specific join so there is no more state to trace. However, | ||||
specific join so there is no more state to trace. However, the path | the path that traffic would use if the RP did perform a source-spe- | |||
that traffic would use if the RP did perform a source-specific join can | cific join can be traced by setting the trace destination to the | |||
be traced by setting the trace destination to the RP, the trace source | RP, the trace source to the traffic source, and the trace group to | |||
to the traffic source, and the trace group to 0. This trace Query may | 0. This trace Query may be unicasted to the RP. | |||
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 | |||
can be performed, setting the trace destination to the traffic source, | trace can be performed, setting the trace destination to the traf- | |||
the trace group to the group being traced, and the trace source to the | fic source, the trace group to the group being traced, and the | |||
Core (or to 0, since CBT does not have source-specific state). This | trace source to the Core (or to 0, since CBT does not have source- | |||
trace Query may be unicasted to the Core. There are two possibilities | specific state). This trace Query may be unicasted to the Core. | |||
when combining the two traces: | There are two possibilities when combining the two traces: | |||
7.7.2.1. No overlap | 7.7.2.1. No overlap | |||
If there is no overlap between the two traces, the second trace can | If there is no overlap between the two traces, the second trace can | |||
be reversed and appended to the first trace. This composite trace | be reversed and appended to the first trace. This composite trace | |||
shows the full path from the source to the destination. | shows the full path from the source to the destination. | |||
7.7.2.2. Overlapping paths | 7.7.2.2. Overlapping paths | |||
If there is a portion of the path that is common to the ends of the | If there is a portion of the path that is common to the ends of the | |||
two traces, that portion is removed from both traces. Then, as in | two traces, that portion is removed from both traces. Then, as in | |||
the no overlap case, the second trace is reversed and appended to | the no overlap case, the second trace is reversed and appended to | |||
the first trace, and the composite trace again contains the full | the first trace, and the composite trace again contains the full | |||
path. | path. | |||
This algorithm works whether the source has joined the CBT tree or not. | This algorithm works whether the source has joined the CBT tree or | |||
not. | ||||
7.8. Protocol-specific considerations | 7.8. Protocol-specific considerations | |||
7.8.1. DVMRP | 7.8.1. DVMRP | |||
DVMRP's dominant router election and route exchange guarantees that | DVMRP's dominant router election and route exchange guarantees that | |||
DVMRP routers know whether or not they are the last-hop forwarder | DVMRP routers know whether or not they are the last-hop forwarder | |||
for the link and who the previous hop is. | for the link and who the previous hop is. | |||
7.8.2. PIM Dense Mode | 7.8.2. PIM Dense Mode | |||
skipping to change at page 20, line 15 | skipping to change at page 20, line 38 | |||
In releases up through 3.5/3.6, packets were not counted as input on an | 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 | interface if the reverse-path forwarding check decided that the packets | |||
should be dropped. That causes the packets to appear as lost on the | 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 | 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 | 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 | 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 | those two routers because the downstream router receives packets for the | |||
other group on another interface, but the upstream router is the elected | other group on another interface, but the upstream router is the elected | |||
forwarder to other routers or hosts on the shared link. | forwarder to other routers or hosts on the shared link. | |||
The packet counts for source/group pairs are generally kept in router | ||||
forwarding caches. These cache entries may be occasionally garbage-col- | ||||
lected on routers, so a multicast traceroute client should be prepared | ||||
to see packet counts decrease. If a long-running traceroute is keeping | ||||
a "base" to compare against, it should use the post-reset trace as the | ||||
new "base", as previous values returned by this hop are no longer valid. | ||||
In addition, it may choose to discard the data for all other hops to | ||||
cover the same amount of time for all hops. | ||||
Some routers (notably the obsolete mrouted 3.3 and 3.4) can constantly | ||||
reset these packet counts. A client might want to detect routers that | ||||
are constantly resetting and simply fail to collect statistics for that | ||||
hop (instead of allowing it to cause all other data to be discarded). | ||||
Some routers send byte-swapped counter values. If the difference | ||||
between a pair of measurements is extremely large, a traceroute client | ||||
may want to see if the difference is more reasonable when byte-swapped. | ||||
Note that this heuristic may start misfiring when packet rates get high, | ||||
so implementations may want to only attempt this heuristic when the | ||||
packet rate is much different on one router than on surrounding routers. | ||||
Some implementations (e.g. UNIX mrouted 3.8 and before) return incorrect | ||||
time values; the difference between the time values for the same hop in | ||||
two traces may have no relationship with the amount of time that passed | ||||
between making the traces. Implementations should check that time val- | ||||
ues look valid before using them. | ||||
10. Acknowledgments | 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 | |||
skipping to change at page 21, line 39 | skipping to change at page 22, line 39 | |||
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, | |||
1999. | September 1999. | |||
Thal99a Thaler, D., "PIM MIB", work in progress, June 1999. | Thal00 Thaler, D., "PIM MIB", work in progress, July 2000. | |||
Thal99b Thaler, D., "DVMRP MIB", work in progress, May 1998. | Thal99 Thaler, D., "DVMRP MIB", work in progress, October 1999. | |||
14. 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: | 15. Change History | |||
(To be removed before publication as RFC) | ||||
15.1. Changes from draft-ietf-idmr-traceroute-ipm-06.txt: | ||||
- Added implementation-specific notes as suggested by Dave Thaler: | ||||
- Forwarding cache entries going away while traffic is flowing, | ||||
causing reset counters. | ||||
- mrouted 3.3 and 3.4 constant resets | ||||
- byte-swapped counters | ||||
- bogus time due to missed ntohl() parenthesis in mrouted <= 3.8 | ||||
- Add example of ALL-[protocol]-ROUTERS.MCAST.NET for the multicast- | ||||
on-prev-hop. (Maybe this isn't important any more; PIM used to be | ||||
allowed to not know the proper prev hop but that's not true any | ||||
more) | ||||
15.2. Changes from draft-ietf-idmr-traceroute-ipm-05.txt: | ||||
- Changes section added. | - Changes section added. | |||
- Updated abstract | - Updated abstract | |||
- Added mention of up-to-date packet counts, in particular allowing | - Added mention of up-to-date packet counts, in particular allowing | |||
the delay of an mtrace packet while the counts are fetched in a | the delay of an mtrace packet while the counts are fetched in a | |||
distributed architecture. | distributed architecture. | |||
- Added mention of ifInMulticastPkts, ifOutMulticastPkts, and ipM- | - Added mention of ifInMulticastPkts, ifOutMulticastPkts, and ipM- | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |