Guest

Private Network-Network Interface (PNNI)

Understanding How PNNI Calculates and Uses Available Cell Rate Parameter (AvCR)

Document ID: 22886



Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
What is AvCR?
How AvCR Works
      Example
Problem
Solution
Related Information

Introduction

The Private Network-Node Interface (PNNI) protocol is designed to distribute topology information between ATM switches and to establish dynamic connections across ATM networks. The Available Cell Rate (AvCR) attribute is one of the most important PNNI topology state parameters.

This document explains how to check, calculate, and troubleshoot AvCR when switched virtual circuits (SVCs) or Soft permanent virtual circuits (Soft-PVCs) are not created due to unavailable cell rate.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

What is AvCR?

AvCR is a topology state attribute that measures an available link capacity. This attribute is used to determine whether a given link or node is acceptable and/or desirable to carry a connection. Every ATM switch calculates this value and exchanges it between other ATM switches.

How AvCR Works

ATM switches do not update AvCR attributes immediately after a change has occurred in the switch's resources. Every virtual circuit (VC) creation/deletion changes a local available bit rate value. However, the switch waits until the changes in AvCR become significant before it updates this value. As AvCR approaches a value of zero, changes in AvCR are more important. For example, transitioning AvCR from a non-zero value to zero implies that no calls are processed where some were processed before. This is an important change. Likewise, transitioning from zero to non-zero values implies that some number of calls are now processed where none were processed before. This is an equally important change.

Changes in AvCR are measured in terms of a proportional difference from the last value advertised. An AvCR proportional multiplier (AvCR_PM) parameter, expressed as a percentage, provides flexible control over the definition of "significant change" for AvCR. There is also an AvCR minimum threshold (AvCR_MT) parameter, expressed as a percentage of maximum cell rate (maxCR). This ensures that the range of insignificance is non-zero. Given a previous value for AvCR, the algorithm establishes an upper and lower bound for AvCR values. These define a range of insignificance. Any new value for AvCR computed that is within these bounds is not considered a significant change from the previous value. Any new value for AvCR that is outside the bounds is considered a significant change.

avcr_a.gif

Variable

Description

MaxCR

Maximum cell rate for service category.

Prev_AvCR

Previously advertised value for AvCR for service category.

AvCR_PM

Proportional Multiplier. The percentage of the last advertised AvCR such that a change within the range AvCR ? (AvCR * AvCR_PM / 100) is not considered significant. (Default value 50).

AvCR_MT

Minimum Threshold. The percentage of maxCR such that changes in AvCR of less than that amount from the last advertised value are never considered significant, even when the rule for AvCR_PM would indicate that the change was significant. (Default value 3).

Example

This example presupposes that there are no VCs traveling through the ATM OC3 interface. A certain number of CBR connections with PCR = 10 Mb must be created.

These are the initial values for all variables required to calculate how many VCs are created before AvCR is updated:

Variable

Value

MaxCR

155519

AvCR

147743

AvCR_PM

50

AvCR_MT

3

With the help of the values from the table and in the algorithm given in the flowchart above, you obtain this:

delta = Prev_AvCR*(AvCR_PM/100) = 147743 * ( 50 / 100 ) = 73871
min_delta = maxCR*(AvCR_MT/100) = 155519 * ( 3 / 100 ) = 4665


Since 73871 > 4665, then, delta > min_delta.
Then Upper AvCR = Prev_AvCR+delta = 221614

Since MaxCR = 155519 and Upper AvCR = 221614, then Upper AvCR > MaxCR 
Therefore Upper AvCR = 155519

Now, since delta = 73871 and Prev_AvCR = 14774, then delta < Prev_AvCR
Therefore 

Lower AvCR = Prev_AvCR - delta = 147743 - 73871 = 73872

Based on the formulas above, AvCR is updated if a new value of AvCR is lower or equal to 73872. In addition, at least eight CBR VC should be created to fulfill this condition.

These are seven CBR VCs that are created:

Casimir#show atm vc conn-type soft-vc 
Interface         VPI  VCI   Type   X-Interface      X-VPI X-VCI Encap  Status 
ATM0/0/2          0    251   SoftVC ATM0/1/3         0     62           UP
ATM0/0/2          0    252   SoftVC ATM0/1/3         0     63           UP
ATM0/0/2          0    253   SoftVC ATM0/1/3         0     64           UP
ATM0/0/2          0    254   SoftVC ATM0/1/3         0     65           UP
ATM0/0/2          0    255   SoftVC ATM0/1/3         0     66           UP
ATM0/0/2          0    256   SoftVC ATM0/1/3         0     67           UP
ATM0/0/2          0    257   SoftVC ATM0/1/3         0     68           UP

Casimir#show atm pnni resource-info a0/1/3
PNNI:56.1 Insignificant change parameters
acr pm 50,  acr mt 3, cdv pm 25, ctd pm 50, resource poll interval 5 sec
Interface insignificant change bounds shown in square brackets
Interface 80103000 (ATM0/1/3)
  CBR    : MCR 155519, ACR 147743 [73871,155519], CTD 50 [25,75],

[ snip ]

Casimir#show atm interface resource a0/1/3

[ snip ]

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

These are eight CBR VCs that are created:

Casimir#show atm vc conn-type soft-vc       
Interface         VPI  VCI   Type   X-Interface      X-VPI X-VCI Encap  Status 
ATM0/0/2          0    251   SoftVC ATM0/1/3         0     62           UP
ATM0/0/2          0    252   SoftVC ATM0/1/3         0     63           UP
ATM0/0/2          0    253   SoftVC ATM0/1/3         0     64           UP
ATM0/0/2          0    254   SoftVC ATM0/1/3         0     65           UP
ATM0/0/2          0    255   SoftVC ATM0/1/3         0     66           UP
ATM0/0/2          0    256   SoftVC ATM0/1/3         0     67           UP
ATM0/0/2          0    257   SoftVC ATM0/1/3         0     68           UP
ATM0/0/2          0    258   SoftVC ATM0/1/3         0     69           UP

Casimir#show atm pnni resource-info a0/1/3
PNNI:56.1 Insignificant change parameters
acr pm 50,  acr mt 3, cdv pm 25, ctd pm 50, resource poll interval 5 sec
Interface insignificant change bounds shown in square brackets
Interface 80103000 (ATM0/1/3)
  CBR    : MCR 155519, ACR 67743 [33871,101614], CTD 50 [25,75],

[ snip ]

Casimir#show atm interface resource a0/1/3

[ snip ]

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

Problem

An AvCR rate parameter is not updated if changes made are insignificant. A problem also arises if SVC/Soft-PVC is not created due to the unavailability of a requested cell rate, even though there are enough resources to process the call setup.

In order to illustrate and troubleshoot this problem, this setup is used:

avcr_b.gif

Goldorak wants to create Soft-PVC (CBR, PCR=80Mb) from interface a4/0/1 to Casimir a0/0/2.

Goldorak#show atm vc conn-type soft-vc interface a4/0/1
 Interface         VPI  VCI   Type   X-Interface      X-VPI X-VCI Encap  Status 
 ATM4/0/1          0    400   SoftVC  NOT CONNECTED

This indicates why Soft-PVC is down:

Goldorak#show atm vc int a4/0/1 0 400
   
   Interface: ATM4/0/1, Type: oc3suni 
   VPI = 0 VCI = 400
   Status: NOT CONNECTED
   Time-since-last-status-change: 19:22:01
   Connection-type: SoftVC 
   Cast-type: point-to-point
   Soft vc location: Source
   Remote ATM address: 47.0091.8100.0000.0060.3e5a.4501.4000.0c80.0020.00
   Remote VPI: 0 
   Remote VCI: 400
   Soft vc call state: Inactive
   Number of soft vc re-try attempts: 1405 
   First-retry-interval: 5000 milliseconds
   Maximum-retry-interval: 60000 milliseconds
   Next retry in: 8876 milliseconds
     Last release cause: 37,user cell rate not available
   Aggregate admin weight: 0

   [ snip ]

   Rx service-category: CBR (Constant Bit Rate)
   Rx pcr-clp01: 80000
   Rx scr-clp01: none
   Rx mcr-clp01: none
   Rx cdvt: 1024 (from default for interface)
   Rx mbs: none
   Tx connection-traffic-table-index: 80
   Tx service-category: CBR (Constant Bit Rate)
   Tx pcr-clp01: 80000
   Tx scr-clp01: none
   Tx mcr-clp01: none
   Tx cdvt: none
   Tx mbs: none

The debug atm sig-all a4/0/1 and debug atm SIG-all a2/0/0 commands at Goldorak show that PNNI refuses the VC creation.

.Mar 16 09:05:05.061: ATMSOFT(ATM4/0/1 vpi = 0 ; vci = 400) 
soft-vc retry timer    
    expired

   .Mar 16 09:05:05.061: ATMSOFT(ATM4/0/1 vpi = 0 ; vci = 400) soft-vc retry to    
    open another soft-vc

   .Mar 16 09:05:05.061: ATMSOFT(ATM4/0/1 vpi = 0 ; vci = 400) sending SETUP msg    
    to open soft-vc 
   .Mar 16 09:05:05.061: ATMAPI: (c->s): SETUP ci: 0x620A59EC mp: 0x0 ei: 0x0
   .Mar 16 09:05:05.061: ATMSIG: Called len 20
   .Mar 16 09:05:05.061: ATMSIG: Calling len 20
   .Mar 16 09:05:05.061: ATMSIG(ATM2/0/0 0,400 - 2534/00): (vcnum:0) build Setup     
    msg, Null(U0) state
   .Mar 16 09:05:05.061: ATMSIG(ATM2/0/0 0,400 - 2534/00): (vcnum:0) API - from    
    sig-client ATM_OWNER_ATM_SOFTVC
   .Mar 16 09:05:05.061: ATMSIG(ATM2/0/0 0,400 - 2534/00): (vcnum:0) API event: 
    Req Setup in P2P Null(U0), in P2MP Multipoint Null
   .Mar 16 09:05:05.061: ATMSIG(ATM2/0/0 0,400 - 2534/00): (vcnum:0)API P2P Null(U0) -> 
    Call Initiated(U1)
   .Mar 16 09:05:05.061: SIG->CC: Svc Event Rcvd Setup, State Call 
    Initiated(U1)atmsig_set_e2e_extqos_def:serv_category    0 extQos 0, 
  end2enddelayIe 0
   
   .Mar 16 09:05:05.061: ATMSIG: sending source route req to routing
   .Mar 16 09:05:05.061: ATMSIG(ATM2/0/0 0,400 - 2534/00): (vcnum:0) 
  sending source    
    route req 
   .Mar 16 09:05:05.061: ATMSIG: ROUTING INTERFACE : call ref = 2534(0x9E6); call    
    end pt ref = 0(0x0); calling port : (2/0/0) : 0 ; 
   pt2mpt = 0; call_is_vp = 0x0; lowest precedence = 0x0; scope = 15; 
   target.type = 0x2; target addr = 47.00918100000000603E5A4501.40000C800020.00
   .Mar 16 09:05:05.065: Port List : no of ports = 0 
   .Mar 16 09:05:05.065: CC->SIG: Svc Event Req Call Proceeding, 
  State Call Initiated(U1)
   .Mar 16 09:05:05.065: ATMSIG_NNI: processing src_route message from pnni
   .Mar 16 09:05:05.065: ATMSIG: ROUTING INTERFACE : 
  err_code = PNNI_USER_CELL_RATE_UNAVAILABLE    
    (0x8) call ref = 2534(0x9E6); call end pt ref = 0(0x0); 
calling port : (2/0/0)    : 0 ; 
   pt2mpt = 0; call_is_vp = 0x0; lowest precedence = 0x0; scope = 15; 
   target.type = 0x2; target addr = 47.00918100000000603E5A4501.40000C800020.00
   .Mar 16 09:05:05.065: Port List : no of ports = 0 
   .Mar 16 09:05:05.065: ATMSIG(ATM2/0/0 0,400 - 2534/00): (vcnum:0) source    
     route failed; PNNI_USER_CELL_RATE_UNAVAILABLE (0x08)
   .Mar 16 09:05:05.065: ATMSIG: Called Party Addr: 
  47.00918100000000603E5A4501.40000C800020.00
   .Mar 16 09:05:05.065: ATMSIG: Calling Party Addr: 
   47.0091810000000050E2030501.40000C820010.00
   .Mar 16 09:05:05.065: CC->SIG: Svc Event Req Release, 
   State Call Initiated(U1)
   .Mar 16 09:05:05.065: ATMSIG(ATM2/0/0 0,400 - 2534/00): 
  (vcnum:0) API - notifying    
    Release event to client ATM2/0/0
   .Mar 16 09:05:05.065: 

   ATMAPI: (c<-s): RELEASE ci: 0x620A59EC, cause: 0x25
   .Mar 16 09:05:05.065: ATMSOFT(ATM4/0/1 vpi = 0 ; vci = 400) received Rel at src 

The PNNI topology information here shows who is responsible for the failure. The information is the same on the switches. It contains information about cell rate values.

Goldorak#show atm pnni topology detail 
 
[ snip ]

Node 9 (name: Casimir, type: LS1010, ios-version: 12.0)
Node ID..: 56:160:47.00918100000000603E5A4501.00603E5A4501.00
Node AESA:        47.00918100000000603E5A4501.00603E5A4501.01
Leadership Priority: 0, Claims PGL: No, Transit Calls: Allowed
Ancestor: No, Nodal Representation: Simple, Connected: Yes
More P2MP Branch Points: Yes, Non-Transit For PGL Election: No
Node has 2 Links (Space for 4 Links)
   port 80103000, ATM0/1/3, remote port 82103000, ATM4/1/3,
   neighbor Laalaa
   type horizontal, vp capable, gcac clp0, agg-token 0
   forward link parameters
            maxcr    avcr     ctd    cdv   clr0  clr01  aw      crm    vf
   CBR      155519   67743    50     34    10    10     5040    n/a    n/a  

[ snip ]

   backward link parameters
            maxcr    avcr     ctd    cdv   clr0  clr01  aw      crm    vf
   CBR      155519   67743    50     34    10    10     5040    n/a    n/a  

[ snip ]

The reason why Goldorak is unable to create a VC is because the link between LaaLaa and Casimir has only 67 Mb of AvCR.

Check the resources at the Casimir switch by doing this:

Casimir#show atm interface resource a0/1/3

[ snip ]



Resource Management state:

    Available bit rates (in Kbps):

    97743 cbr RX, 97743 cbr TX, 97743 vbr RX, 97743 vbr TX, 
        97743 abr RX, 97743 abr TX, 97743 ubr RX, 97743 ubr TX
    Allocated bit rates:
        50000 cbr RX, 50000 cbr TX, 0 vbr RX, 0 vbr TX, 

There are 97 Mb of cell rate available. This is enough to process the call.

This situation occurs based on this scenario:

If you have eight SVCs on this interface, the allocated bandwidth adds up to 80 Mb. On the other hand, the initial available bandwidth for CBR is 147 M. This leads to a current AvCR of 67 Mb (147 Mb - 80 Mb = 67 Mb). Since this is a considerable change in bandwidth, update all the ATM switches where the AvCR is 67 Mb.

If Casimir shuts down three SVCs, you get 30 Mb of additional bandwidth. Then the AvCR is 97 Mb (67 Mb + 30 Mb = 97 Mb). In this case, the change is not considered to be significant. Therefore, there is no need to update the switches that have 97 Mb, or for a PNNI topology update.

Solution

To solve the problem of the AvCR rate parameter not updating if changes made are insignificant, perform these :

  1. Shut/no shut an interface where the AvCR attribute information is inconsistent with the PNNI topology information. AvCR is then recalculated from scratch. In the example , reset interfaces a0/1/3 at Casimir or a4/1/4 at LaaLaa.

  2. Tune the AvCR_PM and AvCR_MT parameters so that an insignificant change in AvCR is declared as significant.

    • In an ATM environment with a high number of VCs created and removed, these changes overflow the network through a high volume of PNNI updates and resource recalculations.

    • The changes should be done on all switches. Otherwise different AvCR values are received in different directions.

    Example:

    LaaLaa

    !
    node 1 level 56 lowest
        ptse significant-change acr-pm 10
    
    !--- AvCR_PM is changed to 10%.
     
    !

The output of the show atm pnni resource-info command displays insignificant change parameters:

Casimir#show atm pnni resource-info a0/1/3
PNNI:56.1 Insignificant change parameters
acr pm 10,  acr mt 3, cdv pm 25, ctd pm 50, resource poll interval 5 sec

[ snip ]

Related Information



Updated: Jun 05, 2005 Document ID: 22886