ATM Routing

ATM Addressing

Introduction to ATM Routing

For any but the simplest ATM network (one consisting of a single switch), routing a call among ATM switches is a major issue. There are several (mostly non-interoperable) ways that the routing is handled in ATM networks.

The most common is IISP (Interim Inter-switch Signaling Protocol), in which you manually program each and every ATM switch with the routes (generally the ATM network prefixes) of every switch in the network. The routes take the form of "if you want to get to an ATM end point with this network prefix, route the cells through output port XYZ". This is obviously labor intensive to set up and maintain and isn't scalable. For more than two switches it pretty much becomes unworkable.

Many vendors have proprietary routing protocols that do "route discovery", that is, they have a mechanism to query their neighbors and learn where all the other switches on the network are. Lucent has LNS (Lucent Network Service). Fore has Forethought. These of course are non-interoperable, and although they eliminate the labor of setting all the routes up manually, they still aren't scalable in the sense of working in a heterogeneous network. LNS, for example, works by querying all the neighbor switches then building IISP routes just as if you had typed them in by hand (it looks like you did just that if you ask the switch what routes it has).

PNNI (Private Network-Network Interface) is the non-proprietary ATM Forum specified route-discovery protocol. PNNI is the ATMF-sanctioned way to handle route discovery. PNNI switches exchange topology information in real time, including updates, and are able to self-configure when placed in a network. This, plus ILMI (which allows the end station to self-register its end system identifier with its ATM switch) eliminates a lot of the manual configuration work.

The ITU has a seperate routing standard for public networks. B-ISUP (Broadband Interim Signaling User Protocol) is an offshoot of SS7, the telephony WAN signaling standard. The ATM Forum has defined a subset of B-ISUP, B-ICI (Broadband InterCarrier Interface). B-ISUP is sort of to B-ICI what PNNI is to IISP, in terms of scope, functionality, and degree to which it is implemented.

ATM Forum is working on a BISUP-PNNI interoperability spec called AINI, for ATM Inter-Network Interface. This will Yet Another protocol that allows you to connect PNNI (private) networks with BISUP (public) networks and have the routing information handled (we hope).

PNNI is hierarchical so that every switch doesn't have to know where every other switch is located. But generally among a LAN of switches, one switch will know more about the network at large, and then in the larger group of LANs, one (or more) switches will know about the still larger network, etc. So PNNI has a way for these switches to interrogate the local "map keeper" for their "routing domain", then up the chain, until a route can be discovered.

PNNI also has this concept of "crank back" where a route is selected, but as the SETUP is processed, some switch denies it (for example, due to Connection Admission Control or CAC rejection) then the route is cranked back to the point behind the failure and a new route is selected. The software developers reading this will recognize that this is a depth first search of the ATM network for a suitable route. PNNI requires that ATM switches keep their map keeper updated with enough state information regarding port usage such that crankback is hopefully minimized by selecting routes through lightly loaded ports. Specifically, PNNI uses two metrics, Cell Rate Margin (CRM) and Variance (VAR), to describe loading on each port on an ATM switch. CRM is a measure of "headroom" or how much bandwidth is available, and VAR is a measure of the burstiness of the existing connections. The typical CAC algorithm computes and maintains CRM and VAR measurements per port, whether or not it uses these metrics itself to make decisions as to the admissability of new connection requests.

Due to the dynamic nature of SVC creation, the available bandwidth along any path may change very quickly over time. Also, a VC setup may specify different bandwidths in the forward and backward directions. CAC algorithms often only allocate bandwidth on the output ports on an ATM switch, the allocation of input bandwidth being the responsibility of the upstream ATM switch. Is it possible for a CAC algorithm to reject a connection from ATM switch A to ATM switch B, but allow a connection to be made from ATM switch B to ATM switch A using the same traffic contract, because of different aggregate forward and backward allocated bandwidths, or because of bandwidth allocated for traffic aggregation on other ports? It would be an interesting failure mode. It does seem obvious that if a VC had identical forward and backward traffic contracts, if it succeeds from A to B, it should succeed from B to A all other things being equal. But it should be possible for a VC with a different forward and backward traffic contract -- for example a point-to-multipoint connection -- to work in one direction but not the other. In voice applications, this would result in one-way talk paths.

For efficiency and scalability, PNNI depends upon intelligent selection of ATM addresses for each ATM switch in the network. Making the right choice for ATM addresses can make the difference between PNNI working fast and reliably versus SETUPs taking many seconds and the ATM network melting down. Unfortunately this requires that you allocate ATM addresses in a hierarchial manner, and doing it right the first time to boot. This is a lot harder than it sounds (I believe, anyway), since changes to the ATM network that seem otherwise minor may be difficult to accomodate without hosing up PNNI or re-administering all ATM switches and end devices with new addresses. (If it's any consolation, the Internet faces a similar problem.) The issue is how much each ATM switch has to know to route a call. If done correctly, all routing may be done using just a subset of a single ATM network prefix. If done tragically wrong, each SETUP may require each ATM switch to search a table of many separate and unrelated full ATM network addresses. Furthermore, ATM switches will spend lots of CPU time transmitting these network addresses to one another, time that could have been used setting up SVCs.

References

Interim Inter-switch Signaling Protocol (IISP) Specification v1.0, ATM Forum, af-pnni-0026.000, December 1994

Private Network-Network Interface Specification Version 1.0 (PNNI 1.0), ATM Forum, af-pnni-0055.000, March 1996

ATM User-Network Interface Specification Version 3.1, ATM Forum, af-uni-0010.002, September 1994

Integrated Local Management Interface (ILMI) Specification Version 4.0, ATM Forum, af-ilmi-0065.000, September 1996

Author

J. L. Sloan jsloan@diag.com 2005-08-16