home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
mospf
/
mospf-minutes-91nov.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
10KB
|
259 lines
CURRENT_MEETING_REPORT_
Reported by Scott Brim/Cornell University
Minutes of the Multicast Extensions to OSPF Working Group (MOSPF)
1. Agenda
o Roster, Intros, Notetaker
o Reports on Related Activities
- X3S3.3?
- BGP?
- Router Requirements?
o Review of Latest MOSPF Draft
- Scott's Comments
- Forwarding Algorithm
- Extent of Reverse Paths
- Inter-AS Interactions
- ``Host'' Behavior of MOSPF Routers
o Token Ring Address Mapping
o Multicast Scope Proposal
o Implementation Status
o Future Work
- MIB
- Standards Track
- Field Tests / Interoperability Tests
2. Reports on Related Activities
X3S3.3: Recently started work on ``advanced services,'' including
multicast. Steve Deering addressed them on multicasting model and
MOSPF. Dave Marlowe has draft extension to CLNS for join & leave
group, proposal for NSAP assignment; other stuff. Nobody knows
what happened at the last meeting in Boston.
BGP: Internet Draft issued on alternative approaches. Only one
person signed up to implement (Scott Brim) and he's not going to do
it until after he finishes MOSPF. Not this year.
Router Requirements: Multicast will not be in the forwarding MIB
because ??? it uses source address and nothing else in there does
right now. They're going to wait. Someone is going to have to
write a multicast routing MIB in addition to the different MC
protocol MIBs. John Moy contributed a section on multicasting
router requirements which will have to be revised, and soon.
3. Review of Latest MOSPF Draft
3.1. Discussion of Scott Brim's Previously Emailed Comments
How do you tell what the previous hop of a packet was? You can't
1
without looking at the previous hop's link-level address. The
issue is that on a border network you need to determine whether a
packet you receive was being multicast *through* your autonomous
system or just *getting* to your autonomous system? (See figure in
draft.) That's why we came up with datalink unicasting. It looks
like this area of interactions between OSPF and RPF protocols isn't
finished. Datalink unicasting is a start, but doesn't cover
everything. We're going to have to study this one more. Do we
have to encapsulate when crossing an AS boundary? Right now the
BGP model is straight RPF, and RPF has no idea what an AS boundary
is.
Perhaps if there's a host sitting on the border LAN, then you only
accept unicasts *unless* the packet originates on that LAN.
Datalink unicasting is for transits, not for locally-originated
traffic. What if someone is *sending* to a group that host belongs
to?
In BGP, only one AS announces the shared net. Should we combine
the flags that say you shouldn't listen to multicasts with the one
that says to do datalink unicasts?
One definite conclusion is that you shouldn't base *forwarding* on
whether something came from another AS. In *building* the FIB
that's important, but should not be used after that.
Caching negative results is already in the document.
What if a vertex is not labelled? Yes, document needs a statement
saying go to the next section.
Yes, there should be justifications for why we did *not* do things
in some way.
3.2. Forwarding Algorithm
Moy: Spell out preprocessing. When called (directly from IP
forwarding), first check:
o If 224.0.0.1 to 224.0.0.255, never forwarded, only sent to
internal applications.
o If IGMP message, send to IGMP process, don't forward.
o Then follow rest of section.
Internally generated multicast packets must be handled differently
-- in John's design at least. This is *not* true in Steve's
design, and we spent a significant amount of time comparing them.
Steve: host specification (RFC 1112) says group membership is
associated with an interface. Forwarding sends to a set of
outgoing interfaces. As *part* of forwarding to an interface, in
the per interface code, if this host is a member of the destination
group *on that interface*, this host receives a copy, not by
interface loopback but in memory. An application which joins on
2
multiple interfaces receives multiple copies. Also, if this host
*sends* a packet, if this is a forwarder, the packet is looped back
in the interface handler for the interface the packet is being sent
on, and given to the forwarder which forwards it as necessary as if
it *came* from that interface. A multicast packet, when it hits
the forwarder, is always associated with an interface. The
forwarding function is thus relatively pure.
John says if you're only doing MOSPF, membership can be associated
with the router, not with a particular interface, so local delivery
is hung off the packet forwarder. If originated locally, a packet
goes directly to the forwarding process, which knows which
interface you want to forward it out of, and decides whether to
deliver it locally. If an interface goes down, with the Deering
scheme, then the application has to rejoin on another interface or
it doesn't receive any traffic. Steve's model is necessary for a
multihomed host; John's is possible on an MOSPF router because of
its complete knowledge of the topology. However, the programmer's
interface shouldn't change depending on whether MOSPF is running or
not, so maybe you should still do it with interfaces.
The time to join on more than one interface is, for example, when
you are doing an expanding ring search, and you want to get a hit
on any interface. Also, Steve's model gives you the possibility of
making sure you only receive a packet for a particular group on
*one* *particular* interface. John's model has the *router* being
a member, on *any* interface, so the router as a whole gets a copy
of a packet. Steve was forced into his approach to make multihomed
hosts work. If we allow both models, then yes, the environment
does change for applications -- applications can't receive multiple
copies with John's approach. An artifact of Steve's approach is
that the packet goes out on the intended interface with the
intended TTL, and goes out on other interfaces (if it needs
forwarding immediately) with the TTL one less. Steve's gut
reaction is that applications won't care if they don't get multiple
copies, but he doesn't know for sure. John *can* emulate all of
Steve's behavior, delivering duplicate packets -- but would it be
better if he didn't.
3.3. Extent of Reverse Paths
Within the area where the source is you still use forward costs.
Everywhere else you use all reverse costs. If you don't use *all*
links in the *reverse* direction, you get pockets of non-delivery
of datagrams. The problem occurs when you have asymmetric
reachability or costs on links within a receiving area. Steve
thinks this is a problem due to the way John stores his information
and due to his decision that a multicast routing table entry is
simply a pointer to a unicast entry and a group address. Steve
thinks the information for using forward costs is there, but not
used. This discussion was not really concluded.
3.4. Inter-AS Interactions
3
Covered already in the section on ``Scott's comments''.
3.5. ``Host'' Behavior of MOSPF Routers
Covered already in the section on ``Forwarding algorithm''.
4. Token Ring Address Mapping
A functional address for carrying IP multicasts on token ring has
not yet been obtained. Steve could write a one-page RFC on how to
use it if he only had the address. Coltun will follow up on it.
5. Multicast Scope Proposal
Steve's proposal reviewed. (1) local wire, already allocated as
224.0.0.1,255; (2) site-wide -- start allocating from the bottom up
at 224.0.1.0; (3) global, allocated from 249.255.255.255 downward.
Thus we can decide about the middle later. This would require the
number czar to ask multicast group requestors just what they are
going to be used for and make an intelligent allocation based on
what they say -- this might not be acceptable.
6. Implementation Status
Not covered.
7. Future Work
7.1. MIB
No volunteers came forward.
7.2. Standards Track
Not covered.
7.3. Field Tests / Interoperability Tests
Not covered, except to say that we should try to line up some test
beds.
Attendees
Nagaraj Arunkumar nak@3com.com
William Babson bill%penril@uunet.UU.NET
Atul Bansal bansal@wile.nac.dec.com
James Beers beers@nr-tech.cit.cornell.edu
Scott Brim swb@nr-tech.cit.cornell.edu
4
Yee-Hsiang Chang yhc@concert.net
Dean Cheng dean@sunz.retix.com
Rob Coltun rcoltun@ni.umd.edu
Steve Deering deering@xerox.com
Kurt Dobbins dobbins@ctron.com
Dino Farinacci dino@cisco.com
Karen Frisa karen.frisa@andrew.cmu.edu
Jim Ghadbane jimgh@newbridge.com
Christine Hemrick hemrick@cisco.com
Ronald Jacoby rj@sgi.com
Jean-Michael Jouanigot jimi@cernvax.cern.ch
Stev Knowles stev@ftp.com
Mark Lewis mlewis@telebit.com
April Merrill abmerri@tycho.ncsc.mil
Greg Minshall minshall@wc.novell.com
Dave Monachello dave@pluto.dss.com
Dean Morris morris@marvin.dec.com
John Moy jmoy@proteon.com
Andy Nicholson droid@cray.com
Stephen Shew sdshew@bnr.ca
Ravi Srinivasan ravi@eng.vitalink.com
Michael St. Johns stjohns@umd5.umd.edu
William Townsend townsend@xylogics.com
Scott Wasson sgw@sgw.xyplex.com
L. Michele Wright uncng!michele@uunet.uu.net
5