--- 1/draft-ietf-mboned-mtrace-v2-05.txt 2010-01-23 11:11:29.000000000 +0100 +++ 2/draft-ietf-mboned-mtrace-v2-06.txt 2010-01-23 11:11:29.000000000 +0100 @@ -1,74 +1,81 @@ MBONED Working Group H. Asaeda Internet-Draft Keio University Intended status: Standards Track T. Jinmei -Expires: April 29, 2010 ISC +Expires: July 27, 2010 ISC W. Fenner Arastra, Inc. S. Casner Packet Design, Inc. - October 26, 2009 + January 23, 2010 Mtrace Version 2: Traceroute Facility for IP Multicast - draft-ietf-mboned-mtrace-v2-05 + draft-ietf-mboned-mtrace-v2-06 + +Abstract + + This document describes the IP multicast traceroute facility. Unlike + unicast traceroute, multicast traceroute requires special + implementations on the part of routers. This specification describes + the required functionality in multicast routers, as well as how + management applications can use the router functionality. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 29, 2010. + This Internet-Draft will expire on July 27, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + + Copyright (c) 2010 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 in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract + 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 + described in the BSD License. - This document describes the IP multicast traceroute facility. Unlike - unicast traceroute, multicast traceroute requires special - implementations on the part of routers. This specification describes - the required functionality in multicast routers, as well as how - management applications can use the router functionality. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . . 9 4.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . 9 5. Mtrace2 Query Header . . . . . . . . . . . . . . . . . . . . . 10 @@ -168,29 +176,29 @@ the ICMP TTL exceeded message, which is specifically precluded as a response to multicast packets. On the other hand, the multicast traceroute facility allows the tracing of an IP multicast routing paths. In this document, we specify the multicast "traceroute" facility to be implemented in multicast routers and accessed by diagnostic programs. The multicast traceroute described in this document named as mtrace version 2 or mtrace2 provides additional information about packet rates and losses that the unicast traceroute cannot, and generally requires fewer packets to be sent. - o. To be able to trace the path that a packet would take from some + o To be able to trace the path that a packet would take from some source to some destination. - o. To be able to isolate packet loss problems (e.g., congestion). + o To be able to isolate packet loss problems (e.g., congestion). - o. To be able to isolate configuration problems (e.g., TTL + o To be able to isolate configuration problems (e.g., TTL threshold). - o. To minimize packets sent (e.g. no flooding, no implosion). + o To minimize packets sent (e.g. no flooding, no implosion). This document supports both IPv4 and IPv6 multicast traceroute facility. The protocol design, concept, and program behavior are same between IPv4 and IPv6 mtrace2. While the original IPv4 multicast traceroute, mtrace, the query and response messages are implemented as IGMP messages [12], all mtrace2 messages are carried on UDP. The packet formats of IPv4 and IPv6 mtrace2 are different because of the different address families, but the syntax is similar. 2. Terminology @@ -823,23 +831,23 @@ response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 mtrace2. Routers can tell the difference between Queries and Requests by checking the length of the packet. 9.2.1. Packet Verification If the mtrace2 Request does not come from an adjacent host or router, it MUST be silently ignored. If the mtrace2 Request is not addressed to this router, or if the Request is addressed to a multicast group which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3] - for IPv6), it MUST be silently ignored. It is highly RECOMMENDED for - the router to use GTSM [16] to determine whether the host or router - is adjacent or not. + for IPv6), it MUST be silently ignored. GTSM [16] SHOULD be used by + the router to determine whether the host or router is adjacent or + not. 9.2.2. Normal Processing When a router receives an mtrace2 Request, it performs the following steps. Note that it is possible to have multiple situations covered by the Forwarding Codes. The first one encountered is the one that is reported, i.e. all "note forwarding code N" should be interpreted as "if forwarding code is not already set, set forwarding code to N". 1. If there is room in the current buffer (or the router can