| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rtype | 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Link ID | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E
| Link Data | R
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | TOS 0 metric | #
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
# | TOS | 0 | metric | I
T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
O | ... | K
S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
| | TOS | 0 | metric | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ... |
The router LSA
+---+---+---+---+---+---+---+---+
| * | * | * | * | W | V | E | B |
+---+---+---+---+---+---+---+-+-+
The rtype field
The following defines the flags found in the rtype field. Each flag
classifies the router by function:
o bit B. When set, the router is an area border router (B is for
border). These routers forward unicast data traffic between OSPF
areas.
o bit E. When set, the router is an AS boundary router (E is for
external). These routers forward unicast data traffic between
Autonomous Systems.
o bit V. When set, the router is an endpoint of an active virtual
link (V is for virtual) which uses the described area as its
Transit area.
o bit W. When set, the router is a wild-card multicast receiver.
These routers receive all multicast datagrams, regardless of
destination. Inter-area multicast forwarders and inter-AS
multicast forwarders are sometimes wild-card multicast receivers
(see Sections 3 and 4).
A.3 Group-membership-LSA
Group-membership-LSAs are the Type 6 link state advertisements.
Group-membership-LSAs are specific to a particular OSPF area. They
are never flooded beyond their area of origination. A router's
group-membership-LSA for Area A indicates its directly attached
networks which belong to Area A and contain members of a particular
multicast group. A router originates a group-membership-LSA for
multicast group D when the following conditions are met for at least
one directly attached network: 1) the router has been elected
Designated Router for the network and 2) at least one host on the
network has joined Group D via the IGMP protocol.
A router may also originate a group-membership-LSA for Group D if
the router itself has internal applications belonging to Group D. In
addition, area border routers originate group-membership-LSAs into
the backbone area when there are group members in the router's
attached non-backbone areas. See Section 10 for more information
concerning the origination of group-membership-LSAs.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID = Destination Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vertex type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vertex ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The group-membership-LSA
The group-membership-LSA consists of the standard 20-byte link state
header (see Section A.4.1 of [OSPF]) followed by a list of transit
vertices to label with the multicast destination. The
advertisement's Link State ID is set to the destination multicast
group address. There is no metric associated with the advertisement.
Each transit vertex is specified by its Vertex type and Vertex ID
(see Section 12.1 for an explanation of this terminology):
o Vertex type. Set equal to 1 for a router, and 2 for a transit
network. Note that the only router that may be included in the
list is the Advertising Router itself.
o Vertex ID. For router vertices, this field indicates the
router's OSPF Router ID. For transit network vertices, this
field indicates the IP address of the network's Designated
Router. Note that the link state advertisement associated with
the transit vertex is the LSA whose LS type = Vertex type, Link
State ID = Vertex ID and Advertising Router = the group-
membership-LSA's Advertising Router.
B. Configurable Constants
This section documents the configurable parameters used by OSPF's
multicast routing extensions. These parameters are in addition to
the configurable constants used by the base OSPF protocol
(documented in Appendix C of [OSPF]). An implementation of MOSPF
must provide the ability to set these parameters, either through
network management or some other means.
B.1 Global parameters
The following parameters apply to the router as a whole.
o Multicast capability. An indication of whether the router is
running MOSPF. If the router is running MOSPF, it will
perform the algorithms as set forth in this specification.
Otherwise, the router is still able to run the basic OSPF
algorithm (as set forth in [OSPF]), and will be able to
interoperate with multicast capable routers (see Section
6.1) when forwarding regular (unicast) IP data traffic.
o Inter-area multicast forwarder. This parameter indicates
whether the router will forward multicast datagrams between
OSPF areas. Such a router summarizes group membership
information to the backbone, and acts as a wild-card
multicast receiver in all its attached non-backbone areas
(see Section 3.1). Not all multicast-capable area border
routers need be configured as inter-area multicast
forwarders. However, whenever both ends of a virtual link
are multicast-capable, they must both be configured as
inter-area multicast forwarders (see Section 14.11). By
default, all multicast-capable area border routers are
configured as inter-area multicast forwarders.
o Inter-AS multicast forwarder. This parameter indicates
whether the router forwards multicast datagrams between
Autonomous Systems. Such a router acts as a wild-card
multicast receiver in all attached areas (see Section 4). It
is also assumed that an inter-AS multicast forwarder runs
some kind of inter-AS multicast routing algorithm.
B.2 Router interface parameters
The following parameters can be configured separately for each
of the router's OSPF interfaces. Remember that an OSPF interface
is the connection between the router and one of its attached IP
networks. Note that the IPMulticastForwarding parameter is
really a description of the attached network. As such, it should
be configured identically on all routers attached to a common
network; otherwise incorrect routing of multicast datagrams may
result.
o IPMulticastForwarding. This configurable parameter indicates
whether IP multicasts should be forwarded over the attached
network, and if so, how the forwarding should be done. The
parameter can assume one of three possible values: disabled,
data-link multicast and data-link unicast. When set to
disabled, IP multicast datagrams will not be forwarded out
the interface. When set to data-link multicast, IP multicast
datagrams will be forwarded as data-link multicasts. When
set to data-link unicast, IP multicast datagrams will be
forwarded as data-link unicasts. The default value for this
parameter is data-link multicast. The other two settings are
for use in the special circumstances described in Sections
6.3 and 6.4. When set to disabled or to data-link unicast,
IGMP group membership is not monitored on the attached
network.
o IGMPPollingInterval. The number of seconds between IGMP Host
Membership Queries sent out this interface. A multicast-
capable router sends IGMP Host Membership Queries only when
it has been elected Designated Router for the attached
network. See [RFC1112] for a discussion of this parameter's
value.
o IGMP timeout. If no IGMP Host Membership Reports have been
heard on an attached network for a particular multicast
group A after this period of time, the entry [Group A,
attached network] is deleted from the router's local group
database. See Section 9 for more information.
C. Sample datagram shortest-path trees
In MOSPF, all routers must calculate exactly the same datagram
shortest-path trees. In order to ensure this in internetworks having
redundant links, a number of tie-breakers were defined in the MOSPF
routing table calculation (see Steps 4 and 5c of Section 12.2, and
Sections 12.2.4 and 12.2.7). This section illustrates the use of
these tie-breakers on a sample topology.
Three different examples are given. All examples use the same
physical topology and the same set of OSPF interface costs (see the
left side of Figure 14). The source of the datagram is always Host
H1 on the network at the top of the figure (192.9.1.0), and the
destination group members are the two hosts labelled with Group Ma
at the bottom of the figure. The first case shows an example of
intra-area multicast, while the remaining two cases show the
influence of OSPF areas on the path of a multicast datagram.
C.1 An intra-area tree
The datagram shortest-path tree resulting from the intra-area case
is shown on the right of Figure 14. The root of the tree is the
source network (192.9.1.0), and the leaves are the two routers (RT4
and RT3) directly attached to the stub networks containing Group Ma
members.
There are equal-cost paths available to both group members. For the
group member on the left, the path could go either through network
10.1.0.0 or through network 10.2.0.0. By the tie-breaking rules, the
path through 10.2.0.0 is chosen since it has the larger IP network
number (see Step 5c of Section 12.2).
For the group member on the right, the path could go either over
Network 10.2.0.0 or over the serial line connecting routers RT2 and
RT3. The path over Network 10.2.0.0 is chosen after executing two
tie-breaking rules. First, Network 10.2.0.0 is placed on the
shortest-path tree before Router RT3 since networks are always
chosen over routers (see Step 4 of Section 12.2). Then, given a
+--+
|H1|
+--+
Net 192.9.1.0 |
+------------------+
| |
+----------+ |1 |1
| Network | 8+---+ +---+ o 192.9.1.0
| 10.1.0.0 |------|RT1| |RT2| |
+----------+ +---+ +---+ 0|
| |8 8| |
8| +----------+ |8 o RT1
+---+10 | Network | 10+---+ |
|RT4|-------| 10.2.0.0 |----|RT3| 8|
+---+ +----------+ +---+ |
|3 |3 o 10.2.0.0
| | / \
+---------+ +-------+ 0/ \0
| | / \
+--+ +--+ o o
|Ma| |Ma| RT4 RT3
+--+ +--+
Figure 14: An intra-area tree
choice of either Network 10.2.0.0 or Router RT2 for RT3's parent on
the tree, Net 10.2.0.0 is again preferred since it is a network (see
Step 5c of Section 12.2)
C.2 The effect of areas
In Figure 15 below, the previous diagram has been modified by the
inclusion of OSPF areas. The datagram source is now part of the OSPF
backbone (Area 0), while the rest of the topology is in Area 1. In
this case, since the datagram source and the group members belong to
different areas, reverse costs are used when building the tree (see
Step 5b of Section 12.2). This actually eliminates the equal cost
paths from the diagram, and leads to the Area 1 datagram shortest-
path tree on the right of Figure 15.
+--+
|H1|
+--+
Net 192.9.1.0 |
+------------------+
..................... | |
. +----------+ . |1 |1 192.9.1.0
. | Network | 8+---+ +---+ o
. | 10.1.0.0 |------|RT1|........|RT2|... / \
. +----------+ +---+ +---+ . 1/ \1
. | |8 8| . / \
. 8| +----------+ |8 . o RT1 o RT2
. +---+10 | Network | 10+---+ . | \
. |RT4|-------| 10.2.0.0 |----|RT3| . 0| \8
. +---+ +----------+ +---+ . | \
. |3 |3 . o 10.1.0.0 o
. | | . | RT3
. +---------+ +-------+. 8|
. | | . |
. +--+ +--+ . o
. |Ma| |Ma| . RT4
. +--+ Area 1 +--+ .
.........................................
Figure 15: The effect of areas
C.3 The effect of virtual links
In Figure 16 below, Network 10.1.0.0 has been configured as a
separate area (Area 1), while everything else belongs to the OSPF
backbone (Area 0). In addition, a virtual link has been configured
through Area 1, enhancing the backbone connectivity. In this case,
both the source and the group members belong to the same area, so
forward costs are used. However, since virtual links are preferred
over regular links (see Step 5c of Section 12.2), the backbone
datagram shortest-path tree uses Network 10.1.0.0 instead of
10.2.0.0 on the path to the left group member. This leads to the
tree on the right of Figure 16.
+--+
|H1|
+--+
Net 192.9.1.0 |
................ +------------------+
. +----------+ . /1 |
. | Network |8. / |1
. | 10.1.0.0 |-+---+ +---+ o 192.9.1.0
. +----------+*|RT1| |RT2| |
. 8|*******+---+ +---+ 0|
.Area1 |*VL . \8 8| |
.....+---+...... +----------+ |8 o RT1
|RT4|10 | Network | 10+---+ / \
+---+-------| 10.2.0.0 |----|RT3| /8 \8
| +----------+ +---+ / \
|3 |3 o 10.1 o 10.2.0.0
| | | |
+---------+ +-------+ |0 |0
| | | |
+--+ +--+ o o
|Ma| |Ma| RT4 RT3
+--+ +--+
Figure 16: The effect of virtual links
Security Considerations
Security issues are not discussed in this memo.
Author's Address
John Moy
Proteon, Inc.
9 Technology Drive
Westborough, MA 01581
Phone: (508) 898-2800
Email: jmoy@proteon.com