New Internet Routing and Addressing Architecture BOF (NIMROD)
Reported by J. Noel Chiappa and Isidro Castineyra/BBN
The objective of this BOF is to design NIMROD: a hierarchical,
map-based, routing architecture. NIMROD's stated purpose is to manage,
in a scalable fashion, the trade-off between the amount of information
about the network and the route quality. A rough draft architecture
document was distributed to the group's mailing list in preparation for
this meeting. The main purpose of the meeting was the review of the
draft architecture document and the preparation of the work plan for the
next meeting scheduled to take place at the next IETF.
The group met on the Tuesday and Wednesday.
On Tuesday, Isidro Castineyra presented the contents of the draft
architecture document. The presentation covered the stated objectives
of NIMROD, its main features and presented an overview of its
mechanisms. The following are among the issues raised by the attendees:
1. Mobility
The question that was raised was whether internetworks (nodes in
NIMROD parlance) are mobile. In response to this it was said that
in NIMROD nodes are mobile, but that NIMROD does not propose, at
this time, a mechanism to support mobility. The draft architecture
suggests ways in which NIMROD can support current approaches to
mobility.
2. Node expansion
In NIMROD, a node in a map can be expanded, substituting the node
for its internal map. The question was raised of when should one
look inside a node for more information. This question was added
to the open issue list.
3. What is an endpoint
The draft says that an endpoint represents a user of the network
layer---a transport layer entity. The question was if this means
that TCP/UDP are two endpoints. Chiappa answered that the an
entity that has an end-to-end connection is an endpoint. It was
noted that the concept of entity in the draft should be better
defined.
4. EIDs and ELs
The draft proposes two forms of endpoint identifier: the EID
(endpoint identifier), and the enpoint labels. The first one is a
relative short bit string, while the second one is more like a DNS
name. The question was raised whether both of these forms are
necessary. It was noted that though the ELs are necessary to
perform a distributed look-up, they should not be part of the
architecture proper. ELs can be considered a user-interface
problem.
5. Multiple EIDs per endpoint
The draft permits an endpoint to have more than one EID. The
questions was raised whether this was necessary. It was pointed
out that there is no apparent way to enforce a single EID per
endpoint.
6. Arc's attributes
The draft defines maps as consisting of arcs and nodes. The arcs
are later defined to have attributes. The question is whether it
is necessary for an arc to have attributes, as it is more common to
have the attributes residing in nodes. It was noted that both
models have the same power of representation and that the
distinction was cosmetic, but it was agreed that the next version
of the draft would try to conform to the more common
representation.
7. Connectivity specifications dynamics
Connectivity specifications describe the capabilities of a node.
The question was raised whether these specifications are
dynamic---that is, whether, for example, they indicate the current
load of an element of the network. It was pointed out that dynamic
specification might not scale. It was also pointed out that a
specification could have different parts with different degrees of
dynamism, and that each part could be distributed differently.
8. Border points
Nodes have border points to which arcs attached. The question was
raised of why are border points necessary. It was answered that
border points are used to be able to separate the internal
description of a node (its internal map) and its connection to the
outside.
9. Bidirectional arcs
The architecture uses both unidirectional and multipoint arcs. The
question was raised of why were bidirectional arcs not included.
It was pointed out that a bidirectional arc can be represented with
either unidirectional or multipoint arcs.
On Wednesday a set of issues was chosen for discussion by the group:
o Arcs and nodes: different representations
o When to look inside of a node
o Dynamics of connectivity specifications
o Work plan
The group decided to continue refining the architecture document using
the output of this meeting and discussions in the mailing list. Work on
the protocols should also start in this period.
Attendees
Edward Allen eallen@wellfleet.com
Michael Anello mike@xlnt.com
Bashir Ashrafi bashraf@chipcom.com
Ute Bormann ute@informatik.uni-bremen.de
Michael Bradley bradley@mdd.comm.mot.com
David Bridgham dab@epilogue.com
Jerry Burchfield burchfiel@bbn.com
Randy Bush randy@psg.com
Ken Carlberg Carlberg@tieo.saic.com
John Carlson johnc@cac.washington.edu
Isidro Castineyra isidro@bbn.com
Brett Chappell bchappe@relay.nswc.navy.mil
Luo-Jen Chiang ljc@lsnhbu1.lincroftnj.ncr.com
J. Noel Chiappa jnc@lcs.mit.edu
Roger Cyganer cygander@telebit.comm
Avri Doria avri@proteon.com
Havard Eidnes havard.eidnes@runit.sintef.no
Robert Elz kre@mulga.cs.mu.oz.au
Jerome Freedman jfjr@mbunix.mitre.org
Shoji Fukutomi fuku@furukawa.co.jp
Vince Fuller vaf@barrnet.net
Dragan Grebovich dragan@bnr.ca
Joel Halpern jhalpern@newbridge.com
Dimitry Haskin dhaskin@wellfleet.com
Kenneth Hays hays@scri.fsu.edu
Ian Heavens ian@spider.co.uk
Roland Hedberg Roland.Hedberg@umdac.umu.se
Jan-Olof Jemnemo Jan-Olof.Jemnemo@intg.telia.se
Bent Jensen bent@cisco.com
Frank Kastenholz kasten@ftp.com
Sean Kennedy liam@nic.near.net
Edwin King eek@atc.boeing.com
Jim Knapik knapik@mdd.comm.mot.com
John Krawczyk jkrawczy@wellfleet.com
Robert Kummerfeld bob@cs.su.oz.au
Joshua Littlefield josh@cayman.com
Peter Lothberg roll@stupi.se
Charles Lynn clynn@bbn.com
Jamshid Mahdavi mahdavi@psc.edu
Gerry Meyer gerry@spider.co.uk
Kim Morla kmorla@pucp.edu.pe
Kenneth Mueller ken@cmc.com
Sandra Murphy murphy@tis.com
Brad Parker brad@fcr.com
Andrew Partan asp@uunet.uu.net
Michael Patton map@bbn.com
Maryann Perez perez@cmf.nrl.navy.mil
James Philippou japhilippou@eng.xyplex.com
Rex Pugh pugh@hprnd.rose.hp.com
Murali Rajagopal murali@mitre.org
Ram Ramanathan ramanath@bbn.com
Robert Reschly reschly@brl.mil
Duncan Rogerson d.rogerson@nosc.ja.net
Joshua Seeger jseeger@bbn.com
William Simpson bsimpson@morningstar.com
Frank Solensky solensky@ftp.com
Martha Steenstrup msteenst@bbn.com
Bernhard Stockman boss@ebone.net
Dan Tappan tappan@lightstream.com
Jerry Toporek jt@mentat.com
Jost Weinmiller jost@prz.tu-berlin.de
Walter Wimer ww0n+@andrew.cmu.edu
Shian-Tung Wong shian@dcsd.sj.nec.com
Kwang Yao kwang@cup.hp.com
Kisong Yoon kysoon@garam.kreonet.re.kr
Lixia Zhang lixia@parc.xerox.com