DRAFT Nimrod Software Architecture DRAFT 950526 DRAFT Nimrod Software Architecture DRAFT Contents 1 Overview 2 Nimrod Agents 2.1 Endpoint Representative 2.2 Route Agent 2.3 Node Representative 2.4 Forwarding Agent 2.4.1 Packet Forwarding 3 Domain Name System 4 Common Nimrod Services and Protocols 4.1 Query/Response Service 4.2 Update Service 4.3 Communications Library 4.4 Reliable Transaction Service 4.5 Nimrod Packet Forwarding 4.5.1 Forwarding Service 4.6 Route Generation Service 4.7 EIDs 4.8 Locators 4.9 Security 5 Bibliography i DRAFT Nimrod Software Architecture DRAFT 1 Overview In a Nimrod internet, Nimrod software will be run on both general purpose computing platforms such as PCs and workstations as well as on special purpose platforms such as routers and servers, from a variety of vendors. However, not all platforms will need to support the full range of functions described in the Nimrod Architecture [1] and Functionality [2] documents. The software architecture must make it straight forward for the vendors to move Nimrod code to their often proprietary environments, possibly by porting code from a reference implementation or by developing code directly from the Nimrod Functional Specification [5]. Thus the usual architectural goals of a clean, modular design with clear inter-module interfaces becomes even more important. Nimrod functionality may be categorized into a collection of databases, agents that both maintain and provide requested information from those databases, and various support modules that provide the communications and other services the agents need to perform their tasks. Low level packet forwarding and discovery mechanisms are also required. This document uses the paradigms of layering, client-server, message passing, and events. Implementors may cast the software architecture described here to other paradigms that may be more suitable to their target platform(s). This software architecture assumes the presence of several services. They include an IP protocol stack with the usual protocols, i.e., IP, Authentication, Confidentiality, ICMP, TCP, and UDP, and the related support services of DNS, Key Management, and Network Management, e.g., SNMP. Figure 1 illustrates this layering and a high level breakdown of the required functionality into databases, agents, and modules. The transitional mechanism of encapsulating Nimrod datagrams in IP places the Nimrod packet forwarding services on top of the IP forwarding layer. Native Nimrod forwarding would appear parallel to the IP layer, e.g., as a new version of IP. There are several databases associated with Nimrod neighbor discovery, agent discovery, and forwarding. There are also some extensions to the IP layer to support Nimrod neighbor and agent discovery, and to assist endpoint representatives in their task of intercepting traffic from an endpoint. Functionality associated with Nimrod endpoint identifiers (EIDs) appears above the security services but below the traditional transport protocols such as TCP and UDP. The basic Nimrod services provided to the Nimrod agents consist of a communications library containing the update protocol and query/response protocol, both based on the reliable transaction protocol, and a generic mechanism used to communicate between applications and operating system (when such a mechanism is required). The reliable transaction protocol is based upon Transaction TCP (RFC 1644). These services take the form of libraries used by the Nimrod agents and use a call and event triggered callback paradigm. This 1 DRAFT Nimrod Software Architecture DRAFT o--------------------------------o o-----------------oo-----------------------o | Node Representative | | Route Agent || Endpoint API | o-------o--------o------o--------o o----o---------o--oo-----------------------o |Locator| : : : | Map | Map | : : |Route Gen| : |Endpoint Representative| |& Assoc| : : : |Abstrn| Filter | : : o---------o : o-----------------------o | DB | : : : o--o---o----o---o : : : : : : : : : : : : : : : o-------o : : : : |Abs|Filt| : : : : : o----------o : : : : : : : : : : : : |DB | DB | : ...:.:..: : | Route DB | : : : : : : : : o---------o : : : o---o----o : : : : : o----------o : : : : : : : : |Adjacency| : : o----------------o : : : o-------------o : : : : : : : | DB | : : | Map DB | : : : | Endpoint DB | : : : : : : : o---------o : : o----------------o : : : o-------------o : : : : : : : : :................... : : : o------------o : : : : : : o--------------------o : : : : | End-to-end | : : : : : : |Map & Locator Update| .........:.: : : | Session DB | : : : : : : o--------------------o : : : : o------------o : : : : : : .....................:..:........:...:.....:....................: : : : : : : : : ......:...:.....:......................: : : : : : o----------------o : : : : : : ......................: : : : : | Forwarding | : : : : : : : : : : : | Agent | : : : : : : : o----------o------------o : : : o----------------o : : : : : : : |DNS Server|DNS Resolver| : : : : o-------o : : : : : : : : o--------o-o----o-------o : : : : | SNMP | :...:..:..:.... : : : : : : |DNS DB| : : : : : : | Agent | : : : : : : : : : : o------o : : : : : : o-------o : : : : : : : : : :........ : : : : : : : :.......:..:..:...:.:...:.....:..:.....:......... : : : : : : : : : : : : : : : : : : : : : : : : : : o--------oo------------------o : ....:.:..: : : : : : : | Update || Query/Response | : : : : : : : o----------------o o--------oo------------------o : : : : : ....: : | Application/ | | Communications Library | : : : : : : : | Nimrod Control | o----------------------------o---------oo----------oo----o | Interface | | Transaction + TCP || UDP ||ICMP| o----------------o o----------------------o---------------oo----------oo----o : | EID + Multiplexing | : o-----------o-----------------o---o : : | Confidentiality | : : o---o------------o----o : : | Authentication | : : o---------------------------------------------------o--------o-------o : : | Nimrod Control + Forwarding | : : : : o----o------------o-------------------o-----oo-----oo---o----o : o-----o : : : | Path Setup | : : : : : |Flood||Agent||Nbr| : : | Key | : : : o------------o : : : : : | DB || DB ||DB | : : | DB | : : : : : : : : : : : o-----oo-----oo---o : : o-----o : : : : : o------------o : : : o------------------------------------------o : : : : |Connectivity| : : : |Endpoint Intercept+ IP Forwarding | : : : : | Spec DB | : : o--o-----------------oo-----o-----oo---o------o : : : : o------------o : : |Network Interface DB|| IP | IP ||ARP| : : : : :................ : o--o--------------------o|Ucast|Mcast|o---o------o : :..:................. : : | Intercept Endpoint DB ||Route|Route||Link Layer| : : : : : o-----------------------o| DB | DB |o----------o o-------------------o o------------------o o-----o-----o |Forwarding Route DB| |Forwarding Path DB| Figure 1. Rev 7 o-------------------o o------------------o Combined Nimrod Protocol Stack 2 DRAFT Nimrod Software Architecture DRAFT permits operations of the Nimrod agents, and the likely multiple instances of an individual agent, to easily interleave their operations. The Nimrod agents (endpoint representative, route agent, node representative, and forwarding agent) use these protocols to communicate between themselves and other entities such as the domain name system (DNS). The agents use the communication services to maintain several databases, using algorithms that may be proprietary to a given vendor. 2 Nimrod Agents The software architecture for the individual agents is presented in the following sections. The update and query/response protocols used to support most inter-agent communication use the authentication (and integrity) security services. Each agent therefore has a key database that contains the necessary, possibly pre-configured, security association information. 2.1 Endpoint Representative There are two forms of endpoint representative, distinguished by whether or not the endpoint representative is coresident with the endpoint. The non-coresident case is used in the Nimrod Deployment Plan [6] to enable unmodified endpoints (hosts) to use Nimrod routing services. Traffic to and from the endpoint is passed through the endpoint representative, which removes or adds, respectively, Nimrod headers to packets using Nimrod services. Endpoint traffic that is not to use Nimrod, e.g., the communication peer is not Nimrod capable, causes an ICMP Redirect (host or possibly net) to be sent to the endpoint so that subsequent traffic to that peer is not routed through the endpoint representative. Note that since the endpoint representative functionality may be coresident with the network's exit router, care must be exercised when sending ICMP Redirects. Modifications to the IP forwarding layer are needed so that packets from the endpoint are passed up to the Nimrod forwarding layer instead of simply being forwarded by IP. The forwarding layer endpoint database contains information, i.e., the IP address(es), for each endpoint to be handled by the endpoint representative so that the relevant packets can be identified and processed. As an optional optimization, DNS queries from an endpoint can be examined so that associated Nimrod related queries can be initiated before arrival of peer to peer traffic. This is expected to reduce the setup latency of peer to peer communications. This function requires that DNS queries received by the IP layer in an endpoint representative be passed up to the agent module. 3 DRAFT Nimrod Software Architecture DRAFT Endpoints with a coresident endpoint representative, which includes all Nimrod agents since each Nimrod agent is an endpoint, do not need the IP layer modifications to intercept received endpoint traffic (unless also functioning as an endpoint representative for unmodified endpoints). Instead, packets being generated by the transport layer protocols need to be passed to the EID and Nimrod processing layers instead of simply being handed to the IP layer. This selection of next lower protocol layer is typically missing in standard IPv4 stacks. However, such a mechanism is required by both IPv6 and the new IPv4 security services, so we expect it to be available for use by Nimrod extensions. For either the coresident or non-coresident case, an endpoint representative is responsible for acquiring a locator for an endpoint it represents, determining the service specification appropriate for an endpoint's communications with its peers, initiating the path setup process by requesting feasible routes, and maintaining the endpoint databases. The locator acquisition process uses locator acquisition messages layered on the query/response and reliable transaction protocols. Acquired locators are entered into the endpoint database. Locator update messages received from node representatives may modify an endpoint's locator entry. The new locator information is also used to update the endpoint's DNS locator (NL) record(s). The endpoint representative initiates the path setup process for communication between an endpoint and its peers by requesting, when not already available in the local cache, any end-to-end route(s) suitable for a session. Having the endpoint representative request a route is intended to relieve the first hop Forwarding agent of the task of holding, or dropping when memory is scarce, endpoint packets while route generation is in progress. The endpoint representative accesses and updates the endpoint database. This database identifies the endpoints to be represented: their DNS name(s), scope, EID, locators, other location information, e.g., IP and link-layer addresses, and any pre-configured service specification, on a per peer IP address, protocol, and port basis. The endpoint representative also maintains a database of peer-to- peer associations and any associated end-to-end path labels or route specifications. The route specifications may be cached to reduce setup latency on subsequent peer to peer associations, or for failure recovery. 2.2 Route Agent Each route agent is responsible for generating feasible routes in response to route requests from the endpoint representatives, forwarding agents, or other route agents. A route agent may choose to pass a request to another route agent either to have another route 4 DRAFT Nimrod Software Architecture DRAFT agent fill in pieces of a route or to obtain more optimal routes from a route agent with more powerful route generation algorithms. Route generation messages use the query/response and reliable transaction protocols. In response to a route request, a route agent might have to request maps from appropriate node representatives, based on the endpoint location and service specification contained in the request. Maps received from node representatives may be cached in a map database and later used when generating subsequent routes as long as the map's lifetime has not been exceeded. The resulting routes, or route segments, are signed, returned to the requester, and optionally cached together with the service parameters of the resulting route in the route database for use in answering subsequent requests. The lifetime of these cached routes is based on the lifetimes of the maps from which they were generated. A route agent may be proactive by refreshing maps or routes that are expected to be needed or are about to expire. Note that the maps collected from node representatives are obtained based on the credentials of several agents: one or more endpoints, the requesting agent, and one or more route agents. Consequently there may be multiple versions of a node's map in the map database, and resulting routes in the route database, due to credential based filtering, e.g., distribution restrictions, that a node representative may have applied. In addition, there are different types of map for a node -- full versus abbreviated and complete versus partial, for a specified set of component nodes. A third source of multiple maps per node is a partioned node. In this case, route agents of the partioned node's parent node receive map updates originating from a node representatives in each partition (if one exists). Consequently, a route agent must deal with and properly handle multiple maps per node. The specific algorithms that are used to generate routes are not part of the Nimrod specification. It is expected that some vendors will develop proprietary algorithms. Route agents for a given node need not all use the same route generation algorithm. A node need not have an internal route agent, but the node's forwarding agents must be capable of reaching one using basic routing, possibly using pre-configured information. 2.3 Node Representative The node representative performs several functions. It builds the node's basic map from map updates received from component nodes via the update protocol. The basic map is then abstracted to form the node's abstract map. The abstraction process is based on a possibly vendor proprietary algorithms and an associated abstraction database that contains any pre-configured results or configurable parameters required by the abstraction algorithms. Note that a lowest level node has no component nodes and thus might produce an abstract map directly 5 DRAFT Nimrod Software Architecture DRAFT from configuration information. The abstraction algorithms produce the "full complete abstract" map of the node. Note that all node representatives for a given node are assumed to produce identical abstract maps, based on all receiving the same updates from component nodes. Thus all node representatives MUST be using the same algorithm and configurable parameters. Omission of the connectivity specification information from s full map produces the "abbreviated complete" map. There may be several "full partial" and "abbreviated partial" maps, depending on which set of component nodes are contained in the map, as specified by a map request received from a route agent via the query/response protocol. Node representatives respond to map queries received from other agents, e.g., route agents, based on the type of map requested, including the set of desired component node in the case of partial maps. The map returned is filtered based on any distribution restrictions found in the filtering database and the credentials of the endpoint representative, forwarding agent, and any route agents present in the map query. All maps given out by a node representative are signed. Some of the signatures may be cached, e.g., for the complete basic map and complete abstract map, while signatures for the other maps, which vary depending on the specific map query, will have to be generated as the maps are produced and, if desired, cached. Note that a map request query may specify that the requesting agent be notified when a map is updated. This functionality requires entries in the map database that identify the desired maps and requesters, i.e., the original map query. The agent discovery mechanisms permit the node representatives to detect (some forms of) a partioned node. When a node is partioned, the node representative(s) in each partion use pre-configured preferences to select a new designated node representative that will send map updates to the parent node's node representatives and route agents. Those node representatives in turn notify any other node representatives or route agents that have previously requested map updates. The locator acquisition process uses the query/response protocol. Information on the locators available for assignment, and the locators that have been assigned, and any rules or requirements used to decide whether or not a locator request should be honored are stored in the locator database in the node representatives. Retaining information about previously assigned locators is kept in order to reduce gratuitous locator changes that might otherwise occur when agents are rebooted or failed components are repaired. The ranges of locators available for assignment by a node representative must be coordinated between the various node representatives of a given node. The algorithm used by any particular node representative to assign 6 DRAFT Nimrod Software Architecture DRAFT locators from its free pool need not be the same for all node representative of a node. The node representative should keep track of those locators that have been assigned and/or released. It may be desirable to retain other location information for those nodes and endpoint representatives that have been assigned in order to simplify subsequent locator updates so that they can be sent directly to the affected agents without having to flood the updates throughout the whole node as flooding at high levels of the aggregation hierarchy does not scale well. When a node's locator changes, the locators that have been acquired by endpoint representatives and component nodes must also be changed. The update protocol is used to notify all Nimrod agents within a node (scope) of the changes. Information in the update specifies whether a locator should be added (as an initial step in renumbering), deleted, changed to a new locator, or have its preference changed. The preference of a locator allows a network administrator to specify a partial ordering of an endpoint's locators so that more desirable (from the administrator's perspective) locators may be tried first. Node representatives respond to adjacency requests received from other nodes during neighbor discovery via the query/response protocol. The decision whether or not to form an adjacency with another node is based on rules, requirements, and restrictions contained in the node representative's adjacency database. 2.4 Forwarding Agent Each forwarding agent records, for each interface, the Nimrod agents and their EIDs, locators, scope(s), and other location information, e.g., IP address and link-layer address, that are directly reachable through that interface. This information may be either pre-configured or learned from the neighbor discovery messages that are link-layer multicast, or sent point-to-point, to groups associated with the various agent types. The information is stored in the forwarding agent's neighbor database. It is then summarized and multicast back throughout the node to all forwarding agents that record in the agent database information about all agents within the node (scope), and to other agents so that agents of each type can identify other agents of the same type serving the same scope. This latter information is stored in the flooding database for each agent type. 2.4.1 Packet Forwarding The Nimrod forwarding layer in each Nimrod agent processes the Nimrod header. In the forwarding agents, this includes flow mode forwarding based on the path stack contained in the Nimrod header and information in the agent's path database, and processing any route 7 DRAFT Nimrod Software Architecture DRAFT specification in both flow mode setup and new datagram forwarding modes. Whenever a packet reaches the end of a path, the next segment of the route is processed. The forwarding agent first checks its path database to see if a path already exists to the next locator specified in the route, or some node in the hierarchy on the way to that locator. If so, the pre-existing path is used to either forward a datagram or setup the next path of a flow. If no pre-existing path meeting the given service specification is found, then one of three cases applies. If the packet has not yet reached the context (the lowest level common ancestor node of a set of locators), it is forwarded to a boundary forwarding agent of the node, i.e., up the aggregation hierarchy. If it has reached the context, but not yet the node containing the target locator, the boundary forwarding agent sends a route request, using the query/response protocol, to a route agent of the parent node, i.e., the context. Finally, if the packet has reached a parent of the target locator, if is forwarded to the next component node specified by the target locator, i.e., down the clustering hierarchy. Note that more complicated routing might cause a packet to exit the context, e.g., a node is partioned, etc. Whenever a forwarding agent received a response to a route request, it may cache the route specification and its associated parameters in the forwarding-layer route database. Subsequent packets that have compatible parameters may then use the cached route specification when either forwarding datagrams or setting up new flows. Forwarding agents must respond to queries requesting path information. These requests will typically be from route agents that are adding new members to a multicast group. When a Nimrod packet enters a node through one of the node's boundary forwarding agents, that agent has the responsibility of enforcing the node's traffic handling or service policy. The enforcement is based on validating the service specification in the packet against the node's policy as specified by information contained in the connectivity specification database. The agent might also check that the connectivity specification contained in a route is valid for the node and the traffic that is attempting to use it. Problems may be logged and or reported back so that a more suitable route can be used. Forwarding agents flood messages using the update protocol to all agents of a given type within a given scope. The information required to perform this function, collected during agent discovery, is maintained in the flooding databases. They also contain information about recent messages that have been flooded so that loops may be detected and broken. 8 DRAFT Nimrod Software Architecture DRAFT See also section 4.5 for more information on Nimrod packet forwarding. 3 Domain Name System Nimrod uses a DNS name, including the IP address form, as endpoint name. Two new DNS resource records, EID and NL, [12] will be used to hold EID and locator information. The DNS KEY resource records will also be used to hold authentication keys [14] for each Nimrod agent used to authenticate Nimrod inter agent communications. An endpoint representative will use the new DNS dynamic update service [13] to maintain the endpoint (DNS) name to locator(s) mapping. Note that any DNS signature (SIG) records [14] that cover the locator records will also have to be updated. 4 Common Nimrod Services and Protocols The agents described in section 2 make use of several underlying services. These services and the protocols that support them are described in this section. 4.1 Query/Response Service Nimrod agents obtain information from the various Nimrod databases using the query/response service. Each distributed database is maintained by a type of agent, with individual agents being responsible (authoritative) for different portions of the database. The inter-agent communication to support the query/response service uses the query/response protocol, the underlying communications library, and reliable transaction service. The query/response protocol has s simple state machine and is driven by a set of query/response message forwarding tables (QMFT) that describe how query/response protocol messages are to be processed and forwarded. Query/response message forwarding tables are described in the Nimrod Functional Specification [5]. Those services provided by the query/response service are adjacency request and release, locator acquisition and release, map requests, path database queries, and route generation requests. 4.2 Update Service Nimrod agents distribute information to other Nimrod agents using the update service. Updates are unsolicited. The inter-agent communication to support the update service uses the update protocol, the underlying communications library, and the reliable transaction service. The update service is driven by a set of update message forwarding tables (UMFT) that describe how update protocol messages 9 DRAFT Nimrod Software Architecture DRAFT are to be processed and forwarded. The update message forwarding tables are described in the Nimrod Functional Specification [5]. Those additional services provided by the update service are adjacency update, locator updates both to endpoint representatives and child node representatives, and map updates. 4.3 Communications Library The query/response and update services and their associated protocols are based on the services offered by the communications library. The library provides routines that provides its users with an event oriented message passing interface. For example, when sending a mending a query, the query is passed to the library along with a callback function that should be invoked to process the response. A library routine fills in the parts of message that are common to all messages, signs the message on behalf of the sending agent, converts the message to its network representation, if required, and lets the agent continue its operation while the message is feed to the underlying transaction TCP. Another library routine reads input from the transaction TCP until a whole message has been assembled, converts the message from the its network representation to that of the receiving system, if necessary, verifies the message's authenticity, looks up the pre-registered callback routine, and invokes that routine on the message. Agents that are to receive updates pre-register the routines that should be called to process the update. The query/response and update message forwarding tables are part of the communications library. They implement flooding of messages throughout a node or scope by automatically forwarding messages to other agents. Local agents are only notified when a message arrives that should be processed by a local agent. The communications library provides a timed callback services so that an agent may establish a timeout. The library contains a generic message parser and compose queries, responses, and updates. They are table driven based on the object type code that begins each object and can handle the variable length objects in an efficient manner. They handle optional objects by comparing the actual object type code with that defined for a given message. 4.4 Reliable Transaction Service The reliable transaction service permits its users to send a message to a peer and receive an optional reply. Both the message and any reply are communicated reliably, i.e., are retransmitted until correctly received or the application aborts the transaction. The 10 DRAFT Nimrod Software Architecture DRAFT reliable transaction service uses Transaction TCP (T/TCP), RFC 1644 [11], for communication between peers. Transaction TCP is a backwards compatible extension to the standard TCP that permits two peers using T/TCP to use a simple two packet exchange to send a request and receive a reply when there are no network related communication errors. If errors are encountered, the standard TCP protocol and retransmission mechanisms are used for error recovery. If only one of the communicating peers is using T/TCP, the behavior reverts to the multipile packet exchange of the standard TCP. The communications library and reliable transaction service add message framing, message identification, transactions numbers, a transaction timestamp, and sender identification to the underlying reliable communication provided by T/TCP. Each query/response or update use a separate TCP connection so that a delay or failure for one transaction blocks neither other transactions from a single agent or other agents in the box. 4.5 Nimrod Packet Forwarding Nimrod packet forwarding uses state information in the forwarding agents and information in a Nimrod header in the packets. When Nimrod is used in conjunction with IP networks, the Nimrod header appears as either a new "IP protocol" (in the sense that TCP is IP protocol 6) for IPv4, or as a new version of the IPv6 routing header. There are two basic forms of forwarding: new datagram mode, and flow mode. Both use common underlying path mechanisms. Flow mode causes flow specific path state to be installed in the path database of certain forwarding agents along the path. The flow state is established through the path maintenance protocol. Once installed, i.e., the path has been setup, only path label information is required in the Nimrod packet header of subsequent datagrams to be forwarded along the path. Any EIDs, locators, service specifications, or route specification that should be associated with a packet being forwarded using flow mode is only required during flow setup portion of the path maintenance protocol. New datagram mode is used to forward packets that do not require the fast and consistent message forwarding and resulting setup overhead and delay of flow mode. New datagram mode does not establish any additional session specific state in the forwarding agents, but makes use of any paths that have been otherwise established --- either in response to flow mode setups, setups due to observed traffic (including new datagram mode traffic) to or through a particular node, or setups due to network management directives. If there is no path that meets the specified requirements, a check is made for existing paths that might be used as the next segment of a path. If one is found it is used. Otherwise, either simple hierarchal routing is used --- up the hierarchy from the source, through nodes at the context, and down the hierarchy to the destination ---, or a session 11 DRAFT Nimrod Software Architecture DRAFT independent path may be setup. Any EIDs, locators, services specification, or route specification that should be associated with a packet being forwarded using new datagram mode must be carried in each packet. Note that this information is almost identical to the information contained in a flow mode setup packet, and the packet formats are essentially the same. The Nimrod packet header consists of five variable length sections; not all sections are present in a given packet. The first sections contains information contains the total header length and the stack of path labels used to forward Nimrod packets; it is always present. The second section is present in flow mode setup packets and new datagram mode data packets. It consists of common control information and any service specifications that must be met and a route stack of tuples containing endpoint EIDs, locators, a route specification, and a pointer into the route specification. The last three sections are only used in special circumstances. The third section is only present in some bootstrapping control packets; it contains recorded route information that is required for inter-agent communication before globally routable locators have been acquired. The last two sections are used for performance data collection. The fourth section is used when monitoring information is to be collected along the path taken by the packet. The fifth section is used when previously collected monitoring information is to be returned to the head of the path. The Nimrod Functional Specification identifies those header fields that are to be covered by authentication. 4.5.1 Forwarding Service Forwarding based on the path label stack in the Nimrod packet header makes use of information stored in the path database of the forwarding agents. When no path either applies or has not yet been identified, information in the route specification at the top of the route stack is used in conjunction with that in the forwarding agent's route database. When neither database contains appropriate information, and a path setup is required, a route request is sent to one of the node's route agents, which may be external to the node(s) containing the forwarding agent, using the query/response service. Note that this is a situation where a low layer service. i.e., Nimrod packet forwarding, makes use of higher layer services, i.e., query/response and reliable transaction, that in turn use the lower layer service. Special care is required in implementations to detect and break this potential dependency loop. The loop may be broken by using simple hierarchal routing to reach route agents external to the node or to a component node, while basic routing covers the case of routing to a route agent internal to a node. 12 DRAFT Nimrod Software Architecture DRAFT Nodes without internal route agents must be configured with routes to the external route agent(s) that use only basic routing. Note that routing up the hierarchy only requires that a forwarding agent in a node know how to reach a boundary forwarding agent of the same node. Similarly for routing down the hierarchy. No configuration is needed for these cases thus configuration for external route agents is only required when the external route agent is not in the direct hierarchy. 4.6 Route Generation Service Nimrod route generation is performed by route agents. The algorithms that a route agent uses to generate routes is not part of the Nimrod Specification and may be vendor specific or even proprietary. Endpoint representatives and forwarding agents use the query/response service to request route specifications from the route agents. The route agents in turn use the query/response service to request appropriate maps from node representatives. The route agents may also request notification of the availability of new maps from node representatives via the update service. 4.7 EIDs Nimrod endpoint identifiers (EIDs) are used to identify communicating endpoints independent of the place where the endpoint attaches to the network. This simplifies peer to peer communication when the attachment point of one or both endpoints changes while communication is in progress. The initial bits of an EID identify both that the object is an EID and the length of the EID. In the IPv6 environment, EID information used to support multiplexing at the transport layer may be carried in the Destination Options header. In the IPv4 environment, or alternatively for IPv6, the EID information is carried in the second section of the Nimrod packet header. 4.8 Locators Nimrod locators are used to identify nodes in the clustering hierarchy and places within those nodes where endpoints are attached to the internetwork. Locators are topologically significant and thus are subject to change when the internetwork topology changes. Locators consist of a set of elements, where each element generally corresponds to a node in the clustering hierarchy. The initial bits of a locator identify both that the object is a locator and the length of the locator. There are several forms of locator. The usual locator is one which is permanent, globally unique and routed at the top-most, universal node. They are the end result of locator acquisition throughout the internet. Each element in the locator is "permanent". 13 DRAFT Nimrod Software Architecture DRAFT Before the locator acquisition process has been completed, temporary locators may be used. They contain one or more temporary elements and are only valid within a limited scope, i.e., they are not globally routable. It is expected that there will be several internets. One is the global Internet from which the others are detached, i.e., outside of the global Internet's universe. It is recommend that the universe of these detached internets be given globally unique prefixes. This is done to allow interconnection, such as dialup, between the internets. There are some locator elements that are context sensitive, such as a locator prefix that generically represents one's parent. Another one can be used to indicate that a packet be multicast throughout a node at a particular location in the hierarchy. A multicast element may be expanded in the context of that location. An anycast element is also possible. In order to reduce the length of the Nimrod packet header, locators may be abbreviated by splitting them into two parts. The first is termed the context and is the common initial prefix (elements) of the abbreviated locators. Since the context is a proper locator prefix, it is itself a locator. The suffixes (remaining elements) of locators that are abbreviated have prepended to them initial bits that specify that the object is a locator suffix and the length of the resulting initial bits and remaining elements. Abbreviated locators are typically found in route specifications where the context is the common prefix of the source and destination locators. 4.9 Security Nimrod uses the integrity, authentication, and, where required, confidentiality security services for all inter-agent communication. The integrity and authentication services are provided by the IP Authentication Header [7] and associated procedures [8]. Confidentiality is provided by the IP ESP Header [9] and associated procedures [10]. In many cases, information passed between Nimrod agents is separately authenticated and signed by agents other than those between which the information is being passed. This requires that the security services be available at both the application, i.e., Nimrod agent, and network layers. The application layer services may be provided by library routines. When distribution restrictions are to be applied to information, it is essential that a confidentiality service be used as there is little to assure that Nimrod messages are protected from unauthorized disclosure by any other mechanisms. Establishment of suitable keys for this or any other purpose is not part of the Nimrod specification. 14 DRAFT Nimrod Software Architecture DRAFT The general security model in Nimrod is that the producer of each piece of routing information sign it, be it a map, a route, or a service offering. The signature is passed between agents along with the information. Thus the information may be authenticated by any consumer of the information. When information is combined, such as map aggregation, the new information is signed by the aggregator. All messages passed between agents are also signed so that the receiving agent may be assured that the received information is both intact and originated at the purported agent. Certificates are also used so that an intermediary may act on behalf of another party. 5 Bibliography [1] "The Nimrod Routing Architecture", Castineyra, Chiappa, Steenstrup, March 1995, draft-ietf-nimrod-routing-arch-00.txt [2] "A Perspective on Nimrod Functionality", Steenstrup, June 1994 [3] "Mobility Support for Nimrod : Requirements and Solution Approaches", Ramanathan, March 1995, draft-ietf-nimrod-mobility-01.txt [4] "Multicast Support for Nimrod : Requirements and Solution Approaches", Ramanathan, March 1995, draft-ietf-nimrod-multicast-01.txt [5] "Nimrod Functional Specification", [6] "Nimrod Deployment Plan", Lynn, January 1995 [7] "IP Authentication Header", Atkinson, April 25, 1995, draft-ietf-ipsec-auth-01.txt [8] "IP Authentication using Keyed MD5, Metzger, Simpson, April 1995, draft-ietf-ipsec-ah-md5-03.txt [9] "IP Encapsulating Security Payload (ESP)", Atkinson, April 25, 1995, draft-ietf-ipsec-esp-01.txt [10] "The ESP DES-CBC Transform", Metzger, Karn, Simpson, April 1995, draft-ietf-ipsec-esp-des-cbc-04.txt [11] "T/TCP -- TCP Extensions for Transactions, Functional Specification", Braden, July 1994, RFC 1644. [12] "DNS Resource Records for Nimrod Routing Architecture", Patton, April 1995, draft-ietf-nimrod-dns-00.txt [13] "Dynamic Updates in the Domain Name System (DNS)", Thomson, Rekhter, Bound, March 24, 1995, draft-ietf-dnsind-dynDNS-01.txt 15 DRAFT Nimrod Software Architecture DRAFT [14] "Domain Name System Protocol Security Extensions", Eastlake, Kaufman, January 2, 1995, draft-ietf-dnssec-secext-03.txt 16