CURRENT_MEETING_REPORT_ Reported by Rob Coltun/Consultant Minutes of the Virtual Circuit Routing BOF (VCROUT) The Group's first session began with a discussion of the VC Routing Architecture Draft and ended somewhere on planet ATM-Forum-Flashback. Several interesting issues were raised here. Radia Perlman suggested that the routing protocol should be scalable to any level of hierarchy so that a prefix address advertised by a switch may represent directly connected terminals or an aggregation address of a directly connected sub-network. Juha Heinanen was concerned that a 32 bit address is not sufficient. It is big enough to identify the exchange portion of a North American Numbering Plan address, should be big enough for the routable portion of other E.164 addresses, and is big enough for the routable part of a GOSIP-style NSAP (Rd/Area). However, it was pointed out that the GOSIP-style NSAP format may be used in a more efficient manner than suggested in RFC1237 (i.e., the Rsvd field may have significance and the RD/Area separation may not be clear cut). This makes a 32 bit address useless. Dan had a strong objection to using the transit carrier ID for call setup in VC networks. Fore's SPANS Next, Drew from Fore systems presented an overview of Fore's SPANS (Simple Protocol for ATM Network Signaling) protocol. The presentation included Fore's internal addressing, UNI, NNI, QoS, SPF routing algorithm, multicast solution and connectionless server. Goals of Proposed Working Group The second session started with a discussion of the goals and milestones of the proposed VCROUT Working Group. The following goals were agreed to: o The Working Group will initially focus on protocols for use within a single VC network (intra-domain routing). Routing for a VC internet (inter-domain routing) is also within the Charter. o Initial specifications to focus on what each switch needs to monitor to describe its local topology (including neighbor interactions), and the protocol for distributing/updating topology information should be in Internet-Draft form by the end of June and submitted as a Proposed Standard by the end of '93. 1 o Interaction between the the CAC and the routing information should be worked out, such that by June, a description of how it would work, with a list of requirements needed from the UNI signaling and NNI signaling detailed for liaison with the ATM Forum. Any modifications should have worked out trade-offs described. o As part of the interaction between the the CAC and routing, ways of describing the performance expected by a switch rather than the algorithm used by the switch should be explored. VC-Routing Proposal We then had a brief overview of the vc-routing proposal, focusing on routing metrics and how they may be used by signaling. Marek suggested that for high-speed networking, the minimum propagation delay between switches is related to the geographic distance between the switches. Tony questioned the stability of a system that would be doing call set-up based on metrics that are in part reflecting available resources. Allison gave a presentation on congestion control implications in signaling which began with the question ``Do we really gain if routing protocol ``helps'' call admission control?'' and continued with an overview of a number of (as of yet unresolved) signaling issues regarding the terminal (hosts and routers) to switch interaction. This presentation (vcroute_mankin.txt) is available on the machine gated.cornell.edu in the pub/ospf directory. Distant-Vector Protocol There was a short discussion on the possible use of a distant-vector protocol to be used for a VC routing protocol. Yakov brought up the point that there is usually no policy routing within the IGP and that congestion avoidance and QoS requirements can be met on a hop-by-hop basis. Others countered that keeping the map at the source (i.e., using a link-state routing protocol) and doing a source route call setup was a superior technical approach. Tony suggested that a VC domain should be able to inform IDRP of reachability information. The Group agreed to meet at the Amsterdam IETF. Attendees David Arneson arneson@ctron.com Fred Baker fbaker@acc.com Jim Beers Jim.Beers@cornell.edu Nutan Behki Nutan_Behki@qmail.newbridge.com 2 Lou Berger lberger@bbn.com Caralyn Brown cbrown@wellfleet.com Jeff Carman tcarman@bnr.ca George Clapp clapp@ameris.center.il.ameritech.com Robert Cole rgc@qsun.att.com Rob Coltun rcoltun@ni.umd.edu Dave Cullerot cullerot@ctron.com Steve DeJarnett steve@ibmpa.awdpa.ibm.com Osmund DeSouza osmund.desouza@att.com Chas DiFatta chas@cmu.edu M.J. Dixon mjd@att.com Kurt Dobbins kurtdob@ctron.com Bob Downs bdowns@combinet.com Chip Elliott celliot@bbn.com Robert Enger enger@reston.ans.net Michael Fidler fidler@mitre.org Karen Frisa karen.frisa@andrew.cmu.edu Mike Goguen goguen@synoptics.com Kenneth Goodwin goodwin@a.psc.edu Daniel Grossman dan@merlin.dev.cdx.mot.com Chris Gunner gunner@dsmail.enet.dec.com Joel Halpern jmh@network.com Patrick Hanel hanel@yoyodyne.trs.ntc.nokia.com Ken Hayward Ken.Hayward@bnr.ca Juha Heinanen juha.heinanen@datanet.tele.fi Frank Hoffmann hoffmann@dhdibm1.bitnet Kathy Huber khuber@bbn.com Fong-Ching Liaw fong@eng.sun.com Andrew Malis malis_a@timeplex.com Tracy Mallory tracym@3com.com Allison Mankin mankin@cmf.nrl.navy.mil Keith McCloghrie kzm@hls.com Gerry Meyer gerry@spider.co.uk David O'Leary doleary@cisco.com Zbigniew Opalka zopalka@agile.com Ayal Opher aopher@synoptics.com John Penners jpenners@advtech.uswest.com Maryann Perez perez@cmf.nrl.navy.mil Drew Perkins ddp@fore.com Radia Perlman perlman@dsmail.enet.dec.com Hal Sandick sandick@vnet.ibm.com Shiva Sawant shiva@synoptics.com Andrew Schmidt ags@uius.edu Kanan Shah kshag@cmf.nrl.navy.mil Andrew Smith asmith@synoptics.com Marco Sosa mxs@sabre.bellcore.com Subbu Subramaniam subbu@cup.hp.com Terry Sullivan terrys@newbridge.com Sally Tarquinio sallyt@gateway.mitre.org Marek Tomaszewski marek@net.com Scott Wasson sgwasson@eng.xyplex.com James Watt james@newbridge.com Rick Wilder wilder@ans.net Steven Willis steve@wellfleet.com 3 4