< draft-ietf-msdp-spec-11.txt		draft-ietf-msdp-spec-12.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
	August, 2001		September, 2001
	Multicast Source Discovery Protocol (MSDP)		Multicast Source Discovery Protocol (MSDP)
	<draft-ietf-msdp-spec-11.txt>		<draft-ietf-msdp-spec-12.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 16 ¶		skipping to change at page 3, line 16 ¶
	When an RP in a PIM-SM domain first learns of a new sender, e.g. via		When an RP in a PIM-SM domain first learns of a new sender, e.g. via
	PIM register messages, it constructs a "Source-Active" (SA) message		PIM register messages, it constructs a "Source-Active" (SA) message
	and sends it to its MSDP peers. The SA message contains the following		and sends it to its MSDP peers. The SA message contains the following
	fields:		fields:
	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.
			Note that an RP that isn't a DR on a shared network SHOULD NOT
			originate SA's for directly connected sources on that shared network.
	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 for the details of peer-RPF		is called an "RPF peer". See section 14 for the details of 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
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	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 so 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 180 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. Finally, an originating RP SHOULD
	after a source has been active can get data quickly via a non-caching		trigger the transmission of an SA message as soon as it receives data
	RP. Finally, an originating RP SHOULD trigger the transmission of an		from an internal source for the first time.
	SA message as soon as it receives data from an internal source for
	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
	skipping to change at page 5, line 11 ¶		skipping to change at page 5, line 11 ¶
	implemenation SHOULD send all cached SA messages when a connection is		implemenation SHOULD send all cached SA messages when a connection is
	established. Finally, the timer is deleted when the MSDP process is		established. Finally, the timer 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 [SA-Advertisement-
			Period] + [SA-Hold-Down-Period].
	8.4. SA-Hold-Down Timer		8.4. SA-Hold-Down Timer
	When an SA message is received which creates (S,G) state, the		When an SA message is received which creates (S,G) state, the
	(S,G)-SA message will be forwarded if the peer-RPF check succeeds. If		(S,G)-SA message will be forwarded if the peer-RPF check succeeds. If
	the peer-RPF check succeeds and the (S,G)-SA message is not already		the peer-RPF check succeeds and the (S,G)-SA message is not already
	in the SA cache, then the (S,G)-SA-Hold-Down timer is set to [SA-		in the SA cache, then the (S,G)-SA-Hold-Down timer is set to [SA-
	Hold-Down-Period] seconds. When an (S,G)-SA message is received and		Hold-Down-Period] seconds. When an (S,G)-SA message is received and
	an (S,G) entry already exists, the message is forwarded only if the		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		(S,G)-SA-Hold-Down timer is not running. [SA-Hold-Down-Period] SHOULD
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 32 ¶
	N is the RPF neighbor of X with respect to R if		N is the RPF neighbor of X with respect to R if
	(i). N == R (X has an MSDP peering with R).		(i). N == R (X has an MSDP peering with R).
	(ii). N is the BGP NEXT_HOP of the active RPF route		(ii). N is the BGP NEXT_HOP of the active RPF route
	for R.		for R.
	(iii). The active RPF route for R is learned through a		(iii). The active RPF route for R is learned through a
	distance-vector or path-vector routing protocol		distance-vector or path-vector routing protocol
	(e.g. BGP, RIP, DVMRP) and N is the neighbor that		(e.g. BGP, RIP, DVMRP) and N is the neighbor that
	advertised the active RPF route for R.		advertised the active RPF route for R if the
			route was learned via a distance-vector or
			path-vector protocol, or N is the IGP next hop
			for if R was learned via a link-state protocol.
	(iv). N resides in an AS that is in the AS_PATH of the active		(iv). N resides in an AS that is in the AS_PATH of the active
	RPF route for R, and N has the highest IP address among		RPF route for R, and N has the highest IP address among
	the MSDP peers that reside in ASs in that AS_PATH.		the MSDP peers that reside in ASs in that AS_PATH.
	(v). N is configured as the static RPF-peer for R.		(v). N is configured as the static RPF-peer for R.
	14.3. MSDP static RPF-peer semantics		14.3. MSDP static RPF-peer semantics
	If none of the rules (i) - (iv) are able to determine an RPF peer for		If none of the rules (i) - (iv) are able to determine an RPF peer for
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 29 ¶
	state, they do not cause a state transition. Appropriate actions are		state, they do not cause a state transition. Appropriate actions are
	listed for each event.		listed for each event.
	*) KeepAlive timer expired:		*) KeepAlive timer expired:
	-> Send KeepAlive TLV		-> Send KeepAlive TLV
	-> Set KeepAlive timer to [KeepAlive-Period]		-> Set KeepAlive timer to [KeepAlive-Period]
	*) KeepAlive TLV received:		*) KeepAlive TLV received:
	-> Set Hold Timer to [HoldTime-Period]		-> Set Hold Timer to [HoldTime-Period]
	*) Source-Active TLV received:		*) Source-Active TLV received:
	-> Set Hold Timer to [HoldTime-Period]		-> Set Hold Timer to [HoldTime-Period]
	-> Run Peer-RPF Forwarding algorithm (if caching, consider		-> Run Peer-RPF Forwarding algorithm (consider SA-Hold-Down
	SA-Hold-Down Timer and SA-State Timer)		Timer and SA-State Timer)
	-> Set KeepAlive timer to [KeepAlive-Period] for those peers the		-> Set KeepAlive timer to [KeepAlive-Period] for those peers
	Source-Active TLV is forwarded to		the Source-Active TLV is forwarded to
	-> Send information to PIM-SM		-> Send information to PIM-SM
	-> If caching, store information		-> Store information in cache
	*) Source-Active Request TLV received:		*) Source-Active Request TLV received:
	-> Set Hold Timer to [HoldTime-Period]		-> Set Hold Timer to [HoldTime-Period]
	-> If SA-Requests are accepted, send Source-Active Response TLV		-> If SA-Requests are accepted, send Source-Active Response
	and set KeepAlive timer to [KeepAlive-Period]		TLV and set KeepAlive timer to [KeepAlive-Period]
	*) Source-Active Response TLV received:		*) Source-Active Response TLV received:
	-> Set Hold Timer to [HoldTime-Period]		-> Set Hold Timer to [HoldTime-Period]
	-> If a corresponding SA-Request were previously sent, send		-> If a corresponding SA-Request were previously sent, send
	information to PIM-SM. If not, an error has occured (event 11		information to PIM-SM. If not, an error has occured
	above)		(event 11 above)
	-> If caching, store information		-> Store information in cache
	15.4. Peer-independent Events		15.4. Peer-independent Events
	There are also a number of events that affect more than one peering		There are also a number of events that affect more than one peering
	session, but still require actions to be performed on a per-peer		session, but still require actions to be performed on a per-peer
	basis. If the MSDP speaker does not cache SA messages, ignore all		basis.
	events and actions pertaining to caching.
	*) SA-Advertisement-Timer expired:		*) SA-Advertisement-Timer expired:
	-> Start periodic transmission of Source-Active TLV(s)		-> Start periodic transmission of Source-Active TLV(s)
	-> Set KeepAlive timer to [KeepAlive-Period] each time a		-> Set KeepAlive timer to [KeepAlive-Period] each time a
	Source-Active TLV is sent		Source-Active TLV is sent
	*) MSDP learns of a new active internal source (e.g. PIM-SM		*) MSDP learns of a new active internal source (e.g. PIM-SM
	register received for a new source):		register received for a new source):
	-> Send Source-Active TLV		-> Send Source-Active TLV
	-> Set KeepAlive timer to [KeepAlive-Period]		-> Set KeepAlive timer to [KeepAlive-Period]
	*) Source-Active Request triggered (event not specified here):		*) Source-Active Request triggered (event not specified here):
	skipping to change at page 22, line 49 ¶		skipping to change at page 23, line 10 ¶
	request at a MSDP peer when an invalid group address requested.		request at a MSDP peer when an invalid group address requested.
	When a MSDP peer receives a request for an invalid group, it returns		When a MSDP peer receives a request for an invalid group, it returns
	the following notification:		the following notification:
	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 | 12 |O| 2 |		| 5 | 12 |O| 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2 | Reserved |		| 1 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address |		| Group Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	17.3. SA-Message/SA-Response Error Handling		17.3. SA-Message/SA-Response Error Handling
	The SA-Message/SA-Response Error code is used to signal the receipt		The SA-Message/SA-Response Error code is used to signal the receipt
	of a erroneous SA Message at an MSDP peer, or the receipt of an SA-		of a erroneous SA Message at an MSDP peer, or the receipt of an SA-
	Response Message by a peer that did not issue a SA-Request. It has		Response Message by a peer that did not issue a SA-Request. It has
	the following form:		the following form:
End of changes. 15 change blocks.
	25 lines changed or deleted		28 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/