--- 1/draft-ietf-mboned-mtrace-v2-11.txt 2015-10-09 01:15:21.477580369 -0700 +++ 2/draft-ietf-mboned-mtrace-v2-12.txt 2015-10-09 01:15:21.549582073 -0700 @@ -1,19 +1,20 @@ MBONED Working Group H. Asaeda Internet-Draft NICT -Intended status: Standards Track W. Lee, Ed. -Expires: April 29, 2015 - October 26, 2014 +Intended status: Standards Track K. Meyer +Expires: April 11, 2016 Cisco + W. Lee, Ed. + October 9, 2015 Mtrace Version 2: Traceroute Facility for IP Multicast - draft-ietf-mboned-mtrace-v2-11 + draft-ietf-mboned-mtrace-v2-12 Abstract This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a query and receives a reply. @@ -25,25 +26,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 29, 2015. + This Internet-Draft will expire on April 11, 2016. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 @@ -63,67 +64,67 @@ 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 14 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 17 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 18 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 19 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 19 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 20 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 20 4.2.1. Request Packet Verification . . . . . . . . . . . . . 20 - 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 20 + 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 21 4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 22 - 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 22 + 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 23 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 23 4.3.3. Appending Standard Response Block . . . . . . . . . . 23 - 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 23 - 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 23 - 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 23 + 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 24 + 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 24 + 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 24 4.4.3. Appending Standard Response Block . . . . . . . . . . 24 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 24 - 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 24 + 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 25 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 25 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 25 - 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 25 - 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 25 + 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 26 + 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 26 5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 26 5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 26 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 26 - 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 26 + 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 27 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 27 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 27 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 27 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 27 - 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 27 + 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 28 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 28 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28 - 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 29 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 29 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 29 - 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 29 + 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 30 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 30 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 8.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . 30 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 8.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . 31 8.2. UDP Destination Port . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 31 9.2. Topology Discovery . . . . . . . . . . . . . . . . . . . 31 9.3. Characteristics of Multicast Channel . . . . . . . . . . 31 - 9.4. Limiting Query/Request Rates . . . . . . . . . . . . . . 31 - 9.5. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 31 + 9.4. Limiting Query/Request Rates . . . . . . . . . . . . . . 32 + 9.5. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction Given a multicast distribution tree, tracing from a multicast source to a receiver is difficult, since we do not know which branch of the @@ -173,33 +174,33 @@ \ | / \ | / \ +---------+ / v | Mtrace2 |/ | client | +---------+ Figure 1 When an Mtrace2 client initiates a multicast trace anywhere on the - Internet, it sends an Mtrace2 Query packet to the LHR for a multicast - group and a source address. The LHR turns the Query packet into a - Request, appends a standard response block containing its interface - addresses and packet statistics to the Request packet, then forwards - the packet towards the source. The Request packet is either - unicasted to its upstream router towards the source, or multicasted - to the group if the upstream router's IP address is not known. In a - similar fashion, each router along the path to the source appends a - standard response block to the end of the Request packet before - forwarding it to its upstream router. When the FHR receives the - Request packet, it appends its own standard response block, turns the - Request packet into a Reply, and unicasts the Reply back to the - Mtrace2 client. + Internet, it sends an Mtrace2 Query packet to the LHR or RP for a + multicast group and a source address. The LHR/RP turns the Query + packet into a Request, appends a standard response block containing + its interface addresses and packet statistics to the Request packet, + then forwards the packet towards the source. The Request packet is + either unicasted to its upstream router towards the source, or + multicasted to the group if the upstream router's IP address is not + known. In a similar fashion, each router along the path to the + source appends a standard response block to the end of the Request + packet before forwarding it to its upstream router. When the FHR + receives the Request packet, it appends its own standard response + block, turns the Request packet into a Reply, and unicasts the Reply + back to the Mtrace2 client. The Mtrace2 Reply may be returned before reaching the FHR if it reaches the RP first, or a fatal error condition such as "no route" is encountered along the path, or the hop count is exceeded. The Mtrace2 client waits for the Mtrace2 Reply message and displays the results. When not receiving an Mtrace2 Reply message due to network congestion, a broken router (see Section 5.6), or a non- 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 @@ -274,21 +275,21 @@ 3. Packet Formats This section describes the details of the packet formats for Mtrace2 messages. All Mtrace2 messages are encoded in TLV format (see Section 3.1). If an implementation receives an unknown TLV, it SHOULD ignored and silently discarded the unknown TLV. If the length of a TLV exceeds the length specified in the TLV, the TLV SHOULD be accepted; however, - any additional data after the TLV SHOULD be ignored. + any additional data after the specified TLV length SHOULD be ignored. All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and Request messages MUST NOT be fragmented. For IPv6, the packet size for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the smallest MTU for an IPv6 interface [2]. The source port is uniquely selected by the local host operating system. The destination port is the IANA reserved Mtrace2 port number (see Section 8). All Mtrace2 messages MUST have a valid UDP checksum. Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed. @@ -337,21 +338,21 @@ Each Mtrace2 message MUST begin with either a Query, Request or Reply TLV. The first TLV determines the type of each Mtrace2 message. Following a Query TLV, there can be a sequence of optional Extended Query Blocks. In the case of a Request or a Reply TLV, it is then followed by a sequence of Standard Response Blocks, each from a multicast router on the path towards the source or the RP. In the case more information is needed, a Standard Response Block can be followed by one or multiple Augmented Response Blocks. - We will describe each message type in details in the next few + We will describe each message type in detail in the next few sections. 3.2.1. Mtrace2 Query An Mtrace2 Query is usually originated by an Mtrace2 client which sends an Mtrace2 Query message to the LHR. When tracing towards the source or the RP, the intermediate routers MUST NOT modify the Query message except the Type field. An Mtrace2 Query message is shown as follows: @@ -375,22 +376,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query ID | Client Port # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 # Hops: 8 bits This field specifies the maximum number of hops that the Mtrace2 client wants to trace. If there are some error conditions in the middle of the path that prevent an Mtrace2 Reply from being - received by the client, the client MAY issues another Mtrace2 - Query with the lower number of hops until it receives a Reply. + received by the client, the client MAY issue another Mtrace2 Query + with a lower number of hops until it receives a Reply. Multicast Address: 32 bits or 128 bits This field specifies an IPv4 or IPv6 address, which can be either: m-1: a multicast group address to be traced; or, m-2: all 1's in case of IPv4 or the unspecified address (::) in case of IPv6 if no group-specific information is desired. Source Address: 32 bits or 128 bits @@ -545,21 +546,21 @@ transmitted or queued for transmission for all groups and sources on the outgoing interface, or all 1's if no count can be reported. This counter may have the same value as ifHCOutMulticastPkts from the IF-MIB [10] for this interface. Total number of packets for this source-group pair: 64 bits This field counts the number of packets from the specified source forwarded by the router to the specified group, or all 1's if no count can be reported. If the S bit is set (see below), the count is for the source network, as specified by the Src Mask field (see - below). If the S bit is set and the Src Mask field is 63, + below). If the S bit is set and the Src Mask field is 127, indicating no source-specific state, the count is for all sources sending to this group. This counter should have the same value as ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] for this forwarding entry. Rtg Protocol: 16 bits This field describes the unicast routing protocol running between this router and the upstream router, and it is used to determine the RPF interface for the specified source or RP. This value should have the same value as ipMcastRouteRtProtocol from the @@ -847,48 +848,50 @@ Extended Query Type: 16 bits This field specifies the type of the Extended Query Block. Value: 16 bits This field specifies the value of this Extended Query. 4. Router Behavior This section describes the router behavior in the context of Mtrace2 - in details. + in detail. 4.1. Receiving Mtrace2 Query An Mtrace2 Query message is an Mtrace2 message with no response blocks filled in, and uses TLV type of 0x01. 4.1.1. Query Packet Verification Upon receiving an Mtrace2 Query message, a router MUST examine whether the Multicast Address and the Source Address are a valid combination as specified in Section 3.2.1, and whether the Mtrace2 Client Address is a valid IP unicast address. If either one is invalid, the Query MUST be silently ignored. - Mtrace2 supports non-local client to the LHR. It is up to the + Mtrace2 supports a non-local client to the LHR/RP. It is up to the implementation to filter out such queries. - In the case when it is a local client, the router must then examine - the Query to see if it is the proper LHR for the destination address - in the packet. It is the proper LHR if it has a multicast-capable - interface on the same subnet as the Mtrace2 Client Address and is the - router that would forward traffic from the given (S,G) or (*,G) onto - that subnet. + In the case where a local LHR client is required, the router must + then examine the Query to see if it is the proper LHR/RP for the + destination address in the packet. It is the proper local LHR if it + has a multicast-capable interface on the same subnet as the Mtrace2 + Client Address and is the router that would forward traffic from the + given (S,G) or (*,G) onto that subnet. It is the proper RP if the + multicast group address specified in the query is 0 and if the IP + header destination address is a valid RP address on this router. - If the router determines that it is not the proper LHR, or it cannot - make that determination, it does one of two things depending on - whether the Query was received via multicast or unicast. If the + If the router determines that it is not the proper LHR/RP, or it + cannot make that determination, it does one of two things depending + on whether the Query was received via multicast or unicast. If the Query was received via multicast, then it MUST be silently discarded. If it was received via unicast, the router turns the Query into a Reply message by changing the TLV type to 0x03 and appending a Standard Response Block with a Forwarding Code of WRONG_LAST_HOP. The rest of the fields in the Standard Response Block MUST be zeroed. The router then sends the Reply message to the Mtrace2 Client Address on the Client Port # as specified in the Mtrace2 Query. Duplicate Query messages as identified by the tuple (Mtrace2 Client Address, Query ID) SHOULD be ignored. This MAY be implemented using @@ -952,61 +955,68 @@ state should be used. If there is no group state or no group- specific information is desired, potential source state (i.e., the path that would be followed for a source-specific Join) should be used. 3. If no forwarding information can be determined, the router notes a Forwarding Code of NO_ROUTE, sets the remaining fields that have not yet been filled in to zero, and then sends an Mtrace2 Reply back to the Mtrace2 client. - 4. Fill in the Incoming Interface Address, Upstream Router Address, - Input Packet Count, Total Number of Packets, Routing Protocol, - S, and Src Mask (or Src Prefix Len for IPv6) using the - forwarding information determined by the step 2. + 4. Fill in the Incoming Interface Address (or Incoming Interface ID + and Local Address for IPv6), Upstream Router Address (or Remote + Address for IPv6), Input Packet Count, Total Number of Packets, + Routing Protocol, S, and Src Mask (or Src Prefix Len for IPv6) + using the forwarding information determined by the step 2. 5. If Mtrace2 is administratively prohibited, note the Forwarding Code of ADMIN_PROHIB. If Mtrace2 is administratively prohibited and any of the fields as filled in the step 4 are considered private information, zero out the applicable fields. 6. If the Outgoing interface is not enabled for multicast, note Forwarding Code of NO_MULTICAST. If the Outgoing interface is the interface from which the router would expect data to arrive from the source, note forwarding code RPF_IF. If the Outgoing interface is not one to which the router would forward data from the source or RP to the group, a Forwarding code of WRONG_IF is noted. In the above three cases, the router will return an Mtrace2 Reply and terminate the trace. 7. If the group is subject to administrative scoping on either the Outgoing or Incoming interfaces, a Forwarding Code of SCOPED is noted. - 8. If this router is the RP for the group, note a Forwarding Code - of REACHED_RP. The router will send an Mtrace2 Reply and - terminate the trace. + 8. If this router is the RP for the group for a non-source-specific + query, note a Forwarding Code of REACHED_RP. The router will + send an Mtrace2 Reply and terminate the trace. - 9. If this router has sent a prune upstream which applies to the + 9. If this router is directly connected to the specified source or + source network on the Incoming interface, it sets the Upstream + Router Address (for IPv4) or the Remote Address (for IPv6) of + the response block to zero. The router will send an Mtrace2 + Reply and terminate the trace. + + 10. If this router has sent a prune upstream which applies to the source and group in the Mtrace2 Request, it notes Forwarding Code of PRUNE_SENT. If the router has stopped forwarding downstream in response to a prune sent by the downstream router, it notes Forwarding Code of PRUNE_RCVD. If the router should normally forward traffic downstream for this source and group but is not, it notes Forwarding Code of NOT_FORWARDING. - 10. If this router is a gateway (e.g., a NAT or firewall) that hides + 11. If this router is a gateway (e.g., a NAT or firewall) that hides the information between this router and the Mtrace2 client, it notes Forwarding Code of REACHED_GW. The router continues the processing as described in Section 4.5. - 11. If the total number of the Standard Response Blocks, including + 12. If the total number of the Standard Response Blocks, including the newly prepared one, and the value of the Augmented Response Type of 0x01, if any, is less than the # Hops in the Request, the packet is then forwarded to the upstream router as described in Section 4.3; otherwise, the packet is sent as an Mtrace2 Reply to the Mtrace2 client as described in Section 4.4. 4.3. Forwarding Mtrace2 Request This section describes how an Mtrace2 Request should be forwarded. @@ -1118,21 +1128,21 @@ from the Mtrace2 Requests. The Forwarding Code of INFO_HIDDEN may be used to note that. For example, the incoming interface address and packet count on the ingress router of a domain, and the outgoing interface address and packet count on the egress router of the domain can be specified as all 1's. Additionally, the source-group packet count (see Section 3.2.4 and Section 3.2.5) within the domain may be all 1's if it is hidden. 5. Client Behavior - This section describes the behavior of an Mtrace2 client in details. + This section describes the behavior of an Mtrace2 client in detail. 5.1. Sending Mtrace2 Query An Mtrace2 client initiates an Mtrace2 Query by sending the Query to the LHR of interest. 5.1.1. Destination Address If an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2 Query packet to that router; otherwise, it MAY send the Mtrace2 Query @@ -1270,21 +1280,22 @@ different multicast protocols. 6.1. PIM-SM 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 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 traced by setting the trace destination to the RP, the trace source to the traffic source, and the trace group to 0. This Mtrace2 Query - may be unicasted to the RP. + may be unicasted to the RP, and the RP takes the same actions as an + LHR. 6.2. Bi-Directional PIM Bi-directional PIM [6] is a variant of PIM-SM that builds bi- directional shared trees connecting multicast sources and receivers. Along the bi-directional shared trees, multicast data is natively forwarded from the sources to the Rendezvous Point Link (RPL), and from which, to receivers without requiring source-specific state. In contrast to PIM-SM, Bi-directional PIM always has the state to trace. @@ -1438,40 +1449,40 @@ A router may limit Mtrace2 Queries and Requests by ignoring some of the consecutive messages. The router MAY randomly ignore the received messages to minimize the processing overhead, i.e., to keep fairness in processing queries, or prevent traffic amplification. The rate limit is left to the router's implementation. 9.5. Limiting Reply Rates The proxying and NO_SPACE behaviors may result in one Query returning multiple Reply messages. In order to prevent abuse, the routers in - the traced MAY need to rate-limit the Replies. The rate limit + the traced path MAY need to rate-limit the Replies. The rate limit function is left to the router's implementation. 10. Acknowledgements 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 Thyagarajan. Van's original slides credit Steve Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original multicast traceroute client, mtrace (version 1), has been implemented by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the "S" bit to allow statistics for a source subnet is due to Tom Pusateri. For the Mtrace version 2 specification, the authors would like to give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner. Also, extensive comments were received from David L. Black, Ronald - Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert W. Kebler, Heidi - Ou, Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, - and Cao Wei. + Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, Heidi Ou, + Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, + Stig Venaas, and Cao Wei. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. @@ -1520,12 +1531,21 @@ Authors' Addresses Hitoshi Asaeda National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi Koganei, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp + Kerry Meyer + Cisco Systems, Inc. + 510 McCarthy Blvd. + Milpitas, CA 95035 + USA + + Email: kerrymey@cisco.com WeeSan Lee (editor) + + Email: weesan@weesan.com