Network Working Group Heidi Ou Internet-Draft Cisco Systems, Inc. Intended status: Experimental H. Asaeda Expires: April 21, 2011 Keio University October 18, 2010 Dual-Path Mtrace draft-hou-dp-mtrace-00.txt Abstract Mtrace2 is a tool that can be used to discover the path a multicast packet takes to reach one or more receivers. This document describes an enhancement to extend mtrace2 to be able to discover more than one path for a single (S,G) or (*,G) entry and to trace more than one (S,G) or (*,G) entries simultaneously. Changes to the mtrace2 protocol, and behaviors required by multicast routers to support the changes, are specified in this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 21, 2011. Copyright Notice 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 (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 Heidi Ou & Asaeda Expires April 21, 2011 [Page 1] Internet-Draft Dual-Path Mtrace October 2010 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. Heidi Ou & Asaeda Expires April 21, 2011 [Page 2] Internet-Draft Dual-Path Mtrace October 2010 Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Mtrace Overview . . . . . . . . . . . . . . . . . . . . . 5 2.2. Mtrace And Multicast Spatial Redundancy . . . . . . . . . 5 3. Dual-Path Mtrace . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Common Topology and Terminologies . . . . . . . . . . . . 7 3.2. Function Overview . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Redundant Paths and Redundant Flows . . . . . . . . . 9 3.2.2. Augmented Response Block . . . . . . . . . . . . . . . 9 3.2.3. Extended Query . . . . . . . . . . . . . . . . . . . . 10 3.2.4. Tracing Dual Path . . . . . . . . . . . . . . . . . . 10 3.2.5. Detecting Merge Point . . . . . . . . . . . . . . . . 10 3.2.6. Sending Asynchronous Response . . . . . . . . . . . . 10 3.2.7. Discarding Duplicated Requests . . . . . . . . . . . . 11 3.2.8. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. New Augmented Response Blocks . . . . . . . . . . . . . . 12 4.1.1. Redundant Path Request . . . . . . . . . . . . . . . . 13 4.1.2. Redundant Flow Request . . . . . . . . . . . . . . . . 14 4.1.3. Topology ID Response . . . . . . . . . . . . . . . . . 14 4.1.4. Redundant Path Information Response . . . . . . . . . 15 4.1.5. Redundant Flow Information Response . . . . . . . . . 16 4.1.6. Merge Point of Redundant Paths Response . . . . . . . 16 4.1.7. Merge Point of Redundant Flow Response . . . . . . . . 17 4.2. Extended Query . . . . . . . . . . . . . . . . . . . . . . 18 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Originating Query . . . . . . . . . . . . . . . . . . . . 20 5.1.1. Redundant Paths . . . . . . . . . . . . . . . . . . . 20 5.1.2. Redundant Flows . . . . . . . . . . . . . . . . . . . 21 5.2. Sending Request . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Redundant Path Request . . . . . . . . . . . . . . . . 21 5.2.2. Redundant Flow Request . . . . . . . . . . . . . . . . 21 5.3. Attaching Response . . . . . . . . . . . . . . . . . . . . 22 5.4. Merging Router . . . . . . . . . . . . . . . . . . . . . . 22 5.5. Asynchronous Response . . . . . . . . . . . . . . . . . . 22 5.6. Interoperability . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 28 9.2. informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Heidi Ou & Asaeda Expires April 21, 2011 [Page 3] Internet-Draft Dual-Path Mtrace October 2010 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Heidi Ou & Asaeda Expires April 21, 2011 [Page 4] Internet-Draft Dual-Path Mtrace October 2010 2. Introduction 2.1. Mtrace Overview Mtrace is a tool that can be used to discover the path a multicast packet takes to reach one or more receivers. The following is an example that shows how mtrace works. 1. A client program initiates a trace by creating an mtrace Query message and forwarding the message to its neighboring multicast router. 2. Upon receiving the Query message, a router -- normally a DR at the last hop LAN -- creates an mtrace Request message and forwards the request towards the specified source or RP being traced. 3. As the mtrace Request message is forwarded hop by hop upstream, each router along the path creates and fills in an mtrace Response block. 4. When the Request message, which by now also includes several Response blocks, reaches a first hop router or the RP, the router creates an mtrace Response message and forwarded it back towards the client. 5. The client receives and process the Response message to complete the trace. The current version of mtrace, also known as "mtrace2", is described in [MTRACE2]. The following lists the key enhancement of mtrace2 over the original design of mtrace. o Mtrace2 messages are encapsulated as UDP messages. o Mtrace2 supports both IPv4 and IPv6 address families. o Mtrace2 introduces a new opaque response block, called Augmented Response Block, that allows the protocol to be extended easily. The protocol and procedures specified in this document is based on mtrace2. Throughout the document, when there is no ambiguity, the terms of "mtrace" and "mtrace2" are used interchangeably. 2.2. Mtrace And Multicast Spatial Redundancy There are many techniques that have been implemented and deployed to enhance resilience of a multicast network. Most of them involves Heidi Ou & Asaeda Expires April 21, 2011 [Page 5] Internet-Draft Dual-Path Mtrace October 2010 some kind of dual-transmission, in the form of either sending the same IP packet twice, or sending the same transport flow twice, each with a different IP header. In the first case, there is only one (S,G) or (*,G) entry created in the network. But for each entry, two forwarding paths (or trees) are established. In the second case, there are two different (S,G) or (*,G) entries created in the network. In both cases, the IP multicast packets are sent along different paths. This is what also known as Spatial Redundancy. The detail of the various techniques is out of the scope of this document. Examples can be found in [MOFRR] and [MTID]. While the mtrace proves to be a very useful and practical tool since its inception, it may be inadequate when a network supports multicast spatial redundancy. This is because by its original design, an mtrace Request message is supposed to be sent to only one upstream or previous hop router, therefore incapable of identifying and tracing redundant paths. Another feature that can be added into the original design is the capability of sending an asynchronous response. Such a response is very useful if the network experiences a change that alters the path a multicast packet takes. With the current design, a client program must issue another mtrace Query/Request in order to detect a change. This document specifies extensions to the mtrace2 protocol and the corresponding processing required by routers to support tracing paths with spatial redundancy. In theory, spatial redundancy allows an arbitrary number of redundancy paths to be established, but in practice, there is rarely the need to support more than two paths. The mechanism described in this document focuses on the case when two paths are available (hence the name dual-path mtrace), and it can be easily extended if there is a need to trace more paths. In addition to specify the protocols and procedures required to support tracing dual paths, this document also describes a mechanism that allows mtrace2 to send and process an asynchronous response. Heidi Ou & Asaeda Expires April 21, 2011 [Page 6] Internet-Draft Dual-Path Mtrace October 2010 3. Dual-Path Mtrace 3.1. Common Topology and Terminologies In Figure 1 a simple topology is drawn to show a network with non- overlapping paths between a traffic source and receiver. Heidi Ou & Asaeda Expires April 21, 2011 [Page 7] Internet-Draft Dual-Path Mtrace October 2010 (source) | | | +-----+ | R-A | +-----+ | | | | + + / \ / \ / \ +-----+ +-----+ | R-B | | R-F | +-----+ +-----+ / \ / \ / \ / \ / \ / \ ( X ) \ / \ / \ / \ / \ / \ / +-----+ +-----+ | R-C |-----| R-E | +-----+ +-----+ \ / \ / \ / + + | | | | +-----+ | R-D | +-----+ | | | (receiver) Figure 1: Network With Spatial Redundancy In the topology, there are six routers, represented as R-A, R-B, R-C, R-D, R-E and R-F. There is also a source and a receiver. We call R-A as a first hop router (FHR) and R-D as a last hop router (LHR). Throughout the document, the terms, primary/active, secondary/backup Heidi Ou & Asaeda Expires April 21, 2011 [Page 8] Internet-Draft Dual-Path Mtrace October 2010 are used quite freely. They carry their normal meanings. Specifically, When there is only one (S,G) or (*,G) entry created, the "primary" path refers to the path from which packets are accepted and forwarded. The "secondary" path refers to the path that either doesn't carry any packets while the primary path is being used, or forwards packets that are discarded by a merging router until the router determines that the primary path is not available. When there are two (S,G) or (*,G) entries created for the same transport flow, we call one IP packet flow as "primary" and the other "secondary", for the only purpose of identifying (or naming) a flow. When we don't care whether a path (or a flow) is "primary" or "secondary", we might call it an "alternate" path (or flow) in this document. This document doesn't specify a way to define which path/flow is "primary" or "secondary". This decision is local to the router or even the multicast application. 3.2. Function Overview 3.2.1. Redundant Paths and Redundant Flows There are two types of redundancy that are discussed in this document. Using the topology in Figure 1 as an example. 1. The source is sending a single IP packet flow, represented as (S,G). In this case, the last hop router R-D may join (S,G) via two paths as described in [MOFRR]. This type of redundancy is referred to as "Redundant Paths" or "Dual Path". 2. The source is sending two different IP packet flows, represented as (S1, G1) and (S2, G2), each taking a different path to reach the receivers. Each flow may also be forwarded by a different FHR, or by the same FHR (for example, by R-A, as in the topology). This scenario is referred to as "Redundant Flows" or "Dual Flows". 3.2.2. Augmented Response Block Mtrace2 introduces a variable length message block called "Augmented Response Block", abbreviated as ARB. It is used to include additional information to the mtrace messages. The TLV format also allows a system to ignore an unknown ARB while still able to process Heidi Ou & Asaeda Expires April 21, 2011 [Page 9] Internet-Draft Dual-Path Mtrace October 2010 the standard Request and Response. To support dual path tracing, several types of new ARBs are introduced in this document to convey the information of redundant path or flow. 3.2.3. Extended Query A new mtrace Query type, named "Extended Query", is also introduced in this document. It is used by a client program to indicate to its last hop router to request tracing of redundant paths or flows when applicable. 3.2.4. Tracing Dual Path Tracing can be initiated by a client program implemented on a receiver host or a router. The originator indicates the type of tracing, whether it is for redundant flows or redundant paths, in the Extended Query that is requested to the last hop router. The last hop router generates two mtrace requests, each traverses upstream along the path that would have been taken by data packets to reach the receiver. Routers in the middle attaches information to the request in the form of Standard Response Block and applicable Augmented Response Block. When the two request/responses reach the first hop router, it will merge the two requests and send a combined response back to the originator. In the case only one request is received (e.g., when the redundant flows are forwarded by two first hop routers), only one response will be sent back. 3.2.5. Detecting Merge Point It is possible that the paths merge unexpectedly in the middle of the network (as opposed to merge at the first hop router), an Augmented Response Block is also attached by the intermediate router detecting the merge. 3.2.6. Sending Asynchronous Response Each dual path mtrace Request has a life time. Within that life time, whenever there is a change to the network that alters the path packets will be taking, a new Response will be sent upstream by an intermediate router detecting the change. This will in turn cause the first hop router to send an asynchronous Response back to the originator of the mtrace Request. In order to avoid sending Heidi Ou & Asaeda Expires April 21, 2011 [Page 10] Internet-Draft Dual-Path Mtrace October 2010 excessive mtrace packets, an implementation must limit the number of asynchronous Response it initiates on intermediate or first hop routers. 3.2.7. Discarding Duplicated Requests Since the LHR converts the Extended Query into multiple Request messages, the two requests will have the same fields in the part of Standard Query. It is not sufficient to use the tuple (Source, Query ID) to detect and discard duplicate Request for this new type of Extended Query. To detect duplicate Requests, redundant path and/or flow information in the Extended Query/Request messages are examined. The detail is explained in the later sections. 3.2.8. TTL A new Time-to-Live field is defined as lifetime of the dual path mtrace Request. Within the lifetime, the mtrace Request is considered "alive", and therefore, any change in the path MAY trigger an intermediate router, or a first hop router, to generate an asynchronous Response. An implementation may wish to ignore the "TTL". In doing so, it loses the ability to notify the originator of the change, requiring the originator to send initiate another Query to detect the change of path. 3.3. IPv6 TBD. Heidi Ou & Asaeda Expires April 21, 2011 [Page 11] Internet-Draft Dual-Path Mtrace October 2010 4. Message Format New mtrace message formats are defined in this section. An asterisk is used to identify a new code or type value. 4.1. New Augmented Response Blocks An mtrace ARB message has the format as shown in Figure 3. But since the ARB message follows an mtrace2 message header as shown in Figure 2, field of an ARB message starts at 32bit boundary. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Mtrac2 TLV Format For An Augmented Response Block Type: 5, indicating the Value field includes an ARB. Length: variable, depending on the length of the ARB Value...: the start of the ARB, which is the 16 bit Type field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Augmented Response Block Format The following table lists the type of ARBs defined. Those marked with an asterisk are new, and are included in the appropriate Extended Query/Request and Response Blocks messages. Heidi Ou & Asaeda Expires April 21, 2011 [Page 12] Internet-Draft Dual-Path Mtrace October 2010 Code Type ====== ================================================= 0x01 # Mtrace2 Standard Response Blocks Returned *0x02 Redundant Path Request *0x03 Redundant Flow Request *0x04 Topology ID Response *0x05 Redundant Path Information Response *0x06 Redundant Flow Information Response *0x07 Merge Point of Redundant Paths Response *0x08 Merge Point Of Redundant Flows Response Figure 4: New Types of Augmented Response Blocks 4.1.1. Redundant Path Request This ARB is included in an mtrace Query or Request message. It has the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Alternate Query ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|R| TTL | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Redundant Path Request ARB Format Type: 2. Alternate Query ID: A Query ID used to trace an alternate path. This value MUST be different than the "Query ID" in the common Query header preceding this ARB. S: When set to 1, the Query ID in the common header is used to trace the primary path, implying that the "Alternative Query ID" refers to the Query ID that must be used to trace the secondary path. When set to 0, the semantic is reversed. R: Reserved. Reset to 0. TTL: The life-time in seconds of this Extended Query and the resulting Request. The duration is usually application dependent, with the maximum value being 16384 seconds. Heidi Ou & Asaeda Expires April 21, 2011 [Page 13] Internet-Draft Dual-Path Mtrace October 2010 4.1.2. Redundant Flow Request This ARB is included in an mtrace Query or Request message. It is used to indicate an alternate (S2,G2) entry that together forms the redundant flows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Alternate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source | Alternate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Group |S|R| TTL . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redundant Flow Request Type: 3. Alternate Source: Source address of the alternate flow. If it is the same as the Source Address field in the common Query header, the group addresses must be different. For IPv4, this field is 32 bits (as shown). For IPv6 it is 128 bits. Alternate Group: Group address of the alternate flow. If it is the same as the Multicast Address field in the common Query header, the source addresses must be different. For IPv4, this field is 32 bits (as shown). For IPv6 it is 128 bits. S: When set to 1, Multicast Address and Source Address in the common header are used to trace the primary flow, implying that the "Alternate Source" and "Alternate Group" refers to the secondary flow. When set to 0, the semantic is reversed. R: Reserved. Rest to 0. TTL: The life-time in seconds of this Extended Query and the resulting Request. The duration is usually application dependent, with the maximum value being 16384 seconds. 4.1.3. Topology ID Response This ARB describes topology ID corresponding to the RPF information included in the preceding Standard Response Bloc. Heidi Ou & Asaeda Expires April 21, 2011 [Page 14] Internet-Draft Dual-Path Mtrace October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 |M| Topology ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Topology ID Response Type: 4. M: A flag indicating the type of the "Topology ID" field that follows. If M is 1, the "Topology ID" is defined for PIM. See [MTID]. If M is 0, the "Topology ID" comes from the corresponding IGP. When multi-topology is not used, M is reset and the "Topology ID" is 0. Topology ID: The lower 15 bits of the ID of the topology from which RPF information is obtained. 4.1.4. Redundant Path Information Response This ARB is included in the mtrace Response message sent from the FHR to the originator of the Request. The response message basically includes two series of Standard Response Blocks. The first one corresponds to the original Query/Request (and the Query ID) that is used to trace the primary path. The second one, which is embedded in an ARB, as described in Figure 6, describes the information of the secondary path. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Alternate Query ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Standard Response Data Blocks . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Redundant Path Information Response Type: 5. Alternate Query ID: As described in "Redundant Path Request". Heidi Ou & Asaeda Expires April 21, 2011 [Page 15] Internet-Draft Dual-Path Mtrace October 2010 Standard Response Data Block: A number of mtrace Standard Response Blocks that are built while tracing using the Alternate Query ID on the secondary path. 4.1.5. Redundant Flow Information Response This ARB is included in the mtrace Response message sent from the FHR to the originator of the Request. The response message has two parts. The first part includes tracing information obtained using the primary flow, (S1,G1), while the second part, which is following by this ARB, includes tracing information obtained using the secondary flow, (S2, G2). In a Redundant Flow Information Response message, each Standard Response Data Block might be immediately followed by a Topology ID Response ARB. In another word, Redundant Flow Information Response might recursively include another ARB. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Standard Response Data Blocks +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ With Topology Information +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Redundant Flow Information Response 4.1.6. Merge Point of Redundant Paths Response This ARB describes a router at which two redundant paths merge. It has the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Alternate Query ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Standard Response Data Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Merge Point of Redundant Paths Response Heidi Ou & Asaeda Expires April 21, 2011 [Page 16] Internet-Draft Dual-Path Mtrace October 2010 Type: 7. Alternate Query ID: The Query ID used to trace and obtain the Standard Response Data Block immediately following. Standard Response Data Block: The Standard Response Data Block that would've been attached by this router when using the "Alternate Query ID" to trace. There can be only one Standard Response Data Block in this ARB. 4.1.7. Merge Point of Redundant Flow Response This ARB describes a router that is forwarding both the primary and the secondary flows. It has the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | Alternate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source | Alternate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Group |M| Topology ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Standard Response Data Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Merge Point of Redundant Flow Response Type: 8. Alternate Source: Source address of the alternate flow. If it is the same as the Source Address field in the common Query header, the group addresses must be different. For IPv4, this field is 32 bits (as shown). For IPv6 it is 128 bits. Alternate Group: Group address of the alternate flow. If it is the same as the Multicast Address field in the common Query header, the source addresses must be different. For IPv4, this field is 32 bits (as shown). For IPv6 it is 128 bits. M: A flag indicating the type of the following "Topology ID". If M is 1, the "Topology ID" is defined for PIM. If M is 0, the "Topology ID" comes from the corresponding IGP. When multi- topology is not used, M is reset and the "Topology ID" is 0. Heidi Ou & Asaeda Expires April 21, 2011 [Page 17] Internet-Draft Dual-Path Mtrace October 2010 Topology ID: The lower 15 bits of the ID of the topology from which RPF information is obtained. Standard Response Data Block: The Standard Response Data Block that would've been attached by this router when using the "Alternate Source" and the "Alternate Group" to trace. There can be only one Standard Response Data Block in this ARB. 4.2. Extended Query An Extended Query consists of one standard Query plus one ARB. The length of the Extended Query varies depending on the length of the ARB. When a first hop router builds an mtrace request, it might choose to modify the fields based on the type of the ARB. The detail is described in later sections. Code Type ====== ====================================== 1 Mtrace2 Query 2 Mtrace2 Request 3 Mtrace2 Response 4 Mtrace2 Standard Response Block 5 Mtrace2 Augmented Response Block *6 Mtrace2 Extended Query Figure 10: MTrace2 TLV Types An Extended Query takes the following format. At this moment, only two types of ARBs are defined for Extended Query. They are "Redundant Path Request" and "Redundant Flow Request". Heidi Ou & Asaeda Expires April 21, 2011 [Page 18] Internet-Draft Dual-Path Mtrace October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Extended_Query_ Length | # hops | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Multicast Address | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Source Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query ID | Client Port # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length | ARB_ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2/3 | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Extended Query Heidi Ou & Asaeda Expires April 21, 2011 [Page 19] Internet-Draft Dual-Path Mtrace October 2010 5. Protocol Operation In this section, we describe in detail how an implementation should generate and process various new messages introduced by this document. The following notations are used to help the illustration. MTRACE(x): This refers to type "x" of the Mtrace2 TLVs. For example, MTRACE(6) refers to the Extended Query TLV introduced by this document. A full list of Mtrace2 TLV types is in Figure 10. ARB(x): This refers to type "x" of the MTrace2 Augmented Response Block TLV. For example, ARB(2) refers to "Redundant Path Request". A full list of new Augmented Response Blocks types is in Figure 4. 5.1. Originating Query A client program starts a traceroute for a multicast flow by originating an mtrace Extended Query. The client program can be running on a host (such as the receiver shown in Figure 1), or on a router. When it is running on a router, the router is considered a last hop router (LHR). It is assumed that the client program is aware how the redundant multicast streams are formed and delivered to the system. That is, the client knows if it is getting two copies of duplicate IP packet flows, or two IP packet flows each with a different IP header. In the case of the later, the client program also knows the actual IP addresses, (S1,G1)/(S2,G2). The type of tracing is indicated by the type of ARB immediately following the common Mtrac2 header. 5.1.1. Redundant Paths In the common header, the Source and Multicast address fields identify the source and destination addresses of the flow. A "Redundant Path Request" ARB follows the common header. In the ARB, an "Alternate Query Id" is set and a TTL is given. The "Alternate Query Id" MUST be different than the "Query ID" in the common header. It is used to tell the router what Query Id to use in tracing the alternate path. Normally, "S" bit is set if "Alternate Query ID" is intended to be used for the secondary path. If it is reset, "Query ID" will be used to trace the secondary path and "Alternate Query ID" will be used for the primary path. The setting of TTL is described in previous sections and is not Heidi Ou & Asaeda Expires April 21, 2011 [Page 20] Internet-Draft Dual-Path Mtrace October 2010 repeated here. 5.1.2. Redundant Flows In this case, the Source and Multicast address fields in the common header identifies one flow, and the "Alternate Source" and "Alternate Group" fields in the "Redundant Flow Request" ARB identify the other. The "S" bit in the ARB indicates which one is the primary flow and which one is the secondary. 5.2. Sending Request A last hop router, e.g., R-D in Figure 1, upon receiving the Extended Query, first determines if the received Extended Query is a duplicate or not. The rules described in [MTRACE2] are applied. If it is not a duplicate, the LHR converts the Extended Query to two Mtrace2 Requests. Both requests have the same IP source and destination addresses in the IP header. 5.2.1. Redundant Path Request If the received ARB is "Redundant Paths Request", one request is sent upstream out of the RPF interface of the primary path, and the other sent out of one of the secondary path. The two resulting requests have different Query ID and Alternate Query ID. For example, if the original Extended Query says the Query ID is 1000, the Alternate Query ID is 2000 with S bit set, the Request sent to the primary path will have Query ID set to 1000, Alternate Query ID set to 2000 and S bit set (the same as the Extended Query), while the Request sent to the secondary path will have Query ID set to 2000, Alternate Query ID to 1000 and S bit is reset. 5.2.2. Redundant Flow Request If the received ARB is "Redundant Flow Request", for example, (S1, G1) is considered the primary flow and (S2, G2) is considered the secondary, an LHR generates two request, one for (S1, G1) and one for (S2, G2). The Request for (S1, G1) will be sent out of the interface based on how the forwarding tree for (S1, G1) is built. In the ARB, (S2, G2) will also be included with S-Bit set. Similarly, the request for (S2, G2) will be sent out of the interface based on the forwarding tree for (S2, G2) is built. And (S1, B1) will be included in the ARB with S-Bit clear. Heidi Ou & Asaeda Expires April 21, 2011 [Page 21] Internet-Draft Dual-Path Mtrace October 2010 The Query ID will be the same for both Requests. 5.3. Attaching Response An intermediate router, including the LHR and the FHR, attaches a Standard Response Block first to the Mtrace2 Request it receives, using the procedures described in [MTRACE2]. In another word, an Mtrace2 Request that includes a "Redundant Path Request" ARB is treated no differently than an Mtrace2 Request without one by an intermediate router in this particular regard. On the other hand, if the ARB is "Redundant Flow Request", an intermediate router SHOULD also attach an ARB of the type "Topology ID Response" immediately following its Standard Response Block. 5.4. Merging Router If two paths converge on the same router, e.g., the FHR, R-A, in Figure 1, the router is considered a Merging Router. A Merging Router that is not the FHR performs the following actions. o For a "Redundant Path Request", the router attaches an ARB of "Merge Point of Redundant Path Information Response" immediately following its Standard Response Block. o For a "Redundant Flow Request", the router attaches an ARB of "Merge Point of Redundant Flow Information Response" immediately following its own "Topology ID Response" if it is present, or following its own "Standard Response Block". On the other hand, if the Merging Router is the FHR, upon receiving the Mtrace2 Request from one path, it may choose to save the packet for some time, anticipating another one from a different path. The delay is implementation specific. If it receives both Mtrace2 Requests, it generates a new Mtrace2 Response by merging the Responses from both packets. The Response from the secondary path follows either "Redundant Path Information Response" ARB or "Redundant Flow Information Response" ARB which follows the Response from the primary path. 5.5. Asynchronous Response Each router supporting this draft attempts to store at least one Request per session. The lifetime of the Request is indicated by the "TTL" field in the corresponding ARB. However, a router MAY wish to purge the requests at any time. In any case, it MUST NOT honor Heidi Ou & Asaeda Expires April 21, 2011 [Page 22] Internet-Draft Dual-Path Mtrace October 2010 Requests that have aged out. The lifetime of a Request is introduced so that routers can notify a client program of an routing change. If the routing change does not result in two diverse paths merging on a router prior to the FHR, the FHR SHOULD NOT send an unsolicited Response. Otherwise, the FHR MAY send one. An Asynchronous Response may be initiated by the following events, using Figure 1 as an example, and assuming there is only a single flow but with dual paths. 1. Under normal operation, the paths to reach the source from the receiver are: Primary Path: R-D -> R-C -> R-B -> R-A Secondary Path: R-D -> R-E -> R-F -> R-A 2. A routing change that results in the link between R-E and R-F becoming unavailable, and the new secondary path becomes, R-D -> R-E -> R-B -> R-A. In another word, R-B becomes the new merging router. 3. This change is detected by R-E because its RPF interface towards the source has been changed. But it is not aware whether its new RPF neighbour, R-B, will become the merging router or not. Upon detecting the RPF change, it sends an Mtrace2 Request (for secondary path) towards R-B. 4. When R-B sees the Request, and detects that it is a merge router (but not an FHR), it adds a Standard Response Block to the Request. It also attaches "Merge Point of Redundant Path Response" and sends the resulting packet to R-A. 5. R-A merges the new Request with the previous information obtained from the primary path and sends the combined information in the Response packet back to the client. 5.6. Interoperability It is possible that an intermediate router, such as R-B, doesn't support this draft. When that happens, the following information will not be available in the Mtrace2 Request/Response packets. o The router will not cache the Request. Heidi Ou & Asaeda Expires April 21, 2011 [Page 23] Internet-Draft Dual-Path Mtrace October 2010 o The router will not attach some of the ARBs. o The router will not generate asynchronous Response packets These will cause certain loss of information but the basic Mtrace2 functionality still remains. It is also possible that the FHR, i.e. R-A, doesn't support this draft. When that happens, Responses from different paths will not be merged. They will be sent separately to the originator. In summary, if not all the routers support this draft, it is up to the client program to parse and handle the partial information received in the Response packet. Heidi Ou & Asaeda Expires April 21, 2011 [Page 24] Internet-Draft Dual-Path Mtrace October 2010 6. IANA Considerations A new mtrace TLV type is introduced by this document. It is named "Mtrace2 Extended Query". Its purpose and format is described in Section 3.2.3 and Section 4.2. A new type value needs to be assigned for it. For now, 6 is used. This document also introduces several new types of Mtrace2 Augmented Response Blocks. The description is in Section 3.2.2 and Section 4.1. The values used by this document are listed in Figure 4. Heidi Ou & Asaeda Expires April 21, 2011 [Page 25] Internet-Draft Dual-Path Mtrace October 2010 7. Security Considerations The Security Consideration as documented in [MTRACE2] also applies to the protocol and procedures changes described in this document. Additionally, this draft introduces the concept of "Asynchronous Response" Section 3.2.6, there will be more request/response packets generated as a result of network topology change, especially during the window when temporary routing loops form. An implementation must take extra care to prevent excessive mtrace packets. This can be done either by rate limiting the number of asynchronous requests generated, or by rate limiting the response sent. Heidi Ou & Asaeda Expires April 21, 2011 [Page 26] Internet-Draft Dual-Path Mtrace October 2010 8. Acknowledgments The authors would like to thank Yiqun Cai for his comments. Heidi Ou & Asaeda Expires April 21, 2011 [Page 27] Internet-Draft Dual-Path Mtrace October 2010 9. References 9.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 9.2. informative References [MOFRR] Karan, A., Filsfils, C., and D. Farinacci, "Multicast Only Fast Re-Route", draft-karan-mofrr-00.txt (work in progress), July 2010. [MTID] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join- Attribute", draft-ietf-pim-mtid-05.txt (work in progress), September 2010. [MTRACE2] Asada, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mbone-mtrace-v2-07.txt (work in progress), July 2010. Heidi Ou & Asaeda Expires April 21, 2011 [Page 28] Internet-Draft Dual-Path Mtrace October 2010 Authors' Addresses Heidi Ou Cisco Systems, Inc. Tasman Drive San Jose, CA 95134 USA Email: hou@cisco.com Hitoshi Asaeda Keio University Graduate School of Media and Governance Fujisawa, Kanagawa 252-0882 Japan Email: asaeda@wide.ad.jp Heidi Ou & Asaeda Expires April 21, 2011 [Page 29]