Private Network-to-Network Interface (PNNI) Route Selection

Available Languages

Download Options

PDF (138.1 KB)
View with Adobe Reader on a variety of devices
ePub (134.5 KB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (176.8 KB)
View on Kindle device or Kindle app on multiple devices

Updated:February 21, 2019

Document ID:19131

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Prerequisites

Requirements

Components Used

Conventions

PNNI Route Selection

Illustration of the Route Selection

Example 1

Example 2

Example 3

Conclusion

Related Information

Introduction

Private Network-to-Network Interface (PNNI) is a suite of network protocols that can be used in order to discover an ATM network topology, create a database of topology information, and route calls over the discovered topology. When you plan properly, the set up of a PNNI network is much easier and faster than the manual configuration of connections through an ATM network.

This document illustrates the PNNI route selection process through the use of several examples.

Prerequisites

Requirements

Cisco recommends that you have knowledge of PNNI. Read these documents for a detailed explanation on PNNI:

Introduction to PNNI (from Cisco PNNI Network Planning Guide for MGX and SES Products, Release 5.2)
Configuring ATM Routing and PNNI
ATM Traffic Management

Components Used

The information in this document is based on these software and hardware versions:

Cisco Catalyst 8540 MSR that runs Cisco IOS® Software Release 12.1(7a)EY1
LightStream LS1010 that runs Cisco IOS Software Release 12.1(7a)EY

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

PNNI Route Selection

PNNI uses source-routing, where the source is responsible for the selection of the destination path. More precisely, the first node of each peer group selects the path across that peer group. The selected path is encoded as a Designated Transit List (DTL) which is included in the connection setup. This DTL specifies every node through which the call setup transits.

This explanation has been taken from the path selection of the PNNI 1.0 specification (af-pnni-0055.0, section 5.13):

"When selecting a route to a destination ATM address, a node shall always route to the node which has advertised the longest prefix which matches the destination. If only nodes with the longest matching prefix are ancestors then the destination is not reachable. Only when several nodes have advertised equal length matching prefixes which are all longer than any other advertisement may the calculating node choose on a local basis which destination to use. Of the nodes advertising equal longest matching prefixes ignore any ancestors and select among the remaining ones, if any."

On Cisco devices, the route selection to a destination ATM address is based on this criteria:

The most preferred route is the one with the longest ATM prefix match.
If several matches exist, then the route selection is based on the precedence of the routes found. The lower the precedence, the higher the priority.
If there are several routes with equal priority, then take the route with the better administrative weight.

This is the default precedence associated with each route:

switch#show atm pnni precedence

                                 Working   Default
  Prefix Poa Type                Priority  Priority
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~  ~~~~~~~~
  local-internal                    1         1
  static-local-internal-metrics     2         2
  static-local-exterior             3         3
  static-local-exterior-metrics     2         2
  pnni-remote-internal              2         2
  pnni-remote-internal-metrics      2         2
  pnni-remote-exterior              4         4
  pnni-remote-exterior-metrics      2         2

These values can be modified with the precedence [prefix type] [priority] command. This is an example:

switch#configure  terminal

Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)#atm router pnni
switch(config-atm-router)#precedence ?
  pnni-remote-exterior           Remote Exterior Prefix Without Metrics
  pnni-remote-exterior-metrics   Remote Exterior Prefix With Metrics
  pnni-remote-internal           Remote Internal Prefix Without Metrics
  pnni-remote-internal-metrics   Remote Internal Prefix With Metrics
  static-local-exterior          Static Exterior Prefix Without Metrics
  static-local-exterior-metrics  Static Exterior Prefix With Metrics
  static-local-internal-metrics  Static Internal Prefix With Metrics
  <cr>

switch(config-atm-router)#precedence pnni-remote-exterior ?
  <2-4>  Priority For Remote Exterior Without Metrics

switch(config-atm-router)#precedence pnni-remote-exterior 2

Illustration of the Route Selection

These three examples illustrate the PNNI route selection and use a single peer group.

Example 1

Network Diagram

Use this network diagram in this example:

Note:

Budvar and Platan are Cisco Catalyst 8540 MSRs that run Cisco IOS Software Release 12.1(7a)EY1.
Miles is a LS1010 that runs Cisco IOS Software Release 12.1(7a)EY.
Devices A and B can be any type of devices able to establish SVCs.

Goal

This first test illustrates the fact that PNNI takes the longest match prefix, the route, with the higher priority, thus the lower precedence, first in order to route a call. In this example, Constant Bit Rate (CBR) call setups are made from device A to device B. These call setups can use these two different but equal paths with the same administrative weight in order to reach device B:

Through Budvar and Platan
Through Budvar and Miles

In this example, Platan advertises an internal PNNI route to device B and Miles advertises an external PNNI route to device B. Normally, in accordance with the definition of the path selection, Budvar must route the call via the PNNI internal route.

Illustration

Device B has this Network Service Access Point (NSAP) address: 47.0091.8100.0000.00d0.58b8.5555.0000.0000.0001.00

See two routes for that destination when you look at the ATM routing table on Budvar:

budvar#
show atm route

Codes: P - installing Protocol (S - Static, P - PNNI, R - Routing control),
       T - Type (I - Internal prefix, E - Exterior prefix, SE -
                 Summary Exterior prefix, SI - Summary Internal prefix,
                 ZE - Suppress Summary Exterior, ZI - Suppress Summary Internal)

P  T Node/Port        St Lev Prefix
~ ~~ ~~~~~~~~~~~~~~~~ ~~ ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
P  I 10  0            UP 0   47.0091.8100.0000.00d0.58b8.5555.0000.0000.0001/152
P  E 14  0            UP 0   47.0091.8100.0000.00d0.58b8.5555.0000.0000.0001/152

budvar#
show atm pnni identifiers

  Node  Node Id                                              Name
  1       56:160:47.00918100000000D058B79A01.00D058B79A01.00 budvar
  10      56:160:47.00918100000000D058B84201.00D058B84201.00 Platan
  14      56:160:47.0091810000000050E2030601.0050E2030601.00 Miles

As previously explained, there is an internal PNNI route learned from Platan and one external PNNI route learned from Miles.

Upon the reception of the call setup from device A to device B, Budvar can compute a DTL as well as the path through Platan. This output shows how Budvar computes the DTL.

budvar#show atm pnni dtl address 47.0091.8100.0000.00d0.58b8.5555.0000.0000.0001.00 cbr pcr 5000 5000
budvar#
00:42:34: PNNI: rcv CBR route req to addr 47.00918100000000D058B85555.000000000001.00
00:42:34: PNNI: Looking For Nodes That Advertise This Prefix
00:42:34: PNNI: Best Match Is 47.00918100000000D058B85555.000000000001.00/152
00:42:34: PNNI: Found 2 POAs
00:42:34:       priority: 2  (10 0) pnni-remote-internal 
00:42:34:       priority: 4  (14 0) pnni-remote-exterior 
00:42:34: PNNI: Compute On-Demand Route Based On Admin Weight
00:42:34: PNNI: Found A Suitable Route Based On AW, Check CDV and CTD
00:42:34: PNNI: Found A Route That Satisfies Both CDV and CTD
00:42:34: PNNI: SOURCE ROUTE
00:42:34:       DTL 1> 2 Nodes
00:42:34:              budvar 85001000 (ATM10/0/1)
00:42:34:              Platan 0
00:42:34: PNNI: Found 1 Ports To Next DTL Node 10 85001000 (ATM10/0/1)
00:42:34: PNNI: Send Source Route Reply To Requestor: Code PNNI_SUCCESS

As previously explained, Budvar detects that there are two possible routes or Point of Attachments (POAs) to reach device B. The route through Budvar (pnni-remote-internal) has a better precedence than the route through Miles. Hence, the DTL is built with that route.

Remarks:

This command can be used in order to determine which DTL must be created for this call setup:

show atm pnni dtl [node|address] [NSAP-address|node number] [traffic class] [class parameters]

where:

NSAP-address is the destination NSAP address (the address of device B in our case).
traffic class is: CBR, UBR, VBR-rt, VBR-nrt, ABR.
class parameters are the different parameters associated with the traffic class such as PCR, MCR, and SCR.

Note: The different rates (PCR, MCR, SCR) are defined in cells/sec and not Kbps.

Note: This command shows which DTL is computed when a call setup is made to the desired NSAP address or PNNI node number with the specified traffic parameters.

Example 2

Network Diagram

Use this network diagram in this example:

Goal

The goal of this example is to show that PNNI only takes into consideration the longest match prefixes and falls back to the next available POA when the current one is not usable.

CBR call setups are created between device A and device B. These two devices do not use ILMI and thus static routes, to E.164 address in this case also known as 45 addresses, that point to them are created on Femke and Droopie.

If congestion occurs within the private ATM cloud that goes through Miles, the CBR call setups must be made through the public ATM network.

Associate different precedence to different types of routes so that the lower the precedence, the higher the priority for the route, in order to make sure that the call setups are made in accordance with the prerequisites.

This is how the prerequisites are achieved:

On Femke and Droopie, the local static routes that point to the locally attached device are created as internal and a backup route that points to the remote device through the public ATM network is defined as external. Furthermore, both static routes are defined with the same length because of the PNNI path selection rule previously mentioned.

In addition to the local static internal route that points to the attached device, another static internal route with a shorter match is created in order to illustrate the fact that PNNI always takes the longest match route into consideration.

Look at Femke and see that there are three routes to reach device B:

An internal PNNI route that results from the redistribution of the internal static route created on Droopie.
A shorter internal PNNI route that results from the redistribution of the shorter match internal static route created on Droopie.
An external static route that is defined on Femke and points to the public ATM network.

Illustration

Device B has this NSAP address: 45.0033.4455.6677.889f.1111.2222.4000.0c80.1111.00

On Droopie, these static routes are defined:

atm route 45.0033.4455.6677.889f.1111.2222.4000.0c80.1111... ATM1/0/0 internal


atm route 45.0033.4455.6677.889f.1111.2222... ATM1/0/0 internal (*)

(*) this route is the shorter match route that points to device B.

On Femke, this backup static route is defined:

atm route 45.0033.4455.6677.889f.1111.2222.4000.0c80.1111... ATM1/0/2

Hence, these entries for device B can be seen on the Femke routing table:

Femke#show atm route

Codes: P - installing Protocol (S - Static, P - PNNI, R - Routing control),
       T - Type (I - Internal prefix, E - Exterior prefix, SE -
                 Summary Exterior prefix, SI - Summary Internal prefix,
                 ZE - Suppress Summary Exterior, ZI - Suppress Summary Internal)


P  T Node/Port        St Lev Prefix
~ ~~ ~~~~~~~~~~~~~~~~ ~~ ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
P  I 14  0            UP 0   45.0033.4455.6677.889f.1111.2222/104
S  E 1   ATM1/0/2     UP 0   45.0033.4455.6677.889f.1111.2222.4000.0c80.1111/152
P  I 14  0            UP 0   45.0033.4455.6677.889f.1111.2222.4000.0c80.1111/152

In order to reach device B, you have:

a /152 internal PNNI route
a /104 internal PNNI route
a /152 external static route that points to the public ATM network

The /152 and /104 are the levels of hierarchy. For a more detailed explanation on the levels of hierarchy, refer to Configuring ATM Routing and PNNI.

This output shows how to verify the available resources between Femke and Miles:

Femke#show atm interface resource atm 1/0/0

Resource Management configuration:
    Output queues:
        Max sizes(explicit cfg): none cbr, none vbr-rt, none vbr-nrt, none abr-ubr
        Max sizes(installed): 256 cbr, 256 vbr-rt, 4096 vbr-nrt, 12032 abr-ubr
        Efci threshold: 25% cbr, 25% vbr-rt, 25% vbr-nrt, 25% abr, 25% ubr
        Discard threshold: 87% cbr, 87% vbr-rt, 87% vbr-nrt, 87% abr, 87% ubr
        Abr-relative-rate threshold: 25% abr
    Pacing: disabled   0 Kbps rate configured, 0 Kbps rate installed
    Service Categories supported: cbr,vbr-rt,vbr-nrt,abr,ubr
    Link Distance: 0 kilometers
    Controlled Link sharing:
        Max aggregate guaranteed services: none RX,  none TX
        Max bandwidth: none cbr RX, none cbr TX, none vbr RX, none vbr TX,
                       none abr RX, none abr TX, none ubr RX, none ubr TX
        Min bandwidth: none cbr RX, none cbr TX, none vbr RX, none vbr TX,
                       none abr RX, none abr TX, none ubr RX, none ubr TX
    Best effort connection limit: disabled  0 max connections
    Max traffic parameters by service (rate in Kbps, tolerance in cell-times):
        Peak-cell-rate RX: none cbr, none vbr, none abr, none ubr
        Peak-cell-rate TX: none cbr, none vbr, none abr, none ubr
        Sustained-cell-rate: none vbr RX, none vbr TX
        Minimum-cell-rate RX: none abr, none ubr
        Minimum-cell-rate TX: none abr, none ubr
        CDVT RX: none cbr, none vbr, none abr, none ubr
        CDVT TX: none cbr, none vbr, none abr, none ubr
        MBS: none vbr RX, none vbr TX

Resource Management state:
    Cell-counts: 0 cbr, 0 vbr-rt, 0 vbr-nrt, 0 abr-ubr
    Available bit rates (in Kbps):
        72615 cbr RX, 72615 cbr TX, 72615 vbr RX, 72615 vbr TX,
        0 abr RX, 0 abr TX, 0 ubr RX, 0 ubr TX
    Allocated bit rates:
        75000 cbr RX, 75000 cbr TX, 128 vbr RX, 128 vbr TX,
        0 abr RX, 0 abr TX, 0 ubr RX, 0 ubr TX
    Best effort connections: 1 pvcs,  0 svcs

Resources available between Miles and Droopie:

Miles#show atm interface resource atm 1/0/3

Resource Management configuration:
    Service Classes:
        Service Category map: c2 cbr, c2 vbr-rt, c3 vbr-nrt, c4 abr, c5 ubr
        Scheduling: RS c1 WRR c2, WRR c3, WRR c4, WRR c5
        WRR Weight: 15 c2, 2 c3, 2 c4, 2 c5
    CAC Configuration to account for Framing Overhead : Disabled
    Pacing: disabled   0 Kbps rate configured, 0 Kbps rate installed
    overbooking :  disabled
    Service Categories supported: cbr,vbr-rt,vbr-nrt,abr,ubr
    Link Distance: 0 kilometers
    Controlled Link sharing:
       Max aggregate guaranteed services: none RX,  none TX
        Max bandwidth: none cbr RX, none cbr TX, none vbr RX, none vbr TX,
                       none abr RX, none abr TX, none ubr RX, none ubr TX
        Min bandwidth: none cbr RX, none cbr TX, none vbr RX, none vbr TX,
                       none abr RX, none abr TX, none ubr RX, none ubr TX
    Best effort connection limit: disabled  0 max connections
    Max traffic parameters by service (rate in Kbps, tolerance in cell-times):
        Peak-cell-rate RX: none cbr, none vbr, none abr, none ubr
        Peak-cell-rate TX: none cbr, none vbr, none abr, none ubr
        Sustained-cell-rate: none vbr RX, none vbr TX
        Minimum-cell-rate RX: none abr, none ubr
        Minimum-cell-rate TX: none abr, none ubr
        CDVT RX: none cbr, none vbr, none abr, none ubr
        CDVT TX: none cbr, none vbr, none abr, none ubr
        MBS: none vbr RX, none vbr TX

Resource Management state:
    Available bit rates (in Kbps):
        57743 cbr RX, 57743 cbr TX, 57743 vbr RX, 57743 vbr TX,
        57743 abr RX, 57743 abr TX, 57743 ubr RX, 57743 ubr TX
    Allocated bit rates:
        90000 cbr RX, 90000 cbr TX, 0 vbr RX, 0 vbr TX,
        0 abr RX, 0 abr TX, 0 ubr RX, 0 ubr TX
    Best effort connections: 1 pvcs,  0 svcs

This output shows what happens when a CBR call setup is made from device A to device B when different PCR values are used:

a. CBR Call Setup from Device A to Device B with PCR= 727 Kbps (1715 cells/s)

There are available resources along the path in order to accommodate such a call setup. Proceed with these instructions in order to check the DTL, which is created on Femke, in order to reach device B:

Femke#show atm pnni dtl address 45.0033.4455.6677.889f.1111.2222.4000.0c80.1111  cbr pcr 1715 1715
Femke#
Nov 13 08:16:08.310: PNNI: rcv CBR route req to addr 45.003344556677889F11112222.40000C801111.00
Nov 13 08:16:08.310: PNNI: Looking For Nodes That Advertise This Prefix
Nov 13 08:16:08.310: PNNI: Best Match Is 45.003344556677889F11112222.40000C801111.00/152
Nov 13 08:16:08.310: PNNI: Found 2 POAs
Nov 13 08:16:08.310:        priority: 2  (16 0) pnni-remote-internal
Nov 13 08:16:08.310:        priority: 3  (1 80802000 (ATM1/0/2)) static-local-exterior
Nov 13 08:16:08.310: PNNI: Compute On-Demand Route Based On Admin Weight
Nov 13 08:16:08.310: PNNI: Found A Suitable Route Based On AW, Check  CDV and CTD
Nov 13 08:16:08.310: PNNI: Found A Route That Satisfies Both CDV and  CTD
Nov 13 08:16:08.310: PNNI: SOURCE ROUTE
Nov 13 08:16:08.310:       DTL 1> 3 Nodes
Nov 13 08:16:08.310:               Femke 80800000 (ATM1/0/0)
Nov 13 08:16:08.310:               Miles 80803000 (ATM1/0/3)
Nov 13 08:16:08.310:               Droopie
Nov 13 08:16:08.310: PNNI: Found 1 Ports To Next DTL Node 13 80800000  (ATM1/0/0)
Nov 13 08:16:08.314: PNNI: Send Source Route Reply To Requestor: Code  PNNI_SUCCESS

In this call setup, these two POAs are found:

/152 Internal PNNI route
/152 External static route

The /104 route is not taken into account. The /152 PNNI internal route is then used because it has a better precedence, precedence 2, compared to the external static route, precedence 3, and because there are enough resources on the path in order to accommodate this call setup.

b. CBR Call Setup from Device A to Device B with PCR = 77620 Kbps (183066 cells/s)

Femke#show atm pnni dtl address 45.0033.4455.6677.889f.1111.2222.4000.0c80.1111  cbr pcr 183066 183066
Femke#
Nov 13 12:38:28.165: PNNI: rcv CBR route req to addr 45.003344556677889F11112222.40000C801111.00
Nov 13 12:38:28.169: PNNI: Looking For Nodes That Advertise This Prefix
Nov 13 12:38:28.169: PNNI: Best Match Is 45.003344556677889F11112222.40000C801111.00/152 
Nov 13 12:38:28.169: PNNI: Found 2 POAs
Nov 13 12:38:28.169:       priority:  2  (14 0) pnni-remote-internal
Nov 13 12:38:28.169:       priority:  3  (1 80802000 (ATM1/0/2)) static-local-exterior
Nov 13 12:38:28.169: PNNI: Compute On-Demand Route Based On Admin Weight
Nov 13 12:38:28.169: PNNI: Failed To Find An On-Demand Route, Code:  PNNI_USER_CELL_RATE_UNAVAILABLE
Nov 13 12:38:28.169: PNNI: My Node Is Destination
PNNI: Port List: 80802000 (ATM1/0/2)
Nov 13 12:38:28.169: PNNI: Return 1 Ports In Source Route
Nov 13 12:38:28.169: PNNI: Send Source Route Reply To Requestor: Code  PNNI_SUCCESS

In the previous example, there are not enough resources along the PNNI path, so the LS1010 tries to use the second available route to the destination. Thus, the switch falls back to the static external route that points to the public ATM network as required.

Example 3

Network Diagram

Use this setup for this example. All links have the same administrative weight.

The goal of this example is to show that PNNI always uses the route with the smaller administrative weight. But, if the best path does not have enough resources in order to accommodate the current call, PNNI can fall back to a lower path.

In this scenario, when device A makes a call to device B, there are two possible paths:

Femke and then Stan
Femke, Miles and then Stan

Throughout normal operations, the call setups flow through the first path as that is the one with the smaller administrative weight.

Illustration

This illustrates the previous explanations:

Device B has this NSAP address: 47.0033.4455.6677.889f.1111.2222.4000.0c80.1111.00. See that the chosen route is the one that goes from Miles to Stan when you look in the routing table:

Femke#show atm route

Codes: P - installing Protocol (S - Static, P - PNNI, R - Routing control),
       T - Type (I - Internal prefix, E - Exterior prefix, SE -
                 Summary Exterior prefix, SI - Summary Internal prefix,
                 ZE - Suppress Summary Exterior, ZI - Suppress Summary Internal)

P  T Node/Port        St Lev Prefix
~ ~~ ~~~~~~~~~~~~~~~~ ~~ ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
P  E 10  0            UP 0   47.0033.4455.6677.889f.1111.2222.4000.0c80.1111/152
[snip]

Femke#show atm pnni identifiers
  Node  Node Id                                              Name
  1       56:160:47.00918100000000E0146CB101.00E0146CB101.00 Femke
  10      56:160:47.0091810000000060705A8F01.0060705A8F01.00 Stan
  11      56:160:47.0091810000000050E2030601.0050E2030601.00 la-miles

a. CBR Call Setup from Device A to Device B with PCR= 848 Kbps (2000 cells/s)

Such a call setup needs to go through the short path without any problem, as there are available resources in order to accommodate it:

Femke#show atm interface resource atm 1/0/3
Resource Management configuration:
[snip]

Resource Management state:
    Cell-counts: 0 cbr, 0 vbr-rt, 0 vbr-nrt, 0 abr-ubr
    Available bit rates (in Kbps):
        72455 cbr RX, 72455 cbr TX, 72455 vbr RX, 72455 vbr TX,
        0 abr RX, 0 abr TX, 0 ubr RX, 0 ubr TX
    Allocated bit rates:
        75000 cbr RX, 75000 cbr TX, 288 vbr RX, 288 vbr TX,
        0 abr RX, 0 abr TX, 0 ubr RX, 0 ubr TX
    Best effort connections: 0 pvcs,  0 svcs

There is still 75 Mbps on that path. This is how to verify which DTL is computed by Femke upon reception of the call setup:

Femke#show atm pnni dtl address 47.0033.4455.6677.889f.1111.2222.4000.0c80.1111  cbr pcr 2000 2000
Femke#
*Dec 20 05:46:11.740: PNNI: CBR route request from ATM_OWNER_UNKNOWN
*Dec 20 05:46:11.740: PNNI: To address 47.003344556677889F11112222.40000C801111.00
*Dec 20 05:46:11.740: PNNI: Best Match Is 47.003344556677889F11112222.40000C801111.00/152
*Dec 20 05:46:11.740: PNNI: Found 1 POAs
*Dec 20 05:46:11.740:       priority:  4  (10 0) pnni-remote-exterior
*Dec 20 05:46:11.740: PNNI: Compute On-Demand Route Based On Admin  Weight
*Dec 20 05:46:11.740: PNNI: Found A Suitable Route Based On AW, Check  CDV and CTD
*Dec 20 05:46:11.740: PNNI: Found A Route That Satisfies Both CDV and  CTD
*Dec 20 05:46:11.740: PNNI: SOURCE ROUTE
*Dec 20 05:46:11.740:       DTL 1>  2 Nodes
*Dec 20 05:46:11.740:                Femke 80803000 (ATM1/0/3)  
*Dec 20 05:46:11.740:               Stan 0  
*Dec 20 05:46:11.744: PNNI: Found 1 Ports To Next DTL Node 10 80803000  (ATM1/0/3)
*Dec 20 05:46:11.744: PNNI: Send Source Route Reply To Requestor: Code  PNNI_SUCCESS

This output shows that the call does indeed go through the shortest path.

b. CBR Call Setup from Device A to Device B with PCR = 84800 Kbps (200000 cells/s)

Upon reception of such a call setup by Femke, the direct path between Femke and Stan cannot be used because there are not enough unused resources. Femke can then try to use the other path through Miles. This is the DTL that Femke creates upon reception of such a call setup from device A:

Femke#show atm pnni dtl address 47.0033..4455.6677.889f.1111.2222.4000.0c80.1111  cbr pcr 200000 200000 
Femke#
*Dec 20 05:47:31.885: PNNI: CBR route request from ATM_OWNER_UNKNOWN
*Dec 20 05:47:31.885: PNNI: To address 47.003344556677889F11112222.40000C801111.00
*Dec 20 05:47:31.885: PNNI: Best Match Is 47.003344556677889F11112222.40000C801111.00/152
*Dec 20 05:47:31.885: PNNI: Found 1 POAs
*Dec 20 05:47:31.885:       priority:  4  (10 0) pnni-remote-exterior
*Dec 20 05:47:31.889: PNNI: Compute On-Demand Route Based On Admin  Weight
*Dec 20 05:47:31.889: PNNI: Found A Suitable Route Based On AW, Check  CDV and CTD
*Dec 20 05:47:31.889: PNNI: Found A Route That Satisfies Both CDV and  CTD
*Dec 20 05:47:31.889: PNNI: SOURCE ROUTE
*Dec 20 05:47:31.889:       DTL 1>  3 Nodes 
*Dec 20 05:47:31.889:                Femke 80800000 (ATM1/0/0)
*Dec 20 05:47:31.889:               la-miles 80801000 (ATM1/0/1)
*Dec 20 05:47:31.889:                Stan 0 
*Dec 20 05:47:31.889: PNNI: Found 1 Ports To Next DTL Node 11 80800000  (ATM1/0/0)
*Dec 20 05:47:31.889: PNNI: Send Source Route Reply To Requestor: Code  PNNI_SUCCESS

Since the shortest path to device B does not have enough resources to accommodate such a call, Femke creates a DTL that corresponds to the path through Miles.

Conclusion

In conclusion, in its route selection, PNNI:

Takes only the longest match route(s) in consideration.
Tries the routes in accordance to their priority, so the lower the precedence, the better, when several routes exist.
Uses the next available route, the next available POA, if available, when the current cannot be used.
Declares the route unreachable if none of the POAs can be used.

Related Information

Introduction to PNNI
Configuring ATM Routing and PNNI

Revision History

Revision	Publish Date	Comments
1.0	06-Feb-2002	Initial Release

Was this Document Helpful?

Feedback

Contact Cisco

Open a Support Case
(Requires a Cisco Service Contract)

Private Network-to-Network Interface (PNNI) Route Selection

Available Languages

Download Options

Bias-Free Language

Contents

Introduction

Prerequisites

Requirements

Components Used

Conventions

PNNI Route Selection

Illustration of the Route Selection

Example 1

Network Diagram

Goal

Illustration

Example 2

Network Diagram

Goal

Illustration

Example 3

Network Diagram

Illustration

Conclusion

Related Information

Revision History

Was this Document Helpful?

Contact Cisco