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]