Dec 13 13:59 1991 Page 1 NORDUNET CLNS RECOMMENDATIONS Version 0, 13.12.1991 Goeran Bengtson Havaard Eidnes Juha Heinanen 1. INTRODUCTION The NORDUNET CLNS project was started in 1990 in order to prepare the NORDUnet community for the support of the OSI Connectionless Network Service (CLNS). The project was motivated by the estimate that the number of CLNS capable intermediate and end systems will increase rapidly in our networks in 1991. One of the main reasons for the growing useage of CLNS is the recent release of DECnet Phase V. At the same time, the CLNS is becoming popular in the Internet community and within RARE. The project was therefore needed in order to gain early experience in CLNS and in order to give recomendations on its wide scale deployment within NORDUnet. A CLNS environment, also called an ISO Internet, consists of End Systems (ES) and Intermediate Systems (IS) connected by subnetworks. ESs and ISs must implement Connectionless Network Protocol (CLNP) (ISO 8473) that provides the CLNS (ISO 8348/Add. 1). In addition, ESs and ISs must implement the ES-IS routing protocol (ISO 9542) that works within a subnetwork and allows the ESs to find the ISs and vice versa. For larger scale routing, ISO TR 9575 defines an OSI routing framework that consists Areas, Routing Domains (RD), and Administrative Domains (AD). An Area consists of a set of connected ESs and ISs. RDs, in turn, consists of a set of areas connected via a backbone of ISs that implement the same intra-domain routing protocol. And finally, ADs consists of a set of routing domains managed by a single administrative authority (like NORDUnet). There exists a standardized intra-domain IS-IS routing protocol (ISO IS 10589) for routing within Areas and RDs. An inter-domain routing protocol (IDRP) for routing both within and between ADs is currently a committed draft (ISO CD 10747). As an intermediate solution, Cisco has implemented their own CLNP routing protocol, called ISO IGRP, which applies to both intra- and inter-domain IS-IS routing. The OSI routing framework reflects itself not only in the routing protocols, but also in the OSI network layer addressing. OSI network layer addresses are called NSAP (Network Service Access Point) addresses (ISO 8348/Add. 2). They are a maximum of 20 octets long and can be either subnetwork dependent (like X.121 addresses) or subnetwork independent (like ISO DCC (Digital Country Code) or ISO ICD (International Code Designator) based addresses). The latter are usually prefered in CLNS because their can be structured Dec 13 13:59 1991 Page 2 hierarchically according to the OSI routing framework. The report continues by first giving an NSAP recommendation to be applied within the NORDUnet followed by a recommendation on how to organize CLNS routing with the NORDUnet. After that we present a DECnet Phase IV to Phase V migration plan. Finally, we report on the experience gained from running the CLNS pilot and from participating in similar pilots both within the Europe and the US. Two appendixes are included that give practical instructions on configuring ESs and ISs in various environments. 2. NSAP RECOMMENDATION 2.1. Introduction This section gives a recommendation on how to allocate NSAPs for OSI systems (routers and hosts) both in the NORDUnet backbone and in the national networks. 2.2. Choice of the Address Family BSI recently granted NORDUnet its own NSAP prefix (0023) from the International Code Designator (ICD) space. At least in some Nordic countries the National Standards Organizations (NSO) have also already set up a procedure to allocate NSAPs to organizations from the Digital Country Code (DCC) space. NORDUnet is therefore facing the choice between two possible address spaces for its routers and hosts. Since the NORDUnet backbone is an international network, it is natural to allocate NSAPs for its routers from the NORDUnet ICD space. It is also advantageous to use the NORDUnet ICD space for national OSI systems participating in the global ISO Internet: - using NORDUnet ICD space allows NORDUnet to design a common NSAP format for all NORDUnet OSI systems thus making us independent of the (lack of) progress or decisions by the individual NSOs - NORDUnet is its own NSAP allocation authority - outside of NORDUnet and inside each Nordic country all NORDUnet OSI systems can be identified with a single prefix (47 0023) thus simplifying international and national routing Since it is not anticipated that the decision to use the NORDUnet ICD space for national NORDUnet OSI systems would cause any disadvantages, NETF CLNS WG recommends that the NORDUnet ICD space is used for all NORDUnet OSI systems. Although the use of the ICD space is the preferred choice, it is still, of course, possible that some NORDUnet OSI systems use the national DCC space for additional NSAPs or even as the only NSAP. In the latter case, however, the OSI system may not be able to participate in the global OSI Internet. Dec 13 13:59 1991 Page 3 2.3. NORDUNet NSAP Format NETF CLNS WG recommends that the NORDUnet ICD NSAP space is structured according to the Internet draft "OSI NSAP Address Format for Use in the Internet". Its straigthforward application to the NORDUnet ICD space results in the following NSAP format: AFI(1=47) IDI(2=0023) DFI(1=00) Admin Author(3) Reserved(2=0000) Routing Domain (2) Area(2) System(6) NSel(1) This format is the same as the US GOSIP Version 2 NSAP structure. If some NORDUnet OSI systems decide to use NSAPs from the national DCC space, then it is strongly recommended that the local part of the DSP is structured similarly as in the above NORDUnet ICD format. 2.4. NSAP Allocation in NORDUnet NSAPs should be allocated from the NORDUnet ICD space for the NORDUnet backbone and for all OSI systems within the national networks. At the top level each national NORDUnet network organization (NNO) is allocated one Admin Author value which together with the AFI+IDI+DFI prefix uniquely identifies the participating NNO. Also the NORDUnet international backbone is allocated an Admin Author value. NSAPs from the backbone prefix are used as NETs in the NORDUnet backbone routers. Finally, an Admin Author value is needed for DECnet Phase IV to Phase V transition. Other Admin Author values can be allocated later, eg. for experimental purposes. Initially, the following (hexadecimal) Admin Author values are assigned: 000001 NORDUnet backbone 000002 DK (UNI-C) 000003 FI (FUNET) 000004 IS (SURIS) 000005 NO (UNINETT) 000006 SE (SUNET) 000007 NORDUnet DECnet transition The NORDUnet international backbone forms a single routing domain with the Routing Domain value 0001, which in turn forms a single area with Area value 0001. Each NNO should allocate Routing Domain values within its membership from its NNO Admin Author prefix. It is suggested that each geographically separate NNO site is given its own Routing Domain value, so that, if desirable, a site may easily form its own Routing Domain, which - leaves the administration of areas within the Routing Domain as Dec 13 13:59 1991 Page 4 the internal matter of each site and - restricts the amount of routing information at the national level to sites instead of areas - makes it possible to implement routing policies on the site level independent of the routing policies of the NNO. Note that IS-IS (typically the routing protocol of preference internally in a routing domain) has very weak mechanisms (if any) to enforce administratively set routing policies. So to implement its own routing policies a site has to be allocated its own routing domain. Similarly to the NORDUnet backbone, also the national backbones should be reserved one Routing Domain value, which in turn forms a single area. Each site should allocate areas to its physical networks. Usually one area covers one or more adjacent LANs connected by bridges or routers. It is not adviced to allocate several areas to one logical LAN, since hosts that autoconfigure themselves may have difficulties to decide which area they belong to. When deciding the area structure internal to a routing domain, do keep in mind that internally in each area, all hosts have an entry in the routing tables. One should probably aim for simple rules and manageable sizes of the routing tables, and allocating an area for each physical network is a possibility. It is probably a wise idea to start allocating area numbers for "pure OSI end systems" above the "DECnet Phase IV compatibility" address range, which uses area numbers 0 to 64 (decimal) inclusive. More detailed design of area allocation is left to the local network administrators. Within an area each host has to have a unique System identifier. This can be achieved by several means. For example, the System identifier can be - the MAC address of the host - the IP address of the host interpreted as 12 hexadecimal digits - a separately administered number It is left for the networks administrators of each area to decide what scheme to use in numbering the hosts. Hosts that autoconfigure themselves often choose the MAC address scheme. NSel can be used to separate different customers of the network service if the software of the OSI system allows more than one NSAP. 2.6. DECnet Transition The aspects of DECnet Phase IV to Phase V transition in the above outlined addressing environment are dealt with in section 4. Dec 13 13:59 1991 Page 5 3. ROUTING CONSIDERATIONS The NSAP allocation scheme of section 2 has the following implications on routing: - Within an area the routing tables consist of NSAPs of the hosts in the area plus NSAPs of routers that form the backbone of the routing domain within the site and are connected to the area. - Within a routing domain of a site the routing tables consist of the area prefixes of the site's areas, NSAPs of other backbone routers of the site plus NSAPs of national backbone routers that are connected to the site. - Within the routing domain of the national backbone the routing tables consist of routing domain prefixes of the sites, NSAPs of other national backbone routers plus NSAPs of NORDUnet backbone routers that are connected to the national backbone. - Within the routing domain of the NORDUnet backbone the routing tables consist of prefixes of the national NORDUnet routing confederations, NSAPs of other NORDUnet backbone routers plus NSAPs of those NORDUnet backbone routers that are connected to external networks. - The routing tables of externally connected NORDUnet backbone routers consist, in addition to above, the prefixes of all externally reachable NSAPs plus NSAPs of the immediate neighbor routers in external routing domains. In terms of the Inter-Domain Routing Protocol (IDRP), the above means that routing domains of each NNO form a Routing Domain Confederation (RDC) with a unique Routing Domain Identifier (RDI) prefix. Further, the national RDCs form recursively with each other and with the NORDUnet backbone routing domain a higher level RDC that also has a unique RDI prefix. The resulting routing domain structure scales well and causes very little routing overhead. 4. DECnet Phase V SUMMARY AND MIGRATION RECOMMENDATION This chapter describes basic facts and considerations for DECnet Phase V (hereafter called DECnet/OSI) and the migration phase from DECnet Phase IV (hereafter called DECnet) to DECnet/OSI. It only discuss the addressing and routing aspects of DECnet/OSI and the migration and does not in detail address other important parts of DECnet/OSI, such as DECdns and DECdts. However, it can not be overemphasized that it is impossible to understand all requirements of DECnet/OSI and to plan and successfully conduct a migration without taking these network services into serious consideration. One should also remember that for systems using, or needing, connectivity with current DECnet hosts, all the naming and Dec 13 13:59 1991 Page 6 addressing assignment and registration procedures for DECnet must be followed in addition to the new procedures for CLNS and DECnet/OSI hosts! In addition, this chapter does not concern itself with the CONS support integrated into DECnet/OSI. 4.1. Basic Facts and Categorization of DECnet/OSI End Systems It must be understood that DECnet/OSI is a complicated topic because its aim is to introduce new services and protocols while maintaining backward compatibility with the old DECnet services and protocols. They therefore simultaneously interacts with both ISO CLNS systems (hosts as well as intermediate systems) and DECnet systems (end nodes as well as DECnet routers). This also implies that the DECnet Phase V specifications, although to large extent equivalent to DECnet and ISO specifications and standards, include extensions and minor modifications to these. To keep this chapter reasonably short we choose to categorize DECnet/OSI end system (ES) into three categories based on their interaction with Intermediate systems (both ISO and DECnet): (a) Systems running as "pure" Phase IV systems. These systems are manually configured to ignore any ISO router present on a LAN. However, they can not be totally ignored as CLNS system, because they still send End System Hello that will be recognized by ISO routers, and they can process CLNS packets if they receive any. (b) Systems used as "pure" ISO CLNS systems. These systems do not need connectivity to DECnet hosts and are considered equivalent to other non-DEC ES mentioned in this paper (e.g. SUNnet OSI ES). (c) Systems needing connectivity to current DECnet hosts and to new DECnet/OSI and other CLNS hosts. We leave out detailed information about the actual operation of DECnet/OSI systems in ISO, DECnet and mixed environments and will instead concentrate on a couple of typical (believed) situations and configurations. Systems and environments supporting systems from category (c) become complicated and may require additional considerations. The total migration planning is however outside the scope of this paper, but one should bear in mind that unexpected interaction may occur in mixed environments. An additional simplification is that we also assume that DECnet/OSI end systems are connected to LANs. The use of point-to-point links between ES and IS (or ES) is not further discussed in this chapter. DECnet/OSI applications on end systems that use CLNS include proprietary protocols at upper layers (session and above, but in some cases also at the transport layer) as well as new standard applications. The proprietary applications are more or less the Dec 13 13:59 1991 Page 7 same as those available with DECnet. The standardized applications include FTAM and X.400 (availability and license requirements varies between platforms). In view of our categorization above, it should be noted that only the proprietary applications in general work for category (a) systems, and that we assume that only standard applications are considered for category (b), although the proprietary applications can work too. In the long term when DECnet is phased out, DECnet/OSI systems will migrate from category (c) to category (b) systems, while still using the other DECnet/OSI infrastructures, such as DECdns and DECdts, that are established already during the migration. 4.2. NSAP Address Structure and Use DECnet/OSI systems do, as CLNS hosts, use NSAP addresses, and support the use of all available formats. Hence they can make use of NSAP addresses structured as recommended in this paper, and this is what we assume in the rest of this chapter. Before we look in detail at the three ES categories, we define four terms. (1) NSAP address prefix. This is the part of the NSAP address starting with the AFI and ending with the field PRECEDING the area field (i.e. with the routing domain field in our case). (2) Area address. This is part of the NSAP address starting with the AFI and ending with the area field (i.e. the prefix + the area). (3) Phase IV Prefix. Of special interest is the Phase IV Prefix, a NSAP prefix used during the migration to allow connectivity between DECnet and DECnet/OSI hosts. This prefix must be shared by all end systems in the region of the network where connectivity between DECnet and DECnet/OSI hosts is required. For most IS-IS implementations (Cisco IGRP as well as IS-IS according to ISO 10589), it also imply that this network region should be one routing domain and that intermediate systems also use addresses with this prefix (at least one such address). (Static routes can relax the later restriction, but should only be used when no other alternatives are available.) To make it possible to keep the current DECnet connectivity in NORDUnet during the migration to DECnet/OSI, the CLNS project recommends that the entire NORDUnet use the following Phase IV Prefix: 47:0023:00-000007-0000-0001 The observant reader may here ask how this will work with our HEPnet/SPAN connections. The simple answer is that it won't. The HEPnet/SPAN connection is explained in 4.5 below. Dec 13 13:59 1991 Page 8 (4) A DECnet compatible NSAP address. This is an NSAP address derived from a DECnet address and consists of: i) the Phase IV Prefix ii) an area field equal to the DECnet area it lives in (1-63) iii) a system field equal to the Ethernet hardware address a DECnet system with the corresponding DECnet address would have. (This is called the system ID in DECnet terms, but has a one to one mapping to the Ethernet address discussed). For example. The NSAP address (or more exact, an network entity title, NET) "compatible" with the DECnet address 57.202 is on NORDUnet: 47:0023:00-000007-0000-0001-0039:AA000400CAE4:00 (Dashes are used only to increase the readability). As specified by the ISO standards, an ISO/CLNS system may have more that one NET (in the rest of this chapter, the term NET, network entity title, will be used in addition to the term NSAP). The DECnet/OSI specifications limits the number of NETs per systems to three, as did DIS 10589. Because the ISO 10589 removed that restriction, this is a DECnet/OSI restriction, at least for the time being. The term multihomed will be used for systems with more that one NET. DECnet/OSI specify that end systems on a LAN may "autoconfigure" their NSAP/NET. This is done by taking the area address from a received IS Hello and combining it with a system field taken from the IEEE 802.3 hardware address of the first LAN interface (except that DECnet compatible areas are handled in a special way). This can, in a controlled DECnet/OSI environment, be of great use (at least make it easy for the end system owner and manager), but may introduce problems and unexpected events in a not so tightly controlled environment. The autoconfiguration feature can be disabled during the configuration of the end system. Our recommendation is to disable autoconfiguration, except possibly for LANs with very strong management. This may change when CLNS becomes a well established and stable service throughout NORDUnet. Now, systems from the different categories may be configured with NSAP addresses as follows (see Appendix A for configuration details): (a) These systems do strictly speaking only make use of a DECnet address, but due to the way DECnet/OSI is implemented (current implementations include DECnet/Ultrix and WANrouters, the later is a DECnet/OSI router from DEC), they must also be assigned a DECnet compatible NSAP address! The DECnet address and a short name (a long, domain based name is also used) is assigned using the same procedures as for the current DECnet in NORDUnet. Dec 13 13:59 1991 Page 9 They should only be configured with ONE NSAP (NET)! (b) These systems can accept any number of NETs up to the limit of three. None of them need to be DECnet compatible, and in fact, they SHOULDN'T. The address assignment is done during end system configuration unless autoconfiguration is enabled. No other special considerations are needed. (c) These systems must have a DECnet address and use the Phase IV prefix for exactly one NET, and hence use a DECnet compatible NET/NSAP, see (a) above. In addition to this it can, optionally, use up to two additional NETs, manually configured, or optionally autoconfigured. For these, DECnet/OSI imposes no further restrictions. (Se 4.4.3 for restrictions set by intermediate systems which are connected to the same LAN as the DECnet/OSI ES). For multihomed systems having a DECnet compatible NET, the algorithm for choosing what local NET/NSAP to use for a session with a given remote NSAP is to use the DECnet compatible local NSAP when the remote NSAP is DECnet compatible and one of the others (at random) otherwise. For multihomed systems from category (b), the local NSAP should be considered as chosen at random (will not change for a given local - remote system pair). DECnet/OSI uses the Selector (Nsel) field to select between the OSI and DECnet transport layer. As default (which should not be changed except in very special situations) it uses Nsel = 20h to select the NSP transport layer (DECnet) and DECnet Session control, and Nsel = 21h to select the OSI transport. If viewed in the long term when DECnet (Phase IV) is phased out, DECnet/OSI has no special requirements on NSAP address structure different from any other ISO CLNS system. It is however HIGHLY advisable to conform to the structure standardized by the IS-IS protocol ISO 10589. In any case, the NSAP recommendation given in this report conforms to this and could be used in the long run for DECnet/OSI as well as other CLNS systems. 4.3. ES-IS Interaction and Considerations The fact that DECnet/OSI is backwards compatible with DECnet implies that systems must interact with both DECnet systems and ISO systems. Much can be said at a detailed level, but we will here only list a couple of facts. End systems from category (a) and (c) send both ISO ES Hellos and DECnet hellos and are therefore discovered by both DECnet and ISO intermediate systems (IS). Specially note that category (a) systems are discovered by an ISO IS while they themselfes don't Dec 13 13:59 1991 Page 10 recognize the ISO IS, which can result in confusion! DECnet/OSI systems can send and receive both CLNS packets and DECnet network layer packets. DECnet/OSI systems from category (c) recognize and use both DECnet routers and ISO routers, but will always give priority to ISO routers. As soon as there is at least one ISO router present on a LAN, a DECnet/OSI system from this category will use this ISO router even if there remain DECnet routers on the LAN. Because DECnet/OSI systems from category (c) always give priority to ISO IS before DECnet routers, they also rely on a DECnet/OSI specified router extension. The router MUST be able to convert CLNS packets it receive to DECnet network layer format if the destination is an adjacent DECnet host or if the next hop to the destination requires DECnet packets. Although this has nothing to do with CLNS as such, it is VITAL for the migration to work. If an ISO IS on a LAN with category (c) end systems can't do this, the systems from category (c) will loose connectivity to DECnet hosts! It may be worth noting that if the routing filter needed for category (a) systems (se Appendix A for details) is forgotten or disappears during an upgrade, the system will automatically become a category (c) system. For example, a reinstallation or complete reconfiguration of DECnet/Ultrix V5.0 replace the startup file in which the filter normally is activated! DECnet/OSI systems from category (b) and (c) use any present ISO IS as intermediate system for the first packet sent to a new destination (and handle "redirects" as described in the ES-IS standard (ISO 9542)), and will in the absence of ISO routers send the first packet for an unknown destination to the All End Systems Multicast LAN SNPA address (all conforming to the standard). There is a minor difference between category (a) and (c). Category (a) will in the absence of an ISO IS use DECnet at the network layer if the destination has a DECnet compatible NSAP address (both in the presence and absence of DECnet routers, as described in the DECnet specifications) and use the All End System method when trying to establish a connection to systems with non-Phase IV compatible addresses. Category (c) systems have no notion about DECnet and DECnet Phase IV prefix and will always try CLNS. 4.4. Routers for DECnet/OSI and Routing Considerations The DECnet/OSI migration extensions make the routing topic complicated. It does not become easier by the entire different implementation strategies chosen by e.g. DEC and Cisco. (Because the DECnet/OSI specifications aren't released to the public yet, it is impossible to say exactly how much can be left to implementation decisions and still conform to the DECnet/OSI specifications). Digital decided to implement a router with a single routing process importing and exporting adjacency information from both DECnet and CLNS end systems and intermediate systems, but exchanging IS-IS Dec 13 13:59 1991 Page 11 routing information from only one of the "worlds" at a time. This lead to an implementation with unexpected side effects in many situations. One reason for this choice is that performance is increased with fewer routing processes. The IS-IS protocol used can be either DECnet routing vector, OR ISO 10589 IS-IS (with minor DECnet/OSI extensions and modifications). It can even be different at Level 1 (intra-area) and Level 2 (inter-area). Ciscos run parallel routing processes, one for DECnet and one for CLNS, each handling its own interaction with adjacent systems, and each running its IS-IS protocol with adjacent routers in its own "world". The processes can optionally exchange a limited amount of information internally to support the packet conversion described in 4.3 above. The fact that Cisco implements both protocols in parallel can reduce the number of conversions needed and will in practice only convert when necessary and give priority to the CLNS format. All features we need in the nearest future are supposed to be implemented in software version 8.3. It is still unclear when support for Phase V cluster alias names/addresses will be included. It will NOT be in 8.3, but hopefully it will be available before DECnet/OSI becomes installed on VMS hosts. Cisco version 9.0 will include support for IS-IS (ISO 10589) and the migration extensions. It is, however, not yet clear if the DECnet/OSI extensions will be implemented as in WANrouters or in a way similar to the DECnet + CLNS/IGRP present in 8.3. Even unclearer (to us and to Cisco) is if and how the migration can work in a mixed DECnet, CLNS/IGRP and ISO 10589 environment. It is likely that there will be some restrictions, at least in the first 9.x releases. We will in this section look at a couple of different ISO IS, concentrating on their impact on DECnet/OSI ESs and ISs. We can categorize the routers into six categories: r1. DECnet only (phase IV) routers. Host based VMS routers fall in this category, as well as Cisco routers with DECnet routing enabled. Cisco routers may run CLNS, but they should not have DECnet conversion enabled. DECrouter 2000 and other DECrouters running Phase IV software also belong here. r2. DECnet/OSI routers running DECnet compatible routing protocol and configured with an DECnet address. (For sake of breviety, we ignore the fact that different IS-IS protocols can be used at Level 1 and Level 2, and only consider Level 1). Currently we only have WANrouters from Digital Equipment in this category. For example, a DECrouters 2000 can be converted to a WANrouter 500 by upgrading the software (and license). r3. DECnet/OSI routers running Link state IS-IS (ISO 10589 standard) and configured with an DECnet address as well as implementing the migration extensions. Dec 13 13:59 1991 Page 12 The only equipment we know of here are the DECnet/OSI routers from DEC, the WANrouters. r4. ISO routers running IS-IS as described in ISO 10589 and NOT implementing the DECnet/OSI migration extensions. We have no experience of any such implementations at this time, but a WANrouter configured without DECnet address and DECnet-compatibility should go here. (It may not be true in detail, it may depend on implementation details for individual routers...). r5. ISO routers running any other IS-IS protocol. Cisco with CLNS and ISO IGRP without any migration extensions enabled fall into this category. r6. ISO routers implementing all or part of the DECnet/OSI migration extensions in a non-DEC compatible way. Cisco routers running DECnet and CLNS with the DECnet conversion enabled is an example of such a system (the only one we know of). For all categories where ISO CLNS is used, we assume the use of ES-IS protocol as specified in the ISO 9542 standard. CLNS routers NOT implementing the ES-IS protocol CAN be used by DECnet/OSI end systems, but that is considered outside the scope of this report. 4.4.1. Category r1 Routers For these, there is not much new to add within this report. What should be known is that DECnet/OSI end systems from category (a) or (c) connected to broadcast subnetworks with these routers but without ISO routers act as DECnet end nodes. Se the paragraph about category r3 systems for additional considerations. 4.4.2. Category r2 Routers Routers from this category have some unexpected consequences. For DECnet systems, they appear as normal DECnet routers, but since they also send ISH and recognize ESH (both according to the ES-IS standard), they interact with any ES-IS compatible CLNS host in a given broadcast subnetwork! They also send and receive IIH (from ISO 10589 standard) and can therefore discover adjacent ISO IS using this IS-IS protocol, but they do not exchange routing information with such systems. (They DO exchange routing information with DECnet routers). We here ignore complications caused by the later interaction, and concentrate on consequences for CLNS end systems. As a further complication, they can only have a single NET (the Phase IV compatible one), and do not accept ESH from non-compatible end systems (in fact, each such ESH generates an error event). DECnet/OSI end systems from category (c) will set the r2 router Dec 13 13:59 1991 Page 13 before any DECnet router, and will therefore always send the first packet to a new destination to this router IN CLNS FORMAT. The router will convert it to a DECnet packet if the destination is an adjacent DECnet host, or when forwarding it to the next DECnet router on the path to the destination. The packet will NOT be translated if the destination is another adjacent DECnet/OSI or CLNS host, but instead it is forwarded and a "redirect" is sent to the source. Note, that the router makes no difference between a DECnet/OSI ES and other (ES-IS speaking) CLNS ES! This may cause confusion. If a CLNS packet from a non-Phase IV compatible CLNS host is sent to an r2 router, it may convert it (if the destination if adjacent and the destination address is DECnet compatible). This is OK if the packet belongs to an DECnet application, but not if it belongs to FTAM, for example. This may lead to confusion and is one of the reasons for configuring systems from category (b) and other ISO CLNS ES with non DECnet compatible NSAP addresses. DECnet/OSI ES from category (a) will only recognize the router as a DECnet router and it will treat it as any other such router and therefore only use DECnet packets at the network layer. One should note that a given DECnet area should not include routers from this category and category r3 at the same time. That can effectively lead to a partitioned area. 4.4.3. Category r3 Routers These routers implement the ISO 10589 standard when compatible with DECnet/OSI. Because the there were some changes from the latest DIS to the final ISO standard as accepted this summer, some minor incompatibilites may remain, what is unclear for the moment. There is at least two minor things we know to differ. First, the limit of three area addresses is given by the DECnet/OSI specification (and it was in a DIS version of the ISO standard), but ISO 10589 removed that. Secondly, a multiarea LAN is handled slightly differently. Is is possible to have multiarea, non-Level 2 only, broadcast subnetworks with WANrouters provided they only use DECnet compatible area addresses. For WANrouters, the only possibility to do inter-domain routing is with static routes. Now, as mentioned before, the migration strategy is implemented in such a way that these ISs also interact with adjacent DECnet end systems and routers. They send and receive DECnet hellos and therefore discover adjacent DECnet systems. These are assigned an NSAP address calculated from the Phase IV prefix and the adjacent DECnet systems address (the Phase IV prefix is a configuration parameter in the router). The router also converts packets from CLNS hosts to DECnet hosts similar to what is described in 4.4.2 and it forward DECnet packets. (If a connection is established between a DECnet host and Dec 13 13:59 1991 Page 14 a DECnet/OSI host on the same broadcast subnetwork, after the initial packet is sent and converted, DECnet packet will be used on the network layer, without involving the router, so the router will not have to convert all packets in this case. In some other cases, where a packet leaves a LAN, a router may need to convert both from and to Phase IV format. As mentioned in 4.4.2, routers from category r2 and r3 should not be mixed in the same DECnet area. 4.4.4. Category r4 Routers We have no experience with these routers, but they should not interact with DECnet end nodes or DECnet routers in any way. End systems from category (a) will therefore never see them. End systems from category (b) will use them as any other ISO IS. End systems from category (c) will use them as any other ISO IS, but because no migration extensions are implemented/active, all end systems from this category will/can loose connectivity to DECnet hosts. With carefully selected multihoming and (often) static routes, it is sometimes possible to arrange so that a broadcast subnetwork can have routers from category r2 and/or r3 and r4-6 while DECnet connectivity is maintained. A CLNS packet from a DECnet/OSI host to a DECnet host need only to pass a single router with the packet conversion implemented. It does not have to be the first or the only router it passes. Details will not be given here, as the number of combinations, special cases, and possible topologies are too numerous for this report. 4.4.5. Category r5 Routers These routers are no different from r4 routers when it comes to the interaction with DECnet/OSI ESs. The statements made in 4.4.4 are valid here to. 4.4.6. Category r6 Routers We can't say exactly how this will work in general, but we will describe as much as possible of the Cisco implementation (as we understand it to work, without practical experience!). Recent discussions with Cisco gave us a fairly clear understanding of how their migration support works in their first, DECnet and CLNS/IGRP based version. The fact that Cisco routers run both DECnet and CLNS routing processes in parallel have a couple of interesting consequences: Dec 13 13:59 1991 Page 15 (1) A given DECnet area can be migrated step by step. (2) Packets may not need to be converted between the two network layer formats as often as in networks with r2-r3 routers. The conversion is only done when it is needed. A Phase IV prefix need not to be given explicitly. Instead DECnet conversion (as the term is) is enabled giving the area tag of the prefix that was previously configured by the CLNS router configuration process. Adjacent systems (neighbors) are discovered with both protocols and DECnet ESs are entered as CLNS ES neighbors as for r2-r3 routers. CLNS ES neighbors are also entered as DECnet adjacencies if they have DECnet compatible NSAP addresses. The following is a summary of OUR UNDERSTANDING of Cisco DECnet/OSI migration support. Some details, such as redirects, are omitted. The information we got from Cisco leading to these conclusions was good, but not as good as a formal specification or exhaustive testing/experiments!!! When a CLNS packet arrives to such a router, the following steps occur: i) The CLNS adjacency database is first examined. If the destination is a neighbor and is NOT marked as a Phase IV host, the packet is delivered unchanged to the destination ii) If the destination is in the adjacency database, but IS marked as a Phase IV host, the packet is converted to Phase IV format and sent to its destination. (If the destination address isn't Phase IV compatible, this step is skipped). iii) If the CLNS forwarding database contains a path to the destination via another CLNS IS, the packet is forwarded to this IS as a normal CLNS packet. iv) If neither of the above is true and DECnet conversions is enabled, the destination NSAP address is examined for Phase IV compatibility. If is IS Phase IV compatible, it is assumed that the destination is a non-adjacent DECnet host, and the packet is therefore converted to Phase IV format and sent to the local DECnet forwarding process. That process will then try to forward it as a normal DECnet packet via other DECnet routers if the DECnet routing database contains a path to the destination. If not, the unreachability error will be generated as for normal DECnet routing. (The exact implementation of this step in uncertain, the examination of the forwarding database for DECnet may occur before the packet is converted, and hence the error report could differ). v) If all these steps fail, the destination is unreachable and an error PDU will be sent to the source. Dec 13 13:59 1991 Page 16 When a Phase IV packet arrives to a router with DECnet conversion enabled, the following steps are tried: i) The DECnet adjacency database is examined to see if the destination is adjacent. If it is, the packet is forwarded as a Phase IV packet (remember that all DECnet/OSI systems understand DECnet). ii) Otherwise, the DECnet forwarding database is examined, and if a DECnet path to the destinations exists the packet is forwarded as a DECnet packet to the next DECnet router on that path. iii) Otherwise, if packet conversion is enabled, the DECnet packet is converted to a CLNS packet and sent to the local CLNS forwarding process, where the reachability of the target is checked. Errors are generated if the destination is unreachable. As for the CLNS->DECnet case, the order of the conversion and forwarding decision is unknown. iv) If all these step fail, the destination is unreachable and the sender is notified in the normal DECnet way. One should remember that there is no automatic redistribution of routing information between the two "domains" (DECnet and ISO). (This statement is based on our interpretation of statements from Cisco, not on experiments). This implies that for certain topologies where both protocols exists and where the conversion isn't enabled over the entire network, static prefix routes are needed on the CLNS side. This is very much like InterPhase Links (see next section) but not quite as flexible. There is no way to "inject" routing information to the Phase IV world like it is in the case of InterPhase Links. In our topology, this is not likely to be a problem. 4.4.7. InterPhase Links Above we ignored the fact that WANrouters (routers form category r2 and r3) could run different IS-IS protocols (DECnet routing vector or ISO 10589 link state) on Level 1 and Level 2, and this will partly be corrected here. As stated in 4.4.2 and 4.4.3, one should only use one routing protocol at the same time within an area for these routers. An whole DECnet area must migrate at a given time when using these routers. All this is on Level 1. At Level 2, it is possible to migrate one area at a time. If this is done, subnetworks will run different area-level protocols, and in a sense therefore be in different routing domains. Consequently, there is a need to implement some redistribution of routing information between the two domains or to invent an inter-domain routing protocol. How this inter-domain routing information redistribution is Dec 13 13:59 1991 Page 17 implemented in WANrouters will be explained further below, not because it has much to to with CLNS, but because this report should give recommendations for the use and migration of the NORDUnet connection(s) to HEPnet/SPAN, and in that context, InterPhase Links are important. Digital choose to implement this redistribution in r2-r3 routers as so called InterPhase links. They can from the CLNS side be viewed as static routes (with cost) specifying an outgoing circuit or MAC address and explicitly stating that Phase IV packets should be used on that link or to that address. It is a bit more than static links, because one must also configure what DECnet routing information to inject into the DECnet domain. As all other static routing, it is not very useful in complicated topologies. The following figure gives an example with a point-to-point link used as an InterPhase Link (it can be used on broadcast subnetworks also). +-------------------+ +-----------------------+ | | | | | Domain A | | Domain B | | Running CLNS, | P-to-P link | Running DECnet (Phase | | DECnet/OSI with |---------------| IV only) | |Category r3 routers| the Inter- | | |in "Areas" 1 and 2 | Phase link | "Area" 3 and 4 | | | | | +-------------------+ +-----------------------+ The r3 router in Domain A connected to the InterPhase Link will be configured to: (i) Have a static routes to area 3 and 4 via the InterPhase Link (expressed as a NET prefix = The Phase IV prefix + "area"=0003 and 0004). A cost is manually assigned. The link will also be marked as using Phase IV packets only, so any packet with compatible addresses destined for hosts in areas 3 and 4 will be converted to Phase IV and sent down the link. (ii) To send Phase IV Level 2 hello and routing updates down the link with information that areas 1 and 2 are reachable from area 3 and 4 through this link. The costs used in the routing updates are manually configured. (iii) The router will also redistribute the static information about areas 3 and 4 in Domain A. Note, that no change at all is needed in the DECnet router in Domain B connected to the InterPhase Link. It will believe that the adjacent router in Domain A is a Phase IV Level 2 router. 4.4.8. InterPhase Routers Dec 13 13:59 1991 Page 18 The Cisco implementation of the migration extensions result in what can be viewed as InterPhase Routers. This is in fact more flexible than the InterPhase links described in 4.4.7, but rely on the use of parallel routing processes in the router, one for DECnet and one for CLNS, with a limited information exchange within a given router. The "InterPhase Routers" is a natural consequence of the migration extension implementation, as described in 4.4.6 above. In all cases, the packet will remain in a given format until a conversion is needed. When one of the routing processes fail to find a forwarding path to the destination, the packet will be converted and the other process will give it a try. This should be enough to indicate the flexibility that this implementation give. See also 4.5 below. 4.4.9. Other Routing/Router Considerations It is probably self-evident, but given the way the migration extensions work, we must use the same CLNS IS-IS throughout a given DECnet area during the migration. The mapping of DECnet addresses to NSAP addresses makes a DECnet area to correspond to an intra-domain CLNS area, and for both routing protocols considered here, the Cisco IGRP and the ISO 10589, an area cannot be split between routing domains. This is not to say that certain implementations, such as Cisco IGRP based IS-IS (but NOT WANrouter IS-IS) can use overlapping routing domains in parallel in a given network region. The statement is for a DECnet compatible routing domain. To further complicate the picture, for routers from category r3 this also implies that the subnetwork comprising a DECnet area also becomes ONE CLNS area (see ISO 10589 specifications for details), although it may have more that one area address (with WANrouters, limited to three!). Although the migration requires that the NORDUnet network share a common prefix, it is strictly speaking not necessary to exchange inter-area routing information for this prefix throughout NORDUnet, but it is probably the easiest way to avoid static routes. It is not clear if Cisco IGRP and/or the coming inter-domain IS-IS protocols accept inter-domain routing between areas. 4.5. HEPnet/SPAN Connection(s) As mentioned earlier, a common Phase IV NSAP prefix must be shared by all DECnet and DECnet/OSI networks needing full connectivity during the migration. Because regional/national DECnet networks connected to the HEPnet/SPAN DECnet use routing filters (so called max area filters), the entire global DECnet network does not lend itself to an easy migration following the rules provided by Digital. Dec 13 13:59 1991 Page 19 As a result, NORDUnet and HEPnet will use different Phase IV prefixes, and since this is unsupported, a lot of complications occur. They are possible to solve, but there are no straightforward and simple rules. We shall not in this paper go into to a detailed discussion, but only summarize the conclusions and recommendations. The DECnet groups within NORDUnet have decided that the following is the only realistic migration strategy for the NORDUnet DECnet connections. (1) Use our own Phase IV prefix, 47:0023:00-000007-0000-0001, as described earlier. (The "normal" part of HEPnet will use a common prefix, 47:0020:). (2) Use InterPhase Links or InterPhase Routers as address translation gateways between the NORDUnet and HEPnet. See 4.5.1 and 4.5.2 below for a detailed description. (3) Use our own DECdns namespace for the coming few years. When all DECnet is migrated, we should consider joining the global DECdns namespace (whatever it may look like at that stage). NOTE! NOTE! See 4.6.1. for a possible change in this recommendation!!! (4) Create our own DECdts region (or regions) for time synchronization. (5) In the few cases it actually is necessary to access HEPnet hosts with names instead of addresses, import the protocol tower information from the HEPnet namespace into the NORDUnet namespace while converting the address information. We believe that this will give us the most flexibility, both for current DECnet hosts in the HEPnet area (DECnet area 21) and DECnet/OSI hosts from the HEPnet community as well as other. We will, if this scheme is implemented, meet the following goals: (a) Allow gradual migration of NORDUnet without unnecessary interaction with HEPnet or the other Nordic countries. (b) Keep intra-phase connectivity inside NORDUnet as well as between NORDUnet and HEPnet. DECnet hosts in area 21 on NORDUnet will keep the same connectivity as of today with both DECnet and DECnet/OSI hosts in HEPnet. If they continue to use a local host database, everything should remain as is is today. DECnet hosts installing the DECnet/VAX extensions and therefore using the NORDUnet namespace for host name to address translation may still enter HEPnet nodes in their local node database (because it is examined before the namespace). If need arise, a selective import of nodename information from the HEPnet namespace (called OMNI) to the NORDUnet namespace Dec 13 13:59 1991 Page 20 can be done. If so, the address information will be changed s that o the HEPnet nodes appear to have our Phase IV prefix. If we are able to join the OMNI namespace, se 4.6.1, this import is a copy of the information from one subtree to another susbtree in the same namespace. (c) Allow limited, but expandable, inter-phase Connectivity. DECnet/OSI hosts in NORDUnet can access HEPnet Phase IV nodes using either their old DECnet addresses or using the imported name- information mentioned in (b). DECnet/OSI hosts in NORDUnet can access HEPnet DECnet/OSI hosts using their full NSAP address. This address is retrieved by querying the OMNI namespace. (A DECdns clerk can access more that one namespace, but it requires some manual configuration if a namespace is "off-LAN". (d) All of the above points are also valid as seen from HEPnet. Of course, we have a couple of drawbacks, the most important being that we don't share a DECdns namespace with HEPnet. This will lead to a couple of complications for the end users, but only for those running Phase IV software and needing connectivity to Phase IV HEPnet nodes. (See 4.6.1. for the possibility of actually joining the global, HEPnet, namespace!!). Another, maybe not so important, drawback for DECnet/OSI hosts is that the back translation (address to host name) is done only using the so called default namespace (in our case, the NORDUnet namespace). It is, however, not as bad as it seems. The DECnet/OSI session layer passes name information in the connect request, so the back translation is only needed for old applications not using this new feature (an old Phase IV application is a good example) and applications relying on back translation for security reasons (for example). These effects are seen whenever using more that one namespace (Digital recommends against using more than one). 4.5.1. InterPhase Links as an Address Translation Gateway The most flexible way of solving the HEPnet connection problem is to use a general address translation gateway combined with routers implementing the DECnet/OSI migration extensions. To our knowledge, no such equipment exist. What we CAN rely on, is that the InterPhase Links mentioned in 4.4.7 in fact can be used as a translation gateway. The complication is that an entire area must run DECnet protocol for this to work with WANrouters. In view of the fact that Cisco is the dominant router vendor on NORDUnet, and that the link between NORDUnet and CERN soon will be Cisco based, the method described in this section is not likely to be the one we actually implement. It is included here for the sake of completeness. The following picture outlines the simplest case. In the figure, Dec 13 13:59 1991 Page 21 area 21 is a DECnet area. The HEPnet region and the Sweden region run CLNS/DECnet/OSI. The exact details of the implementation phase are left to the DECnet and CLNS service responsibles of NORDUnet when the equipment and software details are clear. +--------------------+ +----------+ +--------------------------+ | HEPnet region | Link A | Phase IV |Link B | Sweden region | | Phase IV Pref. (R1)--------| Area 21 |------(R2) Phase IV pref. | | 47:0020: | | | | 47:0023:0000000700000001 | | DECnet area 1-46 | | | | DECnet area 56-60 | +--------------------+ +----------+ +--------------------------+ Links A and B are InterPhase Links. Therefore, in the HEPnet region, a route to addresses 47:0020:0038 - 47:0020:003C (38h = 56, 3Ch = 60) is through the A link and that the packets should be converted to Phase IV packets. In the same time, throughout Sweden, a route to addresses 47:0023:00-000007-0000-0001:0001 - 47:0023:00-000007-0000-0001:002E is known to be via the B link, and that packets should be translated to Phase IV format. The routers, R1 and R2, connected to the DECnet/OSI ends of the InterPhase Links, will convert packets using THEIR Phase IV prefix. Altogether, this has the effect of an address translation gateway for DECnet compatible addresses in the two DECnet/OSI domains. If we in parallel with Link A and B have CLNS paths for the rest of the 47:0020 and 47:0023 NSAP subtrees, it is also possible to access full DECnet/OSI or non-DECnet CLNS systems with their full, untranslated NSAP addresses using these parallel links. (Depending on the actual implementation of the InterPhase Links, multihoming with non DECnet Phase IV compatible prefixes may be needed for full CLNS connectivity in parallel with the DECnet compatible connectivity). In the long term, when most system have migrated, the InterPhase Links and the address translation gateway may be turned off and full CLNS will be the only supported network protocol to HEPnet. 4.5.2. InterPhase Routers as an address translation gateway This is the method we are likely to implement. It relies on the migration implementation in Cisco routers, and we believe it will work as described. It is important to remember that we have not confirmed, from experiments or from Cisco, that it will work!!! The following is a simplified picture of how this translation gateway can be implemented with the equipment we already use. +--------------------+ +----------+ +--------------------------+ | HEPnet region | Link A | Phase IV |Link B | Sweden region | | Phase IV Pref. (R1)--------| Area 21 |------(R2) Phase IV pref. | | 47:0020: | | Cisco | | 47:0023:0000000700000001 | | DECnet area 1-46 | | rtr (R3) | | DECnet area 56-63 and 21 | | and R1 in area 21! | +----------+ +--------------------------+ Dec 13 13:59 1991 Page 22 +--------------------+ In this picture, the important routers are R1, R2 and R3, all assumed to be Cisco routers. They will be configured as follows: R1. DECnet routing at area level. Address 21.x. CLNS router with several routing domains (a CLNS only consideration!), one of which is the one with the DECnet IV Prefix 47:0020:. DECnet conversion is enabled for this domain/area tag. (It does in fact not matter if the DECnet conversion is enabled or not, but it should as soon as we need CLNS connectivity to HEPnet hosts with DECnet compatible addresses (with HEPnet Phase IV Prefix). An alternative to DECnet conversion on R1 is to let WANrouters at CERN (it is likely that they will have such boxes) do the conversion by InterPhase Links pointing to R1, in which case R1 can run DECnet only (if a CLNS path for other prefixes exists in parallel), or DECnet + CLNS. In this case, the management regions where InterPhase configuration is required are clearly defined. One at CERN, managing the InterPhase Link from HEPnet address space to Area 21, and one on NORDUnet managing the DECnet conversion from our address space to DECnet areas <47. I does not require any DECnet migration-specific configuration on R1, R3 and any other DECnet/CLNS Cisco's on the path between CERN and NORDUnet. R2. CLNS routing, but NOT for the domain used on R1 for the DECnet conversion. DECnet area router. Address 21.y. DECnet conversion NOT enabled! R3. DECnet routing at area level. Address 21.z. CLNS router for several domains (inter-domain IGRP, static routes etc, all a CLNS-only matter!). CLNS router for the routing domain/area tag that NORDUnet choose as the DECnet/OSI migration routing domain (common for the entire NORDUnet). DECnet conversion enabled for this domain/area tag. In addition, prefix routes for 47:0023:00-000007-0000-0001-{0001-002E} pointing to R2 are needed on NORDUnet CLNS routers adjacent to R2 if we want to transport packets with DECnet compatible addresses as CLNS packets as close to R2 as possible. This may be of interest if we want to run IP and CLNS only on the NORDUnet backbone at some later time. As seen from the description of how we believe Cisco implements the migration extensions (see 4.4.6 above), this will allow for the same connectivity as the InterPhase Link described in 4.5.1. It will, in fact, be more flexible than using InterPhase Links. Note that DECnet Phase IV could be avoided on the "backbone line" from CERN via Amsterdam to KTH, if the R2 router is moved to either Dec 13 13:59 1991 Page 23 KTH or CERN. In that case, the backbone link could run CLNS for the CERN or NORDUnet migration routing domain only (not DECnet Phase IV). Solutions with tunneling the Phase IV traffic in TCP/IP could also be built, but details are not given here. (There must be at least one DECnet router or link without conversion, from whatever vendor, between the R1 and R3 router). 4.6. Other Considerations, Short as well as Long Term 4.6.1. DECdns DECdns will not be described in this paper, but it is important to realize a couple of basic facts about DECdns and the DECnet to DECnet/OSI migration. NOTE! NOTE! NOTE! Recently, the question of NORDUnet joining the "global" HEPnet DECdns namespace (called OMNI) already from the start has been brought up again. The information about how Cisco supports the migration and the progress of the COSINE CLNS pilot may make this a realistic alternative. However, all details are not know yet, and the next of this subsection assumes that NORDUnet use its own DECdns namespace. From the CLNS point of view, a late change in the implementation plans will not have any serious effect on the other conclusions and recommendations in this document. It mostly puts higher demand on the planning of the server placement and on replication topology in DECdns. It can take advantage of a fast introduction of CLNS connectivity and DECnet conversion throughout NORDUnet, but will not entirely depend on the rate at which CLNS becomes available. (1) DECdns must work for DECnet/OSI systems that use the proprietary applications, and connectivity between servers and between servers and clients must therefore be assured. In the long term, this is not a problem; it is no different from other CLNS connectivity. It is also natural that the entire DECnet/OSI world use one, and only one, DECdns namespace. (This imply that in some point in time, NORDUnet DECnet/OSI hosts must switch namespace). During the migration it requires that the network region where DECdns is used (NORDUnet in our case) maintains connectivity between all hosts (DECnet as well as DECnet/OSI) using and included in our DECdns namespace. This is the same requirement as for other systems from categories (a) and (c). As a consequence, DECdns server must have Phase IV compatible addresses and either be connected to networks/LANs with working DECnet/OSI packet conversion functionality, or be locked to DECnet Phase IV. Gradually when the needed migration functionality is implemented, the DECdns namespace will also be accessible with CLNS (from DECnet/OSI hosts) too. Dec 13 13:59 1991 Page 24 (2) DECdns is currently NOT used by the standardized applications included in DECnet/OSI (e.g. FTAM), but that may change in the future. This means that systems from category (b) can work without DECdns, at least in theory (it is not supported). It is easier, and probably safer, to configure them with DECdns, both from a configuration point of view and to make it possible to use the proprietary applications in addition to the standardized ones. (We have no experience of trying to configure a DECnet/OSI end system to run without DECdns). One implication from this is that initially (during the DECnet/OSI migration), systems from category (b) must create their own namespace (preferably the NORDUnet or world wide one) using full CLNS connectivity between servers and clients. Another implication that should be remembered is that DECdns uses an advertisement/solicitation protocol on broadcast subnetworks, with special data link level protocols and multicast addresses. This has as a result that all DECnet/OSI hosts on a LAN where these protocols and addresses are allowed and not filtered out will know of DECdns namespaces served by category (b) DECdns servers. This may be confusing for DECnet/OSI host from category (a) (and (c)). 4.6.2. DECdts A few words about DECdts. DECdts is a distributed time service, comparable to the NTP based service on Internet. Although it in itself set no extra restrictions on NSAPs and CLNS, one should remember that this protocol also includes an advertising/solicitation scheme with its own data link protocol on broadcast subnetworks, and that it includes a WAN synchronization where information about remote DECdts timeserver is fetched from DECdns. So, here is also a potential interaction between DECnet/OSI systems from categories (a)+(c) and category (b) that may be confusing if not handled with care. 4.6.3. VAX/VMS Clusteralias Requirements As have been mentioned, the VAXCluster alias concepts puts some additional demands on the routers supporting DECnet/OSI migration. The goal Digital has is to support both Phase IV and Phase V cluster aliases in Phase IV as well as Phase V areas. 4.6.3.1. Phase IV Cluster Alias A Phase IV VAXCluster contains at least one DECnet VMS based router supporting the alias. On a network with only WANrouters running link state routing, this implies that such routers must be treated different from other DECnet routers. All routers in a given area should migrate at a given time, but single-circuit VAXCluster alias routers are handled specially. The details will not be described in this paper. Dec 13 13:59 1991 Page 25 The way Cisco supports the migration makes this very easy. As long as DECnet, CLNS and the DECnet conversion are active in the same time, we won't have any problems at all. There is no difference between a cluster alias router and a normal Phase IV router in the Cisco case. When a network area converts to CLNS only, Phase IV cluster aliases will cease to work unless WANrouters are present. Cisco have no plans to introduce the special extensions needed to avoid this. For NORDUnet, this is not likely to ever become a serious problem. 4.6.3.2. Phase V Cluster Alias A Phase V VAXcluster (not released yet!) will work entirely different from a Phase IV cluster and will put special demands on ISO ISs on the LAN the VAXcluster is connected to. This will be a permanent requirement if Phase V cluster aliases are to be used. All nodes on a Phase V VAXcluster include multiple NSAP addresses in their ESH packets. One of them is the cluster alias address. This implies that the cluster alias NSAP will have several SNPA addresses (e.g. Ethernet addresses) associated with it, and this requires special handling by the ISO router. Cisco is supposed to implement support for this, but not in version 8.3, maybe in 9.0. When DECnet conversion is enabled, the cluster alias will then be "visible" in both domains. What IS unclear is if they will implement support for Phase V cluster aliases in an area running Phase IV only on routers. This is a unlikely situation and is probably not of any importance to the NORDUnet community. 4.7. Summary of the Recommendation This section summarizes the recommendation. The migration of the HEPnet connection is outlined in 4.5 above, and the technical implementation details must be left to the persons working with this. 4.7.1. NSAP Allocation The Phase IV prefix to use on NORDUnet will be: 47:0023:00-000007-0000-0001 4.7.2. Routing Topology The entire NORDUnet (where Phase IV <-> Phase V connectivity is needed) is made into one routing domain with the Phase IV prefix. This routing domain may overlap smaller routing domains mentioned in the general routing recommendations. In that case, multihoming Dec 13 13:59 1991 Page 26 CAN be used for end systems from category (b) and (c), but it doesn't have to. Assuming Cisco and Phase IV routers only (no WANrouters running Phase V software), the "migration" routing domain is called NDNDECNET (area tag = NDNDECNET). DECnet routing and DECnet conversion for the the NDNDECNET routing domain are enabled on most Cisco routers. When the topology, software and hardware, and the number of migrated hosts allow, consider removing the DECnet Phase IV routing from the backbone networks. (As long as the majority of DEC systems are Phase IV, the conversion load on the routers will be less if routing for both protocols is maintained). It is impossible to give detailed recommendation for WHAT routers should have DECnet conversion enabled, and when to migrate away from DECnet backbones. This must be determined in cooperation by the DECnet, DECnet/OSI and ISO CLNS managers on NORDUnet and the national networks. It will be a moving target as the software and topology change. Packet conversion (DECnet conversion in Cisco terms) should be enabled on every LAN with hosts as soon as possible. Exact timing depends on software and hardware availability. In a configuration that includes WANrouters, or other non-Cisco routers supporting the migration, make sure that all consequences are understood before enabling CLNS routing. We believe that the method Cisco selected for the migration support makes it possible to enable the conversion on all routers running both DECnet and CLNS (for the migration area tag) as soon as the software is stable. However, one restriction is that if a DECnet compatible area exist in the CLNS routing domain using the NDNDECNET area tag, there should also be at least one Cisco CLNS router in that area (CLNS and DECnet sense) running DECnet and the DECnet conversion for that area tag. Another restriction is that since no routing information is redistributed between the CLNS and DECnet worlds, the routing domain with the NDNDECNET prefix should be connected (because it is a CLNS routing domain). It is possible to have a partitioned domain, if static CLNS routes are configured, causing multiple conversions between CLNP and DECnet, but that SHOULD BE AVOIDED. 5. PILOT EXPERIENCE 5.1. DECnet/Ultrix V5.0 Not much to say yet. Until now, DECnet/Ultrix V5.0 has only been used in experimental configurations and in production Phase IV only environments. 5.2. VAX/VMS with DECnet/VAX Extensions To be supplied in a future version of this report. Dec 13 13:59 1991 Page 27 5.3. Sun with SunNet OSI SunNet OSI has performed rather well in practice. It doesn't seem to accept all 20 octect DCCs though and it implements the short term version of CLNP ping that is not compatible with the long term version implemented by cisco and other router vendors. No actual performance measurements have been made yet. 5.4 DEC WANrouters No experience yet, apart from the field test versions, and that is of limited interest here. 5.5. Cisco routers Cisco routers have been used almost exclusively in the pilot. They have had software problems ranging from configuration and routing troubles to actual crashes of the routers. It seems, however, that all serious problems have been fixed recently in version 8.3. Some people have reported problems even in 8.3, but they are likely to be X.25 rather than CLNS originated. What comes to the Cisco propriatery ISO IGRP, it seems as a suitable solution for a small scale CLNP pilot and allows dynamic routing both at intra- and inter-domain levels. The latter doesn't, however, scale well because there is no means to collapse information about routing domains sharing a common NSAP prefix. Also ISO IGRP doesn't currently support CLNS access lists that limits its usefulness in general CLNS environment. ISO IS-IS intra-domain routing protocol will be included in software version 9.0. The schedule for ISO IDRP is not known yet. APPENDIX A. CONFIGURING HOSTS FOR CLNS A1. Sun with SunNet OSI 7.0 and ISODE The following instructions are turned for running the public domain version of ISODE on top of SunNet OSI instead of the ISODE "lookalike" that comes with SunNet 7.0. Installing SunNet OSI involves (a) loading the software from the media to /usr/sunlink/osi, (b) running the configuration program /usr/sunlink/osi/etc/install.osi, (c) installing a new kernel, (d) configuring relevant files in /etc/sunlink/osi, and (c) rebooting the operating system. Assuming that (a) has been done, run install.osi as a super user. Below are hints on how to answer to the various questions that install.osi makes. - Choose to install OSI. You may choose to install X.25 also, but Dec 13 13:59 1991 Page 28 that requires the SunNet X.25 package which you may not have. Also, it is not currently possible to run "real" CONS and CLNS at the same time. So in the following we assume that you only install OSI. - Choose to use TP4 over CLNP. Again, don't choose to run TP4/CLNP over X.25 unless you have SunNet X.25. You may also choose to use RFC-1006 if you are not planning to install ISODE, which also provides an RFC-1006 implementation. - Choose to run OSI (TP4/CLNP/LLC1) on le0 (or whatever is your Ethernet interface). Again, don't choose TP4/CLNP over X.25 unless you have SunNet X.25. - You don't want your host to be a CLNP IS. - Choose an automatically generated NSAP even it will not be used, since it is easier to edit the relevant files later rather than trying to answer all questions that would follow. - Don't specify any optional addresses, since you can do that later. - Choose to use only dynamic routing on llc0 unless you want to experiment also with static routing (which should not be necessary). - Use default ES-IS multicast address. - You don't want to add entries for remote hosts and services since you can do it later, or if you are using ISODE, it has its own files for this purpose. - Choose to install /etc/sunlink/osi/rc, /etc/sunlink/osi/rc.config, /etc/sunlink/osi/routes, /etc/sunlink/osi/isoentities, /etc/sunlink/osi/isobjects, /etc/sunlink/osi/isoservices, /etc/sunlink/osi/isomacros, /etc/sunlink/osi/isotailor, and /etc/sunlink/osi/isodocuments. The iso* files are only needed by SunNet OSI applications. ISODE has the corresponding files of its own. - Choose to update your system files. - Have a new kernel configured. After you have configured and installed a new kernel, edit files 'rc', 'hosts' and 'routes' in /etc/sunlink/osi. - In 'rc', check that correct variables are "on". Normally if you don't have SunNet MHS, only osi and tp4_clnp should be "on". Further down the file, comment out the startup of tsapd if you are running ISODE and want to use its tsapd instead. - In 'hosts', edit the source address entry for outgoing calls to look like localhost { \ Dec 13 13:59 1991 Page 29 [(user-defined)4700230000000300000003000113117710414200] \ [(tsel)0] \ [(ssel)"NULL"] \ } CLIENT where 4700230000000300000003000113117710414200 is your host's NSAP. Comment out all other entries in 'hosts'. - In 'routes' edit my_addr_default to my_addr_default 'realNS=4700230000000300000003000113117710414200' where 4700230000000300000003000113117710414200 is your host's NSAP. You may also give additional addresses to your host by adding one or more my_addr_optional entries. When you have done all this, reboot the operating system. SunNet OSI should now get started since install.osi has added an entry to /etc/rc.local that runs /etc/sunlink/osi/rc. During the reboot watch the console for possible error messages. When SunNet OSI is up, you can compile and install ISODE to run on top of it. In order to do so, base your configuration on copies of $(SRCDIR)/config/sunnet7.h and config/sunnet7.make and proceed normally as described in $(SRCDIR)/README. Note that sunnet7.make doesn't by default build the ISODE libraries as shared libraries. In order to build dynamic ISODE libraries, edit sunnet7.make by importing the relevant parts from sunos4.make. Dynamic ISODE libraries will decrease the demand for memory on your system and will likely have a positive impact on performance especially if you plan to run several OSI applications simultaneously. After starting tsapd, you should be able to connect to your own host using TP4/CLNP. You can test this by adding an entry datanet-osi default 1.17.4.3.37.1.0 \ #1/NS+4700230000000300000003000113117710414200 where datanet-osi is the name of your host with NSAP 4700230000000300000003000113117710414200, to the local part of $(ETCDIR)/isoentities file and then running isode-test datanet-osi Similarly you should now be able to connect to other TP4/CLNP speaking hosts using various application protocols such as ftam, ds, and vt. It is also possible to add the presentation addresses of the ISO applications to the X.500 directory as an alternative to using the $(ETCDIR)/isoentities file. A2. Host with DECnet/Ultrix V5.0 This subsection applies to full DECnet/OSI end system implementations. Currently only DECnet/Ultrix V5.0 falls into this category. DECnet/VAX Extensions VMS hosts are described separately Dec 13 13:59 1991 Page 30 in Appendix A4. To start with, the general recommendation is to stay with Phase IV implementations (i.e. do NOT install DECnet/Ultrix V5.0) for a while (e.g. with DECnet/Ultrix V4.2) unless CLNS or ISO applications are badly needed. It is wise to wait until the necessary DECdns and DECdts infrastructure is present. They were expected to be present during fall 1991, but some late events reopened the possibility to join a global namespace already from the start which delayed the creation of our DECdns infrastructure. When that infrastructure IS available, or if you are prepared to live without it (i.e. create you own, which should be cleared by your network managers), the following recommendation apply. It is assumed that we live in a migration environment. In the future, when DECnet is completely phase out, the recommendations will change. The initial configuration is done by answering a couple of questions from the configuration script (/usr/etc/decnetsetup). The script is used at least twice. First to rebuild the kernel after installing the software, then for configuring the host. In the later case, two alternatives, basic and advanced, exists. The differences between these are whether the host should be configured as a DECdns and/or DECdts server system, and if more that one physical interface can be used for DECnet/OSI. If the system should be a DECdns/DECdts server should be determined by the local DECnet and DECnet/OSI manager, not the end system owner, but that is outside the scope of this document. National and Nordic DECdns managers decide what systems that should be used as DECdns servers on our global namespace. Note that what is described here is DECnet/Ultrix V5.0. In later versions, there may be additional questions and choices. Because of that, this section describes the answers, it does not list them literally. We do also assume a basic installation and leave out the questions related to DECdns and DECdts. The installation manuals and other documentation describes this in detail. Disable autoconfiguration of network addresses, unless you are very sure of what you and the local network management is doing! For systems from category (a) and (c), obtain a DECnet Phase IV address using the same procedures as today. A short name should also be assigned to all systems that need connectivity to Phase IV hosts (the Node synonym, comparable to, and following the same naming rules as, the Phase IV nodename). Assign a full/long name to the system. Normally, the same name as the host is given in the IP world should be used (reverse order, but that is a DECdns matter). If the systems isn't running IP, assign a name using the same naming scheme (......). The rest of the naming business is DECdns specific and not relevant in this document. It should be noted that automatic node registration won't be allowed on NORDUnet, so the network managers must manually enter your node in the namespace when you apply for a name and address. Dec 13 13:59 1991 Page 31 For systems from category (b), obtain address and name using the procedure for CLNS hosts that apply to your organization. In this case, no special DECnet considerations are needed. You must enter the Phase V (full) host name for you host. Include the namespace name! The namespace will be either OMNI (if we manage to join the global namespace from the start) or NORDUnet (if we use our own). You must also enter you node synonym, i.e. the Phase IV compatible short name for you node, if you choose to have one. You should if you need connectivity to Phase IV nodes. You must enter you Phase IV compatible address (in the Phase IV . format) unless you configure a system from category (b), in which case you enter 0. You must enter the Phase IV prefix (given in 4.7.1 for NORDUnet hosts). For systems from category (c) assign additional NSAP addresses using the procedures for general CLNS hosts in your organization. Your host will then be multihomed (up to three NETs per host). You have the possibility to enter these NSAP addresses during the configuration process. If the LAN you are connected to doesn't support DECnet migration (i.e. the packet conversion isn't supported) and ISO CLNS is run or is likely to be run in the (near) future, a routing filter MUST be installed. Today, the only full DECnet/OSI implementation is DECnet/Ultrix V5.0, and the filter is described in the release notes in section 2.7.2. (Execute "/usr/field/rouv_rtrfltr iv" before DECnet/OSI is started. Normally add this command in one of the DECnet/OSI startup files.). This makes your system a category (a) end system. On LANs supporting the migration, the routing filter may not be necessary, but the local network management should advise you on this. If the filter is needed or not depends on the status of CLNS and the migration on YOUR LAN. Remember that you may loose connectivity to Phase IV nodes when the packet conversion isn't turned on. (If the filter isn't installed, your end system is in category (c), or possibly, in (b)). A3. VAX/VMS with DECnet/VAX Extensions The only recommendation given here is to disable autoconfiguration of NSAP addresses and to avoid using area (the area field in the NSAP) in the 1-40h range. DECnet/VAX Extensions is not a full DECnet/OSI implementation and can at large be seen a a general ISO CLNS host. The DECnet Phase IV protocols run in parallel without any interaction with CLNS on Dec 13 13:59 1991 Page 32 these systems. Rest of this section to be supplied to a later version of this report. A4. PC with Novell 3.11 To be supplied to a laetr version of this report. APPENDIX B. CONFIGURING ROUTERS FOR CLNS This appendix contains examples of how routers can be configured for routing of ISO CLNS. Included are sections for Cisco routers and DEC WANrouters. B1. Cisco with CLNS Routing Using Cisco ISO IGRP This section will describe how to configure a Cisco router using Cisco ISO IGRP in the varius possible configurations: as an intra-area router (level 1 only), as an inter-area (level 2 and level 1) router and as an inter-domain router. These configurations can then individually be extended with static routing. Current Cisco software does not support IS-IS. The area/domain structure used in the examples is shown here: + - - - - - - - - - - - - - - - - - - + Domain 2 (university) ! + - - - - - - - - - - - - - - + ! ! ==+== ! ! ! +-+-+ ! ! ! ! A ! Area 66 (cs) ! ! ! +-+-+ ! ! ! ==+=========+== ! ! + - - - - - - - - - +-+-+ - - + ! ! B ! ! + - - - - - - - - - +-+-+ - - + ! ! Area 65 (u-bb) ! ! + - - - - - - - + ! ! ==+=========+== ! ! + - - - - - ! - - - - - - - - + ! + - - - - - + ! + - - - - - - - ! - - - - - - - - - - + ! ! +-+-+ + - - - - - - - - - + ! +---+ ! ! ! C +-----------------------+--+ D ! ! +---+ ! ! +-+-+ ! ! ! ! ! ! ! ==+== ! ! ! Area 65 ! ! ! (bb-area) ! ! Domain 1 (backbone) + - - - - - + + - - - - - - - - - - - - - - - - - + Router A is strictly area-internal. B is a router connecting two areas internally in a routing domain, routers C and D interconnect two routing domains. The common prefix used in the examples is Dec 13 13:59 1991 Page 33 47.0023.0000.0010, thus the (so far) unassigned admin author value of 000010 is used. The figure includes in parenthesis the area tags used by the Cisco IGRP-for-CLNS implementation on the Cisco. The area tags have local significance only. Note that the area numbers shown in the figure are in decimal, whereas the NSAPs specified in the configurations are in hexadecimal. The NSAP structure chosen is the same as the proposed NORDUnet structure. For further information on setting up Cisco routers for routing of ISO CLNS, see the "Cisco Gateway System Manual", chapter 11: "ISO Connectionless Network Services Routing (CLNS)." B1.1. Configuration for Router A: Level-1 Only Interface "Ethernet 0" is on the top of the figure. ! clns routing ! clns router cs NET 47.0023.0000.0010.0000.0002.0042.1292.4111.1001.00 ! interface Ethernet 0 clns router igrp cs ! interface Ethernet 1 clns router igrp cs ! Since this is an intra-area router, we use the same area tag for both interfaces. B1.2. Configuration for Router B: Level-2 (and Level-1) ! clns routing ! clns router cs NET 47.0023.0000.0010.0000.0002.0042.1292.4111.1002.00 clns router u-bb NET 47.0023.0000.0010.0000.0002.0041.1292.4111.1002.00 ! interface Ethernet 0 clns router igrp cs ! interface Ethernet 1 clns router igrp u-bb ! The routing information about the "other" area will automatically be distributed to other level-2 routers on the respective Dec 13 13:59 1991 Page 34 interfaces. B1.3. Configuration for Router C: Inter-Domain Router ! clns routing ! clns router igrp u-bb NET 47.0023.0000.0010.0000.0002.0041.1292.4100.1002.00 clns router igrp bb-area NET 47.0023.0000.0010.0000.0001.0041.1292.4100.1002.00 clns router igrp u-bb redistribute domain_bb-area clns router igrp bb-area redistribute domain_u-bb ! interface Ethernet 0 clns router u-bb ! interface Serial 0 clns router bb-area ! Information from the different routing domains are automatically injected into each other with the "redistribute" clauses. The "domain_" prefix given to the area tags (to convert them to domain tags) is fixed to this value by the Cisco software. B2. Configuring Cisco for DECnet conversion The first version of Cisco router software supporting the migration is 8.3, and although it now is available, we have no experience with it when this chapter is written and this section may therefore not be complete. As said in 4.7.2, choosing what routers that should have DECnet conversion enabled must be done when the software is installed and taking the rest of the NORDUnet and local network CLNS, DECnet and DECnet migration into consideration. The only new line that needs to be added in the configuration for a Cisco already running DECnet and CLNS (in at least the NDNDECNET routing domain) is "decnet conversion igrp NDNDECNET", which enables the DECnet conversion. B3. Configuring DEC WANrouters The WANrouters are configured with a menu driven procedure. The exact questions asked is not known for the final release. The result is a NCL file that will be compiled into a downloaded configuration. If any change outside the possibilites given by the configuration programs are needed, the NCL files must be manually edited (after reading the THICK NCL-manual) and recompiled. As far as can be said from the field test versions that we have Dec 13 13:59 1991 Page 35 worked with, the configuration program is sufficient for simple, straight forward cases. Complicated cases will need manual configuration and detailed knowledge about NCL as well as router and network topology in the local area and on the national networks.