home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / SIP / 93JUL.MIN < prev    next >
Encoding:
Text File  |  1993-09-16  |  18.2 KB  |  513 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Robert Hinden/Sun Microsystems
  5.  
  6. Minutes of the Simple Internet Protocol Working Group (SIP)
  7.  
  8. These minutes are based on notes taken by Christian Huitema.
  9.  
  10. The SIP Working Group held two sessions and a demonstration at the
  11. Amsterdam IETF. The first session was 12 July at 4:00 p.m.  The second
  12. session was 15 July at 1:30 p.m.  Both sessions were audio/video
  13. multicast on the Internet.  The demonstration was held on 14, 15, and
  14. 16 July.
  15.  
  16.  
  17. Agenda
  18.  
  19.    o Administrivia
  20.    o Review of Action Items
  21.    o Implementation Status Reports
  22.    o Demonstration Plans
  23.    o SIP Source Routing
  24.    o Review of Recent Work
  25.    o Assign Action Items
  26.  
  27.  
  28. Administrivia
  29.  
  30. Bob Hinden introduced the agenda.  Ross Callon mentioned his desire to
  31. add transition plans as a discussion item.  The item was added, but due
  32. to a lack of time in the second session, was not discussed.
  33.  
  34.  
  35. Review of Action Items
  36.  
  37.  
  38. ACTION: Everyone read Auto-Configuration proposal and reply to list and
  39.         put on agenda for next meeting.
  40.  
  41.     Closed.
  42.  
  43. ACTION: Simpson and Deering resolve differences and come up with one
  44.         addressing allocation/assignment scheme.
  45.  
  46.     In progress.   Open.
  47.  
  48. ACTION: Crocker define and plan Amsterdam demo.
  49.  
  50.     Crocker declined action.  Hinden assumed action.  Closed.
  51.  
  52. ACTION: Hinden/Deering agenda for Amsterdam meeting.
  53.  
  54.     Closed.
  55.  
  56. ACTION: Deering to send message to list outlining IPv4 ID generation
  57.         choices and propose a solution.
  58.  
  59.     Open.
  60.  
  61. ACTION:  Gilligan/Mulligan to define and write up.
  62.  
  63.     Closed.
  64.  
  65. ACTION: Hinden to send Erik F. a message stating that the
  66.         w.g. will develop a formal response.
  67.  
  68.     Done at meeting.  Closed.
  69.  
  70. ACTION: Gilligan to post his auto configuration proposal to list.
  71.  
  72.     Done.
  73.  
  74. ACTION: Jim Bound to coordinate a w..g reply.
  75.  
  76.     In progress.  Open.
  77.  
  78. ACTION: Deering to contact other IPng chairs about coordinating IESG
  79.         submissions.
  80.  
  81.     OBE.  Internet ADs held lunch meeting with IPng chairs.  Closed.
  82.  
  83. ACTION: Gilligan to revise and reissue BSD API for SIP document.
  84.  
  85.     Submitted as ID.  Closed.
  86.  
  87. ACTION: Deering to work on separate Flow ID document.
  88.  
  89.     No progress.  Open.
  90.  
  91. ACTION: Deering to talk to Ran Atkinson about status of SIP security
  92.         proposal.
  93.  
  94.     Open.
  95.  
  96. ACTION: Christian Huitema: To post as an Internet Draft of DNS changes
  97.         for SIP (if not already posted).
  98.  
  99.     Done.  Closed.
  100.  
  101. ACTION: Simpson to get status of IDRP work and report to list.
  102.  
  103.     OBE.  Sue Hares reported on IDPR status at working group session.
  104.     Closed.
  105.  
  106. ACTION: Deering/Hinden to ask John Moy to do revision of OSPF for SIP
  107.         document.
  108.  
  109.     John Moy (w/ Rob Coltun's assistance) agreed to do a version of OSPF
  110.     for SIP.  Closed.
  111.  
  112. ACTION: Deering to write ICMP for SIP document.
  113.  
  114.     Not done.  Open.
  115.  
  116. ACTION: Deering will also include IGMP changes to ICMP document.
  117.  
  118.     Open.
  119.  
  120. ACTION: Christian Huitema: Will produce a new version of SIP for RIP
  121.         document or get Gary Malkin to do it.
  122.  
  123.     Done.  Closed.
  124.  
  125. ACTION: Deering to look at SIP RIP to make sure it includes multicast
  126.         support.
  127.  
  128.     Done.  Closed.
  129.  
  130. ACTION: Deering to get first version of SIP addressing document out
  131.         before Amsterdam IETF.
  132.  
  133.     In progress.  Open.
  134.  
  135. ACTION: Deering to send SIP list contents to Hinden.
  136.  
  137.     Done.  Closed.  New ACTION: Hinden to set up SIP list at Sun.
  138.  
  139. ACTION: Hinden to revise charter and submit to Internet AD's.
  140.  
  141.     Draft written.  Open.
  142.  
  143. ACTION: Gilligan post a message to SIP list asking for volunteers to
  144.         deploy and test Sun border router implementation.
  145.  
  146.     Done.  Closed.
  147.  
  148. ACTION: Mulligan send KA9Q code to Simpson.
  149.  
  150.     Done.  Closed.
  151.  
  152. ACTION: Deering to update SIP specification.  Small amount of changes.
  153.  
  154.     Not done.  Closed.
  155.  
  156. ACTION: Gilligan/Nordmark to provide updates to IPAE Specification by
  157.         June 18.
  158.  
  159.     OBE.  Closed.
  160.  
  161. ACTION: Crocker to do revision of IPAE specification by June 25.
  162.  
  163.     OBE.  Closed.
  164.  
  165. ACTION: Hinden to update and submit criteria as Informational RFC.
  166.  
  167.     Not done.  Open.
  168.  
  169. ACTION: Crocker to ask Marshall Rose to develop SIP MIBs.
  170.  
  171.     Not done.  Open.
  172.  
  173.  
  174.  
  175. Implementation Status Reports
  176.  
  177. o Public Domain BSD
  178.  
  179. A presentation was given by Werner Vogel.  Three BSD implementations
  180. have been done:  Initial INRIA, full 64 bits, x-kernel.  The target of
  181. INESC is BSD, specifically Mach and x-kernel.
  182.  
  183. Werner presented the architecture of the INRIA implementation:
  184.  
  185.  
  186.    o SIP processor in the kernel
  187.    o Interface configuration and route set up
  188.    o 64-bit ping
  189.    o 32-bit TCP and UDP without fragmentation
  190.  
  191.  
  192. Other features are implemented but not yet tested.
  193.  
  194. Performance of the loop-back interface is faster than straight IP.
  195. Performance over Ethernet is equivalent to IP (same figure).  NFS (block
  196. of 1K) and AFS work over SIP.
  197.  
  198. Next steps:  more debugging, real 64-bit TCP, transport level support,
  199. integration of routing, use real interfaces, checksums, etc.
  200.  
  201.  
  202. o Sun Solaris Implementation
  203.  
  204. Erik Nordmark gave the presentation.  Sun included the ``border router''
  205. code.  SIP Multicast is implemented.  VAT and NV work over SIP using
  206. multicast address translation.  They are working on getting
  207. ``traceroute'' to work over the encapsulation, and avoiding the ``lost
  208. ICMP'' problem.
  209.  
  210. For solving the lost ICMP problem, the SIP process has to keep track of
  211. the tunnel's MTU, and also of the ``unreachable'' status of tunnels.
  212. The TTL exceeded problem is harder to solve.  This can be delegated to
  213. the routing process for ``inter-router'' tunnels, but cannot easily be
  214. used for ``tail'' tunnels.  Tony Li mentioned that SDR is using ``tunnel
  215. IDs'' (64-bit encapsulation header) in order to solve this problem.  He
  216. suggested we look at the SDR IDs.
  217.  
  218.  
  219. o SIP IDRP Status
  220.  
  221. Sue Hares described the status of IDRP for SIP. She said that IDRP is
  222. part of ``gated'' which is already multiprotocol.  She needs a SunOS 4.1
  223. implementation (INRIA/INESC) to test the relaying of the packets over
  224. SIP, and for installing SIP routes.  She believes the code is modular
  225. enough to install routes without problems.  Yakov Rekhter mentioned the
  226. possibility of having extra attributes, for automatically installing
  227. tunnels.  Sue also mentioned extensions for multicast, for example,
  228. using the next hop information for memorizing the ``broadcast tree''
  229. from a given source.  A base level support could be ready for test
  230. within a month given a kernel.  The link between IDRP and IGPs other
  231. than IS-IS is neither done nor funded.  She suggested finding volunteers
  232. within the working group.  Code is public domain and can now be provided
  233. to ``co-developers.''
  234.  
  235. She also mentioned that the ISO IDRP specification will soon be
  236. published as an Informational RFC.
  237.  
  238.  
  239. Demonstration Plans
  240.  
  241. Bob Gilligan presented the IETF demonstration set up.  There were 6
  242. sites participating:
  243.  
  244.  
  245.    o IETF at Amsterdam
  246.    o Xerox PARC
  247.    o TGV
  248.    o Sun
  249.    o Intercon Macintosh
  250.    o Beame & Whiteside (PC with DOS)
  251.  
  252.  
  253. The first 4 sites run a SIP border router; at PARC and TGV, an IP host
  254. points to the SIP border router.  In the last two sites, PCs and
  255. Macintoshes are isolated SIP hosts, connected to the routers in their
  256. domain space.  Metro addressing is used.  Werner volunteered the
  257. addition of a BSD SIP host in Portugal to the demonstration.
  258.  
  259. The demonstration featured Telnet, FTP, Ping, Traceroute, and VAT. FTP
  260. ``third party'' connections are limited to using the same prefix as the
  261. control connection.
  262.  
  263.  
  264. SIP Source Routing
  265.  
  266. Charlie Perkins presented the use of source routing for solving the
  267. ``mobile routing'' problem.  The classical problem is router efficiency:
  268. the forwarding of IPv4 packets with source routes was slow, which lead
  269. to the use of IP encapsulation.  Source Routing (SR) also has a bad
  270. reputation for security, though encapsulation has the same inherent
  271. problem.  SR has slightly less overhead than encapsulation (16 vs 24
  272. octets).  ICMP messages are delivered to the source with SR, and to the
  273. encapsulator with IP encapsulation.  There are also slight differences
  274. with fragmentation (reassembly at end of tunnel for encapsulation is
  275. less efficient), and MTU discovery in which tunnels are transparent.
  276.  
  277. The decision is in fact linked to ``who does what.''  The source itself
  278. should do SR, but intermediate hops should use encapsulation.
  279.  
  280. On the lesson of the mobile IP experience:  The SIP specification should
  281. be clearer about ``reversal of source routed packets.''  It is not very
  282. clear, but it appears that ``layer 4'' solutions are generally
  283. inadequate.  This design should really be studied inside the MOBILEIP
  284. Working Group.  Tony Li mentioned that it is also being addressed by the
  285. SDR Working Group.
  286.  
  287.  
  288.  
  289. Review of Recent Works
  290.  
  291.  
  292.  
  293. o SIP RIP
  294.  
  295. Gary Malkin presented comments received from Garcia Luna Aceves on SIP
  296. RIP. The loop detection algorithm is not described precisely, and needs
  297. to be corrected.  However, this is a major improvement over previous
  298. version of RIP, with the cost of more CPU. A consequence is that the
  299. maximum number of hops has been raised to 32.
  300.  
  301. Paul Francis asserted that loops are better than black holes, as you do
  302. not miss packets.  He suggested that we look at using a path vector
  303. algorithm.  Tony Li rejected the idea of accepting routing loops, as
  304. they are traffic multipliers that generate congestion; he also said that
  305. path tracing is a significant modification of the protocol.  He said
  306. that cisco found that path tracing breaks when ``route filtering'' is in
  307. operation.  He suggests that DUAL, which includes incremental updates,
  308. and guarantees loop freedom, is looked at.  Toni also mentioned that
  309. some networks are larger than 32 hops, and that we should use path
  310. metrics, but that would make the whole thing much more complex.
  311.  
  312. Tony Li then offered to provide SIP-IGRP, giving change control to the
  313. IETF for SIP-specific extensions!  After considerable discussion, the
  314. working group agreed that this should be pursued, given the usual
  315. caveats about licensing agreements and change control.
  316.  
  317. A proposal was made that SIP RIP should be limited to be used in ``small
  318. networks.''  This raises the question of how should the current SIP RIP
  319. draft be progressed.  The working group decided to continue with a basic
  320. version of SIP RIP (without the loop control) and to ask the RIPv2
  321. Working Group to take on the issue of loop control.  The current version
  322. of SIP RIP (without loop control) will be called SRIP.
  323.  
  324.  
  325. o System Discovery
  326.  
  327. Bill Simpson led the discussion on the system discovery draft.
  328.  
  329. Not a lot of implementation was done of the current version of the
  330. Router Discovery ICMP message type.  It was nice, but it lacked
  331. extensibility.  The current draft proposes a ``single block with
  332. extensions'' format:
  333.  
  334.                            ____________________
  335.                           |_SIP_+_ICMP_headers_|
  336.                           |_IFACE_____________ |
  337.                           |_MAC_______________ |
  338.                           |_Services__________ |
  339.                           |_Security_label____ |
  340.                           |_Changed_prefix____ |
  341.                           |_QOS_______________ |
  342.                           |_Authentication____ |
  343.  
  344.  
  345. This format is similar to Novell's SAP. There are two messages:
  346. solicitation and response.  The message operates similarly to the
  347. router's advertisement ICMP. ``Changed prefix'' is intended to enable
  348. dynamic address reconfiguration, which should have similar effects on
  349. TCP as on the current IP mobility solutions, i.e.  require some form of
  350. source routing to retain the existing address.
  351.  
  352. The security label is really informational.  QOS is ``claiming to be the
  353. router for a particular QOS.'' This, as the security label, is
  354. equivalent to similar fields in the OSPF and IS-IS ``hello'' packets.
  355.  
  356. The service field is used to advertise the location of particular
  357. servers, e.g.  ``DNS'' or ``bootp.''
  358.  
  359. Tony Li suggested having both a length and an AFI for the ``iface''
  360. parameter.  He also suggested making both ``MAC'' and ``service''
  361. optional.  Greg Minshall suggest MAC should, on the contrary, be present
  362. all the time in order to facilitate parsing.  Greg also suggested that
  363. the experience acquired by Novell suggests that ``service'' is not a
  364. very good idea---he would prefer to use multicast queries.  Steve
  365. Deering observes that there are more clients than servers, and that
  366. having servers advertise themselves is preferable (less traffic).  Geert
  367. Jan de Groot questioned this assertion, as the ``keep polling with
  368. backup'' is more stable and easier to diagnose (the repeated packet pops
  369. in link analyzers, etc.).  Bill Simpson mentioned that the algorithm
  370. which he described is exactly that of ``IP router discovery,'' i.e.,
  371. tested and true.
  372.  
  373. Paul Francis questioned the utility of the QOS field:  there is no such
  374. thing as a QOS per router, but rather per router/destination tuple.  The
  375. group agreed that redirection is a better solution.  Paul also suggested
  376. that a strictly router-to-host protocol is much simpler than
  377. router-to-router hellos, and that the two groups do not have the same
  378. frequency and complexity requirements.
  379.  
  380. In order to do this for mobile systems, one also needs to carry a ``list
  381. of routers heard by mobile'' in the solicitation messages send by the
  382. mobiles.  This needs to be discussed on the SIP mailing list.
  383.  
  384.  
  385. o Host Auto Configuration
  386.  
  387.  
  388. Bob Gilligan presented a set of ``preliminary ideas'' that he proposed
  389. to the mailing list on auto configuration.  He proposes to represent the
  390. address as a combination of:
  391.  
  392.  
  393.                             Prefix + Suffix
  394.  
  395.                            0              63
  396.                            ----------------
  397.                            |      |       |
  398.                            ----------------
  399.  
  400.  
  401. The suffix part is allocated by the system administrator.  The prefix is
  402. heard from the router advertisement.  At boot time, the system obtains
  403. (by various means) the ``local suffix'' (e.g.  32-bit IP address); then
  404. it obtains the ``prefix'' from the router advertisement and combines it
  405. to form a complete address.
  406.  
  407. Christian Huitema suggested that this is a very dangerous scheme as one
  408. can inadvertently boot the system in a new environment where the suffix
  409. is not unique.  Bill Simpson suggested using a combination of IEEE 802
  410. and directory names.
  411.  
  412. Paul Francis suggested the use of a two hop source route:  the IEEE 802
  413. unique SIP address of the host, and the router address obtained from the
  414. advertisement.
  415.  
  416.  
  417. Conclusion and Assignment of Action Items
  418.  
  419. Steve Deering mentioned the need for more implementations, and also the
  420. need to start deployment.  Members were encouraged to go see the
  421. demonstration in the terminal room, with border routers, VAT over SIP,
  422. Internet Talk Radio acquired over SIP, etc.
  423.  
  424.  
  425. Attendees
  426.  
  427. Kannan Alagappan         kannan@DSMAIL.ENET.DEC.COM
  428. Steve Alexander          stevea@lachman.com
  429. James Allard             jallard@microsoft.com
  430. Frederik Andersen        fha@dde.dk
  431. Michael Anello           mike@xlnt.com
  432. Anders Baardsgaad        anders@cc.uit.no
  433. Dennis Baker             dbaker@wellfleet.com
  434. John Ballard             jballard@microsoft.com
  435. Nutan Behki              Nutan_Behki@qmail.newbridge.com
  436. Per Bilse                bilse@ic.dk
  437. Jim Binkley              jrb@ibeam.intel.com
  438. David Borman             dab@cray.com
  439. Jim Bound                bound@zk3.dec.com
  440. Robert Braden            braden@isi.edu
  441. Ronald Broersma          ron@nosc.mil
  442. Suzy Brown               suzy_brown@genmagic.com
  443. John Burnett             jlb@adaptive.com
  444. Ross Callon              rcallon@wellfleet.com
  445. Peter Cameron            cameron@xylint.co.uk
  446. Henry Clark              henryc@oar.net
  447. Dave Cullerot            cullerot@ctron.com
  448. Walid Dabbous            Walid.Dabbous@sophia.inria.fr
  449. James Davin              davin@thumper.bellcore.com
  450. Geert Jan de Groot       geertj@ica.philips.nl
  451. Stephen Deering          deering@parc.xerox.com
  452. Tim Dixon                dixon@rare.nl
  453. Kurt Dobbins             dobbins@ctron.com
  454. Pierre Dupont            dupont@mdd.comm.mot.com
  455. Kjeld Borch Egevang      kbe@craycom.dk
  456. Ed Ellesson              ellesson@vnet.ibm.com
  457. Mark Fedor               fedor@psi.com
  458. Eric Fleischman          ericf@act.boeing.com
  459. Paul Francis             Francis@thumper.bellcore.com
  460. Shoji Fukutomi           fuku@furukawa.co.jp
  461. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  462. Joseph Godsil            jgodsil@ncsa.uiuc.edu
  463. Ramesh Govindan          rxg@thumper.bellcore.com
  464. Marcel Graf              graf%dhdibm1.bitnet@vm.gmd.de
  465. Terry Gray               gray@cac.washington.edu
  466. Chris Gunner             gunner@dsmail.lkg.dec.com
  467. Robert Hinden            hinden@eng.sun.com
  468. Frank Hoffmann           hoffmann@dhdibm1.bitnet
  469. Gerd Holzhauer           Holzhauer1@applelink.apple.com
  470. John Hopkins             J_Hopkins@icrf.icnet.uk
  471. Christian Huitema        Christian.Huitema@sophia.inria.fr
  472. Ronald Jacoby            rj@sgi.com
  473. David Johnson            dbj@cs.cmu.edu
  474. Marijke Kaat             marijke@sara.nl
  475. Tomaz Kalin              kalin@rare.nl
  476. Neil Katin               katin@eng.sun.com
  477. Ton Koelman              koelman@stc.nato.int
  478. John Larson              jlarson@parc.xerox.com
  479. Tony Li                  tli@cisco.com
  480. Marjo Mercado            marjo@cup.hp.com
  481. Donald Merritt           don@arl.army.mil
  482. Greg Minshall            minshall@wc.novell.com
  483. Keith Mitchell           keith@pipex.net
  484. Daniel Myers             dan@nsd.3com.com
  485. Erik Nordmark            nordmark@eng.sun.com
  486. Masataka Ohta            mohta@cc.titech.ac.jp
  487. Zbigniew Opalka          zopalka@agile.com
  488. Jorg Ott                 jo@cs.tu-berlin.de
  489. Christian Panigl         christian.panigl@cc.univie.ac.at
  490. Charles Perkins          perk@watson.ibm.com
  491. David Piscitello         dave@mail.bellcore.com
  492. Aiko Pras                pras@cs.utwente.nl
  493. James Reeves             jreeves@synoptics.com
  494. Alex Reijnierse          a.a.reijnierse@research.ptt.nl
  495. Yakov Rekhter            yakov@watson.ibm.com
  496. Dan Romascanu            dan@lannet.com
  497. Marjo Rottschaefer
  498. Henry Sanders            henrysa@microsoft.com
  499. Kitty Shih               kmshih@novell.com
  500. William Simpson          Bill.Simpson@um.cc.umich.edu
  501. John Stewart             jstewart@cnri.reston.va.us
  502. Fumio Teraoka            tera@csl.sony.co.jp
  503. Richard Thomas           rjthomas@bnr.ca
  504. Susan Thomson            set@bellcore.com
  505. Thierry Turletti         turletti@sophia.inria.fr
  506. Hisao Uose               uose@tnlab.ntt.jp
  507. Willem van der Scheun    scheun@sara.nl
  508. Werner Vogels            werner@inesc.pt
  509. Wilfried Woeber          Wilfried.Woeber@CC.UniVie.ac.at
  510. Jessica Yu               jyy@merit.edu
  511. Romeo Zwart              romeo@sara.nl
  512.  
  513.