Switch Virtual Circuits (SVCs) will enable customers to dynamically establish, maintain and clear logical connections within the The provider ATM network on an “as needed” basis - similar to making a phone call. These connections are established, maintained and cleared on demand by end users using real-time signalling procedures, similar to dialing a phone. SVCs enable end users of The provider's ATM service to dynamically define their logical connections on an "as needed" basis.
In contrast, permanent virtual connections (PVCs) are those that are set up and torn down via provisioning by The provider’s network administrators. Permanent virtual connections are pre-defined over static routes through the The provider ATM network, manually established and remain established for long periods of time.
Thus, SVCs provide end users the flexibility to instantaneously establish connections when needed, where needed, and at whatever class of service (COS), quality of service (QoS) and information rate required by the end user's applications. SVCs can also simplify an end users implementation of ATM by alleviating the need for end users and/or carriers to pre-define, provision and maintain large numbers of PVCs.
The set of mappings in the ATM network used to route cells from a source to a destination are referred to as virtual paths (VPs) and virtual channels (VCs) within virtual paths. In a PVC environment, these VPs and VCs must be pre-defined and manually provisioned by the The provider ATM network administrators through the The provider ATM network before an end user can transmit traffic.
With SVCs, these connections are established dynamically by the end user through signaling procedures. Essentially, the end user’s Digital Terminating Equipment (DTE) will signal a call set up message to the The provider ATM network switch over a pre-defined signaling channel. This message will identify the destination location (Called Party), the Class of Service and the required bandwidth parameters of the connection. The The provider ATM switch inserts the VPI/VCI assignment for the connection into the signaling message and forwards it to the end user destination. The route for the connection is dynamically selected by the The provider ATM network over the shortest available path. When the end user destination DTE receives the message, it accepts the connection by sending back an acknowledgement message through the ATM network and the connection is established. Once established, the virtual connection will perform in the same manner as a PVC of like COS and bandwidth. To tear down the connection, the end user DTE sends a release message into the The provider ATM network.
In the unlikely event a network failure causes a loss of an established connection, the end user re-establishes the connection by repeating the above call set up routine. The The provider ATM network will automatically re-route the new connection over a new path and around the network failure.
The provider’s ATM SVC offering supports Unspecified Bit Rate (UBR), Constant Bit Rate (CBR) and Variable Bit Rate –non real time (VBR-nrt) connections between customers locations served from the Nortel Vector “edge” switch. Customer locations on the Vector will be able to establish SVC connections with other locations served by the Vector.
Signaling will be based upon the ATM Forum UNI 3.1 specification. The SVCs will be dynamically routed through the NEC “core” network over Virtual Path “tunnels” using the FOREThought PNNI (FT-PNNI) routing protocol available in the Vector. The ATM UNI interface will support a value added feature that allows a customer to use SPVC (Soft Permanent Virtual Circuit or Smart PVCs) information as part of the SVC payload.
UBR, CBR and VBR-nrt SVC’s are available to DS1, DS3 and OC3 ATM customers served off the Vector “edge” switch. Both originating and terminating end points must reside on the Vector platform in order to establish SVC connections between the two.
SVCs are not available to ATM customers served directly from the NEC “core” or Hitachi AMUX switches. ATM customers served from the NEC core platform will need to migrate to the Vector to take advantage of The provider’s SVC offering.
Further, SVCs are not available for connectivity to the Frame Relay/ATM gateway, the IP/ATM gateway or locations not part of the The provider ATM domestic network.
· Increased Flexibility: Customers initiate and manage information transfers dynamically, establishing connections when and where needed at the level of service and bandwidth required.
· Improved Network Efficiency: Customers can instantly tear-down unused network connections, freeing up bandwidth for other applications.
· Instantaneous Disaster Recovery: In the unlikely event of a network failure, customers can re-establish lost connections generally in less than one second. The The provider ATM network will automatically re-route the new connection around the network failure.
· Simplified Network Administration: Customers can alleviate the need to define, install and maintain large numbers of static PVCs, simplifying the administration of their ATM network.
· Cost Savings: The provider’s usage based pricing ensures customers only pay for traffic actually delivered by the ATM network, providing a more cost effective solution than competitor’s flat-rate PVC charges.
With the introduction of SVCs, each customer location must be uniquely identified in the ATM network. This will require each customer location to register an address with the The provider ATM network.
The ATM Forum UNI Version 3.1 Specification defines four forms of network addresses that can be used for SVCs, three private Network Service Access Point (NSAP) addresses and one public Native E.164 address.
The provider ATM SVC service will support the use of any of the three private NSAP formats by customers. Customers are required to provide a Private NSAP address for each location using SVCs. The provider prefers to use customer-provided addresses. If requested, The provider will also provide addresses to customers under certain terms and conditions.
In order to transfer data from one Data Terminating Equipment (DTE) to another, there must be some way of uniquely identifying the destination DTE. Thus, with each DTE, you must be able to associate a unique identifier or address. This address will allow DTEs to perform the routing function properly.
In the OSI environment, this unique address is equated to a network service access point (NSAP). An NSAP uniquely identifies a DTE within the Internet. A DTE may have more than one NSAP, but each is unique to that particular system. It is at the network layer that the end systems involved in a communication must be identified.
The ATM Forum UNI Version 3.1 Specification defines four (4) forms of network addresses: a Public Native E.164 number up to 15 digits in length, or one of the three private 20-octet ATM Endsystem Addresses (AESAs) based on the ISO NSAP (Network Service Access Point) encoding format - International Code Designator (ICD), Data Country Code (DCC), or E.164.
The provider’s ATM Service SVC offering supports customer use of any of the three Private NSAP formats. Public Native E.164 addresses is not currently supported.
The provider will use a static address registration process for recording customer NSAP addresses associated with a UNI port. Customer addresses will be included on the ATM Order and manually provisioned in the network. These addresses will be considered the valid Calling Party addresses for calls originating from the UNI port into the network or the valid Called Party addresses for calls terminating from the network to the UNI Port.
The provider expects customers to obtain and provide their own NSAP addresses for use with The provider ATM SVC service. If necessary, The provider will provide customers use of a The provider NSAP address(es) upon request.
All The provider-provided NSAP Addresses will remain the property of The provider and assigned solely for customer use to address ATM destinations reachable via the customer’s The provider domestic ATM Service.
A series of signaling messages between the switches in the The provider ATM network and the customer’s terminal equipment are used to set up SVCs. In ATM, signaling is similar to that used in all common telecommunications networks (e.g., the telephone network). That is, a connection request from the origination-user is propagated through the network, setting up the connection as it goes, until it reaches the final destination-user. The routing of the connection request—and hence of any subsequent data flow—is governed by the ATM routing protocols. Such protocols route the connection request based upon the destination address, and the traffic and QoS parameters requested by the origination-user.
The ATM Forum's signaling protocol defines the sequence of messages that origination and destination users and the The provider ATM network switches exchange during the call setup process to establish an SVC. Each of the messages that make up the SVC signaling protocol must be transmitted between the source and destination end-stations for a SVC to be established, maintained, and ultimately torn down.
The following criteria must be satisfied and determined by the network and end user:
· Basic service support
· VC availability
· Physical and Virtual resource availability to provide QoS requested
· End system resource availability to provide QoS requested
Since ATM is connection oriented, an SVC connection request needs to be routed from the requesting node through the ATM network and to the destination node. Routing methodologies, executed during the call setup process, are key to meeting QoS and availability requirements of users. This process involves signaling between the switches over a network-to-network interface (NNI). There are two principal routing methodologies used in ATM networks: hop-by-hop routing and source dynamic routing.