|
|
This chapter introduces Private Network-to-Network Interface (PNNI) switching and routing protocol and describes how to design your network for PNNI. PNNI is an extensive standard, and this chapter will generally refer to the capabilities and behaviors of the standard. Those few cases that show capabilities and behaviors of that standard which are specific to the Cisco MGX 8850, Release 2 software image will reference the Cisco product.
In general, routing protocols determine how a path is chosen for a call to transverse the LAN or WAN elements (routers and switches) from the call origin to its destination. In the WAN environment, this path may span countries, continents, or the globe. These protocols are therefore a critical part of the WAN environment, so expanding requirements in the speed, flexibility, and scalability of the WANs is periodically reflected by the creation of routing protocols with more speed, robustness, and scalability.
The original WAN routing protocols were proprietary to the company employing them: PNNI is the first industry-standard routing and switching protocol. This is one of the primary appeals of PNNI. Industry-standardization not only encourages interoperability between WANs, but also pushes a faster, more reliable communication across WANs due to decreased protocol translation within data paths.
The Cisco products that currently employ these protocols are the Cisco LS1010, Cisco BPX 8600/SES, and Cisco MGX 8850, as shown in Table 4-1.
| Industry Protocol | Industry Connections | Cisco Platforms Supporting |
|---|---|---|
Various Proprietary protocols | SV Connection | Cisco MGX 8850 Release 2, |
PNNI 0 (IISP) | Static routes, SPVC, SVC | MGX 8850 Release 2, |
PNNI 1.x | MGX 8850 Release 2, |
This section consists of
PNNI is a standard OSI level 2 switching and routing link-state protocol. As a switching protocol, PNNI supports
As a routing protocol, PNNI supports
PNNI is an extensive protocol. Functionally, PNNI
In order to understand the workings of the extensive PNNI protocol, one must first understand its basic architecture. PNNI varies from existing protocols in the way it works with virtual summarizations of various WANs, grouping these representations into their own virtual networks.
In the language of the PNNI protocol, a PNNI WAN consists of peers. Each peer is a switch in its WAN, which is referred to as the peer group.
As a PNNI WAN starts up, peers discover their neighbors, and add this information to their own existing knowledge of the peer group. The peer then transfers to their neighbors the peer group topology and capacities that they know. This progress repeats until every peer in a peer group knows their entire topology. A key element of this information regards which peers connect to other networks; these nodes are called border nodes.
In a behavior unique to PNNI, the peer group then elects a virtual peer group leader PGL. This PGL still carries and is updated with all the information about its WAN. This PGL can then join the PGLs from other WANs to form a virtual network. Though PGLs carry information about the entire topology and capability (speeds and feeds) of their WANs, these representatives summarize this information when they speak to other PGLs. This information-compacting both speeds communication, and protects a WAN's internal information from discovery by neighboring WANs.
An analogy to PNNI is the use of SS7 to transit call setup information for the PSTN. Obviously, the requirements of the two standards are identical: the high-speed transition of vast amounts of information across large physical expanses. SS7 allowed call-setup information to be separated from voice-traffic, and transverses across a separate physical network using a separate protocol.
The current version of the MGX 8850, Release 2 software image supports only single peer groups (SPG) architecture; it does not yet support communication between PGLs.
The Cisco MGX 8850, Release 1 supported the Cisco proprietary routing protocol autoroute. If you are upgrading to a system that supports MGX 8850, Release 2 software image, it is useful to know the primary advantages that PNNI offers over autorouting, as listed in Table 4-2.
| Supported Features | Cisco MGX 8850 Release 1 | MGX 8850 Release 2 |
|---|---|---|
Routing Protocol supported | Autorouting | IISP |
Scalability | Up to 220 nodes | Limited by design, bandwidth |
Network Provisioning | User-intensive--often requiring weeks of configuration | Largely accomplished by PNNI following configured node bringup. |
OSI Routing Level | Level 3 | Level 2 |
Connection Resiliency | Not part of Autoroute protocol | Provided through support of SPVCs |
Is routing protocol standard? | Cisco-proprietary | PNNI 1.x is industry-standard switching protocol |
Routing computation growth | Since Autoroute supports only flat-networks, every node's routing table grows at a 1:1 rate with each node added. | PNNI supports multi-level networks in which a single logical address can represent an entire group of nodes. If networks are correctly designed, computational growth can increase at a rate far less than that of node growth. |
No | Yes | |
Support for other routing protocols (for example: OSPF) | No |
|
The PNNI standard can support two types of WANs:
The MGX 8850, Release 2 software image supports only a single-peer group WAN. This is a standard flat network. In a single PNNI peer group, all nodes in the network share the identical view of their network topology, the distribution of the traffic resources, and the reachability of the ATM addresses. It is therefore possible to optimize call routing paths.
Figure 4-1 shows an example topology of a PNNI Single Peer Group WAN.
A multiple peer group WAN, or MPG, utilizes the PNNI capability to create hierarchal networks including peer groups that only consist of logical nodes. In Figure 4-2, physical nodes reside at level 56, while logical nodes reside in level 40. As stated earlier, this type of WAN has extreme scaling capabilities, and also protects each peer group's internal topology from access by neighboring WANs.
Figure 4-2 shows an example topology of a PNNI Multiple Peer Group WAN.
The remainder of this chapter gives overviews of standard PNNI procedures and concepts, including the MGX 8850, Release 2 software image CLI commands required, and procedural tips. The Cisco MGX 8850 Command Reference Guide gives detailed information about the entire CLI.
By default, a node loaded with MGX 8850 Release 2 will come up as a PNNI node. Before you bring up a PNNI-configured node, you can configure it. Initially, that will probably consist primarily of assigning address: it is likely that you'll want to take statistics before tuning nodes for optimum performance.
This portion consists of:
The full PNNI address consists of the following
The MGX 8850 Release 2 ships with peer group ID 4700918100000
Before bringup, each peer group must have a pre-assigned 14-byte peer group ID, as shown in Figure 4-3.
Since nodes with the same peer group ID are within the same peer group, all nodes loaded with MGX 8850 Release 2 image ship with the same peer group ID. The MGX 8850 Release 2 ships with peer group ID
4700918100000
You can apply for your own unique address and configure your MGX 8850 Release 2 to that address.
One or more address prefixes may be configured for each node. The prefix is unique for each PNNI node in the network. The default ATM UNI port address prefix is shown in Figure 4-4.
This prefix includes the 7-byte PNNI peer group ID (0x47 0091 8100 0000), plus a unique 6 byte MAC address. This is the prefix used for ATM ILMI address registration with ATM UNI ports.
The MGX 8850 Release 2 ships with the default address shown in Figure 4-5.
A PNNI node is identified by a unique identifier called the node ID. A node ID consists of 22 bytes, including the node's 20-byte default, as shown in Figure 4-6.
The first most significant byte corresponds to the PNNI level indicator byte (38 hex or 56 hex). The second most significant byte is decimal 160 (A0 hex). The reminder of the node ID address may be configured independently if the default node ID is not used.
You enable PNNI on a node by entering the command:
This command is not required to bring up a node as PNNI, since PNNI is the default protocol.
PNNI supports two methods of address assignment: static and dynamic.
In static addressing you use the protocol IISP (PNNI 0) to assign prefixes to any static node(s). Nodes so configured can still run proprietary SPVCs over ILMI using PNNI. In some cases, use of static addressing may be advisable:
On bringup, PNNI nodes send their neighbor Hello packets that include their status and capabilities. They also flood their peer group with PNNI topology state elements (PTSEs) to disseminate topology database information in the ATM network. Hello protocol is used by PNNI to detect and maintain adjacency between PNNI nodes. When the PNNI nodes discover they are members of the same peer group, they form an inside link.
When the Hello protocol has declared the link as functional, the adjacent PNNI nodes exchange a summary of their database contents. This synchronization is governed by a a master and slave relationship of the PNNI nodes. Nodes exchange database summary packet's which contain header information of all PNNI PTSEs in a node database. After this exchange, the nodes check for information that they lack, and differences in the topological databases are updated. When completed, both PNNI nodes have identical topological databases.
A PNNI node newly connected to an existing PNNI network copies its database from its immediate neighbor.
By default, a node loaded with MGX 8850 Release 2 will come up as a PNNI node. Once a PNNI node is up, enter the command dsppnni-node to show the WAN's nodal table. The node list is displayed in ascending order of each node's node index, all with 1 setting the node to the lowest PNNI hierarchy.
The significant information that will display is
The command dsppnsysaddr is more specific; it displays the following list of addresses from the System Address Table:
The command dsppnni-link shows the PNNI link table.
If you specify:
The final option allows you to overview all communication lines in the PNNI network.
The PNNI protocol includes a source-rooting protocol. Source-rooting defines that the sole responsibility for routing rests on the originating node; defined PNNI routes, composed of one or more Designated Transit List (DTL), can not be changed by a node that did not generate that DTL. It is useful to remember that a PNNI node routes in detail through it's peer group, but in general through the world. This becomes important if hierarchal topology multiple peer group (MPG) is available.
Originating nodes calculate a WAN's PNNI routing tables. Route calculation is a CPU-intensive, background activity that is triggered by significant changes in network topology, Significant changes include the appearance and/or disappearance of nodes, operational variations in link availability, and changes to link state parameters on links and complex nodes.
Route selection is a two-part process that consists of searching for the called party address and determining the routing path to the destination node.
The number of pre-computed routing tables is dependent on the combined number of class-of-service PTSEs that a node generates and receives from the network. The minimum number of tables generated is three (the default), when each of the these traffic metrics is identical for all applicable class of service types. After the calculating node generates or receives class-of-service based traffic metrics, the tables split as shown in Table 4-3, up to a maximum of 10.
| Traffic Metrics | QoS-Based Routing Paths |
|---|---|
Administrative Weight (AW) | CBR, rtVBR, nrtVBR, ABR, UBR |
Cell Transfer Delay (CTD) | CBR, rtVBR, nrtVBR |
Cell Delay Variation (CDV) | CBR, rtVBR |
Each routing table is maintained as a shortest path tree (SPT) and each SPT is constructed based on the optimization of a particular traffic metric. An SPT maintains the shortest path tree to each reachable destination node located in the same PNNI routing domain as based on the traffic metric.
The routing path is selected directly from the PNNI topology database on the basis of the currently configured mode--either first fit or best fit. If first fit is configured, the route consists of finding a single path that satisfies the call request as quickly as possible. If best fit is configured, the route consists of finding a single path that satisfies the call request at the least cost.
Other characteristics of routing are:
An originating node looks up the routing tables to determine the DTL for a call or connection.
As a switching protocol, PNNI supports Quality of Service.
This portion consists of:
MGX 8850 Release 2 supports the service categories shown in Table 4-4.
| CBR | constant bit rate | Used by connections that request a static amount of bandwidth that is continuously available during the connection lifetime. The amount of bandwidth is characterized by Peak Cell Rate (PCR) value. |
| rtVBR | real-time variable bit rate | Intended for real-time applications that require tightly constrained delay and delay variation (voice/video applications). It is characterized in terms of a Peak Cell Rate (PCR), Sustainable Cell Rate (SCR), and Maximum Burst Size (MBS). |
| nrtVBR | non-real-time variable bit rate | Intended for non-real-time applications that have bursty traffic characteristics and are characterized in terms of a PCR, SCR, and MBS. |
| ABR | available bit rate | An ATM layer service category for which the limiting ATM layer transfer characteristics provided by the network may change subsequent to connection establishment. Flow control mechanism is specified. |
During or/and after the network design, a number of parameters can be provisioned on a per-node or per-link basis to enhance overall network performance. The tunable parameters described in this section are
The administrative weight (AW) for a path is the sum of the individual weights of the links on the path. The AW is one of the key elements used to optimize route selection. The assignment of administrative weights to links and nodes influences which paths PNNI selects in autorouting.
Tuning the AW on interfaces impacts the distribution of SPVC/SVCs over the network.
Administrative weight can also be used to exclude certain links from routing, such as a backup link that needs to be used only when the primary link is full.
Available cell rate (AvCR) is the effective available capacity for CBR, rtVBR, and nrtVBR service categories. For ABR service, AvCR is the capacity available for minimum cell rate (MCR) reservation.
The per-service class based AvCR on each link is advertised by PNNI routing protocol after the overbooking factor applied. Tuning bandwidth overbooking impacts the results of the G-CAC during the routing path selection procedure. A more aggressive overbooking approach allows more SVC/SPVC to share the same set of network resources more efficiently, with trade-off of possible more signaling crankbacks in the network.
Bandwidth overbooking may be configured at a per-interface and per-service class basis at lowest level nodes. The setting is established by configuring AvCR and reflects the equivalent bandwidth that is available on the link or node. AvCR is the most dynamic metric in PNNI; AvCR depends on the calls traversing the links and is viewed as the residual capacity left for use by additional calls. PNNI must know AvCR to decide if a link or node can carry a certain call, as measured in calls per second (cps).
The CTD is one of the key matrixes used in route selection procedure for route-optimization as well as meeting QoS-based signaling requirements. Tuning the CTD on interfaces impacts distribution of SPVC/SVC over the network.
CTD includes processing and queueing delays plus propagation delay, as measured in calls per second.
CDV is defined at a per-interface and per- service class basis. The CDV is one of the key elements used in to optimize route selection, and for meeting QoS-based signalling requirements. Tuning the CDV on interfaces impacts the distributions of SPVC/SVC over the network. CDV is measured peak-to-peak, in micro-seconds.
When multiple links connect two PNNI nodes, you can configure preferences that prioritize one link any given SVC/SPVC, based on the AW, AvCR, or randomizing. This mechanism may be used in the network design process to layout the traffic behavior on parallel links between nodes or peer groups.
Cell loss ratio for CLP0 traffic (CLR0) the maximum cell loss ratio for CLP0 traffic over a link or node.
Cell loss ratio for CLP0+1 traffic (CLR0+1) is the maximum cell loss ratio for CLP0+1 traffic over a link or node.
Per the PNNI protocol, advertisement only occurs at for significant changes. The network would be overwhelmed with PNNI advertisement packets if its frequently changed parameters generated advertisements every time they changed. Changes in CDV, MaxCDT, or AvCR are measured in terms of a proportional difference from the last value advertised. A proportional multiplier threshold expressed as a percentage provides flexible control over the definition of significant change.
For some parameters, such as AW, any change in value is considered significant.
Crankback is a PNNI signaling mechanism that triggers re-routing if call-setup encounters a failure, such as a broken line or resource unavailability. If call setup encounter such a failure, Crankback passes re-routing responsibility back to the last node that generated a designated transit list (DTL). The release carries a specific log of the problem; the re-routing node considers this to determine a call-setup path that avoids the blocked link. Failing that, it initiates further crankback of the call.
Tranversion of any peer-group requires a border node from that peer group to create a new DTL, and a node can only alter a DTL that it created. Therefore, routing can only change within a peer group, unless call-setup cranks back to the originating node.
In an SPG, crankback must always return re-routing responsibility to the originating node.
As stated in "How Does PNNI Work?" section, address selection largely determines a WAN topology design, particularly if the WAN employs dynamic addressing. Unfortunately, there is no algorithm that determines which addresses are best chosen for a given architecture. However, there are factors that a designer should consider.
If you must bring a PNNI node down, use the command
The command that brings up a node is found in the "Bringing Up a PNNI Node," which appears earlier in this chapter.
Before you change the node's default configuration, remember that the MGX 8850 Release 2 defaults to a working PNNI configuration that operates in flat ATM networks topologies. All
MGX 8850 Release 2 CLI commands are explained in detail in the Cisco MGX-8850 Routing Switch Command Reference guide.
Configure the following nodal attributes with the command cnfpnni-node:
atm-address | Node's ATM address. |
level | PNNI hierarchical level. This must remain identical on all SPG nodes. |
node-id | Node's identifier. Once assigned, you may only change it while the node's administrative status is disabled (while the node is disabled). |
pg-id | Node's peer group ID. Once assigned, you may only change it while the node's administrative status is disabled (while the node is disabled). |
enable | Node's administrative status, either enable or disable. |
transitRestricted | Specifies if node is a restricted transit node. |
complexNode | Specifies if the node is a complex node (complex nodes are not supported by MGX 8850, Release 2 software image). |
branchingRestricted | Specifies if node supports additional point-to-multipoint branches. |
pglNoTransit | |
nodeName | Node's name. |
Configure PNNI SVCC-based RCC variables with the command cnfpnni-svcc-rcc-timer. This defines a node's initial PNNI SVCC-based variables, as follows:
node-index | Node's index. |
init-time | Time (in seconds) that the node delays initiating establishment of an SVCC to a neighbor with a numerically lower ATM address, after determining that such an SVCC should be established. |
retry-time | Time (in seconds) that the node delays before attempting to re-establish an SVCC-based RCC after the RCC is unexpectedly torn down. |
calling-integrity-time | Time (in seconds) that the node waits for a sent SVCC to become fully established before giving up and tearing it down. |
called-integrity-time | Time (in seconds) that the node waits for a received SVCC to become fully established before giving up and tearing it down. |
Configure the routing policies used for background routing tables generation with the command cnfpnni-routing-policy.
epsilon Indicates the node's policy in determining equal-cost path during routes calculation. holddown Defines the node's minimum time interval between two consecutive calculations for generating routing tables. bn-path-holddown Defines the minimum time interval between two consecutive calculations for generating border node path in a peer group for a complex node representation at the next higher level. (complex nodes are not supported by MGX 8850, Release 2 software image) loadBalance Defines the node's load balancing rule if alternative equal-lose routes exist for the call request. onDemand Defines the node's on-demand routing rule, either to:
Configure a PNNI interface service category-based administrative weight and aggregation token with the command cnfpnni-intf.
token | This is a 32-bit number used for link aggregation purpose. When an interface is added, the default is 0. |
aw | Number used as administrative weight on this interface. |
Configure the PNNI timers with the command cnfpnni-timer. You can define the initial PNNI timer values and significant change thresholds of a PNNI logical node.
node-index | Logical node's node index. |
hello-holddown | Value for the Hello hold down timer that limits the rate at which it sends Hellos. |
hello-interval | Initial value for the Hello timer. |
hello-inactivity-factor | Inactivity time factor on a horizontal link between two logical nodes. |
ptse-refresh-interval | Time allowed for the PTSE to re-originate. |
ptse-lifetime-factor | Value for the lifetime multiplier, expressed as a percentage. The product of it and the ptse-refresh-interval is used as the initial value of the remaining lifetime of a self-originated PTSE. |
retransmit-interval | Period between retransmissions of unacknowledged DS, PTSE request, and PTSP. |
ptse-delayed-ack-interval | Minimum time allowed between transmissions of delayed PTSE acknowledgment packets. |
avcr-pm | Proportional multiplier used in the algorithms that determines significant change for AvCR parameters. |
avcr-mt | Minimum threshold used in the algorithms that determine significant change for AvCR parameters. |
cdv-pm | Proportional multiplier used in the algorithms that determine significant change for CDV parameters. |
ctd-pm | Proportional multiplier used in the algorithms that determine significant change for CTD parameters. |
Posted: Mon Aug 7 08:42:32 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.