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/ |