CURRENT_MEETING_REPORT_
Reported by Isidro Castineyra/Bolt Beranek and Newman
Minutes of the New Internet Routing and Addressing Architecture
Working Group (NIMROD)
Preface
The Nimrod Working Group met on Wednesday December 7, 1994 from 0930 to
1200 and on Thursday December 8 from 0930 to 1200. The agenda for the
meeting was:
o Agenda bashing/Announcements (Isidro Castineyra)
o Introduction: Nimrod Components (Isidro Castineyra)
o Nimrod Database Naming System (Isidro Castineyra)
o External Data Representation (Isidro Castineyra)
o Discovery Protocol (Isidro Castineyra)
o Hierarchical Update Protocol (Ram Ramanathan)
o Hierarchical Query/Response Protocol (Ram Ramanathan)
o Path Setup/Teardown Protocol (Martha Steenstrup)
o Transition Plan (Charlie Lynn)
o Reliable Transport Protocol (Charlie Lynn)
o Open Issues and Work Plan
Components
Isidro Castineyra enumerated the components being designed:
o Database
o Discovery Protocol
o Hierarchical Update Protocol
o Reliable Transport
o Hierarchical Query/Response Protocol
o Hierarchical Path Setup/Teardown Protocol
Database
Isidro Castineyra briefly described the organization of the database of
routing information, a query language, and a suggested external
representation. The database was presented in terms of a description of
the data structures for: arcs, nodes, maps and connectivity
specifications. A proposed structure for each one of these was
presented. A sketch of a query language was also presented. The
suggested external data representation is based on (type, length, value)
triples in which each element of the triple is encoded as in RFC 1014.
Hierarchical Update Protocol
Ram Ramanathan discussed the hierarchical update and query protocols and
the mapping of the association database maintenance, and map
distribution to these protocols. There were three main themes to the
presentation:
1. Overview of functionality and description of map update and
association maintenance. The functionality of Nimrod includes
agent and neighbor discovery, locator acquisition, arc formation,
map query, map distribution, association query and update, path
setup and teardown. Currently, the plan is to use five protocols
in Nimrod - hierarchical update, hierarchical query-response, path
setup, discovery, reliable transport. The functionality is
designed in terms of Nimrod ``agents'' which include the Entity
Representative, Association Agent, Route Agent and Forwarding
Agent.
The functionality of map distribution and association maintenance
were described in terms of a node's immediate environment (i.e.,
the agents of the node's parent, child and sibling nodes).
2. Hierarchical Update and Query Response Protocols. The hierarchical
update protocol is used to update database contents (e.g.,
association database, map database, etc.). It uses the Reliable
Transport protocol between peer agents. The protocol engine at an
agent works as follows. On the arrival of a message, it checks the
timestamp, sequence number, authentication, etc. If it is not
okay, the message is ignored. Otherwise, the Update Message
Forwarding Table (UMFT, to be defined) is consulted and a decision
is made whether or not to cache and/or forward. As per the UMFT,
the message is forwarded to each agent. If error, another agent is
tried. Exceptions that must be handled include invalid timestamp,
duplicate message, nexthop unreachable.
The query response protocol is used for obtaining information about
a specific portion of a database (e.g., association query, map
query, etc.). Like the Update Protocol, this also uses the
Reliable Transport protocol between peer agents. The protocol
engine at a transit agent is very similar to the update protocol
engine, except that a different table, Query Message Forwarding
Table (QMFT) is consulted. At an originating agent, the protocol
engine is slightly different. The originator prepares and sends a
query message (according to the QMFT) and sets a timer and waits
for one of the following : A response to the query, upon which the
response is handed to the application; a query abort command from
the application, upon which the state is reset; a timer expiration
upon which state is reset.
3. The mapping of functionality into protocols. This is done by means
of the control message forwarding tables (UMFT and QMFT described
earlier). A (U/Q)FMT contains, for each agent, a table with the
protocol messages (e.g., association update, map update, etc.) as
the rows and the source of the message (e.g., agent F of parent,
agent E of child, etc.) as the columns. Every entry (i,j)
indicates the set of actions to be taken if a message of type i is
received from source j.
The benefits of this approach include flexibility, implementation
friendliness and the explicit identification of all combinations.
A few UMFT and QMFT tables were described.
The detailed design of the update and query-response protocols is in
progress. A draft will be posted to the nimrod-wg list shortly.
Hierarchical Setup/Teardown Protocol
Martha Steenstrup discussed data message forwarding in Nimrod. She
presented a high-level overview of the Nimrod path setup protocol,
including functional description, finite state machine, and packet
formats. The Nimrod path setup protocol establishes forwarding
information in ``forwarding agents'' according to the routes selected.
Each forwarding agent along the path performs route consistency and
resource availability checks, before establishing forwarding state.
Path setup may be initiated by the source or the destination, and paths
may be torn down at any time by any forwarding agent along the path.
She also discussed how Nimrod message forwarding would operate with
IPv6. She proposed several Nimrod-specific IPv6 options to carry nested
path labels, performance monitoring information, Nimrod routes, service
specifications, and endpoint identifiers. Also, she provided examples
of IPv6 data message formats corresponding to the Nimrod ``datagram''
and ``flow'' message forwarding modes.
Transition Plan
Charlie Lynn presented a transition plan that discussed the issues
associated with moving from an IPv4 internetwork supporting the current
routing protocols to an internetwork supporting IPv6 and Nimrod. The
slides from his presentation will be posted to the mailing list.
Points Raised
Noel Chiappa proposed that maps be composed of ``metanodes'' and
adjacencies (arcs with no attributes). A metanode has attributes
associated with it (e.g., connectivity specifications). Connectivity
between metanodes is represented with adjacencies. Metanodes can be
used to represent: nodes, arcs with attributes, and multipoint arcs.
Dave Bridgham proposed that all connectivity specifications associated
with a node be uniform: i.e., that they apply between all pairs of
incoming and outgoing arcs.
Open Issues
The following open issues were identified.
o Locator external representation:
1. Can the hierarchical structure of a locator be inferred from
its representation?
2. Is there a single representation for locators?
o Performance specification and representation: how to characterize
performance guarantees and how to represent these externally.
o Policy representation.
o Five alternative Architectural/representational variants:
1. Multipoint arcs with attributes +
nodes with abstract maps and no connectivity specs;
2. Unidirectional arcs with attributes +
nodes with uniform connectivity specs and abstract maps;
3. Adjacencies +
nodes with specific (non-uniform) connectivity specs and *no*
abstract maps;
4. Adjacencies +
nodes with uniform connectivity specs and abstract maps;
5. Unidirectional arcs with attributes +
nodes with specific connectivity specs (no abstract maps).