< draft-ietf-msdp-spec-09.txt		draft-ietf-msdp-spec-10.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		May, 2001
	Multicast Source Discovery Protocol (MSDP)		Multicast Source Discovery Protocol (MSDP)
	<draft-ietf-msdp-spec-09.txt>		<draft-ietf-msdp-spec-10.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 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	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 the largest MSDP packet that can be sent has
	size that is the minimum of MTU of outgoing link minus size of TCP		size that is the minimum of MTU of outgoing link minus size of TCP
	and IP headers, and 1400 (largest MSDP packet). Finally, the timer is		and IP headers, and 1400 (largest MSDP packet). Finally, the timer is
	deleted when the MSDP process is deconfigured.		deleted when the MSDP process is 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		The per-(S,G) timer is set to [SA-Hold-Down-Period] when forwarding
	an SA message, and a SA message MUST only be forwarded when its		an SA message, and a SA message MUST only be forwarded when its
	associated timer is not running. [SA-Hold-Down-Period] SHOULD be set		associated timer is not running. [SA-Hold-Down-Period] SHOULD be set
	to 30 seconds. A MSDP peer MUST NOT forward a (S,G)-SA message it has		to 30 seconds. A MSDP peer MUST NOT forward a (S,G)-SA message it has
	received in during the previous [SA-Hold-Down-Period] seconds.		received in during the previous [SA-Hold-Down-Period] seconds.
	Finally, the timer is deleted when the SA cache entry is deleted.		Finally, the timer is deleted when the SA cache entry is deleted.
	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. [Hold-Time-Period] MUST be at least three seconds. A		closed. [HoldTime-Period] MUST be at least three seconds. The
	suggested value for [Hold-Time-Period] is 90 seconds.		recommended value for [HoldTime-Period] is 90 seconds.
	The Hold Timer is initialized to [Hold-Time-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 [Hold-Time-		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
	up. [KeepAlive-Period] SHOULD NOT be less than 75 seconds, and MUST		up. The timer is reset to [KeepAlive-Period] each time an MSDP
	NOT be less than [Hold-Time-Period]. The timer is reset to		message is sent to the peer, and reset when the timer expires.
	[KeepAlive-Period] each time an MSDP message is sent to peer, and		Finally, the KeepAlive timer is deleted when the peer's transport
	reset when the timer expires. Finally, the KeepAlive timer is deleted		connection is closed.
	when the peer's transport connection is closed.
			[KeepAlive-Period] MUST be less than [HoldTime-Period], and MUST be
			at least one second. The recommended value for [KeepAlive-Period] is
			75 seconds.
	8.7. ConnectRetry Timer		8.7. ConnectRetry Timer
	The ConnectRetry timer is used by an MSDP peer to transition from		The ConnectRetry timer is used by an MSDP peer to transition from
	INACTIVE to CONNECTING states. There is one timer per peer, and the		INACTIVE to CONNECTING states. There is one timer per peer, and the
	[ConnectRetry-Period] SHOULD be set to 30 seconds. The timer is		[ConnectRetry-Period] SHOULD be set to 30 seconds. The timer is
	initialized to [ConnectRetry-Period] when an MSDP peer's active		initialized to [ConnectRetry-Period] when an MSDP speaker attempts to
	connect attempt fails. When the timer expires, the peer retries the		actively open a TCP connection to its peer (see section 15, event E2,
	connection and the timer is reset to [ConnectRetry-Period]. It is		action A2 ). When the timer expires, the peer retries the connection
	deleted if either the connection transitions into ESTABLISHED state		and the timer is reset to [ConnectRetry-Period]. It is deleted if
	or the peer is deconfigured.		either the connection transitions into ESTABLISHED state or the peer
			is deconfigured.
	9. Intermediate MSDP Peers		9. Intermediate MSDP Peers
	Intermediate MSDP speakers do not originate periodic SA messages on		Intermediate MSDP speakers do not originate periodic SA messages on
	behalf of sources in other domains. In general, an RP MUST only		behalf of sources in other domains. In general, an RP MUST only
	originate an SA for a source which would register to it, and ONLY RPs		originate an SA for a source which would register to it, and ONLY RPs
	may originate SA messages.		may originate SA messages.
	10. SA Filtering and Policy		10. SA Filtering and Policy
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	SA message from R2. In this case, both R1 and R3 will send		SA message from R2. In this case, both R1 and R3 will send
	SA messages to each other (because they share common mesh-group		SA messages to each other (because they share common mesh-group
	C), but neither of them will forward any further the SA messages		C), but neither of them will forward any further the SA messages
	received from each other (as their peer-RPF neighbors do		received from each other (as their peer-RPF neighbors do
	not lie in mesh-group C).		not lie in mesh-group C).
	Note that since mesh-groups suspend peer-RPF checking of SAs received		Note that since mesh-groups suspend peer-RPF checking of SAs received
	from a mesh-group member ((i). above), they allow for mis-		from a mesh-group member ((i). above), they allow for mis-
	configuration to cause SA looping.		configuration to cause SA looping.
	15. MSDP Connection Establishment		15. MSDP Connection State Machine
	MSDP messages will be encapsulated in a TCP connection. An MSDP peer		MSDP uses TCP as its transport protocol. In a peering relationship,
	listens for new TCP connections on port 639. One side of the MSDP		one MSDP peer listens for new TCP connections on the well-known port
	peering relationship will listen on the well-known port and the other		639. The other side makes an active connect to this port. The peer
	side will do an active connect to the well-known port. The side with		with the higher IP address will listen. This connection establishment
	the higher peer IP address will do the listen. This connection		algorithm avoids call collision. Therefore, there is no need for a
	establishment algorithm avoids call collision. Therefore, there is no		call collision procedure. It should be noted, however, that the
	need for a call collision procedure. It should be noted, however,		disadvantage of this approach is that it may result in longer startup
	that the disadvantage of this approach is that it may result in		times at the passive side.
	longer startup times at the passive end.
	An MSDP peer starts in the INACTIVE state. MSDP peers establish		An MSDP peer starts in the DISABLED state. MSDP peers establish
	peering sessions according to the following state machine:		peering sessions according to the following state machine:
	De-configured or		--------------->+----------+
	disabled		/ | DISABLED |<----------
	+-------------------------------------------+		| ------>+----------+ \
	| |		| / |E1->A1 |
	| |		| | | |
	Enable |		| | V |E7->A7
	+-----|--------->+----------+ Connect Retry Timer |		| | +----------+ E3->A3 +--------+
	| | +->| INACTIVE |----------------+ |		| | | INACTIVE |------->| LISTEN |
	| | | +----------+ | |		| | +----------+ +--------+
	Deconf'ed | | | /|\ /|\ | | Lower Address		| | E2->A2| ^ |E5->A5
	or | | | | | | |		| | | | |
	disabled | | | | | \|/ |		| |E7->A6 V |E6 |
	| | | | | | +-------------+		| \ +------------+ |
	| | | | | +---------------| CONNECTING |		E7->A8 | ------| CONNECTING | |
	| | | | | Timeout or +-------------+		E8->A9 | +------------+ |
	| | | | | Local Address Change |		E9->A10| |E4->A4 |
	\|/ \|/ | | | |		E10->A11| | |
	+----------+ | | | |		E11->A12| V |
	| DISABLED | | | +---------------------+ | TCP Established		\ +-------------+ /
	+----------+ | | | |		--------------| ESTABLISHED |<---------
	/|\ /|\ | | Connection Timeout, | |		+-------------+
	| | | | Local Address change, | |
	| | | | Authorization Failure | |		15.1. Events
	| | | | | |
	| | | | | \|/		E1) Enable MSDP peering with P
	| | | | +-------------+		E2) Own IP address < P's IP address
	| | Local | | | ESTABLISHED |		E3) Own IP address > P's IP address
	| | Address | | Higher Address +-------------+		E4) TCP established (active side)
	| | Change | \|/ /|\ |		E5) TCP established (passive side)
	| | | +--------+ | |		E6) ConnectRetry timer expired
	| | +--| LISTEN |--------------------+ |		E7) Disable MSDP peering with P
	| | +--------+ TCP Accept |		An example of when to do this is when one's own address is
	| | | |		changed)
	| | | |		E8) Hold Timer expired
	| +---------------+ |		E9) Authorization failure
	| De-configured or |		E10) Notification TLV received
	| disabled |		E11) Error detected
	| |
	+------------------------------------------------------+		15.2. Actions
	De-configured or
	disabled		A1) Allocate resources for peering with P
			Compare one's own and peer's IP addresses
			A2) TCP active OPEN
			Set ConnectRetry timer to [ConnectRetry-Period]
			A3) TCP passive OPEN (listen)
			A4) Delete ConnectRetry timer
			Send KeepAlive TLV
			Set KeepAlive timer to [KeepAlive-Period]
			Set Hold Timer to [HoldTime-Period]
			A5) Send KeepAlive TLV
			Set KeepAlive timer to [KeepAlive-Period]
			Set Hold Timer to [HoldTime-Period]
			A6) Abort TCP active OPEN attempt
			Release resources allocated for peering with P
			A7) Abort TCP passive OPEN attempt
			Release resources allocated for peering with P
			In action sets 8)-12), the action "Close peering session" includes
			the following steps:
			Close TCP connection
			Delete KeepAlive timer
			Delete Hold Timer
			Release resources allocated for peering with P
			A8) Send Notification TLV with Error Code "Cease"
			Close peering session
			A9) Send Notification TLV with Error Code "Hold Timer Expired"
			Close peering session
			A10) Notify management system unless this has already been done by
			the security mechanism
			Close peering session
			A11) Notify management system
			If the received Notification TLV's O-bit was cleared, close
			peering session. Otherwise, remain in ESTABLISHED state.
			A12) Send Notification TLV with appropriate Error Code
			Notify management system
			If the sent Notification TLV's O-bit was cleared, close peering
			session. Otherwise, remain in ESTABLISHED state.
			15.3. Peer-specific Events
			The following peer-specific events can occur in the ESTABLISHED
			state, they do not cause a state transition. Appropriate actions are
			listed for each event.
			*) KeepAlive timer expired:
			-> Send KeepAlive TLV
			-> Set KeepAlive timer to [KeepAlive-Period]
			*) KeepAlive TLV received:
			-> Set Hold Timer to [HoldTime-Period]
			*) Source-Active TLV received:
			-> Set Hold Timer to [HoldTime-Period]
			-> Run Peer-RPF Forwarding algorithm (if caching, consider
			SA-Hold-Down Timer and SA-State Timer)
			-> Set KeepAlive timer to [KeepAlive-Period] for those peers the
			Source-Active TLV is forwarded to
			-> Send information to PIM-SM
			-> If caching, store information
			*) Source-Active Request TLV received:
			-> Set Hold Timer to [HoldTime-Period]
			-> If SA-Requests are accepted, send Source-Active Response TLV
			and set KeepAlive timer to [KeepAlive-Period]
			*) Source-Active Response TLV received:
			-> Set Hold Timer to [HoldTime-Period]
			-> If a corresponding SA-Request were previously sent, send
			information to PIM-SM. If not, an error has occured (event 11
			above)
			-> If caching, store information
			15.4. Peer-independent Events
			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
			basis. If the MSDP speaker does not cache SA messages, ignore all
			events and actions pertaining to caching.
			*) SA-Advertisement-Timer expired:
			-> Start periodic transmission of Source-Active TLV(s)
			-> Set KeepAlive timer to [KeepAlive-Period] each time a
			Source-Active TLV is sent
			*) MSDP learns of a new active internal source (e.g. PIM-SM
			register received for a new source):
			-> Send Source-Active TLV
			-> Set KeepAlive timer to [KeepAlive-Period]
			*) Source-Active Request triggered (event not specified here):
			-> Send Source-Active Request TLV
			-> Set KeepAlive timer to [KeepAlive-Period]
			*) SA-State-Timer expired (one timer per cache entry):
			-> Implementation specific, typically mark the cache entry for
			deletion
	16. Packet Formats		16. Packet Formats
	MSDP messages will be encoded in TLV format. If an implementation		MSDP messages will be encoded in TLV format. If an implementation
	receives a TLV that has length that is longer than expected, the TLV		receives a TLV that has length that is longer than expected, the TLV
	SHOULD be accepted. Any additional data SHOULD be ignored.		SHOULD be accepted. Any additional data SHOULD be ignored.
	16.1. MSDP TLV format:		16.1. MSDP TLV format:
	0 1 2 3		0 1 2 3
	skipping to change at page 16, line 29 ¶		skipping to change at page 18, line 8 ¶
	IPv4 Source-Active Response TLV is type 3.		IPv4 Source-Active Response TLV is type 3.
	Length x		Length x
	Is the length of the control information in the message. x is 8		Is the length of the control information in the message. x is 8
	octets (for the first two 32-bit quantities) plus 12 times Entry		octets (for the first two 32-bit quantities) plus 12 times Entry
	Count octets.		Count octets.
	16.2.4. KeepAlive TLV		16.2.4. KeepAlive TLV
	A KeepAlive TLV is sent to an MSDP peer if and only if there were no		A KeepAlive TLV is sent to an MSDP peer if and only if there were no
	MSDP messages sent to the peer after a period of time. This message		MSDP messages sent to the peer within [KeepAlive-Period] seconds.
	is necessary for the active connect side of the MSDP connection. The		This message is necessary to keep the MSDP connection alive.
	passive connect side of the connection knows that the connection will
	be reestablished when a TCP SYN packet is sent from the active
	connect side. However, the active connect side will not know when the
	passive connect side goes down. Therefore, the KeepAlive timeout will
	be used to reset the TCP connection.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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.
	skipping to change at page 26, line 7 ¶		skipping to change at page 28, line 7 ¶
	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 editor 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
	Fenner, Bill Nickless, John Meylor, Liming Wei, Manoj Leelanivas,		Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner,
	Mark Turner, John Zwiebel, Cristina Radulescu-Banu, Brian Edwards and		John Zwiebel, Cristina Radulescu-Banu, Brian Edwards, Selina
	IJsbrand Wijnands provided useful and productive design feedback and		Priestley and IJsbrand Wijnands provided useful and productive design
	comments. In addition to many other contributions, Tom Pusateri		feedback and comments. In addition to many other contributions, Tom
			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.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
End of changes. 16 change blocks.
	83 lines changed or deleted		172 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/