< draft-ietf-msdp-spec-10.txt		draft-ietf-msdp-spec-11.txt >
	Network Working Group David Meyer (Editor)		Network Working Group David Meyer (Editor)
	INTERNET DRAFT Bill Fenner (Editor)		INTERNET DRAFT Bill Fenner (Editor)
	Category Standards Track		Category Standards Track
	May, 2001		August, 2001
	Multicast Source Discovery Protocol (MSDP)		Multicast Source Discovery Protocol (MSDP)
	<draft-ietf-msdp-spec-10.txt>		<draft-ietf-msdp-spec-11.txt>
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.		all provisions of Section 10 of RFC 2026.
	Internet Drafts are working documents of the Internet Engineering		Internet Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	o Source address of the data source.		o Source address of the data source.
	o Group address the data source sends to.		o Group address the data source sends to.
	o IP address of the RP.		o IP address of the RP.
	Each MSDP peer receives and forwards the message away from the RP		Each MSDP peer receives and forwards the message away from the RP
	address in a "peer-RPF flooding" fashion. The notion of peer-RPF		address in a "peer-RPF flooding" fashion. The notion of peer-RPF
	flooding is with respect to forwarding SA messages. The Multicast RPF		flooding is with respect to forwarding SA messages. The Multicast RPF
	Routing Information Base (MRIB) is examined to determine which peer		Routing Information Base (MRIB) is examined to determine which peer
	towards the originating RP of the SA message is selected. Such a peer		towards the originating RP of the SA message is selected. Such a peer
	is called an "RPF peer". See section 14 below for the details of		is called an "RPF peer". See section 14 for the details of peer-RPF
	peer-RPF forwarding.		forwarding.
	If the MSDP peer receives the SA from a non-RPF peer towards the		If the MSDP peer receives the SA from a non-RPF peer towards the
	originating RP, it will drop the message. Otherwise, it forwards the		originating RP, it will drop the message. Otherwise, it forwards the
	message to all its MSDP peers (except the one from which it received		message to all its MSDP peers (except the one from which it received
	the SA message).		the SA message).
	When an MSDP peer which is also an RP for its own domain receives a		When an MSDP peer which is also an RP for its own domain receives a
	new SA message, it determines if it has any group members interested		new SA message, it determines if it has any group members interested
	in the group which the SA message describes. That is, the RP checks		in the group which the SA message describes. That is, the RP checks
	for a (*,G) entry with a non-empty outgoing interface list; this		for a (*,G) entry with a non-empty outgoing interface list; this
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	conventions. Finally, if an RP in a domain receives a PIM Join		conventions. Finally, if an RP in a domain receives a PIM Join
	message for a new group G, the RP SHOULD trigger a (S,G) join event		message for a new group G, the RP SHOULD trigger a (S,G) join event
	for each SA for that group in its cache.		for each SA for that group in its cache.
	This procedure has been affectionately named flood-and-join because		This procedure has been affectionately named flood-and-join because
	if any RP is not interested in the group, they can ignore the SA		if any RP is not interested in the group, they can ignore the SA
	message. Otherwise, they join a distribution tree.		message. Otherwise, they join a distribution tree.
	7. Caching		7. Caching
	A MSDP speaker SHOULD cache SA messages. Caching allows pacing of		A MSDP speaker MUST cache SA messages. Caching allows pacing of MSDP
	MSDP messages as well as reducing join latency for new receivers of a		messages as well as reducing join latency for new receivers of a
	group G at an originating RP which has existing MSDP (S,G) state. In		group G at an originating RP which has existing MSDP (S,G) state. In
	addition, caching greatly aids in diagnosis and debugging of various		addition, caching greatly aids in diagnosis and debugging of various
	problems.		problems.
	8. Timers		8. Timers
	The main timers for MSDP are: SA-Advertisement-Timer, SA-Hold-Down-		The main timers for MSDP are: SA-Advertisement-Timer, SA-Hold-Down-
	Timer, SA Cache Entry timer, KeepAlive timer, ConnectRetry and Peer		Timer, SA Cache Entry timer, KeepAlive timer, ConnectRetry and Peer
	Hold Timer. Each is considered below.		Hold Timer. Each is considered below.
	8.1. SA-Advertisement-Timer		8.1. SA-Advertisement-Timer
	RPs which originate SA messages do it periodically as long as there		RPs which originate SA messages do it periodically as long as there
	is data being sent by the source. There is one SA-Advertisement-Timer		is data being sent by the source. There is one SA-Advertisement-Timer
	covering the sources that an RP may advertise. [SA-Advertisement-		covering the sources that an RP may advertise. [SA-Advertisement-
	Period] MUST be 60 seconds. An RP MUST not send more than one		Period] MUST be 60 seconds. An RP MUST not send more than one
	periodic SA message for a given (S,G) within an SA Advertisement		periodic SA message for a given (S,G) within an SA Advertisement
	interval. Originating periodic SA messages is required to keep		interval. Originating periodic SA messages is required to keep
	announcements alive in caches, and so that new receivers who join		announcements alive in caches, and so that new receivers who join
	after a source has been active can get data quickly via a non-caching		after a source has been active can get data quickly via a non-caching
	RP. Finally, an originating RP SHOULD trigger the transmission of an		RP. Finally, an originating RP SHOULD trigger the transmission of an
	SA message as soon as it receives data from an internal source for		SA message as soon as it receives data from an internal source for
	the first time.		the first time.
	8.2. SA-Advertisement-Timer Processing		8.2. SA-Advertisement-Timer Processing
	An RP MUST spread the generation of periodic SA messages over its		An RP MUST spread the generation of periodic SA messages over its
	reporting interval (i.e. SA-Advertisement-Period). An RP starts the		reporting interval (i.e. SA-Advertisement-Period). An RP starts the
	SA-Advertisement-Timer when the MSDP process is configured. When the		SA-Advertisement-Timer when the MSDP process is configured. When the
	timer expires, an RP resets the timer to [SA-Advertisement-Period]		timer expires, an RP resets the timer to [SA-Advertisement-Period]
	seconds, and begins the advertisement of its active sources. Active		seconds, and begins the advertisement of its active sources. Active
	sources are advertised in the following manner: An RP packs its		sources are advertised in the following manner: An RP packs its
	active sources into an SA message until the largest MSDP packet that		active sources into an SA message until the largest MSDP packet that
	can be sent is built or there are no more sources, and then sends the		can be sent is built or there are no more sources, and then sends the
	message. This process is repeated periodically within the SA-		message. This process is repeated periodically within the SA-
	Advertisement-Period in such a way that all of the RP's sources are		Advertisement-Period in such a way that all of the RP's sources are
	advertised. Note that the largest MSDP packet that can be sent has		advertised. Note that since MSDP is a periodic protocol, an
	size that is the minimum of MTU of outgoing link minus size of TCP		implemenation SHOULD send all cached SA messages when a connection is
	and IP headers, and 1400 (largest MSDP packet). Finally, the timer is		established. Finally, the timer is deleted when the MSDP process is
	deleted when the MSDP process is deconfigured.		deconfigured.
	8.3. SA Cache Timeout (SA-State Timer)		8.3. SA Cache Timeout (SA-State Timer)
	Each entry in an SA Cache has an associated SA-State Timer. A		Each entry in an SA Cache has an associated SA-State Timer. A
	(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially		(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
	received by a MSDP peer. The timer is reset to [SA-State-Period] if		received by a MSDP peer. The timer is reset to [SA-State-Period] if
	another (S,G)-SA message is received before the (S,G)-SA-State Timer		another (S,G)-SA message is received before the (S,G)-SA-State Timer
	expires. [SA-State-Period] MUST NOT be less than 90 seconds.		expires. [SA-State-Period] MUST NOT be less than 90 seconds.
	8.4. SA-Hold-Down Timer		8.4. SA-Hold-Down Timer
	The per-(S,G) timer is set to [SA-Hold-Down-Period] when forwarding		When an SA message is received which creates (S,G) state, the
	an SA message, and a SA message MUST only be forwarded when its		(S,G)-SA message will be forwarded if the peer-RPF check succeeds. If
	associated timer is not running. [SA-Hold-Down-Period] SHOULD be set		the peer-RPF check succeeds and the (S,G)-SA message is not already
	to 30 seconds. A MSDP peer MUST NOT forward a (S,G)-SA message it has		in the SA cache, then the (S,G)-SA-Hold-Down timer is set to [SA-
	received in during the previous [SA-Hold-Down-Period] seconds.		Hold-Down-Period] seconds. When an (S,G)-SA message is received and
	Finally, the timer is deleted when the SA cache entry is deleted.		an (S,G) entry already exists, the message is forwarded only if the
			(S,G)-SA-Hold-Down timer is not running. [SA-Hold-Down-Period] SHOULD
			be set to 30 seconds.
	8.5. Peer Hold Timer		8.5. Peer Hold Timer
	If a system has not received any MSDP message within the period		If a system has not received any MSDP message within the period
	specified by the Hold Timer, then a Notification message with Hold		specified by the Hold Timer, then a Notification message with Hold
	Timer Expired Error Code MUST be sent and the MSDP connection MUST be		Timer Expired Error Code MUST be sent and the MSDP connection MUST be
	closed. [HoldTime-Period] MUST be at least three seconds. The		closed. [HoldTime-Period] MUST be at least three seconds. The
	recommended value for [HoldTime-Period] is 90 seconds.		recommended value for [HoldTime-Period] is 90 seconds.
	The Hold Timer is initialized to [HoldTime-Period] when the peer's		The Hold Timer is initialized to [HoldTime-Period] when the peer's
	transport connection is established, and is reset to [HoldTime-		transport connection is established, and is reset to [HoldTime-
	Period] when any MSDP message is received. Finally, the timer is		Period] when any MSDP message is received. Finally, the timer is
	deleted when the peer's transport connection is closed.		deleted when the peer's transport connection is closed.
	8.6. KeepAlive Timer		8.6. KeepAlive Timer
	Once an MSDP transport connection is established, each side of the		Once an MSDP transport connection is established, each side of the
	connection sends a KeepAlive message and sets a KeepAlive timer. If		connection sends a KeepAlive message and sets a KeepAlive timer. If
	the KeepAlive timer expires, the local system sends a KeepAlive		the KeepAlive timer expires, the local system sends a KeepAlive
	message and restarts its KeepAlive timer.		message and restarts its KeepAlive timer.
	The KeepAlive timer is set to [KeepAlive-Period] when the peer comes		The KeepAlive timer is set to [KeepAlive-Period] when the peer comes
	skipping to change at page 15, line 32 ¶		skipping to change at page 17, line 12 ¶
	In addition, the following TLV Types are assigned but not described		In addition, the following TLV Types are assigned but not described
	in this memo:		in this memo:
	Code Type		Code Type
	===========================================================		===========================================================
	6 MSDP traceroute in progress		6 MSDP traceroute in progress
	7 MSDP traceroute reply		7 MSDP traceroute reply
	16.2.1. IPv4 Source-Active TLV		16.2.1. IPv4 Source-Active TLV
	The maximum size SA message that can be sent is 1400 octets. If an		The maximum size SA message that can be sent is 9192 octets. The 9192
	MSDP peer needs to originate a message with information greater than		octet size does not include the TCP, IP, layer-2 headers.
	1400 octets, it sends successive 1400 octet or smaller messages. The
	1400 octet size does not include the TCP, IP, layer-2 headers.
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | x + y | Entry Count |		| 1 | x + y | Entry Count |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RP Address |		| RP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Sprefix Len | \		| Reserved | Sprefix Len | \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
	skipping to change at page 18, line 22 ¶		skipping to change at page 20, line 7 ¶
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 4 | 3 |		| 4 | 3 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The length of the message is 3 octets which encompasses the one octet		The length of the message is 3 octets which encompasses the one octet
	Type field and the two octet Length field.		Type field and the two octet Length field.
	16.2.5. Notification TLV		16.2.5. Notification TLV
	A Notification message is sent when an error condition is detected,		A Notification message is sent when an error condition is detected,
	and has the following form:		and has the following form:
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 5 | x + 5 |O| Error Code |		| 5 | x + 5 |O| Error Code |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Error subcode | ... |		| Error subcode | ... |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ |
	| Data |		| Data |
	skipping to change at page 19, line 17 ¶		skipping to change at page 20, line 47 ¶
	1 Message Header Error Section 17.1		1 Message Header Error Section 17.1
	2 SA-Request Error Section 17.2		2 SA-Request Error Section 17.2
	3 SA-Message/SA-Response Error Section 17.3		3 SA-Message/SA-Response Error Section 17.3
	4 Hold Timer Expired Section 17.4		4 Hold Timer Expired Section 17.4
	5 Finite State Machine Error Section 17.5		5 Finite State Machine Error Section 17.5
	6 Notification Section 17.6		6 Notification Section 17.6
	7 Cease Section 17.7		7 Cease Section 17.7
	Error subcode:		Error subcode:
	This one-octet unsigned integer provides more specific information		This one-octet unsigned integer provides more specific information
	about the reported error. Each Error Code may have one or more		about the reported error. Each Error Code may have one or more Error
	Error
	Subcodes associated with it. If no appropriate Error Subcode is		Subcodes associated with it. If no appropriate Error Subcode is
	defined, then a zero (Unspecific) value is used for the Error		defined, then a zero (Unspecific) value is used for the Error Subcode
	Subcode
	field, and the O-bit must be cleared (i.e. the connection will be		field, and the O-bit must be cleared (i.e. the connection will be
	closed). The used notation in the error description below is: MC =		closed). The used notation in the error description below is: MC =
	Must Close connection = O-bit clear; CC = Can Close connection =		Must Close connection = O-bit clear; CC = Can Close connection =
	O-bit MAY be cleared.		O-bit MAY be cleared.
	Message Header Error subcodes:		Message Header Error subcodes:
	0 - Unspecific (MC)		0 - Unspecific (MC)
	2 - Bad Message Length (MC)		2 - Bad Message Length (MC)
	3 - Bad Message Type (CC)		3 - Bad Message Type (CC)
	skipping to change at page 25, line 8 ¶		skipping to change at page 26, line 34 ¶
	In absence of any fatal errors (that are indicated in this section),		In absence of any fatal errors (that are indicated in this section),
	an MSDP node may choose at any given time to close its MSDP		an MSDP node may choose at any given time to close its MSDP
	connection by sending the Notification message with Error Code Cease.		connection by sending the Notification message with Error Code Cease.
	However, the Cease Notification message MUST NOT be used when a fatal		However, the Cease Notification message MUST NOT be used when a fatal
	error indicated by this section does exist.		error indicated by this section does exist.
	18. SA Data Encapsulation		18. SA Data Encapsulation
	This section describes UDP, GRE, and TCP encapsulation of data		This section describes UDP, GRE, and TCP encapsulation of data
	packets to be included with SA messages. Encapsulation type is a		packets to be included with SA messages. Encapsulation type is a
	configuration option.		configuration option.
	18.1. UDP Data Encapsulation		18.1. UDP Data Encapsulation
	Data packets MAY be encapsulated in UDP. In this case, the UDP		Data packets MAY be encapsulated in UDP. In this case, the UDP
	pseudo-header has the following form:		pseudo-header has the following form:
	0 1 2 3		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		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 Port | Destination Port |		| Source Port | Destination Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Checksum |		| Length | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Origin RP Address |		| Origin RP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Source port, Destination Port, Length, and Checksum are used		The Source port, Destination Port, Length, and Checksum are used
	according to RFC 768. Source and Destination ports are known via an		according to RFC 768. Source and Destination ports are known via
	implementation-specific method (e.g. per-peer configuration).		an implementation-specific method (e.g. per-peer configuration).
	Checksum		Checksum
	The checksum is computed according to RFC 768 [RFC768].		The checksum is computed according to RFC 768 [RFC768].
	Originating RP Address		Originating RP Address
	The Originating RP Address is the address of the RP sending		The Originating RP Address is the address of the RP sending
	the encapsulated data.		the encapsulated data.
	18.2. GRE Encapsulation		18.2. GRE Encapsulation
	skipping to change at page 27, line 35 ¶		skipping to change at page 28, line 35 ¶
	As discussed earlier, encapsulation of data in SA messages MAY be		As discussed earlier, encapsulation of data in SA messages MAY be
	supported for backwards compatibility with legacy MSDP peers.		supported for backwards compatibility with legacy MSDP peers.
	19. IANA Considerations		19. IANA Considerations
	The IANA should assign 0x0009 from the IANA SNAP Protocol IDs [IANA]		The IANA should assign 0x0009 from the IANA SNAP Protocol IDs [IANA]
	to MSDP-GRE-ProtocolType.		to MSDP-GRE-ProtocolType.
	20. Security Considerations		20. Security Considerations
	An MSDP implementation MAY use IPsec [RFC2401] or keyed MD5 [RFC1828]		An MSDP implementation MUST use IPsec [RFC2401] to secure control
	to secure control messages. When encapsulating data packets in GRE,		messages. In particular, the TCP connection between MSDP peers MUST
			be secured using IPsec. When encapsulating data packets in GRE,
	security should be relatively similar to security in a normal IPv4		security should be relatively similar to security in a normal IPv4
	network, as routing using GRE follows the same routing that IPv4 uses		network, as routing using GRE follows the same routing that IPv4 uses
	natively. Route filtering will remain unchanged. However packet		natively. Route filtering will remain unchanged. However packet
	filtering at a firewall requires either that a firewall look inside		filtering at a firewall requires either that a firewall look inside
	the GRE packet or that the filtering is done on the GRE tunnel		the GRE packet or that the filtering is done on the GRE tunnel
	endpoints. In those environments in which this is considered to be a		endpoints. In those environments in which this is considered to be a
	security issue it may be desirable to terminate the tunnel at the		security issue it may be desirable to terminate the tunnel at the
	firewall.		firewall.
	21. Acknowledgments		21. Acknowledgments
	The editors would like to thank the original authors, Dino Farinacci,		The editors would like to thank the original authors, Dino Farinacci,
	Yakov Rehkter, Peter Lothberg, Hank Kilmer, and Jermey Hall for their		Yakov Rehkter, Peter Lothberg, Hank Kilmer, and Jermey Hall for their
	orginal contribution to the MSDP specification. In addition, Bill		orginal contribution to the MSDP specification. In addition, Bill
	Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner,		Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner,
	John Zwiebel, Cristina Radulescu-Banu, Brian Edwards, Selina		John Zwiebel, Cristina Radulescu-Banu, Brian Edwards, Selina
	Priestley and IJsbrand Wijnands provided useful and productive design		Priestley and IJsbrand Wijnands provided useful and productive design
	feedback and comments. In addition to many other contributions, Tom		feedback and comments. In addition to many other contributions, Tom
	Pusateri, Kristofer.Warell, Henning Eriksson, and Thomas Eriksson		Pusateri, Kristofer Warell, Henning Eriksson, and Thomas Eriksson
	helped to clarify the connection state machine, Dave Thaler helped to		helped to clarify the connection state machine, Dave Thaler helped to
	clarify the Notification message types. Ravi Shekhar helped clarify		clarify the Notification message types. Ravi Shekhar helped clarify
	the semantics of mesh-groups, and countless others helped to clarify		the semantics of mesh-groups, and countless others helped to clarify
	the Peer-RPF rules.		the Peer-RPF rules.
	22. Editors' Address:		22. Editors' Address:
	David Meyer		David Meyer
	Cisco Systems, Inc.		Sprint
	170 Tasman Drive		12502 Sunrise Valley Drive
	San Jose, CA, 95134		Reston VA, 20191
	Email: dmm@cisco.com		Email: dmm@sprint.net
	Bill Fenner		Bill Fenner
	AT&T Labs -- Research		AT&T Labs -- Research
	75 Willow Road		75 Willow Road
	Menlo Park, CA 94025		Menlo Park, CA 94025
	Email: fenner@research.att.com		Email: fenner@research.att.com
	23. REFERENCES		23. REFERENCES
	[IANA] www.iana.org		[IANA] http://www.iana.org
	[RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation
	(GRE)", RFC 2784, March 2000.
	[RFC768] Postel, J. "User Datagram Protocol", RFC 768, August,		[RFC768] Postel, J. "User Datagram Protocol", RFC 768, August,
	1980.		1980.
	[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",		[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",
	RFC 1191, November 1990.		RFC 1191, November 1990.
	[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4		[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
	(BGP-4)", RFC 1771, March 1995.		(BGP-4)", RFC 1771, March 1995.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
	the Internet Protocol", RFC 2401, November 1998.
	[RFC1828] P. Metzger and W. Simpson, "IP Authentication using
	Keyed MD5", RFC 1828, August, 1995.
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March, 1997.		Requirement Levels", RFC 2119, March, 1997.
	[RFC2283] Bates, T., Chandra, R., Katz, D., and Y. Rekhter.,		[RFC2283] Bates, T., Chandra, R., Katz, D., and Y. Rekhter.,
	"Multiprotocol Extensions for BGP-4", RFC 2283,		"Multiprotocol Extensions for BGP-4", RFC 2283,
	February 1998.		February 1998.
	[RFC2362] Estrin D., et al., "Protocol Independent Multicast -		[RFC2362] Estrin D., et al., "Protocol Independent Multicast -
	Sparse Mode (PIM-SM): Protocol Specification", RFC		Sparse Mode (PIM-SM): Protocol Specification", RFC
	2362, June 1998.		2362, June 1998.
	[RFC2365] Meyer, D. "Administratively Scoped IP Multicast", RFC		[RFC2365] Meyer, D. "Administratively Scoped IP Multicast", RFC
	2365, July, 1998.		2365, July, 1998.
			[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
			the Internet Protocol", RFC 2401, November 1998.
			[RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation
			(GRE)", RFC 2784, March 2000.
	24. Full Copyright Statement		24. Full Copyright Statement
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
End of changes. 21 change blocks.
	47 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/