< draft-liu-pim-single-stream-multicast-frr-00.txt		draft-liu-pim-single-stream-multicast-frr-01.txt >
	Network working group H. Liu		Network working group H. Liu
	Internet Draft L. Zheng		Internet Draft L. Zheng
	Category: Standard Track Y. Yu		Category: Standard Track T. Bai
	Created: July 6, 2010 Huawei Technologies.		Created: October 18, 2010 Y. Yu
	Expires: January 2011		Expires: April 2011 Huawei Technologies.
	Single Stream Multicast Fast Reroute (SMFR) Method		Single Stream Multicast Fast ReRoute (SMFRR) Method
	draft-liu-pim-single-stream-multicast-frr-00		draft-liu-pim-single-stream-multicast-frr-01
	Abstract		Abstract
	This document proposes an IP multicast fast convergence method based		This document proposes an IP multicast fast reroute method based on
	on differentiating primary and backup PIM join. The multicast		differentiating primary and backup PIM join. The multicast stream
	stream is only sent along one of the multicast primary and backup		is only sent along one of the multicast primary and backup path,
	path, which enables the efficient multicast delivery under both		which enables the efficient multicast delivery under both normal and
	normal and abnormal conditions.		abnormal conditions.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [RFC2119].		document are to be interpreted as described in RFC-2119 [RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document.		respect to this document.
	Table of Contents		Table of Contents
	1. Introduction.................................................3		1. Introduction.................................................3
	2. Principle of Single Stream Solution..........................3		2. Principle of Single Stream Solution..........................3
	2.1. Primary and Backup Path Setup...........................3		2.1. Primary and Backup Path Setup...........................3
	2.2. Fault Processing........................................4		2.2. Fault Processing........................................4
			2.3. Fault Recovery..........................................4
	3. The Definition of packet format..............................5		3. The Definition of packet format..............................5
	3.1. Multicast FRR join Attribute............................5		3.1. Multicast FRR join Attribute............................5
	3.2. PIM multicast FRR Hello Options.........................6		3.2. PIM multicast FRR Hello Options.........................5
	4. Scenario Analysis for Single Stream Forwarding...............6		4. Single Stream Implementation Options.........................6
	4.1. Disabling all nodes on backup path......................6		4.1. Disabling all nodes on backup path......................6
	4.2. Disabling only root node on backup path.................7		4.2. Disabling only root node on backup path.................8
	5. Security Considerations......................................8		5. Security Considerations......................................8
	6. Acknowledgement..............................................8		6. References...................................................8
	7. References...................................................8		6.1. Normative References....................................8
	7.1. Normative References....................................8
	7.2. Informative References..................................8
	Authors' Addresses..............................................9		Authors' Addresses..............................................9
	1. Introduction		1. Introduction
	This document proposes an IP multicast fast convergence method based		This document proposes an IP multicast fast reroute method based on
	on differentiating primary and backup PIM join, which is called		differentiating primary and backup PIM join, which is called Single
	Single Stream multicast FRR. In this method, two multicast		Stream multicast FRR. In this method, two multicast forwarding
	forwarding paths are established respectively by PIM primary join		paths are established respectively by PIM primary join and backup
	and backup join. Under normal conditions, only primary path is used		join. Under normal conditions, only primary path is used to make
	to make the multicast data delivery. If the node or link on the		the multicast data delivery. If the node or link on the primary
	primary path fails, the multicast data forwarding is switched to the		path fails, the multicast data forwarding is switched to the backup
	backup path.		path.
	Because either primary or backup nodes forward multicast data		Because either primary or backup nodes forward multicast data
	packets, they should be able to identify on which path they are		packets, they should be able to identify on which path they are
	located and to take appropriate forwarding action according to this		located to make appropriate forwarding decision. One feasible
	information. One feasible solution is to include a new join		solution is to include a new join attribute in a PIM backup join
	attribute in a PIM backup join message. During the transmission of		message to set up backup multicast path whose entries are disabled
	the joins hop-by-hop on the backup path, the node(s) of backup path		by default. If a failure is detected on the primary path, the
	are disabled for data forwarding when creating the multicast		backup nodes are notified and the entries which were previously
	forwarding entries. If the failure is detected on the primary path,		disabled are enabled for multicast data forwarding.
	the backup path is notified and the forwarding entry on backup path
	node which was previously disabled is enabled for data forwarding.
	The Single stream FRR solution has the advantages of implementing		The Single stream FRR solution has the advantages of implementing
	fast multicast protection and of avoiding double multicast bandwidth		fast multicast protection and of avoiding double multicast bandwidth
	occupation in both normal and abnormal situations.		occupation in both normal and abnormal situations.
	2. Principle of Single Stream Solution		2. Principle of Single Stream Solution
	2.1. Primary and Backup Path Setup		2.1. Primary and Backup Path Setup
	The backup multicast path is set up using backup PIM join. The join		The backup multicast path is set up using backup PIM join. The join
	is sent by the initiating node of the backup path from the backup IP		is sent by the initiating node (i.e. the downstream converge point
	FRR upstream interface or from a statically configured backup		of primary and backup paths) from a backup IP FRR upstream interface
	interface towards the multicast source. The join is transmitted		or from a statically configured backup interface towards the
	hop-by-hop upwards and is terminated when reaching the root of the		multicast source. The join is transmitted hop-by-hop upwards and is
	multicast tree (i.e. Source DR or RP), or when merging with primary		terminated when reaching the root of the multicast tree (i.e. Source
	forwarding states created by primary join. On the merging point,		DR or RP), or when merging with primary forwarding states created by
	only the primary states are maintained.		primary join. On the merging point, only the primary states are
			maintained.
	The forwarding state(s) on backup path are disabled by default for		The forwarding state(s) on backup path are disabled by default for
	data forwarding when being created by the backup joins, which		data forwarding when being created by the backup joins, which
	requires the backup join to be flagged to be differentiated from the		requires the backup join to be flagged to be differentiated from the
	primary ones. A new join attribute [RFC5384] (referred to as e.g.		primary ones. A new join attribute [RFC5384] (referred to as e.g.
	Multicast FRR join Attribute, or MFA), is suggested to be introduced		Multicast FRR join Attribute, or MFA), is suggested to be introduced
	to serve this purpose and a new hello option for this attribute		to serve this purpose and a new hello option for this attribute
	should be defined to negotiate this capability. The format of the		should be defined to negotiate this capability. The format of the
	attribute and its hello option are respectively defined in section		attribute and its hello option are respectively defined in section
	3.1 and 3.2		3.1 and 3.2
	To make precise switching from a primary path to a backup path for
	multiple load-balancing primary paths, an additional identification
	for the primary path should be included in the MFA attribute of a
	backup join. The primary path ID could be the interface ID of a
	router ID, or a logic number configured for the primary path. In
	some cases multiple primary path IDs have to be included in the
	backup join and they have to be merged when backup join has to be
	sent upwards. PIM incremental mechanism [PORT] could be used in
	these cases to reduce information to be carried in the backup joins.
	The establishing of primary path could be a normal PIM join process.		The establishing of primary path could be a normal PIM join process.
	In this case an ordinary PIM join is generated on the initiating		In this case an ordinary PIM join is generated on the initiating
	node of primary path and is sent hop-by-hop upstream until the join		node of primary path and is sent hop-by-hop upstream until the join
	arrives at the root of the tree or at the other valid forwarding		arrives at the root of the tree or at the other valid forwarding
	branch.		branch.
	2.2. Fault Processing		2.2. Fault Processing
	The fault on the primary path could be detected by using some fault		The fault on the primary path could be detected by using some fault
	detection mechanism (e.g. BFD protocol), which is configured to be		detection mechanism (e.g. BFD protocol), which is configured to be
	run between each pair of PIM neighbors. If error condition occurs,		run between each pair of PIM neighbors. If error condition occurs,
	the node on the upstream or downstream of the error point will		the node on the upstream or downstream of the error point will
	possibly detect it and should pass this error condition to the		possibly detect it and should pass this error condition to the
	backup path, and enable multicast data forwarding on it.		backup path, and enable multicast data forwarding on it.
	As the node on the primary path detects a failure, it could flood		As the node on the primary path detects a failure, it could choose
	the failure notification packet to all its PIM neighbors. Then the		to flood the failure notification packet to all its PIM neighbors
	notification will reach to all the PIM routers in the area. To		until all the PIM routers in the area get the notification. To
	prevent excessive transmission of these packets, the sending and		prevent excessive transmission of these packets, the sending and
	forwarding of the packets should be rate-limited. The fault		forwarding of the packets should be rate-limited. There are other
	notification like this can be implemented by extending BFD or other		options such as setting up special fault notification tree with
	protocol, which is not covered by this document.		reserved multicast address and etc.
	When backup node(s) receive the notification packets, they will		After the enabling of the backup path triggered by the fault
	enable the multicast forwarding which was previous disabled. To		notification, the multicast data will be forwarded along the backup
	select correct data stream switching to the backup path, the		path to the initiating node of the backup path. The initiating
	information of primary path ID should be carried in the notification.		point will change the backup incoming interface (IIF) as its RPF
	And prior to that, the backup path should record the primary path ID		interface if no data is available from the primary IIF.
	for corresponding multicast forwarding entries during backup join
	operation.
	After the enabling of the backup path, the multicast data will be		2.3. Fault Recovery
	forwarded along the path downstream to the initiating node of the
	backup path. The backup path initiating point then changes the
	backup incoming interface (IIF) as its RPF interface if no data is
	available from the primary IIF.
	If primary path heals, multicast forwarding could choose to switch		If primary path heals, multicast forwarding could choose to switch
	back to the primary path. The primary join will be generated hop-		back to the primary path. Once the data is received from the
	by-hop to set up the primary path, as illustrated in section 2.1.		primary IIF, the initiating node will change its RPF interface to
	Once the data is received from the primary IIF, the initiating node		its primary IIF. The node may also send a PIM prune message to tear
	will change its RPF interface to its primary IIF. The node may also		down the backup path, and may possibly after waiting for a specified
	send a PIM prune message to tear down the backup path, and may		period of time, re-setup the backup path without stream using the
	possibly after waiting for a specified period of time, re-setup the		same process as described in section 2.1.
	backup path without stream using the same process as described in
	section 2.1.
	3. The Definition of packet format		3. The Definition of packet format
	3.1. Multicast FRR join Attribute		3.1. Multicast FRR join Attribute
	The format of the join attribute is defined as:		The format of the join attribute is defined as:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| F| E| Attr_Type | Length | Flags | Path Count |		|F|E| Attr_Type | Length | Flags | Path Count |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Path ID |		| Path ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ . . . ~		~ . . . ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Path ID |		| Path ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	- F-bit, Transitive Attribute. If this bit is set, the attribute is		- F-bit, Transitive Attribute. If this bit is set, the attribute is
	a transitive attribute; otherwise, it is a non-transitive attribute		a transitive attribute; otherwise, it is a non-transitive attribute
	skipping to change at page 6, line 5 ¶		skipping to change at page 5, line 35 ¶
	- E-bit, End of Attributes. If this bit is set, then this is the		- E-bit, End of Attributes. If this bit is set, then this is the
	last Join Attribute appearing in the Encoded-Source Address field		last Join Attribute appearing in the Encoded-Source Address field
	specified by [RFC5384].		specified by [RFC5384].
	- Attr_Type, Type of the Attribute. It should be set to a new value		- Attr_Type, Type of the Attribute. It should be set to a new value
	(e.g.) for this MFA join attribute, e.g., taking value of 8.		(e.g.) for this MFA join attribute, e.g., taking value of 8.
	- Length, a 1-octet field specifying the length in octets, encoded		- Length, a 1-octet field specifying the length in octets, encoded
	as an unsigned binary integer, of the value field.		as an unsigned binary integer, of the value field.
	- Flags, flag for primary or backup join. 0 is for a primary join, 1		- Flags, flags for the methods of setting up of primary or backup
	for backup join.		paths. For the rightmost bit, 0 is for a primary join, 1 for backup
			join. Other bits are reserved for the future definition.
	- Path Count, the number of path included following Path ID.		- Path Count, the number of Path ID.
	- Path ID, the Identification for this path.		- Path ID, the Identification for this path. It may be an interface
			ID or a logical number to identify a primary path.
	3.2. PIM multicast FRR Hello Options		3.2. PIM multicast FRR Hello Options
	This multicast FRR Hello options are used for the PIM neighbors to		This multicast FRR Hello options are used for the PIM neighbors to
	negotiate the capability of multicast FRR join attribute. It has		negotiate the capability of multicast FRR join attribute. It has
	the format prescribed in [RFC5384] and the OptionType is defined a		the format prescribed in [RFC5384] and the OptionType is defined a
	new value representing this MFA attribute.		new value representing this MFA attribute.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OptionType | OptionLength |		| OptionType | OptionLength |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OptionValue |		| OptionValue |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	- OptionType = 38		- OptionType = 38
	- OptionLength = 8		- OptionLength = 8
	- OptionValue, reserved for future use		- OptionValue, reserved for future use
	4. Scenario Analysis for Single Stream Forwarding		4. Single Stream Implementation Options
	4.1. Disabling all nodes on backup path		4.1. Disabling all nodes on backup path
	In this method, when backup join is transmitted to set up the backup		In this method, when backup join is transmitted to set up the backup
	path, the backup forwarding states of all the nodes are by default		path, the forwarding states of all backup nodes are by default
	disabled for multicast data forwarding when being created. When		disabled for multicast data forwarding when being created. When
	backup join arrives at a primary node that has primary forwarding		backup join arrives at a primary node that has primary forwarding
	state, it is ''absorbed'' and will not created any backup state there.		state, it is ''absorbed'' and will not create any backup state there.
			Because each node on the backup path could be disabled or enabled
	Because each backup path will be merged at transit or root node of a		for data forwarding, it is possible to implement relatively precise
	multicast tree, and each node on this backup path could be disabled		control of path switching.
	or enabled for data forwarding, it is possible to implement
	relatively precise control of path switching.
	RT1 | |		RT1 | |
	/ RT1 - RT2		/ RT1 - RT2
	RT2 / \		RT2 / \
	| \ RT3 RT4		| \ RT3 RT4
	RT3 RT4 \ /		RT3 RT4 \ /
	/ \ / RT5 - RT6		/ \ / RT5 - RT6
	RT5 RT6		RT5 RT6
	Figure 1 Figure 2		Figure 1 Figure 2
	Figure 1 is an example of an arbitrary tree topology. Supposing RT6		Figure 1 is an example of an arbitrary tree topology. Supposing RT6
	has a downstream receiver and it is the initiating node of both the		has a downstream receiver and it is the initiating node of both the
	primary and backup path for this receiver. Then RT1-RT2-RT3-RT6 is		primary and backup path for this receiver. RT2-RT3-RT6 is setup as
	setup as the primary path by primary join, and RT2-RT4-RT6 as the		the primary path by primary join, and RT2-RT4-RT6 as the backup path
	backup path by backup join. The backup forwarding states for the		by backup join. The backup forwarding entries for the backup path,
	backup path, i.e. the outgoing interfaces of RT2 (the one towards		i.e. the outgoing interfaces of RT2 (the one towards RT4) and RT4
	RT4) and RT4 (towards RT6) are all disabled for multicast forwarding.		(towards RT6), are all disabled for multicast forwarding. Only
	Only primary path imports multicast stream through RT2 to RT6 and to		primary path imports multicast stream through RT2 to RT6 and to the
	the receiver.		receiver.
	If link between RT3 and RT6 goes down, the failure will be detected		If link between RT3 and RT6 goes down, the failure will be detected
	and be notified to RT2 and RT4 on backup path. They will be enabled		by RT6. The fault notification will be generated by RT6 and be
	the data forwarding on their outgoing interface, and the data will		notified to RT4 and RT2 on backup path, by flooding or through fault
	be imported from RT2, through RT4, to RT6 and the receiver.		multicast tree which is pre-established on RT4 and RT2 by back join
			with RT6 as the source of the tree The nodes RT4 and RT2 will be
			enabled the data forwarding on their outgoing interfaces, and the
			data will be imported from RT2, through RT4, to RT6 and the receiver.
	In the ring topology shown in figure 2, supposing RT3 has a receiver		In the ring topology shown in figure 2, supposing RT3 has a receiver
	downstream, the primary path for it is RT1-RT3 and takes the duty of		downstream, the primary path for it is RT1-RT3 and takes the duty of
	data forwarding. The backup path is RT2-RT4-RT6-RT5-RT3 and the		data forwarding. The backup path is RT2-RT4-RT6-RT5-RT3 and the
	backup outgoing interface on each of them is disabled when the		backup outgoing interface on each of them is disabled when the
	forwarding state is created. If link between RT1 and RT3 breaks,		forwarding state is created. If node RT1 undergos failure, it will
	the failure will be detected and be notified to RT2, RT4, RT6, and		be detected by RT3 and be notified by flooding or by multicast fault
	RT5. They will enable their data forwarding, and the traffic will		tree which is pre-established on RT5, RT6, RT4, and RT2, with RT3 as
	be delivered along backup path to RT3 and to the receiver. Each		the source of the tree. After enabling data forwarding for these
	node on the ring processes in the similar manner, if it has		nodes, the traffic will be delivered along backup path to RT3 and to
	downstream multicast receiver. If any upstream failure on the		the receiver. Each node on the ring processes in the similar manner,
	primary path occurs, the node will turn to receive reverse stream		if it has downstream multicast receiver. If any upstream failure on
	from the backup path.		the primary path occurs, the node will turn to receive reverse
			stream from the backup path.
			Because a backup node or path might provide protection for more than
			one primary path, the identification of the primary path should be
			bound to its own backup multicast entries, which requires the
			identification to be carried in the backup join during setting up of
			backup path, and in the fault notification to enable the forwarding
			of these entries.
			In normal cases, a primary path is identified by the primary IIF ID
			of an initiating node. In figure 1, this ID is the upstream
			interface ID of RT6 towards RT3. Its correlation with backup
			forwarding entries are maintained at RT4 and RT2. The backup path
			RT2-RT4-RT6 is used to protect failure detected by RT6 (i.e. RT3
			node failure or RT3-RT6 link failure). To provide protection for
			the whole primary network, each primary node is required to have a
			backup interface to form disjoint backup path for the upstream node/
			link to be protected, which is generally the case for ring topology
			and dual-homing protection tree topology.
			As an extension, the primary ID could also be the collection of all
			interface IDs of a primary path (i.e. upstream interface IDs of RT3
			and RT6 in figure 1), which could be configured on the initiating
			point (i.e. RT6) and be carried in backup join. The fault
			notification still carries the interface ID of downstream detecting
			node. Because the backup path is set up according to the interface
			ID collection for the whole primary path, one backup path can
			provide protection for a complete primary path (i.e. RT2-RT3-RT6),
			rather than for only one hop distance in the former case.
	4.2. Disabling only root node on backup path		4.2. Disabling only root node on backup path
	In this method, when backup join is sent hop-by-hop to setup the		In this method, when backup join is sent to setup the backup path,
	backup path, only the root node is disabled of its multicast data		only the root node is disabled of its multicast data forwarding.
	forwarding. The forwarding states on other nodes on the backup path		The forwarding states on other nodes on the backup path are kept
	are kept normal. In normal condition, the only stream comes from		normal. In normal condition, the only stream comes from the primary
	the primary path established by the primary join. If error occurs		path established by the primary join. If error occurs on the
	on the primary path, the root node of the backup path is notified of		primary path, the root node of the backup path is notified of the
	the failure, it then enables its data forwarding and the data stream		failure, it then enables its data forwarding and the data stream
	will be delivered from the backup path to the receiver.		will be delivered from the backup path to the receiver.
	The primary join and backup join in this method can be used to setup		Because only the ingress node of the backup path is disabled, the
	primary and backup trees. In normal condition, only primary tree		method requires the backup path not to intersect with the primary
	makes the multicast forwarding. When failure occurs on the primary		path for the intermediate nodes and can be applied to multiple tree
	tree, the root node of the backup tree could be notified to open its		topologies. E.g., the primary join and backup join can be used to
	data forwarding and the multicast data will delivered over the		setup primary and backup trees with only primary tree makes the
	backup tree to the receiver.		multicast forwarding in normal condition. When failure occurs on
			the primary tree, the root node of the backup tree could be notified
			to open its data forwarding and the multicast data will delivered
			over the backup tree to the receiver.
	5. Security Considerations		5. Security Considerations
	They will be described in the later version of this draft.		They will be described in the later version of this draft.
	6. Acknowledgement		6. References
	Special thanks should be given to Bai Tao for his valuable comments
	on the work.
	7. References
	7.1. Normative References		6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
	requirement levels", RFC 2119, March 1997.		requirement levels", RFC 2119, March 1997.
	[RFC4601] Fenner, W., "Internet Group Management Protocol, Version		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	2", RFC 2236, November 1997.		"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
			Specification (Revised)", RFC 4601, August 2006.
	[RFC5384] Deering, S. ''Host Extensions for IP Multicasting'', RFC1112,		[RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent
	August 1989.		Multicast (PIM) Join Attribute Format", RFC 5384, November 2008
	[RFC5880] Katz, D., and Ward, D., "Bidirectional Forwarding		[RFC5880] Katz, D., and Ward, D., "Bidirectional Forwarding
	Detection", RFC 5880, June, 2010.		Detection", RFC 5880, June, 2010.
	7.2. Informative References
	[PORT] Farinacci, D., "A Reliable Transport Mechanism for PIM",
	draft-ietf-pim-port-03.txt, March, 2010.
	Authors' Addresses		Authors' Addresses
	Hui Liu		Hui Liu
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	Huawei Bld., No.3 Xinxi Rd.		Huawei Bld., No.3 Xinxi Rd.
	Shang-Di Information Industry Base		Shang-Di Information Industry Base
	Hai-Dian Distinct, Beijing 100085		Hai-Dian Distinct, Beijing 100085
	China		China
	EMail: Liuhui47967@huawei.com		EMail: Liuhui47967@huawei.com
	Lianshu Zheng		Lianshu Zheng
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	Huawei Bld., No.3 Xinxi Rd.		Huawei Bld., No.3 Xinxi Rd.
	Shang-Di Information Industry Base		Shang-Di Information Industry Base
	Hai-Dian Distinct, Beijing 100085		Hai-Dian Distinct, Beijing 100085
	China		China
	EMail: verozheng@huawei.com		EMail: verozheng@huawei.com
			Tao Bai
			Huawei Technologies Co., Ltd.
			No.156 BeiQing Rd.
			Hai-Dian Distinct, Beijing 100094
			EMail: baitao_bys@huawei.com
	YunFu Yu		YunFu Yu
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	No.156 BeiQing Rd.		No.156 BeiQing Rd.
	Hai-Dian Distinct, Beijing 100094		Hai-Dian Distinct, Beijing 100094
	China		China
	EMail: yuyunfu@huawei.com		EMail: yuyunfu@huawei.com
End of changes. 34 change blocks.
	136 lines changed or deleted		149 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/