cc/td/doc/product/wanbu/bpx8600/8_4
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

SVCs, ATM and Frame Relay

SVCs, ATM and Frame Relay

This chapter provides a summary of switched virtual circuits with respect to the BPX Service Node and co-located Extended Services Processor. For additional information, refer to the BPX Service Node Extended Services Processor Installation and Operations document.

This chapter contains the following:

ATM and Frame Relay SVCs

With a co-located 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:

The ESP provides the BPX Service Node with the ATM or Frame Relay signaling function. It interprets industry-standard signaling messages from ATM or Frame Relay CPE to provide the call setup and tear down for switched virtual circuits across the ATM network. In addition to SVC signaling, the ESP also performs PNNI routing, collects statistics, and processes alarms and billing records for SVC connections through the BPX Service Node.

PVCs and SVCs

Both permanent virtual circuits and switched virtual circuits are defined by ATM and Frame Relay standards groups.

PVCs

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.

SVCs

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 StrataCom 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 StrataCom 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 StrataCom network. Frame Relays SVCs are created on user demand and removed when the call is over, thus freeing up network resources.


Figure 11-1: Wide Area Network with BPX Service Nodes

BPX Service Node Interfaces

The BPX Service Node supports the UNI and NNI interfaces for SVC operations as described in the following:

  For ATM SVCs, the UNI supports either the ATM Forum 3.0 or 3.1 signaling standards as well as traditional ATM PVCs. (Remember the BPX switch also supports high-speed ATM UNI ports.)
  For Frame Relay, the UNI supports Frame Relay Forum Frame Relay User-to-Network SVC Implementation Agreement (FRF.4), which specifies the Frame Relay SVC signaling protocols. BPX Service Node Frame Relay UNIs (FRSMs) also support traditional Frame Relay PVCs.

Interim Inter-switch Protocol Routing

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.

PNNI

The Private Network to Network Interface standards essentially define two protocols:

  The Private Network to Network Interface (PNNI) defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology. PNNI topology and routing are based on the well-known link-state routing technique.
  PNNI also defines a second protocol for signaling, that is message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure.

Signaling Plane

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 StrataCom wide-area ATM network.


Figure 11-2: BPX Service Node Network Signaling Plane


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.

UNI Signaling Channel

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.


Figure 11-3:
UNI Signaling Channels


NNI Signaling Channel

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 ATN NICs indicates a logical connection; the physical connection is configured through BPX 1 and BPX 2.


Figure 11-4:
ESP Signaling PVC


Network Interworking Between Frame Relay and ATM

Because the BPX is an ATM switch, Frame Relay SVCs that are setup and established across the Cisco StrataCom 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.)

Extended Services Processor

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.

ESP Interfaces

The ESP uses three main physical interfaces, as shown in Figure 11-5:


Figure 11-5:
ESP Physical Interfaces


The ESP also provides the following application interfaces:

Redundant ESPs

ESPs can be installed in redundant pairs in the BPX Service Node. In a redundant pair, one ESP is active, that is it controls the switched services in the BPX Service Node, and the other ESP is standby. The redundant ESPs are known as peers. The ESPs will switch roles from active to standby and vice versa under the following conditions:


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.

Network Management

As shown in Figure 11-5, the BPX Service Node could have an Ethernet LAN connection to a StrataView Plus Workstation. StrataView Plus discovers and monitors the ESP similarly to the way it does an AXIS interface shelf. StrataView Plus 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 StrataView Plus topology map as a shelf attached to the BPX switch.

StrataView Plus manages the BPX Service Node by providing:

Resource Partitioning

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 AXIS command line interfaces. This partitioning information is retrieved from the BPX by reading its port and trunk tables and from the AXIS 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:

AXIS Feeder Trunk (BXM/BNI) resources to be partitioned are:

AXIS AUSM port resources to be partitioned are:

AXIS FRSM port resources to be partitioned are:


hometocprevnextglossaryfeedbacksearchhelp
Posted: Thu Jan 18 12:55:39 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.