home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
mospf
/
mospf-minutes-90feb.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
9KB
|
210 lines
CURRENT_MEETING_REPORT_
February 6, 1990 Held at Tallahassee IETF meeting Chaired in Steve's
absence by J. Moy/Proteon Minutes also written by J. Moy
MINUTES
This was the initial meeting of the MOSPF working group. John Moy
presented a number of slides to introduce the subject of multicast
routing . The slides also attempted to discuss the main areas where the
OSPF protocol needs to be changed/extended in order to provide multicast
support.
The slide discussion was broken up into the following areas:
o o There was a short introduction into IP multicasting, including
the Internet Group Management Protocol (IGMP, RFC 1112). IGMP is
responsible for maintaining host group membership. Multicast
routers must support IGMP (although in multicast OSPF only the
Designated router will be actively sending/receiving IGMP
messages). Through using IGMP, a multicast router knows which
multicast destinations are active on its attached LANs, but does
not need to keep track of which particular hosts are requesting
them (this is a considerable savings).
o o A brief (and very incomplete) survey of multicast routing was
attempted. This was done through examination of Steve Deering's
"Multicast routing in Internetworks and Extended LANs" paper. This
paper discusses a number of multicast routing methodologies: an
extension to the learning bridges to better support multicast, four
separate Bellman-Ford multicast routing algorithms (arranged in
order of increasing functionality and complexity) and a link-state
multicast algorithm. Finally, a mix of these approaches is
explored for internet-wide multicast (and the wild-card multicast
group is introduced).
The most functional Bellman-Ford multicast algorithm in Steve's
paper has been implemnted for BSD UNIX and is documented in RFC
1075.
It is expected that the multicast OSPF extensions will closely
follow the link-state multicast algorithm in Steve's paper.
o o The basic mechanism behind link-state multicasting was explored.
A shortest-path tree is built having as root the multicast
datagram's source. Those branches not containing the specified
multicast destination are then pruned. This tree then yields the
multicast datagram's path.
At each hop, the multicast datagram is sent as a link-level
multicast (or broadcast). For this reason, multicast routers
receive all multicast packets (i.e., must open up their multicast
filters).
The above trees are built on demand, and the results are cached
(see below).
1
o o Cache entries are used to store the results of the above SPF
calculation. For each tree built (there is potentially a different
tree for each [source net, multicast destination] pair), a cache
entry is formed. The cache entry specifies the interface expected
to receive the datagram, and the set of interfaces that the
datagram should be forwarded out.
Note that this proposed cache structure is slightly different than
the one in Steve's paper. First, it skips caching whole subtrees
(implementation experience with OSPF shows that subtree caching is
a lot of work), and it simplifies things by ignoring TTL.
A separate tree (and a separate cache entry) will also possibly be
calculated for each TOS value. The entire cache must be cleared on
topology changes. When a group's membership changes, only cache
entries pertaining to that destination need be flushed.
o o The changes and additions to the OSPF protocol are expected to be
slight. This is because OSPF already maintains a complete
topological map of the routing domain, enabling the multicast tree
calculation. The expected changes to OSPF include the following:
1) During the Dijkstra calculation, routing table entries (e.g.,
for net X) will be marked with their corresponding "transit node".
This node will be the root for multicast tree calculations having
net X as datagram source.
o o Expected additions to OSPF include the following: 1) OSPF
Designated Routers (DRs) will need to speak IGMP. 2) There will be
a new link state advertisement (type 6) that routers will originate
when there are multicast destinations on attached LANs. There will
be separate advertisements for each multicast destination. These
advertisements will be originated by DRs only. This additional
link state information will enable tree pruning. 3) There will
probably be a new bit in the router links advertisement indicating
"multicast-capable". This allows some routers in the AS to decline
multicast support. 4) The multicast tree calculation must be made
deterministic; i.e., all routers must calculate the same tree in
the presence of multiple equal-cost routes.
o o Inter-area multicast will be a little more complicated. This is
because when the datagram source is in another area, the local
topology surrounding the source is hidden, inhibiting the multicast
tree calculation. In this case, we propose forming a tree for each
of the other areas. Each tree can be thought of as still being
rooted at the datagram source; there will be a link from the
datagram's source to each of the area's border routers. The cost
of these links will be that advertised by the area border routers
in their summary link advertisements (note reverse direction). The
rest of the tree will (as in the intra-area case) deals only with
the area's own topology.
datagram source
:
----------------
: : : :
: : : :
ABR ABR ABR ABR
| | |
2
-------
|
A multicast datagram enters the area through the border border
routers. The above scheme works only if area border routers are
"wild-card" multicast receivers (i.e., receive all muticast
packets).
The logic for when the source of the datagram is exterior to the AS
should be similar to the inter-area case.
The following questions were raised by the slides. Bob Hinden asked
whether there were any estimates for the CPU usage consumed by the
potentially large number of tree calculations. In a related question,
Chuck Davin wondered about the expected distribution of host group
memberships (e.g., number per LAN and lifetime). These questions were
put off, hopefully for Steve Deering to answer.
Scott Brim questioned the behavior of the above inter-area multicasting
scheme in the presence of asymmetric paths. He thought that there might
be the possibility of packet looping. This issue should be looked into
further.
Besides the above, the following issues were brought up:
o Should the multicast specification be written as a separate
document, or should it simply depend on RFC 1131 (the OSPF
specification)?
o If we do not require all of the routers to be multicast-capable, is
the possibility of reduced functionality acceptable?
o How much backward compatibility should there be with the present
OSPF protocol?
o Should we try to be more efficient in inter-area multicasting, and
drop the requirement that border routers be wild-card multicast
receivers?
FUTURE MEETINGS
We intend to begin writing the specification for OSPF multicast
extensions. This will be done primarily through communications on the
mospf mailing list (mospf@devvax.tn.cornell.edu).
There will be a MOSPF WG meeting at the next IETF (Pittsburgh). Also,
if enough progress is made between meeting, we will attempt to schedule
the teleconferencing facilities.
ATTENDEES
John Cavanaugh johncavanaugh@stpaul.ncr.com
3
Rob Coltun rcoltun@umds.umd.edu
Samir K. Chatterjee samir@nynexst.com
George Clapp meritec!clapp@bellcore.bellcore.com
Daniel Kellen kellen@odixie.enet.dec.com
Stan Froyd sfroyd@salt.acc.com
James R. Davin jrd@ptt.lcs.mit.edu
Douglas Bagnall bagnall-d@apollo.hp.com
Metin Feridun mferidun@bbn.com
Tom Easterday tom@nisca.ircc.ohio-state.edu
Ballard Bare bare%hprnd@hplabs.hp.com
Cathy Aronson cja@merit.edu
Bob Hinden hinden@bbn.com
Frank Solensky solensky@interlna.com
Dave Miller dtm@mitre.org
Tim Seaver tas@mcnc.org
Joel Replogle replogel@ncsa.uiuc.edu
Tony Mason mason@transarc.com
Farokh Deboo fjd@interlink.com
Dino Farinacci dino@bridge2.3com.com
Jeffrey Burgan jeff@nsipo.nasa.gov
Dave O'Leary oleary@noc.sura.net
4