< draft-ietf-mospf-mospf-00.txt		draft-ietf-mospf-mospf-01.txt >
	Network Working Group J. Moy		Network Working Group J. Moy
	Internet Draft Ascend Communications, Inc.		Internet Draft Ascend Communications, Inc.
	Expiration Date: February 1999 August 1998		Expiration Date: May 1999 December 1998
	File name: draft-ietf-mospf-mospf-00.txt		File name: draft-ietf-mospf-mospf-01.txt
	Multicast Extensions to OSPF		Multicast Extensions to OSPF
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	C Sample datagram shortest-path trees ................... 92		C Sample datagram shortest-path trees ................... 92
	C.1 An intra-area tree .................................... 93		C.1 An intra-area tree .................................... 93
	C.2 The effect of areas ................................... 95		C.2 The effect of areas ................................... 95
	C.3 The effect of virtual links ........................... 96		C.3 The effect of virtual links ........................... 96
	D Differences from RFC 1584 ............................. 97		D Differences from RFC 1584 ............................. 97
	D.1 Bug Fixes ............................................. 97		D.1 Bug Fixes ............................................. 97
	D.1.1 Merging datagram shortest-path trees .................. 97		D.1.1 Merging datagram shortest-path trees .................. 97
	D.1.2 Candidate list initialization for stub areas .......... 97		D.1.2 Candidate list initialization for stub areas .......... 97
	D.1.3 Sources on multiply addressed segments ................ 97		D.1.3 Sources on multiply addressed segments ................ 97
	D.1.4 Local group database modifications .................... 98		D.1.4 Local group database modifications .................... 98
			D.1.5 Setting the W-bit in backbone router-LSAs ............. 98
			D.1.6 Post-processing a cache entry's outgoing interfaces ... 98
	D.2 Changes required by RFC 2328 .......................... 98		D.2 Changes required by RFC 2328 .......................... 98
	D.2.1 Deleting the TOS routing option ....................... 98		D.2.1 Deleting the TOS routing option ....................... 98
	D.2.2 Giving more-specific sources precedence ............... 98		D.2.2 Giving more-specific sources precedence ............... 98
	D.3 Changes required by IGMPv2 ............................ 98		D.3 Changes required by IGMPv2 ............................ 98
	D.4 Clarifications ........................................ 99		D.4 Clarifications ........................................ 99
	Security Considerations .............................. 100		Security Considerations .............................. 100
	Author's Address ..................................... 100		Author's Address ..................................... 100
	1. Introduction		1. Introduction
	This memo documents enhancements to OSPF Version 2 to support IP		This memo documents enhancements to OSPF Version 2 to support IP
	skipping to change at page 12, line 39 ¶		skipping to change at page 12, line 39 ¶
	state advertisements, the group-membership-LSA is flooded		state advertisements, the group-membership-LSA is flooded
	throughout the Autonomous System. A MOSPF router's group-		throughout the Autonomous System. A MOSPF router's group-
	membership-LSA for Group A lists those local transit		membership-LSA for Group A lists those local transit
	vertices (i.e., the router itself and/or any directly		vertices (i.e., the router itself and/or any directly
	connected transit networks) that should not be pruned from		connected transit networks) that should not be pruned from
	Group A's datagram shortest-path trees. The router lists		Group A's datagram shortest-path trees. The router lists
	itself in its group-membership-LSA for Group A if either 1)		itself in its group-membership-LSA for Group A if either 1)
	one or more of the router's attached stub networks contain		one or more of the router's attached stub networks contain
	Group A members or 2) the router itself is a member of Group		Group A members or 2) the router itself is a member of Group
	A. The router lists a directly connected transit network in		A. The router lists a directly connected transit network in
			the group-membership-LSA for Group A if both 1) the router
	Router local group database		Router local group database
	____________________________________________________		____________________________________________________
	RT1 [Group B, N1], [Group B, N3]		RT1 [Group B, N1], [Group B, N3]
	RT2 [Group A, N2], [Group B, N2], [Group B, N3]		RT2 [Group A, N2], [Group B, N2], [Group B, N3]
	RT3 [Group B, N3]		RT3 [Group B, N3]
	RT4 [Group B, N3]		RT4 [Group B, N3]
	Table 1: Sample local group databases		Table 1: Sample local group databases
	the group-membership-LSA for Group A if both 1) the router
	is Designated Router on the network and 2) the network		is Designated Router on the network and 2) the network
	contains one or more Group A members.		contains one or more Group A members.
	In Figure 1, if Router RT3 has been elected Designated		In Figure 1, if Router RT3 has been elected Designated
	Router for Network N3, then each of the routers RT1, RT2 and		Router for Network N3, then each of the routers RT1, RT2 and
	RT3 will originate a group-membership-LSA for Group B. In		RT3 will originate a group-membership-LSA for Group B. In
	addition, RT2 will also be originating a group-membership-		addition, RT2 will also be originating a group-membership-
	LSA for Group A. RT1 and RT2's group-membership-LSAs will		LSA for Group A. RT1 and RT2's group-membership-LSAs will
	list solely the routers themselves (N1 and N2 are stub		list solely the routers themselves (N1 and N2 are stub
	networks). RT3's group-membership-LSA will list the transit		networks). RT3's group-membership-LSA will list the transit
	skipping to change at page 14, line 4 ¶		skipping to change at page 13, line 51 ¶
	datagram's shortest-path tree is a pruned shortest-path tree		datagram's shortest-path tree is a pruned shortest-path tree
	rooted at the datagram's source. Two datagrams having		rooted at the datagram's source. Two datagrams having
	differing [source net, multicast destination] pairs may		differing [source net, multicast destination] pairs may
	have, and in fact probably will have, different pruned		have, and in fact probably will have, different pruned
	shortest-path trees.		shortest-path trees.
	A datagram's shortest path tree is built "on demand"[3],		A datagram's shortest path tree is built "on demand"[3],
	i.e., when the first multicast datagram is received having a		i.e., when the first multicast datagram is received having a
	particular [source net, multicast destination] combination.		particular [source net, multicast destination] combination.
	To build the datagram's shortest-path tree, the following		To build the datagram's shortest-path tree, the following
			calculations are performed. First, the datagram's source IP
	**FROM**		**FROM**
	|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|		|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
	|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|		|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
	----- ---------------------------------------------		----- ---------------------------------------------
	RT1| | | | | | | | | | | | |0 | | | |		RT1| | | | | | | | | | | | |0 | | | |
	RT2| | | | | | | | | | | | |0 | | | |		RT2| | | | | | | | | | | | |0 | | | |
	RT3| | | | | |6 | | | | | | |0 | | | |		RT3| | | | | |6 | | | | | | |0 | | | |
	RT4| | | | |8 | | | | | | | |0 | | | |		RT4| | | | |8 | | | | | | | |0 | | | |
	RT5| | | |8 | |6 |6 | | | | | | | | | |		RT5| | | |8 | |6 |6 | | | | | | | | | |
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	Figure 2: The MOSPF database.		Figure 2: The MOSPF database.
	Networks and routers are represented by vertices.		Networks and routers are represented by vertices.
	An edge of cost X connects Vertex A to Vertex B iff		An edge of cost X connects Vertex A to Vertex B iff
	the intersection of Column A and Row B is marked		the intersection of Column A and Row B is marked
	with an X. In addition, RT1, RT2 and N3 are labelled		with an X. In addition, RT1, RT2 and N3 are labelled
	with multicast group A and RT1, N6 and RT9 are		with multicast group A and RT1, N6 and RT9 are
	labelled with multicast group B.		labelled with multicast group B.
	calculations are performed. First, the datagram's source IP
	network is located in the link state database. Then using		network is located in the link state database. Then using
	the router-LSAs and network-LSAs in the link state database,		the router-LSAs and network-LSAs in the link state database,
	a shortest-path tree is built having the source network as		a shortest-path tree is built having the source network as
	root. To complete the process, the branches that do not		root. To complete the process, the branches that do not
	contain routers/transit networks that have been labelled		contain routers/transit networks that have been labelled
	with the particular multicast destination (via a group-		with the particular multicast destination (via a group-
	membership-LSA) are pruned from the tree.		membership-LSA) are pruned from the tree.
	As an example of the building of a datagram's shortest path		As an example of the building of a datagram's shortest path
	tree, again consider the Autonomous System in Figure 1. The		tree, again consider the Autonomous System in Figure 1. The
	skipping to change at page 16, line 5 ¶		skipping to change at page 15, line 49 ¶
	would be indicated by a forwarding cache entry having no		would be indicated by a forwarding cache entry having no
	upstream node or an empty list of downstream interfaces.		upstream node or an empty list of downstream interfaces.
	As an example of a router describing its position on the		As an example of a router describing its position on the
	datagram's shortest-path tree, consider Router RT10 in		datagram's shortest-path tree, consider Router RT10 in
	Figure 3. Router RT10's upstream node for the datagram is		Figure 3. Router RT10's upstream node for the datagram is
	Router RT6, and there are two downstream interfaces: one		Router RT6, and there are two downstream interfaces: one
	connecting to Network N6 and the other connecting to Network		connecting to Network N6 and the other connecting to Network
	N8.		N8.
			2.3.3. Support for Non-broadcast networks
			When forwarding multicast datagrams over non-broadcast
			networks, the datagram cannot be sent as a link-level
	o RT3 (N4, origin)		o RT3 (N4, origin)
	/ \		/ \
	1/ \8		1/ \8
	/ \		/ \
	N3 (Mb) o o RT6		N3 (Mb) o o RT6
	/ \		/ \
	0/ \7		0/ \7
	/ \		/ \
	RT2 (Ma,Mb) o o RT10		RT2 (Ma,Mb) o o RT10
	/ \		/ \
	skipping to change at page 16, line 34 ¶		skipping to change at page 16, line 33 ¶
	/		/
	N9 o		N9 o
	/		/
	0/		0/
	/		/
	RT9 (Ma) o		RT9 (Ma) o
	Figure 3: Sample datagram's shortest-path tree,		Figure 3: Sample datagram's shortest-path tree,
	source N4, destination Group A		source N4, destination Group A
	2.3.3. Support for Non-broadcast networks
	When forwarding multicast datagrams over non-broadcast
	networks, the datagram cannot be sent as a link-level
	multicast (since neither link-level multicast nor broadcast		multicast (since neither link-level multicast nor broadcast
	are supported on these networks), but must instead be		are supported on these networks), but must instead be
	forwarded separately to specific neighbors. To facilitate		forwarded separately to specific neighbors. To facilitate
	this, forwarding cache entries can also contain downstream		this, forwarding cache entries can also contain downstream
	neighbors as well as downstream interfaces.		neighbors as well as downstream interfaces.
	The IGMP protocol is not defined over non-broadcast		The IGMP protocol is not defined over non-broadcast
	networks. For this reason, there cannot be group members		networks. For this reason, there cannot be group members
	directly attached to non-broadcast networks, nor do non-		directly attached to non-broadcast networks, nor do non-
	broadcast networks ever appear in local group database		broadcast networks ever appear in local group database
	skipping to change at page 18, line 35 ¶		skipping to change at page 18, line 31 ¶
	(reflected by a change in group-membership-LSAs), all cache		(reflected by a change in group-membership-LSAs), all cache
	entries associated with the particular multicast destination		entries associated with the particular multicast destination
	group must be cleared. Other than these two cases,		group must be cleared. Other than these two cases,
	forwarding cache entries need not ever be deleted or		forwarding cache entries need not ever be deleted or
	otherwise modified; in particular, the forwarding cache		otherwise modified; in particular, the forwarding cache
	entries do not have to be aged. However, forwarding cache		entries do not have to be aged. However, forwarding cache
	entries can be freely deleted after some period of		entries can be freely deleted after some period of
	inactivity (i.e., garbage collected), if router memory		inactivity (i.e., garbage collected), if router memory
	resources are in short supply.		resources are in short supply.
			3. Inter-area multicasting
			Up to this point this memo has discussed multicast forwarding when
			the entire Autonomous System is a single OSPF area. The logic for
			when the multicast datagram's source and its destination group
			members belong to the same OSPF area is the same. This section
	Router Upstream Downstream interfaces		Router Upstream Downstream interfaces
	node (interface:hops)		node (interface:hops)
	___________________________________________		___________________________________________
	RT10 Router RT6 (N6:1), (N8:2)		RT10 Router RT6 (N6:1), (N8:2)
	RT11 Net N8 (N9:1)		RT11 Net N8 (N9:1)
	RT3 Net N4 (N3:1), (RT6:3)		RT3 Net N4 (N3:1), (RT6:3)
	RT6 Router RT3 (RT10:2)		RT6 Router RT3 (RT10:2)
	RT2 Net N3 (N2:1)		RT2 Net N3 (N2:1)
	Table 2: Sample forwarding cache entries,		Table 2: Sample forwarding cache entries,
	for source N4 and destination Group A.		for source N4 and destination Group A.
	3. Inter-area multicasting
	Up to this point this memo has discussed multicast forwarding when
	the entire Autonomous System is a single OSPF area. The logic for
	when the multicast datagram's source and its destination group
	members belong to the same OSPF area is the same. This section
	explains the behavior of the MOSPF protocol when the datagram's		explains the behavior of the MOSPF protocol when the datagram's
	source and (at least some of) its destination group members belong		source and (at least some of) its destination group members belong
	to different OSPF areas. This situation is called inter-area		to different OSPF areas. This situation is called inter-area
	multicast.		multicast.
	Inter-area multicast brings up the following issues, which are		Inter-area multicast brings up the following issues, which are
	resolved in succeeding sections:		resolved in succeeding sections:
	o Are the group-membership-LSAs specific to a single area? And if		o Are the group-membership-LSAs specific to a single area? And if
	they are, how is group membership information conveyed from one		they are, how is group membership information conveyed from one
	skipping to change at page 20, line 8 ¶		skipping to change at page 20, line 5 ¶
	Figure 4 as an example. This figure, taken from the OSPF		Figure 4 as an example. This figure, taken from the OSPF
	specification, shows an Autonomous System split into three areas		specification, shows an Autonomous System split into three areas
	(Area 1, Area 2 and Area 3). A single backbone area has been		(Area 1, Area 2 and Area 3). A single backbone area has been
	configured (everything outside of the shading). Since the backbone		configured (everything outside of the shading). Since the backbone
	area must be contiguous, a single virtual link has been configured		area must be contiguous, a single virtual link has been configured
	between the area border routers RT10 and RT11. Additionally, an area		between the area border routers RT10 and RT11. Additionally, an area
	address range has been configured in Router RT11 so that Networks		address range has been configured in Router RT11 so that Networks
	N9-N11 and Host H1 will be reported as a single route outside of		N9-N11 and Host H1 will be reported as a single route outside of
	Area 3 (via summary-LSAs).		Area 3 (via summary-LSAs).
	3.1. Extent of group-membership-LSAs
	Group-membership-LSAs are specific to a single OSPF area. This
	means that, just as with OSPF router-LSAs, network-LSAs and
	summary-LSAs, a group-membership-LSA is flooded throughout a
	single area only[6]. A router attached to multiple areas (i.e.,
	an area border router) may end up originating several group-
	membership-LSAs concerning a single multicast destination, one
	for each attached area. However, as we will see below, the
	contents of these group-membership-LSAs will vary depending on
	their associated areas.
	Just as in OSPF, each MOSPF area has its own link state
	database. The MOSPF database is simply the OSPF link state
	database enhanced by the group-membership-LSAs. Consider again
	the area configuration pictured in Figure 4. The result of
	adding the group-membership-LSAs to the area databases yields
	the databases pictured in Figures 6 and 7. Figure 6 shows Area
	1's MOSPF database. RT1, RT2 and N3 are labelled with multicast
	group A, RT1 is labelled with multicast group B, and both RT3
	and RT4 are labelled as wild-card multicast receivers. Summary-
	LSAs and ASE-external-LSAs are also included, as links
	originating from routers RT3 and RT4, and from routers RT5 and
	RT7, respectively.
	Similarly, Figure 7 shows the backbone's MOSPF database. Note
	that Router RT11 has condensed its routes to Networks N9-N11 and
	Host H1 into a single summary-LSA.
	Suppose an OSPF router has a local group database entry for
	[Group Y, Network X], and that the router has been elected
	Designated Router on Network X. The router then originates a
	group-membership-LSA for Group Y into the area containing
	Network X. For example, in the area configuration pictured in
	Figure 4, Router RT1 originates a group-membership-LSA for Group
	B. This group-membership-LSA is flooded throughout Area 1, and
	no further. Likewise, assuming that Router RT3 has been elected
	Designated Router for Network N3, RT3 originates a group-
	membership-LSA into Area 1 listing the transit Network N3 as
	having group members. Note that in the link state database for
	Area 1 (Figure 6) both Router RT1 and Network N3 have
	accordingly been labelled with Group B.
	..................................		..................................
	. + .		. + .
	. | 3+---+ +--+ +--+ . N12 N14		. | 3+---+ +--+ +--+ . N12 N14
	. N1|--|RT1|\1 |Mb| |H4| . \ N13 /		. N1|--|RT1|\1 |Mb| |H4| . \ N13 /
	. _| +---+ \ +--+ /+--+ . 8\ |8/8		. _| +---+ \ +--+ /+--+ . 8\ |8/8
	. | + \ _|__/ . \|/		. | + \ _|__/ . \|/
	. +--+ +--+ / \ 1+---+8. 8+---+6		. +--+ +--+ / \ 1+---+8. 8+---+6
	. |Mb| |Mb| * N3 *---|RT4|------|RT5|--------+		. |Mb| |Mb| * N3 *---|RT4|------|RT5|--------+
	. +--+ /+--+ \____/ +---+ . +---+ |		. +--+ /+--+ \____/ +---+ . +---+ |
	. + / | . |7 |		. + / | . |7 |
	skipping to change at page 22, line 4 ¶		skipping to change at page 21, line 4 ¶
	. +--+ 10+----+ ..N8 +---+ .		. +--+ 10+----+ ..N8 +---+ .
	. |H1|-----|RT12| .. |RT8| .		. |H1|-----|RT12| .. |RT8| .
	. +--+SLIP +----+ .. +---+ +--+.		. +--+SLIP +----+ .. +---+ +--+.
	. |2 .. |4 _|H5|.		. |2 .. |4 _|H5|.
	. | .. | / +--+.		. | .. | / +--+.
	. +---------+ .. +--------+ .		. +---------+ .. +--------+ .
	. N10 Area 3..Area 2 N7 .		. N10 Area 3..Area 2 N7 .
	.............................................................		.............................................................
	Figure 4: A sample MOSPF area configuration		Figure 4: A sample MOSPF area configuration
			3.1. Extent of group-membership-LSAs
			Group-membership-LSAs are specific to a single OSPF area. This
			means that, just as with OSPF router-LSAs, network-LSAs and
			summary-LSAs, a group-membership-LSA is flooded throughout a
			single area only[6]. A router attached to multiple areas (i.e.,
			an area border router) may end up originating several group-
			membership-LSAs concerning a single multicast destination, one
			for each attached area. However, as we will see below, the
			contents of these group-membership-LSAs will vary depending on
			their associated areas.
			Just as in OSPF, each MOSPF area has its own link state
			database. The MOSPF database is simply the OSPF link state
			database enhanced by the group-membership-LSAs. Consider again
			the area configuration pictured in Figure 4. The result of
			adding the group-membership-LSAs to the area databases yields
			the databases pictured in Figures 6 and 7. Figure 6 shows Area
			1's MOSPF database. RT1, RT2 and N3 are labelled with multicast
			group A, RT1 is labelled with multicast group B, and both RT3
			and RT4 are labelled as wild-card multicast receivers. Summary-
			LSAs and ASE-external-LSAs are also included, as links
			originating from routers RT3 and RT4, and from routers RT5 and
			RT7, respectively.
			Similarly, Figure 7 shows the backbone's MOSPF database. Note
			that Router RT11 has condensed its routes to Networks N9-N11 and
			Host H1 into a single summary-LSA.
			Suppose an OSPF router has a local group database entry for
			[Group Y, Network X], and that the router has been elected
			Designated Router on Network X. The router then originates a
			group-membership-LSA for Group Y into the area containing
			Network X. For example, in the area configuration pictured in
			Figure 4, Router RT1 originates a group-membership-LSA for Group
			B. This group-membership-LSA is flooded throughout Area 1, and
			no further. Likewise, assuming that Router RT3 has been elected
			Designated Router for Network N3, RT3 originates a group-
			membership-LSA into Area 1 listing the transit Network N3 as
			having group members. Note that in the link state database for
			Area 1 (Figure 6) both Router RT1 and Network N3 have
			accordingly been labelled with Group B.
	In OSPF, the area border routers forward routing information and		In OSPF, the area border routers forward routing information and
	data traffic between areas. In MOSPF. a subset of the area		data traffic between areas. In MOSPF. a subset of the area
	border routers, called the inter-area multicast forwarders,		border routers, called the inter-area multicast forwarders,
	forward group membership information and multicast datagrams		forward group membership information and multicast datagrams
	between areas. Whether a given OSPF area border router is also a		between areas. Whether a given OSPF area border router is also a
	MOSPF inter-area multicast forwarder is configuration dependent		MOSPF inter-area multicast forwarder is configuration dependent
	(see Section B.1). In Figure 4 we assume that all area border		(see Section B.1). In Figure 4 we assume that all area border
	routers are also inter-area multicast forwarders.		routers are also inter-area multicast forwarders.
	In order to convey group membership information between areas,		In order to convey group membership information between areas,
	skipping to change at page 22, line 40 ¶		skipping to change at page 22, line 35 ¶
	MOSPF is asymmetric. While a non-backbone area's group		MOSPF is asymmetric. While a non-backbone area's group
	membership is summarized to the backbone, this information is		membership is summarized to the backbone, this information is
	not then readvertised into other non-backbone areas. Nor is the		not then readvertised into other non-backbone areas. Nor is the
	backbone's group membership summarized for the non-backbone		backbone's group membership summarized for the non-backbone
	areas. Going back to the example in Figure 4, while the presence		areas. Going back to the example in Figure 4, while the presence
	of Area 3's group (Group A) is advertised to the backbone, this		of Area 3's group (Group A) is advertised to the backbone, this
	information is not then redistributed to Area 1. In other words,		information is not then redistributed to Area 1. In other words,
	routers internal to Area 1 have no idea of Area 3's group		routers internal to Area 1 have no idea of Area 3's group
	membership.		membership.
			At this point, if no extra functionality was added to MOSPF,
			multicast traffic originating in Area 1 destined for Multicast
			Group A would never be forwarded to those Group A members in
			Area 3. To accomplish this, the notion of wild-card multicast
	membership +------------------+ datagrams		membership +------------------+ datagrams
	+ > > > >>| Backbone |< < < < +		+ > > > >>| Backbone |< < < < +
	^ +------------------+ ^		^ +------------------+ ^
	^ / | \ ^		^ / | \ ^
	^ / | \ ^		^ / | \ ^
	+----^-----+/ +----------+ \+----^-----+		+----^-----+/ +----------+ \+----^-----+
	| Area 1 | | Area 2 | | Area 3 |		| Area 1 | | Area 2 | | Area 3 |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	Figure 5: Inter-area routing architecture		Figure 5: Inter-area routing architecture
	At this point, if no extra functionality was added to MOSPF,
	multicast traffic originating in Area 1 destined for Multicast
	Group A would never be forwarded to those Group A members in
	Area 3. To accomplish this, the notion of wild-card multicast
	receivers is introduced. A wild-card multicast receiver is a		receivers is introduced. A wild-card multicast receiver is a
	router to which all multicast traffic, regardless of multicast		router to which all multicast traffic, regardless of multicast
	destination, should be forwarded. A router's wild-card multicast		destination, should be forwarded. A router's wild-card multicast
	reception status is per-area. In non-backbone areas, all inter-		reception status is per-area. In non-backbone areas, all inter-
	area multicast forwarders[7] are wild-card multicast receivers.		area multicast forwarders[7] are wild-card multicast receivers.
	This ensures that all multicast traffic originating in a non-		This ensures that all multicast traffic originating in a non-
	backbone area will be forwarded to its inter-area multicast		backbone area will be forwarded to its inter-area multicast
	forwarders, and hence to the backbone area. Since the backbone		forwarders, and hence to the backbone area. Since the backbone
	has complete knowledge of all areas' group membership, the		has complete knowledge of all areas' group membership, the
	datagram can then be forwarded to all group members. Note that		datagram can then be forwarded to all group members. Note that
	skipping to change at page 24, line 5 ¶		skipping to change at page 23, line 48 ¶
	use of wild-card multicast receivers and OSPF summary-LSAs.		use of wild-card multicast receivers and OSPF summary-LSAs.
	When it first receives a datagram for a particular [source net,		When it first receives a datagram for a particular [source net,
	destination group] pair, a router calculates a separate datagram		destination group] pair, a router calculates a separate datagram
	shortest-path tree for each of the router's attached areas. Each		shortest-path tree for each of the router's attached areas. Each
	datagram shortest-path tree is built solely from LSAs belonging		datagram shortest-path tree is built solely from LSAs belonging
	to the particular area's link state database. Suppose that a		to the particular area's link state database. Suppose that a
	router is calculating a datagram shortest-path tree for Area A.		router is calculating a datagram shortest-path tree for Area A.
	It is useful then to separate out two cases.		It is useful then to separate out two cases.
			The first case, Case 1: The source of the datagram belongs to
			Area A has already been described in Section 2.3.2. However, in
			the presence of OSPF areas, during tree pruning care must be
			taken so that the branches leading to other areas remain, since
	**FROM**		**FROM**
	|RT|RT|RT|RT|RT|RT|		|RT|RT|RT|RT|RT|RT|
	|1 |2 |3 |4 |5 |7 |N3|		|1 |2 |3 |4 |5 |7 |N3|
	----- -------------------		----- -------------------
	RT1| | | | | | |0 |		RT1| | | | | | |0 |
	RT2| | | | | | |0 |		RT2| | | | | | |0 |
	RT3| | | | | | |0 |		RT3| | | | | | |0 |
	* RT4| | | | | | |0 |		* RT4| | | | | | |0 |
	* RT5| | |14|8 | | | |		* RT5| | |14|8 | | | |
	skipping to change at page 25, line 41 ¶		skipping to change at page 25, line 41 ¶
	Figure 7: The backbone's MOSPF database.		Figure 7: The backbone's MOSPF database.
	Networks and routers are represented by vertices.		Networks and routers are represented by vertices.
	An edge of cost X connects Vertex A to Vertex B iff		An edge of cost X connects Vertex A to Vertex B iff
	the intersection of Column A and Row B is marked		the intersection of Column A and Row B is marked
	with an X. In addition, RT3 and RT4 are labelled		with an X. In addition, RT3 and RT4 are labelled
	with both multicast groups A and B, and RT7, RT10,		with both multicast groups A and B, and RT7, RT10,
	and RT11 are labelled with multicast group A.		and RT11 are labelled with multicast group A.
	The first case, Case 1: The source of the datagram belongs to
	Area A has already been described in Section 2.3.2. However, in
	the presence of OSPF areas, during tree pruning care must be
	taken so that the branches leading to other areas remain, since
	it is unknown whether there are group members in these (remote)		it is unknown whether there are group members in these (remote)
	areas. For this reason, only those branches having no group		areas. For this reason, only those branches having no group
	members nor wild-card multicast receivers are pruned when		members nor wild-card multicast receivers are pruned when
	producing the datagram shortest-path tree.		producing the datagram shortest-path tree.
	As an example, suppose in Figure 4 that Host H2 sends a		As an example, suppose in Figure 4 that Host H2 sends a
	multicast datagram to destination Group A. Then the datagram's		multicast datagram to destination Group A. Then the datagram's
	shortest-path tree for Area 1, built identically by all routers		shortest-path tree for Area 1, built identically by all routers
	in Area 1 that receive the datagram, is shown in Figure 8. Note		in Area 1 that receive the datagram, is shown in Figure 8. Note
	that both inter-area multicast forwarders (RT3 and RT4) are on		that both inter-area multicast forwarders (RT3 and RT4) are on
	skipping to change at page 26, line 37 ¶		skipping to change at page 26, line 33 ¶
	As an example, suppose again that Host H2 in Figure 4 sends		As an example, suppose again that Host H2 in Figure 4 sends
	a multicast datagram to destination Group A. The datagram's		a multicast datagram to destination Group A. The datagram's
	shortest-path tree for the backbone is shown in Figure 9.		shortest-path tree for the backbone is shown in Figure 9.
	The neighborhood around the source (Network N4) has been		The neighborhood around the source (Network N4) has been
	approximated by the summary links advertised by routers RT3		approximated by the summary links advertised by routers RT3
	and RT4. Note that all links in Figure 9's datagram		and RT4. Note that all links in Figure 9's datagram
	shortest-path tree have arrows pointing in the reverse		shortest-path tree have arrows pointing in the reverse
	direction, towards Network N4 instead of away from it.		direction, towards Network N4 instead of away from it.
			The reverse costs used for the entire tree in Case 2 are forced
			because summary-LSAs only specify the cost towards the datagram
			source. In the presence of asymmetric link costs, this may lead
	o RT3 (W, origin=N4)		o RT3 (W, origin=N4)
	|		|
	1|		1|
	|		|
	N3 (Mb) o		N3 (Mb) o
	/ \		/ \
	0/ \0		0/ \0
	/ \		/ \
	RT2 (Ma,Mb) o o RT4 (W)		RT2 (Ma,Mb) o o RT4 (W)
	skipping to change at page 27, line 27 ¶		skipping to change at page 27, line 27 ¶
	|		|
	2|		2|
	|		|
	RT11 (Ma) o		RT11 (Ma) o
	Figure 9: Datagram shortest-path tree: Backbone,		Figure 9: Datagram shortest-path tree: Backbone,
	source N4, destination Group A. Note that		source N4, destination Group A. Note that
	reverse costs (i.e., toward origin) are		reverse costs (i.e., toward origin) are
	used throughout.		used throughout.
	The reverse costs used for the entire tree in Case 2 are forced
	because summary-LSAs only specify the cost towards the datagram
	source. In the presence of asymmetric link costs, this may lead
	to less efficient routes when forwarding multicasts between		to less efficient routes when forwarding multicasts between
	areas.		areas.
	Those routers attached to multiple areas must calculate multiple		Those routers attached to multiple areas must calculate multiple
	trees and then merge them into a single forwarding cache entry.		trees and then merge them into a single forwarding cache entry.
	As shown in Section 2.3.2, when connected to a single area the		As shown in Section 2.3.2, when connected to a single area the
	router's position on the datagram shortest-path tree determines		router's position on the datagram shortest-path tree determines
	(in large part) its forwarding cache entry. When attached to		(in large part) its forwarding cache entry. When attached to
	multiple areas, and hence calculating multiple datagram		multiple areas, and hence calculating multiple datagram
	shortest-path trees, each tree contributes to the forwarding		shortest-path trees, each tree contributes to the forwarding
	skipping to change at page 30, line 22 ¶		skipping to change at page 30, line 18 ¶
	tree indicates that the routers expect the datagram to enter		tree indicates that the routers expect the datagram to enter
	the Autonomous System at Router RT7, and then to enter the		the Autonomous System at Router RT7, and then to enter the
	area at Router RT4.		area at Router RT4.
	Note that in those cases where the "best" inter-AS multicast		Note that in those cases where the "best" inter-AS multicast
	forwarder is not directly attached to the area, the		forwarder is not directly attached to the area, the
	neighborhood of the source is actually approximated by the		neighborhood of the source is actually approximated by the
	concatenation of a summary link and a multicast-capable AS		concatenation of a summary link and a multicast-capable AS
	external link. This is in fact the case in Figure 10.		external link. This is in fact the case in Figure 10.
			In Case 3 (datagram source in another AS) the requirement that
			all tree links point in the reverse direction (towards the
			source) accommodates the fact that summary links and AS external
			links already point in the reverse direction. This also leads to
	o N12		o N12
	|		|
	2|		2|
	|		|
	o RT7		o RT7
	|		|
	14|		14|
	|		|
	o RT4 (W)		o RT4 (W)
	|		|
	skipping to change at page 31, line 5 ¶		skipping to change at page 31, line 5 ¶
	/ | \		/ | \
	RT1 (Mb) o | o RT3 (W)		RT1 (Mb) o | o RT3 (W)
	o		o
	RT2 (Ma,Mb)		RT2 (Ma,Mb)
	Figure 10: Datagram shortest-path tree: Area 1,		Figure 10: Datagram shortest-path tree: Area 1,
	source N12, destination Group B. Note that		source N12, destination Group B. Note that
	reverse costs (i.e., toward origin) are		reverse costs (i.e., toward origin) are
	used throughout.		used throughout.
	In Case 3 (datagram source in another AS) the requirement that
	all tree links point in the reverse direction (towards the
	source) accommodates the fact that summary links and AS external
	links already point in the reverse direction. This also leads to
	the requirement that the inter-AS multicast routing protocol		the requirement that the inter-AS multicast routing protocol
	operate in a reverse path forwarding fashion (see condition 2 of		operate in a reverse path forwarding fashion (see condition 2 of
	Section 4). Note that Reverse path forwarding can lead to sub-		Section 4). Note that Reverse path forwarding can lead to sub-
	optimal routing when costs are configured asymmetrically. And it		optimal routing when costs are configured asymmetrically. And it
	can even lead to non-delivery of multicast datagrams in the case		can even lead to non-delivery of multicast datagrams in the case
	of asymmetric reachability.		of asymmetric reachability.
	Inter-AS multicast forwarders may end up calculating a		Inter-AS multicast forwarders may end up calculating a
	forwarding cache entry's upstream node as being external to the		forwarding cache entry's upstream node as being external to the
	AS. As an example, Router RT7 in Figure 10 will end up		AS. As an example, Router RT7 in Figure 10 will end up
	skipping to change at page 33, line 4 ¶		skipping to change at page 32, line 48 ¶
	(pictured as a box containing a question mark) is made, and the		(pictured as a box containing a question mark) is made, and the
	packet is (possibly) forwarded out certain interfaces. If these		packet is (possibly) forwarded out certain interfaces. If these
	interfaces are not capable of receiving their own multicasts, a copy		interfaces are not capable of receiving their own multicasts, a copy
	of the datagram must be internally looped back to appropriately		of the datagram must be internally looped back to appropriately
	joined applications.		joined applications.
	The advantages to the RFC 1112 representation are as follows:		The advantages to the RFC 1112 representation are as follows:
	o It is the standard for the way an IP host joins multicast		o It is the standard for the way an IP host joins multicast
	groups. It is simplest to use the same membership model for		groups. It is simplest to use the same membership model for
			hosts and routers; most would consider an IP router to be a
			special case of an IP host anyway.
	+-------+		+-------+
	|receive|		|receive|
	+-------+		+-------+
	|		|
	|---> To application		|---> To application
	|		|
	+-------------------+		+-------------------+
	|forwarding decision|		|forwarding decision|
	+-------------------+		+-------------------+
	|		|
	skipping to change at page 33, line 26 ¶		skipping to change at page 33, line 27 ¶
	/ \------> To application		/ \------> To application
	/ \		/ \
	/ \		/ \
	+--------+ +--------+		+--------+ +--------+
	|transmit| |transmit|		|transmit| |transmit|
	+--------+ +--------+		+--------+ +--------+
	Figure 11: RFC 1112 representation of internal		Figure 11: RFC 1112 representation of internal
	group membership		group membership
	hosts and routers; most would consider an IP router to be a
	special case of an IP host anyway.
	o It is the way group membership has been implemented in BSD UNIX.		o It is the way group membership has been implemented in BSD UNIX.
	Existing multicast applications are written to join multicast		Existing multicast applications are written to join multicast
	groups on specific interfaces.		groups on specific interfaces.
	o The possibility of receiving multiple datagram copies may		o The possibility of receiving multiple datagram copies may
	improve fault tolerance. If the datagram is dropped due to an		improve fault tolerance. If the datagram is dropped due to an
	error on the path to some interface, another interface may still		error on the path to some interface, another interface may still
	receive a copy.		receive a copy.
	o The ability to specify a particular receiving interface may		o The ability to specify a particular receiving interface may
	skipping to change at page 34, line 27 ¶		skipping to change at page 34, line 24 ¶
	o The application does not need to have knowledge of the router		o The application does not need to have knowledge of the router
	interfaces. It does not need to know what kind or how many		interfaces. It does not need to know what kind or how many
	interfaces there are; this will be taken care of by the MOSPF		interfaces there are; this will be taken care of by the MOSPF
	protocol itself.		protocol itself.
	o As long as any interface is operational, the application will		o As long as any interface is operational, the application will
	continue to receive multicast datagrams. This happens		continue to receive multicast datagrams. This happens
	automatically, without the application modifying its group		automatically, without the application modifying its group
	membership.		membership.
			o The application receives only one copy of the datagram. Using
			the RFC1112 representation, whenever an application joins on
			more than one interface (which must be done if the application
	+-------+		+-------+
	|receive|		|receive|
	+-------+		+-------+
	|		|
	|		|
	|		|
	+-------------------+		+-------------------+
	|forwarding decision|---> to application		|forwarding decision|---> to application
	+-------------------+		+-------------------+
	|		|
	skipping to change at page 35, line 4 ¶		skipping to change at page 35, line 4 ¶
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	+--------+ +--------+		+--------+ +--------+
	|transmit| |transmit|		|transmit| |transmit|
	+--------+ +--------+		+--------+ +--------+
	Figure 12: MOSPF-specific representation of internal		Figure 12: MOSPF-specific representation of internal
	group membership		group membership
	o The application receives only one copy of the datagram. Using
	the RFC1112 representation, whenever an application joins on
	more than one interface (which must be done if the application
	does not want to rely on a single interface), multiple datagram		does not want to rely on a single interface), multiple datagram
	copies will be received during normal operation.		copies will be received during normal operation.
	6. Additional capabilities		6. Additional capabilities
	This section describes the MOSPF configuration options that allow		This section describes the MOSPF configuration options that allow
	routers of differing capabilities to be mixed together in the same		routers of differing capabilities to be mixed together in the same
	routing domain. Note that these options handle special circumstances		routing domain. Note that these options handle special circumstances
	that may not be encountered in normal operation. Default values for		that may not be encountered in normal operation. Default values for
	the configuration settings are specified in Appendix B.		the configuration settings are specified in Appendix B.
	skipping to change at page 38, line 4 ¶		skipping to change at page 37, line 50 ¶
	on those router interfaces attaching to the network (see Section		on those router interfaces attaching to the network (see Section
	B.2). As an example, in Figure 13 the routers in AS #2 could be		B.2). As an example, in Figure 13 the routers in AS #2 could be
	configured so that Router C would send the multicast datagram		configured so that Router C would send the multicast datagram
	out onto Network X as a data-link unicast addressed directly to		out onto Network X as a data-link unicast addressed directly to
	Router D. Router D would accept this data-link unicast, but		Router D. Router D would accept this data-link unicast, but
	would reject any data-link multicast forwarded by Router A. This		would reject any data-link multicast forwarded by Router A. This
	would eliminate replication of multicast datagrams downstream		would eliminate replication of multicast datagrams downstream
	from Network X. In addition, if the IPMulticastForwarding		from Network X. In addition, if the IPMulticastForwarding
	parameter is set to data-link unicast on Network X, group		parameter is set to data-link unicast on Network X, group
	membership will not be monitored on the network. This will		membership will not be monitored on the network. This will
			prevent group members attached directly to Network X from
			receiving multiple datagram copies, since group membership on
			the boundary network will be monitored from only one AS (AS #1
	<-Datagram path->*		<-Datagram path->*
	* *		* *
	* *		* *
	* .....*.........		* .....*.........
	.........*..... | . * AS #2		.........*..... | . * AS #2
	AS #1 * . |*****+---+		AS #1 * . |*****+---+
	+---+*****|*----|RTC|		+---+*****|*----|RTC|
	|RTA|----*|* . +---+		|RTA|----*|* . +---+
	+---+ . *|* .		+---+ . *|* .
	. *|* .		. *|* .
	skipping to change at page 38, line 25 ¶		skipping to change at page 38, line 25 ¶
	+---+ . *|*----|RTD|		+---+ . *|*----|RTD|
	|RTB|----*|*****+---+		|RTB|----*|*****+---+
	+---+*****| .....*..........		+---+*****| .....*..........
	.........*.... | *		.........*.... | *
	* | *		* | *
	* Network X *		* Network X *
	*		*
	Figure 13: Networks on AS boundaries		Figure 13: Networks on AS boundaries
	prevent group members attached directly to Network X from
	receiving multiple datagram copies, since group membership on
	the boundary network will be monitored from only one AS (AS #1
	in our example).		in our example).
	It should be noted that forwarding IP multicasts as data-link		It should be noted that forwarding IP multicasts as data-link
	unicasts has some disadvantages when three or more MOSPF routers		unicasts has some disadvantages when three or more MOSPF routers
	are attached to the network. First of all, it is more work for a		are attached to the network. First of all, it is more work for a
	router to send multiple unicasts than a single multicast.		router to send multiple unicasts than a single multicast.
	Second, the multiple unicasts consume more network bandwidth		Second, the multiple unicasts consume more network bandwidth
	than a single multicast. And last, it increases the delay for		than a single multicast. And last, it increases the delay for
	some group members since multiple unicasts also take longer to		some group members since multiple unicasts also take longer to
	send than a single multicast.		send than a single multicast.
	skipping to change at page 55, line 40 ¶		skipping to change at page 55, line 40 ¶
	This section describes how a MOSPF router forwards a multicast		This section describes how a MOSPF router forwards a multicast
	datagram that has been originated by one of the router's own		datagram that has been originated by one of the router's own
	internal applications. The process begins with one of the		internal applications. The process begins with one of the
	router's internal applications formatting and addressing the		router's internal applications formatting and addressing the
	datagram. Forwarding the locally originated multicast then		datagram. Forwarding the locally originated multicast then
	consists of the following steps:		consists of the following steps:
	(1) Find the router interface whose IP address matches the		(1) Find the router interface whose IP address matches the
	datagram's source address. Multicast the datagram out that		datagram's source address. Multicast the datagram out that
	interface, according to the Host extensions for IP		interface, according to the Host extensions for IP
			multicasting specified in [RFC 1112].
	Network Mask Cost MC-bit		Network Mask Cost MC-bit
	______________________________________________________		______________________________________________________
	10.1.1.0 255.255.255.0 Type 1: 10 clear		10.1.1.0 255.255.255.0 Type 1: 10 clear
	10.1.0.0 255.255.0.0 Type 2: LSInfinity set		10.1.0.0 255.255.0.0 Type 2: LSInfinity set
	10.0.0.0 255.0.0.0 Type 2: 1 set		10.0.0.0 255.0.0.0 Type 2: 1 set
	Table 3: Sample AS-external-LSAs		Table 3: Sample AS-external-LSAs
	multicasting specified in [RFC 1112].
	(2) Set the receiving MOSPF interface to that interface.		(2) Set the receiving MOSPF interface to that interface.
	(3) Execute the MOSPF forwarding process described in Section		(3) Execute the MOSPF forwarding process described in Section
	11, beginning with its Step 4.		11, beginning with its Step 4.
	The above algorithm amounts to the router always multicasting		The above algorithm amounts to the router always multicasting
	the datagram out the source interface, and the executing the		the datagram out the source interface, and the executing the
	basic forwarding algorithm (in Section 11) as if the datagram		basic forwarding algorithm (in Section 11) as if the datagram
	had actually been received on the source interface. In those		had actually been received on the source interface. In those
	cases where the router receives its own multicast transmissions,		cases where the router receives its own multicast transmissions,
	skipping to change at page 57, line 19 ¶		skipping to change at page 57, line 19 ¶
	initially set to NULL. After completing Area A's datagram		initially set to NULL. After completing Area A's datagram
	shortest-path tree, the calculation in Section 12.2.6 will		shortest-path tree, the calculation in Section 12.2.6 will
	determine whether Area A is the datagram's RootArea.		determine whether Area A is the datagram's RootArea.
	(3) Update the forwarding cache entry's list of outgoing interfaces,		(3) Update the forwarding cache entry's list of outgoing interfaces,
	according to the contents of the local group database. This		according to the contents of the local group database. This
	ensures multicast delivery to group members residing on the		ensures multicast delivery to group members residing on the
	calculating router's directly attached networks. This process is		calculating router's directly attached networks. This process is
	described in Section 12.3.		described in Section 12.3.
			(4) Ensure that none of the outgoing interfaces connect to the
			upstream node. If they do, remove them from the cache entry's
			list of outgoing interfaces. (An interface to the upstream node
			may have mistakenly been added to the forwarding cache entry if
			SourceNet is a locally advertised stub network).
	These main steps are described in more detail below. The detailed		These main steps are described in more detail below. The detailed
	description begins with an explanation of the major data structure		description begins with an explanation of the major data structure
	used by the datagram shortest-path tree calculation: The Vertex data		used by the datagram shortest-path tree calculation: The Vertex data
	structure.		structure.
	12.1. The Vertex data structure		12.1. The Vertex data structure
	A datagram shortest-path tree is built by the Dijkstra or SPF		A datagram shortest-path tree is built by the Dijkstra or SPF
	algorithm. The algorithm is stated herein using graph-oriented		algorithm. The algorithm is stated herein using graph-oriented
	language: vertices and links. Vertices are the area's routers		language: vertices and links. Vertices are the area's routers
	skipping to change at page 60, line 41 ¶		skipping to change at page 60, line 46 ¶
	SourceNet (i.e., has the smallest Cost value). If there are		SourceNet (i.e., has the smallest Cost value). If there are
	multiple possibilities, select transit networks over		multiple possibilities, select transit networks over
	routers. If there are still multiple possibilities		routers. If there are still multiple possibilities
	remaining, select the vertex having the highest Vertex ID.		remaining, select the vertex having the highest Vertex ID.
	Call the chosen vertex Vertex V. Remove Vertex V from the		Call the chosen vertex Vertex V. Remove Vertex V from the
	candidate list, and install it on the shortest-path tree.		candidate list, and install it on the shortest-path tree.
	Next, determine whether Vertex V has been labelled with the		Next, determine whether Vertex V has been labelled with the
	Destination multicast Group G. If so, it may cause the		Destination multicast Group G. If so, it may cause the
	forwarding cache entry's list of outgoing		forwarding cache entry's list of outgoing
	interfaces/neighbors to be updated. See Section 12.2.6 for		interfaces/neighbors to be updated. See Section 12.2.5 for
	details.		details.
	(5) Examine Vertex V's neighbors for possible inclusion in the		(5) Examine Vertex V's neighbors for possible inclusion in the
	candidate list. Consider Vertex V's LSA. Each link in the		candidate list. Consider Vertex V's LSA. Each link in the
	LSA describes a connection to a neighboring router/network.		LSA describes a connection to a neighboring router/network.
	If the link connects to a stub network, examine the next		If the link connects to a stub network, examine the next
	link in the LSA. Otherwise, the link (Link L) connects to a		link in the LSA. Otherwise, the link (Link L) connects to a
	neighboring transit node. Call this node Vertex W. Perform		neighboring transit node. Call this node Vertex W. Perform
	the following steps on Vertex W:		the following steps on Vertex W:
	a. If W is already on the shortest-path tree, or if W's LSA		a. If W is already on the shortest-path tree, or if W's LSA
	does not contain a link back to vertex V, or if W's LSA		does not contain a link back to vertex V, or if W's LSA
	has LS age of MaxAge, or if W is not multicast-capable		has LS age of MaxAge, or if W is not multicast-capable
	(indicated by the MC-bit in the LSA's Options field),		(indicated by the MC-bit in the LSA's Options field),
	examine the next link in V's LSA.		examine the next link in V's LSA.
	skipping to change at page 75, line 23 ¶		skipping to change at page 75, line 25 ¶
	14.6. Originating Router-LSAs		14.6. Originating Router-LSAs
	This functionality is described in Section 12.4.1 of [OSPF]. A		This functionality is described in Section 12.4.1 of [OSPF]. A
	MOSPF router sets the MC-bit in the Options field of its		MOSPF router sets the MC-bit in the Options field of its
	router-LSA. This allows the router to be included in datagram		router-LSA. This allows the router to be included in datagram
	shortest-path trees (see Step 5a of Section 12.2).		shortest-path trees (see Step 5a of Section 12.2).
	In addition, MOSPF has introduced a new flag in the router-LSA's		In addition, MOSPF has introduced a new flag in the router-LSA's
	rtype field: the W-bit. When the W-bit is set, the router is		rtype field: the W-bit. When the W-bit is set, the router is
	included on all datagram shortest-path trees, regardless of		included on all datagram shortest-path trees, regardless of
	multicast group (see Section 12.2.6). Such a router is called a		multicast group (see Section 12.2.5). Such a router is called a
	wild-card multicast receiver. The router sets the W-bit when it		wild-card multicast receiver. The router sets the W-bit when it
	wishes to receive all multicast datagrams, regardless of		wishes to receive all multicast datagrams, regardless of
	destination. This will sometimes be true of inter-area multicast		destination. This will sometimes be true of inter-area multicast
	forwarders (see Section 3.1), and inter-AS multicast forwarders		forwarders (see Section 3.1), and inter-AS multicast forwarders
	(see Section 4).		(see Section 4). In addition, an inter-area multicast forwarder
			must set the W-bit in its backbone router-LSA if there are
			inter-AS multicast forwarders interior to any of its attached
			non-zero areas. This can be detected by the presence of a
			router-LSA in one of its attached non-zero areas which does not
			have bit B (area border router) set but does have the W-bit set.
	A router must originate a new instance of its router-LSA		A router must originate a new instance of its router-LSA
	whenever an event occurs that would invalidate the LSA's current		whenever an event occurs that would invalidate the LSA's current
	contents. In particular, if the router's multicast capability or		contents. In particular, if the router's multicast capability or
	its ability to function as either an inter-area or inter-AS		its ability to function as either an inter-area or inter-AS
	multicast forwarder changes, its router-LSA must be		multicast forwarder changes, its router-LSA must be
	reoriginated.		reoriginated.
	14.7. Originating Network-LSAs		14.7. Originating Network-LSAs
	This functionality is described in Section 12.4.2 of [OSPF]. In		This functionality is described in Section 12.4.2 of [OSPF]. In
	OSPF, a transit network's network-LSA is originated by the		OSPF, a transit network's network-LSA is originated by the
	network's Designated Router. The Designated Router sets the MC-		network's Designated Router. The Designated Router sets the MC-
	bit in the Options field of the network-LSA if and only if both		bit in the Options field of the network-LSA if and only if both
	a) the Designated Router is multicast-capable (i.e., running		a) the Designated Router is multicast-capable (i.e., running
	MOSPF) and b) the Designated Router's interface's		MOSPF) and b) the Designated Router's interface's
	IPMulticastForwarding parameter has been set to a value other		IPMulticastForwarding parameter has been set to a value other
	than disabled (see Section B.2). When the network-LSA has the		than disabled (see Section B.2). When the network-LSA has the
	MC-bit set, the network can be included in datagram shortest-		MC-bit set, the network can be included in datagram shortest-
	path trees (see Section 12.2.6).		path trees (see Section 12.2).
	It is intended that all routers attached to a common network		It is intended that all routers attached to a common network
	agree on the network's IPMulticastForwarding capability.		agree on the network's IPMulticastForwarding capability.
	However, this agreement is not enforced. When there are		However, this agreement is not enforced. When there are
	disagreements, incorrect routing of multicast datagrams can		disagreements, incorrect routing of multicast datagrams can
	result.		result.
	14.8. Originating Summary-LSAs		14.8. Originating Summary-LSAs
	This functionality is described in Section 12.4.3 of [OSPF].		This functionality is described in Section 12.4.3 of [OSPF].
	Inter-area multicast forwarders always set the MC-bit in the		Inter-area multicast forwarders always set the MC-bit in the
	Options field of their summary-link-LSAs, regardless of whether		Options field of their summary-link-LSAs, regardless of whether
	the path described by the summary-LSA is actually multicast-		the path described by the summary-LSA is actually multicast-
	skipping to change at page 98, line 18 ¶		skipping to change at page 99, line 18 ¶
	processing. First, all MOSPF routers (and not just the		processing. First, all MOSPF routers (and not just the
	Designated Router and Backup Designated Router) maintain		Designated Router and Backup Designated Router) maintain
	local group database entries for their attached segments by		local group database entries for their attached segments by
	listening to IGMP membership Reports. Second, only those		listening to IGMP membership Reports. Second, only those
	local group database entries associated with stub networks		local group database entries associated with stub networks
	cause outgoing interfaces to be added to multicast		cause outgoing interfaces to be added to multicast
	forwarding cache entries.		forwarding cache entries.
	See Sections 2.3.1, 2.3.4, 9, 9.1, and 12.3 for details.		See Sections 2.3.1, 2.3.4, 9, 9.1, and 12.3 for details.
			D.1.5 Setting the W-bit in backbone router-LSAs
			An inter-area multicast forwarder must set the W-bit in its
			backbone router-LSA if there are inter-AS multicast
			forwarders interior to any of its attached non-zero areas.
			See Section 14.6 for details.
			D.1.6 Post-processing a cache entry's outgoing interfaces
			If a cache entry's SourceNet is a locally advertised stub
			network, interfaces to the cache entry's upstream node may
			have been mistakenly added to the cache entry's list of
			outgoing interfaces. These interfaces must be removed from
			the cache entry's list of outgoing interfaces at the end of
			the multicast routing calculation (see Section 12).
			The two places where an interface to the upstream node may
			have been mistakenly added are when a) SourceNet has entries
			in the local group database (see Section 12.3) and b)
			SourceNet is the address of the other end of a point-to-
			point link (see Section 12.2.6).
	D.2 Changes required by RFC 2328		D.2 Changes required by RFC 2328
	The following changes were made to stay in step with the latest		The following changes were made to stay in step with the latest
	OSPFv2 base specification [OSPF].		OSPFv2 base specification [OSPF].
	D.2.1 Deleting the TOS routing option		D.2.1 Deleting the TOS routing option
	As was done for the base OSPFv2 specification, TOS routing		As was done for the base OSPFv2 specification, TOS routing
	has now been removed from the MOSPF specification, due to		has now been removed from the MOSPF specification, due to
	lack of deployment experience.		lack of deployment experience.
	skipping to change at page 100, line 26 ¶		skipping to change at page 102, line 26 ¶
	Author's Address		Author's Address
	John Moy		John Moy
	Ascend Communications, Inc.		Ascend Communications, Inc.
	1 Robbins Road		1 Robbins Road
	Westford, MA 01886		Westford, MA 01886
	Phone: 978-952-1367		Phone: 978-952-1367
	Fax: 978-392-2075		Fax: 978-392-2075
	Email: jmoy@casc.com		Email: jmoy@casc.com
	This document expires in February 1999.		This document expires in May 1999.
End of changes. 37 change blocks.
	88 lines changed or deleted		127 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/