home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / nimrod / nimrod-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  14KB  |  439 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. Preface
  11.  
  12. The Nimrod Working Group met on Wednesday, 19 July, and on Thursday,
  13. 20 July.  The agenda for the meeting was:
  14.  
  15.  
  16.    o Wednesday
  17.       -  Agenda bashing/Announcements
  18.       -  Overview of the Implementation Model (Isidro Castineyra)
  19.       -  Neighbor Discovery Protocol (Ram Ramanathan)
  20.       -  Agent Discovery Protocol (Ram Ramanathan)
  21.  
  22.    o Thursday
  23.       -  Path Set-up Protocol (Isidro Castineyra)
  24.       -  Reliable Transaction Protocol (Ram Ramanathan)
  25.       -  Query Response and Update Protocols (Ram Ramanathan)
  26.       -  Open Issues and Work Plan
  27.  
  28.  
  29. The discussion of the agent discovery protocol was eliminated from the
  30. agenda.  A demonstration of a configuration tool written by Mike Patton
  31. was added at the end of the first session.
  32.  
  33.  
  34. Overview of the Implementation Model
  35.  
  36. The following are the main points from that presentation:
  37.  
  38.  
  39.    o Network Components
  40.  
  41.       -  A Nimrod network is composed of Nimrod boxes:  Nimrod routers
  42.          and Nimrod hosts.
  43.  
  44.       -  Nimrod forwarding agents live in Nimrod routers.
  45.  
  46.       -  Other agents, e.g., route agents, node representatives,
  47.          endpoint representatives, can live in either Nimrod routers or
  48.          in Nimrod hosts.
  49.  
  50.       -  A given Nimrod box can be the home of agents for multiple
  51.          nodes, e.g., for a node and its component nodes.
  52.  
  53.  
  54.    o Interfaces
  55.  
  56.       -  Nimrod routers and hosts have distinct interfaces to the
  57.          external world.
  58.  
  59.       -  Interfaces are not assigned locators.
  60.  
  61.       -  Interfaces are numbered for management purposes.
  62.  
  63.  
  64.    o Interconnectivity of Nimrod Boxes
  65.  
  66.       -  Two different boxes are directly connected if there are
  67.          interfaces in each one of them that can exchange data without
  68.          the aid of any other Nimrod Box and such that data exchange is
  69.          actually enabled.
  70.  
  71.       -  The connectivity between two interfaces can be realized in many
  72.          ways, for example:  PPP, Ethernet, IP, IPv6, ATM, etc.  The
  73.          underlying technology is not important.
  74.  
  75.       -  We say that a set of Nimrod boxes is connected if between any
  76.          two of them there exists a path consisting of other Nimrod
  77.          boxes in that set, such that consecutive boxes in the path are
  78.          directly connected.
  79.  
  80.  
  81.    o Agents
  82.  
  83.          -  Endpoint Representatives
  84.          -  Node Representatives
  85.          -  Forwarding Agents
  86.          -  Route Agents
  87.  
  88.    
  89.    o Connectivity
  90.    
  91.       -  Any one agent is associated with a one and only one node.  That
  92.          is, an agent for a component node is not associated with the
  93.          parent node.
  94.  
  95.       -  This is emphasized by the phrase ``associated in the narrow
  96.          sense.''
  97.  
  98.       -  An agent is associated ``in the wide sense'' with a node if it
  99.          is associated with the node or one of its component nodes
  100.          (recursively).
  101.  
  102.       -  Two agents are directly connected if either they
  103.          1. reside in the same box, or
  104.          2. reside in boxes that are directly connected.
  105.  
  106.       -  A set of agents is connected if the set of boxes they belong to
  107.          is connected.
  108.  
  109.  
  110.    o Boundaries
  111.  
  112.       -  A boundary between two nodes exists between any two directly
  113.          connected forwarding agents that belong to different nodes.
  114.  
  115.       -  Therefore, a boundary between two nodes can occur both inside a
  116.          Nimrod box and between two boxes.
  117.  
  118.       -  Existence of a boundary between two nodes does not necessarily
  119.          imply the existence at that point of an adjacency between those
  120.          two nodes.
  121.  
  122.  
  123.    o Tight Connectivity Restrictions
  124.  
  125.       -  Forwarding Agents:  the set of forwarding agents associated
  126.          with a node (in the narrow sense) must be connected, i.e., the
  127.          node must have a backbone of forwarding agents.
  128.  
  129.       -  Node Representatives:  each node representative must be
  130.          directly connected to a forwarding agent of the node it
  131.          represents.
  132.  
  133.       -  Endpoint Representatives:  To communicate with agents to which
  134.          it is not directly connected, an endpoint representative must
  135.          be connected to a forwarding agent.
  136.  
  137.       -  For a node that has a parent, at least one of its forwarding
  138.          agents (narrow sense) must be connected to a forwarding agent
  139.          in the parent.
  140.  
  141.  
  142.    o Tight Flooding Rule
  143.  
  144.      ``Agent discovery messages are flooded only within the boundaries
  145.      of a node (strict sense).''
  146.  
  147.    o Loose Connectivity Restrictions
  148.  
  149.       -  Forwarding Agents:  The set of all forwarding agents associated
  150.          in the wide sense with a given node must be connected.
  151.  
  152.       -  Node Representatives:  each node representative must be
  153.          connected to a forwarding agent associated in the wide sense
  154.          with the node it represents.
  155.  
  156.       -  Endpoint Representatives:  To communicate with agents to which
  157.          it is not directly connected, an endpoint representative must
  158.          be connected to a forwarding agent of the same node.
  159.  
  160.       -  The set of forwarding agents of sibling nodes must be connected
  161.          to one agent of the parent node.
  162.  
  163.  
  164.    o Protocols
  165.  
  166.       -  Neighbor Discovery:  implemented by all agents.
  167.       -  Agent Discovery:  implemented by all agents.
  168.       -  Reliable Transaction Protocol:  implemented by all agents.
  169.       -  Query/Response:  implemented by all agents.
  170.       -  Update:  implemented by all agents.
  171.       -  Path Set-Up:  requests sent by endpoint representatives (at top
  172.          level) and/or forwarding agents (at lower level paths) by
  173.          forwarding agents.
  174.  
  175.  
  176. There was a discussion on the benefits of the ``tight'' against the
  177. ``loose'' model.  The general consensus was that the loose model was
  178. preferable.
  179.  
  180.  
  181. Agent Discovery Protocol
  182.  
  183. Ram Ramanathan presented the agent discovery protocol.  The slides of
  184. this presentation will be posted to the mailing list.
  185.  
  186.  
  187. Path Set Up Protocol
  188.  
  189. Isidro Castineyra presented the path set up protocol.  Highlights of
  190. that presentation follow:
  191.  
  192.  
  193.    o Agents and Path Management
  194.  
  195.       -  Path management is the responsibility of forwarding agents and
  196.          endpoint representatives.
  197.  
  198.       -  Forwarding agents establish state in routers, endpoint
  199.          representatives in hosts and in themselves.
  200.  
  201.       -  Forwarding agents and endpoint representatives are responsible
  202.          for forwarding Nimrod messages according to this state
  203.          information and according to forwarding directives carried
  204.          along in the messages.
  205.  
  206.       -  Each forwarding agent and endpoint representative maintains
  207.          forwarding information for those paths that originate,
  208.          terminate, or, in the case of forwarding agents, pass thorough
  209.          it.
  210.  
  211.       -  Forwarding agents try to build new forwarding paths by piecing
  212.          together existing paths.
  213.  
  214.  
  215.    o Paths
  216.  
  217.       -  Paths may be set up from source to destination or from
  218.          destination to source.
  219.  
  220.       -  Each path has an initiator and a target.
  221.  
  222.       -  Multiple traffic sessions may use the same path.
  223.  
  224.       -  A single traffic session may use multiple paths.
  225.  
  226.       -  A path may connect one or more source endpoints to one or more
  227.          destination endpoints.  In the initial implementation of
  228.          Nimrod, each multicast path is either a source tree or a sink
  229.          tree.
  230.  
  231.  
  232.    o Path Labels
  233.  
  234.       -  Paths are identified by path labels, which are unique along the
  235.          path but not necessarily globally unique throughout the
  236.          internetwork.
  237.  
  238.       -  The labels for direction of a path are distinguished by a bit
  239.          that indicates whether the direction is toward the target or
  240.          toward the initiator.
  241.  
  242.       -  Labels are assigned randomly.  There exists a label collision
  243.          resolution procedure.
  244.  
  245.  
  246.    o Multilevel Paths
  247.  
  248.       -  A single path comprises multiple lower level contiguous paths ,
  249.          one for each of the n segments of the route on which the
  250.          original path is based.
  251.  
  252.       -  Each component path itself comprises multiple contiguous paths
  253.          corresponding to each of its segments, and so on recursively.
  254.  
  255.       -  For each pij composing pi-1 k, the initiator and target of pij
  256.          maintain linkages from the path pi-1k to pi j , which helps to
  257.          guide forwarding along the successive segments of pi-1k.
  258.  
  259.       -  A flow mode data message, at any point along the end-to-end
  260.          path, contains one path label for each level, but only one path
  261.          label is used for forwarding at a given time.  Path labels are
  262.          stacked in the message and manipulated by the forwarding agents
  263.          handling the message.
  264.  
  265.  
  266.    o Protocol Messages
  267.  
  268.       -  There are four types of message:  setup, accept, teardown, and
  269.          management.
  270.  
  271.       -  These messages travel along the path to which they refer.
  272.  
  273.       -  The messages can be used to collect and return performance
  274.          monitoring information for a path---e.g., path delay and
  275.          throughput.
  276.  
  277.       -  Monitoring operates in two modes:  collection and return.
  278.  
  279.  
  280.    o Setup Message
  281.  
  282.      Generated by the path initiator and used to establish forwarding
  283.      state in forwarding agents.  It contains:
  284.  
  285.       1. End-to-end path label and label stack.
  286.  
  287.       2. Route.
  288.  
  289.       3. Path label collision indication.
  290.  
  291.       4. Multicast group identifier (for multicast).
  292.  
  293.       5. Indication of whether the path is source- or
  294.          destination-initiated.
  295.  
  296.       6. Service requirements for the source and/or destination (TLV
  297.          format).
  298.  
  299.       7. Monitored information for the path updated at each node in the
  300.          path (TLV format).
  301.  
  302.  
  303.    o Accept Message
  304.  
  305.      This message is generated by the path target and is used to
  306.      indicate successful path establishment from initiator to target.
  307.      It contains:
  308.  
  309.       1. The label of the accepted path.
  310.       2. Any monitored information for the path, collected during setup.
  311.  
  312.  
  313.    o Teardown Message
  314.  
  315.      This message is generated by any forwarding agent on the path and
  316.      is used to remove forwarding state.  It contains:
  317.    
  318.       1. The label of the path being torn down.
  319.  
  320.       2. Any monitored information for the path collected along the
  321.          path.
  322.  
  323.       3. The reason for the teardown (TLV format).  This may include
  324.          target service requirements.  Teardown messages may travel in
  325.          both directions along paths and may result from any of the
  326.          following:
  327.  
  328.          -  Failure to meet source and/or destination's service
  329.             requirements.
  330.  
  331.          -  Loss of component lower-level path.
  332.  
  333.          -  Timeout.
  334.  
  335.          -  Change in service requirements.
  336.  
  337.          -  Insufficient available resource at the next hop.
  338.  
  339.          -  Change in connectivity specification for a node in the
  340.             route.
  341.  
  342.          -  Unresolvable label collision.
  343.  
  344.          -  Preemption.
  345.  
  346.  
  347.    o Initiator Finite State Machine
  348.  
  349.      It has four states:  idle, check, ready, and done.  Transitions are
  350.      described below:
  351.  
  352.       -  idle !  check:  initiator begins the setup
  353.  
  354.       -  check !  ready:  occurs after the initiator has successfully
  355.          completed all of the resource availability checks for the path.
  356.  
  357.       -  check !  idle:  occurs if the initiator fails to complete the
  358.          resource availability check for the path.
  359.  
  360.       -  ready !  done:  initiator receives an accept message.
  361.  
  362.       -  ready !  idle, done !  idle:  occurs when the initiator
  363.          receives a teardown message for the path.  Forwarding
  364.          information for the path is removed.
  365.  
  366.  
  367.    o Forwarding Agent and Target State Machine
  368.  
  369.      This machine has three states:  idle, check, and ready.  State
  370.      transitions are described below:
  371.  
  372.       -  idle !  check:  occurs when one of the agents receives a setup
  373.          message.
  374.  
  375.       -  check !  ready:  occurs after the agent has successfully
  376.          completed all the consistency and resource availability checks
  377.          for the path---including target service requirements check.
  378.  
  379.       -  check !  idle:  occurs if the agent fails to complete the
  380.          consistency checks and resource availability checks for the
  381.          path.
  382.  
  383.       -  ready !  idle:  occurs when the agent receives or generates a
  384.          teardown message for the path.
  385.  
  386.  
  387.    o Check State Actions
  388.  
  389.       -  General consistency checks:
  390.  
  391.          1. setup not out of date;
  392.  
  393.          2. setup not duplicate;
  394.  
  395.          3. path label not in use (not generally fatal).
  396.  
  397.       -  Checks performed by intermediate forwarding agents:
  398.  
  399.          1. The forwarding agents acts on behalf of the current node in
  400.             the route specification carried in the setup message.
  401.  
  402.          2. The connectivity specification label for the node, carried
  403.             in the setup message, is a valid connectivity specification
  404.             for this node.
  405.  
  406.          3. The node's service restrictions do not preclude carrying
  407.             traffic along the specified route.
  408.  
  409.       -  Checks performed by target:
  410.  
  411.          1. The route specified carried in the setup message meets the
  412.             target endpoint's service requirement.
  413.  
  414.  
  415.    o Resource Availability Checks
  416.      These include the following:
  417.  
  418.       1. The forwarding database can accommodate state for a new path.
  419.  
  420.       2. There exists a feasible path to the next node on the specified
  421.          route.  This is an extensive check performed by the initiator
  422.          and intermediate forwarding agents.  The initiator or
  423.          intermediate forwarding agent may have to request a route and
  424.          set up this path, or there may be such a path already
  425.          established.
  426.  
  427.  
  428. Reliable Transaction Protocol
  429.  
  430. Ram Ramanathan presented briefly the reliable transaction protocol used
  431. by Nimrod:  TTCP.
  432.  
  433.  
  434. Query Response Protocol
  435.  
  436. Ram Ramanathan presented the query response protocol.  The slides from
  437. the presentation will be sent to the mailing list of the working group.
  438.  
  439.