CURRENT_MEETING_REPORT_ Reported by Robert Hinden/Sun Microsystems Minutes of the Simple Internet Protocol Working Group (SIP) These minutes are based on notes taken by Christian Huitema. The SIP Working Group held two sessions and a demonstration at the Amsterdam IETF. The first session was 12 July at 4:00 p.m. The second session was 15 July at 1:30 p.m. Both sessions were audio/video multicast on the Internet. The demonstration was held on 14, 15, and 16 July. Agenda o Administrivia o Review of Action Items o Implementation Status Reports o Demonstration Plans o SIP Source Routing o Review of Recent Work o Assign Action Items Administrivia Bob Hinden introduced the agenda. Ross Callon mentioned his desire to add transition plans as a discussion item. The item was added, but due to a lack of time in the second session, was not discussed. Review of Action Items ACTION: Everyone read Auto-Configuration proposal and reply to list and put on agenda for next meeting. Closed. ACTION: Simpson and Deering resolve differences and come up with one addressing allocation/assignment scheme. In progress. Open. ACTION: Crocker define and plan Amsterdam demo. Crocker declined action. Hinden assumed action. Closed. ACTION: Hinden/Deering agenda for Amsterdam meeting. Closed. ACTION: Deering to send message to list outlining IPv4 ID generation choices and propose a solution. Open. ACTION: Gilligan/Mulligan to define and write up. Closed. ACTION: Hinden to send Erik F. a message stating that the w.g. will develop a formal response. Done at meeting. Closed. ACTION: Gilligan to post his auto configuration proposal to list. Done. ACTION: Jim Bound to coordinate a w..g reply. In progress. Open. ACTION: Deering to contact other IPng chairs about coordinating IESG submissions. OBE. Internet ADs held lunch meeting with IPng chairs. Closed. ACTION: Gilligan to revise and reissue BSD API for SIP document. Submitted as ID. Closed. ACTION: Deering to work on separate Flow ID document. No progress. Open. ACTION: Deering to talk to Ran Atkinson about status of SIP security proposal. Open. ACTION: Christian Huitema: To post as an Internet Draft of DNS changes for SIP (if not already posted). Done. Closed. ACTION: Simpson to get status of IDRP work and report to list. OBE. Sue Hares reported on IDPR status at working group session. Closed. ACTION: Deering/Hinden to ask John Moy to do revision of OSPF for SIP document. John Moy (w/ Rob Coltun's assistance) agreed to do a version of OSPF for SIP. Closed. ACTION: Deering to write ICMP for SIP document. Not done. Open. ACTION: Deering will also include IGMP changes to ICMP document. Open. ACTION: Christian Huitema: Will produce a new version of SIP for RIP document or get Gary Malkin to do it. Done. Closed. ACTION: Deering to look at SIP RIP to make sure it includes multicast support. Done. Closed. ACTION: Deering to get first version of SIP addressing document out before Amsterdam IETF. In progress. Open. ACTION: Deering to send SIP list contents to Hinden. Done. Closed. New ACTION: Hinden to set up SIP list at Sun. ACTION: Hinden to revise charter and submit to Internet AD's. Draft written. Open. ACTION: Gilligan post a message to SIP list asking for volunteers to deploy and test Sun border router implementation. Done. Closed. ACTION: Mulligan send KA9Q code to Simpson. Done. Closed. ACTION: Deering to update SIP specification. Small amount of changes. Not done. Closed. ACTION: Gilligan/Nordmark to provide updates to IPAE Specification by June 18. OBE. Closed. ACTION: Crocker to do revision of IPAE specification by June 25. OBE. Closed. ACTION: Hinden to update and submit criteria as Informational RFC. Not done. Open. ACTION: Crocker to ask Marshall Rose to develop SIP MIBs. Not done. Open. Implementation Status Reports o Public Domain BSD A presentation was given by Werner Vogel. Three BSD implementations have been done: Initial INRIA, full 64 bits, x-kernel. The target of INESC is BSD, specifically Mach and x-kernel. Werner presented the architecture of the INRIA implementation: o SIP processor in the kernel o Interface configuration and route set up o 64-bit ping o 32-bit TCP and UDP without fragmentation Other features are implemented but not yet tested. Performance of the loop-back interface is faster than straight IP. Performance over Ethernet is equivalent to IP (same figure). NFS (block of 1K) and AFS work over SIP. Next steps: more debugging, real 64-bit TCP, transport level support, integration of routing, use real interfaces, checksums, etc. o Sun Solaris Implementation Erik Nordmark gave the presentation. Sun included the ``border router'' code. SIP Multicast is implemented. VAT and NV work over SIP using multicast address translation. They are working on getting ``traceroute'' to work over the encapsulation, and avoiding the ``lost ICMP'' problem. For solving the lost ICMP problem, the SIP process has to keep track of the tunnel's MTU, and also of the ``unreachable'' status of tunnels. The TTL exceeded problem is harder to solve. This can be delegated to the routing process for ``inter-router'' tunnels, but cannot easily be used for ``tail'' tunnels. Tony Li mentioned that SDR is using ``tunnel IDs'' (64-bit encapsulation header) in order to solve this problem. He suggested we look at the SDR IDs. o SIP IDRP Status Sue Hares described the status of IDRP for SIP. She said that IDRP is part of ``gated'' which is already multiprotocol. She needs a SunOS 4.1 implementation (INRIA/INESC) to test the relaying of the packets over SIP, and for installing SIP routes. She believes the code is modular enough to install routes without problems. Yakov Rekhter mentioned the possibility of having extra attributes, for automatically installing tunnels. Sue also mentioned extensions for multicast, for example, using the next hop information for memorizing the ``broadcast tree'' from a given source. A base level support could be ready for test within a month given a kernel. The link between IDRP and IGPs other than IS-IS is neither done nor funded. She suggested finding volunteers within the working group. Code is public domain and can now be provided to ``co-developers.'' She also mentioned that the ISO IDRP specification will soon be published as an Informational RFC. Demonstration Plans Bob Gilligan presented the IETF demonstration set up. There were 6 sites participating: o IETF at Amsterdam o Xerox PARC o TGV o Sun o Intercon Macintosh o Beame & Whiteside (PC with DOS) The first 4 sites run a SIP border router; at PARC and TGV, an IP host points to the SIP border router. In the last two sites, PCs and Macintoshes are isolated SIP hosts, connected to the routers in their domain space. Metro addressing is used. Werner volunteered the addition of a BSD SIP host in Portugal to the demonstration. The demonstration featured Telnet, FTP, Ping, Traceroute, and VAT. FTP ``third party'' connections are limited to using the same prefix as the control connection. SIP Source Routing Charlie Perkins presented the use of source routing for solving the ``mobile routing'' problem. The classical problem is router efficiency: the forwarding of IPv4 packets with source routes was slow, which lead to the use of IP encapsulation. Source Routing (SR) also has a bad reputation for security, though encapsulation has the same inherent problem. SR has slightly less overhead than encapsulation (16 vs 24 octets). ICMP messages are delivered to the source with SR, and to the encapsulator with IP encapsulation. There are also slight differences with fragmentation (reassembly at end of tunnel for encapsulation is less efficient), and MTU discovery in which tunnels are transparent. The decision is in fact linked to ``who does what.'' The source itself should do SR, but intermediate hops should use encapsulation. On the lesson of the mobile IP experience: The SIP specification should be clearer about ``reversal of source routed packets.'' It is not very clear, but it appears that ``layer 4'' solutions are generally inadequate. This design should really be studied inside the MOBILEIP Working Group. Tony Li mentioned that it is also being addressed by the SDR Working Group. Review of Recent Works o SIP RIP Gary Malkin presented comments received from Garcia Luna Aceves on SIP RIP. The loop detection algorithm is not described precisely, and needs to be corrected. However, this is a major improvement over previous version of RIP, with the cost of more CPU. A consequence is that the maximum number of hops has been raised to 32. Paul Francis asserted that loops are better than black holes, as you do not miss packets. He suggested that we look at using a path vector algorithm. Tony Li rejected the idea of accepting routing loops, as they are traffic multipliers that generate congestion; he also said that path tracing is a significant modification of the protocol. He said that cisco found that path tracing breaks when ``route filtering'' is in operation. He suggests that DUAL, which includes incremental updates, and guarantees loop freedom, is looked at. Toni also mentioned that some networks are larger than 32 hops, and that we should use path metrics, but that would make the whole thing much more complex. Tony Li then offered to provide SIP-IGRP, giving change control to the IETF for SIP-specific extensions! After considerable discussion, the working group agreed that this should be pursued, given the usual caveats about licensing agreements and change control. A proposal was made that SIP RIP should be limited to be used in ``small networks.'' This raises the question of how should the current SIP RIP draft be progressed. The working group decided to continue with a basic version of SIP RIP (without the loop control) and to ask the RIPv2 Working Group to take on the issue of loop control. The current version of SIP RIP (without loop control) will be called SRIP. o System Discovery Bill Simpson led the discussion on the system discovery draft. Not a lot of implementation was done of the current version of the Router Discovery ICMP message type. It was nice, but it lacked extensibility. The current draft proposes a ``single block with extensions'' format: ____________________ |_SIP_+_ICMP_headers_| |_IFACE_____________ | |_MAC_______________ | |_Services__________ | |_Security_label____ | |_Changed_prefix____ | |_QOS_______________ | |_Authentication____ | This format is similar to Novell's SAP. There are two messages: solicitation and response. The message operates similarly to the router's advertisement ICMP. ``Changed prefix'' is intended to enable dynamic address reconfiguration, which should have similar effects on TCP as on the current IP mobility solutions, i.e. require some form of source routing to retain the existing address. The security label is really informational. QOS is ``claiming to be the router for a particular QOS.'' This, as the security label, is equivalent to similar fields in the OSPF and IS-IS ``hello'' packets. The service field is used to advertise the location of particular servers, e.g. ``DNS'' or ``bootp.'' Tony Li suggested having both a length and an AFI for the ``iface'' parameter. He also suggested making both ``MAC'' and ``service'' optional. Greg Minshall suggest MAC should, on the contrary, be present all the time in order to facilitate parsing. Greg also suggested that the experience acquired by Novell suggests that ``service'' is not a very good idea---he would prefer to use multicast queries. Steve Deering observes that there are more clients than servers, and that having servers advertise themselves is preferable (less traffic). Geert Jan de Groot questioned this assertion, as the ``keep polling with backup'' is more stable and easier to diagnose (the repeated packet pops in link analyzers, etc.). Bill Simpson mentioned that the algorithm which he described is exactly that of ``IP router discovery,'' i.e., tested and true. Paul Francis questioned the utility of the QOS field: there is no such thing as a QOS per router, but rather per router/destination tuple. The group agreed that redirection is a better solution. Paul also suggested that a strictly router-to-host protocol is much simpler than router-to-router hellos, and that the two groups do not have the same frequency and complexity requirements. In order to do this for mobile systems, one also needs to carry a ``list of routers heard by mobile'' in the solicitation messages send by the mobiles. This needs to be discussed on the SIP mailing list. o Host Auto Configuration Bob Gilligan presented a set of ``preliminary ideas'' that he proposed to the mailing list on auto configuration. He proposes to represent the address as a combination of: Prefix + Suffix 0 63 ---------------- | | | ---------------- The suffix part is allocated by the system administrator. The prefix is heard from the router advertisement. At boot time, the system obtains (by various means) the ``local suffix'' (e.g. 32-bit IP address); then it obtains the ``prefix'' from the router advertisement and combines it to form a complete address. Christian Huitema suggested that this is a very dangerous scheme as one can inadvertently boot the system in a new environment where the suffix is not unique. Bill Simpson suggested using a combination of IEEE 802 and directory names. Paul Francis suggested the use of a two hop source route: the IEEE 802 unique SIP address of the host, and the router address obtained from the advertisement. Conclusion and Assignment of Action Items Steve Deering mentioned the need for more implementations, and also the need to start deployment. Members were encouraged to go see the demonstration in the terminal room, with border routers, VAT over SIP, Internet Talk Radio acquired over SIP, etc. Attendees Kannan Alagappan kannan@DSMAIL.ENET.DEC.COM Steve Alexander stevea@lachman.com James Allard jallard@microsoft.com Frederik Andersen fha@dde.dk Michael Anello mike@xlnt.com Anders Baardsgaad anders@cc.uit.no Dennis Baker dbaker@wellfleet.com John Ballard jballard@microsoft.com Nutan Behki Nutan_Behki@qmail.newbridge.com Per Bilse bilse@ic.dk Jim Binkley jrb@ibeam.intel.com David Borman dab@cray.com Jim Bound bound@zk3.dec.com Robert Braden braden@isi.edu Ronald Broersma ron@nosc.mil Suzy Brown suzy_brown@genmagic.com John Burnett jlb@adaptive.com Ross Callon rcallon@wellfleet.com Peter Cameron cameron@xylint.co.uk Henry Clark henryc@oar.net Dave Cullerot cullerot@ctron.com Walid Dabbous Walid.Dabbous@sophia.inria.fr James Davin davin@thumper.bellcore.com Geert Jan de Groot geertj@ica.philips.nl Stephen Deering deering@parc.xerox.com Tim Dixon dixon@rare.nl Kurt Dobbins dobbins@ctron.com Pierre Dupont dupont@mdd.comm.mot.com Kjeld Borch Egevang kbe@craycom.dk Ed Ellesson ellesson@vnet.ibm.com Mark Fedor fedor@psi.com Eric Fleischman ericf@act.boeing.com Paul Francis Francis@thumper.bellcore.com Shoji Fukutomi fuku@furukawa.co.jp Robert Gilligan Bob.Gilligan@Eng.Sun.Com Joseph Godsil jgodsil@ncsa.uiuc.edu Ramesh Govindan rxg@thumper.bellcore.com Marcel Graf graf%dhdibm1.bitnet@vm.gmd.de Terry Gray gray@cac.washington.edu Chris Gunner gunner@dsmail.lkg.dec.com Robert Hinden hinden@eng.sun.com Frank Hoffmann hoffmann@dhdibm1.bitnet Gerd Holzhauer Holzhauer1@applelink.apple.com John Hopkins J_Hopkins@icrf.icnet.uk Christian Huitema Christian.Huitema@sophia.inria.fr Ronald Jacoby rj@sgi.com David Johnson dbj@cs.cmu.edu Marijke Kaat marijke@sara.nl Tomaz Kalin kalin@rare.nl Neil Katin katin@eng.sun.com Ton Koelman koelman@stc.nato.int John Larson jlarson@parc.xerox.com Tony Li tli@cisco.com Marjo Mercado marjo@cup.hp.com Donald Merritt don@arl.army.mil Greg Minshall minshall@wc.novell.com Keith Mitchell keith@pipex.net Daniel Myers dan@nsd.3com.com Erik Nordmark nordmark@eng.sun.com Masataka Ohta mohta@cc.titech.ac.jp Zbigniew Opalka zopalka@agile.com Jorg Ott jo@cs.tu-berlin.de Christian Panigl christian.panigl@cc.univie.ac.at Charles Perkins perk@watson.ibm.com David Piscitello dave@mail.bellcore.com Aiko Pras pras@cs.utwente.nl James Reeves jreeves@synoptics.com Alex Reijnierse a.a.reijnierse@research.ptt.nl Yakov Rekhter yakov@watson.ibm.com Dan Romascanu dan@lannet.com Marjo Rottschaefer Henry Sanders henrysa@microsoft.com Kitty Shih kmshih@novell.com William Simpson Bill.Simpson@um.cc.umich.edu John Stewart jstewart@cnri.reston.va.us Fumio Teraoka tera@csl.sony.co.jp Richard Thomas rjthomas@bnr.ca Susan Thomson set@bellcore.com Thierry Turletti turletti@sophia.inria.fr Hisao Uose uose@tnlab.ntt.jp Willem van der Scheun scheun@sara.nl Werner Vogels werner@inesc.pt Wilfried Woeber Wilfried.Woeber@CC.UniVie.ac.at Jessica Yu jyy@merit.edu Romeo Zwart romeo@sara.nl