idnits 2.17.1 draft-ietf-idmr-traceroute-ipm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 307: '...remaining MUST still get forwarded....' RFC 2119 keyword, line 387: '... router MUST use a globally routab...' RFC 2119 keyword, line 389: '...terface, then it SHOULD NOT try to sen...' RFC 2119 keyword, line 394: '... MUST be forwarded as if it were r...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...working docu-...' == Line 15 has weird spacing: '...t other group...' == Line 16 has weird spacing: '...cuments as In...' == Line 19 has weird spacing: '... may be updat...' == Line 20 has weird spacing: '...other documen...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 26, 1996) is 10011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Katz96' on line 412 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Inter-Domain Multicast Routing Working Group 2 INTERNET-DRAFT W. Fenner 3 draft-ietf-idmr-traceroute-ipm-01.txt Xerox PARC 4 S. Casner 5 Precept Software 6 November 26, 1996 7 Expires: 3/31/97 9 A "traceroute" facility for IP Multicast. 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a 22 "working draft" or "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. 32 Abstract 34 This draft describes the IGMP multicast traceroute facility. As 35 the deployment of IP multicast has spread, it has become clear that 36 a method for tracing the route that a multicast IP packet takes 37 from a source to a particular receiver is absolutely required. 38 Unlike unicast traceroute, multicast traceroute requires a special 39 packet type and implementation on the part of routers. This 40 specification describes the required functionality. 42 This document is a product of the Inter-Domain Multicast Routing working 43 group within the Internet Engineering Task Force. Comments are soli- 44 cited and should be addressed to the working group's mailing list at 45 idmr@cs.ucl.ac.uk and/or the author(s). 47 1. Introduction 49 The unicast "traceroute" program allows the tracing of a path from one 50 machine to another, using mechanisms that already existed in IP. Unfor- 51 tunately, no such existing mechanisms can be applied to IP multicast 52 paths. The key mechanism for unicast traceroute is the ICMP TTL exceeded 53 message, which is specifically precluded as a response to multicast 54 packets. Thus, we specify the multicast "traceroute" facility to be 55 implemented in multicast routers and accessed by diagnostic programs. 56 While it is a disadvantage that a new mechanism is required, the multi- 57 cast traceroute facility can provide additional information about packet 58 rates and losses that the unicast traceroute cannot, and generally 59 requires fewer packets to be sent. 61 Goals: 63 + To be able to trace the path that a packet would take from some 64 source to some destination. 66 + To be able to isolate packet loss problems (e.g., congestion). 68 + To be able to isolate configuration problems (e.g., TTL threshold). 70 + To minimize packets sent (e.g. no flooding, no implosion). 72 2. Overview 74 Tracing from a source to a multicast destination is hard, since you 75 don't know down which branch of the multicast tree the destination lies. 76 This means that you have to flood the whole tree to find the path from 77 one source to one destination. However, walking up the tree from desti- 78 nation to source is easy, as all existing multicast routing protocols 79 know the previous hop for each source. Tracing from destination to 80 source can involve only routers on the direct path. 82 The party requesting the traceroute (which need be neither the source 83 nor the destination) sends a traceroute Query packet to the last-hop 84 multicast router for the given destination. The last-hop router turns 85 the Query into a Request packet by adding a response data block contain- 86 ing its interface addresses and packet statistics, and then forwards the 87 Request packet via unicast to the router that it believes is the proper 88 previous hop for the given source. Each hop adds its response data to 89 the end of the Request packet, then unicast forwards it to the previous 90 hop. The first hop router (the router that believes that packets from 91 the source originate on one of its directly connected networks) changes 92 the packet type to indicate a Response packet and sends the completed 93 response to the response destination address. The response may be 94 returned before reaching the first hop router if a fatal error condition 95 such as "no route" is encountered along the path. 97 3. Multicast Traceroute header 99 The header for all multicast traceroute packets is as follows: 101 0 1 2 3 102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | IGMP Type | # hops | checksum | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Multicast Group Address | 107 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 108 | Source Address | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Destination Address | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Response Address | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | resp ttl | Query ID | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 3.1. IGMP Type: 8 bits 119 The IGMP type field is defined to be 0x1F for traceroute queries 120 and requests. The IGMP type field is changed to 0x1E when the 121 packet is completed and sent as a response from the first hop 122 router to the querier. Two codes are required so that multicast 123 routers won't attempt to process a completed response in those 124 cases where the initial query was issued from a router or the 125 response is sent via multicast. 127 3.2. # hops: 8 bits 129 This field specifies the maximum number of hops that the requester 130 wants to trace. If there is some error condition in the middle of 131 the path that keeps the traceroute request from reaching the 132 first-hop router, this field can be used to perform an expanding- 133 length search to trace the path to just before the problem. 135 3.3. Checksum: 16 bits 137 This is the standard IGMP checksum. 139 3.4. Group address 141 This field specifies the group address to be traced, or zero if no 142 group-specific information is desired. Note that non-group- 143 specific traceroutes may not be possible with certain multicast 144 routing protocols. 146 3.5. Source address 148 This field specifies the IP address of the multicast source for the 149 path being traced. The traceroute request proceeds hop-by-hop from 150 the intended multicast receiver towards this source. 152 3.6. Destination address 154 This field specifies the IP address of the multicast receiver for 155 the path being traced. The trace starts at this destination and 156 proceeds toward the source. 158 3.7. Response Address 160 This field specifies where the completed traceroute response packet 161 gets sent. It can be a unicast address or a multicast address, as 162 explained in section 6.2. 164 3.8. resp ttl: 8 bits 166 This field specifies the TTL at which to multicast the response, if 167 the response address is a multicast address. 169 3.9. Query ID: 24 bits 171 This field is used as a unique identifier for this traceroute 172 request so that duplicate or delayed responses may be detected and 173 to minimize collisions when a multicast response address is used. 175 4. Response data 177 Each router adds a "response data" segment to the traceroute packet be- 178 fore it forwards it on. The response data looks like this: 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Query Arrival Time | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Incoming Interface Address | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Outgoing Interface Address | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Previous-Hop Router Address | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Input packet count on incoming interface | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Output packet count on outgoing interface | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Total number of packets for this source-group pair | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Rtg Protocol | FwdTTL |MBZ| Src Mask | ForwardingErr | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 4.1. Query Arrival Time 202 The Query Arrival Time is a 32-bit NTP timestamp specifying the 203 arrival time of the traceroute request packet at this router. The 204 32-bit form of an NTP timestamp consists of the middle 32 bits of 205 the full 64-bit form; that is, the low 16 bits of the integer part 206 and the high 16 bits of the fractional part. 208 4.2. Incoming Interface Address 210 This field specifies the address of the interface on which packets 211 from this source are expected to arrive, or 0 if unknown. 213 4.3. Outgoing Interface Address 215 This field specifies the address of the interface on which packets 216 from this source flow to the specified destination, or 0 if unk- 217 nown. 219 4.4. Previous-Hop Router Address 221 This field specifies the router from which this router expects 222 packets from this source, or 0 if unknown. 224 4.5. Input packet count on incoming interface 226 This field contains the number of multicast packets received for 227 all groups and sources on the incoming interface, or 0xffffffff if 228 no count can be reported. 230 4.6. Output packet count on outgoing interface 232 This field contains the number of multicast packets that have been 233 transmitted for all groups and sources on the outgoing interface, 234 or 0xffffffff if no count can be reported. 236 4.7. Total number of packets for this source-group pair 238 This field counts the number of packets from the specified source 239 forwarded by this router to the specified group, or 0xffffffff if 240 no count can be reported. 242 4.8. Rtg Protocol: 8 bits 244 This field describes the routing protocol in use between this 245 router and the previous-hop router. Specified values include: 247 1 - DVMRP 248 2 - MOSPF 249 3 - PIM 250 4 - CBT 251 5 - PIM using special routing table 252 6 - PIM using a static route 253 7 - DVMRP using a static route 255 4.9. FwdTTL: 8 bits 257 This field contains the TTL that a packet is required to have 258 before it will be forwarded over the outgoing interface. 260 4.10. Src Mask: 6 bits 262 This field contains the number of 1's in the netmask this router 263 has for the source (i.e. a value of 24 means the netmask is 264 0xffffff00) 266 4.11. ForwardingErr: 8 bits 268 This field contains a forwarding error code. Specified values 269 include: 271 0x00 No error 272 0x01 Traceroute request arrived on an interface 273 to which this router would not forward 274 for this source,group,destination. 275 0x02 This router has sent a prune upstream for the group. 276 0x03 This router has stopped forwarding in response to a 277 request from the next hop router. 278 0x04 The group is subject to administrative scoping at this hop. 279 0x05 This router has no route for the source. 280 0x07 This router is not forwarding this source,group 281 for an unspecified reason. 282 0x08 Reached Rendez-vous Point or Core 283 0x09 Traceroute request arrived on the expected 284 RPF interface for this source,group. 285 0x0A Traceroute request arrived on an interface which 286 is not enabled for multicast. 287 0x81 There was not enough room to insert another response data block 288 in the packet. 289 0x82 The next hop router does not understand traceroute requests. 290 0x83 Traceroute is administratively prohibited. 292 Note that if a router discovers there is not enough room in a 293 packet to insert its response, it puts the 0x81 error code in the 294 previous router's ForwardingErr field, overwriting any error the 295 previous router placed there. It is expected that a multicast tra- 296 ceroute client, upon receiving this error, will restart the trace 297 at the last hop listed in the packet. 299 The 0x80 bit of the ForwardingErr code is used to indicate a fatal 300 error. A fatal error is one where the router may know the previous 301 hop but cannot forward the message to it. 303 5. Router Behavior 305 All of these actions are performed in addition to (NOT instead of) for- 306 warding the packet, if applicable. E.g. a multicast packet that has TTL 307 remaining MUST still get forwarded. 309 5.1. Traceroute Query 311 Upon receiving a traceroute Query message (a request with no 312 response blocks filled in), a router must examine the traceroute 313 request to see if it is the proper last-hop router for the destina- 314 tion address in the packet. It is the proper last-hop router if it 315 has a multicast-capable interface on the same subnet as the Desti- 316 nation Address and is the router that would forward traffic from 317 the given source onto that subnet. It is also the proper last-hop 318 router if the Destination Address is the address of one of its 319 interfaces and either it is the router that would forward traffic 320 from the given source onto that subnet or there is no other router 321 on that subnet. 323 A router may receive a traceroute Query message via either unicast 324 or multicast. If received via multicast and it determines that it 325 is not the proper last-hop router, the packet should be silently 326 dropped. If received via unicast and it determines that it is not 327 the proper last-hop router, a response block with an error code of 328 0x1 must be inserted and the response forwarded to the response 329 address as described below. If the router knows which router is 330 the correct last-hop router, it puts that router's address in the 331 "Previous Hop" field of the response. 333 When a router receives a traceroute request with no response blocks 334 and it determines that it is the proper last-hop router, it inserts 335 a response block and forwards the traceroute request towards the 336 router that it expects to be the previous hop for this source and 337 group (or, if no group is specified, the previous hop for this 338 source). 340 5.2. Traceroute Request 342 When a router receives a traceroute request with some number of 343 response blocks filled in, it first checks the interface from which 344 it received the traceroute request. If the reception interface is 345 not one to which the router would forward data from the source, an 346 error code of 0x1 is noted and processing continues. If the recep- 347 tion interface is the interface from which the router would expect 348 data to arrive from the source, an error code of 0x9 is noted and 349 processing continues. If it receives a traceroute Request with 350 some number of response blocks filled in and the packet destination 351 is a multicast address, it must silently drop the packet. If a 352 router has no way to determine a route for the source, an error 353 code of 0x5 is noted and processing continues. The router fills in 354 as many fields as possible in the response packet, and then for- 355 wards the packet on or returns it to the requester. If the 356 Previous-hop router is known for the source and group (or, if no 357 group is specified, the previous-hop router for the source) and the 358 number of response blocks is less than the number requested, the 359 packet is forwarded to that router. Otherwise, it is sent to the 360 Response Address in the header, with the indicated TTL if the 361 Response Address is a multicast address. 363 5.3. Traceroute response 365 A router must forward all traceroute response packets normally, 366 with no special processing. 368 5.4. Sending Traceroute Responses 370 5.4.1. Destination Address 372 A traceroute response must be sent to the Response Address in the 373 traceroute header. 375 5.4.2. TTL 377 If the Response Address is unicast, the router inserts its normal 378 unicast TTL in the IP header. If the Response Address is multi- 379 cast, the router copies the Response TTL from the traceroute header 380 into the IP header. 382 5.4.3. Source Address 384 If the Response Address is unicast, the router may use any of its 385 interface addresses as the source address, preferring globally 386 routable addresses. If the Response Address is multicast, the 387 router MUST use a globally routable source address, if it has one. 388 If the router does not have a globally routable address attached to 389 any interface, then it SHOULD NOT try to send a multicast response. 391 5.4.4. Sourcing Multicast Responses 393 When a router sources a multicast response, the response packet 394 MUST be forwarded as if it were received on the outgoing interface. 396 6. Using multicast traceroute 398 <> 400 Several problems may arise when attempting to use multicast traceroute. 402 6.1. Last hop router 404 The traceroute querier may not know which is the last hop router, 405 or that router may be behind a firewall that blocks unicast packets 406 but passes multicast packets. In these cases, the traceroute 407 request should be multicasted to the group being traced (since the 408 last hop router listens to that group). All routers except the 409 correct last hop router should ignore any multicast traceroute 410 request received via multicast. Traceroute requests which are mul- 411 ticasted to the group being traced must include the Router Alert IP 412 option [Katz96]. 414 If the traceroute querier is attached to the same router as the 415 destination of the request, the traceroute request may be multi- 416 casted to 224.0.0.2 (ALL-ROUTERS.MCAST.NET) if the last-hop router 417 is not known. 419 6.2. First hop router 421 The traceroute querier may not be unicast reachable from the first 422 hop router. In this case, the querier should set the traceroute 423 response address to a multicast address, and should set the 424 response TTL to a value sufficient for the response from the first 425 hop router to reach the querier. It may be appropriate to start 426 with a small TTL and increase in subsequent attempts until a suffi- 427 cient TTL is reached, up to an appropriate maximum (such as 192). 429 The IANA has assigned 224.0.1.32, MTRACE.MCAST.NET, as the default 430 multicast group for multicast traceroute responses. Other groups 431 may be used if needed, e.g. when using mtrace to diagnose problems 432 with the IANA-assigned group. 434 6.3. Broken intermediate router 436 A broken intermediate router might simply not understand traceroute 437 packets, and drop them. The querier would then get no response at 438 all from its traceroute requests. It should then perform a hop- 439 by-hop search by setting the number of responses field until it 440 gets a response (both linear and binary search are options, but 441 binary is likely to be slower because a failure requires waiting 442 for a timeout). 444 6.4. Trace termination 446 When performing an expanding hop-by-hop trace, it is necessary to 447 determine when to stop expanding. 449 6.4.1. Arriving at source 451 A trace can be determined to have arrived at the source if the last 452 router in the trace has an interface on the same subnet as the 453 source. (***BAD HEURISTIC***! A router might have secondary sub- 454 nets attached to it but not have an address on any of those sub- 455 nets) <> 458 6.4.2. Fatal Error 460 A trace has encountered a fatal error if the last Forwarding Error 461 in the trace has the 0x80 bit set. 463 6.4.3. No Previous Hop 465 A trace can not continue if the last Previous Hop in the trace is 466 set to 0. 468 7. Problem Diagnosis 470 7.1. Forwarding Inconsistencies 472 The forwarding error code can tell if a group is unexpectedly 473 pruned or administratively scoped. 475 7.2. TTL problems 477 By taking the maximum of (hops from source + forwarding TTL thres- 478 hold) over all hops, you can discover the TTL required for the 479 source to reach the destination. 481 7.3. Congestion 483 By taking two traces, you can find packet loss information by com- 484 paring the difference in input packet counts to the difference in 485 output packet counts at the previous hop. On a point-to-point 486 link, any difference in these numbers implies packet loss. Since 487 the packet counts may be changing as the trace query is propagat- 488 ing, there may be small errors (off by 1 or 2) in these statistics. 489 However, these errors will not accumulate if multiple traces are 490 taken to expand the measurement period. On a shared link, the 491 count of input packets can be larger than the number of output 492 packets at the previous hop, due to other routers or hosts on the 493 link injecting packets. This appears as "negative loss" which may 494 mask real packet loss. 496 In addition to the counts of input and output packets for all mul- 497 ticast traffic on the interfaces, the response data includes a 498 count of the packets forwarded by a node for the specified source- 499 group pair. Taking the difference in this count between two traces 500 and then comparing those differences between two hops gives a meas- 501 ure of packet loss just for traffic from the specified source to 502 the specified receiver via the specified group. This measure is 503 not affected by shared links. 505 On a point-to-point link that is a multicast tunnel, packet loss is 506 usually due to congestion in unicast routers along the path of that 507 tunnel. On native multicast links, loss is more likely in the out- 508 put queue of one hop, perhaps due to priority dropping, or in the 509 input queue at the next hop. The counters in the response data do 510 not allow these cases to be distinguished. Differences in packet 511 counts between the incoming and outgoing interfaces on one node 512 cannot generally be used to measure queue overflow in the node 513 because some packets may be routed only to or from other interfaces 514 on that node. 516 In the multicast extensions for SunOS 4.1.x from Xerox PARC, both 517 the output packet count and the packet forwarding count for the 518 source-group pair are incremented before priority dropping for rate 519 limiting occurs and before the packets are put onto the interface 520 output queue which may overflow. These drops will appear as (posi- 521 tive) loss on the link even though they occur within the router. 523 In release 3.3/3.4 of the UNIX multicast extensions, a multicast 524 packet generated on a router will be counted as having come in an 525 interface even though it did not. This can create the appearance 526 of negative loss even on a point-to-point link. 528 In releases up through 3.5/3.6, packets were not counted as input 529 on an interface if the reverse-path forwarding check decided that 530 the packets should be dropped. That causes the packets to appear 531 as lost on the link if they were output by the upstream hop. This 532 situation can arise when two routers on the path for the group 533 being traced are connected by a shared link, and the path for some 534 other group does not flow between those two routers because the 535 downstream router receives packets for the other group on another 536 interface, but the upstream router is the elected forwarder to 537 other routers or hosts on the shared link. 539 7.4. Link Utilization 541 Again, with two traces, you can divide the difference in the input 542 or output packet counts at some hop by the difference in time 543 stamps from the same hop to obtain the packet rate over the link. 544 If the average packet size is known, then the link utilization can 545 also be estimated to see whether packet loss may be due to the rate 546 limit or the physical capacity on a particular link being exceeded. 548 7.5. Time delay 550 If the routers have synchronized clocks, it is possible to estimate 551 propagation and queueing delay from the differences between the 552 timestamps at successive hops. 554 8. Acknowledgments 556 This specification started largely as a transcription of Van Jacobson's 557 slides from the 30th IETF, and the implementation in mrouted 3.3 by Ajit 558 Thyagarajan. Van's original slides credit Steve Casner, Steve Deering, 559 Dino Farinacci and Deb Agrawal. A multicast traceroute client, mtrace, 560 has been implemented by Ajit Thyagarajan, Steve Casner and Bill Fenner. 562 9. Security Considerations 564 Security issues are not discussed in this memo. <> 565 <> 567 10. References 569 Katz96 Katz, D., "IP Router Alert Option," RFC XXXX, Cisco Sys- 570 tems, April 1996. 572 11. Authors' Addresses 574 William C. Fenner 575 Xerox PARC 576 3333 Coyote Hill Road 577 Palo Alto, CA 94304 578 Phone: +1 415 812 4816 579 Email: fenner@parc.xerox.com 581 Stephen L. Casner 582 Precept Software, Inc. 583 21580 Stevens Creek Blvd, Suite 207 584 Cupertino, CA 95014 585 Email: casner@precept.com