A giant step for ATM.

Need a service that delivers application bandwidth on demand, in real time, to any user destination, with custom-tailored performance to meet the needs of almost any application? Such a service exists: public carriers have started to introduce switched virtual connections (SVCs) for ATM.

As the name implies, SVCs enable connectivity on a switched basis. Although they can coexist on the same port with ATM permanent virtual connections (PVCs), SVC connections are made in real time without the need for manual pre-provisioning of the connection.

Any application suited for ATM PVCs is a candidate for ATM SVCs. SVCs are well-suited -- and a key enabler -- for a number of multimedia applications, including data distribution and warehousing, videoconferencing and workgroup collaboration, telemedicine, and distance learning.

SVCs offer customers several key cost and quality benefits. Perhaps the biggest is the ability to make connection bandwidth available for new and existing network applications whenever and wherever it is needed.

With SVCs, users establish connections on a call-by-call basis and each connection request contains the bandwidth and ATM service quality information necessary to support a particular application. When the application completes, the associated connection is released and network resources are available for use by another application.

SVCs also offer scalability to large networks with many ports and a high degree of interconnectivity, or meshiness. For example, to fully connect 20 network sites with PVCs, a total of 190 PVCs is required. With SVCs, connections to and from any of the 20 sites can be set up on demand and the connections are terminated when the calls finish.

Usage-based pricing is another attractive feature of SVCs, particularly for public network providers that carry ATM SVC traffic between private networks or individual end-points. Although PVC customers pay a flat rate, SVC customers pay for what they use. Using both PVCs and SVCs, they can build more optimal enterprise networks.

User adoption and widespread use of switched ATM connections depend on the existence of common signaling protocols between private ATM switches, private and public ATM networks, and between public ATM networks.

The Private Network-Node Interface, or PNNI, defines how private ATM switch networks communicate and interoperate.

The Public User-Network Interface, or Public UNI, defines how a private network or end system communicates with a public ATM network.

Finally, the Broadband Inter-Carrier Interface, or B-ICI, defines how two public networks communicate and interoperate to support end-to-end ATM service.

To establish an ATM SVC connection, an end user or application creates a call setup request. When one source and one destination are required, the connection request is referred to as a point-to-point call. When one source and multiple destinations are required, the connection is a point-to-multipoint call.

In either case, the calling user initiates a setup request message and forwards the request, using ATM Forum UNI signaling procedures, to the network.

The setup request message is the most important component of a call sequence. It includes all of the critical information needed to define and support a connection:

* Addressing information, which includes the destination, or called party, and source, or calling party, location information.

* The ATM Traffic Descriptor, which specifies traffic parameters, including peak cell rate, sustained cell rate, and maximum burst size for both the forward and backward directions of the SVC connection.

* The Broadband Bearer Capability, which specifies the ATM transport service for the connection. UNI 3.1 signaling procedures allow support for Constant Bit Rate (CBR), Variable Bit Rate Non-Real Time (VBR-NRT), and Unspecified Bit Rate (UBR) service.

* The Quality of Service (QoS) indicator, which specifies the cell loss, cell delay, and cell delay variation performance associated with the connection.

Using the information specified in the call setup message, the network routes the call through the public network to the destination, ensuring that the path chosen has sufficient resources to support the traffic descriptor, bearer capability, and QoS parameters.

Once established, the connection is available for use until either the source or destination issues a connection disconnect (release) message.

To initiate and establish an SVC connection for an enterprise network, users also need to understand how to identify and locate one another with an address or numbering plan.

Similarly, a public network needs a numbering plan to determine how to route a call through the network. An ATM address, referred to as an ATM End System Address (AESA), must uniquely identify an ATM endpoint from any other endpoint within a global network.

The ATM Forum devised an addressing scheme that specifies three types of formats to use across public and/or private UNIs. It is flexible, scalable, easy to use, and allows for efficient routing.

However, the Forum's ATM plan is not directly compatible with the traditional E.164 address format used in today's circuit switched networks. The addressing scheme, therefore, requires that either the customer equipment or the network translate between formats or that the public network accept and route calls based on the private network numbering plan.

Once a numbering plan is defined and administered for the network, user equipment can populate the source and destination address fields of the call request message.

The ATM community continues to work on how to best populate the call request message information -- for example, the traffic descriptor, and QoS information for specific user applications such as multimedia.

Many of today's applications are based on connectionless LAN technology that does not recognize or communicate bandwidth or QoS requirements. An easy mechanism for conveying the necessary connection requirements from the LAN to the ATM signaling software does not exist.

As a result, many initial SVC applications will default to UBR service to support SVC connections. With this service, die network transmits ATM cells based on available network bandwidth without a guaranteed throughout or delay.

UBR prevents SVC applications from taking advantage of one of ATM's key benefits: guaranteed quality of service.

As the new UNI 4.0 and Traffic Management 4.0 specifications become widely implemented, the Available Bit Rate (ABR) service (which enables the network to tell the user what bandwidth is available) will allow for a better way to support such traffic.

Security is a potential concern in any public switched network environment. Unlike PVCs, where connections are "nailed-up" by a trusted network manager or administrator, a user can establish an SVC from any end system on the network simply by specifying a calling party address.

Potential security solutions exist, and the ATM Forum is working on a specification to address end-to-end security issues.