draft-ietf-mboned-mtrace-v2-20.txt   draft-ietf-mboned-mtrace-v2-21.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track K. Meyer Intended status: Standards Track K. Meyer
Expires: April 17, 2018 Cisco Expires: May 6, 2018 Cisco
W. Lee, Ed. W. Lee, Ed.
October 14, 2017 November 2, 2017
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-20 draft-ietf-mboned-mtrace-v2-21
Abstract Abstract
This document describes the IP multicast traceroute facility, named This document describes the IP multicast traceroute facility, named
Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2
requires special implementations on the part of routers. This requires special implementations on the part of routers. This
specification describes the required functionality in multicast specification describes the required functionality in multicast
routers, as well as how an Mtrace2 client invokes a query and routers, as well as how an Mtrace2 client invokes a query and
receives a reply. receives a reply.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2018. This Internet-Draft will expire on May 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 8 skipping to change at page 4, line 8
9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Given a multicast distribution tree, tracing from a multicast source Given a multicast distribution tree, tracing from a multicast source
to a receiver is difficult, since we do not know which branch of the to a receiver is difficult, since we do not know on which branch of
multicast tree the receiver lies. This means that we have to flood the multicast tree the receiver lies. This means that we have to
the whole tree to find the path from a source to a receiver. On the flood the whole tree to find the path from a source to a receiver.
other hand, walking up the tree from a receiver to a source is easy, On the other hand, walking up the tree from a receiver to a source is
as most existing multicast routing protocols know the upstream router easy, as most existing multicast routing protocols know the upstream
for each source. Tracing from a receiver to a source can involve router for each source. Tracing from a receiver to a source can
only the routers on the direct path. involve only the routers on the direct path.
This document specifies the multicast traceroute facility named This document specifies the multicast traceroute facility named
Mtrace version 2 or Mtrace2 which allows the tracing of an IP Mtrace version 2 or Mtrace2 which allows the tracing of an IP
multicast routing path. Mtrace2 is usually initiated from an Mtrace2 multicast routing path. Mtrace2 is usually initiated from an Mtrace2
client by sending an Mtrace2 Query to a Last Hop Router (LHR) or to a client by sending an Mtrace2 Query to a Last Hop Router (LHR) or to a
Rendezvous Point (RP). The RP is a special router where sources and Rendezvous Point (RP). The RP is a special router where sources and
receivers meet in PIM-SM [5]. From the LHR/RP receiving the query, receivers meet in PIM-SM [5]. From the LHR/RP receiving the query,
the tracing is directed towards a specified source if a source the tracing is directed towards a specified source if a source
address is specified and source specific state exists on the address is specified and source specific state exists on the
receiving router. If no source address is specified or if no source receiving router. If no source address is specified or if no source
skipping to change at page 6, line 7 skipping to change at page 6, line 7
RP or gateway, or when any of several types of error or exception RP or gateway, or when any of several types of error or exception
conditions occur which prevent sending of a request to the next conditions occur which prevent sending of a request to the next
upstream router. upstream router.
The Mtrace2 client waits for the Mtrace2 Reply message and displays The Mtrace2 client waits for the Mtrace2 Reply message and displays
the results. When not receiving an Mtrace2 Reply message due to the results. When not receiving an Mtrace2 Reply message due to
network congestion, a broken router (see Section 5.6), or a non- network congestion, a broken router (see Section 5.6), or a non-
responding router (see Section 5.7), the Mtrace2 client may resend responding router (see Section 5.7), the Mtrace2 client may resend
another Mtrace2 Query with a lower hop count (see Section 3.2.1), and another Mtrace2 Query with a lower hop count (see Section 3.2.1), and
repeat the process until it receives an Mtrace2 Reply message. The repeat the process until it receives an Mtrace2 Reply message. The
details are Mtrace2 client specific, and it is outside the scope of details are Mtrace2 client specific and outside the scope of this
this document. document.
Note that when a router's control plane and forwarding plane are out Note that when a router's control plane and forwarding plane are out
of sync, the Mtrace2 Requests might be forwarded based on the control of sync, the Mtrace2 Requests might be forwarded based on the control
states instead. In which case, the traced path might not represent states instead. In this case, the traced path might not represent
the real path the data packets would follow. the real path the data packets would follow.
Mtrace2 supports both IPv4 and IPv6. Unlike the previous version of Mtrace2 supports both IPv4 and IPv6. Unlike the previous version of
Mtrace, which implements its query and response as IGMP messages [8], Mtrace, which implements its query and response as IGMP messages [8],
all Mtrace2 messages are UDP-based. Although the packet formats of all Mtrace2 messages are UDP-based. Although the packet formats of
IPv4 and IPv6 Mtrace2 are different because of the address families, IPv4 and IPv6 Mtrace2 are different because of the address families,
the syntax between them is similar. the syntax between them is similar.
This document describes the base specification of Mtrace2 that can This document describes the base specification of Mtrace2 that can
serve as a basis for future proposals such as Mtrace2 for AMT [9] and serve as a basis for future proposals such as Mtrace2 for AMT [9] and
skipping to change at page 11, line 48 skipping to change at page 11, line 48
except the Type field is 0x03. except the Type field is 0x03.
When a FHR or a RP receives an Mtrace2 Request message which is When a FHR or a RP receives an Mtrace2 Request message which is
destined to itself, it would append an Mtrace2 Standard Response destined to itself, it would append an Mtrace2 Standard Response
Block (see Section 3.2.4) of its own to the Request message. Next, Block (see Section 3.2.4) of its own to the Request message. Next,
it would turn the Request message into a Reply by changing the Type it would turn the Request message into a Reply by changing the Type
field of the Request from 0x02 to 0x03. The Reply message would then field of the Request from 0x02 to 0x03. The Reply message would then
be unicasted to the Mtrace2 client specified in the Mtrace2 Client be unicasted to the Mtrace2 client specified in the Mtrace2 Client
Address field. Address field.
There are a number of cases an intermediate router might return a There are a number of cases in which an intermediate router might
Reply before a Request reaches the FHR or the RP. See Section 4.1.1, return a Reply before a Request reaches the FHR or the RP. See
Section 4.2.2, Section 4.3.3, and Section 4.5 for more details. Section 4.1.1, Section 4.2.2, Section 4.3.3, and Section 4.5 for more
details.
3.2.4. IPv4 Mtrace2 Standard Response Block 3.2.4. IPv4 Mtrace2 Standard Response Block
This section describes the message format of an IPv4 Mtrace2 Standard This section describes the message format of an IPv4 Mtrace2 Standard
Response Block. The Type field is 0x04. Response Block. The Type field is 0x04.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ | | Type | Length | MBZ |
skipping to change at page 19, line 11 skipping to change at page 19, line 11
path. path.
The Augmented Response Type is defined as follows: The Augmented Response Type is defined as follows:
Code Type Code Type
==== =============================================== ==== ===============================================
0x01 # of the returned Standard Response Blocks 0x01 # of the returned Standard Response Blocks
When the NO_SPACE error occurs on a router, the router should send When the NO_SPACE error occurs on a router, the router should send
the original Mtrace2 Request received from the downstream router the original Mtrace2 Request received from the downstream router
as a Reply back to the Mtrace2 client, and continue with a new as a Reply back to the Mtrace2 client and continue with a new
Mtrace2 Request. In the new Request, the router would add a Mtrace2 Request. In the new Request, the router would add a
Standard Response Block followed by an Augmented Response Block Standard Response Block followed by an Augmented Response Block
with 0x01 as the Augmented Response Type, and the number of the with 0x01 as the Augmented Response Type, and the number of the
returned Mtrace2 Standard Response Blocks as the Value. returned Mtrace2 Standard Response Blocks as the Value.
Each upstream router would recognize the total number of hops the Each upstream router would recognize the total number of hops the
Request has been traced so far by adding this number and the Request has been traced so far by adding this number and the
number of the Standard Response Block in the current Request number of the Standard Response Block in the current Request
message. message.
skipping to change at page 19, line 38 skipping to change at page 19, line 38
Value: variable length Value: variable length
The format is based on the Augmented Response Type value. The The format is based on the Augmented Response Type value. The
length of the value field is Length field minus 6. length of the value field is Length field minus 6.
3.2.7. Mtrace2 Extended Query Block 3.2.7. Mtrace2 Extended Query Block
There may be a sequence of optional Extended Query Blocks that follow There may be a sequence of optional Extended Query Blocks that follow
an Mtrace2 Query to further specify any information needed for the an Mtrace2 Query to further specify any information needed for the
Query. For example, an Mtrace2 client might be interested in tracing Query. For example, an Mtrace2 client might be interested in tracing
the path the specified source and group would take based on a certain the path the specified source and group would take based on a certain
topology. In which case, the client can pass in the multi-topology topology. In this case, the client can pass in the multi-topology ID
ID as the Value for an Extended Query Type (see below). The Extended as the Value for an Extended Query Type (see below). The Extended
Query Type is extensible and the behavior of the new types will be Query Type is extensible and the behavior of the new types will be
addressed by separate documents. addressed by separate documents.
The Mtrace2 Extended Query Block's Type field is 0x06, and is The Mtrace2 Extended Query Block's Type field is 0x06, and is
formatted as follows: formatted as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ |T| | Type | Length | MBZ |T|
skipping to change at page 24, line 40 skipping to change at page 24, line 40
after appending a Standard Response Block to the end of the received after appending a Standard Response Block to the end of the received
Mtrace2 Request. The Standard Response Block includes the multicast Mtrace2 Request. The Standard Response Block includes the multicast
states and statistics information of the router described in states and statistics information of the router described in
Section 3.2.4. Section 3.2.4.
If appending the Standard Response Block would make the Mtrace2 If appending the Standard Response Block would make the Mtrace2
Request packet longer than the MTU of the Incoming Interface, or, in Request packet longer than the MTU of the Incoming Interface, or, in
the case of IPv6, longer than 1280 bytes, the router MUST change the the case of IPv6, longer than 1280 bytes, the router MUST change the
Forwarding Code in the last Standard Response Block of the received Forwarding Code in the last Standard Response Block of the received
Mtrace2 Request into NO_SPACE. The router then turns the Request Mtrace2 Request into NO_SPACE. The router then turns the Request
into a Reply, and sends the Reply as described in Section 4.4. into a Reply and sends the Reply as described in Section 4.4.
The router will continue with a new Request by copying from the old The router will continue with a new Request by copying from the old
Request excluding all the response blocks, followed by the previously Request excluding all the response blocks, followed by the previously
prepared Standard Response Block, and an Augmented Response Block prepared Standard Response Block, and an Augmented Response Block
with Augmented Response Type of 0x01 and the number of the returned with Augmented Response Type of 0x01 and the number of the returned
Standard Response Blocks as the value. The new Request is then Standard Response Blocks as the value. The new Request is then
forwarded upstream. forwarded upstream.
4.4. Sending Mtrace2 Reply 4.4. Sending Mtrace2 Reply
skipping to change at page 29, line 12 skipping to change at page 29, line 12
Incoming Interface of the last router in the trace is non-zero, but Incoming Interface of the last router in the trace is non-zero, but
the Upstream Router is zero. the Upstream Router is zero.
5.8.2. Fatal Error 5.8.2. Fatal Error
A trace has encountered a fatal error if the last Forwarding Error in A trace has encountered a fatal error if the last Forwarding Error in
the trace has the 0x80 bit set. the trace has the 0x80 bit set.
5.8.3. No Upstream Router 5.8.3. No Upstream Router
A trace can not continue if the last Upstream Router in the trace is A trace cannot continue if the last Upstream Router in the trace is
set to 0. set to 0.
5.8.4. Reply Timeout 5.8.4. Reply Timeout
This document defines the [Mtrace Reply Timeout] value, which is used This document defines the [Mtrace Reply Timeout] value, which is used
to time out an Mtrace2 Reply as seen in Section 4.5, Section 5.2, and to time out an Mtrace2 Reply as seen in Section 4.5, Section 5.2, and
Section 5.7. The default [Mtrace Reply Timeout] value is 10 Section 5.7. The default [Mtrace Reply Timeout] value is 10
(seconds), and can be manually changed on the Mtrace2 client and (seconds), and can be manually changed on the Mtrace2 client and
routers. routers.
5.9. Continuing after an Error 5.9. Continuing after an Error
When the NO_SPACE error occurs, as described in Section 4.2, a router When the NO_SPACE error occurs, as described in Section 4.2, a router
will send back an Mtrace2 Reply to the Mtrace2 client, and continue will send back an Mtrace2 Reply to the Mtrace2 client, and continue
with a new Request (see Section 4.3.3). In which case, the Mtrace2 with a new Request (see Section 4.3.3). In this case, the Mtrace2
client may receive multiple Mtrace2 Replies from different routers client may receive multiple Mtrace2 Replies from different routers
along the path. When this happens, the client MUST treat them as a along the path. When this happens, the client MUST treat them as a
single Mtrace2 Reply message. single Mtrace2 Reply message.
If a trace times out, it is very likely that a router in the middle If a trace times out, it is very likely that a router in the middle
of the path does not support Mtrace2. That router's address will be of the path does not support Mtrace2. That router's address will be
in the Upstream Router field of the last Standard Response Block in in the Upstream Router field of the last Standard Response Block in
the last received Reply. A client may be able to determine (via the last received Reply. A client may be able to determine (via
mrinfo or SNMP [11][13]) a list of neighbors of the non-responding mrinfo or SNMP [11][13]) a list of neighbors of the non-responding
router. If desired, each of those neighbors could be probed to router. The neighbors obtained in this way could then be probed (via
determine the remainder of the path. Unfortunately, this heuristic the multicast MIB [13]) to determine which one is the upstream (RPF)
may end up with multiple paths, since there is no way of knowing what neighbor of the non-responding router. This algorithm can identify
the non-responding router's algorithm for choosing an upstream router the upstream neighbor because, even though there may be multiple
is. However, if all paths but one flow back towards the non- neighbors, the non-responding router should only have sent a "join"
responding router, it is possible to be sure that this is the correct to the one neighbor corresponding to its selected RPF path. Because
path. of this, only the RPF neighbor should contain the non-responding
router as a multicast next hop in its MIB output list for the
affected multicast route.
6. Protocol-Specific Considerations 6. Protocol-Specific Considerations
This section describes the Mtrace2 behavior with the presence of This section describes the Mtrace2 behavior with the presence of
different multicast protocols. different multicast protocols.
6.1. PIM-SM 6.1. PIM-SM
When an Mtrace2 reaches a PIM-SM RP, and the RP does not forward the When an Mtrace2 reaches a PIM-SM RP, and the RP does not forward the
trace on, it means that the RP has not performed a source-specific trace on, it means that the RP has not performed a source-specific
skipping to change at page 31, line 27 skipping to change at page 31, line 27
or administratively scoped. or administratively scoped.
7.2. TTL or Hop Limit Problems 7.2. TTL or Hop Limit Problems
By taking the maximum of hops from the source and forwarding TTL By taking the maximum of hops from the source and forwarding TTL
threshold over all hops, it is possible to discover the TTL or hop threshold over all hops, it is possible to discover the TTL or hop
limit required for the source to reach the destination. limit required for the source to reach the destination.
7.3. Packet Loss 7.3. Packet Loss
By taking two traces, it is possible to find packet loss information By taking multiple traces, it is possible to find packet loss
by comparing the difference in input packet counts to the difference information by tracking the difference between the output packet
in output packet counts for the specified source-group address pair count for the specified source-group address pair at a given upstream
at the previous hop. On a point-to-point link, any difference in router and the input packet count on the next hop downstream router.
these numbers implies packet loss. Since the packet counts may be On a point-to-point link, any steadily increasing difference in these
changing as the Mtrace2 Request is propagating, there may be small counts implies packet loss. Although the packet counts will differ
errors (off by 1 or 2 or more) in these statistics. However, these due to Mtrace2 Request propagation delay, the difference should
errors will not accumulate if multiple traces are taken to expand the remain essentially constant (except for jitter caused by differences
measurement period. On a shared link, the count of input packets can in propagation time among the trace iterations). However, this
be larger than the number of output packets at the previous hop, due difference will display a steady increase if packet loss is
to other routers or hosts on the link injecting packets. This occurring. On a shared link, the count of input packets can be
appears as "negative loss" which may mask real packet loss. larger than the number of output packets at the previous hop, due to
other routers or hosts on the link injecting packets. This appears
as "negative loss" which may mask real packet loss.
In addition to the counts of input and output packets for all In addition to the counts of input and output packets for all
multicast traffic on the interfaces, the Standard Response Block multicast traffic on the interfaces, the Standard Response Block
includes a count of the packets forwarded by a node for the specified includes a count of the packets forwarded by a node for the specified
source-group pair. Taking the difference in this count between two source-group pair. Taking the difference in this count between two
traces and then comparing those differences between two hops gives a traces and then comparing those differences between two hops gives a
measure of packet loss just for traffic from the specified source to measure of packet loss just for traffic from the specified source to
the specified receiver via the specified group. This measure is not the specified receiver via the specified group. This measure is not
affected by shared links. affected by shared links.
 End of changes. 15 change blocks. 
42 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/