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