home news blogs forums events research newsletter whitepapers careers


Network Computing Network Computing Network Computing
HOT PICKS

IMMERSE YOURSELF:

SOA

  |

Data Center

  |

802.11n

  |

Data Privacy

  |
APO  |

Virtualization

  |

NAC

  |

Security

  |

Network Mgmt

  |

Enterprise Apps

  |

Storage & Servers




Building an ATM Wide Area Network

July 26, 1999
By David Willis

Addressing and Routing

Building an ATM Address Plan
Each User-Network Interface (UNI ý the interface between an ATM end system and an ATM switch) in an ATM network has a unique identifier in the form of a 20 byte ATM address. This address is used by ATM devices for signaling and management functions, and by protocols such as PNNI.


Printer Print this Page
E-Mail E-mail this URL
Within PVC-only networks, it is not necessary to create a custom address plan. However, if you plan to use SVCs at any point in the evolution of your network, you'll save yourself some grief if you assign the appropriate addresses from the beginning.

The ATM Forum specifies two broad types of addresses : E.164 addresses, which use the same address space as the telephone network, and are intended for public use; and ATM End System Addresses (AESAs) for use in private or mixed private/public networks. Because users of private networks may desire to connect to other private ATM networks, registration authorities are used to obtain AESA address prefixes.

AESA addresses may be constructed in one of four formats

- The Data Country Code (DCC) format, using codes administered by each country's ISO member body.

- The International Code Designator (ICD) format, using codes administered by the British Standards Institute. This is the default format used by many switches.

- NSAP encoded E.164 format.

- Local format, using any structure desired within a private network.

As noted in the diagrams, each format specifies a High-Order Domain Specific Part, which is used along with the higher order bits to route calls to the appropriate switch. In this regard, the E.164 AESA format leaves the fewest number of octets available for route aggregation in hierarchical PNNI networks, whereas the local format leaves the most. The End System Identifier portion of the address is typically the endpoint's MAC addresses. The Selector field may be used for internal purposes by the endpoint, much like IP port numbers are used to identify an application.

When building a completely private network that will never be interconnected with other networks or an ATM Service Provider (ASP), a private addressing plan can be used. However, if you'll be using an ASP that supports SVCs you'll obtain your addresses from the carrier. Fortunately, your equipment should be able to use the Integrated Local Management Interface (ILMI) protocol to discover addresses of switches at the edge of the ASP's network ý but substantial readdressing within your own internal network may be required if you extend the carrier's scheme and change providers.

Alternatively, you can apply for your own addresses with the appropriate address registrar and use the DCC or ICD formats. In North America, the American National Standards Insitute (ANSI) assigns DCC codes in the form of a unique, permanent organizational name to approved applicants. A derivation from this name is then used as a prefix within the larger ATM address space. The British Standards Institute assigns ICD addresses ý contact see http://www.bsi.org.uk/disc/iota.html. for more information.

If you'll be building a large network backbone which will require hierarchical PNNI, you'll achieve more scalability if you make the prefix of your addresses location-specific. This will allow address aggregation and more efficient routing.

If your equipment provides an E.164 gateway feature, calls within from AESA-addressable endpoints can be statically mapped to E.164 addresses for transport across a carrier network. If you use the NSAP encoded E.164 format, address conversion can be automatically performed by your equipment.

For more detail on ATM addressing, see the ATM Forum's User Guide to Addressing at

ftp://ftp.atmforum.com/pub/approved-specs/af-ra-0105.000.pdf

Routing within the ATM Network
In an all PVC environment, virtual circuits (VCs) are treated like static links with a simple mapping between IP interfaces and ATM VCs. Some equipment allows for the relative classification and queuing of IP traffic which is mapped onto an ATM PVC. For example, IP packets may be prioritized by the IP Precedence field in the Ipv4 packet header and in turn placed on the VC in the most appropriate order.

In an SVC environment, where the best route for a call is determined at setup time, ATM routing can be static or dynamic. The Interim Interswitch Signaling Protocol (IISP) is a simple mechanism for assigning fixed, static routes between switches. With IISP, all routing decisions are made on a hop-by-hop basis, preventing end-to-end Quality of Service and providing limited ability to route around congestion or link failures. IISP also requires substantial administration and is not recommended.

In contrast, the Private Network Node Interface (PNNI) protocol provides dynamic control over ATM routes. It is a highly scalable, QoS-aware link state routing protocol that can support source routing and alternate routing during link or connection setup failures.

Flat or Hierarchical?
Most equipment supporting PNNI defaults to a single-level, flat network topology, using addresses automatically determined upon installation. But the real power of PNNI is in its ability to support hierarchies of switches for better scalability. If you think you'll ultimately need to use hierarchical PNNI, you should design an addressing scheme that will allow for maximum growth before the first switch is installed ý you won't want to renumber later.

There are several reasons to adopt a hierarchical PNNI topology. Traffic load and performance may be improved by reducing the amount of topological information that switches have to maintain. By assigning switches to a common peer group, the local topology of those switches is hidden from outside view for better administration. Yet there is a cost to this consolidation ý it limits the information that may be used for routing decisions. Thus you won't want to combine just a handful of switches to form a peer group, but instead choose to group a large number of switches that form a natural administrative boundary.

Your addressing plan is key to providing route aggregation. As noted, you should use addresses to identify the topological location of switches, using the High-Order Domain Specific Part of the ATM addresses to identify levels in the hierarchy. You'll need to determine the maximum number of levels your organization will require, even if you don't plan to use all of them in your initial installation.

For more information on PNNI, see ftp://ftp.atmforum.com/pub/approved-specs/af-pnni-0055.000.pdf



PAGE: 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 I 10 I 11 I 12 I 13 I NEXT PAGE
 





Ready to take that job and shove it?

Function:

Keyword(s):

State:
SPONSOR
RECENT JOB POSTINGS
CAREER NEWS
Go beyond Google and get vertical. These specialized search sites will help you find the business information you need -- fast.

Ari Balogh was named to the post of chief technology officer as the companys for a "realignment" of employees.










InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Purchase Today: $299
 
ROLLING RIGHT ALONG
Follow key Network Computing Reviews from conception to completion. This Week: Holistic APM.



Network Computing Reports Emerging Enterprise Podcast Series: Secrets to Success








TechSearch


Microsite of the Week


Powerful Information at Your Fingertips



techweb
Online Communities TechWebInformationWeekLight ReadingIntelligent EnterprisebMightyNetwork ComputingDark ReadingDigital LibraryWall Street & Technology
Byte & SwitchNo JitterInternet EvolutionLight Reading's Cable Digital NewsContentinopleUnStrungBank Systems & TechnologyAdvanced TradingInsurance & Technology
Face-to-Face Events
InteropWeb 2.0 ExpoWeb 2.0 SummitVoiceConBlack HatCSISoftwareEntrprise 2.0 ConferenceGTEC
Mobile Business Expo
InformationWeek 500 ConferenceBuy Side Trading XchangeBuy Side Trading SummitBank Executive SummitInsurance Executive SummitTelcoTVEthernet ExpoOptical Expo
Magazines  
InformationWeekWall Street & TechnologyInsurance & TechnologyBank Systems & TechnologyAdvanced TradingMSDNTechNetSmart EnterpriseThe Architecture JournalDatabase Magazine
 
Research & Analyst Services  
Heavy ReadingInformationWeek ReportsInformationWeek Analytics
 
   
   
App Infrastructure   |   Messaging & Collaboration   |   Network & Systems Mgmt   |   Network Infrastructure   |   Security  |   Storage & Servers   |   Wireless   |   Enterprise Apps
About Us  |  Contact Us  |  Site Map  |  Technology Marketing Solutions  |   Briefing Centers
Copyright © 2008  United Business Media Limited  |  Privacy Statement  |  Terms of Service  |  Your California Privacy Rights