TITLE: Routing and Addressing in ATM Networks SOURCE: Juha Heinanen, Telecom Finland PO Box 228, SF-33101 Tampere, Finland Tel: +358 49 500958 Fax: +358 31 2432211 Internet: jh@datanet.tele.fi Abstract: This contribution proposes the use of ISO NSAPs as ATM Called party and Calling party identifiers in addition to or, preferably, instead of E.164 addresses. It gives several examples on how the NSAPs can be formatted for ATM purposes and also shows how standard ISO routing protocols can be used to dynamically route NSAP based ATM calls. 1. Introduction For some reason, none of the original 14 B-ISDN recommendations deals with address- ing and routing in B-ISDN networks, which should be a very important topic in the design of any new network architecture. Accordingly, E.164 addresses as ATM Called and Call- ing party identifiers seem to have been crept in to Q.93B from N-ISDN Q.931 without any real debate. The axiom has been that public ATM networks will not support anything else but E.164 addresses, which is clearly not true in any competitive situation. It is therefore a high time to take a fresh look at the ATM addressing from the users' perspective. The basis of E.164 addressing is the B-ISDN reference configuration, as described in I.327, which falsely assumes the existence of a single public B-ISDN to which all private B-ISDNs connect as end networks. As witnessed by the increasing interest in ATM as a private network technology, a more realistic reference configuration would describe the overall ATM architecture as an arbitrarily connected mesh of private and public ATM net- works (B-ISDNs) covering both local (LATMs) or wider (WATMs) areas. Such an infra- structure is called an ATM internet (figure 1). If the ATM internet model is accepted as the new basis for an overall B-ISDN reference configuration then also ATM addressing and routing issues need to be revisited. This con- tribution suggests that in an ATM internet ISO NSAP addresses should be used as Called and Calling party identifiers in addition to or, preferably, instead of E.164 addresses. We begin by showing how ISO NSAPs are structured and compare ISO NSAPs with E.164 addresses. Then we describe several possible NSAP formats that could be used in various kinds of ATM networks. Finally, we discuss how ISO routing protocols can be used to dynamically route calls based on ISO NSAPs no matter which of the formats are chosen. A Numbering plan code point value 0010 denoting an ISO NSAP has already been allocated in Q.93B for the Called party number and Calling party number IEs. This contri- bution is thus compatible with the current version of Q.93B and doesn't require any changes to it. It may, however, be desirable to add one more code point to the Numbering plan field to denote IEEE 48 bit MAC addresses. IEEE MAC addresses could be useful in relatively small private ATM networks, for example, for bridging purposes. It is, however, unrealistic to suggest that IEEE MAC addressing could also be supported by public ATM networks due to the scaling problems caused by the flat address space. 2. Structure of ISO NSAPs The abstract syntax and semantics of OSI Network Service Access Point (NSAP) addresses (NSAPs) is defined in ISO 8348 Adendums 2, 4, and 5. ISO NSAPs are either Digital Country Code (DCC) or International Code Designator (ICD) based. They start with a one octet Authority and Format Identifier (AFI) followed by a two octet Initial Domain Identifier (IDI), and a maximum of 17 binary octet or 35 decimal digit Domain Specific Part (DSP) (figure 2). The AFI selects the authority responsible for allocating the values of the IDI (in this case a DCC or ICD authority) and the abstract syntax of the DSP (binary or decimal). It also tells whether the NSAP defines a unicast or a multicast (group) address. In the DCC case, the IDI selects a country and in the ICD case, an international organization. The structure of the DSP is decided by each country or international organization. ISO NSAPs form a superset of E.164 addresses in that the latter can be easily mapped to the former (see section 3). Therefore, properly structured ISO NSAPs as Q.93B Called and Calling party identifiers would provide at least the same functionality as E.164 addresses. In addition, ISO NSAPs have several advantages over E.164 addresses. For example: o ISO NSAPs can be used to uniquely identify terminals no matter if they are connected to public or private ATM networks. o ISO NSAPs are longer than E.164 addresses. This allows more hierarchy and capability to address any station even in a very large ATM internet without a need for subaddres- sing. ISO NSAPs also have room to embed a unique terminal (host) identifier in to the NSAP, which is useful when routing to mobile ATM terminals. o ISO NSAPs don't need to denote a particular subscription point to an ATM network. This improves robustness, since calls to the ATM network can be routed via any cur- rently operational subscription point. o State of the art ISO NSAP based dynamic routing protocols are already available that can be used for call (re)routing in an ATM internet both within (ISO 10589) and between (ISO DIS 10747) routing domains. o ISO ES-IS protocol (ISO 9542) can be used by ATM switches and terminals (hosts) to automatically learn about each other. Also, hosts can use ES-IS protocol to automati- cally learn the high order part of their ISO NSAPs. o Addresses of many exiting network layer protocols can be mechanically mapped to NSAPs (CLNP is using NSAPs natively), which eliminates the need for a complex mapping of network layer addresses to ATM addresses. Because of these advantages, and since no functionality is lost as compared to E.164, it is proposed that ISO NSAPs should be used in addition to or instead of E.164 addresses for ATM Called party and Calling party identification. 3. Possible NSAP formats for ATM networks ISO NSAP addresses can be formatted and allocated in several different ways. Three of the most commonly suggested allocation schemes are: o geography based o provider based o organization based A fourth possibility is o network address based which can be used to map existing network layer addresses to NSAPs. Geography based NSAPs would use the ISO DCC format and within each country the DSP could hierarchically select the geographical location of the addressed hosts. Below is an example of a geography based NSAP format: 39 country state city block house apartment host-id nsel The problem with geography based NSAPs is determining the final provider to which the customer is attached to. They have therefore not been popular in existing networks. In order make an NSAP address routeable with IS-IS (see section 4), the host-id must in all NSAPs be exactly 6 octets long and be followed be followed by a one octet Network Selector (nsel). The host-id can have any value as long as it uniquely identifiees a host within its scope (an apartment in the above example). One possibility to achieve this is to use IEEE 48 bit MAC addresses as host-ids, which has the additional advantage that host-ids become globally unique. The value of nsel has no significance when NSAPs are used to identify endpoints in an ATM network. Provider based NSAPs would use either the ISO DCC or ISO ICD format depending on whether the provider is a national one or an international one, respectively. It would, of course, be also possible for an international provider to register itself nationally in each operating country. Below is a concrete example of a provider based NSAP format: 39 country provider lata exchange subscriber host-id nsel The advantage of provider based addressing is that it matches well with routing and allows keeping the routing tables small at each level of the hierarchy. The disadvantage is that if a customer changes a provider, it has to change its addresses too. Automatic learn- ing of addresses, for example, with the help of ES-IS protocol, is therefore a necessary requirement. Note that E.164 addresses could be straightforwardly mapped to the above provider based NSAP format. Organization based NSAPs would use either ISO DCC or ISO ICD format depending on whether the organization is a national one or an international one, respectively. As above, it would again be possible for an international organization to register itself nation- ally in each country. Below is a concrete example of a provider based NSAP format: 39 country organization routing-domain area host-id nsel This kind of format has already been adopted by many national ISO members, e.g., ANSI. Organizational format would be suitable, for example, for private ATM networks not using any service provider. It would also be possible for service providers to support organizational NSAP addresses, but the problem is scaling, since each provider within a country should be aware of all organizations, i.e., also those served by other providers. Finally, network address based NSAP formats can be designed to allow automatic mapping of existing network layer addresses to NSAPs. Such mappings may be desirable if a name server (e.g. DNS or X.500) is not available that would map a name of an ATM host directly to a real provider or organization based NSAP. The general format for net- work address based NSAPs could be the following: 47 ATM-FORUM addr-type [organization] [network-or-area] host-id nsel ATM-FORUM is an ICD code to be assigned to the ATM Forum. addr-type specifies the type of the mapped network layer address, e.g., IP, Novell IPX, Apple Talk, or DEC- net. addr-type would not be strictly needed, but its presence allows "smart" ATM switches to find out and extract the real network address from the NSAP. With the exception of IP and CLNP (which uses NSAPs), network layer addresses can- not be guaranteed to be globally unique. It may still be desirable to route based on them within a single organization even over a public ATM network. This can be accomplished by prefixing the network layer address in the NSAP by a unique organization identifier assigned to the customer by the public ATM service provider. A network-or-area component is present if the mapped network layer address has such a component and if it can be uniquely identified. This is the case at least with DEC- net, Novell IPX, and Apple Talk addresses, but is not the case with IP addresses, where there is no syntactic way to determine the network/host-id boundary. Finally, the host identifier portion (or the whole network address in case the network- or-area field is not present) of the network address is mapped to host-id field of the NSAP. If the result is not 6 octets long, host-id it must be padded from the right with zeros in order to be effectively routeable with IS-IS. Below are some concrete examples of network address based NSAPs. An IP address 128.214.105.2: 47 ATM-FORUM IP 80D669020000 00 A DECnet address 47.166 including a unique two octet organization field 0034: 47 ATM-FORUM DECNET 0034 2F 920000000000 00 A Novell IPX address 115F362C.00001B234926 without a unique organization field: 47 ATM-FORUM IPX 115F362C 00001B234926 00 An AppleTalk address 43256.130 without a unique organization field: 47 ATM-FORUM APPLETALK A8F8 820000000000 00 An addr-type value could also be allocated for IEEE 48 bit MAC addresses and the MAC address placed to the host-id field of the NSAP. However, since IEEE is a recog- nized body in CCITT, an alternative is to ask CCITT to allocate a new Numbering plan code point for IEEE 48 bit MAC addresses. ISO NSAPs can also be used to support multicasting, since for each unicast AFI there exists a corresponding multicast AFI (see figure 2). Multicast NSAP formats could include a scope field that would restrict the scope of the multicast group to a single subnet, area, domain/subscriber, organization/lata, or country or it could specify that the scope is glo- bal. In the subnet case, the host-id could be a valid IEEE multicast MAC address. In the other cases, the the NSAP field specified by scope could identify a multicast group iden- tifier. Details related to multicast addressing are left for further study. 4. Call Routing Based on NSAPs A major advantage of ISO NSAP based ATM addressing is that allows calls to be routed through an ATM internet using standard, state of the art ISO routing protocols. Another advantage is that the ATM switches don't need to care about various NSAP for- mats or addressing plans, since routing works as long as the NSAPs obey the simple for- matting rules outlined above. The ISO routing protocols simply deal with NSAP prefixes and host identifiers as follows. IS-IS is used inside a routing domain and it works at two levels. At the routing domain level, IS-IS routes based on so-called area address portion of the NSAP towards each area. The area address consists of all fields of the NSAP up to, but not including, the host- id field. At the area level, IS-IS routes towards the individual hosts based on the host-ids. IS-IS learns about the hosts by listening the ES hello packets that the hosts send period- ically to the ATM switches. The hosts (and other ATM switches), in turn, learn about the ATM switches by listening the IS hello packets that the switches send periodically to the hosts and to each other. The hosts can also configure the area address portion of their NSAPs automatically by extracting them from the received IS hello packets. Note that IS-IS scales well if the NSAPs include a subscriber or network-or-area field before the host-id field. Since mapped IP addresses don't have such a field, an IP domain can consist of only a single area. It is therefore desirable to modify the DNS to include real provider or organization based NSAPs as soon as possible. IDRP (Inter-domain Routing Protocol) is used between routing domains, e.g., between public as well as private and public ATM networks, and also between private ATM net- works when they belong to different organizations. IDRP routers (in this case ATM switches) advertize to their neighbors what NSAP prefixes are reachable behind each other. They also learn about the actual routing domain path (RDP) that must be traversed in order to reach each NSAP prefix. The RDPs can be used to implement a routing policy for the domain. It is naturally also possible to filter received or sent routing information according to the policies of the ATM networks. In case of mapped IP addresses, a routing domain, e.g. a LATM, would advertize to its neighbors the bit prefixes of the IP network or subnetwork numbers server by the routing domain. This is functionally equivalent to advertizing IP prefixes using BGP-4. Figure 3 summarizes the routing protocols that could be active at each ATM switch and host in parts of an example ATM internet. Note that this routing model also supports call routing to/from non-ATM hosts, since a conventional router can act as a proxy for the non-ATM hosts by advertizing to the ATM switch an NSAP prefix or area address that includes all of them. This feature can cause setting up several parallel ATM VCs between the same host and router, which may not desirable in all situations. 5. Implementation Plan Adopting the above described addressing and routing architecture doesn't mean that each switch has to support IDRP, IS-IS, nor even ES-IS immediately, since all these com- ponents can be initially replaced by static routes. ES-IS is not needed if each host and ATM switch is manually told about its immediate neighbors. IS-IS, in turn, can be replaced by static tables that at each ATM switch belong- ing to the routing domain tell which areas are behind each neighboring switch and which neighbors serve which destinations outside the routing domain. Finally, IDRP can be sub- stituted by manually configured tables that contain the NSAP prefixes served by each neighboring switch in other routing domains. For example, it might well be enough in an international border switch to list which DCC prefixes are served by each neighbor. Assuming a reasonable, e.g. a provider based, addressing plan, it would be easy to man- age even a quite large ATM network just be using static routes. Dynamic routing with IS- IS, IDRP, and ES-IS, however, adds considerable value both to private and public ATM networks by decreasing manual configuration work both in hosts and ATM switches, by supporting dynamic rerouting of calls in case of link or switch failures, and by simplifying policy based routing. It would thus be beneficial to both network operators and users if dynamic routing capabilities would be added to the ATM switches as soon as possible. One big advantage of NSAPs is that there is already in place official addressing author- ities from which organizations (including the ATM Forum itself) and network providers can acquire unique NSAP prefixes for their own use or redistribution. Another one is the existence of standardized routing protocols. Both of these important for fast, widespread deployment of high-quality ATM services. 6. Conclusions This contribution has shown the advantages of using NSAPs as ATM Called and Call- ing party identifiers. It has given examples of NSAP formats that could be useful in vari- ous kinds of ATM internets and outlined how standard ISO routing protocols could be used to route calls based on any kind of NSAPs fulfilling certain simple constrains. Is is suggested that ATM Forum and other ATM interest groups would adopt the above NSAP based model for ATM routing and addressing rather than sticking only to E.164 addressing or inventing yet another, add hoc addressing scheme.