|
|
This chapter provides a summary of switched virtual circuits with respect to the BPX Service Node and collocated Extended Services Processor. For additional information, refer to the BPX Service Node Extended Services Processor Installation and Operations document.
This chapter contains the following:
With a collocated Extended Services Processor (ESP), the BPX Service Node adds the capability to support ATM and Frame Relay Switched Virtual Circuits (SVCs) in addition to support for Permanent Virtual Circuits (PVCs) as shown in Figure 11-1.
The Private Network to Network Interface (PNNI) protocol is used to route SVCs across the network. PNNI provides a dynamic routing protocol which is responsive to changes in network availability and will scale to large networks.
BPX Service Node resources, such as port VPI range and trunk bandwidth are partitioned between SVCs and PVCs. This provides a firewall between the two types of connections so that any SVCs that come on-line and off-line do not affect the availability of existing PVC services.
The following SVC connections are supported with Release 8.4:
Both permanent virtual circuits and switched virtual circuits are defined by ATM and Frame Relay standards groups.
After being added to a network, permanent virtual circuits (PVCs) remain relatively static. The PVC only allocates a physical circuit and consumes bandwidth when there is data to send. However, the permanent virtual circuit remains in place, always available for use, and is similar to a dedicated private line in this respect.
A switched virtual circuit (SVC) only exists when there is data to send and a calling process has been initiated. With a switched virtual circuit, there must be some signaling mechanism to build a connection each time the user (ATM or Frame Relay device in this case) needs it. In addition, when the call is disconnected, there must be a mechanism for the orderly disconnection of the call, and the network's resources must be relinquished. During a disconnect, the Cisco WAN switching network sweeps through its connection tables and removes the connection.
ATM SVCs are ATM connections setup and maintained by a standardized signaling mechanism between ATM CPE (ATM user end systems) across a Cisco WAN switching network. ATM SVCs are created on user demand and removed when the call is over, thus freeing up network resources.
Frame Relay SVCs are Frame Relay connections setup and maintained by a standardized signaling mechanism between Frame Relay CPE (Frame Relay user end systems) across a Cisco WAN switching network. Frame Relays SVCs are created on user demand and removed when the call is over, thus freeing up network resources.
The BPX Service Node supports the UNI and NNI interfaces for SVC operations as described in the following:
Interim Inter-switch Protocol (IISP) is an interim static routing protocol defined by the ATM Forum to provide base level capability until the Private Network to Network Interface (PNNI) was specified. The IISP provides users with some level of multi-vendor switch interoperability based on the existing ATM Forum UNI 3.1 specifications. IISP assumes no exchange of routing information between switching systems. It uses a a fixed routing algorithm with static routes. Routing is done on a hop-by-hop basis by making a best match of the destination address in the call setup with address entries in the next hop routing table at a given switching system. Entries in the next hop routing table are configured by the user.
The Private Network to Network Interface standards essentially define two protocols:
To support ATM and Frame Relay SVCs, the BPX Service Nodes essentially overlay a signaling network over a traditional (that is PVC-based) network. This signaling network, indicated by the dashed lines in Figure 11-2, connects all of the BPX Service Nodes and extends to the CPE. The signaling plane establishes and maintains SVCs between the CPE, that is, end users, across a Cisco WAN switching wide-area ATM network.
The signaling plane is created out of two basic types of signaling channels:
The signaling VCCs are normally configured during the provisioning of UNI ports and NNI trunks.
There is an internal signaling VCC established between every UNI port on the BPX Service Node which will support ATM or Frame Relay SVCs and the ESP in the BPX Service Node. There are two types of UNI signaling channels supported by the BPX Service Node as shown in Figure 11-3.
There is also a signaling channel established between each adjacent pair of BPX Service Nodes. This NNI signaling channel shown in Figure 11-4 is configured for either IISP or PNNI protocol. During IISP configuration, one side of the NNI signaling connection is configured as the user side and a weight is assigned. In the figure, the direct line between the ATM NICs indicates a logical connection; the physical connection is configured through BPX 1 and BPX 2.
Because the BPX is an ATM switch, Frame Relay SVCs that are setup and established across the Cisco WAN switching network must be translated into an ATM format to be carried across the network. At the far end, where typically the connection is terminated on another Frame Relay CPE, the ATM cells will have to be converted back to Frame Relay format. This is referred to as Network Interworking. Network Interworking can be performed between Frame Relay CPE and ATM CPE when the ATM CPE recognizes that it is connected to an interworking function (Frame Relay, in this case). The ATM CPE must then exercise the appropriate service specific convergence sublayer (SSCS). The SSCS will then convert the ATM cells to Frame Relay traffic.
In this release of the BPX Service Node, all Frame Relay SVC connections must be between Frame Relay CPE (that is, Frame Relay end users) or ATM CPE that is aware that it is performing Network Interworking, and all ATM SVC connections must be between ATM CPE (that is ATM end users). In other words, Service Interworking between ATM and Frame Relay SVCs is not supported in this release. (ATM and Frame Relay Service Interworking for PVCs is supported by the BPX Service Node as part of Release 8.4.)
The Extended Services Processor (ESP) is an adjunct processor shelf integrated into the BPX Service Node.
The basic ESP features include:
Available in either AC- or DC-powered models (ESP-AC or ESP-DC), the ESP is an orderable option for the BPX switch. The ESP can be configured in both non-redundant and redundant configurations. For the redundant configuration, two ESPs are installed in the BPX Service Node.
The ESP uses three main physical interfaces, as shown in Figure 11-5:
The ESP also provides the following application interfaces:
 |
Note During a switchover, all SVC connections will be torn down and the ATM or Frame Relay CPE will have to initiate another SVC call to reestablish them. |
As shown in Figure 11-5, the BPX Service Node could have an Ethernet LAN connection to a Cisco WAN Manager workstation. Cisco WAN Manager discovers and monitors the ESP similarly to the way it does an Cisco MGX 8220 edge concentrator shelf. Cisco WAN Manager discovers the existence of the ESP when it is added to the BPX shelf with the addshelf command. After discovery, the ESP will be displayed on the Cisco WAN Manager topology map as a shelf attached to the BPX switch.
Cisco WAN Manager manages the BPX Service Node by providing:
During provisioning, resources on all UNI ports (both ATM and Frame Relay) are partitioned between SVCs and PVCs. Partitioning is performed using the BPX and Cisco MGX 8220 edge concentrator command line interfaces. This partitioning information is retrieved from the BPX by reading its port and trunk tables and from the Cisco MGX 8220 edge concentrator by reading the resource partitioning tables in the AUSM and FRSM MIBs.
The BPX line and routing or feeder trunk resources to be partitioned are:
Cisco MGX 8220 edge concentrator Feeder Trunk (BXM/BNI) resources to be partitioned are:
Cisco MGX 8220 edge concentrator AUSM port resources to be partitioned are:
Cisco MGX 8220 edge concentrator FRSM port resources to be partitioned are:
Posted: Tue Jan 16 11:04:51 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.