Received: from PIZZA.BBN.COM by BBN.COM id aa20570; 6 Jul 95 15:43 EDT Received: from pizza by PIZZA.BBN.COM id aa09324; 6 Jul 95 14:42 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa09320; 6 Jul 95 14:39 EDT Received: from ns.Newbridge.Com by BBN.COM id aa12261; 6 Jul 95 14:22 EDT Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id LAA14767; Thu, 6 Jul 1995 11:51:01 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma014761; Thu Jul 6 11:50:48 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id LAA20547; Thu, 6 Jul 1995 11:50:44 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA16829; Thu, 6 Jul 95 11:48:39 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA15256; Thu, 6 Jul 1995 11:49:57 +0500 Date: Thu, 6 Jul 1995 11:49:57 +0500 From: Joel Halpern Message-Id: <9507061549.AA15256@lobster.Newbridge.COM> To: ip-atm@matmos.hpl.hp.com, rolc@nexen.com, nimrod-wg@BBN.COM Subject: ATM Forum PNNI Drafts X-Sun-Charset: US-ASCII Content-Length: 521 The current draft of the ATM Forum PNNI Routing protocol is available to any interested IETF participants (which means anyone) by anonymous FTP. The current document is revision 9, and can be found atm: node: atmforum.com directory: pub/contributions file: atm94-0471.ps For clarity, the URL is: ftp://ftp.atmforum.com/pub/contributions/atm94-0471.ps Sorry, but it is only available in Postscript. It is quite large. Enjoy, Joel M. Halpern jhalpern@newbridge.com   Received: from PIZZA.BBN.COM by BBN.COM id aa10425; 10 Jul 95 11:16 EDT Received: from pizza by PIZZA.BBN.COM id aa07797; 10 Jul 95 10:51 EDT Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa07793; 10 Jul 95 10:47 EDT To: nimrod-wg@BBN.COM Subject: Agenda for IETF33 Date: Mon, 10 Jul 95 10:51:58 -0400 From: Isidro Castineyra Group Name: Nimrod - The New Internet Routing and Addressing Architecture IETF Area: Routing Date/Time: Wednesday, 19 July, 1995 1300-1500 Thursday, 20 July, 1995 0900-1130 Proposed Agenda -- First Session 1. Agenda bashing/Announcements 5min 2. Overview of the Implementation Model 45min (Isidro Castineyra) 3. Neighbor Discovery Protocol 15min (Ram Ramanathan) 4. Agent Discovery Protocol 30min (Ram Ramanathan) Proposed Agenda -- Second Session 5. Path Set-up Protocol 30min (Isidro Castineyra) 6. Reliable Transaction Protocol 10min (Ram Ramanathan) 7. Query Response and Update Protocols 30min (Ram Ramanathan) 8. Open Issues and Work Plan 15min   Received: from PIZZA.BBN.COM by BBN.COM id aa06057; 10 Jul 95 15:12 EDT Received: from pizza by PIZZA.BBN.COM id aa08932; 10 Jul 95 14:01 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa08928; 10 Jul 95 13:57 EDT Received: from lobster.wellfleet.com by BBN.COM id aa27629; 10 Jul 95 13:46 EDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA01762; Mon, 10 Jul 95 12:12:51 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA17127; Mon, 10 Jul 95 12:14:09 EDT Date: Mon, 10 Jul 95 12:14:09 EDT Message-Id: <9507101614.AA17127@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA04929; Mon, 10 Jul 95 12:14:05 EDT From: Mike Davis To: isidro@BBN.COM Cc: nimrod-wg@BBN.COM In-Reply-To: <9507101529.AA28827@lobster.wellfleet.com> (message from Isidro Castineyra on Mon, 10 Jul 95 10:51:58 -0400) Subject: Re: Agenda for IETF33 Is this the correct list of documents? (taken from the WWW page of nimrod Charter at CNRI) o The Nimrod Routing Architecture (70577 bytes) o Mobility Support for Nimrod : Requirements and Solution Approaches (41042 bytes). (There is also a PostScript version [157021 bytes].) o Multicast Support for Nimrod : Requirements and Solution Approaches (49321 bytes). (There is also a PostScript version [186438 bytes].) o DNS Resource Records for Nimrod Routing Architecture (14224 bytes) --mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016   Received: from PIZZA.BBN.COM by BBN.COM id aa26040; 20 Jul 95 7:38 EDT Received: from pizza by PIZZA.BBN.COM id aa10950; 20 Jul 95 7:13 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa10946; 20 Jul 95 7:10 EDT Received: from GAAK.BBN.COM by BBN.COM id aa21801; 20 Jul 95 7:11 EDT Date: Thu, 20 Jul 1995 07:11:05 EDT Message-ID: To: Nimrod-WG@BBN.COM Subject: Info on IETF demo From: "Michael A. Patton" Reply-To: "Michael A. Patton, Nimrod" For those at the IETF this week, I put together a snapshot of a tool I'm working on for visualizing Nimrod maps and other data. I said in the WG session that I would post the instructions for those who couldn't see it or wanted more time to give me feedback. Well, after the direct feedback from the demo, I fiddled it a little and just put the new version in place, so even those who saw the demo may want to play. (the changes were mostly distinguishing nodes that can be expanded and some cosmetic cleanup of some maps, there were more comments that I don't have time to do this week, but I will :-). Here's the command to run the "explorer" demo in the IETF terminal room. If you're not here but have AFS on either a Sun4 or DECmips, you, too, can run it this way. If you have AFS on another platform all you need to do is build STk (available from kaolin.unice.fr), then look at the script for how to start it. Other combinations will be harder... /afs/athena.mit.edu/user/m/a/map/nimrod-demo/start You need to be running X, first, of course... -MAP   Received: from PIZZA.BBN.COM by BBN.COM id aa06004; 4 Aug 95 11:44 EDT Received: from pizza by PIZZA.BBN.COM id aa04407; 4 Aug 95 10:43 EDT Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa04401; 4 Aug 95 10:39 EDT To: minutes@cnri.reston.va.us cc: nimrod-wg@BBN.COM Subject: Nimrod WG Minutes Date: Fri, 04 Aug 95 10:44:10 -0400 From: Isidro Castineyra Nimrod WG Minutes, IETF 32, Danvers Isidro Castineyra, BBN August 4, 1995 1 Preface The Nimrod Working Group met on Wednesday July 19 from 1300 to 1500, and on Thursday July 20 from 0900 to 1130. The agenda for the meeting was: o Wednesday, July 19, 1995---1300-1500 1. Agenda bashing/Announcements---5min 2. Overview of the Implementation Model---45min (Isidro Castineyra) 3. Neighbor Discovery Protocol---15min (Ram Ramanathan) 4. Agent Discovery Protocol---30min (Ram Ramanathan) o Thursday, July 20, 1995---0900-1130 1. Path Set-up Protocol---30min (Isidro Castineyra) 2. Reliable Transaction Protocol---10min (Ram Ramanathan) 3. Query Response and Update Protocols---30min (Ram Ramanathan) 4. Open Issues and Work Plan---15min 1 The discussion of the agent discovery protocol was eliminated from the agenda. A demo of a configuariont tool written by Mike Patton was added at the end of the first session. 2 Overview of the Implementation Model The following are the main points from that presentation: o Network Components -- A Nimrod network is composed of Nimrod boxes: Nimrod routers and Nimrod hosts. -- Nimrod forwarding agents live in Nimrod routers. -- Other agents---e.g., route agents, node representatives, endpoint representatives---can live in either Nimrod routers or in Nimrod hosts. -- A given Nimrod box can be the home of agents for multiple nodes---e.g., for a node and its component nodes. o Interfaces -- Nimrod routers and hosts have distinct interfaces to the external world. -- Interfaces are not assigned locators. -- Interfaces are numbered for management purposes. o Interconnectivity of Nimrod Boxes -- Two different boxes are directly connected if there are interfaces in each one of them that can exchange data without the aid of any other Nimrod Box and such that data exchange is actually enabled. -- The connectivity between two interfaces can be realized in many ways, for example: PPP, Ethernet, IP, IPv6, ATM, etc. The underlying technology is not important. 2 -- We say that a set of Nimrod boxes is connected if between any two of them there exists a path consisting of other Nimrod boxes in that set, such that consecutive boxes in the path are directly connected. o Agents -- Endpoint Representatives -- Node Representatives -- Forwarding Agents -- Route Agents o Connectivity -- Any one agent is associated with a one and only one node. That is, an agent for a component node is not associated with the parent node. -- This is emphasized by the phrase ``associated in the narrow sense.'' -- An agent is associated ``in the wide sense'' with a node if it is associated with the node or one of its component nodes (recursively). -- Two agents are directly connected if either they 1. reside in the same box, or 2. reside in boxes that are directly connected. -- A set of agents is connected if the set of boxes they belong to is connected. o Boundaries -- A boundary between two nodes exists between any two directly connected forwarding agents that belong to different nodes. 3 -- Therefore, a boundary between two nodes can occur both inside a Nimrod box and between two boxes. -- Existence of a boundary between two nodes does not necessarily imply the existence at that point of an adjacency between those two nodes. o Tight Connectivity Restrictions -- Forwarding Agents : the set of forwarding agents associated with a node (in the narrow sense) must be connected. I.e., the node must have a backbone of forwarding agents. -- Node Representatives: each node representative must be directly connected to a forwarding agent of the node it represents. -- Endpoint Representatives: To communicate with agents to which it is not directly connected, an endpoint representative must be connected to a forwarding agent. -- For a node that has a parent, at least one of its forwarding agents (narrow sense) must be connected to a forwarding agent in the parent. o Tight Flooding Rule ``Agent discovery messages are flooded only within the boundaries of a node (strict sense).'' o Loose Connectivity Restrictions -- Forwarding Agents: The set of all forwarding agents associated in the wide sense with a given node must be connected. -- Node Representatives: each node representative must be connected to a forwarding agent associated in the wide sense with the node it represents. -- Endpoint Representatives: To communicate with agents to which it is not directly connected, an endpoint representative must be connected to a forwarding agent of the same node. -- The set of forwarding agents of sibling nodes must be connected to one agent of the parent node. 4 o Protocols -- Neighbor Discovery: implemented by all agents. -- Agent Discovery: implemented by all agents -- Reliable Transaction Protocol: implemented by all agents -- Query/Response: implemented by all agents -- Update: implemented by all agents -- Path Set-Up: requests sent by endpoint representatives (at top level) and/or forwarding agents (at lower level paths) by forwarding agents. There was a discussion on the benefits of the ``tight'' againts the ``loose'' model. The general consensus was that the loose model was preferable. 3 Agent Discovery Protocol Ram Ramanathan presented the agent discovery protocol. The slides of this presentation will be posted to the mailing list. 4 Path Set Up Protocol Isidro Castineyra presented the path set up protocol. Highlights of that presentation follow: o Agents and Path Management -- Path management is the responsibility of forwarding agents and endpoint representatives. -- Forwarding agents establish state in routers, endpoint representatives in hosts and in themselves. -- Forwarding agents and endpoint representatives are responsible for forwarding Nimrod messages according to this state information and according to forwarding directives carried along in the messages. 5 -- Each forwarding agent and endpoint representative maintains forwarding information for those paths that originate, terminate, or, in the case of forwarding agents, pass thorough it. -- Forwarding agents try to build new forwarding paths by piecing together existing paths. o Paths -- Paths may be set up from source to destination or from destination to source. -- Each path has an initiator and a target. -- Multiple traffic sessions may use the same path. -- A single traffic session may use multiple paths. -- A path may connect one or more source endpoints to one or more destination endpoints. In the initial implementation of Nimrod, each multicast path is either a source tree or a sink tree. o Path Labels -- Paths are identified by path labels, which are unique along the path but not necessarily globally unique throughout the internetwork. -- The labels for direction of a path are distinguished by a bit that indicates whether the direction is toward the target or toward the initiator. -- Labels are assigned randomly. There exists a label collision resolution procedure. o Multilevel Paths -- A single path comprises multiple lower level contiguous paths , one for each of the n segments of the route on which the original path is based. -- Each component path itself comprises multiple contiguous paths corresponding to each of its segments, and so on recursively. 6 -- For each pij composing pi-1 k, the initiator and target of pij maintain linkages from the path pi-1k to pi j , which helps to guide forwarding along the successive segments of pi-1k. -- A flow mode data message, at any point along the end-to-end path, contains one path label for each level, but only one path label is used for forwarding at a given time. Path labels are stacked in the message and manipulated by the forwarding agents handling the message. o Protocol Messages -- There are four types of message: setup, accept, teardown, and management. -- These messages travel along the path to which they refer. -- The messages can be used to collect and return performance monitoring information for a path---e.g., path delay and throughput. -- Monitoring operates in two modes: collection and return. o Setup Message Generated by the path initiator and used to establish forwarding state in forwarding agents. It contains: 1. End-to-end path label and label stack; 2. Route; 3. Path label collision indication; 4. Multicast group identifier (for multicast); 5. Indication of whether the path is source- or destination-initiated; 6. Service requirements for the source and/or destination (TLV format); 7. Monitored information for the path updated at each node in the path (TLV format). 7 o Accept Message This message is generated by the path target and is used to indicate successful path establishment from initiator to target. It contains: 1. The label of the accepted path. 2. Any monitored information for the path, collected during setup. o Teardown Message This message is generated by any forwarding agent on the path and is used to remove forwarding state. It contains: 1. The label of the path being torn down. 2. Any monitored information for the path collected along the path. 3. The reason for the teardown (TLV format). This may include target service requirements. Teardown messages may travel in both directions along paths and may result from any of the following: (a) Failure to meet source and/or destination's service requirements. (b) Loss of component lower-level path. (c) Timeout. (d) Change in service requirements. (e) Insufficient available resource at the next hop. (f) Change in connectivity specification for a node in the route. (g) Unresolvable label collision. (h) Preemption. o Initiator Finite State Machine It has four states: idle, check, ready, and done. Transitions are described below: 8 -- idle ! check: initiator begins the setup -- check ! ready: occures after the initiator has succesfully completed all of the resource availability checks for the path. -- check ! idle: occurs if the initiator fails to complete the resource availability check for the path. -- ready ! done: initiator receives an accept message. -- ready ! idle, done ! idle: occurs when the initiator receives a teardown message for the path. Forwarding information for the path is removed. o Forwarding Agent and Target State Machine This machine has three states: idle, check, and ready. State transitions are described below: -- idle ! check: occurs when one of the agents receives a setup message. -- check ! ready: occurs after the agent has successfully completed all the consistency and resource availability checks for the path---including target service requirements check. -- check ! idle: occurs if the agent fails to complete the consistency checks and resource availability checks for the path. -- ready ! idle: occurs when the agent recieves or generates a teardown message for the path. o Check State Actions -- General consistency checks: 1. setup not out of date; 2. setup not duplicate; 3. path label not in use (not generally fatal). -- Checks performed by intermediate forwarding agents: 9 1. the forwarding agents acts on behalf of the current node in the route specification carried in the setup message; 2. the connectivity specification label for the node, carried in the setup message, is a valid connectivity specification for this node; 3. the node's service restrictions do not preclude carrying traffic along the specified route. -- Checks performed by target: 1. The route specified carried in the setup message meets the target endpoint's service requirement. o Resource Availability Checks These include the following: 1. the forwarding database can accommodate state for a new path; 2. there exists a feasible path to the next node on the specified route. This is an extensive check performed by the initiator and intermediate forwarding agents. The initiator or intermediate forwarding agent may have to request a route and set up this path, or there may be such a path already established. 5 Reliable Transaction Protocol Ram Ramanathan presented briefly the reliable transaction protocol used by Nimrod: TTCP. 6 Query Response Protocol Ram Ramanathan presented the query response protocol. The slides from tha presentation will be sent to the mailing list of the working group. 10   Received: from PIZZA.BBN.COM by BBN.COM id aa02016; 9 Aug 95 13:05 EDT Received: from pizza by PIZZA.BBN.COM id aa00789; 9 Aug 95 12:30 EDT Received: from TTL.BBN.COM by PIZZA.BBN.COM id aa00785; 9 Aug 95 12:26 EDT To: nimrod-wg@BBN.COM Subject: Re: Nimrod WG Minutes In-reply-to: Your message of Fri, 04 Aug 95 10:44:10 -0400. Date: Wed, 09 Aug 95 12:22:23 -0400 From: Ram Ramanathan >3 Agent Discovery Protocol >Ram Ramanathan presented the agent discovery protocol. The slides of this >presentation will be posted to the mailing list. Here are the main points of my presentation in the Stockholm IETF, covering the following topics: 1. Agent discovery 2. Reliable transaction protoocol. 3. Update protocol. 4. Query-Response protocol. Please send your comments or questions to ramanath@bbn.com cc to the mailing list. -Ram. -------------------------------------------------------------------------- 1. AGENT DISCOVERY Purpose : Enables agents in a node to learn how to reach each other before all nodes are fully operational (i.e., bootstrapping). o Assumptions/Restrictions -- All inter-agent links are 2-way. -- All forwarding agents are connected to each other. -- Every agent is directly connected to a forwarding agent. o Protocol Features -- Periodic flooding of agent advertisements. -- Each agent maintains a next-hop-agent table. -- At the `end' of agent discovery o Every agent knows next-hop to reach every `key' agent (all agents except interior forwarding agents). o Route agent(s) have link-state information of entire topology and can construct a route to any other agent. o Protocol Operation -- Every agent generates an agent advertisement periodically containing: Agent type, EID, locator (if available), NID, list of neighboring agents and services offered on links to them, timestamp. -- Advertisements reliably flooded through the node. o Agent generating sends to each neighbor. o Only forwarding agents redistribute. -- When an agent T receives from an agent N an advertisement generated by an agent D, then o T checks that the timestamp is okay. o Creates/updates next-hop entry for D as N. o Only the FIRST next-hop learned is used. o If T is a route agent, then it updates its link-state -- If agents Q and R lose connectivity with each other, each o generates an agent advertisement. o generate an ``unreachability indication'' which is flooded as advertisements are. 2. RELIABLE TRANSACTION PROTOCOL o Provides its clients the ability to reliably communicate arbitrary sized blocks of information to a peer. o Built on Transaction-TCP (TTCP), RFC 1644, RFC 1379. o Bypasses 3-way handshake of TCP by using a ``connection-count''. o Can be accessed from applications via BSD sockets. Services offered : - nim-xact(src-eid, src-loc, dst-eid, dst-loc, callback, cookie, xact-len, xact-data, flags) - nim-xabort(cookie) 3. UPDATE PROTOCOL o Purpose : Convey data for updating distributed database contents. - Map database. - Locator database. - Adjacency database. o Protocol Operation - Multiple agents over multiple nodes. - One agent originates Update Message (UpdMsg) transit agents participate in distributing. - Reliable Transaction protocol provides hop-by-hop reliability, but NO end-to-end reliability is attempted, no ``state'', no ``acks''. - Sequence number used to handle duplicates. - Action of agent upon receipt of UpdMsg depends on Agent Type and Operation Type (OpType) : The Update Message Action Table (UMAT). o Update Header - org-agent. The type of agent originating the update. - dst-agent. The type of agents for whom the update is intended. - flags. Miscellaneous operation dependent flags. - db-type. The type of the database that is being updated. At most one kind of database can be updated with an update message. - seq-no. A 24-bit number that denotes the sequence number of the message with respect to the originating agent EID (and database?). - dst-scop. The scope of the destination. The update is not to propagate out of this scope. - org-eid. EID of the agent that issued the update. - org-loc. Locator of the agent that issued the update. - Sign. Authentication field. Contains the MD-5 signature of the agent originating the update. 4. QUERY-RESPONSE PROTOCOL Purpose: To retrieve or subscribe to database contents and release previously subscribed information. - Map request and release. - Route request. - Adjacency request and release. - Locator request and release. - Path information request. o Protocol Operation - Typically involves two agents (querier and responder). - A Query Message (QryMsg) is sent by querier identifying database information requested; a response message (RspMsg) is sent by responder containing requested database. - Originating agent client-protocol interactions: o InitiateQuery (client -> protocol) o AbortQuery (client -> protocol) o QueryFail (protocol -> client) - Action of agent upon receipt of QryMsg depends on Agent Type and Operation Type (OpType) : The Query Message Action Table (QMAT). o Query-Response header - org-agent. The type of agent originating the query/response. - dst-agent. The type of agents for whom the query/response is intended. - flags. Miscellaneous operation dependent flags. e.g., Authoritative - db-type. The type of the database that is being queried. At most one kind of database can be queried with a QRMsg. - count. Operation dependent. e.g., no. of routes. - opcode. In query, operation specific or database specific information; in response, zero if query can be responded to successfully, otherwise an error code indicating the reason for failure. - org-eid. EID of the agent that issued the query/response. - org-loc. Locator of the agent that issued the query/response. - Sign. Authentication field. Contains the MD-5 signature of the agent originating the query/response.   Received: from PIZZA.BBN.COM by BBN.COM id aa18017; 9 Aug 95 13:43 EDT Received: from pizza by PIZZA.BBN.COM id aa01090; 9 Aug 95 13:08 EDT Received: from TTL.BBN.COM by PIZZA.BBN.COM id aa01086; 9 Aug 95 13:06 EDT To: nimrod-wg@BBN.COM Subject: Stockholm IETF presentations Date: Wed, 09 Aug 95 13:01:42 -0400 From: Ram Ramanathan >3 Agent Discovery Protocol >Ram Ramanathan presented the agent discovery protocol. The slides of this >presentation will be posted to the mailing list. Here are the main points of my presentation in the Stockholm IETF, covering the following topics: 1. Agent discovery 2. Reliable transaction protoocol. 3. Update protocol. 4. Query-Response protocol. Please send your comments or questions to ramanath@bbn.com cc to the mailing list. - -Ram. - -------------------------------------------------------------------------- 1. AGENT DISCOVERY Purpose : Enables agents in a node to learn how to reach each other before all nodes are fully operational (i.e., bootstrapping). o Assumptions/Restrictions -- All inter-agent links are 2-way. -- All forwarding agents are connected to each other. -- Every agent is directly connected to a forwarding agent. o Protocol Features -- Periodic flooding of agent advertisements. -- Each agent maintains a next-hop-agent table. -- At the `end' of agent discovery o Every agent knows next-hop to reach every `key' agent (all agents except interior forwarding agents). o Route agent(s) have link-state information of entire topology and can construct a route to any other agent. o Protocol Operation -- Every agent generates an agent advertisement periodically containing: Agent type, EID, locator (if available), NID, list of neighboring agents and services offered on links to them, timestamp. -- Advertisements reliably flooded through the node. o Agent generating sends to each neighbor. o Only forwarding agents redistribute. -- When an agent T receives from an agent N an advertisement generated by an agent D, then o T checks that the timestamp is okay. o Creates/updates next-hop entry for D as N. o Only the FIRST next-hop learned is used. o If T is a route agent, then it updates its link-state -- If agents Q and R lose connectivity with each other, each o generates an agent advertisement. o generate an ``unreachability indication'' which is flooded as advertisements are. 2. RELIABLE TRANSACTION PROTOCOL o Provides its clients the ability to reliably communicate arbitrary sized blocks of information to a peer. o Built on Transaction-TCP (TTCP), RFC 1644, RFC 1379. o Bypasses 3-way handshake of TCP by using a ``connection-count''. o Can be accessed from applications via BSD sockets. Services offered : - nim-xact(src-eid, src-loc, dst-eid, dst-loc, callback, cookie, xact-len, xact-data, flags) - nim-xabort(cookie) 3. UPDATE PROTOCOL o Purpose : Convey data for updating distributed database contents. - Map database. - Locator database. - Adjacency database. o Protocol Operation - Multiple agents over multiple nodes. - One agent originates Update Message (UpdMsg) transit agents participate in distributing. - Reliable Transaction protocol provides hop-by-hop reliability, but NO end-to-end reliability is attempted, no ``state'', no ``acks''. - Sequence number used to handle duplicates. - Action of agent upon receipt of UpdMsg depends on Agent Type and Operation Type (OpType) : The Update Message Action Table (UMAT). o Update Header - org-agent. The type of agent originating the update. - dst-agent. The type of agents for whom the update is intended. - flags. Miscellaneous operation dependent flags. - db-type. The type of the database that is being updated. At most one kind of database can be updated with an update message. - seq-no. A 24-bit number that denotes the sequence number of the message with respect to the originating agent EID (and database?). - dst-scop. The scope of the destination. The update is not to propagate out of this scope. - org-eid. EID of the agent that issued the update. - org-loc. Locator of the agent that issued the update. - Sign. Authentication field. Contains the MD-5 signature of the agent originating the update. 4. QUERY-RESPONSE PROTOCOL Purpose: To retrieve or subscribe to database contents and release previously subscribed information. - Map request and release. - Route request. - Adjacency request and release. - Locator request and release. - Path information request. o Protocol Operation - Typically involves two agents (querier and responder). - A Query Message (QryMsg) is sent by querier identifying database information requested; a response message (RspMsg) is sent by responder containing requested database. - Originating agent client-protocol interactions: o InitiateQuery (client -> protocol) o AbortQuery (client -> protocol) o QueryFail (protocol -> client) - Action of agent upon receipt of QryMsg depends on Agent Type and Operation Type (OpType) : The Query Message Action Table (QMAT). o Query-Response header - org-agent. The type of agent originating the query/response. - dst-agent. The type of agents for whom the query/response is intended. - flags. Miscellaneous operation dependent flags. e.g., Authoritative - db-type. The type of the database that is being queried. At most one kind of database can be queried with a QRMsg. - count. Operation dependent. e.g., no. of routes. - opcode. In query, operation specific or database specific information; in response, zero if query can be responded to successfully, otherwise an error code indicating the reason for failure. - org-eid. EID of the agent that issued the query/response. - org-loc. Locator of the agent that issued the query/response. - Sign. Authentication field. Contains the MD-5 signature of the agent originating the query/response. ------- End of Forwarded Message   Received: from PIZZA.BBN.COM by BBN.COM id aa26406; 17 Aug 95 13:31 EDT Received: from pizza by PIZZA.BBN.COM id aa13897; 17 Aug 95 13:10 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa13893; 17 Aug 95 13:06 EDT Received: from ginger.lcs.mit.edu by BBN.COM id aa15948; 17 Aug 95 13:00 EDT Received: by ginger.lcs.mit.edu id AA11853; Thu, 17 Aug 95 13:00:02 -0400 Date: Thu, 17 Aug 95 13:00:02 -0400 From: Noel Chiappa Message-Id: <9508171700.AA11853@ginger.lcs.mit.edu> To: nimrod-wg@BBN.COM Subject: Partitioning Cc: jnc@ginger.lcs.mit.edu Pardon me for asking what may be a dumb question, but I don't have the energy to dig for this: what strategy is Nimrod going to use to deal with partitioning? Advertise the sub-pieces, or create a tunnel to tie them together? (Did I miss any?) Noel   Received: from PIZZA.BBN.COM by BBN.COM id aa09859; 21 Aug 95 17:55 EDT Received: from pizza by PIZZA.BBN.COM id aa02349; 21 Aug 95 17:33 EDT Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa02345; 21 Aug 95 17:28 EDT To: nimrod-wg@BBN.COM Subject: Nimrod node partitions Date: Mon, 21 Aug 95 17:34:13 -0400 From: Martha Steenstrup Hi Noel, Here is some information about partitions. Failure of physical assets in a Nimrod internetwork may lead to the partitioning of a Nimrod node, such that assets in one part of the node cannot communicate with assets in the other part of the node by traversing assets within the node. There are two cases. (1) A group of assets in a node are completely isolated from the rest of the internetwork. (2) No assets are isolated from the internetwork, but assets in one part of a node must use assets external to the node in order to communicate with assets in another part of the node. This second case is the more interesting, and the one we discuss below. A node's representatives detect node partitions of the second type, using information received through agent discovery. Specifically, each node representative tracks the reachability of all boundary forwarding agents and all node representatives. When a node representative detects that some boundary forwarding agents are no longer reachable, it concludes that the node has partitioned into multiple pieces. These multiple pieces of the same node are not new nodes. Each piece has the same locator and node id of the original node. However, each piece may have a different map. All node representatives within a given piece have the same knowledge of that piece of the node. A single mutually agreed upon node representative resident in that piece of the node may generates a map for that piece, if the loss of reachability of a boundary forwarding agent has resulted in a change in the node's map. Note that if the node representative cannot reach any boundary forwarding agents, there is no point in generating a new map for the node, because no one outside that piece of the node will be able to obtain the map. Representatives resident in each such piece of the node generate a different map for the node. These maps are distinguished by the endpoint id of the node representative generating the map and are distributed throughout the parent node. Route agents receiving these maps maintain multiple maps for the node. In fact, when generating routes that include the partitioned node, a route agent uses the node's maps as though they were constructed by different nodes. During a partition, when an endpoint in one piece of the node wishes to communicate with another endpoint in the same node, it may have to use a route that goes outside of the node. First, the representative acting on behalf of the source endpoint determines the locator and endpoint id of the destination endpoint (and its representative), using the name of the destination endpoint. If the source and destination locators are different, the source's representative then attempts to obtain a route (usually from a route agent in the parent node) to the destination. This route agent may need to ask each piece of the node for a more detailed map, containing its component nodes, in order to determine which piece contains the source and which piece contains the destination. Once it determines which pieces contain which session endpoints, the route agent can generate a route connecting them and passing through external nodes to do so. If the source and destination locators are the same, the source endpoint's representative determines whether it can reach the destination's endpoint representative, using information obtained through agent discovery. Only if it cannot reach the destination endpoint's representative, does the source endpoint's representative ask a route agent for a route. This route agent does not know which piece each resides in, and generates multiple routes, one from each of the two pieces of the node to the other. The endpoint representative can determine which route is feasible by attempting to set up paths; one path setup is likely to fail because an adjacent node will be unreachable. This trial-end-error setup, while not the most efficient, is reasonable, because we expect that nodes will seldom partition into more than two pieces. When the failed resources work again and the node partition disappears, a node representative generates a new map for the node. Maps generated during the partition might still exist in the route agent's map database after the partition disappears. These maps will eventually be removed from that database, because all maps have finite lifetimes. Moreover, the new map for the whole node is available for use immediately, and even the old maps are usable. The only drawbacks to keeping the old maps around for awhile are the storage space they consume, and the slight amount of extra work they cause during route generation.   Received: from PIZZA.BBN.COM by BBN.COM id aa12774; 21 Aug 95 18:39 EDT Received: from pizza by PIZZA.BBN.COM id aa02593; 21 Aug 95 18:18 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa02587; 21 Aug 95 18:16 EDT Received: from ns.Newbridge.Com by BBN.COM id aa27712; 21 Aug 95 18:21 EDT Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id SAA01201; Mon, 21 Aug 1995 18:21:33 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma001186; Mon Aug 21 18:21:26 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id SAA27388; Mon, 21 Aug 1995 18:21:24 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA03684; Mon, 21 Aug 95 18:18:22 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA24314; Mon, 21 Aug 1995 18:20:34 +0500 Date: Mon, 21 Aug 1995 18:20:34 +0500 From: Joel Halpern Message-Id: <9508212220.AA24314@lobster.Newbridge.COM> To: nimrod-wg@BBN.COM, msteenst@BBN.COM Subject: Re: Nimrod node partitions X-Sun-Charset: US-ASCII Content-Length: 2047 As I read your proposal, what it says can be paraphrased as: If a route agent sees several nodes with the same locator and different "representative endpoint ids", then it should treat them as a collective representaive, querying all of them any time it needs information from any of them. I understand the tradeoffs in that. I find the tradeoffs when this is then used to support inernal communication to be rather frightening. I think we can simplify it a little. Can we not assume that the route agent knows which piece the source is in, based on some information being passed in the query? (In other words, I think this would work better if there were enough information to do that.) Otherwise, in the case of multiple partition, the results would get hairy. I am also concerned, both for internal and external, about how this would work for "dumb"/"hierarchical" forwarding. It appears that all the packets with a target locator would probably end up in one partition, and never reach the destination if it is in a different partition. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS: At the beginning of your message, you say: " A node's representatives detect node partitions of the second type, using information received through agent discovery. Specifically, each node representative tracks the reachability of all boundary forwarding agents and all node representatives. When a node representative detects that some boundary forwarding agents are no longer reachable, it concludes that the node has partitioned into multiple pieces. " It is fortunate that this is irrelevant to the rest of your text, as it won't work. In many common partition cases the representatives will not know about the "missing" border elements. Take for example a power failure/restart, where some stuff in the middle died. Since everything is restarting, no-one knows who the borders are. I would hate to think that we were insisting on configuring the representatives with knowledge of the full set of borders!   Received: from PIZZA.BBN.COM by BBN.COM id aa06578; 22 Aug 95 15:20 EDT Received: from pizza by PIZZA.BBN.COM id aa07185; 22 Aug 95 14:49 EDT Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa07181; 22 Aug 95 14:47 EDT To: nimrod-wg@BBN.COM Subject: more about partitions Date: Tue, 22 Aug 95 14:52:47 -0400 From: Martha Steenstrup Hi Joel, I have a few comments in response to your note from yesterday. Paraphasing: Your paraphrase is not quite what I said. Rather, what I did say is that a route agent, upon receiving multiple maps of the same node from different node representatives, might need to obtain more detailed versions of one or more of these maps when constructing a route that includes the node. The route agent might query for these more detailed maps. That is the method described in the previous message. One could also mandate that a node representative, upon detecting a partition of its node that alters the node's map, automatically generates and distributes an abstract map of the node as well as a more detailed map containing component nodes if they exist. Both maps represent the node as perceived by the node representative that generated them. Note that a node might partition in such a way that even the detailed maps of the two node pieces appear the same. For example, this situation can occur if the node is composed of component nodes in a line, such that each component node has two connections to the neighbor nodes and the partition splits each node down the middle of these connections. In this case, each map includes the same component nodes connected in the same way. Route agent's knowledge of source location: The route agent might be able to determine which piece of the node the source is in, based on information passed in the route query and on detailed maps of the node pieces. There are a few different ways to accomplish this. (1) If a prefix of the source endpoint's locator matches a locator of a component node in the partitioned node and if that component node is contained in exactly one of the node's pieces, then the route agent itself can determine in which piece the source resides, using the detailed maps of the node pieces. (2) If the source endpoint's locator matches a locator of a component node in more than one piece of the partitioned node, then there are a couple of alternatives: (a) The source endpoint's representative is explicitly informed about the piece of the node containing the source endpoint. This means that information about the representative that generates a node's map trickles down to all endpoints in the node and in descendant nodes. The process is analogous to the process of updating the locators of endpoints when a change occurs in the locator of an ancestral node. An expensive procedure, and one to avoid, if there are other less expensive alternatives. (b) The source endpoint's representative learns the endpoint ids of all of the node's representatives reachable from it. This information is exchanged by agent discovery among agents acting on behalf of the same node. Assuming it knows the node representatives for the given node, the source endpoint's representative must be capable of one of at least three things. (i) It knows the algorithm the node representatives use to determine which node representative generates a map for a node and hence can determine the piece of the node to which it belongs, using the eid of that node representative. (ii) It can ask any reachable node representative for the eid of the node representative corresponding to the map piece. (iii) It relies on the route agent to determine which piece it is in, passing to the route agent the eids of all reachable node representatives and letting the route agent match these with its maps for the node pieces. Alternative (2.b.ii) is a reasonable alternative to trial and error. It requires the source endpoint's representative to query a node representative (for the eid of the node representative used to distinguish the piece of the node) only when the node appears to be partitioned from the endpoint representative's view (i.e., there is a change in the set of reachable boundary forwarding agents). So in this way, the source endpoint representative could find out which node piece it is in. Finding out where a destination lies within a partitioned node is more difficult, unless (2.a) holds and information about node pieces is injected into the DNS itself as part of an endpoint's locator. I'd rather not do this because of the amount of DNS updating activity it may cause. Hence, trial and error seems a reasonable alternative for learning in which piece of a node the destination resides, given that we don't expect a node to partition into a large number of pieces. Strict hierarchical routing: Using strict hierarchical routing to reach an endpoint in a partitioned node may cause messages to traverse longer routes than necessary. These messages should, however, reach their destination, provided the destination is reachable from the source. If the penultimate hop from the parent to the destination node happens to end up in the piece of the node containing the destination endpoint, then no extra work is necessary. If the penultimate hop is an unfortunate one, i.e. does not go the piece of the node containing the destination endpoint, then the forwarding agent receiving this message in the destination node must do some extra work. Specifically, it tries to set up paths to the other pieces of the same node, until it reaches the piece containing the destination endpoint or until there are no other pieces to try. Provided it can establish a path to the destination, it will use this path to reach the given endpoint, when it receives a data message containing the eid for the destination. Detecting partitions: I believe that the partition detection mechanism I described (i.e., detecting a change in the set of boundary forwarding agents reachable from a node representative) will work. Whether this partition causes a change in a map must be determined by the information available to the node representative. This information includes the maps of component nodes, if such nodes exist, and adjacencies to neighboring nodes. The case you describe - a node representative X fails, loses its memory of node state, and restarts - works just fine. Upon restarting, X learns, through agent discovery, the set of agents acting on behalf of its node. If there is another node representative Y for the node and X and Y are mutually reachable, X queries Y for node maps and adjacencies, in an effort to get its node state information up to date. If Y has node state, X updates its own state accordingly but does not attempt to form adjacencies or generate a map; these it simply gets from Y. If the boundary forwarding agents changed while X was down, Y or some other node representative would have already dealt with the potential partition. If Y does not have node state, X continues its initialization procedure. If it is the node representative responsible for making maps of the node, it attempts to form adjacencies with the neighboring nodes it has learned about through the boundary forwarding agents' advertisements received during agent discovery. After forming adjacencies, X distributes these to other node representatives. They all may make a map of the node, but only X distributes the map it makes. If, however, X is not the node representative that is supposed to be forming adjacencies and distributing maps, then it doesn't do anything more. A restart of a node representative is detected as a potential partition by that node representative, but is not necessarily acted upon as such, as described above. Moreover, one may, but is not required to, configure agents with the knowledge of other agents acting on behalf of the same node. All of this information may be learned through agent discovery.   Received: from PIZZA.BBN.COM by BBN.COM id aa12394; 22 Aug 95 16:17 EDT Received: from pizza by PIZZA.BBN.COM id aa07591; 22 Aug 95 15:51 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa07587; 22 Aug 95 15:49 EDT Received: from ns.Newbridge.Com by BBN.COM id aa09177; 22 Aug 95 15:51 EDT Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id PAA08515 for ; Tue, 22 Aug 1995 15:51:29 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma008509; Tue Aug 22 15:51:22 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id PAA21011 for ; Tue, 22 Aug 1995 15:51:21 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA10273; Tue, 22 Aug 95 15:48:18 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA24534; Tue, 22 Aug 1995 15:50:31 +0500 Date: Tue, 22 Aug 1995 15:50:31 +0500 From: Joel Halpern Message-Id: <9508221950.AA24534@lobster.Newbridge.COM> To: nimrod-wg@BBN.COM Subject: Re: more about partitions X-Sun-Charset: US-ASCII Content-Length: 2064 (I was going to send this just to Martha, but I figure if I am finding it confusing, then at least some of the readers of the list probably are too.) The question is partition detection. The scenario I imagined was one where an entire "node" A at some level of the hierarchy fails. When it comes back up, it has become partitioned internally. The node was multiply connected to the rest of the world, so there is a path between the two pieces outside the node. (As you note, in the absence of such a path it does not much matter what we do.) So, now representatives come up. It appears from your (Martha's) description that X "knows" that it is a node representative for A. Ok. It participates in agent discovery. If there is another node representative, Y, X and Y eventually talk to each other. But neither one knows that Z, a boundary forwarding agent, should exist and is missing. In fact, inside each partition no-one has knowledge of the missing people. Thus, I can not see how anyone would "know" about the partition. In addition, I will observe that the definition of partition detection seems to be equivalent to "A boundary forwarder failed". I would hate to think that we engaged in a complex "partition" algorithm every time a boundary forwarder failed. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS I don't know if it applies, but in PNNI we made use of the exterior connectivity to detect the partition. In particular, if node maps are distributed (flooded) among the higher level representatives, then the node representative producing the maps will see that there is another representative producing maps for the "same" node. A check of the known (discovered) elements of the node will show that the producer is not in the known node. That indicates an actual partition (subject to the dynamics/currency of the information). I would actually prefer an internally discovery mechanism such as Martha outlines, if someone would please convince me that it will work.   Received: from PIZZA.BBN.COM by BBN.COM id aa16706; 22 Aug 95 17:12 EDT Received: from pizza by PIZZA.BBN.COM id aa07962; 22 Aug 95 16:49 EDT Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa07958; 22 Aug 95 16:47 EDT To: nimrod-wg@BBN.COM Subject: partitions continued Date: Tue, 22 Aug 95 16:53:03 -0400 From: Martha Steenstrup Hi Joel, In your example of node A "failing" with all of its representatives failing, it does not matter whether representatives X and Y know about boundary forwarding agent Z. What does matter is that if node A changes (e.g., it partitions) such that its map changes, some node representative(s) will generate the new map(s) for node A. If X and Y fail and return to service, each will discover the other. Among the mutually reachable node representatives in the piece of the node containing X and Y, the node representative responsible for maps will generate and distribute a map for the piece of A it knows about. But with no previous state information available, neither X nor Y can know that Z is not there. This map generation is part of the normal procedure when a node representative returns to service, if it is the representative that is responsible for maps. In this case, the node representative does not detect a partition, but it does know that it has to generate a map. A change in a node, such as its initial formation, the temporary failure of some of its assets, or the addition of new assets, might change the map of the node. A node representative generates a new map (1) whenever it comes into service and detects that there are no existing maps of the node in any of the representatives; (2) whenever its locator changes; (3) whenever its connectivity specifications are reconfigured; (4) whenever it receives a map from a component node; or (5) whenever it detects a change in the set of nodes that are adjacent to it. Note that the new map generated might be the same as the previous map, if the event triggering map generation did not change the node from the perspective of its map. The loss of a boundary forwarding agent does indicate that the node partitioned, but it does not necessarily mean the map must change. In particular, if the boundary forwarding agent that failed is one in a set of several that participate in a single adjacency, then the node's map can remain the same. The "complex" partition algorithm that the node representative (responsible for maps) executes when it detects the loss of a boundary forwarding agent is a follows. First, the node representative checks to see in which adjacencies the boundary forwarding agent previously participated. For each of these adjacencies, the node representative updates the list of participating boundary forwarding agents and distributes it to all other node representatives and boundary forwarding agents it can reach within A. If the loss of the boundary forwarding agent also caused the loss of an adjacency, the node representative must now generate a new map, reflecting the new, reduced set of adjacent nodes and the corresponding connectivity specifications. (Note that the loss of a boundary forwarding agent may also be reflected in the maps of those component nodes of A that connect to the given boundary forwarding agent.) m   Received: from PIZZA.BBN.COM by BBN.COM id aa18487; 22 Aug 95 17:39 EDT Received: from pizza by PIZZA.BBN.COM id aa08153; 22 Aug 95 17:21 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa08149; 22 Aug 95 17:19 EDT Received: from ns.Newbridge.Com by BBN.COM id aa17539; 22 Aug 95 17:24 EDT Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id RAA12788 for ; Tue, 22 Aug 1995 17:24:10 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma012776; Tue Aug 22 17:24:08 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id RAA22711 for ; Tue, 22 Aug 1995 17:24:07 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA10855; Tue, 22 Aug 95 17:21:04 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA24570; Tue, 22 Aug 1995 17:23:17 +0500 Date: Tue, 22 Aug 1995 17:23:17 +0500 From: Joel Halpern Message-Id: <9508222123.AA24570@lobster.Newbridge.COM> To: nimrod-wg@BBN.COM Subject: Re: partitions continued X-Sun-Charset: US-ASCII Content-Length: 839 Then detecting the loss of the boundary forwarding agent (or of anything else) is an important function that has nothing to do with partition. The partition coping mechanisms are: 1) A way to ensure that one node representative will be producing the maps for the node. If this is always done dynamically, then it will simply work in the partition case. 2) Remote route agents may need to cope with receiving several maps of a node which represent different portions of a partitioned node 3) Possibly an enhancement to certain query mechanisms so that agents can determine what partition they are in and so identify themselves when asking for routes. (Or something related to allow the partition patching through external to work easily.) Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc.   Received: from PIZZA.BBN.COM by BBN.COM id aa18260; 23 Aug 95 11:24 EDT Received: from pizza by PIZZA.BBN.COM id aa11905; 23 Aug 95 11:03 EDT Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa11901; 23 Aug 95 10:59 EDT To: nimrod-wg@BBN.COM Subject: a small clarification Date: Wed, 23 Aug 95 11:04:27 -0400 From: Martha Steenstrup Hi Joel, At the risk of picking nits, here's an extra two cents. You state that: "detecting the loss of the boundary forwarding agent (or of anything else) is an important function that has nothing to do with partition". It has everything to do with partition. That is how (potentially map-affecting) partitions are detected by node representatives. Here is how I defined partitions in the original message in response to Noel's question: "Failure of physical assets in a Nimrod internetwork may lead to the partitioning of a Nimrod node, such that assets in one part of the node cannot communicate with assets in the other part of the node by traversing assets within the node." Thus, if a node representative can no longer reach a boundary forwarding agent by using assets in its node, that node is partitioned. Even if all assets of the node are working properly, except that one boundary forwarding agent, that node is said to be partitioned, according to the above definition of partition.   Received: from PIZZA.BBN.COM by BBN.COM id aa16700; 24 Aug 95 2:43 EDT Received: from pizza by PIZZA.BBN.COM id aa15881; 24 Aug 95 2:17 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa15877; 24 Aug 95 2:15 EDT Received: from ginger.lcs.mit.edu by BBN.COM id aa13114; 24 Aug 95 2:20 EDT Received: by ginger.lcs.mit.edu id AA07141; Thu, 24 Aug 95 02:20:44 -0400 Date: Thu, 24 Aug 95 02:20:44 -0400 From: Noel Chiappa Message-Id: <9508240620.AA07141@ginger.lcs.mit.edu> To: nimrod-wg@BBN.COM Subject: Graph theory Cc: jnc@ginger.lcs.mit.edu In all the recent discussion (elsewhere) about multi-homing, it has become clear to me that's there's another characterization of a graph which people who do routing need to think about. It's one which is, as far as I know, new; I've looked through "Distances in Graphs", by Harary, and didn't see it. (If I've reinvented something, please send me a reference! :-) I'm telling this mailing list since the people here seem more likely to appreciate graph theory arcana... That characterization is what I call "spacing" (alternate name glady accepted!), and it's a measure of how widely "spaced" the connectivity of a graph is; i.e. how far apart the connections of a node are to the fabric of the graph. It's important because I conjecture that routing overhead is more expensive in a graph with high spacing. More on all this below. First some formal definitions. "Spacing" is in some sense similar to the "degree" of a graph. For those of you who've not delved into graph theory, the degree of a node is the number of links to it. The degree of a graph is an average (for "non-regular" graphs, which have nodes of differing degree) of the degrees of all the constituent nodes, although this is a rough measure: more accurate would be a histogram of the degrees of the individual nodes. (A graph theoery term called "degree sequence" is essentially this histogram.) In similar fashion, the "spacing" of a node says something about how widely spaced its connections to the rest of the graph are, and one can define the spacing of the graph as a whole as either an average, or a histogram, etc, etc. The spacing of a single node (well, actually, of a single arc, to begin with) is defined as follows. Since the representation of a graph can be fairly plastic, one can't simply say "oh, that arc goes a long way", since one can redraw the graph to bring the node on the other end closer. However, if one considers the *shortest alternate path* between the nodes at either end of the arc, that is an exact, and useful (as we shall see) definition. One simply tries to find the shortest path betwen those two nodes which is *not* the one-hop path of that arc. One can thus speak of the spacing of one arc of a node; the spacing of the node as a whole (for nodes which have arcs of differing spacing) can be either an average, or, probably more usefully (because of it's effect on routing overhead cost, to be discussed), the maximum of the spacing of the individual arcs of the node. A graph as a whole would have a spacing sequence, or, more usefully to us, a spacing average. So, why is this important? Routing overhead is higher in graphs with high average spacing is higher, for a given measure of path optimality (remember that hierarchical routing results in paths which are, while not optimal, close to optimal, with a tradefoff between how close to optimal the paths are and how much routing overhead there is). This is easy to see: if I have regular NEWS graph (i.e. one of constant degree 4), the scope over which any given node has to be visible, to produce a given measure of optimality in the path, is quite small. If, on the other hand, one node has an extra arc with high spacing, to produce equally optimal paths to all destinations, information about destinations near one end of the arc will have to flow out to nodes near the other end of the arc, a routing load above and beyond the original. --> While adding the highly-spaced arc has made paths between many pairs --> of nodes shorter, it has done so at the cost of increased routing --> overhead. To look an another example, consider a multi-homed network. If it is singly homed, it can be given an address which is part of the area to which it is attached, and the extra routing load is minimal. If, on the other hand, it has two links, then it must be visible over a far larger scope (one that extends around both of the areas to which it is connected), with consequent high routing overhead costs. This is easy to see. For the multi-homing to be useful if either links fails, it has to be visible as a separate destination. (If this is not the case, but rather it is numbered as part of one area or the other, then if the linke from it that area fails, traffic to it will continue to go to that area even though that area no longer has a link to it.) Note that it does not have to be separately visible over a global scope, though; a smaller scope will do, one enclosing both locations to which it is connected to the rest of the graph. Exactly how much bigger the scope has to be is controlled by how optimal one wishes the routes to be; if the scope is minimal, traffic for that destination may head to the wrong part of the enclosing abstraction before arriving at the scope border, from whence it does take a more optimal path to the destination. It is important to realize, however, that multiply-homed sites represent just one class of thing which produce high-average-spacing networks; there are others. The real networks we tend to build will probably have high average spacing. The reason is that in a large network with low average spacing, most node pairs will be separated by long paths (although, as previously discussed with Ohta-san, exactly how average path length is reduced as highly-spaced links are introduced is hard to predict). This is probably undesirable, but maybe not. Even if the switches are not cut-through, the store-and-forward delay added by each additional switch adds a minimum extra (packet_length/transmission_speed) delay (plus queueing delays), but as transmission speeds go up, these are pretty minimal. E.g. with 1 Kbyte packets, a 1 Gbi/sec links, that's 8 usec per switch, hardly a killer when we have SOL delays, coast-to-cost, in the 20 msec range; S&F delays in 1000 switches will only up that by 50%. Anyway, I was going to say more about high average spacing networks, and their effect on routign overhead, but I have run out of brain cells completely at this hour. More later. Noel   Received: from PIZZA.BBN.COM by BBN.COM id aa10091; 24 Aug 95 10:13 EDT Received: from pizza by PIZZA.BBN.COM id aa17344; 24 Aug 95 9:50 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa17340; 24 Aug 95 9:46 EDT Received: from ns.Newbridge.Com by BBN.COM id aa08301; 24 Aug 95 9:50 EDT Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA21396 for ; Thu, 24 Aug 1995 09:50:11 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma021380; Thu Aug 24 09:50:03 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id JAA06495 for ; Thu, 24 Aug 1995 09:50:03 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA23983; Thu, 24 Aug 95 09:46:58 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA24972; Thu, 24 Aug 1995 09:49:12 +0500 Date: Thu, 24 Aug 1995 09:49:12 +0500 From: Joel Halpern Message-Id: <9508241349.AA24972@lobster.Newbridge.COM> To: nimrod-wg@BBN.COM Subject: Re: Graph theory X-Sun-Charset: US-ASCII Content-Length: 1319 Noel sent a note to the Nimrod list suggesting that a notion of Nodal Spacing might me helpful in thinking about topology. I agree that the concept seems useful. However, I can think of two ways of look at it that are a little different. 1) A node whose removal partitions the graph has infinite spacing. This is probably a little bit drastic. 2) Related to the above, I think that spacing is really only significant relative to the topology hierarchy. That is, what really matters is the number of levels upwards one must go to enclose the set of arcs. compare two cases, all of them for Node A inside Node X: A) Node A has connections to nodes B and C. Due to a very strange internal topology, the path between B and C goes through 8 routers, but it is all within X. The "spacing" of A could be said to be "X". B) Node A has connections to nodes B and C inside X. B has a connection to a node Y outside X, and C has a connection to node Z, also outside X. Y and Z are connected. The path between B and C is only two hops, but the spacing must be large enough to include X, Y, and Z. This is because the hierarchy was drawn differently. Have I misunderstood your concept? Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc.   Received: from PIZZA.BBN.COM by BBN.COM id aa03037; 24 Aug 95 15:13 EDT Received: from pizza by PIZZA.BBN.COM id aa18945; 24 Aug 95 14:51 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa18941; 24 Aug 95 14:50 EDT Received: from ginger.lcs.mit.edu by BBN.COM id aa01656; 24 Aug 95 14:55 EDT Received: by ginger.lcs.mit.edu id AA09299; Thu, 24 Aug 95 14:54:37 -0400 Date: Thu, 24 Aug 95 14:54:37 -0400 From: Noel Chiappa Message-Id: <9508241854.AA09299@ginger.lcs.mit.edu> To: jhalpern@newbridge.com, nimrod-wg@BBN.COM Subject: Re: Graph theory Cc: jnc@ginger.lcs.mit.edu From: Joel Halpern A node whose removal partitions the graph has infinite spacing. Umm, yes, that's true. (How clever of you to notice it! :-) On the other hand, I'm not sure how likely that is in a real network (except in the common case where you have a stub area with only a single link to the rest of the graph). Stub areas represent no challenge to the routing (in terms of the load) since they can be aggregated with whatever they join up to. Bit of a bug in the definition, really! Related to the above, I think that spacing is really only significant relative to the topology hierarchy. You mean the abstraction hierachy? The topology can be perfectly flat, in which case there is no topology hierarchy. That is, what really matters is the number of levels upwards one must go to enclose the set of arcs. In the abstraction hierarchy, yes. But, of course, when setting up the abstarction hierarchy, presumably one would organize it so as to globally minimize the scopes needed to enclose multi-homed portions of the topology... A) Node A has connections to nodes B and C. Due to a very strange internal topology, the path between B and C goes through 8 routers, but it is all within X. The "spacing" of A could be said to be "X". (Well, 10, actually, since that's the distance from A to C if the direct link to C is down (1 to B, and 9 links from B to C) and the same for A to B, no?) The concept was really only defined for ordinary graphs. I did that because I wanted to think about what the fundamentals were of how such connectivity patterns affected routing overhead, etc, etc. Yes, unless you impose a hierarchical naming structure, and hierarchical routing, you don't see any effect; i.e. flat routing in a graph with high average spacing is going to cost more or less the same as flat routing in a graph with low average spacing. It's only in the hierarchical case that a high spacing starts to effect you, by expanding the scopes over which lower-level aggregates have to be visible. Which leads me to some of my conjectures which I forgot last night because I ran out of brain cells. For one, it would be interesting to go back and look at Kleinrock+Kamoun's results on routing overhead and path non-optimality with this idea in one's head. I wonder if their results implicitly assume low or high average spacing for their graphs, or what? I'm not enough of a mathematician to see if one could build on their work to provide the results for graphs with varying spacing, but I'll bet there is a relationship. For another, for a graph of a given size, both diameter and average path length ought to be lower for graphs with higher average spacing. I suspect the results that people have obtained for the average values of these in random graphs are in effect the values of these for median values of average spacing; graphs with either higher or lower spacing ought to have different averages. Of course, most real-world networks are not totaly random, and probably do not have the same average spacing value as a true random graph.... B) Node A has connections to nodes B and C inside X. B has a connection to a node Y outside X, and C has a connection to node Z, also outside X. Y and Z are connected. The path between B and C is only two hops, but the spacing must be large enough to include X, Y, and Z. Urrrmm. I'm not sure what you're using the term "spacing" for in that last sentence; it's just a measure of how far apart in the graph a node's arcs connect to the graph. So, A has a spacing of three, since the *minimum* path from A to C (if the A-C link is down) is three, and vice versa for A to B. The links to Y and X don't come into it since they aren't on the minimum path. This is because the hierarchy was drawn differently. Are you trying to provide a case where the alternative minimum path from the subject node to the node at which the link whose spacing is being determined terminates leaves the area? (E.g, above, if the path betwen B and C inside X is longer than the path from B to C via Y and Z?) As I said, the spacing is still the same (as I have defined it), since it is only defined in pure graph terms. The imposition of an abstraction hierachy on a graph does not change the graph properties of that graph. It may have an effect on the routing, depending on where you set the abstraction ation boundaries, etc, etc, etc. Have I misunderstood your concept? Yes and no, apparently... Did the reply help? Noel   Received: from PIZZA.BBN.COM by BBN.COM id aa19477; 26 Aug 95 12:54 EDT Received: from pizza by PIZZA.BBN.COM id aa27783; 26 Aug 95 12:36 EDT Received: from BBN.COM by PIZZA.BBN.COM id aa27777; 26 Aug 95 12:33 EDT Received: from ginger.lcs.mit.edu by BBN.COM id aa19142; 26 Aug 95 12:38 EDT Received: by ginger.lcs.mit.edu id AA20887; Sat, 26 Aug 95 12:38:55 -0400 Date: Sat, 26 Aug 95 12:38:55 -0400 From: Noel Chiappa Message-Id: <9508261638.AA20887@ginger.lcs.mit.edu> To: nimrod-wg@BBN.COM Subject: Graph theory... Cc: jnc@ginger.lcs.mit.edu From: jnc@ginger.lcs.mit.edu (Noel Chiappa) I have discovered, while musing about this spacing stuff, that there's another, and more important bug, with the definition I gave: The spacing of a single node (well, actually, of a single arc, to begin with) is defined as follows. ... if one considers the *shortest alternate path* between the nodes at either end of the arc, that is an exact, and useful .. definition. One simply tries to find the shortest path betwen those two nodes which is *not* the one-hop path of that arc. Well, not quite. Consider the case where a node has 4 arcs; one pair of them joins the graph at places one hop apart, and the other pair does the same... except the spots are separated by a large number (n) of hops. In this example, the spacing of any arc is two, since the shortest alternate path is simply one hop to the neighbour node which is the termination of the other arc of the pair, then one hop over that arc. Saying those arcs all have a spacing of two is clearly wrong; that nodes has very widely separated connectivity. So, it seems that the definition needs to be either i) the average of the shortest paths between the nodes at either end of the arc, one path for (and including) each of the other arcs from the node being considered, or ii) the maximum of the shortest paths for each of the other arcs. Either one would be useful in characterizing what this measure attempts to characterize, which is how "non-local" the graph is, since the more a graph has this characteristic, the further routing information will have to spread to allow a given degree of optimality in the paths, etc, etc. (When one calcuates the spacing of the node as a whole, either by taking the max of the spacing of each arc, or averaging the spacings of all the arcs, these two variants of the arc spacing do not lead to the same number if you use the latter definition of the node spacing.) Exactly what the best definition is (the average, or the max) remains to be seen; I expect it will be whichever is more useful in routing theory, which I suspect will be the max, since that's the one that controls how far the information has to spread to provide a given degree of optimality in the routing. Noel   Received: from PIZZA.BBN.COM by BBN.COM id aa11229; 2 Nov 95 10:38 EST Received: from pizza by PIZZA.BBN.COM id aa03618; 2 Nov 95 9:52 EST Received: from BBN.COM by PIZZA.BBN.COM id aa03614; 2 Nov 95 9:46 EST Received: from ietf.cnri.reston.va.us by BBN.COM id aa03955; 2 Nov 95 9:31 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11586; 2 Nov 95 9:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: nimrod-wg@BBN.COM From: Internet-Drafts@cnri.reston.va.us Reply-to: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-nimrod-dns-01.txt Date: Thu, 02 Nov 95 09:16:53 -0500 Sender: cclark@cnri.reston.va.us Message-ID: <9511020916.aa11586@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the New Internet Routing and Addressing Architecture Working Group of the IETF. Title : DNS Resource Records for Nimrod Routing Architecture Author(s) : M. Patton Filename : draft-ietf-nimrod-dns-01.txt Pages : 5 Date : 11/01/1995 This document describes two additional RR types for the Domain Name System[7,8] required to implement the Nimrod Routing Architecture[1]. These RRs record the Nimrod Locator and an Endpoint Identifier (EID) associated with a given Domain Name. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nimrod-dns-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-nimrod-dns-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-nimrod-dns-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951101102134.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-nimrod-dns-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nimrod-dns-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951101102134.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from PIZZA.BBN.COM by BBN.COM id aa02673; 2 Nov 95 14:18 EST Received: from pizza by PIZZA.BBN.COM id aa04995; 2 Nov 95 13:47 EST Received: from BBN.COM by PIZZA.BBN.COM id aa04991; 2 Nov 95 13:45 EST Received: from ginger.lcs.mit.edu by BBN.COM id aa27519; 2 Nov 95 13:27 EST Received: by ginger.lcs.mit.edu id AA21456; Thu, 2 Nov 95 13:27:45 -0500 Date: Thu, 2 Nov 95 13:27:45 -0500 From: Noel Chiappa Message-Id: <9511021827.AA21456@ginger.lcs.mit.edu> To: nimrod-wg@BBN.COM Subject: Re: I-D ACTION:draft-rfced-info-corson-00.txt Cc: jnc@ginger.lcs.mit.edu You all might want to take a look at the following document (I have included an edited abstarct as well): Title : Architectural Considerations for Mobile Mesh Networking Author(s) : S. Corson, S. Batsell, J. Macker Filename : draft-rfced-info-corson-00.txt Pages : 20 Date : 11/01/1995 This memo describes the problem of routing and resource reservation in mobile mesh networks and presents architectural recommendations necessary for Internet protocols to operate effectively in these environments. ... The routers are free to move randomly; thus, the network's wireless topology may change rapidly and unpredictably. ... Next, it focuses on routing and concludes that highly adaptive, multipath routing is necessary for congestion avoidance in mobile networks. It then focuses on the process of route selection and reservation setup and advocates an integrated approach for supporting quality-of-service-based delivery in the presence of congestion. I don't agree with all of it, but I think it's worth looking at. Noel   Received: from PIZZA.BBN.COM by BBN.COM id aa15515; 27 Nov 95 17:11 EST Received: from pizza by PIZZA.BBN.COM id aa25533; 27 Nov 95 16:28 EST Received: from BBN.COM by PIZZA.BBN.COM id aa25529; 27 Nov 95 16:22 EST Received: from ginger.lcs.mit.edu by BBN.COM id aa13473; 27 Nov 95 16:29 EST Received: by ginger.lcs.mit.edu id AA14553; Mon, 27 Nov 95 16:29:18 -0500 Date: Mon, 27 Nov 95 16:29:18 -0500 From: Noel Chiappa Message-Id: <9511272129.AA14553@ginger.lcs.mit.edu> To: nimrod-wg@BBN.COM Subject: Another good reason for explicity/unitary routing... Cc: jnc@ginger.lcs.mit.edu To: ... cidrd@iepg.org Subject: Re: CIDR Aggregation Tool From: Enke Chen I can see that aggregation at transit provider level is useful, but it is dangerous and could easily cause connectivity problems if not done with coordination. This person is right, of course - in a hop by hop routing system. In a system using explicit/unitary routing (the latter is the original term I used in the old Nimrod document, but the former one, dreamed up the SDRP guys, is something I like better, maybe we should formally adopt the former) it's not so bad, *especially* if the underlying information distribution is a map-based system (i.e. not a vector of routing-table entries). Getting your abstraction action boundaries wrong in an MD system just means "big deal, some people have too little/too much information in the basic map" (remember that in Nimrod, at least, you have the option of using incoming abstraction control to explicity ask for more topology detail). One more reason that MD is clearly the way to go... Noel   Received: from PIZZA.BBN.COM by BBN.COM id aa27847; 28 Nov 95 21:53 EST Received: from pizza by PIZZA.BBN.COM id aa03553; 28 Nov 95 21:12 EST Received: from BBN.COM by PIZZA.BBN.COM id aa03549; 28 Nov 95 21:08 EST Received: from ietf.cnri.reston.va.us by BBN.COM id aa25960; 28 Nov 95 21:14 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18223; 27 Nov 95 10:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: nimrod-wg@BBN.COM From: Internet-Drafts@cnri.reston.va.us Reply-to: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-nimrod-eid-00.txt Date: Mon, 27 Nov 95 10:36:50 -0500 Sender: cclark@cnri.reston.va.us Message-ID: <9511271036.aa18223@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the New Internet Routing and Addressing Architecture Working Group of the IETF. Title : Endpoint Identifier Destination Option Author(s) : C. Lynn Filename : draft-ietf-nimrod-eid-00.txt Pages : 4 Date : 11/22/1995 This document describes a Destination Option that is used to convey topologically independent endpoint identification information between source and destination endpoints in either IPv4 or IPv6 packets. The general format of Destination Options are described in [5]. The Nimrod Routing System [1] will make use of this option to convey Nimrod EIDs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nimrod-eid-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-nimrod-eid-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-nimrod-eid-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951122180402.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-nimrod-eid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nimrod-eid-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122180402.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from PIZZA.BBN.COM by BBN.COM id ab24296; 5 Dec 95 19:19 EST Received: from pizza by PIZZA.BBN.COM id aa10391; 5 Dec 95 17:04 EST Received: from KARIBA.BBN.COM by PIZZA.BBN.COM id aa10383; 5 Dec 95 16:58 EST To: nimrod-wg@BBN.COM Subject: Nimrod WG Meeting Date: Tue, 05 Dec 95 17:05:09 -0500 From: Isidro Castineyra There will be no Nimrod WG meeting this IETF. Apologies for the delayed notice, but there was a scheduling misunderstanding. Isidro   Received: from PIZZA.BBN.COM by BBN.COM id aa14645; 6 Dec 95 11:38 EST Received: from pizza by PIZZA.BBN.COM id aa15257; 6 Dec 95 10:57 EST Received: from BBN.COM by PIZZA.BBN.COM id aa15253; 6 Dec 95 10:54 EST Received: from wd40.ftp.com by BBN.COM id aa12564; 6 Dec 95 10:59 EST Received: from ftp.com by ftp.com ; Wed, 6 Dec 1995 10:59:21 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 6 Dec 1995 10:59:21 -0500 Received: from kasten.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA16657; Wed, 6 Dec 95 10:56:15 EST Date: Wed, 6 Dec 95 10:56:15 EST Message-Id: <9512061556.AA16657@mailserv-D.ftp.com> To: isidro@BBN.COM Subject: Re: Nimrod WG Meeting From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: nimrod-wg@BBN.COM Cc: jhalpern@newbridge.com Sender: kasten@mailserv-d.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed Dec 6 10:56:10 1995] Originating-Client: d-cell.ftp.com Content-Length: 519 > There will be no Nimrod WG meeting this IETF. Apologies for the > delayed notice, but there was a scheduling misunderstanding. Isidro and Nimrodians... This is very unfortunate. There is no small amount of grumbling that nimrod is simply vaporizing. The lack of any significant discussions on the mailing list and the apparent lack of significant participation by any major router vendors has already reduced the 'believability' of NIMROD. Cancelling the meetings has hurt even more. -- Frank Kastenholz