One document matched: draft-ietf-msdp-traceroute-00.txt
Internet Engineering Task Force W. Fenner
INTERNET-DRAFT AT&T Labs - Research
draft-ietf-msdp-traceroute-00.txt D. Meyer
cisco Systems
March, 2000
Expires September 2000
MSDP Traceroute
Status of this Memo
This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its Areas, and its
Working Groups. Note that other groups may also distribute working doc-
uments as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other docu-
ments at any time. It is not appropriate to use Internet Drafts as ref-
erence material or to cite them other than as a "working draft" or "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.
Distribution of this document is unlimited.
Abstract
In order to diagnose problems with the Peer-RPF-Flooding mechanisms
in the Multicast Source Discovery Protocol [MSDP], we introduce a
method of tracing the path that an SA message should have taken,
along with collecting statistics along that path. This occurs in a
way similar to multicast traceroute [MTRACE], with each router
appending information about this hop and forwarding the message
towards the desired RP.
This document is a product of the MSDP working group within the Internet
Engineering Task Force. Comments are solicited and should be addressed
to the working group's mailing list at msdp@network-services.uoregon.edu
Fenner, Meyer Expires September 2000 [Page 1]
Internet Draft draft-ietf-msdp-traceroute-00.txt March, 2000
and/or the authors.
Fenner, Meyer Expires September 2000 [Page 2]
Internet Draft draft-ietf-msdp-traceroute-00.txt March, 2000
1. Introduction
One of the key problems in the deployment of MSDP [MSDP] infrastructures
has been the inability to trace the path taken by MSDP control packets.
The protocol specified in the document addresses this problem by provid-
ing a traceroute facility for MSDP Source Active (SA) Messages. It is
important to note that, with the exception of data encapsulated in SA
messages, MSDP traceroute traces a path through the MSDP control plane.
It is important to note that the MSDP control path need not be the same
as the path followed by data packets.
As is the case for multicast traceroute, the goals of MSDP traceroute
include
o To be able to trace the path that a SA message would take from some
source router (RP) to some destination route (RP).
o To be able to isolate SA Message loss problems
o To be able to isolate configuration problems (e.g., TTL threshold).
o To minimize packets sent (e.g. no flooding, no implosion).
1.1. Definitions
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 RFC 2119 [RFC2119].
2. Originating an MSDP Traceroute Query
As is the case for other kinds of traceroute, both routers and hosts
will want to originate MSDP traceroute queries.
2.1. Routers Originating an MSDP Traceroute Query
When a router originates an MSDP traceroute Query, it formulates the
Query by filling its first block and unicasts the Query packet its RPF
neighbor toward the specified RP. Note that this is unlike multicast
traceroute, in which the Query is sent to the last-hop multicast router
for the destination, converted into a Request, and fowarded back towards
the source and group.
Fenner, Meyer Expires September 2000 [Page 3]
Internet Draft draft-ietf-msdp-traceroute-00.txt March, 2000
2.2. Hosts Originating an MSDP Traceroute Query
When a host originates an MSDP traceroute Query, it formulates the Query
by filling its first block with the RP (and optionally the source and
group), and then unicasts the UDP encapsulated Query packet to the spec-
ified RP [means UDP encapsulation has to be supported]. The RP must
store state that describes the host that made the query [security stuff
here]. If a router receives a Query packet and is not running MSDP, the
router discards the packet and returns a response with error code TBD
[do we want a notification for this in the MSDP spec?]
3. Packet Formats
Encapsulated in 2 different MSDP TLVs:
In-progress MSDP traceroute: ...
MSDP traceroute answer: ...
Fixed request header contains S, G, RP, query ID, current router pointer
(for returning packet HBH). Variable length request header contains
optional data (TBD, must be skipped by implementations that don't sup-
port it).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| skip hops | max hops | addl length | rtr pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... maxhops*4 octets of router addresses ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... addl length*4 octets of additional request data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fenner, Meyer Expires September 2000 [Page 4]
Internet Draft draft-ietf-msdp-traceroute-00.txt March, 2000
3.1. Source Address
Source in (S,G,RP)
3.2. Group Address
Group in (S,G,RP)
3.3. RP Address
RP in (S,G,RP)
3.4. Query ID
This field is used as a unique identifier for this traceroute
request so that duplicate or delayed responses may be detected.
3.5. skip hops
The number of hops that have been skipped in this request. This
allows for partial replies.
3.6. max hops
The max. # of hops requested in this traceroute request.
3.7. addl length
Length (in units of 4 octets) of accompanying additional request
data.
3.8. rtr pointer
The rtr pointer is a pointer into the router addresses table. When
the query is being filled in (outbound) the rtr pointer points to
the next available entry. On return to the query originator, it
points to the next hop back (toward the originator).
3.9. router addresses
Table of the outgoing interfaces that this request has traversed.
Inserted by requestor, max hops * 4 octets.
3.10. optional data
Optional data, addl length * 4 octets long.
Fenner, Meyer Expires September 2000 [Page 5]
Internet Draft draft-ietf-msdp-traceroute-00.txt March, 2000
Fixed part of response block contains: - my IP address on outgoing
interface (in the routing block) - RPF peer - flag: (S,G,RP) present? -
flag: hit source - who I learned this SA from - msdpSACacheInSAs - msdp-
SACacheInDataPackets - msdpSACacheUpTime - msdpSACacheExpiryTime Vari-
able length part to go with request's variable length part.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addl length | MBZ | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count of SA messages received for this (S,G,RP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count of encapsulated data packets received for this (S,G,RP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA cache entry uptime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA cache entry expiry time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... addl length * 4 octets of additional data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Protocol Processing
4.1. Processing an in-progress traceroute
The following steps are taken when receiving an in-progress tracer-
oute:
1. If the # of hops have already been exceeded, then something
bad happened; just turn it into a response and return it.
2. Append an empty router response to the packet. If this action
causes the message to exceed MSDP's 1400-byte MTU, follow the
steps in section XXX, Returning Partial Responses, and then
continue with the now-smaller packet.
3. Look up the SA cache information for the (S,G,RP). If no SA
cache entry exists, fill in zeros for these values.
4. Look up the MSDP RPF neighbor for the RP, using the MSDP peer-
RPF-forwarding rules in the MSDP spec [MSDP].
Fenner, Meyer Expires September 2000 [Page 6]
Internet Draft draft-ietf-msdp-traceroute-00.txt March, 2000
5. This lookup returns a peering. Insert your IP address on this
peering into the current hop in the router info table, and
increment the rtr count field. Insert the peer's address into
the Next-Hop Router Address field.
6. If the RPF neighbor lookup failed, or if the rtr pointer ==
max hops, switch to a response and return this packet. Other-
wise, unicast the current packet over the MSDP peering to the
RPF neighbor.
4.2. Returning partial responses
Turn the MSDP type from traceroute request to traceroute response.
Decrement the router pointer.
If the router pointer was already 0, you're the one who requested
the trace.
Otherwise, send the message on your MSDP peering with the router at
the current router pointer's offset in the router table.
4.3. Processing a traceroute answer
Decrement the router pointer.
If the router pointer was already 0, you're the one who requested
the trace.
Otherwise, send the message on your MSDP peering with the router at
the current router pointer's offset in the router table.
5. Security Considerations
(flesh these out)
6. References
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119/BCP 14, Harvard University,
March 1997.
MSDP Farinacci, D., et. al. "Multicast Source Discovery Proto-
col (MSDP)", draft-ietf-msdp-spec-05.txt, February, 2000.
Fenner, Meyer Expires September 2000 [Page 7]
Internet Draft draft-ietf-msdp-traceroute-00.txt March, 2000
MTRACE Fenner, W. and S. Casner, "A "traceroute" facility for IP
Multicast", draft-ietf-idmr-traceroute-ipm-06.txt, March,
2000.
7. Author's Addresses
William C. Fenner
AT&T Labs - Research
75 Willow Rd
Menlo Park, CA 94025
Phone: +1 650 330 7893
Email: fenner@research.att.com
David Meyer
Cisco Systems
170 Tasman Drive
San Jose, CA, 95134
Phone: +1 541 915 0094
Email: dmm@cisco.com
Fenner, Meyer Expires September 2000 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:40 |