|
|
This chapter provides information about the two ATM routing protocols, the Interim Interswitch Signaling Protocol (IISP) and Private Network-Node Interface (PNNI). IISP provides a static routing solution that is not easily scalable and has no support for quality of service (QoS). PNNI provides a highly scalable routing solution with dynamically determined routing paths and support for QoS requirements.
 |
Note The information in this chapter is applicable to the Catalyst 8540 MSR, Catalyst 8510 MSR, and LightStream 1010 ATM switch routers. For detailed configuration information, refer to the ATM Switch Router Software Configuration Guide and the ATM Switch Router Command Reference publication. |
This chapter includes the following sections:
Although less powerful and complex than PNNI, IISP is still used today to allow backward compatibility with switches not yet implementing ATM Forum-compliant PNNI. IISP can also be used to isolate distribution of PNNI information in specific network design scenarios.
|
Note Your ATM switch router supports both IISP and PNNI. |
To enable UNI signaling, switches arbitrarily take the role of UNI user or network side on either end of an IISP link. Signaling requests are routed between switches using configured address prefix tables within each switch. These tables are configured with the address prefixes that are reachable through each port on the switch. When a signaling request is received by a switch, the switch checks the destination ATM address against the prefix table and notes the port with the longest prefix match. It then forwards the signaling request across that port using UNI procedures.
Routing using IISP requires manual configuration of the routing tables. For a small number of paths this is a relatively simple task, but in a large network the configuration can be time-consuming and prone to error. In Figure 7-1, for example, routes to each of the three router end systems would have to be configured on each of the ATM switch routers.
Configuring static routing using IISP requires the following steps:
Step 2 Save the running configuration to the startup configuration.
Step 3 Reload the ATM switch router.
The ATM switch router is now configured for static routing. In static routing mode it does not function as a PNNI device.
Step 4 Configure the ATM address of the ATM switch router (optional).
Step 5 From interface configuration mode, configure the interface as IISP.
This procedure is described in the "IISP Interfaces" section.
Step 6 Configure a static route to a reachable address prefix.
A static route on an interface allows all ATM addresses matching the configured address prefix to be reached through that interface.
Among the advantages offered by IISP are the following:
Potential limitations offered by IISP are the following:
The PNNI protocol provides mechanisms to support scalable, QoS-based ATM routing and switch-to-switch switched virtual connection (SVC) interoperability. To do so, the PNNI specification addresses two issues, signaling and routing.
The features supported by PNNI signaling include the following:
Features of PNNI routing include the following:
PNNI uses a number of mechanisms to support its signaling and routing features. These are described in the following subsections.
When the Hello protocol has declared a link to be functional, the adjacent switches exchange a summary of their database contents. The aim of this process is to compare one node's view of the topology with a neighboring node's view. By exchanging the differences, they can synchronize their databases and both will have the same topological information.
Reachability information is the first step in routing a PNNI request for a connection. The connection is directed to a node that advertises a prefix that matches the leading portion of the destination address. The connection always uses the longest matching advertisement.
Reachable addresses are advertised with one of two parameters:
To support QoS routing, the status of links and nodes is advertised using metrics and attributes. Metrics are combined along a path. For example, the administrative weight of a path is the sum of the weights of all links and nodes along the path. Attributes are treated differently. If one attribute value violates the QoS constraint of the call request, that topological element (node or link) is eliminated from the path selection.
The metrics that are advertised and used in path computation are as follows:
The attributes that are advertised for links and nodes are as follows:
To reduce the potential for the network to be overwhelmed by PNNI advertisements when parameters frequently change, a mechanism exists to limit advertisements below a set threshold. Changes in CDV, MCTD, and AvCR are measured in terms of a proportional difference from the last value advertised and are advertised only if they are significant. Changes in administrative weight, on the other hand, are always considered significant and are therefore advertised.
The final decision regarding whether a call can proceed over a given link is made at the node's own Connection Admission Control (CAC), a function that evaluates only the local resources and determines whether it has sufficient bandwidth to meet the call's QoS requirements. The CAC algorithm, which varies in its particulars from vendor to vendor, first calculates available resources by subtracting the resources currently in use from the total resources. It then compares the requirements of the call's setup request to the remaining resources and makes a determination.
For a complete description of Cisco's CAC implementation and algorithm, see the "Connection Admission Control" section.
The ATM switch router supports two flavors of GCAC. The first, simple GCAC, requires advertisement of only AvCR. The second, complex GCAC, uses two additional parameters that can optionally be advertised, cell rate margin (CRM) and variance factor. While the Cisco ATM switch router does not advertise these two parameters, it does support them if advertised by other nodes.
Once the requirement of a unified view of the network topology and its state has been met, PNNI can route a call through the network, honoring the call's request for specific QoS parameters. Figure 7-2 shows a hypothetical network in which a call is to be routed from end system A to end system B.
The following sequence describes the process of routing a call from end system A to end system B:
1. A connection request arrives at switch 1 over the UNI from end system A. A longest match comparison is done for the destination address to determine which destination switch connects to the address.
3. Once such a path is found, the node constructs a designated transit list (DTL) that describes the complete route to the destination and inserts this into the signaling request. When possible, the ATM switch router uses a path that has been precomputed in the background—a process similar to the cache concept. If a path cannot be found that satisfies the QoS requirements using precomputed paths, the ATM switch router performs an on-demand path calculation.
4. The setup request is forwarded along the path specified by the DTL. At each node along the way, signaling asks PNNI for an acceptable set of links to reach the next node along the path. The list is ordered based upon the configured link selection options and is handed to the CAC routine which determines the first acceptable link. If no link passes the CAC checks, a crankback is performed. See the description of the crankback mechanism that follows these steps.
5. If the request passes CAC for each designated hop, a signaling connect message is returned along the same path and, after it reaches the source node, data transfer begins.
PNNI employs a crankback mechanism to reroute a call that fails CAC at any point in the path specified by the DTL. Crankback improves the call setup success rate, which can be limited by the lack of a complete view of the network topology, due to summarization of information. Crankback also provides immediate alternate rerouting without the delay inherent in waiting for topological updates that can take time to propagate through the network. For crankback (see Figure 7-3), a message is returned to the node that generated the DTL, which includes crankback information about the cause and location of the problem. If the call is retried, PNNI prevents the failing node or link from being considered when it generates an alternate path. This process might occur several times before a successful path is found, or a determination is made that there is no suitable path.
One of PNNI's main goals is scalability. Scalability is achieved in PNNI by creating a hierarchical organization of the network, which reduces the amount of topological information PNNI has to store. It also reduces the amount of PNNI traffic and processing.
However, you can also use the PNNI hierarchy for other needs, such as creating an administrative boundary. For example, you can use the PNNI hierarchy to hide the internal details of a peer group from ATM switches outside of the peer group. This might be the case, for example, when connecting multiple sites using VP tunnels.
The key components of the PNNI hierarchy follow:
|
Note The lowest level of the hierarchy always has the highest level indicator. For example, given two entities, where one is the ancestor of the other, the ancestor is a higher-level entity but has a smaller level indicator than the lower-level entity. |
The relationship between PGL and LGN is further described in the "Higher Levels of the PNNI Hierarchy" section.
To create a PNNI network hierarchy, ATM switches at the lowest hierarchical level can be organized into multiple peer groups. Then some of the nodes in each peer group can be configured to have their peer group leader election priority greater than zero and can have a parent node designated. The peer group then elects a peer group leader, and its parent node becomes active.
The purpose of the active parent node, or LGN, is to represent the entire peer group to other LGNs. Within each peer group, all nodes exchange complete topology database information with one another. However, the LGN reduces the amount of information shared with other peer groups by sending only a limited amount of summarized or aggregated information to its neighbor LGNs, which in turn flood that information down to all nodes within their child peer group.
Figure 7-4 shows a flat network topology, where every node maintains information about every physical link in the network and reachability information for every other node in the network.
Figure 7-5 shows the same nodes organized into a PNNI hierarchical network topology. Each node in a given peer group shares complete and identical information about the peer group's topology. Information about other peer groups comes from the upper level node, where LGNs (not shown in the figure) aggregate information from the PGLs at the lower level. As the flat network is migrated to a hierarchical network, aggregation of topological and reachability information reduces exponentially the number of nodes, links, and reachable address prefixes visible from any one ATM switch in the network.
The aggregation of reachability and topology information allows PNNI networks to scale to very large numbers of nodes. PNNI handles several types of aggregation:
In some cases the default topology aggregation can lead to nonoptimal routing. This situation is addressed using complex node representation. See the "Complex Node Representation for LGNs" section.
The main advantages of a hierarchical implementation of PNNI are the following:
A limitation of PNNI hierarchy is the loss of information caused by topology aggregation. PNNI performs route computations based on its view of the network topology. Because a hierarchical view of the network is restricted, compared to a nonhierarchical (flat topology) view, routing decisions are not as efficient as in a flat topology. In both cases, a path to the destination is selected; however, in most cases the path selected in a flat topology is more efficient. This trade-off between routing efficiency and scalability is not specific to PNNI; it is a known limitation of any hierarchical routing protocol.
If your network is relatively small and scalability is not a problem, and the PNNI hierarchy is not required for other reasons, the benefits of a flat PNNI network can far outweigh the benefits of a hierarchical PNNI network.
The decision to implement a PNNI hierarchy depends on many factors, including the size of the network, type of network traffic, call setup activity, and the amount of processing and memory required to handle the PNNI control traffic. Because you must consider several factors, and their interdependency is not easily quantifiable, it is not possible to specify the exact number of nodes above which a flat network must be migrated to a hierarchical network. A high CPU load caused by PNNI control traffic can be a strong indication that a hierarchical organization of the topology is needed.
This section discusses the use of the autoconfigured ATM address, considerations for E.164 addresses, and provides guidelines for adopting an addressing scheme for your PNNI network.
The preconfigured ATM address, as described in the "Autoconfigured ATM Addressing Scheme" section provides plug-and-play operation in isolated flat topology ATM networks.
All preconfigured addresses share the same 7-byte address prefix. This prefix allows all lowest-level PNNI nodes to generate the same default peer group identifier at level 56. When you interconnect multiple ATM switches, one large autoconfigured peer group is created at level 56. The next 6 bytes comprise the MAC address of the ATM switch. The 7-byte address prefix combined with the 6-byte MAC address provide a 13-byte prefix that uniquely identifies each ATM switch. This 13-byte prefix is also the default ILMI address prefix and is used by ILMI for address registration and summarization. Although in this scheme the preconfigured addresses are globally unique, they are not suitable for connection through service provider networks using SVCs or within hierarchical PNNI networks. Furthermore, address summarization is not possible beyond the level of one ATM switch.
The address format used in PNNI is the ATM End System Address (AESA), as described in the "Addressing" section. Besides the three types of AESAs (E.164, ICD, and DCC), ATM networks also use E.164 numbers, also known as native E.164 addresses. E.164 numbers are supported on UNI and IISP interfaces, but are not directly supported by PNNI. Instead, these are supported indirectly through use of the E.164 AESA format.
|
Note Refer to the ATM Forum UNI specifications for more information. |
PNNI address prefixes are usually created by taking the first p (0 to 152) bits of an address. The encoding defined for E.164 AESAs creates difficulties when using native E.164 numbers with E.164 AESAs.
The encoding defined for E.164 AESAs in the ATM Forum UNI specifications is shown in Figure 7-6.
For example, all international E.164 numbers that represent destinations in Germany begin with the country code 49. The length of international E.164 numbers in Germany varies between 9
and 12 digits. To configure static routes to all E.164 numbers in Germany, you would configure static routes to the following set of E.164 AESA prefixes:
E.164 numbers that share a common prefix can be summarized by a single reachable address prefix, even when the corresponding set of full E.164 numbers varies in length. For this reason, the encoding of E.164 address prefixes is modified to a left-justified format, as shown in Figure 7-7.
The left-justified encoding of the international E.164 number within the IDI allows for a single E.164 AESA prefix to represent reachability to all matching E.164 numbers, even when the matching E.164 numbers vary in length. Before PNNI routing looks up a destination address to find a route to that address, it converts the destination address from the call setup in the same way and then carries out the longest match lookup.
|
Note The converted encoding of the E.164 AESA is not used in PNNI signaling. The conversion is only used for PNNI reachable address prefixes, and when determining the longest matching address prefix for a given AESA. Full 20-byte AESAs are always encoded as shown in Figure 7-6. |
Configuration Overview
The ATM switch router supports the left-justified encoding of E.164 AESAs. Enabling this feature has the following implications:
You can obtain globally unique address prefixes from a national or world registration authority or they can be suballocated to you from a service provider's address space. See the section "Obtaining Registered ATM Addresses" section for information on obtaining and registering ATM addresses. Make sure that the addresses you assign in your network are derived from a globally unique address prefix, as shown in Figure 7-8.
The high order domain-specific part (HO-DSP) remainder, the part of the address between the assigned ATM address prefix and the ESI, should be assigned in a hierarchical manner. All systems in the network share the assigned ATM address prefix. The assigned address space can be further subdivided by providing longer prefixes to different regions of the network. Within each peer group, the first level bits of each ATM switch address should match the corresponding bits of the Peer Group Identifier (PGI) value. An example of a hierarchical address assignment is shown in Figure 7-9.
Note that the address prefix is longer at each lower level of the PNNI hierarchy shown in Figure 7-9.
The advantages of hierarchical address assignment include:
When the ATM network topology (which consists of switches, links, and virtual path [VP] tunnels) differs from the logical topology (which consists of VPNs and virtual LANs), it is important that the address hierarchy follow the network topology. You can construct the logical topology using other features, such as emulated LANs or Closed User Groups (CUGs).
You can subdivide the HO-DSP remainder to allow for upward and downward future growth. For example, assume that you have 6 octets available for the HO-DSP remainder: 8 through 13 (as shown in Figure 7-10).
The HO-DSP remainder in this example spans levels 56 through 104. To allow for future expansion at the lowest level of the hierarchy, you must provide sufficient addressing space in the HO-DSP remainder to accommodate all future switches. Assume that you start with the lowest level at 88. For administrative purposes, in the future you might want to group some of these switches into peer groups where additional switches can be added. For those switches that will be part of the new peer group you should assign addresses that can be easily clustered into a level 96 peer group. These addresses would share a common 12th octet, leaving the 13th octet for downward future expansion. The octet pairs (12 and 13) for these switches could be as follows: (01, 00), (02, 00), (03, 00) and so on, while switches that will be added in the future could be: (02, 01), (02, 02), (02, 03) and so on.
This type of addressing scheme leaves room for expansion without requiring address modification. If you add a hierarchical level 96, the switches form a new peer group at level 96. Although you started with no more than 256 switches at the lowest level, by expanding this to two levels in the future, you can accommodate up to 65,536 switches in the same region. An example of HO-DSP assignment is shown in Figure 7-11.
Following similar guidelines, you can plan for future expansion in the upward and downward direction. Specifically, you can expand upward by adding hierarchical levels as your network grows in size.
This section describes the configuration of a flat PNNI network and provides an overview of the tasks involved.
To configure a lowest level of the PNNI hierarchy requires the following steps:
Step 2 Configure static routes
Step 3 Configure a summary address
Step 4 Configure scope mapping
These tasks are described in the following sections.
The default PNNI configuration of the ATM switch router is a node at level 56. To configure a node in a higher level of the PNNI hierarchy, the value of the node level must be a smaller number. For example, a three-level hierarchical network could progress from level 72 to level 64 to level 56. Notice that the level numbers graduate from largest at the lowest level (72) to smallest at the highest level (56). (See Figure 7-9 earlier in this chapter.)
Configuration Overview
To change the active ATM address and (optionally) change the node level requires the following steps:
Step 2 Display the new ATM address to verify it.
Step 3 Remove the old ATM address.
Step 4 In ATM router configuration mode, disable the PNNI node.
Step 5 Reenable the PNNI node and, if necessary, specify a new node level.
Disabling then reenabling the node recalculates the node IDs and peer group IDs.
|
Note Two PNNI peer groups can be connected using the IISP protocol. Connecting PNNI peer groups requires that a static route be configured on the IISP interfaces, allowing connections to be set up across the IISP link(s). |
Configuration Overview
Configuring a static route requires the following steps:
This procedure is described in the "IISP Interfaces" section.
Step 2 Configure a static route to a reachable address prefix.
A static route on an interface allows all ATM addresses matching the configured address prefix to be reached through that interface.
We recommend that you use summary addresses when all end system addresses that match the summary address are directly reachable from the node. If an end system that matches the summary address is not directly reachable from the node, it can still be reached assuming that the advertised prefix is longer than the summary address. This is because PNNI always selects the nodes advertising the longest matching prefix to a destination address.
By default, each lowest-level node has a summary address equal to the 13-byte address prefix of the ATM address of the switch. This address prefix is advertised into its peer group.
|
Note Summary addresses less than 13 bytes long must not be used with autoconfigured ATM addresses, since other switches with autoconfigured ATM addresses matching the summary can exist outside of the default PNNI peer group. |
Configuration Overview
If all nodes and end systems in your PNNI network are running ILMI, you do not need to configure reachable addresses to establish calls between end systems. If, however you do not run ILMI you might need to configure reachable addresses; for example, when you have an address you need to reach over an IISP connection.
Summary addresses, other than the default, must be configured on each node. Each node can have multiple summary address prefixes. Configuring summary address prefixes requires the following steps:
Perform this step when system that match the first 13 bytes of the ATM address(es) of the node are attached to different ATM switch routers. You might also want to use this for security purposes.
Step 2 Select the node by its node index and disable autosummarization.
Step 3 Configure the ATM PNNI summary address prefix.
|
Note On UNI and IISP interfaces, the scope is specified in terms of organizational scope values ranging from 1 (local) to 15 (global). (Refer to the ATM Forum UNI Signaling 4.0 specification for more information.) |
In PNNI networks, the scope is specified in terms of PNNI levels. The mapping from organizational scope values used at UNI and IISP interfaces to PNNI levels is configured on the lowest-level node. The mapping can be determined automatically (which is the default setting) or manually, depending on the configuration of the scope mode.
In manual mode, whenever the level of node 1 is modified, the scope map should be reconfigured to avoid unintended suppression of reachability advertisements. Misconfiguration of the scope map might cause addresses to remain unadvertised.
In automatic mode, the UNI to PNNI level mapping is automatically reconfigured whenever the level of the node 1 is modified. The automatic reconfiguration avoids misconfigurations caused by node level modifications. Automatic adjustment of scope mapping uses the values shown in Table 7-1.
| Organizational Scope | ATM Forum PNNI 1.0 Default Level | Automatic Mode PNNI Level |
|---|---|---|
1 to 3 | 96 | Minimum (l,96) |
4 to 5 | 80 | Minimum (l,80) |
6 to 7 | 72 | Minimum (l,72) |
8 to 10 | 64 | Minimum (l,64) |
11 to 12 | 48 | Minimum (l,48) |
13 to 14 | 32 | Minimum (l,32) |
15 (global) | 0 | 0 |
Configuration Overview
Configuring the scope mapping requires the following steps:
Step 2 Configure the scope mode to manual.
The automatic scope mode ensures that all organizational scope values cover an area at least as wide as the current node's peer group. Configuring the scope mode to manual disables this feature, and no changes can be made without explicit configuration.
Step 3 Configure the new scope mapping.
Each peer group can contain one active PGL. The PGL is a logical node within the peer group that collects data about the peer group to represent it as a single node to the next PNNI hierarchical level. Upon becoming a PGL, the PGL creates a parent LGN. The LGN represents the PGL's peer group within the next higher level peer group. The LGN aggregates and summarizes information about its child peer group and floods that information into its own peer group. The LGN also distributes information received from its peer group to the PGL of its child peer group for flooding. Figure 7-12 shows an example of PGLs and LGNs.
When creating the PNNI hierarchy, keep in mind the following guidelines:
|
Note The choice of PGL does not directly affect the selection of routes across a peer group. |
Configuration Overview
Configuring the higher levels of the PNNI hierarchy requires the following steps:
Step 2 Configure the node name.
Step 3 Configure a parent node.
Step 4 Configure the node election leadership priority.
Step 5 Configure a summary address.
These tasks are described in the following sections.
Higher level nodes only become active if:
Configuration Overview
Configuring an LGN and peer group identifier requires the following steps:
Step 2 Configure the logical node with the node index, level, and, optionally, peer group identifier.
The peer group identifier defaults to a value created from the first part of the child peer group identifier, and does not need to be specified. If you want a non-default peer group identifier, you must configure all logical nodes within a peer group with the same peer group identifier.
Step 3 If you have more than one logical node on the same switch, specify a different node index to distinguish it.
If you prefer higher level node names that more accurately reflect the child peer group, you can assign a new name to a node at any level. For example, you could change the parent node name to Calif1 to represent the entire geographic region of the peer group to which it belongs.
Configuration Overview
Configuring a new node name requires the following steps:
Step 2 Specify the new name.
We recommend you choose a node name of 12 characters or less so that your screen displays remain nicely formatted and easy to read.
After a node name has been configured, it is distributed to all other nodes by PNNI flooding.
For a node to be eligible to become a PGL within its own peer group, it must have a configured parent node and nonzero election leadership level (described in the next section, "Node Election Leadership Priority"). If the node is elected a PGL, the node specified as the parent becomes the parent node and represents the peer group at the next hierarchical level.
Configuration Overview
Configuring a parent node requires the following steps:
Step 2 Specify a node index for the parent.
You must use a node index higher than the index of the child node.
|
Note The choice of PGL does not directly affect the selection of routes across the peer group. |
The control for election is done through the assignment of leadership priorities. We recommend that the leadership priority space be divided into three tiers:
This subdivision is used because when a node becomes PGL, it increases the advertised leadership priority by a value of 50. This avoids instabilities after election.
Configuration Overview
Configuring the node election leadership priority requires the following steps:
Step 2 Assign the node an election leadership priority number.
The following guidelines apply:
We recommend that you use summary addresses when all end system addresses that match the summary address are directly reachable from the node. If an end system that matches the summary address is not directly reachable from the node, it can still be reached assuming that the advertised prefix is longer than the summary address. This is because PNNI always selects the nodes advertising the longest matching prefix to a destination address.
A single default summary address is configured for each LGN in the PNNI hierarchy. The length of that summary for any LGN equals the level of the child peer group, and its value is equal to the first level bits of the child peer group identifier. This address prefix is advertised into the LGN's peer group. For example, switch A has two PNNI nodes running on it:
The switch ATM address is 47.0091.4455.6677.1144.1017.3333.0060.3e7b.3a01.00. The summary address prefix of the LGN (node 2) is 47.0091.4455.6677.1144.1017.33; that is, the first 96 bits of the node 1 address.
Summary addresses other than defaults must be explicitly configured on each node. A node can have multiple summary address prefixes. Note that every node in a peer group that has a potential to become a PGL should have the same summary address lists in its parent node configuration.
Configuration Overview
Configuring the nondefault summary address requires the following steps:
Step 2 Disable autosummarization.
Step 3 Configure the new summary address prefix.
This section describes advanced PNNI features that allow you to fine-tune the performance of your PNNI network. These features include adjusting parameters that affect route selection, parameters that are used in calculating topology attributes, and parameters that are used by the protocol to manage and distribute information.
This section describes features you can use to tune the mechanisms by which routes are selected in your PNNI network.
The background routes mode should be enabled in large networks where it usually exhibits less-stringent processing requirements and better scalability. Route computation is performed at almost every poll interval when a significant change in the topology of the network is reported or when significant threshold changes have occurred since the last route computation. It is most effective in networks where the topology with respect to QoS is relatively stable. Campus LANE networks can use this feature very effectively, since all the SVCs in the network belong to the UBR or ABR category.
Configuration Overview
Enabling background route computation requires the following steps:
Step 2 Enable background route computation.
You can specify a threshold for the number of insignificant changes necessary to trigger a new computation. You can also specify a poll interval for detecting the changes that trigger recomputation.
|
Note Calls always use the load balance method over parallel IISP links between two switches. |
Table 7-2 lists the PNNI link selection methods from which you can choose.
The switch applies a single link selection method for a group of parallel links connected to a neighbor switch. If multiple links within this group are configured with a different link selection method, then the switch selects a method according to the order of precedence as shown in Table 7-2. For example, if any link within the parallel link group is configured as admin-weight-minimize, then admin-
weight-minimize becomes the link selection method for the entire group. Further, the admin-weight-
minimize, blocking-minimize, and transmit-speed-maximize methods are only available to guaranteed service categories (CBR, VBR-NRT, and VBR-RT) with the default set at blocking-minimize. Best effort traffic (ABR and UBR) is always load balanced by default.
You can also specify one or more links among the parallel links as an alternate (or backup) link. An alternate link is a link that is used only when all other non-alternate links are either down or full. Alternate links are not considered part of the parallel link group targeted for link selection. By default, calls are always load balanced over multiple parallel alternate links.
Configuration Overview
Link selection is configured on a per-interface basis. To configure link selection, take the following steps:
Step 2 Configure the link selection method and specify the traffic category. Additionally, you can specify an alternate link on an interface.
Administrative weight is a cumulative metric and provides a measure similar to hop count. The maximum administrative weight percentage feature thus provides a generalized form of a hop count limit. The maximum acceptable administrative weight is equal to the specified percentage of the least administrative weight of any route to the destination (from the background routing tables). For example, if the least administrative weight to the destination is 5040 and the configured percentage is 300, the maximum acceptable administrative weight for the call is 5040 * 300 / 100, or 15120.
Configuration Overview
The maximum administrative weight percentage feature is disabled by default on the ATM switch router. The feature, when enabled, only takes effect if background route computation is also enabled.
Configuring the maximum administrative weight percentage requires the following steps:
Step 2 Specify the maximum administrative weight percentage. You configure the maximum administrative weight percentage with a value from 100 to 2000.
Reachable addresses fall into the following categories:
Local internal reachable addresses, whether learned via ILMI or as static routes, are given highest precedence or a precedence value of one. The other reachable address types have default values of 2 through 4; you can modify these values through manual configuration.
Configuration Overview
Configuring the reachable address precedence requires the following steps:
Step 2 Specify the reachable address type and a precedence value.
When you configure the precedence for reachable address types, you are modifying the default values used by the ATM switch router. Refer to your ATM switch router software documentation for the default values of each reachable address type.
The explicit path feature enables you to manually configure either a fully specified or partially specified path for routing soft permanent virtual channel connections (soft PVCCs) and soft permanent virtual path connections (soft PVPCs). Once these routes are configured, up to three explicit paths can be applied to these connections.
A fully specified path includes all adjacent nodes (and optionally the corresponding exit port) for all segments of the path. A partially specified path consists of one or more segment target nodes that should appear in their proper order in the explicit path. The standard routing algorithm is used to determine all unspecified parts of the partially specified path.
Configuration Overview
Step 2 Add entries to the explicit path. You can add three types of entries:
a. Next-node—specifies the next adjacent node for fully specified paths.
b. Segment-target—specifies the target node for cases where the path through intermediate nodes should be automatically routed.
c. Exclude-node—specifies nodes or ports that are excluded from all partial path segments.
You can also edit an explicit path after configuring it, or modify an explicit path while it is in use; see the "Soft PVCs with Explicit Paths" section. For detailed information on configuring and editing explicit paths, refer to the ATM switch router software documentation.
This section describes features you can use to tune the topology attributes of your PNNI network.
In the absence of other constraints, configuring the administrative weight as uniform causes PNNI routing to minimize the number of hops. Basing administrative weight on linespeed allows path selection to prefer paths along higher bandwidth interfaces. This happens because in linespeed mode higher speed links have lower administrative weights, and are thus preferred during route selection. Figure 7-13 provides an example of how network administrative weight works.
The network depicted at the top of Figure 7-13 is configured as uniform, causing equal administrative weight to be assigned to each link. The identical network at the bottom of the figure is configured as linespeed. The links between SW1 and SW2 (SW1p1 to SW2p1) and SW2 and SW3 (SW2p2 to SW3p2) are both faster OC-12 connections and therefore have lower administrative weights. PNNI interprets the route over the two OC-12 links as being administratively equivalent to a more direct route between SW1 and SW3 using the OC-3 connection.
Configuration Overview
When you assign the global administrative weight mode, you are doing so for all links attached to the node. Configuring the global administrative weight mode requires the following steps:
Step 2 Specify the administrative weight mode as uniform or linespeed.
With uniform mode, every link has a default value of 5040. With linespeed, the value of administrative weight is assigned a value inversely proportional to the speed of the interface.
Configuring a specific administrative weight on an interface requires the following steps:
Step 2 Specify an administrative weight value and, optionally, a service category.
When you specify a service category, you limit the use of this value to calls requesting that service category.
Configuration Overview
The following steps are required to block transit calls on a node:
Step 2 Enable transit restriction.
Configuration Overview
The route redistribution feature is enabled by default on the ATM switch router. Disabling the feature requires the following steps:
Step 2 Disable static route redistribution.
Figure 7-14 shows four physical links between four nodes in the two lower-level peer groups. Two physical links between two nodes in different peer groups are assigned the PNNI aggregation token value of 221; the other two are assigned the value of 100. These four links are summarized and represented as two links in the next higher PNNI level.
Configuration Overview
Configuring the aggregation token requires the following steps:
Step 2 Assign an aggregation token value.
The following guidelines apply when configuring the PNNI aggregation token:
In the PNNI hierarchy, link aggregation is used to represent several parallel links between two peer groups as a single higher-level link, as shown in Figure 7-14. The ATM switch router has two algorithms, best link and aggressive, which control how the metrics for the higher level links are derived from the individual parallel links that have the same aggregation token. The aggregation mode can be assigned for links or for nodes with complex node representation (see the "Complex Node Representation for LGNs" section).
When specified for complex nodes, best link selects the parameters from a single path even when multiple paths exist between the border nodes. The best path for each service category is chosen based on a single metric considered most important for the service category.
When specified for complex nodes, the aggressive mode selects the best parameters from among multiple paths joining a pair of border nodes. The resulting path metrics might look better than any single real path between the border nodes. This mode can make it more likely that connections will be routed through the complex LGN.
Configuration Overview
Configuring the aggregation mode requires the following steps:
Step 2 Specify link or node, the service category, and aggregation mode. The metrics for the specified service category are aggregated using the mode you select.
|
Note Any change in administrative weight or CLR is considered significant and triggers a new PTSE. |
Configuration Overview
The ATM switch router uses default values to determine when to trigger PTSEs. When you configure the significant change threshold parameters, you are specifying a value, expressed as a minimum threshold percent or proportional multiplier, that defines when a change is significant. Available cell rate (AvCR), cell delay variation (CDV), and cell transfer delay (CTD) can be configured.
Configuring the significant change threshold requires the following steps:
Step 2 Specify the metric and percent of change.
You can configure additional parameters that affect the timing and frequency of Hello and PTSE exchanges, as described in the "PNNI Hello, Database Synchronization, and Flooding Parameters" section.
For example, in Figure 7-15, let us attempt to find the shortest path for a connection originating in Peer Group A.1 at node A.1.1 with a destination node within the peer group represented by LGN A.3.
Assume that LGN A.2 represents a peer group that contains a large number of nodes. If LGN A.2 is represented as a single node (simple node representation), then the shortest path appears to be the one shown as the thicker solid line, which appears to represent three "hops." However, since there are several internal hops required to transit across LGN A.2, the four-hop path shown by the dashed line is really the shortest path.
Simple node representation also hides information about link capacities within the peer group. If LGN A.2 represents a peer group that has links with very limited bandwidth, that information would also be unavailable to nodes in other peer groups.
In the simplest radius-only version, the LGN A.2 advertises only the metrics of a radius link to other peer groups. The radius metrics represent the aggregated (average) path metrics from any border node to a destination within the peer group. Its administrative weight can represent values larger than a single hop.
In Figure 7-16, for example, the cumulative administrative weight for the path through LGN A.2 reflects the multiple hops through the child peer group, and the shortest path can be chosen correctly.
Paths that transit a radius-only complex node are represented as a first hop from the entry port to the nucleus and a second hop from the nucleus to the exit port, both of which use radius metrics. This two-hop internal path is also referred to as the diameter of the complex node.
Figure 7-17 illustrates the information that can be sent in addition to the radius to further improve the accuracy of the complex node. Default spokes, exception spokes, and exception bypasses are all components that build the aggregated topology of the complex node. These components are advertised by PNNI in Nodal State Parameters (NSP) PTSEs.
A practical description of these components follows:
You can tune the degree of aggressiveness in presenting the resulting aggregated topology and its metrics by specifying best-link or aggressive aggregation mode. See the "Aggregation Mode" section.
For nodal aggregation there is a trade-off between routing accuracy and additional PNNI complex node PTSE generation. Here is the range of options that exist for nodal aggregation in order from the lowest routing accuracy to the highest routing accuracy.
The amount of PNNI processing and additional PTSE traffic also generally increases for the more accurate options.
For hierarchies with three or more levels, the same guidelines should be applied at all levels. If a third level LGN is representing a child peer group containing many nodes and LGNs, then it is more likely that the third level LGN should also use complex node representation.
However, running multiple complex nodes on the same ATM switch router can impact performance. Designing the network so that lowest level nodes are configured to run as peers of higher level nodes, can prevent the necessity of running more than two node levels on the same ATM switch router.
Configuration Overview
Nodal representation is configured as simple by default on the ATM switch router. To configure complex node representation requires the following steps:
Step 2 Enable complex node representation and optionally modify the handling of exceptions.
You can configure a nondefault threshold percentage for generation of more or fewer bypass or spoke exceptions. You can also specify to advertise radius metrics only with no bypass or spoke exceptions.
Step 3 Configure the aggregation mode (optional).
For details, see the "Aggregation Mode" section.
Step 4 Configure the aggregation token (optional).
Inaccurate nodal aggregation can result when higher level horizontal links are attempting to represent multiple links from widely separated border nodes in the child peer group. By assigning a separate aggregation token to the link on the border node that is farthest from the others, a separate horizontal link and port are created for the parent LGN, which can increase the accuracy of the complex nodal representation.
See the "Aggregation Tokens" section for further information.
The following sections describe how to tune some PNNI protocol parameters that can affect the performance of your network.
Configuration Overview
The ATM switch router uses default values for timers and related parameters. There are consequences to changing these values, and they must be adjusted cautiously. For information on all the parameters and their values, refer to your ATM switch router software documentation.
Configuring the Hello protocol and PTSP exchange parameters requires the following steps:
Step 2 Configure the Hello database synchronization and flooding parameters.
Step 3 Configure the timing and frequency of PTSE exchanges.
You can also configure the significant change threshold for PTSEs, as described in the "Significant Change Thresholds" section.
Configuration Overview
You can change the default value of the resource management poll interval used by the ATM switch router. A larger value usually generates a smaller number of PTSE updates. A smaller value results in greater accuracy in tracking resource information.
Configuring the resource management poll interval requires the following steps:
Step 2 Specify the number of seconds to use for the resource management poll interval.
Posted: Wed Sep 27 13:24:02 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.