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