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).