|
|
This chapter describes soft permanent virtual circuits (SPVCs) as they are implemented by the Extended Services Processor and WAN Service Node. It contains the following sections:
Soft permanent virtual circuits (SPVCs) are PVCs which are routed using the Private Network to Network Interface (PNNI) routing protocol. The "permanent" qualifier indicates that the virtual connection is established administratively, through an operator's command, rather than on demand by signaling. A soft PVC is one where the establishment within the network is done by signaling (that is, PNNI signaling), just as it is done for ATM and Frame Relay SVCs. Refer to Chapter 4, Soft Permanent Virtual Circuits, for more details on PNNI routing and signaling.
As shown in Figure 5-1, a point-to-point SPVC will have a master (originating) end and slave (terminating) end of the connection. The master end is said to own the connection. The master endpoint is responsible for establishing and releasing the connection. The slave endpoint is created at the terminating node upon receiving the connection indication from the PNNI signaling.
To set up an SPVC, the network operator configures the connection parameters and the calling and called endpoint addresses. The endpoint address consists of an ATM Address and VPI/VCI.When an SPVC connection is routed, the originating node initiates an SVC to the terminating node. The WAN Service Node network will use the PNNI routing database and signaling to route the SPVC. SPVC connections must terminate on both ends on a BPX switch BXM.
For establishing and managing SPVCs, the ESP uses its SPVC Manager, which is distinct from the SVC processing done for ATM and Frame Relay SVCs. The logical interfaces to, and main functions of, the SPVC Manager are shown in Figure 5-2. The SPVC Manager includes the following components:
When a network operator configures an SPVC through the ESP Configuration Interface, the ESP System Manager forwards messages and parameters to the SPVC Manager. The SPVC Manager validates the originating endpoint address, obtains a route from the PNNI Route Agent, and sends a connection request to the Call Processing function. The Call Processing function establishes the connection on the WAN Service Node PNNI network. The route of the connection is saved in the Persistent Endpoint database. The SPVC Manager also informs the CPE of the status of the connection.
The SPVC Managers at via segments (that is, WAN Service Nodes which are not originating or terminating endpoints) do not get involved in any connection management activities.
At the slave endpoint, when the SPVC manager receives a connection request from the Call Processing function, it creates the slave endpoint record and the connection is accepted. The slave endpoint SPVC Manager does not save the path of the connection in its persistent database.
The user can specify a maximum cumulative Administrative Weight (AW) for an SPVC. Then, the SPVC will only use routes whose cumulative AW metric is less than this value. This will allow the user to prevent specific SPVCs from being routed over certain trunks, such as over trans-Atlantic links.
Only the owner (that is, the master endpoint) of an SPVC connection can delete it. When the SPVC Manager receives a request to delete a connection from the ESP Configuration Interface through the System Manager, it verifies the status of a connection, then issues the connection release request to the Call Processing function. The master endpoint is also removed from the SPVC Manager's persistent endpoint database.
Only the master endpoint of an SPVC connection can begin the re-routing of an connection. SPVC connections are re-routed for the following situations:
Once the SPVC connection is released, the master endpoint is added to a routing work list to wait for re-routing. Re-routing of the SPVC uses the dynamic capabilities of the underlying PNNI routing system to find and manage optimal routes.
SPVCs can be groomed to obtain an improved alternate route. The SPVC Manager saves the current route of an SPVC and its accumulated Administrative Weight metric. When an SPVC is groomed the metric for the current route is compared with that of an alternative possible route. If the metric for the alternative route is less than that for the existing route by a certain percentage specified by the user, then the old route is released and the new route is established.
Grooming is invoked manually through the SPVC command line interface, which is described in Appendix J, SPVC Command Line Interface.
In the PNNI network, SPVC connections are established using the best available route. Upon network failure, SPVC connections are re-routed. The newly selected route may not be the optimal path, however. When the network recovers from the failure, the SPVC needs to groomed to optimize the network resources.
The ESP's auto-grooming feature is a background management process that evaluates SPVC connections; if a better path is found, the SPVC connection is released and rerouted to a the optimal path.
Auto-grooming is enabled or disabled through the SPVC Command Line Interface, which is described in Appendix J. The auto-grooming feature allows you to specify the grooming time-frame, the grooming criteria, and/or the range of connections to be groomed. It also allows you to query the status of the auto-grooming process and provides an auto-grooming report.
The calling and called party addresses of an SPVC connection, that is the master and slave endpoint addresses, use the 20-byte ATM NSAP address format (plus the VPI, VCI) to specify an endpoint. This address is similar to the SVC NSAP Address used for ATM SVCs which was described in Chapter 2. As shown in Figure 5-3, the SPVC NSAP address and the SVC NSAP address use the same 13-byte prefix (47 0091 8100 0000, plus the node's 6-byte MAC address). Up to 10 SPVC prefixes can be added and these are advertised by the PNNI protocol.
The final 7-bytes of the address, the ESI (end system identifier), distinguish end systems from one another. The SPVC Identifier field (SPVC Ident in Figure 5-3) is used to distinguish SPVC NSAP addresses from SVC NSAP addresses. The SPVC Identifier ensures that the SPVC ESI will not match the ESI of an SVC address. ATM CPE addresses, registered with the WAN Service Node through ILMI, contain MAC addresses as part of their ESI. The MAC address consists of a 3-byte IEEE Organizational Unique Identifier (OUI) and a 3-byte user part. The 3-byte OUI is assigned by IEEE to provide a universally unique MAC address to identify LAN stations per ANSI/IEEE standard 802. The SPVC Identifier may be configured by the user and has a default value of FFFF hexadecimal. The IEEE does not assign the value FFFFxx hex to the OUI. If the OUI in the ESI field of an ILMI-registered SVC address has the value FFFFxx hex on a particular node, the user may select another SPVC Identifier value to construct SPVC addresses on that node
The 4-byte Logical Port Identifier field of the SPVC NSAP address consists of three fields:
In accordance with the ATM Forum Traffic Management Specification 4.0, the ESP supports the following service categories:
In accordance with the ATM Forum Traffic Management specification 4.0 and ATM Forum UNI Signaling Specification 4.0, the ESP supports the user-settable parameters listed in Table 5-1 for each Service Category and Traffic Set. An x in one of the columns indicates that parameter is user-settable for that Service Category.
| Service Category | CBR | VBR | VBR | VBR | UBR | UBR | ABR |
|---|---|---|---|---|---|---|---|
| Traffic Set | CBR.1 | VBR.1 | VBR.2 | VBR.3 | UBR.1 | UBR.2 | ABR |
| ATM Forum Specification | 3.x 4.0 | 3.x 4.0 | 3.x 4.0 | 3.x 4.0 | 3.x 4.0 | 4.0 | 4.0 |
| Parameter | |||||||
| PCR (0+1) | x | x | x | x | x | x | x |
| SCR (0+1) | x | ||||||
| SCR (0) | x | x | |||||
| MBS (0+1) | x | ||||||
| MBS (0) | x | x | |||||
| Tagging | x | x | |||||
| Best Effort | x | x | |||||
| Frame Discard | x | x | x | x | x | x | x |
| CDVT | x | x | x | x | x | x | x |
| MCR | x | ||||||
| ABR parameters | x | ||||||
| ATM Transfer Capability (ATC) | 7 | 19 - rtVBR 11 - | 9 - rtVBR
10 - nrtVBR | 9 -rtVBR
10 - nrtVBR | 10 | 10 | 12 |
| ILMI Traffic Descriptor Type | NoClpNoScr | NoClpScr | ClpNoTaggingScr | ClpTaggingScr | NoClpNoScr | NoClpNoScr | ClpNoTagingMcr |
| ILMI Best Effort Indicator | false | false | false | false | true | true | false |
There is more information about user-settable SPVC parameters in Chapter 8, Understanding the ESP Configuration Interface.
Table 5-2 lists the various ways the system (that is, ESP and the WAN Service Node network) handle the types of failures that can affect SPVC operation. The table lists the failure, then describes the systems reaction to that failure.
| Failure | Description |
|---|---|
| Local Port Failure | When there is a failure at the port of a master (that is, persistent) endpoint of a connection, the ESP System Manager is informed by the BPX switch. The System Manager forwards the information to the SPVC Manager, which ensures that:
All SPVC connections at the failed port are released with the cause "Endpoint out of order"; All slave endpoints of the released connections are released; (subsequent retries from the remote master segment are rejected with the cause "Endpoint out of order" until the local port failure is cleared). There is no SPVC re-routing while the local port failure persists. |
| Network Failure (Single Domain) | For network failures, all affected SPVC connections are released and automatically re-covered using the underlying PNNI resilient routing. |
| BCC Switchover | When the BPX switch's BCCs switchover, all channels on the NNI or UNI ports get re-routed.
Any ESP channel programming requests in progress during the switchover are lost. No re-routing for any "active" SPVC connections; either its in the owner, via, or last segment. |
| ESP Crash | If the ESP processor fails (and comes back up), and there is no standby (redundant ESP), the ESP will rebuild its database. |
| PNNI Trunk Failure (with no redundancy) | All connections using the failed trunk will be rebuilt.
SPVC connections are re-routed by the SPVC Manager at the master endpoint. |
| Maintenance Down Card Command. | All connections using the downed card will be rebuilt.
SPVC connections are re-routed by the SPVC Manager at the master endpoint. |
| ESP NIC/Driver Failure | ESP will switchover as part of normal redundancy control. |
| PNNI Signaling Stack Failure at remote WAN Service Node | All connections using the failed WAN Service Node will be rebuilt.
SPVC connections are re-routed by the SPVC Manager at the master endpoint. |
| PNNI Signaling Stack Restart | All SPVCs are released and automatically re-established. |
The master endpoint of the SPVC connection is responsible for the re-establishment of an SPVC connection. When the SPVC is released due to ESP or PNNI network failure, the re-routing will use a SPVC slow timer to pace the retry frequency. In this release, the retry parameters are per SPVC, and there is no upper limit on the number of retries.
The ESP lets the user know about the status of SPVC connections through asynchronous events. These event notices let the user know when:
The WAN Service Node maintains statistics for SPVCs which can be accessed through the ESP Configuration Interface. The SPVC statistics include cell counts sent to-and-from the port and the BPX switch backplane, queue depths, performance monitoring counts, and OAM status. The statistic values are updated once per second.
ATM PVCs that are terminated at both ends on BXM cards can be migrated to SPVCs. The migration process will convert an ATM PVC into an ATM SPVC with the same endpoint VPI and VCIs.
This PVC migration can be performed with a Migration Utility, which runs on the StrataView Plus workstation, and is described in Appendix J, SPVC Command Line Interface.
When a PVC is upgraded (that is, migrated) to an SPVC, its endpoint identifier must be maintained, that is, its VPI/VCI are maintained. (If this is not done the CPE must be reprovisioned with new VPI/VCI values.)
The first release of the Extended Services Processor supported only static resource partitioning. With static resource partitioning, VPI, LCN and bandwidth resources were partitioned into 2 regions: one for SVCs, the other for PVCs. PVCs were controlled by the WAN Service Node's BCC; SVCs were controlled by the ESP. With static resource partitioning, all connections on the port (PVCs or SVCs) must be deleted from a port before the partitioning can be changed. Dynamic resource partitioning allows the partition to be changed without deleting existing connections.
Figure 5-4 illustrates how dynamic partitioning works. To upgrade a PVC to an SPVC the VPI partition is changed to include that PVC endpoint VPI value p.q. When this is done, no new PVCs may be added into this extended SPVC region. The ESP is notified about the existing PVCs in this extended region; the ESP can add SPVCs in this region. As PVCs in the extended SPVC region are removed, the ESP is informed so that it can re-use those identifier (VPI, VCI) values.
When a PVC is migrated to an SPVC, the following things must occur:
1 ) The user must identify the PVCs that are to be migrated and select the new VPI range that will include the VPIs of these PVCs.
2 ) The user changes the VPI partition on the BXM card using the cnfport command.
3 ) The user changes the number of SVC channels, bandwidth, and queue sizes on the line and trunk cards through which the SPVCs are to be routed.
4 ) From the StrataView Plus workstation, the user will execute a script that will delete PVCs using the BPX switch CLI and add SPVCs with the same VPI, VCI using the ESP Configuration Interface. The StrataView Plus migration script communicates with the BPX switch CLI and ESP Configuration Interface using telnet sessions.
In ESP Release 2.2, SPVCs can be routed through foreign private networks when the two networks (or domains) are connected through an IISP trunk. The IISP trunk support is based on ATM Forum UNI 3.1.
SPVC connections to a foreign private network do not support ATM Forum UNI 3.0, Available Bit Rate (ABR) or Virtual Path connections.
Figure 5-5 provides a simple illustration of this feature.
The IISP trunk to the foreign private network has to be explicitly configured to support SPVCs. This is done through the ESP Configuration Interface with the Add NNI menu described in Chapter 8.
The traffic types supported for SPVCs across the IISP trunk to a foreign private network are UBR, CBR, VBR-nonRT, and VBR-RT. ABR traffic type is not supported.
Since VBR-RT is not supported in the Broadband Bearer Capability information element of IISP 1.0, the ESP uses a proprietary implementation of VBR-RT. This proprietary implementation sets the VBR-RT Broadband Bearer Capability information element as follows:
The network-side of an IISP trunk always assigns the VPI/VCI for the connection, and the user-side extracts VPI/VCI from the SETUP message and tries to assign it. When the call is originated from the network-side, it specifies the VPI/VCI in the SETUP message of the SPVC connection. If the VPI/VCI is not available on the user-side, the user-side will send a RELEASE COMPLETE message back to the originating side. When the call is originated from the user-side of the IISP trunk, the user side sends out a SETUP message which does not specify a VPI/VCI for the connection. The network-side will respond with a CONNECT message containing the selected VPI/VCI for the connection. If the VPI/VCI is not available on the user-side, the user side will send out a RELEASE message and the network side will respond with a RELEASE COMPLETE message.
The IISP protocols support any of the NSAP-encoded Private Network Address formats as specified in Section 5.1.2.1 of the ATM Forum UNI 3.1 specification. Addressing considerations for a public UNI are described in Annex A of the UNI specification.
To provision an IISP that will be carry SPVC connections over a private foreign network, you must assign the port a prefix based on the prefix of the terminating end of the SPVC connection. As shown in Figure 5-6, the port on the WAN Service Node PNNI network, which is connected to the foreign private network over an IISP trunk, must be provisioned with the prefix of far-end port (slave endpoint).
In this illustration, when setting up an SPVC connection between UNI 1 and UNI 2 (with UNI 1 being the master endpoint), the call is routed to the IISP port of the WAN Service Node PNNI network since it has the same prefix as the UNI 2. The SETUP message is then sent across the IISP trunk to the foreign private network.
The ESP converts the Call Control messages between PNNI 1.0 and IISP 1.0 (based on UNI 3.1) as necessary.
The WAN Service Node supports soft permanent virtual circuits in accordance with:
|
|