< draft-ietf-msdp-spec-03.txt		draft-ietf-msdp-spec-04.txt >
	Network Working Group Dino Farinacci		Network Working Group Dino Farinacci
	INTERNET DRAFT Procket Networks		INTERNET DRAFT Procket Networks
	Yakov Rekhter		Yakov Rekhter
	David Meyer		David Meyer
	Cisco Systems		Cisco Systems
	Peter Lothberg		Peter Lothberg
	Sprint		Sprint
	Hank Kilmer		Hank Kilmer
	Jeremy Hall		Jeremy Hall
	UUnet		UUnet
	Category Standards Track		Category Standards Track
	January, 2000		February, 2000
	Multicast Source Discovery Protocol (MSDP)		Multicast Source Discovery Protocol (MSDP)
	<draft-ietf-msdp-spec-03.txt>		<draft-ietf-msdp-spec-04.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 8 ¶		skipping to change at page 3, line 8 ¶
	cache Source Active (SA) messages (see below). MSDP is a		cache Source Active (SA) messages (see below). MSDP is a
	periodic protocol.		periodic protocol.
	The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,		The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
	SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined		SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
	in RFC 2119 [RFC2119].		in RFC 2119 [RFC2119].
	5. Overview		5. Overview
	An RP (or other MSDP SA originator) in a PIM-SM [RFC2362] domain will		An RP (or other MSDP SA originator) in a PIM-SM [RFC2362] domain will
	have a MSDP peering relationship with a MSDP peers in another domain.		have a MSDP peering relationship with MSDP peers in another domain.
	The peering relationship will be made up of a TCP connection in which		The peering relationship will be made up of a TCP connection in which
	control information exchanged. Each domain will have one or more		control information is exchanged. Each domain will have one or more
	connections to this virtual topology.		connections to this virtual topology.
	The purpose of this topology is to have domains discover multicast		The purpose of this topology is to have domains discover multicast
	sources from other domains. If the multicast sources are of interest		sources from other domains. If the multicast sources are of interest
	to a domain which has receivers, the normal source-tree building		to a domain which has receivers, the normal source-tree building
	mechanism in PIM-SM will be used to deliver multicast data over an		mechanism in PIM-SM will be used to deliver multicast data over an
	inter-domain distribution tree.		inter-domain distribution tree.
	We envision this virtual topology will essentially be congruent to		We envision this virtual topology will essentially be congruent to
	the existing BGP topology used in the unicast-based Internet today.		the existing BGP topology used in the unicast-based Internet today.
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	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 will not send more than one		Period] MUST be 60 seconds. An RP will 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 important so that new		interval. Originating periodic SA messages is important so that new
	receivers who join after a source has been active can get data		receivers who join after a source has been active can get data
	quickly via the receiver's own RP when it is not caching SA state.		quickly via the receiver's own RP when it is not caching SA state.
			Finally, an originating RP SHOULD trigger the transmission of an 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 starts the SA-Advertisement-Timer when the MSDP process is		An RP starts the SA-Advertisement-Timer when the MSDP process is
	configured. When the timer expires, an RP advertises any candidate		configured. When the timer expires, an RP advertises any candidate
	internal sources to its peers and resets the timer to [SA-		internal sources to its peers and resets the timer to [SA-
	Advertisement-Period] seconds. The timer is deleted when the MSDP		Advertisement-Period] seconds. The timer is deleted when the MSDP
	process is deconfigured. Note that a caching implementation may also		process is deconfigured. Note that a caching implementation may also
	wish to check the SA-Cache on this timer event.		wish to check the SA-Cache on this timer event.
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 41 ¶
	(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 caching MSDP peer. The timer is reset to [SA-State-		received by a caching MSDP peer. The timer is reset to [SA-State-
	Period] if another (S,G)-SA message is received before the (S,G)-SA-		Period] if another (S,G)-SA message is received before the (S,G)-SA-
	State-Timer expires. [SA-State-Period] MUST NOT be less than 90		State-Timer expires. [SA-State-Period] MUST NOT be less than 90
	seconds.		seconds.
	8.4. SA-Hold-Down-Timer		8.4. SA-Hold-Down-Timer
	A caching MSDP peer SHOULD NOT forward an SA message it has received		A caching MSDP peer SHOULD NOT forward an SA message it has received
	in during the previous [SA-Hold-Down-Period] seconds. [SA-Hold-Down-		in during the previous [SA-Hold-Down-Period] seconds. [SA-Hold-Down-
	Period] SHOULD be set to 30 seconds. The timer is set to [SA-Hold-		Period] SHOULD be set to 30 seconds. The per-SA message timer is set
	Down-Period] upon receipt of an (S,G)-SA message, and reset to [SA-		to [SA-Hold-Down-Period] when forwarding an (S,G)-SA message, and a
	Hold-Down-Period] when forwarding an (S,G)-SA message. Finally, the		(S,G)-SA message MUST only forwarded when it's associated timer is
	timer is deleted when the (S,G)-SA cache entry is deleted.		not running. Finally, the timer is deleted when the (S,G)-SA cache
			entry is deleted.
	8.5. KeepAlive Timer		8.5. KeepAlive Timer
	The KeepAlive timer is used by the active connect side of the MSDP		The KeepAlive timer is used by the active connect side of the MSDP
	connection to track the state of the passive-connect side of the		connection to track the state of the passive-connect side of the
	connection. In particular, the KeepAlive timer is be used to reset		connection. In particular, the KeepAlive timer is used to reset the
	the TCP connection when the passive-connect side of the connection		TCP connection when the passive-connect side of the connection goes
	goes down. The KeepAlive timer is set to [KeepAlive-Period] when		down. The KeepAlive timer is set to [KeepAlive-Period] when passive-
	passive-connect peer comes up. [KeepAlive-Period] SHOULD NOT be less		connect peer comes up. [KeepAlive-Period] SHOULD NOT be less that 75
	that 75 seconds. The timer is reset to [KeepAlive-Period] upon		seconds. The timer is reset to [KeepAlive-Period] upon receipt of
	receipt of data from peer, and deleted when the timer expires or the		data from peer, and deleted when the timer expires or the passive-
	passive-connect peer closes the connection.		connect peer closes the connection.
	8.6. ConnectRetry Timer		8.6. 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 peer's active
	connect attempt fails. When the timer expires, the peer retries the		connect attempt fails. When the timer expires, the peer retries the
	connection and the timer is is reset to [ConnectRetry-Period]. It is		connection and the timer is reset to [ConnectRetry-Period]. It is
	deleted deleted if either the connection transitions into ESTABLISHED		deleted if either the connection transitions into ESTABLISHED state
	state or the peer is deconfigured.		or the peer is deconfigured.
	8.7. Peer Hold Timer		8.7. Peer Hold Timer
	If a system does not receive successive KeepAlive messages (or any SA		If a system does not receive successive KeepAlive messages (or any SA
	message) within the period specified by the Hold Timer, then a		message) within the period specified by the Hold Timer, then a
	Notification message with Hold Timer Expired Error Code MUST be sent		Notification message with Hold Timer Expired Error Code MUST be sent
	and the MSDP MUST be connection closed. [Hold-Time-Period] MUST be at		and the MSDP connection MUST be closed. [Hold-Time-Period] MUST be at
	least three seconds. A suggested value for [Hold-Time-Period] is 90		least three seconds. A suggested value for [Hold-Time-Period] is 90
	seconds.		seconds.
	The Hold Timer is initialized to [Hold-Time-Period] when the peer's		The Hold Timer is initialized to [Hold-Time-Period] when the peer's
	transport connection is established, and is reset to [Hold-Time-		transport connection is established, and is reset to [Hold-Time-
	Period] when either a KeepAlive or any SA message is received.		Period] when either a KeepAlive or any SA message is received.
	9. Intermediate MSDP Peers		9. Intermediate MSDP Peers
	Intermediate RPs do not originate periodic SA messages on behalf of		Intermediate RPs do not originate periodic SA messages on behalf of
	skipping to change at page 7, line 42 ¶		skipping to change at page 8, line 14 ¶
	12. Encapsulated Data Packets		12. Encapsulated Data Packets
	For bursty sources, the RP may encapsulate multicast data from the		For bursty sources, the RP may encapsulate multicast data from the
	source. An interested RP may decapsulate the packet, which SHOULD be		source. An interested RP may decapsulate the packet, which SHOULD be
	forwarded as if a PIM register encapsulated packet was received. That		forwarded as if a PIM register encapsulated packet was received. That
	is, if packets are already arriving over the interface toward the		is, if packets are already arriving over the interface toward the
	source, then the packet is dropped. Otherwise, if the outgoing		source, then the packet is dropped. Otherwise, if the outgoing
	interface list is non-null, the packet is forwarded appropriately.		interface list is non-null, the packet is forwarded appropriately.
	Note that when doing data encapsulation, an implementation MUST bound		Note that when doing data encapsulation, an implementation MUST bound
	the time during which the source which are encapsulated.		the time during which packets are encapsulated.
	This allows for small bursts to be received before the multicast tree		This allows for small bursts to be received before the multicast tree
	is built back toward the source's domain. For example, an		is built back toward the source's domain. For example, an
	implementation SHOULD encapsulate at least the first packet to		implementation SHOULD encapsulate at least the first packet to
	provide service to bursty sources.		provide service to bursty sources.
	13. Other Scenarios		13. Other Scenarios
	MSDP is not limited to deployment across different routing domains.		MSDP is not limited to deployment across different routing domains.
	It can be used within a routing domain when it is desired to deploy		It can be used within a routing domain when it is desired to deploy
	multiple RPs for different group ranges. As long as all RPs have a		multiple RPs for the same group ranges. As long as all RPs have a
	interconnected MSDP topology, each can learn about active sources as		interconnected MSDP topology, each can learn about active sources as
	well as RPs in other domains.		well as RPs in other domains.
	14. MSDP Peer-RPF Forwarding		14. MSDP Peer-RPF Forwarding
	The MSDP Peer-RPF Forwarding rules are used for forwarding SA		The MSDP Peer-RPF Forwarding rules are used for forwarding SA
	messages throughout an MSDP enabled internet. Unlike the RPF check		messages throughout an MSDP enabled internet. Unlike the RPF check
	used when forwarding data packets, the Peer-RPF check is against the		used when forwarding data packets, the Peer-RPF check is against the
	RP address carried in the SA message.		RP address carried in the SA message.
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 20 ¶
	(vi). The internal MBGP advertiser of the router towards R is		(vi). The internal MBGP advertiser of the router towards R is
	the RPF neighbor if we have an MSDP peering with it.		the RPF neighbor if we have an MSDP peering with it.
	(v). If none of the above match, and we have an MSDP		(v). If none of the above match, and we have an MSDP
	default-peer configured, the MSDP default-peer is		default-peer configured, the MSDP default-peer is
	the RPF neighbor.		the RPF neighbor.
	14.2. MSDP default-peer semantics		14.2. MSDP default-peer semantics
	A MSDP default-peer is much like a default route. It is intended to		An MSDP default-peer is much like a default route. It is intended to
	be used in those cases where a stub network isn't running BGP or		be used in those cases where a stub network isn't running BGP or
	MBGP. An MSDP peer configured with a default-peer accepts all SA		MBGP. An MSDP peer configured with a default-peer accepts all SA
	messages from the default-peer. Note that a router running BGP or		messages from the default-peer. Note that a router running BGP or
	MBGP SHOULD NOT allow configuration of default peers, since this		MBGP SHOULD NOT allow configuration of default peers, since this
	allows the possibility for SA looping to occur.		allows the possibility for SA looping or black-holes to occur.
	15. MSDP Connection Establishment		15. MSDP Connection Establishment
	MSDP messages will be encapsulated in a TCP connection. An MSDP peer		MSDP messages will be encapsulated in a TCP connection. An MSDP peer
	listens for new TCP connections on port 639. One side of the MSDP		listens for new TCP connections on port 639. One side of the MSDP
	peering relationship will listen on the well-known port and the other		peering relationship will listen on the well-known port and the other
	side will do an active connect on the well-known port. The side with		side will do an active connect on the well-known port. The side with
	the higher peer IP address will do the listen. This connection		the higher peer IP address will do the listen. This connection
	establishment algorithm avoids call collision. Therefore, there is no		establishment algorithm avoids call collision. Therefore, there is no
	need for a call collision procedure. It should be noted, however,		need for a call collision procedure. It should be noted, however,
	skipping to change at page 11, line 23 ¶		skipping to change at page 11, line 23 ¶
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Value .... |		| Type | Length | Value .... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type (8 bits)		Type (8 bits)
	Describes the format of the Value field.		Describes the format of the Value field.
	Length (16 bits)		Length (16 bits)
	Length of Type, Length, and Value fields in octets. The		Length of Type, Length, and Value fields in octets. The
	minimum length required is 4 octets. The total length		minimum length required is 4 octets.
	of the TLV should be a multiple of 2 octets.
	Value (variable length)		Value (variable length)
	Format is based on the Type value. See below. The length of		Format is based on the Type value. See below. The length of
	the value field is Length field minus 3. All reserved fields		the value field is Length field minus 3. All reserved fields
	in the Value field MUST be transmitted as zeros and ignored on		in the Value field MUST be transmitted as zeros and ignored on
	receipt.		receipt.
	16.2. Defined TLVs		16.2. Defined TLVs
	The following TLV Types are defined:		The following TLV Types are defined:
	skipping to change at page 20, line 23 ¶		skipping to change at page 20, line 23 ¶
	| 5 | x + 5 |O| 3 |		| 5 | x + 5 |O| 3 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 7 | SA Message ....		| 7 | SA Message ....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length x		Length x
	x is the length of the SA message (which contained data which		x is the length of the SA message (which contained data which
	was encapsulated in some unknown way) that is with contained in the		was encapsulated in some unknown way) that is with contained in the
	data field of the Notification message.		data field of the Notification message.
	17.3.8. Adminstrative Scope Boundary Violated		17.3.8. Administrative Scope Boundary Violated
	This notification is used when an SA message is received for a group		This notification is used when an SA message is received for a group
	G from a peer which is across an administrative scope boundary for G.		G from a peer which is across an administrative scope boundary for G.
	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 | 16 |O| 3 |		| 5 | 16 |O| 3 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 8 | Reserved |		| 8 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 21, line 33 ¶		skipping to change at page 21, line 33 ¶
	17.7. Cease		17.7. Cease
	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 TCPC encapsulation of SA data.		This section describes UDP, GRE, and TCP encapsulation of SA data.
	Encapsulation type is a configuration option.		Encapsulation type is a 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 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 |
	skipping to change at page 25, line 8 ¶		skipping to change at page 25, line 8 ¶
	David Meyer		David Meyer
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA, 95134		San Jose, CA, 95134
	Email: dmm@cisco.com		Email: dmm@cisco.com
	22. REFERENCES		22. REFERENCES
	[GRE] Farinacci, D., et al., "Generic Routing Encapsulation		[GRE] Farinacci, D., et al., "Generic Routing Encapsulation
	(GRE)", draft-meyer-gre-update-02.txt, January,		(GRE)", draft-meyer-gre-update-03.txt, January,
	2000. Work in Progress.		2000. Work in Progress.
	[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.
End of changes. 18 change blocks.
	28 lines changed or deleted		32 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/