home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / nimrod / nimrod-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  8KB  |  194 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Isidro Castineyra/Bolt Beranek and Newman
  5.  
  6. Minutes of the New Internet Routing and Addressing Architecture
  7. Working Group (NIMROD)
  8.  
  9.  
  10.  
  11. Preface
  12.  
  13. The Nimrod Working Group met on Wednesday December 7, 1994 from 0930 to
  14. 1200 and on Thursday December 8 from 0930 to 1200.  The agenda for the
  15. meeting was:
  16.  
  17.  
  18.    o Agenda bashing/Announcements (Isidro Castineyra)
  19.    o Introduction:  Nimrod Components (Isidro Castineyra)
  20.    o Nimrod Database Naming System (Isidro Castineyra)
  21.    o External Data Representation (Isidro Castineyra)
  22.    o Discovery Protocol (Isidro Castineyra)
  23.    o Hierarchical Update Protocol (Ram Ramanathan)
  24.    o Hierarchical Query/Response Protocol (Ram Ramanathan)
  25.    o Path Setup/Teardown Protocol (Martha Steenstrup)
  26.    o Transition Plan (Charlie Lynn)
  27.    o Reliable Transport Protocol (Charlie Lynn)
  28.    o Open Issues and Work Plan
  29.  
  30.  
  31. Components
  32.  
  33. Isidro Castineyra enumerated the components being designed:
  34.  
  35.  
  36.    o Database
  37.    o Discovery Protocol
  38.    o Hierarchical Update Protocol
  39.    o Reliable Transport
  40.    o Hierarchical Query/Response Protocol
  41.    o Hierarchical Path Setup/Teardown Protocol
  42.  
  43.  
  44. Database
  45.  
  46. Isidro Castineyra briefly described the organization of the database of
  47. routing information, a query language, and a suggested external
  48. representation.  The database was presented in terms of a description of
  49. the data structures for:  arcs, nodes, maps and connectivity
  50. specifications.  A proposed structure for each one of these was
  51. presented.  A sketch of a query language was also presented.  The
  52. suggested external data representation is based on (type, length, value)
  53. triples in which each element of the triple is encoded as in RFC 1014.
  54.  
  55.  
  56. Hierarchical Update Protocol
  57.  
  58. Ram Ramanathan discussed the hierarchical update and query protocols and
  59. the mapping of the association database maintenance, and map
  60. distribution to these protocols.  There were three main themes to the
  61. presentation:
  62.  
  63.  
  64.   1. Overview of functionality and description of map update and
  65.      association maintenance.  The functionality of Nimrod includes
  66.      agent and neighbor discovery, locator acquisition, arc formation,
  67.      map query, map distribution, association query and update, path
  68.      setup and teardown.  Currently, the plan is to use five protocols
  69.      in Nimrod - hierarchical update, hierarchical query-response, path
  70.      setup, discovery, reliable transport.  The functionality is
  71.      designed in terms of Nimrod ``agents'' which include the Entity
  72.      Representative, Association Agent, Route Agent and Forwarding
  73.      Agent.
  74.  
  75.      The functionality of map distribution and association maintenance
  76.      were described in terms of a node's immediate environment (i.e.,
  77.      the agents of the node's parent, child and sibling nodes).
  78.  
  79.   2. Hierarchical Update and Query Response Protocols.  The hierarchical
  80.      update protocol is used to update database contents (e.g.,
  81.      association database, map database, etc.).  It uses the Reliable
  82.      Transport protocol between peer agents.  The protocol engine at an
  83.      agent works as follows.  On the arrival of a message, it checks the
  84.      timestamp, sequence number, authentication, etc.  If it is not
  85.      okay, the message is ignored.  Otherwise, the Update Message
  86.      Forwarding Table (UMFT, to be defined) is consulted and a decision
  87.      is made whether or not to cache and/or forward.  As per the UMFT,
  88.      the message is forwarded to each agent.  If error, another agent is
  89.      tried.  Exceptions that must be handled include invalid timestamp,
  90.      duplicate message, nexthop unreachable.
  91.  
  92.      The query response protocol is used for obtaining information about
  93.      a specific portion of a database (e.g., association query, map
  94.      query, etc.).  Like the Update Protocol, this also uses the
  95.      Reliable Transport protocol between peer agents.  The protocol
  96.      engine at a transit agent is very similar to the update protocol
  97.      engine, except that a different table, Query Message Forwarding
  98.      Table (QMFT) is consulted.  At an originating agent, the protocol
  99.      engine is slightly different.  The originator prepares and sends a
  100.      query message (according to the QMFT) and sets a timer and waits
  101.      for one of the following :  A response to the query, upon which the
  102.      response is handed to the application; a query abort command from
  103.      the application, upon which the state is reset; a timer expiration
  104.      upon which state is reset.
  105.  
  106.   3. The mapping of functionality into protocols.  This is done by means
  107.      of the control message forwarding tables (UMFT and QMFT described
  108.      earlier).  A (U/Q)FMT contains, for each agent, a table with the
  109.      protocol messages (e.g., association update, map update, etc.)  as
  110.      the rows and the source of the message (e.g., agent F of parent,
  111.      agent E of child, etc.)  as the columns.  Every entry (i,j)
  112.      indicates the set of actions to be taken if a message of type i is
  113.      received from source j.
  114.  
  115.      The benefits of this approach include flexibility, implementation
  116.      friendliness and the explicit identification of all combinations.
  117.      A few UMFT and QMFT tables were described.
  118.  
  119.  
  120. The detailed design of the update and query-response protocols is in
  121. progress.  A draft will be posted to the nimrod-wg list shortly.
  122.  
  123.  
  124. Hierarchical Setup/Teardown Protocol
  125.  
  126. Martha Steenstrup discussed data message forwarding in Nimrod.  She
  127. presented a high-level overview of the Nimrod path setup protocol,
  128. including functional description, finite state machine, and packet
  129. formats.  The Nimrod path setup protocol establishes forwarding
  130. information in ``forwarding agents'' according to the routes selected.
  131. Each forwarding agent along the path performs route consistency and
  132. resource availability checks, before establishing forwarding state.
  133. Path setup may be initiated by the source or the destination, and paths
  134. may be torn down at any time by any forwarding agent along the path.
  135. She also discussed how Nimrod message forwarding would operate with
  136. IPv6.  She proposed several Nimrod-specific IPv6 options to carry nested
  137. path labels, performance monitoring information, Nimrod routes, service
  138. specifications, and endpoint identifiers.  Also, she provided examples
  139. of IPv6 data message formats corresponding to the Nimrod ``datagram''
  140. and ``flow'' message forwarding modes.
  141.  
  142.  
  143. Transition Plan
  144.  
  145. Charlie Lynn presented a transition plan that discussed the issues
  146. associated with moving from an IPv4 internetwork supporting the current
  147. routing protocols to an internetwork supporting IPv6 and Nimrod.  The
  148. slides from his presentation will be posted to the mailing list.
  149.  
  150.  
  151. Points Raised
  152.  
  153. Noel Chiappa proposed that maps be composed of ``metanodes'' and
  154. adjacencies (arcs with no attributes).  A metanode has attributes
  155. associated with it (e.g., connectivity specifications).  Connectivity
  156. between metanodes is represented with adjacencies.  Metanodes can be
  157. used to represent:  nodes, arcs with attributes, and multipoint arcs.
  158.  
  159. Dave Bridgham proposed that all connectivity specifications associated
  160. with a node be uniform:  i.e., that they apply between all pairs of
  161. incoming and outgoing arcs.
  162.  
  163.  
  164. Open Issues
  165.  
  166. The following open issues were identified.
  167.  
  168.  
  169.    o Locator external representation:
  170.  
  171.       1. Can the hierarchical structure of a locator be inferred from
  172.          its representation?
  173.       2. Is there a single representation for locators?
  174.  
  175.    o Performance specification and representation:  how to characterize
  176.      performance guarantees and how to represent these externally.
  177.  
  178.    o Policy representation.
  179.  
  180.    o Five alternative Architectural/representational variants:
  181.  
  182.       1. Multipoint arcs with attributes +
  183.          nodes with abstract maps and no connectivity specs;
  184.       2. Unidirectional arcs with attributes +
  185.          nodes with uniform connectivity specs and abstract maps;
  186.       3. Adjacencies +
  187.          nodes with specific (non-uniform) connectivity specs and *no*
  188.          abstract maps;
  189.       4. Adjacencies +
  190.          nodes with uniform connectivity specs and abstract maps;
  191.       5. Unidirectional arcs with attributes +
  192.          nodes with specific connectivity specs (no abstract maps).
  193.  
  194.