< draft-ietf-msdp-spec-04.txt		draft-ietf-msdp-spec-05.txt >
	skipping to change at page 1, line 17 ¶		skipping to change at page 1, line 17 ¶
	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
	February, 2000		February, 2000
	Multicast Source Discovery Protocol (MSDP)		Multicast Source Discovery Protocol (MSDP)
	<draft-ietf-msdp-spec-04.txt>		<draft-ietf-msdp-spec-05.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 7 ¶		skipping to change at page 3, line 7 ¶
	Global source state is not required, since a router need not		Global source state is not required, since a router need not
	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		MSDP-speaking routers in a PIM-SM [RFC2362] domain will have a MSDP
	have a MSDP peering relationship with MSDP peers in another domain.		peering relationship with MSDP peers in another domain. The peering
	The peering relationship will be made up of a TCP connection in which		relationship will be made up of a TCP connection in which control
	control information is exchanged. Each domain will have one or more		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 allow 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.
	That is, the TCP connections between MSDP peers can be realized by		That is, the TCP connections between MSDP peers are likely to be
	the underlying BGP routing system.		congruent to the connections in the BGP routing system.
	6. Procedure		6. Procedure
	A source in a PIM-SM domain originates traffic to a multicast group.		A source in a PIM-SM domain originates traffic to a multicast group.
	The PIM DR which is directly connected to the source sends the data		The PIM DR which is directly connected to the source sends the data
	encapsulated in a PIM Register message to the RP in the domain.		encapsulated in a PIM Register message to the RP in the domain.
	The RP will construct a "Source-Active" (SA) message and send it to		The RP will construct a "Source-Active" (SA) message and send it to
	its MSDP peers. The SA message contains the following fields:		its MSDP peers. The SA message contains the following fields:
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	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 BGP routing		flooding is with respect to forwarding SA messages. The BGP routing
	table is examined to determine which peer is the NEXT_HOP towards the		table is examined to determine which peer is the NEXT_HOP towards the
	originating RP of the SA message. Such a peer is called an "RPF		originating RP of the SA message. Such a peer is called an "RPF
	peer". See section 14 below for the details of peer-RPF forwarding.		peer". See section 14 below for the details of peer-RPF 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.		message to all its MSDP peers (except the one from which it received
			the SA message).
	The flooding can be further constrained to children of the peer by		The flooding can be further constrained to children of the peer by
	interrogating BGP reachability information. That is, if a BGP peer		interrogating BGP reachability information. That is, if a BGP peer
	advertises a route (back to you) and you are the next to last AS in		advertises a route (back to you) and you are the next to last AS in
	the AS_PATH, the peer is using you as the NEXT_HOP. This is known in		the AS_PATH, the peer is using you as the NEXT_HOP. This is known in
	other circles as Split-Horizon with Poison Reverse. An implementation		other circles as Split-Horizon with Poison Reverse. An implementation
	SHOULD NOT forward SA messages (which were originated from the RP		SHOULD NOT forward SA messages (which were originated from the RP
	address covered by a route) to peers which have not Poison Reversed		address covered by a route) to peers which have not Poison Reversed
	that route.		that route.
	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
	implies that the domain is interested in the group. In this case, the		implies that the domain is interested in the group. In this case, the
	RP triggers a (S,G) join event towards the data source as if a		RP triggers a (S,G) join event towards the data source as if a
	Join/Prune message was received addressed to the RP itself (See		Join/Prune message was received addressed to the RP itself. This sets
	[RFC2362] Section 3.2.2). This sets up a branch of the source-tree to		up a branch of the source-tree to this domain. Subsequent data
	this domain. Subsequent data packets arrive at the RP which are		packets arrive at the RP which are forwarded down the shared-tree
	forwarded down the shared-tree inside the domain. If leaf routers		inside the domain. If leaf routers choose to join the source-tree
	choose to join the source-tree they have the option to do so		they have the option to do so according to existing PIM-SM
	according to existing PIM-SM conventions. Finally, if an RP in a		conventions. Finally, if an RP in a domain receives a PIM Join
	domain receives a PIM Join message for a new group G, and it is		message for a new group G, and it is caching SAs, then the RP should
	caching SAs, then the RP should trigger a (S,G) join event for each		trigger a (S,G) join event for each SA for that group in its cache.
	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. Controlling State		7. Controlling State
	While RPs which receive SA messages are not required to keep MSDP		While RPs which receive SA messages are not required to keep MSDP
	(S,G) state, an RP SHOULD cache SA messages by default. The advantage		(S,G) state, an RP SHOULD cache SA messages by default. One of the
	of caching is that newly formed MSDP peers can get MSDP (S,G) state		main advantages of caching is that since the RP has MSDP (S,G) state,
	sooner and therefore reduce join latency for new joiners. In		join latency is greatly reduced for new receivers of G. In addition,
	addition, caching greatly aids in diagnosis and debugging of various		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, and ConnectRetry and		Timer, SA Cache Entry timer, KeepAlive timer, and ConnectRetry and
	Peer Hold Timer. Each is considered below.		Peer 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 will 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 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		Finally, an originating RP SHOULD trigger the transmission of an SA
	message as soon as it receives data from an internal source for the		message as soon as it receives data from an internal source for the
	first time.		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 MUST spread the generation of periodic SA messages over its
	configured. When the timer expires, an RP advertises any candidate		reporting interval (i.e. SA-Advertisement-Period). An RP starts the
	internal sources to its peers and resets the timer to [SA-		SA-Advertisement-Timer when the MSDP process is configured. When the
	Advertisement-Period] seconds. The timer is deleted when the MSDP		timer expires, an RP resets the timer to [SA-Advertisement-Period]
	process is deconfigured. Note that a caching implementation may also		seconds, and begins the advertisement of its active sources. Active
	wish to check the SA-Cache on this timer event.		sources are advertised in the following manner: An RP packs its
			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
			message. This process is repeated periodically within the SA-
			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
			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
			deleted when the MSDP process is deconfigured. Note that a caching
			implementation may also wish to check the SA-Cache on this timer
			event.
	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 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 per-SA message timer is set		Period] SHOULD be set to 30 seconds. The per-SA message timer is set
	to [SA-Hold-Down-Period] when forwarding an (S,G)-SA message, and a		to [SA-Hold-Down-Period] when forwarding an (S,G)-SA message, and a
	(S,G)-SA message MUST only forwarded when it's associated timer is		(S,G)-SA message MUST only be forwarded when it's associated timer is
	not running. Finally, the timer is deleted when the (S,G)-SA cache		not running. Finally, the timer is deleted when the (S,G)-SA cache
	entry is deleted.		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 used to reset the		connection. In particular, the KeepAlive timer is used to reset the
	TCP connection when the passive-connect side of the connection goes		TCP connection when the passive-connect side of the connection goes
	down. The KeepAlive timer is set to [KeepAlive-Period] when passive-		down. The KeepAlive timer is set to [KeepAlive-Period] when the
	connect peer comes up. [KeepAlive-Period] SHOULD NOT be less that 75		passive-connect peer comes up. [KeepAlive-Period] SHOULD NOT be less
	seconds. The timer is reset to [KeepAlive-Period] upon receipt of		that 75 seconds. The timer is reset to [KeepAlive-Period] upon
	data from peer, and deleted when the timer expires or the passive-		receipt of an MSDP message from peer, and deleted when the timer
	connect peer closes the connection.		expires or the passive-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 reset to [ConnectRetry-Period]. It is		connection and the timer is reset to [ConnectRetry-Period]. It is
	deleted if either the connection transitions into ESTABLISHED state		deleted if either the connection transitions into ESTABLISHED state
	skipping to change at page 6, line 39 ¶		skipping to change at page 7, line 4 ¶
	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 connection MUST be 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 any MSDP 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
	sources in other domains. In general, an RP MUST only originate an SA		sources in other domains. In general, an RP MUST only originate an SA
	for its own sources.		for a source which would register to it.
	10. SA Filtering and Policy		10. SA Filtering and Policy
	As the number of (S,G) pairs increases in the Internet, an RP may		As the number of (S,G) pairs increases in the Internet, an RP may
	want to filter which sources it describes in SA messages. Also,		want to filter which sources it describes in SA messages. Also,
	filtering may be used as a matter of policy which at the same time		filtering may be used as a matter of policy which at the same time
	can reduce state. Only the RP co-located in the same domain as the		can reduce state. Only the RP co-located in the same domain as the
	source can restrict SA messages. Note, however, that MSDP peers in		source can restrict SA messages. Note, however, that MSDP peers in
	transit domains should not filter SA messages or the flood-and-join		transit domains should not filter SA messages or the flood-and-join
	model can not guarantee that sources will be known throughout the		model can not guarantee that sources will be known throughout the
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	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.
	14.1. Peer-RPF Forwarding Rules		14.1. Peer-RPF Forwarding Rules
	An SA message originated by an MSDP originator R and received by a		An SA message originated by an MSDP originator R and received by a
	MSDP router from MSDP peer N is accepted if N is the appropriate RPF		MSDP router from MSDP peer N is accepted if N is the appropriate RPF
	neighbor for originator R, and discarded otherwise.		neighbor for originator R (the RP in the SA message), and discarded
			otherwise.
	The RPF neighbor is chosen using the first of the following rules		The RPF neighbor is chosen using the first of the following rules
	that matches:		that matches:
	(i). R is the RPF neighbor if we have an MSDP peering with R.		(i). R is the RPF neighbor if we have an MSDP peering with R.
	(ii). The external MBGP neighbor towards which we are		(ii). The external MBGP neighbor towards which we are
	poison-reversing the MBGP route towards R is the RPF neighbor		poison-reversing the MBGP route towards R is the RPF neighbor
	if we have an MSDP peering with it.		if we have an MSDP peering with it.
	(iii). If we have any MSDP peerings with neighbors in the first		(iii). If we have any MSDP peerings with neighbors in the first
	AS along the AS_PATH (the AS from which we learned this		AS along the AS_PATH (the AS from which we learned this
	route), but no external MBGP peerings with them,		route), but no external MBGP peerings with them,
	pick one via a deterministic rule.		the neighbor with the highest IP address is the RPF neighbor.
	(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
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 33 ¶
	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 or black-holes 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 to 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,
	that the disadvantage of this approach is that it may result in		that the disadvantage of this approach is that it may result in
	longer startup times at the passive end.		longer startup times at the passive end.
	An MSDP peer starts in the INACTIVE state. MSDP peers establish		An MSDP peer starts in the INACTIVE state. MSDP peers establish
	peering sessions according to the following state machine:		peering sessions according to the following state machine:
	De-configured or		De-configured or
	disabled		disabled
	+-------------------------------------------+		+-------------------------------------------+
	| |		| |
	| |		| |
	Enable |		Enable |
	+-----|--------->+----------+ |		+-----|--------->+----------+ Connect Retry Timer |
	| | +->| INACTIVE |----------------+ |		| | +->| INACTIVE |----------------+ |
	| | | +----------+ | |		| | | +----------+ | |
	Deconf'ed | | | /|\ /|\ | | Lower Address		Deconf'ed | | | /|\ /|\ | | Lower Address
	or | | | | | | |		or | | | | | | |
	disabled | | | | | \|/ |		disabled | | | | | \|/ |
	| | | | | | +-------------+		| | | | | | +-------------+
	| | | | | +---------------| CONNECTING |		| | | | | +---------------| CONNECTING |
	| | | | | Timeout or +-------------+		| | | | | Timeout or +-------------+
	| | | | | Local Address Change |		| | | | | Local Address Change |
	\|/ \|/ | | | |		\|/ \|/ | | | |
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 22 ¶
	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.
	minimum length required is 4 octets.		minimum length required is 4 octets, except for
			Keepalive messages.
	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 12, line 9 ¶		skipping to change at page 12, line 9 ¶
	3 IPv4 Source-Active Response		3 IPv4 Source-Active Response
	4 KeepAlive		4 KeepAlive
	5 Notification		5 Notification
	Each TLV is described below.		Each TLV is described below.
	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 1400 octets. If an
	MSDP peer needs to originate a message with information greater than		MSDP peer needs to originate a message with information greater than
	1400 octets, it sends successive 1400-octet messages. The 1400 octet		1400 octets, it sends successive 1400 octet or smaller messages. The
	size does not include the TCP, IP, layer-2 headers.		1400 octet size does not include the TCP, IP, layer-2 headers.
	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 | \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
	| Group Address | ) z		| Group Address | ) z
	skipping to change at page 12, line 38 ¶		skipping to change at page 12, line 38 ¶
	Length x		Length x
	Is the length of the control information in the message. x is		Is the length of the control information in the message. x is
	8 octets (for the first two 32-bit quantities) plus 12 times		8 octets (for the first two 32-bit quantities) plus 12 times
	Entry Count octets.		Entry Count octets.
	Length y		Length y
	If 0, then there is no data encapsulated. Otherwise an IPv4		If 0, then there is no data encapsulated. Otherwise an IPv4
	packet follows and y is the length of the total length field		packet follows and y is the length of the total length field
	of the IPv4 header encapsulated. If there are multiple SA TLVs		of the IPv4 header encapsulated. If there are multiple SA TLVs
	in a message, and data is also included, y must be 0 in all SA		in a message, and data is also included, y must be 0 in all SA
	TLVs except the last one. And the last SA TLV must reflect the		TLVs except the last one and the last SA TLV must reflect the
	source and destination addresses in the IP header of the		source and destination addresses in the IP header of the
	encapsulated data.		encapsulated data.
	Entry Count		Entry Count
	Is the count of z entries (note above) which follow the RP		Is the count of z entries (note above) which follow the RP
	address field. This is so multiple (S,G)s from the same domain		address field. This is so multiple (S,G)s from the same domain
	can be encoded efficiently for the same RP address.		can be encoded efficiently for the same RP address.
	RP Address		RP Address
	The address of the RP in the domain the source has become		The address of the RP in the domain the source has become
	skipping to change at page 16, line 26 ¶		skipping to change at page 16, line 26 ¶
	2 - Invalid RP Address (MC)		2 - Invalid RP Address (MC)
	3 - Invalid Group Address (MC)		3 - Invalid Group Address (MC)
	4 - Invalid Source Address (MC)		4 - Invalid Source Address (MC)
	5 - Invalid Sprefix Length (MC)		5 - Invalid Sprefix Length (MC)
	6 - Looping SA (Self is RP) (MC)		6 - Looping SA (Self is RP) (MC)
	7 - Unknown Encapsulation (MC)		7 - Unknown Encapsulation (MC)
	8 - Administrative Scope Boundary Violated (MC)		8 - Administrative Scope Boundary Violated (MC)
	Hold Timer Expired subcodes (the O-bit is always clear):		Hold Timer Expired subcodes (the O-bit is always clear):
	0 - Unspecific (MC)		0 - Unspecific (MC)
	Finite State Machine Error subcodes:		Finite State Machine Error subcodes:
	0 - Unspecific (MC)		0 - Unspecific (MC)
	1 - Unexpected Message Type FSM Error (MC)		1 - Unexpected Message Type FSM Error (MC)
	Notification subcodes (the O-bit is always clear):		Notification subcodes (the O-bit is always clear):
	0 - Unspecific (MC)		0 - Unspecific (MC)
	skipping to change at page 17, line 47 ¶		skipping to change at page 17, line 47 ¶
	The SA-Request Error code is used to signal the receipt of a SA		The SA-Request Error code is used to signal the receipt of a SA
	request at a non-caching MSDP peer, or at a caching MSDP peer when an		request at a non-caching MSDP peer, or at a caching MSDP peer when an
	invalid group address requested.		invalid group address requested.
	When a non-caching MSDP peer receives an SA-Request, it returns the		When a non-caching MSDP peer receives an SA-Request, it returns the
	following notification:		following notification:
	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 | 16 |O| 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | Reserved |		| 1 | Reserved | Gprefix Len |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Gprefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address |		| Group Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			y.fi
	If a caching MSDP peer receives a request for an invalid group, it		If a caching MSDP peer receives a request for an invalid
	returns the following notification:		group, it returns the following notification:
	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 | 16 |O| 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2 | Reserved |		| 2 | Reserved | Gprefix Len |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Gprefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Invalid Group Address |		| Invalid 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:
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 22 ¶
	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| 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 contained in the
	data field of the Notification message.		data field of the Notification message.
	17.3.8. Administrative 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 | Gprefix Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP Address |		| Gprefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address |		| Group Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	17.4. Hold Time Expired		17.4. Hold Time Expired
	If a system does not receive successive KEEPALIVE or any SA Message		If a system does not receive successive KeepAlive or any SA Message
	and/or Notification messages within the period specified in the Hold		and/or Notification messages within the period specified in the Hold
	Timer, then the notification message with Hold Timer Expired Error		Timer, the notification message with Hold Timer Expired Error Code
	Code must be sent and the MSDP connection closed.		and no additional data MUST be sent and the MSDP connection closed.
	17.5. Finite State Machine Error Handling		17.5. Finite State Machine Error Handling
	Any error detected by the MSDP Finite State Machine (e.g., receipt of		Any error detected by the MSDP Finite State Machine (e.g., receipt of
	an unexpected event) is indicated by sending the Notification message		an unexpected event) is indicated by sending the Notification message
	with Error Code Finite State Machine Error.		with Error Code Finite State Machine Error.
	17.6. Notification Message Error Handling		17.6. Notification Message Error Handling
	If a node sends a Notification message, and there is an error in that		If a node sends a Notification message, and there is an error in that
	skipping to change at page 22, line 42 ¶		skipping to change at page 22, line 42 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|C| Reserved0 | Ver | [MSDP-GRE-ProtocolType] |\		|C| Reserved0 | Ver | [MSDP-GRE-ProtocolType] |\
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header
	| Checksum (optional) | Reserved1 |/		| Checksum (optional) | Reserved1 |/
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originating RP IPv4 Address |\		| Originating RP IPv4 Address |\
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
	| (S,G) Data Packet .... /		| (S,G) Data Packet .... /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	18.2.1. GRE Encapsulation and Path MTU Discovery [RFC1191]		18.2.1. Encapsulation and Path MTU Discovery [RFC1191]
	Existing implementations of GRE, when using IPv4 as the Delivery		Existing implementations of GRE, when using IPv4 as the Delivery
	Header, do not implement Path MTU discovery and do not set the Don't		Header, do not implement Path MTU discovery and do not set the Don't
	Fragment bit in the Delivery Header. This can cause large packets to		Fragment bit in the Delivery Header. This can cause large packets to
	become fragmented within the tunnel and reassembled at the tunnel		become fragmented within the tunnel and reassembled at the tunnel
	exit (independent of whether the payload packet is using PMTU). If a		exit (independent of whether the payload packet is using PMTU). If a
	tunnel entry point were to use Path MTU discovery, however, that		tunnel entry point were to use Path MTU discovery, however, that
	tunnel entry point would also need to relay ICMP unreachable error		tunnel entry point would also need to relay ICMP unreachable error
	messages (in particular the "fragmentation needed and DF set" code)		messages (in particular the "fragmentation needed and DF set" code)
	back to the originator of the packet, which is not required by the		back to the originator of the packet, which is not required by the
End of changes. 33 change blocks.
	61 lines changed or deleted		77 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/