Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / MISC / MERIT / NOOP / TUTORIAL / IDRP.TUT < prev next >

Wrap

Text File | 1992-01-21 | 42.7 KB | 885 lines

IDRP Tutorial By Susan Hares (MERIT) Introduction ------------ Out of the fertile ground of the Internet and the traditional ANSI subcommittees has sprung an OSI Inter-Domain Routing Protocol (IDRP). This protocol is officially called "Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs (CD 10747)". This paper provides an overview of the IDRP protocol in terms of its architecture and features. No attempt has been made to describe the format of packets or state machines. These details are better left to the protocol document. Charlie Kunzinger (IBM), the editor of the ISO IDRP document, has kept this document readable, and deserves a lot of thanks for his efforts. IDRP has progressed along the standards track to Committee Draft (CD) ballot. CD Ballot is the second stage in the ISO standards process. This stage is similar to "Proposed Internet Standard" status in the IP Internet world. The current protocol description is firm foundation for implementation but, like all standards at the Committee Draft level, IDRP is still open to possible technical changes. Merit demonstrated a prototype implementation of the IDRP during INTEROP 91. Experience with the prototype has been fed back into the IDRP specification. For additional information about the IDRP prototype, please contact Merit (email address:nsfnet-info @merit.edu). Special thanks go to Charlie Kunzinger (IBM), the editor of IDRP, whose ten pages of overheads were turned into this document. Thanks are also due to Dave Katz (Merit) and Yakov Rekhter (IBM) who reviewed this document extensively. Architectural Overview ====================== OSI Routing Environment ------------------------- The OSI routing environment is described in ISO TR 9575 [1] as a set of interconnected Routing Domains (RDs). RDs are groups of hosts and routers that operate according to the same routing plan and are administered by a single authority. Routing domains interact with each other in a "mutually suspicious manner" [1] due to their mutual independence and autonomy. Routing domains may each have their own view of what constitutes an optimal route. The OSI routing environment does not require that all routing domains have homogenous criteria (policy) about how to select an optimal route. In many ways a routing domain is like an Autonomous System in the 1 IP Internet [2]. Routing information passed within a routing domain (Intra-Domain) is trusted. Routing information passed between domains (Inter-Domain) may not be trusted. IDRP provides a means to communicate routing information and to calculate routes between routing domains. IDRP does not require that all routing domains have homogeneous criteria (policy) for route selection[3]. Routing knowledge needs to be spread throughout an internet in some ubiquitous manner if packets are going to reach their destinations. However, the independent and autonomous status of routing domains within an internet work against providing homogeneous routing information. In this environment, some routing domains (such as NSFNET) need to carry traffic on behalf of other routing domains. Routing domains that carry traffic on the behalf of other routing domains are known as Transit Routing Domains (regional networks and backbone networks, for example). Since a routing domain has only a finite amount of resources, it must control on how these resources are used. For example, NSF does not want to subsidize XYZ Corporation by allowing the commercial traffic from XYZ Corporation to go across NSFNET. To control what traffic passes through NSFNET, NSFNET controls what routing information it accepts and transmits. By using this control, NSFNET does not carry the commercial traffic for XYZ corporation. In an atmosphere, in which each routing domain needs to control the traffic passed through it by controlling the dissemination of routing information, one RD may filter the routing information it receives from another RD. By filtering the routes, a routing domain keeps only the routing information needed to do its job. A routing domain may also filter what it sends to other RDs so that only certain pathways are used. In addition, configurations are set up to authenticate the remote peer sending the information. This filtering and authentication creates a "firewall" to keep each routing domain independent of other routing domains. Routing domains whose policies do not permit them to carry transit traffic are known as End Routing Domains. End Routing Domains may be further subdivided into those connected to a single adjacent RD (Stub) and those connected to multiple adjacent RDs (multi-homed). In figure 1, C is a transit routing domain and B is a multi-homed routing domain. Routing domain A is a stub routing domain. Routing domain A is adjacent to routing domain C. ---------- ------------ ------------ | RD A |--------------| RD C | | RD D | | (stub) | | transit |------------| transit | ----------- ------------ ------------- | | \ / \ / \ / ---------------- | RD B | | multi-homed | --------------- 2 Figure 1 - Routing Domains Inter-Domain Routing Goals --------------------------- IDRP is designed to provide for the deterministic selection of paths through the OSI environment (internet) taken by network layer packets. Included in the design criteria for IDRP are the ability to: - scale well to a growing internet, and - allow transit routing domains to transit traffic. Additionally, IDRP assumes that the OSI environment (internet) may face multiple cuts to the topology of the network. Therefore IDRP provides routing that adapts to the topological changes (at the Inter-Domain level). When a protocol scales well, it will make efficient use of network bandwidth and the processing and memory within routers. IDRP was designed to fit into the OSI stack without affecting the existing network layer protocols. These protocols are: CLNP - Connectionless Network Layer Protocol (ISO 8473) [3] ES-IS - End System to Intermediate System routeing exchange protocol (ISO 9452) [4] IS-IS - Intermediate System to Intermediate System Intra-Domain Routeing protocol (ISO 10589) [5] IDRP does not require either ES-IS or IS-IS in order to operate properly. The only requirement placed on the intra-domain routing environment is the presence of stable paths between border routers in the same RD participating in IDRP (for the forwarding of transit traffic) and the presence of stable paths to and from end systems within the routing domain (for the forwarding of traffic originating or terminating within the local RD). IDRP was not designed to provide user data security, to adapt routes based on traffic load, or to repair partitions of routing domains. Multiple Qualities of Service ----------------------------- The OSI connectionless network layer protocol (ISO 8473) allows a network packet to request several qualities of service (QOS). This QOS is similar to types of service (TOS) in IP. These QOS values allow a packet to be "colored". IDRP supports the calculation of separate paths for each of these different qualities of service by means of Distinguishing Attributes [5], thus allowing paths or routes to be "colored". When an ISO 8473 packet comes into a router, the router will check to see if the packet has been "colored" by QOS. If so, the router looks up the destination address in the appropriate 3 QOS's routing table. The IDRP protocol specifies a mapping between the QOS values (packet's "color") and an IDRP inter-domain pathway (the route's "color"). If no QOS value has been set, the default routing table is used. Most of the Internet will probably start out having only a "default" QOS (or colorless pathway). Packets without any QOS (colorless packets) may be able to travel much further than "colored" packets. If a pathway of the right QOS (color) is not available, the packet is dropped. The CLNP QOS function or an IDRP QOS pathway does not have to be supported by each system in the pathway. However, each system must correctly handle a packet with a QOS value set. For example, suppose a particularly miserly end system wanted to send a packet along pathways which had minimal costs. He would set the "Expense" bit (perhaps like a green color) in the network layer packet and shove the packet out the door to a router. If IS-IS is used within a routing domain, the local routing domain would pass the packet on a low expense route until it hit a router on the border of the routing domain. This border router would check in its routing tables to find a route which had low expense. If it found one, the miserly end systems's packet would speed along low cost routes. If a route was not found, the packet would be discarded and an Error PDU would be passed back to the miserly end system. Given that our miserly end system did not want to spend lots of money reaching the destination, this behavior makes the end system happy. If the miserly end system must spend the money to send this packet, it can switch to a route with no QOS set (colorless) when it receives the ERROR PDU. (Figure 2 - Miserly Packet example goes here. Note figure two is only available in the postscript version. The figure is available for anonymous ftp from merit.edu. The file is located in /pub/iso/noop/tutorial/idrp.f02.ps) Scope of QOS ------------- The "color" of a packet (QOS) or route (Distinguishing Attribute) has a scope. The scope may either be specific to: - a source address (a route may have scope for a group of source addresses), - a destination address (a route may have scope for a group of destination addresses), or - a globally unique QOS such as the Expense flag. Two types of "color" for the packet or route (QOS and Distinguishing Attributes) deal with source addresses: Source Specific QOS and Source Specific Security QOS. Two types of "color" deal with destination addresses: Destination Specific QOS and Destination Specific Security QOS. To indicate a globally unique QOS value, a value is set in the header of a CLNP (ISO 8473) packet in an option field. For example, the packet from our miserly end system would have a bit set that indicates "Expense" QOS. The "Expense" Distinguishing Attribute which IDRP maps to the "Expense" QOS has a value which 4 indicates how expensive each route is. However, the meaning of that "Expense QOS" value may be valid only within an RD or a set of RDs. Global availability or agreement on the colors of "packets" or routes will probably take a great deal of coordination in the Inter-Domain realm. Today's Internet is built on such coordination between networks. The current policies on how routes are passed in the Internet are implemented in router configurations in lots of networks. For the scope of a "color" or a packet (QOS) or a route (Distinguishing Attribute) to truly be global, many countries may have to agree on the exact syntax and meaning of a "color". For example, NSF currently limits any traffic passing across the NSFNET to being non-commercial and in support of research and education. This type of policy restriction may be illogical within Japan or Australia. If our miserly packet was from a University, it could find a "golden" pathway that was the research pathway through the US. But when it hit the US border, the definition of what this "golden" pathway means may simply not apply to Canada or Japan or Australia or imply something different within those countries. Protocol Overview ================== A router that participates in inter-domain routing (and thus runs the IDRP protocol) is known as a Border Intermediate System (BIS). A routing domain may contain one or more BISs. A BIS uses policy to select among the routes it receives. In order for the IDRP protocol to work, all the BISs within an RD must have a reliable and consistent picture of how to route packets. To minimize the network bandwidth and processing power used by IDRP, IDRP must help control the amount of information passed. The next sections stroll through the features provided by the IDRP protocol. Architectural Place of IDRP ---------------------------- IDRP is part of the suite of routing protocols for in the OSI Network Layer, and runs over the OSI Connectionless Network Layer Protocol (CLNP ISO 8473). IDRP describes how PDUs are exchanged between BISs, how routes are constructed, and how protocol errors are handled, but the choice of how routes are selected is left to the local BIS's policy. BIS PDUs are passed between BISs within a domain and between BISs in different routing domains. IDRP is a Path Vector Method Protocol ------------------------------- IDRP is a "path vector" protocol, which is neither a distance vector nor a link state protocol. The distance metric of a distance vector protocol is not required. Unlike a link state protocol, the full topology and explicit link status are not distributed. In a "path vector" protocol, the routes distributed contain a complete path to the source of the route. Such a protocol provides the following: 5 - a vector of path attributes, - one route to destination for each QOS value, - excellent information hiding/abstraction and - provides for hop-by-hop routing. Inclusion of path information allows more rapid convergence than classic distance vector protocols and eliminates the "count to infinity" problem. IDRP Information Flow ---------------------- IDRP operates between pairs of BISs as shown in figure 3. Similar to the BGP protocol in the IP Internet, IDRP is used between BISs within the same routing domain so that the entire RD has a consistent picture of inter-domain routing. -------- --------- | RD A | | RD C | | BIS|\ ----------- /|BIS | | BIS | \ | RD B | / ---------- --------- ---------|BIS BIS|--- | /|BIS BIS|\ ----------- | | ----------- \ | RD E | --------- | \---|BIS | | BIS BIS|----------|-------------------| | | RD D | | ----------- | BIS BIS|\ -------- ---------- \ -----| BIS | | | RD G | | -------- ----------- | BIS | | RD F | ----------- Figure 3 - Routing Domains connected by BISs IDRP allows each BIS to control routing information passed on to other BISs. Only routes which satisfy the local policy of a BIS and have been selected to be to be used will be passed on to the next BIS. IDRP exchanges routing information between BISs within a domain and between adjacent BISs in adjacent routing domains. Since IDRP routing updates are incremental, routing traffic between BISs are minimized. The heaviest flow of traffic comes when a BIS first becomes operational. The BIS must establish a connection to other BISs in its RD and adjacent RDs. Routing information must be sent from the adjacent BISs to this new BIS. A BIS's route re-calculation is partial and event driven (only newly arrived routes need to be evaluated). The events which cause route re-calculation are: - a BIS receives an incremental routing update with new routes, - a BIS neighbor goes down, or - a BIS neighbor comes up. 6 Loop Suppression in IDRP ------------------------- The richly interconnected Internet topology provides the opportunity to construct paths that form loops. However, IDRP will never construct looping paths because it keeps track of all RDs traversed by a route. If a BIS sees its own RD in a route advertised by a BIS in another RD, it will ignore that route. Routing Domain Identifiers -------------------------- IDRP uses a Routing Domain Identifier (RDI) to uniquely identify a Routing Domain. The Routing Domain Identifier is taken from the same address space as the Network Service Access Point (NSAP) addresses. RDIs are drawn from the NSAP address space solely to simplify administration; no relationship should be inferred between the value of an RDI and the NSAP addresses resident within the RD. IDRP Path Attributes --------------------- Like BGP, IDRP defines a pathway as a pairing between a destination and the attributes of that path to the destination. A destination in IDRP is described by Network Layer Reachability Information (NLRI). NLRI contains groups of NSAP addresses described by NSAP prefixes. IDRP describes pathways through the morass of routing domains as ordered sequences of RDIs. For example, the pathway in Figure 3 between A and E could be A,B,E. In IDRP, the attributes of a path to a destination describe the characteristics of the path. Of these attributes, some are "Distinguishing attributes" and color the routes. Figure 4 shows which attributes can be listed together on a pathway. Like your mother when she gave you choices of vegetables, you can choose one from Group A, one from Group B and one from Group C. Unlike your mother, you also have the choice of "none", which is called "default" routing (no vegetables). Figure 4 - Possible Groups of Distinguished attributes Group A Group B Group C -------------- ---------- ----------------- -Transit Delay -Priority -Source Sensitive -Residual Error Security -Expense -Destination -Capacity Sensitive -Source Sensitive Security QOS -Destination Sensitive QOS Information Bases ----------------- For each unique combination of distinguishing attributes and destinations, there is local policy that affects the router. IDRP policy is akin to BGP policy. It is policy that is set by a routing domain administrator for a routing domain and expressed 7 in local configuration files on each node. The functioning of the "global" internet policy is the combination of all these "local" policies. Each BIS builds a Routing Information Base (RIB) based on routing information received from other BISs and from within the local RD. The RIB represents the set of routes that has been selected for use by the BIS. Each remote BIS neighbor sends a BIS its RIB for each unique set of distinguishing attributes. For example, if a BIS supports an expense attribute (for our miserly network user) and a route with default QOS, a Routing Information Base will be sent for expense QOS and for default QOS. This routing information contains only the active routes selected by the neighbor. The local BIS, upon receiving this information, uses local policy to select the routes, and updates its RIB. From the RIB the BIS generates a Forwarding Information Base (FIB). The FIB effectively contains a set of destinations and next hop BISs for each destination. Upon the loss of a BIS neighbor, the local BIS will re-run the route selection function. The local BIS will use local policy to select among the routes from the remaining neighbors, update its RIB, and generate a new FIB. Routing Domain Confederations ----------------------------- A Routing Domain Confederation (RDC) is a group of routing domains that join together in such a way that they appear to be a single routing domain as viewed from outside the RDC. The only common policy that must be supported among the members of the RDC is that all routes between members of the RDC must lie entirely within the RDC. RDCs provide a powerful mechanism for reducing the complexity of routing information, since the details of the internal topology of the RDC are hidden from those domains outside the RDC. In addition, the size of the RD path information carried by IDRP will be reduced. RDCs can overlap and/or be nested. Figure 5 shows 6 RD organized into 3 RDCs. RDCs A and B overlap. RDC C is nested inside of RDC B. Routing Domain Confederations - Figure 5 6 RDs, organized into 3 Routing Confederations -----------------| | RDC A -------|-----------------| | | RDC B ------------ | | | |RDC C | | | RD1--|---RD4----|-------RD6| | | / | | / \ | / | | | | | | | \ | / | | --|---|---| | ----RD5 | | RD2 RD3-|-| |----------| | |------------------------- How IDRP provides Scaling 8 -------------------------- IDRP provides good scaling by a variety of mechanisms. Three types of information can be abstracted or hidden: Network reachability information, topology information, and transit policies. Topology information is expressed in terms of RD pathways to the remote destination. The abstractions IDRP provides are comforting in the face of an expanding internet. This abstraction of data will lessen the routing information that is passed around. Less bandwidth devoted to routing means there is more bandwidth for the internet's real purpose- sending data from here to there. "Hiding" by Use of OSI NSAP Structure -------------------------------------- Network reachability information can be abstracted or hidden by using the hierarchical nature of the NSAP address to group NSAPs under shorter NSAP prefixes. Such prefixes are carried in IDRP routes. Figure 6 shows an example of how several addresses are combined into a shorter prefix. A part of an NSAP address used to describe a group of NSAP addresses is called an NSAP Prefix. Figure 6 - Combination of NSAPs into a Prefix 47.0005.80.ffff00.0000.0001.0001.010203040506.01 47.0005.80.ffff00.0000.0001.0002.80ff32401f23.01 47.0005.80.ffff00.0000.0001.0003.800103040500.01 could be represented by one of the following prefixes, among others (going from most specific to most general). 47.0005.80.ffff00.0000.0001 or 47.0005.80.ffff00 or 47.0005 or 47 Sets of RDs Compress RD Pathway (Topology) Information ------------------------------------------------------- In combination with the use of NSAP prefixes, RD path information can abstracted from an ordered sequence of RDIs to an unordered set of RDIs. Although some information is lost, the automatic loop suppression mechanism in IDRP is preserved. For example, if paths to two destinations have RD paths A,B,C and A,B,D, the single unordered set A,B,C,D could be used and a single path created. This abstraction may allow multiple routes to be aggregated based on the policies of a routing domain. RDCs allow Compression of Pathway Information and Policy -------------------------------------------------------- Topology information can be abstracted using the IDRP concept of Routing Domain Confederations. RDCs provide a nice means for scaling. Fewer policies need to be administered by other routing domains. Fewer total routes need to be reported to the world outside the RDC. Inside an RDC the policies are exploded to serve the needs of RDs within the Confederation. The IDRP protocol can distinguish between intra-RDC and trans-RDC routing information. In addition, transit policies may be implemented in the presence of an RDC via the "Hierarchical Recording" feature. Transit policies can also be abstracted by using RDCs. RDCs can 9 be nested, allowing policy for several routing domains to be summarized as a single policy of a Routing Confederation. Taming the Shrew -Reducing the Information Flow in Policy Routing ----------------------------------------------------------------- In the play by William Shakespeare, "Taming of the Shrew," a husband seeks to tame a head-strong wife. The wife has a strong verbal flow and a stronger temper. He accomplishes this task by taming himself and the wife. The wife learns that ranting and raving can be more effective if it is truthful, used sparingly, and directed at the right person. RFC 1104 describes the same sort of global taming for the Internet. The Internet, like the wife, has a strong flow of information which must be tamed by correct policies in order to let packets peacefully flow. Routes, like "ranting and raving," must be directed at just the right routing domains. IDRP provides a taming or reduction of routing information and processing via control of the distribution of information. Only the actual routes that are selected to be used by a BIS are propagated to other routing domains. Like what "truth in advertising" should be for home appliances, the BIS only advertises what it uses. We should have the same restriction on those people who sell vacuum cleaners or coffee makers. Each RD may also select the set of RDs to which its routes are distributed. In this way, transit routing policies are supported via control of the distribution of routing information. Again, to use the analogy of home appliances, a company could choose to not ship chain saws to someone under 16 years of age. Route selection processing is also reduced because routes are selected based on routes received (actual routes only) plus the local BIS's policy, which can further reduce the number of routes. The IDRP attributes "DIST_LIST_INCL" and "DIST_LIST_EXCL" give routing domains the means to select the routing domains that will receive their routing information. The "DIST_LIST_INCL" allows routing information to be sent to RDIs listed in the attribute. "DIST_LIST_EXCL" allows routing information to be sent to any RDI not included in the attribute list. An RDI in one of these attributes can specify either a routing domain or a routing domain confederation. The use Routing Domain confederation (RDCs) also helps tame the flow of routing information needed. The "Hierarchical Recording" attribute helps track when RDCs have been entered and exited so routes can limited to within an RDC. Once a RDC has been entered and the "Hierarchical Recording" attribute is set, routes can be advertised only to BISs that can be reached without exiting any RDCs. An RDC can be nested within an RDC or overlap another RDC. Routes can be announced to RDs: - within the same RDC, - in an RDC nested in side this RDC, or - or in an overlapping RDC. This establishes a Hierarchy of RDs as you enter further into nested or overlapping RDCs and controls route transitivity. 10 Disjoint RDCs are RDCs which can only be reached by exiting all routing confederations in which this local BIS resides. The "Hierarchical Recording" attribute cannot be passed between two Disjoint RDCs. Interaction with Intra-Domain routing ------------------------------------- IDRP may need to interact with intra-domain routing if it is running in an RD that contains end systems. First of all, IDRP needs to know the set of NSAP prefixes reachable within the local routing domain. This information is likely to be statically configured information, and not extracted dynamically from intra-domain routing. Secondly, a representation of the destinations reachable outside of the RD may be injected into intra-domain routing so that the appropriate exit BIS can be reached. This information may be provided to intra-domain routing in a dynamic fashion. Both of these interactions can be accomplished by the manipulation of managed objects via network management primitives. Reliability built into IDRP --------------------------- Like the truck ads that say "Ford tough", the IDRP protocol is built to be "internet tough". All communications between peer BISs can be protected through the use of a cryptographic signature on a per-packet basis. Unlike BGP, IDRP implements its own reliable transport. Each data-carrying packet (BIS protocol data unit (PDU)) contains a sequence number which is used for re-transmission and flow control. Data-carrying PDUs are the OPEN PDU (which contains the connection information), the UPDATE PDU (which contains incremental routing information), and the RIB REFRESH PDU (which contains routing information). A retransmission timer controls the retransmission of packets. The method of flow control is a window scheme. This scheme only allows a fixed number of BIS PDUs to be transmitted to a remote BIS neighbor prior to the local BIS receiving an acknowledgement. Especially Neat Features of IDRP -------------------------------- Thanks to the rich technical environment of the Internet, the contributors to the IDRP specification have put in several neat features to make it work even better than BGP. Two of these features which have made it into the current CD ballot version of the document are: 1.) A BIS playing route server for another router 2.) RIB Refresh PDU Some features which are under discussion but not in the CD ballot are: Auto-configuration of BISs and Source-based routes. 11 The Route server function in IDRP allows one BIS to do policy and handle the BIS PDUS but point to another router to do the packet switching. Suppose your BIS was running on a slow packet pusher (perhaps a unix system running "gated"). With the route server you can point your data flow to a fast packet pusher of a router (say one of the commercially available routers) and traffic would not be impacted by the IDRP protocol running on a slow machine. (figure 7 - Route Server. Figure 7 is only available in postscript. The figure is available for anonymous ftp from merit.edu in the directory /pub/iso/noop/tutorial the file is idrp.f07.ps) By using a RIB REFRESH PDU, a BIS may refresh its Routing Information Base (RIB) from a neighbor BIS or to send its active routing information to a neighbor BIS. If a router detects that its routing information has been corrupted, it can get fresh IDRP routing information from all its neighbors. Or perhaps something convinces the BIS (or the person operating the router) that a neighbor BIS has scrambled the routing information advertised by the local BIS. The local BIS simply ships the remote BIS a new copy of the RIB. Auto-configuration of BISs involve the methods by which BISs can communicate with each other without having to pre-configure each neighbor BIS. This feature could make it easier to add new BISs to an RD without having to reconfigure all other BISs. Each network packet (NPDU) has a source and destination field just like a good old IP packet. Source-based routing establishes routes based on both source and destination addresses. Source-based routing may help "commercial" traffic take a different route than "research" traffic or provide two different routes to the same destination, each tagged for a different set of source addresses. Conclusion ----------- IDRP reminds one of "Stone soup". "Stone soup" is described in a children's fairy tale in which three soldiers return from a war and no one in the village wants to give them any food. They start with 3 stones in a pot of water. By the end of the tale, the villagers have added all the vegetables, meat and potatoes you could ever want. IDRP started with the concepts of BGP and the OSI routing framework. These two original concepts are like the "stones" in the "stone soup." To this beginning, the experience and needs of the Internet community and the ANSI X3S3.3 communities have been added to make IDRP one OSI protocol full of "meat" and substance. IDRP has already followed the tradition of Internet protocols by having a prototype developed by Merit during the CD ballot stage. Nothing improves a protocol like an implementor. Often implementors cannot wait until they "talk" to the person that 12 wrote a protocol specification. This dialogue is most painful when you are both implementor and the person that helped with the original text. Perhaps this tutorial has given you an appetite to read the protocol and any associated documents. Below you will find a reading list to help you fill up on OSI routing issues. Bon appetit! References [1] "Information processing systems - Telecommunications and information exchange between systems - OSI Routeing Framework" (ISO TR 9575) [2] "RFC 1136 - Administrative Domains and Routing Domains: A Model for Routing in the Internet" (Hares/Katz) [3] "Information processing systems - Telecommunications and information exchange between systems - Protocol for Providing the Connectionless-Mode Network Service" (ISO 8473) March 1987 [4] "Information processing systems - Telecommunications and information exchange between systems - End System to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing connectionless-mode network service (ISO 8473)" (ISO 9542) March 1988 [5] "Information processing systems - Telecommunications and information exchange between systems - Intermediate system to Intermediate System Intra-Domain Routeing Exchange protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589, forthcoming Reading List --------------- RFC 1136 RFC 1237 RFC 1195 Tutorials on the ISO routing documents [3], [4], [5], found on merit.edu in the /pub/iso/noop/tutorial. The actual ISO documents [1], [3], [4], [5], and IDRP. Working copies of IS-IS, and IDRP can be found on merit.edu for ANSI X3S3.3 committee work in the /pub/iso directory. ANSI X3S3.3 notes and mail archives on IDRP. The ANSI X3S3.3 archives are on merit.edu. The ANSI X3S3.3 mail list is x3s33@merit.edu. 13