< draft-ietf-msdp-spec-01.txt		draft-ietf-msdp-spec-02.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
	December, 1999		January, 2000
	Multicast Source Discovery Protocol (MSDP)		Multicast Source Discovery Protocol (MSDP)
	<draft-ietf-msdp-spec-01.txt>		<draft-ietf-msdp-spec-02.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 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	2. Abstract		2. Abstract
	The Multicast Source Discovery Protocol, MSDP, describes a mechanism		The Multicast Source Discovery Protocol, MSDP, describes a mechanism
	to connect multiple PIM-SM domains together. Each PIM-SM domain uses		to connect multiple PIM-SM domains together. Each PIM-SM domain uses
	it's own independent RP(s) and does not have to depend on RPs in		its own independent RP(s) and does not have to depend on RPs in other
	other domains.		domains.
	3. Copyright Notice		3. Copyright Notice
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Copyright (C) The Internet Society (20000). All Rights Reserved.
	4. Introduction		4. Introduction
	The Multicast Source Discovery Protocol, MSDP, describes a mechanism		The Multicast Source Discovery Protocol, MSDP, describes a mechanism
	to connect multiple PIM-SM domains together. Each PIM-SM domain uses		to connect multiple PIM-SM domains together. Each PIM-SM domain uses
	its own independent RP(s) and does not have to depend on RPs in other		its own independent RP(s) and does not have to depend on RPs in other
	domains. Advantages of this approach include:		domains. Advantages of this approach include:
	o No Third-party resource dependencies on RP		o No Third-party resource dependencies on RP
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	o Source address of the data source.		o Source address of the data source.
	o Group address the data source sends to.		o Group address the data source sends to.
	o IP address of the RP.		o IP address of the RP.
	Each MSDP peer receives and forwards the message away from the RP		Each MSDP peer receives and forwards the message away from the RP
	address in a "peer-RPF flooding" fashion. The notion of peer-RPF		address in a "peer-RPF flooding" fashion. The notion of peer-RPF
	flooding is with respect to forwarding SA messages. The 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 10 below for the details of peer-RPF fowarding.		peer". See section 10 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 it's MSDP peers.		message to all its MSDP peers.
	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. In this case, an		the AS_PATH, the peer is using you as the NEXT_HOP. This is known in
	implementation SHOULD forward an SA message (which was originated		other circles as Split-Horizon with Poison Reverse. An implementation
	from the RP address covered by that route) to the peer. This is		SHOULD NOT forward SA messages (which were originated from the RP
	known in other circles as Split-Horizon with Poison Reverse.		address covered by a route) to peers which have not Poison Reversed
			that route.
	When an MSDP peer which is also an RP for its own domain receives an		When an MSDP peer which is also an RP for its own domain receives a
	SA message, it determines if it has any group members interested in		new SA message, it determines if it has any group members interested
	the group which the SA message describes. That is, the RP checks for		in the group which the SA message describes. That is, the RP checks
	a (*,G) entry with a non-empty outgoing interface list; this implies		for a (*,G) entry with a non-empty outgoing interface list; this
	that the domain is interested in the group. In this case, the RP		implies that the domain is interested in the group. In this case, the
	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 (See
	[RFC2362] Section 3.2.2). This sets up a branch of the source-tree to		[RFC2362] Section 3.2.2). This sets up a branch of the source-tree to
	this domain. Subsequent data packets arrive at the RP which are		this domain. Subsequent data packets arrive at the RP which are
	forwarded down the shared-tree inside the domain. If leaf routers		forwarded down the shared-tree inside the domain. If leaf routers
	choose to join the source-tree they have the option to do so		choose to join the source-tree they have the option to do so
	according to existing PIM-SM conventions. Finally, if an RP in a		according to existing PIM-SM conventions. Finally, if an RP in a
	domain receives a PIM Join message for a new group G, and it is		domain receives a PIM Join message for a new group G, and it is
	caching SAs, then the RP should trigger a (S,G) join event for each		caching SAs, then the RP should trigger a (S,G) join event for each
	SA for that group in its cache.		SA for that group in its cache.
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 40 ¶
	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. The advantage
	of caching is that newly formed MSDP peers can get MSDP (S,G) state		of caching is that newly formed MSDP peers can get MSDP (S,G) state
	sooner and therefore reduce join latency for new joiners. In		sooner and therefore reduce join latency for new joiners. In
	addition, caching greatly aids in diagnosis and debugging of various		addition, caching greatly aids in diagnosis and debugging of various
	problems.		problems.
	7.1. Timers		7.1. Timers
	The main timers for MSDP are: SA Advertisement period, SA Hold-down		The main timers for MSDP are: SA-Advertisement-Timer, SA-Hold-Down-
	period, the SA Cache timeout period, KeepAlive, HoldTimer, and		Timer, SA Cache entry timers, and KeepAlive timer.
	ConnectRetry. Each is described below.
	7.1.1. SA Advertisement Period		7.1.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. The SA Advertisement Period MUST be		is data being sent by the source. There is one SA-Advertisement-Timer
	60 seconds. An RP will not send more than one SA message for a given		covering the sources that an RP may advertise. [SA-Advertisement-
	(S,G) within an SA Advertisement period. Originating periodic SA		Timer] MUST be 60 seconds. An RP will not send more than one SA
	messages is important so that new receivers who join after a source		message for a given (S,G) within an SA Advertisement interval.
	has been active can get data quickly via the receiver's own RP when		Originating periodic SA messages is important so that new receivers
	it is not caching SA state. Finally, if an RP in a domain receives a		who join after a source has been active can get data quickly via the
	PIM Join message for a new group G, and it is caching SAs, then the		receiver's own RP when it is not caching SA state.
	RP should trigger a (S,G) join for each SA for that group in its
	cache.
	7.1.2. SA Hold-down Period		7.1.1.1. SA-Advertisement-Timer Processing
			When an RP is processing a PIM register message, it encapsulates the
			data (if any) in an SA message and sends the SA message it to each of
			its peers. The RP starts the SA Advertisement-Timer for the (S,G) at
			this time. When the timer expires, and there is (S,G) state for a
			source within the RP's domain, an (S,G)-SA message is sent to each
			peer and the timer is reset to [SA-Advertisement-Timer] seconds. If
			no (S,G) state exists, the timer is deleted.
			The following table summarizes (S,G)-SA-Advertisement-Timer
			processing:
			Set to | When | Applies to
			[SA-Advertisement-Timer] | created off Register packet | (S,G)
			Reset to | When | Applies to
			[SA-Advertisement-Timer] | Timer expires and (S,G) | (S,G)
			| state exists and was |
			| created by a register |
			Deleted | When | Applies to
			[SA-Advertisement-Timer] | Timer expires and (S,G) | (S,G)
			| state has expired |
			Note that a caching implementation may also wish to check the SA-
			Cache on this timer event.
			7.1.2. SA Cache Timeout (SA-State-Timer)
			Each entry in an SA Cache has an associated SA-State-Timer. A
			(S,G)-SA-State-Timer is is started when an (S,G)-SA message is
			initially received by a caching MSDP speaker. The timer is reset to
			[SA-State-Timer] if another (S,G)-SA message is received before the
			(S,G)-SA-State-Timer expires. [SA-State-Timer] MUST NOT be less than
			90 seconds. The following table summarizes SA-State-Timer
			processing:
			Set to | When | Applies to
			[SA-State-Timer] | creating (S,G)-SA cache | (S,G)-SA Cache Entry
			| entry (on receipt of a |
			| (S,G)-SA message) |
			Reset to | When | Applies to
			[SA-State-Timer] | On receipt of (S,G)-SA | (S,G)-SA Cache Entry
			| message |
			Deleted | When | Applies to
			(S,G) SA Cache | Timer expires | (S,G)-SA Cache Entry
			entry | |
			7.1.3. SA-Hold-Down-Timer
	A caching MSDP speaker SHOULD NOT forward an SA message it has		A caching MSDP speaker SHOULD NOT forward an SA message it has
	received in the last SA-Hold-down period. The SA-Hold-down period		received in the last SA-Hold-Down interval. [SA-Hold-Down-Timer]
	SHOULD be set to 30 seconds.		SHOULD be set to 30 seconds. The following table summarizes SA-Hold-
			Down-Timer processing:
	7.1.3. SA Cache Timeout		Set to | When | Applies to
			[SA-Hold-Down-Timer] | Upon receipt of | (S,G)-SA Cache Entry
			| (S,G)-SA message |
	A caching MSDP speaker times out it's SA cache at SA-State-Timer.		Reset to | When | Applies to
	The SA-State-Timer MUST NOT be less than 90 seconds.		[SA-Hold-Down-Timer] | When forwarding (S,G)-SA | (S,G)-SA Cache Entry
			| message |
	7.1.4. KeepAlive, HoldTimer, and ConnectRetry		Deleted | When | Applies to
			(S,G)-SA-Hold-Down-Timer] | (S,G)-SA entry is | (S,G)-SA Cache Entry
			deleted
	The KeepAlive, HoldTimer, and ConnectRetry timers are defined in RFC		7.1.4. KeepAlive Timer
	1771 [RFC1771].
			Set to | When | Applies to
			[KeepAliver-Timer] | passive-connect peer comes | each peer
			| up |
			Reset to | When | Applies to
			[KeepAliver-Timer] | Receipt of data from peer | each peer
			Deleted | When | Applies to
			KeepAliver-Timer | Timer expires | each peer
			| or passive-connect peer |
			| closes connection |
	7.2. Intermediate MSDP Speakers		7.2. Intermediate MSDP Speakers
	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 its own sources.
	7.3. SA Filtering and Policy		7.3. 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, hoever, 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
	Internet (i.e., SA filtering by transit domains can cause black		Internet (i.e., SA filtering by transit domains can cause undesired
	holes). In general, policy should be expressed using MBGP [RFC2283].		lack of connectivity). In general, policy should be expressed using
	This will cause MSDP messages will flow in the desired direction and		MBGP [RFC2283]. This will cause MSDP messages will flow in the
	peer-RPF fail otherwise. An exception occurs at an administrative		desired direction and peer-RPF fail otherwise. An exception occurs at
	scope [RFC2365] boundary. In particular, a SA message for a (S,G)		an administrative scope [RFC2365] boundary. In particular, a SA
	MUST NOT be sent to peers which are on the other side of an		message for a (S,G) MUST NOT be sent to peers which are on the other
	administrative scope boundary for G.		side of an administrative scope boundary for G.
	7.4. SA Requests		7.4. SA Requests
	If an MSDP peer decides to cache SA state, it may accept SA-Requests		If an MSDP peer decides to cache SA state, it MAY accept SA-Requests
	from other MSDP peers. When an MSDP peer receives an SA-Request for a		from other MSDP peers. When an MSDP peer receives an SA-Request for a
	group range, it will respond to the peer with a set of SA entries, in		group range, it will respond to the peer with a set of SA entries, in
	an SA-Response message, for all active sources sending to the group		an SA-Response message, for all active sources sending to the group
	range requested in the SA-Request message. The peer that sends the		range requested in the SA-Request message. The peer that sends the
	request will not flood the responding SA-Response message to other		request will not flood the responding SA-Response message to other
	peers.		peers. See section 12 for discussion of error handling relating to SA
			requests and responses.
	If an implementation receives an SA-Request message and is not
	caching SA messages, it sends a notification with Error code 7
	subcode 1, as defined in section 12.2.7.
	8. Encapsulated Data Packets		8. 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 number of packets from the source which are encapsulated.		the time during which the source which 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.
	Finally, if an implementation supports an encapsulation of SA data
	other than default TCP encapsulation, then it MUST support GRE
	encapsulation. In addition, an implementation MUST learn about not
	TCP encapsulations via capability advertisement (see section 11.2.5).
	9. Other Scenarios		9. 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 different 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. Another example is the Anycast RP		well as RPs in other domains. Another example is the Anycast RP
	mechanism [ANYCASTRP].		mechanism [ANYCASTRP].
	10. MSDP Peer-RPF Forwarding		10. 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.
	10.1. Peer-RPF Forwarding Rules		10.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. The RPF neighbor is chosen using the first		neighbor for originator R, and discarded otherwise.
	of the following rules that matches:
			The RPF neighbor is chosen using the first of the following rules
			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 an MSDP peering with a neighbor 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 exeternal MBGP peering with that neighbor,		route), but no external MBGP peerings with them,
	pick a neighbor via a deterministic rule if you have have		pick one via a deterministic rule.
	several, and that 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.
	Once an RPF neighbor is chosen (as defined above), an SA message is
	accepted if it was received from the RPF neighbor, and discarded
	otherwise.
	10.2. MSDP default-peer semantics		10.2. MSDP default-peer semantics
	A MSDP default-peer is much like a default route. It is intended to		A 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. A MSDP speaker configured with a default-peer accepts all SA		MBGP. A MSDP speaker 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 to occur.
	11. MSDP Connection Establishment		11. MSDP Connection Establishment
	MSDP speakers establish peering sessions according to the following		MSDP messages will be encapsulated in a TCP connection using well-
	state machine:		known port 639. One side of the MSDP 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 the higher peer IP address will
			do the listen. This connection establishment algorithm avoids call
			collision. Therefore, there is no need for a call collision
			procedure. It should be noted, however, that the disadvantage of this
			approach is that it may result in longer startup times at the passive
			end.
			An MSDP speaker starts in the INACTIVE state. MSDP speakers establish
			peering sessions according to the following state machine:
	De-configured or		De-configured or
	disabled		disabled
	+-------------------------------------------+		+-------------------------------------------+
	| |		| |
			| |
			Enable |
	+-----|--------->+----------+ |		+-----|--------->+----------+ |
	| | +->| INACTIVE |----------------+ |		| | +->| INACTIVE |----------------+ |
	| | | +----------+ | |		| | | +----------+ | |
	Deconf'ed | | | /|\ /|\ | Timer + Higher Address		Deconf'ed | | | /|\ /|\ | Higher Address
	or | | | | | | |		or | | | | | | |
	disabled | | | | | \|/ |		disabled | | | | | \|/ |
	| | | | | | +-------------+		| | | | | | +-------------+
	| | | | | +---------------| CONNECTING |		| | | | | +---------------| CONNECTING |
	| | | | | Timeout or +-------------+		| | | | | Timeout or +-------------+
	| | | | | Router ID Change |		| | | | | Local Address Change |
	\|/ \|/ | | | |		\|/ \|/ | | | |
	+----------+ | | | |		+----------+ | | | |
	| DISABLED | | | +---------------------+ | TCP Established		| DISABLED | | | +---------------------+ | TCP Established
	+----------+ | | | |		+----------+ | | | |
	/|\ /|\ | | Connection Timeout or | |		/|\ /|\ | | Connection Timeout, | |
	| | | | Router ID change or | |		| | | | Local Address change, | |
	| | | | Authorization Failure | |		| | | | Authorization Failure | |
	| | | | | |		| | | | | |
	| | | | | \|/		| | | | | \|/
	| | | | +-------------+		| | | | +-------------+
	| | Router ID | | Timer + | ESTABLISHED |		| | Local | | | ESTABLISHED |
	| | Change | | Low Address +-------------+		| | Address | | Lower Address +-------------+
	| | | \|/ /|\ |		| | Change | \|/ /|\ |
	| | | +--------+ | |		| | | +--------+ | |
	| | +--| LISTEN |--------------------+ |		| | +--| LISTEN |--------------------+ |
	| | +--------+ TCP Accept |		| | +--------+ TCP Accept |
	| | | |		| | | |
	| | | |		| | | |
	| +---------------+ |		| +---------------+ |
	| De-configured or |		| De-configured or |
	| disabled |		| disabled |
	| |		| |
	+------------------------------------------------------+		+------------------------------------------------------+
	De-configured or		De-configured or
	disabled		disabled
	12. Packet Formats		12. Packet Formats
	MSDP messages will be encapsulated in a TCP connection using well-		MSDP messages will be encoded in TLV format. If an implementation
	known port 639. One side of the MSDP peering relationship will listen		receives a TLV that has length that is longer than expected, the TLV
	on the well-known port and the other side will do an active connect		SHOULD be accepted. Any additional data SHOULD be ignored.
	on the well-known port. The side with the higher peer IP address will
	do the listen. This connection establishment algorithm avoids call
	collision. Therefore, there is no need for a call collision
	procedure. It should be noted, however, that the disadvantage of this
	approach is that it may result in longer startup times at the passive
	end.
	Finally, if an implementation receives a TLV that has length that is
	longer than expected, the TLV SHOULD be accepted. Any additional data
	SHOULD be ignored.
	12.1. MSDP messages will be encoded in TLV format:		12.1. MSDP TLV format:
	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 3 octets.		minimum length required is 3 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.		the value field is Length field minus 3.
	12.2. The following TLV Types are defined:		12.2. Defined TLVs
			The following TLV Types are defined:
	Code Type		Code Type
	===========================================================		===========================================================
	1 IPv4 Source-Active		1 IPv4 Source-Active
	2 IPv4 Source-Active Request		2 IPv4 Source-Active Request
	3 IPv4 Source-Active Response		3 IPv4 Source-Active Response
	4 KeepAlive		4 KeepAlive
	5 Encapsulation Capability Advertisement		5 Notification
	6 Encapsulation Capability Request
	7 Notification
	8 GRE Encapsulation
	Each TLV is described below.		Each TLV is described below.
	12.2.1. IPv4 Source-Active TLV		12.2.1. IPv4 Source-Active TLV
	The maximum size SA message that can be sent is 1400 bytes. 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 bytes, it sends successive 1400-byte messages. The 1400 byte		1400 octets, it sends successive 1400-octet messages. The 1400 octet
	size does not include the TCP, IP, layer-2 headers.		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 | Gprefix Len | Sprefix Len | \		| Reserved | Sprefix Len | \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
	| Group Address Prefix | ) z		| Group Address | ) z
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
	| Source Address Prefix | /		| Source Address | /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	IPv4 Source-Active TLV is type 1.		IPv4 Source-Active TLV is type 1.
	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.
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 48 ¶
	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
	active in.		active in.
	Reserved		Reserved
	The Reserved field MUST be transmitted as zeros and ignored		The Reserved field MUST be transmitted as zeros and ignored
	by a receiver.		by a receiver.
	Gprefix Len and Sprefix Len		Sprefix Len
	The route prefix length associated with the group address		The route prefix length associated with source address.
	prefix and source address prefix, respectively.
	Group Address Prefix		Group Address
	The group address the active source has sent data to.		The group address the active source has sent data to.
	Source Address Prefix		Source Address
	The route prefix associated with the active source.		The IP address of the active source.
	Multiple SA TLVs MAY appear in the same message and can be batched		Multiple SA TLVs MAY appear in the same message and can be batched
	for efficiency at the expense of data latency. This would typically		for efficiency at the expense of data latency. This would typically
	occur on intermediate forwarding of SA messages.		occur on intermediate forwarding of SA messages.
	12.2.2. IPv4 Source-Active Request TLV		12.2.2. IPv4 Source-Active Request TLV
	The Source-Active Request is used to request SA-state from a caching		The Source-Active Request is used to request SA-state from a caching
	MSDP peer. If an RP in a domain receives a PIM Join message for a		MSDP peer. If an RP in a domain receives a PIM Join message for a
	group, creates (*,G) state and wants to know all active sources for		group, creates (*,G) state and wants to know all active sources for
	group G, and it has been configured to peer with an SA-state caching		group G, and it has been configured to peer with an SA-state caching
	peer, it may send an SA-Request message for the group.		peer, it may send an SA-Request message for the group.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2 | 8 | Gprefix Len |		| 2 | 8 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address Prefix |		| Group Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	IPv4 Source-Active Request TLV is type 2.		IPv4 Source-Active Request TLV is type 2.
	Gprefix Len		Reserved
	The route prefix length associated with the group address prefix.		The Reserved field MUST be transmitted as zeros and ignored
			by a receiver.
	Group Address Prefix		Group Address
	The group address prefix the MSDP peer is requesting.		The group address the MSDP peer is requesting.
	12.2.3. IPv4 Source-Active Response TLV		12.2.3. IPv4 Source-Active Response TLV
	The Source-Active Response is sent in response to a Source-Active		The Source-Active Response is sent in response to a Source-Active
	Request message. The Source-Active Response message has the same		Request message. The Source-Active Response message has the same
	format as a Source-Active message but does not allow encapsulation of		format as a Source-Active message but does not allow encapsulation of
	multicast data.		multicast data.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 13, line 38 ¶		skipping to change at page 14, line 23 ¶
	MSDP messages sent to the peer after a period of time. This message		MSDP messages sent to the peer after a period of time. This message
	is necessary for the active connect side of the MSDP connection. The		is necessary for the active connect side of the MSDP connection. The
	passive connect side of the connection knows that the connection will		passive connect side of the connection knows that the connection will
	be reestablished when a TCP SYN packet is sent from the active		be reestablished when a TCP SYN packet is sent from the active
	connect side. However, the active connect side will not know when the		connect side. However, the active connect side will not know when the
	passive connect side goes down. Therefore, the KeepAlive timeout will		passive connect side goes down. Therefore, the KeepAlive timeout will
	be used to reset the TCP connection.		be used to reset the TCP connection.
	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 | 4 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The length of the message is 3 bytes which encompasses the 1-byte		The length of the message is 4 octets which encompasses the 1-octet
	Type field and the 2-byte Length field.		Type field and the 2-octet Length field, plus the Reserved field. The
			Reserved field MUST be transmitted as zeros and ignored by a
	12.2.5. Encapsulation Capability Advertisement TLV		receiver.
	This TLV is sent by an MSDP speaker to advertise its ability to		12.2.5. Notification TLV
	receive data packets encapsulated as described by the TLV (in
	addition to the default TCP encapsulation).
	A MSDP speaker receiving this TLV can choose to either default TCP		A Notification message is sent when an error condition is detected,
	encapsulation, or may send a IPv4 Encapsulation Request to change to		and has the following form:
	the advertised encapsulation type.
	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 | 8 | ENCAP_TYPE |		| 5 | x + 5 |O| Error Code |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Port | Reserved |		| Error subcode | ... |
			+-+-+-+-+-+-+-+-+ |
			| Data |
			| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	IPv4 Encapsulation Advertisement TLV is type 5.		The Notification TLV is type 7.
	Length		Length
	Length is a two byte field with value 8.		Length is a two octet field with value x + 5, where x is
			the length of the notification data field.
	ENCAP_TYPE		O-bit
	The following data encapsulation types are defined for MSDP:		Open-bit. If reset, the connection will be closed [MASC].
	Value Meaning		Error code
	---------------------------------------		This 7-bit unsigned integer indicates the type of Notification.
	0 TCP Encapsulation		The following Error Codes have been defined:
	1 UDP Encapsulation [RFC768]
	2 GRE Encapsulation [GRE]
	Source Port		Error Code Symbolic Name Reference
	Port for use by the requester.
	Reserved		1 Message Header Error Section 12.3
	The Reserved field MUST be transmitted as zeros and ignored
	by a receiver.
	Note that since the TLV does not carry endpoint addresses for the GRE		2 Finite State Machine Error Section 12.4
	or UDP tunnels, an implementation using these encapsulations MUST use
	the endpoints that are used for the MSDP peering.
	12.2.6. Encapsulation Capability Request TLV		3 Notification Message Error Section 12.5
	The Encapsulation Capability Request is sent to notify a peer that		4 SA-Request Error Section 12.6
	has advertised an encapsulation capability that it will encapsulate
	SA data according to the advertised ENCAP_TYPE.		5 SA-Response Error Section 12.7
			6 SA-Message Error Section 12.8
			Error subcode:
			This one-octet unsigned integer provides more specific information
			about the reported error. Each Error Code may have one or more Error
			Subcodes associated with it. If no appropriate Error Subcode is
			defined, then a zero (Unspecific) value is used for the Error Subcode
			field, and the O-bit must be reset (i.e. the connection will be
			closed). The used notation in the error description below is: MC =
			Must Close connection = O-bit reset; CC = Can Close connection =
			O-bit might be reset [MASC].
			Message Header Error subcodes:
			0 - Unspecific (MC)
			1 - Bad Message Length (MC)
			2 - Bad Message Type (MC)
			Finite State Machine Error subcodes:
			0 - Unspecific (MC)
			1 - Unexpected Message Type FSM Error (MC)
			Notification subcodes (the O-bit is always reset):
			0 - Unspecific (CC)
			SA-Request Error subcodes:
			0 - Not caching (MC)
			0 - Invalid Group Address prefix (CC)
			SA-Reponse Error subcodes:
			0 - Didn't send Request (MC)
			SA-Message Error subcodes
			0 - Invalid Entry Count (CC)
			1 - Invalid RP Address (CC)
			2 - Invalid Group Address (CC)
			3 - Invalid Source Address (CC)
			4 - Invalid Sprefix Length (CC)
			5 - Looping SA (Self is RP) (CC)
			6 - Unknown Encapsulation (MC)
			12.3. Message Header Error Handling
			All errors detected while processing the Message Header are indicated
			by sending the Notification message with Error Code Message Header
			Error. The Error Subcode describes the specific nature of the error.
			The Data field contains the erroneous Message (including the message
			header).
			If the Length field of the message header is less than 4 or greater
			than 1400, or the length of a Keepalive message is not equal to 4,
			then the Error Subcode is set to Bad Message Length.
			If the Type field of the message header is not recognized, then the
			Error Subcode is set to Bad Message Type.
			12.4. Finite State Machine Error Handling
			Any error detected by the MSDP Finite State Machine (e.g., receipt of
			an unexpected event) is indicated by sending the Notification message
			with Error Code Finite State Machine Error.
			12.5. Notification Message Error Handling
			If a node sends a Notification message, and there is an error in that
			message, and the O-bit of that message is not reset, a Notification
			with O-bit reset, Error Code of Notification Error, and subcode
			Unspecific must be sent. In addition, the Data field must include
			the Notification message that triggered the error. However, if the
			erroneous Notification message had the O-bit reset, then any error,
			such as an unrecognized Error Code or Error Subcode, should be
			noticed, logged locally, and brought to the attention of the
			administrator of the remote node.
			12.6. SA-Request Error Handling
			The SA-Request Error code is used to signal the receipt of a SA
			request at a non-caching MSDP speaker, or at a caching MSDP speaker
			when an invalid group address requested.
			When a non-caching MSDP speaker receives an SA-Request, it returns
			the following notification and closes the connection:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 6 | 4 | ENCAP_TYPE |		| 7 | 16 |O| 4 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 0x0 | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Group Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type
	IPv4 Encapsulation Request TLV is type 6.
	Length		If a caching MSDP speaker receives a request for an invalid group, it
	Length is a two byte field with value 4.		returns the following notification and closes the connection:
	ENCAP_TYPE		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
	ENCAP_TYPE is described above.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 7 | 12 |O| 4 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 0x1 | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Invalid Group Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A requester MAY also provide a source port, in which case		12.7. SA-Response Error Handling
	the TLV has the following form:
			The SA-Response Error code is used to signal the receipt of a SA
			Response at MSDP speaker which did not issue a SA-Request to the
			peer. It 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 6 | 8 | ENCAP_TYPE |		| 7 | 8 |O| 5 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Port | Reserved |		| 0x0 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	12.2.7. NOTIFICATION TLV		12.8. SA-Message Error Handling
			The SA-Message Error code is used to signal the receipt of an SA
			message that contains invalid data.
			12.8.1. Invalid Entry Count
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 7 | x + 5 | Error Code |		| 7 | 12 |O| 6 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Error subcode | ... |		| 0x0 | Reserved |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data |		| Invalid Entry Count |
	| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		12.8.2. Invalid RP Address
	The Notification TLV is type 7.
	Length		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
	Length is a two byte field with value x + 5, where x is		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	the length of the notification data field.		| 7 | 12 |O| 6 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 0x1 | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Invalid RP Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Error code		12.8.3. Invalid Group Address
	See [RFC1771]. In addition, Error code 7 indicates an
	an SA-Request Error.
	Error subcode		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
	See [RFC1771]. In addition, Error code 7 subcode 1 indicates		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	the receipt of an SA-Request message by a non-caching		| 7 | 12 |O| 6 |
	MSDP speaker.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 0x2 | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Invalid Group Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Data		12.8.4. Invalid Source Address
	See [RFC1771]. In addition, for Error code 7 subcode 1 (receipt
	of an SA-Request message by a non-caching MSDP speaker), the
	TLV 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 7 | 20 | 7 |		| 7 | 12 |O| 6 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | Reserved | Gprefix Len | Sprefix Len |		| 0x3 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Advertising RP Address |		| Invalid Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Address Prefix |
			12.9. Invalid Sprefix Length
			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 Address Prefix |		| 7 | 12 |O| 6 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 0x4 | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Invalid Sprefix Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [RFC1771] for NOTIFICATION error handling.		12.10. Looping SAs (Self is RP in received SA)
	12.2.8. Encapsulation Capability State Machine		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 7 | 8 |O| 6 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 0x5 | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The active connect side of an MSDP peering SHALL begin in ADVERTISING		12.11. Unknown Encapsulation
	state, and the passive side of the TCP connection begins in DEFAULT
	state. This will cause the state machine to behave deterministically.
	+-------+		This notification is sent on receipt of SA data that is encapsulated
	| | Receive TLV which isn't		in an unknown encapsulation type. See section 12.12 for known
	| | understood or		encapsulations.
	| | Receive Request (TLV 6) or
	| | Receive Advertisement (TLV 5)
	\|/ | that isn't understood
	+---------+----+
	| DEFAULT |----------------+
	+---------+ |
	|
	+-------------+ |
	| ADVERTISING | |
	+-------------+ |
	| |
	Timeout +--------+ | |
	+-------->| FAILED | | Send Advertisement | Receive Advertisement
	| +--------+ | (TLV 5) | (TLV 5)
	| | |
	| | |
	| | |
	| | |
	| Receive non-matching | |
	| Request (TLV 6) | |
	| +----+ | |
	| | | | |
	| | | | |
	| | \|/ | \|/
	| | +------+ | +----------+
	| +-| SENT |<-------------+ | RECEIVED |
	+---+------+ +----------+
	| \|/
	| |
	| Receive matching | Send matching
	| Request (TLV 6) | Request (TLV 6)
	| +--------+ |
	+------------>| AGREED |<------------------+
	+--------+
	Note that if an advertiser transitions into the FAILED state, it		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
	SHOULD assume that it has an old-style peer which can only support		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TCP encapsulation. If an implementation wishes to be backwardly		| 7 | 8 |O| 6 |
	compatible, it SHOULD support TCP encapsulation. In addition, a		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	requester in any state other than AGREED MUST only encapsulate data		| 0x6 | Reserved |
	in the TCP stream.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	12.2.9. UDP Data Encapsulation		12.12. SA Data Encapsulation
	When using UDP encapsulation, the UDP psuedo-header has the following		This section describes UDP and GRE encapsulation of SA data.
	form:		Encapsulation type is a configuration option.
			12.12.1. UDP Data Encapsulation
			MSDP SA-data MAY be encapsulated in UDP. In this case, the UDP
			psuedo-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 | Dest Port |		| Source Port | Destination Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Checksum |		| Length | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Origin RP Address |		| Origin RP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Source Port		Source Port
	When using UDP encapsulation, a capability requester		Port to be used by the remote end, and is known via
	uses the advertiser's Source Port as its destination		configuration.
	port. The advertiser MUST provide a Source Port.
	Destination Port		Destination Port
	When using UDP encapsulation, a capability advertiser		The Destination Port is set to the remote endpoint's Source port,
	uses the well known port 639 as the destination port.		and is known via configuration.
	A capability requester MUST listen on this well-known
	port. The requester MAY provide a Source Port in it's
	reply to the advertiser.
	Length		Length
	Length is the length in octets of this user datagram		Length is the length in octets of this user datagram
	including this header and the data. The minimum value		including this header and the data. The minimum value
	of the length is twelve.		of the length is twelve.
	Checksum		Checksum
	The checksum is computed according to RFC 768 [RFC768].		The checksum is computed according to RFC 768 [RFC768].
	Originating RP Address		Originating RP Address
	The Originating RP Address is the address of the RP sending		The Originating RP Address is the address of the RP sending
	the encapsulated data.		the encapsulated data.
	12.2.10. GRE Encapsulation TLV		12.12.2. GRE Encapsulation
	A TLV is defined to describe GRE encapsulated data packets. The TLV
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 8 | 8 + x | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originating RP IPv4 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| (S,G) Data Packet ....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type
	GRE encapsulated data packet TLV is type 8.
	Length
	Length is a two byte field with value 8 + x, where
	x is the length of the (S,G) Data packet.
	Reserved
	The Reserved field MUST be transmitted as zeros and ignored
	by a receiver.
	The entire GRE header, then, will have the following form:		MSDP SA-data MAY be encapsulated in GRE using protocol type [MSDP-
			GRE-ProtocolType].
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Delivery Headers ..... |		| Delivery Headers ..... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|C| Reserved0 | Ver | Protocol Type |\		|C| Reserved0 | Ver | [MSDP-GRE-ProtocolType] |\
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header
	| Checksum (optional) | Reserved1 |/		| Checksum (optional) | Reserved1 |/
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 8 | 8 + x | Reserved | \		| Originating RP IPv4 Address |\
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
	| Originating RP IPv4 Address | /		| (S,G) Data Packet .... /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
	| (S,G) Data Packet .... .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	12.2.10.1. Problems with MTU Exceeded by Encapsulation		12.12.2.1. GRE Encapsulation and PMTU Discovery [RFC1191]
	Black holes can arise when PMTU [RFC1191] is used and the tunnel		Existing implementations of GRE, when using IPv4 as the Delivery
	entry point does not relay MTU exceeded errors back to the originator		Header, do not implement Path MTU discovery and do not set the Don't
	of the packet. A black hole can be realized by the following		Fragment bit in the Delivery Header. This can cause large packets to
	behavior: the originator sets the Don't Fragment bit in the Delivery		become fragmented within the tunnel and reassembled at the tunnel
	Header, the packet gets dropped within the tunnel (MTU is exceeded),		exit (independent of whether the payload packet is using PMTU). If a
	but since the originator doesn't receive feedback, it retransmits		tunnel entry point were to use Path MTU discovery, however, that
	with the same PMTU, causing subsequently transmitted packets to be		tunnel entry point would also need to relay ICMP unreachable error
	dropped. While GRE [GRE] does not require that such errors be relayed		messages (in particular the "fragmentation needed and DF set" code)
	back to the originator, known implementations of GRE do not set the		back to the originator of the packet, which is not required by the
	Don't Fragment bit in the Delivery Header.		GRE specification [GRE]. Failure to properly relay Path MTU
			information to an originator can result in the following behavior:
			the originator sets the don't fragment bit, the packet gets dropped
			within the tunnel, but since the originator doesn't receive proper
			feedback, it retransmits with the same PMTU, causing subsequently
			transmitted packets to be dropped.
	13. Security Considerations		13. Security Considerations
	An MSDP implementation MAY use IPsec [RFC1825] or keyed MD5 [RFC1828]		An MSDP implementation MAY use IPsec [RFC1825] or keyed MD5 [RFC1828]
	to secure control messages. When encapsulating SA data in GRE,		to secure control messages. When encapsulating SA data in GRE,
	security should be relatively similar to security in a normal IPv4		security should be relatively similar to security in a normal IPv4
	network, as routing using GRE follows the same routing that IPv4 uses		network, as routing using GRE follows the same routing that IPv4 uses
	natively. Route filtering will remain unchanged. However packet		natively. Route filtering will remain unchanged. However packet
	filtering at a firewall requires either that a firewall look inside		filtering at a firewall requires either that a firewall look inside
	the GRE packet or that the filtering is done on the GRE tunnel		the GRE packet or that the filtering is done on the GRE tunnel
	endpoints. In those environments in which this is considered to be a		endpoints. In those environments in which this is considered to be a
	security issue it may be desirable to terminate the tunnel at the		security issue it may be desirable to terminate the tunnel at the
	firewall.		firewall.
	14. Acknowledgments		14. Acknowledgments
	The authors would like to thank Dave Thaler, Bill Nickless, John		The authors would like to thank Dave Thaler, Bill Nickless, John
	Meylor, Liming Wei, Manoj Leelanivas, Mark Turner, and John Zwiebel		Meylor, Liming Wei, Manoj Leelanivas, Mark Turner, John Zwiebel, and
	for their design feedback and comments. Bill Fenner also made many		Cristina Radulescu-Banu for their design feedback and comments. Bill
	contributions, including clarification of the Peer-RPF rules.		Fenner also made many contributions, including clarification of the
			Peer-RPF rules.
	15. Author's Address:		15. Author's Address:
	Dino Farinacci		Dino Farinacci
	Procket Networks		Procket Networks
	3850 No. First St., Ste. C		3850 No. First St., Ste. C
	San Jose, CA 95134		San Jose, CA 95134
	Email: dino@procket.com		Email: dino@procket.com
	Yakov Rehkter		Yakov Rehkter
	skipping to change at page 22, line 11 ¶		skipping to change at page 25, line 11 ¶
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA, 95134		San Jose, CA, 95134
	Email: dmm@cisco.com		Email: dmm@cisco.com
	16. REFERENCES		16. REFERENCES
	[ANYCASTRP] Meyer, et. al, "Anycast RP mechanism using PIM and		[ANYCASTRP] Meyer, et. al, "Anycast RP mechanism using PIM and
	MSDP", draft-ietf-mboned-anycast-rp-04.txt, November,		MSDP", draft-ietf-mboned-anycast-rp-04.txt, November,
	1999. Work in Progress.		1999. Work in Progress.
	[GRE] Farinacci, D., at el., "Generic Routing Encapsulation		[GRE] Farinacci, D., et al., "Generic Routing Encapsulation
	(GRE)", draft-meyer-gre-update-01.txt, December,		(GRE)", draft-meyer-gre-update-02.txt, January,
	1999. Work in Progress.		2000. Work in Progress.
			[MASC] Estrin, D., et al., "The Multicast Address-Set Claim
			(MASC) Protocol", draft-ietf-malloc-masc-04.txt,
			October, 1999. 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
	(BGP-4)", RFC 1771, March 1995.
	[RFC1825] Atkinson, R., "Security Architecture for the Internet		[RFC1825] Atkinson, R., "Security Architecture for the Internet
	Protocol", RFC 1825, August, 1995.		Protocol", RFC 1825, August, 1995.
	[RFC1828] P. Metzger and W. Simpson, "IP Authentication using		[RFC1828] P. Metzger and W. Simpson, "IP Authentication using
	Keyed MD5", RFC 1828, August, 1995.		Keyed MD5", RFC 1828, August, 1995.
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March, 1997.		Requirement Levels", RFC 2119, March, 1997.
	[RFC2283] Bates, T., Chandra, R., Katz, D., and Y. Rekhter.,		[RFC2283] Bates, T., Chandra, R., Katz, D., and Y. Rekhter.,
End of changes. 106 change blocks.
	298 lines changed or deleted		417 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/