DC-PNNI provides the ATM PNNI Routing layer (V1.0), including
- border node
- peer group leader
- multiple peer group support.
DC-PNNI includes exit points in the core code to allow OEMs to provide value-add services to the base functionality. For example, such exit points allow the customisation of
- user-defined route calculations
- route preference based on traffic parameters and current resource availability.
Functions and Features
This section describes the full set of functions provided by DC-PNNI. Flexible licensing options are available, restricting the range of supported functions to fit the functional requirements of the system being constructed. Functions marked * in the list below may be included or excluded depending on the scope of your license. Other functions listed are available in all versions.
DC-PNNI provides an ATM Forum-compliant ATM PNNI implementation which supports
- Single Peer Group
- Multiple Peer Group *
- Peer Group Leader Election
- Peer Group Leader *
- Hello Protocol
- Database Synchronisation
- Aging PTSEs in the Topology Database
- Advertising and Summarising Reachable Addresses
- Path Selection and Generic CAC
- SVC Support *
- Border Node *
- Fault Tolerance *
- Routing Services Caching and Partial Updates *
- Distributed Architecture
- MIB Management (including all tables in the PNNI MIB as specified in the ATM Forum PNNI Specification) *
Supported PNNI Routing Packets
The PNNI Routing function within DC-PNNI supports the following packet types.
- DATABASE SUMMARY
- HELLO
- PTSE REQUEST
- PTSE ACKNOWLEDGEMENT
- PTSP
Fault-Tolerant Operation
DC-PNNI has been architected to split the topology database from the routing engines, giving a number of benefits.
- A backup copy of the routing engine can run on a separate card.
- The routing database is optimised for very fast route calculations.
- A single PNNI node can support multiple routing engines.
- The route calculation processing can be distributed away from a central processor, allowing call forwarding to happen without requiring the involvement of the central processor. This avoids both a processing bottleneck and a single point of failure.
For fault-tolerant operation, a PNNI routing engine runs on each of the primary and secondary systems. When the primary fails, the secondary routing engine is unaffected and a new instance of the PNNI topology database is instantiated on the secondary. As the new topology database is synchronised with adjacent PNNI nodes, the routing is also updated. During this period, however, the routing engine can continue to make routing decisions independent from the central database, and calls can continue to be established, minimising the effect of the hardware failure.
For more information about Data Connection's ATM products and expertise contact .