< draft-lu-fn-transport-03.txt		draft-lu-fn-transport-04.txt >
	Network Working Group W. Lu		Network Working Group W. Lu
	Internet-Draft S. Kini		Internet-Draft S. Kini
	Intended status: Standards Track A. Csaszar, Ed.		Intended status: Standards Track A. Csaszar, Ed.
	Expires: September 13, 2012 G. Enyedi		Expires: August 29, 2013 G. Enyedi
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	March 12, 2012		February 25, 2013
	Transport of Fast Notification Messages		Transport of Fast Notification Messages
	draft-lu-fn-transport-03		draft-lu-fn-transport-04
	Abstract		Abstract
	This document specifies mechanisms for fast and light-weight		This document specifies mechanisms for fast and light-weight
	dissemination of event notifications. The purpose is to enable		dissemination of event notifications. The purpose is to enable
	dataplane dissemination of Fast Notifications (FNs). The draft		dataplane dissemination of Fast Notifications (FNs). The draft
	discusses the design goals, the message container and options for		discusses the design goals, the message container and options for
	delivering the notifications to all routers within a routing area.		delivering the notifications to all routers within a routing area.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 13, 2012.		This Internet-Draft will expire on August 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	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 respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Transport Logic - Distribution of the Notifications . . . . . 4		3. Transport Logic - Distribution of the Notifications . . . . . 4
	3.1. Duplicate Check . . . . . . . . . . . . . . . . . . . . . 5		3.1. Flooding mode . . . . . . . . . . . . . . . . . . . . . . 5
			3.1.1. Duplicate Check with Flooding . . . . . . . . . . . . 5
			3.2. Spanning Tree Mode . . . . . . . . . . . . . . . . . . . . 6
	4. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 6		4. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Seamless Encapsulation . . . . . . . . . . . . . . . . . . 6		4.1. Seamless Encapsulation . . . . . . . . . . . . . . . . . . 6
	4.2. Dedicated FN Message . . . . . . . . . . . . . . . . . . . 6		4.2. Dedicated FN Message . . . . . . . . . . . . . . . . . . . 7
	4.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 8		4.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 8
	4.2.1.1. Area-scoped and Link-scoped Authentication . . . . 9		4.2.1.1. Area-scoped and Link-scoped Authentication . . . . 9
	4.2.1.2. Simple Password Authentication . . . . . . . . . . 9		4.2.1.2. Simple Password Authentication . . . . . . . . . . 9
	4.2.1.3. Cryptographic Authentication for FN . . . . . . . 10		4.2.1.3. Cryptographic Authentication for FN . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. FN Packet Processing Summary . . . . . . . . . . . . . . . . . 13		6. FN Packet Processing Summary . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Further Options for Transport Logic . . . . . . . . . 14		Appendix A. Further Options for Transport Logic . . . . . . . . . 15
	A.1. Multicast Tree-based Transport . . . . . . . . . . . . . . 15		A.1. Multicast Tree-based Transport . . . . . . . . . . . . . . 15
	A.1.1. Fault Tolerance of a Single Distribution Tree . . . . 15		A.1.1. Fault Tolerance of a Single Distribution Tree . . . . 16
	A.1.2. Pair of Redundant Trees . . . . . . . . . . . . . . . 15		A.1.2. Pair of Redundant Trees . . . . . . . . . . . . . . . 16
	A.2. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 17		A.2. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 18
	A.2.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 17		A.2.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 18
	A.2.2. Sample Operation . . . . . . . . . . . . . . . . . . . 18		A.2.2. Sample Operation . . . . . . . . . . . . . . . . . . . 19
	A.3. Gated Multicast through RPF Check . . . . . . . . . . . . 19		A.3. Gated Multicast through RPF Check . . . . . . . . . . . . 19
	A.3.1. Loop Prevention - RPF Check . . . . . . . . . . . . . 19		A.3.1. Loop Prevention - RPF Check . . . . . . . . . . . . . 20
	A.3.2. Operation . . . . . . . . . . . . . . . . . . . . . . 20		A.3.2. Operation . . . . . . . . . . . . . . . . . . . . . . 20
	A.4. Further Multicast Tree based Transport Options . . . . . . 21		A.4. Further Multicast Tree based Transport Options . . . . . . 21
	A.4.1. Source Specific Trees . . . . . . . . . . . . . . . . 21		A.4.1. Source Specific Trees . . . . . . . . . . . . . . . . 21
	A.4.2. A Single Bidirectional Shared Tree . . . . . . . . . . 21		A.4.2. A Single Bidirectional Shared Tree . . . . . . . . . . 22
	A.5. Layer 2 Networks . . . . . . . . . . . . . . . . . . . . . 22		A.5. Layer 2 Networks . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Enabling fast dissemination of a network event to routers in a		Enabling fast dissemination of a network event to routers in a
	limited area could benefit multiple applications. Existing use cases		limited area could benefit multiple applications. Existing use cases
	are centered around new approaches for IP Fast ReRoute such as		are centered around new approaches for IP Fast ReRoute such as
	[I-D.csaszar-ipfrr-fn]. In the future, however, multiple innovative		[I-D.csaszar-ipfrr-fn]. In the future, however, multiple innovative
	applications may take advantage of a Fast Notification service.		applications may take advantage of a Fast Notification service.
	A hop by hop control plane based flooding mechanism is used widely		A hop by hop control plane based flooding mechanism is used widely
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	flooding procedures.		flooding procedures.
	5. The mechanism should have low processing overhead.		5. The mechanism should have low processing overhead.
	These design goals present a trade-off. Proper balance needs to be		These design goals present a trade-off. Proper balance needs to be
	found that offers good authentication and reliability while keeping		found that offers good authentication and reliability while keeping
	processing complexity sufficiently low to enable implementation in		processing complexity sufficiently low to enable implementation in
	dataplane. This draft proposes solutions that take the above goals		dataplane. This draft proposes solutions that take the above goals
	and trade-offs into considerations.		and trade-offs into considerations.
			It is important to note that information contained by the
			notification packet may needed to be processed at multiple points in
			the router (e.g. multiple linecards may need to react on that
			message). This document describes the way of sending the information
			between nodes, but distributing this information inside the node (if
			needed) is out of the scope of this document.
	3. Transport Logic - Distribution of the Notifications		3. Transport Logic - Distribution of the Notifications
	The distribution of a notification to multiple receivers can be		The distribution of a notification to multiple receivers can be
	implemented in many ways. The main body of this draft describes one		implemented in many ways. The main body of this draft describes some
	such option, a flooding-like approach.		such options, however, other application specific distribution
			mechanisms may exist. Some more details can be found in the
			Appendix.
			3.1. Flooding mode
	In flooding mode, the IGP configures the dataplane cards to replicate		In flooding mode, the IGP configures the dataplane cards to replicate
	each received FN message to each interface with a neighbour router in		each received FN message to each interface with a neighbour router in
	the same area.		the same area.
	This happens by making use of bidirectional multicast forwarding. In		This happens by making use of bidirectional multicast forwarding. In
	bidir multicast, all interfaces added to the multicast group can be		bidir multicast, all interfaces added to the multicast group can be
	incoming and outgoing interfaces as well. The principle is that a		incoming and outgoing interfaces as well. The principle is that a
	router replicates the incoming packet to *all* assigned interfaces		router replicates the incoming packet to *all* assigned interfaces
	except the incoming interface. If the local router is the source of		except the incoming interface. If the local router is the source of
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 36 ¶
	IP destination address to the MC-FN multicast address. This IP		IP destination address to the MC-FN multicast address. This IP
	packet is then multicasted to all IGP neighbours in the area.		packet is then multicasted to all IGP neighbours in the area.
	Recipients of FN multicast-forward the packet according to the rules		Recipients of FN multicast-forward the packet according to the rules
	of bidirectional multicast, i.e. to all interfaces which the local		of bidirectional multicast, i.e. to all interfaces which the local
	IGP pre-configured except the incoming interface. As this may cause		IGP pre-configured except the incoming interface. As this may cause
	loops without pre-caution (consider three routers in a triangle),		loops without pre-caution (consider three routers in a triangle),
	before forwarding, therefore, the forwarding engine has to perform		before forwarding, therefore, the forwarding engine has to perform
	duplicate check.		duplicate check.
	3.1. Duplicate Check		3.1.1. Duplicate Check with Flooding
	Duplicate check can be performed in numeruous ways.		Duplicate check can be performed in numeruous ways.
	Duplicate check can be performed by maintaining a short queue of		Duplicate check can be performed by maintaining a short queue of
	previously forwarded FN messages. Before forwarding, if the FN		previously forwarded FN messages. Before forwarding, if the FN
	message is found in the queue, then it was forwarded beforehand, so		message is found in the queue, then it was forwarded beforehand, so
	it may be dropped. Otherwise it should be forwarded and it should be		it may be dropped. Otherwise it should be forwarded and it should be
	added to the queue.		added to the queue.
	Alternatively, the queue may contain a signature of the previously		Alternatively, the queue may contain a signature of the previously
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 18 ¶
	trigger the most FN messages (1 from each neighbour).		trigger the most FN messages (1 from each neighbour).
	It is also possible to use application-dependent duplicate check: the		It is also possible to use application-dependent duplicate check: the
	state machine of the FN-application can be left responsible to decide		state machine of the FN-application can be left responsible to decide
	whether the information carried in the packet contains new		whether the information carried in the packet contains new
	information or it is a duplicate. This is only useful in the case if		information or it is a duplicate. This is only useful in the case if
	the application can perform the duplicate check more efficiently than		the application can perform the duplicate check more efficiently than
	the above generic mechanisms. Presently, [I-D.csaszar-ipfrr-fn]		the above generic mechanisms. Presently, [I-D.csaszar-ipfrr-fn]
	specifies an application-specific duplicate check procedure.		specifies an application-specific duplicate check procedure.
			3.2. Spanning Tree Mode
			If reliable forwarding of notification packet is not always a strict
			requirement, spanning trees may be used for forwarding. In the
			simplest case, the nodes can build up a single spannig tree, and
			notification packets can be forwarded along this tree with
			bidirectional forwarding. This solution has the advantage that no
			duplicate check is needed. The tree may be built up with
			bidirectional PIM [RFC5015].
			Another possibility is to use Maximally Redundant Trees
			[I-D.ietf-rtgwg-mrt-frr-architecture], a pair of spanning trees which
			give some failure tolerance. Since the common root of these trees
			can always be reached in the case of a single failure, and since the
			root can reach all the nodes, notification packets sent on both trees
			can tolerate any single failure, if the root propagates the packets
			it received on both trees. Further details about spanning trees are
			described in the Appendix.
	4. Message Encoding		4. Message Encoding
	4.1. Seamless Encapsulation		4.1. Seamless Encapsulation
	An application may define its own message for FN to distribute		An application may define its own message for FN to distribute
	quickly. In this case, only the special destination address (e.g.		quickly. In this case, only the special destination address (e.g.
	MC-FN) shows that the message was sent using the FN service.		MC-FN) shows that the message was sent using the FN service.
	In this case, the entire payload of the IP packet is determined by		In this case, the entire payload of the IP packet is determined by
	the application including sequence numbering and authentication. The		the application including sequence numbering and authentication. The
	skipping to change at page 13, line 16 ¶		skipping to change at page 13, line 37 ¶
	When receiving an FN packet, a node has to perform the following		When receiving an FN packet, a node has to perform the following
	steps.		steps.
	It has to identify that the packet is an FN packet. This can be done		It has to identify that the packet is an FN packet. This can be done
	utilising the destination IP address (MC-FN) or by inspecting the UDP		utilising the destination IP address (MC-FN) or by inspecting the UDP
	port field.		port field.
	If the flooding like transport logic described in Section 3 is used		If the flooding like transport logic described in Section 3 is used
	the node has to perform duplicate check following the teachings in		the node has to perform duplicate check following the teachings in
	Section 3.1.		Section 3.1.1.
	If AuType is non-null, the node has to perform authentication check		If AuType is non-null, the node has to perform authentication check
	as discussed in Section 4.2.1.		as discussed in Section 4.2.1.
	To protect against replay attacks, the node shall perform		To protect against replay attacks, the node shall perform
	verification of the sequence number provided by the application.		verification of the sequence number provided by the application.
	Punt and forward. The notification may need to be multicasted but it		Punt and forward. The notification may need to be multicasted but it
	also needs to be punted to the local application on the linecard to		also needs to be punted to the local application on the linecard to
	start processing.		start processing.
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 34 ¶
	8. Acknowledgements		8. Acknowledgements
	The authors owe thanks to Acee Lindem, Joel Halpern and Jakob Heitz		The authors owe thanks to Acee Lindem, Joel Halpern and Jakob Heitz
	for their review and comments. Also thanks to Alia Atlas for		for their review and comments. Also thanks to Alia Atlas for
	constructive feedback.		constructive feedback.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
			[I-D.enyedi-rtgwg-mrt-frr-algorithm]
			Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan,
			"Algorithms for computing Maximally Redundant Trees for
			IP/LDP Fast- Reroute",
			draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in
			progress), October 2012.
			[I-D.ietf-rtgwg-mrt-frr-architecture]
			Atlas, A., Kebler, R., Envedi, G., Csaszar, A.,
			Konstantynowicz, M., White, R., and M. Shand, "An
			Architecture for IP/LDP Fast-Reroute Using Maximally
			Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01
			(work in progress), March 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.		[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
	Shaffer, "Extensions to OSPF for Advertising Optional		Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", RFC 4970, July 2007.		Router Capabilities", RFC 4970, July 2007.
	[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate		[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
	skipping to change at page 14, line 39 ¶		skipping to change at page 15, line 27 ¶
	"Bidirectional Protocol Independent Multicast (BIDIR-		"Bidirectional Protocol Independent Multicast (BIDIR-
	PIM)", RFC 5015, October 2007.		PIM)", RFC 5015, October 2007.
	9.2. Informative References		9.2. Informative References
	[Eny2009] Enyedi, G., Retvari, G., and A. Csaszar, "On Finding		[Eny2009] Enyedi, G., Retvari, G., and A. Csaszar, "On Finding
	Maximally Redundant Trees in Strictly Linear Time, IEEE		Maximally Redundant Trees in Strictly Linear Time, IEEE
	Symposium on Computers and Communications (ISCC)", 2009.		Symposium on Computers and Communications (ISCC)", 2009.
	[I-D.csaszar-ipfrr-fn]		[I-D.csaszar-ipfrr-fn]
	Csaszar, A., Tantsura, J., Kini, S., Sucec, J., and S.		Csaszar, A., Envedi, G., Tantsura, J., Kini, S., Sucec,
	Das, "IP Fast Re-Route with Fast Notification",		J., and S. Das, "IP Fast Re-Route with Fast Notification",
	draft-csaszar-ipfrr-fn-02 (work in progress),		draft-csaszar-ipfrr-fn-03 (work in progress), June 2012.
	October 2011.
	[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with		[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
	Digital Signatures", RFC 2154, June 1997.		Digital Signatures", RFC 2154, June 1997.
	Appendix A. Further Options for Transport Logic		Appendix A. Further Options for Transport Logic
	The options described in this appendix represent alternative		The options described in this appendix represent alternative
	solutions to the flooding based approach described in Section		solutions to the flooding based approach described in Section
	Section 3.		Section 3.
	skipping to change at page 15, line 50 ¶		skipping to change at page 16, line 37 ¶
	notifications (or a subset of them) may be sufficient for the		notifications (or a subset of them) may be sufficient for the
	application to make the right decision. This draft provides several		application to make the right decision. This draft provides several
	different transport options from which an applications can choose.		different transport options from which an applications can choose.
	A.1.2. Pair of Redundant Trees		A.1.2. Pair of Redundant Trees
	If an FN application needs the exact same data to be distributed in		If an FN application needs the exact same data to be distributed in
	the case of any single node or any single link failure, the FN		the case of any single node or any single link failure, the FN
	service could opt to run in "redundant tree mode".		service could opt to run in "redundant tree mode".
	A pair of "redundant trees" ensures that at each single node or link		A pair of "maximally redundant trees"
	failure each node still reaches the common root of the trees through		[I-D.enyedi-rtgwg-mrt-frr-algorithm] ensures that at each single node
	at least one of the trees. A redundant tree pair is a known prior-		or link failure each node still reaches the common root of the trees
	art graph-theoretical object that is possible to find on any 2-node		through at least one of the trees. A redundant tree pair is a known
	connected network. Even better, it is even possible to find		prior-art graph-theoretical object that is possible to find on any
			2-node connected network. Even better, it is even possible to find
	maximally redundant trees in networks where the 2-node connected		maximally redundant trees in networks where the 2-node connected
	criterion does not "fully" hold (e.g. there are a few cut vertices)		criterion does not "fully" hold (e.g. there are a few cut vertices)
	[Eny2009].		[Eny2009], [I-D.ietf-rtgwg-mrt-frr-architecture].
	Note that the referenced algorithm(s) build a pair of trees		Note that the referenced algorithm(s) build a pair of trees
	considering a specific root. The root can be selected in different		considering a specific root. The root can be selected in different
	ways, the only thing that is important that each node makes the same		ways, the only thing that is important that each node makes the same
	selection, consistently. For instance, the node with the highest or		selection, consistently. For instance, the node with the highest or
	lowest router ID can be used.		lowest router ID can be used.
	#1 tree #2 tree		#1 tree #2 tree
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	| B |=======| | | B |=======| |		| B |=======| | | B |=======| |
	skipping to change at page 16, line 38 ¶		skipping to change at page 17, line 26 ¶
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	| |=======| | | |=======| |		| |=======| | | |=======| |
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	Figure 6: Example: a pair of redundant trees (double lines) of a		Figure 6: Example: a pair of redundant trees (double lines) of a
	common root R		common root R
	There is one special constraint in building the redundant trees. A		There is one special constraint in building the redundant trees. A
	(maximally) redundant tree pair is needed, where in one of the trees		(maximally) redundant tree pair is needed, where in one of the trees
	the root has only one child in order to protect against the failure		the root has only one child in order to protect against the failure
	of the root itself. Algorithms presented in [Eny2009] produce such		of the root itself. Algorithms presented in [Eny2009],
	trees.		[I-D.enyedi-rtgwg-mrt-frr-algorithm] produce such trees.
	In redundant-tree mode, each node multicasts the requested		In redundant-tree mode, each node multicasts the requested
	notification on both trees, if it is possible, but at least along one		notification on both trees, if it is possible, but at least along one
	of the trees. Redundant trees require two multicast group addresses.		of the trees. Redundant trees require two multicast group addresses.
	MC-FN identifies one of the trees, and MC-FN-2 identifies the other		MC-FN identifies one of the trees, and MC-FN-2 identifies the other
	tree.		tree.
	Each node multicast forwards the received notification packet (on the		Each node multicast forwards the received notification packet (on the
	same tree). The root node performs as every other node but in		same tree). The root node performs as every other node but in
	addition it also multicast the notification on the other tree! I.e.		addition it also multicast the notification on the other tree! I.e.
End of changes. 24 change blocks.
	35 lines changed or deleted		81 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/