Cell relay service

From Hill2dot0
(Redirected from CRS)
Jump to: navigation, search

By far the simplest and easiest ATM service is cell relay service (CRS). With CRS, a service provider relays a customer’s cells through the network without regard to cell content or connection characteristics. The only agreement between service provider and user boils down to “you give me a cell, and I’ll get it there.” Thus, CRS essentially extends the basic transport carrier concept to ATM. In a basic transport service, the carrier does not look at, modify, or even store the user’s bits in any shape, manner, or form. This applies to CRS, too.

Not surprisingly, most carriers’ initial ATM service offering is some form of CRS. The complexity of such a network is in the endpoint device, not in the carrier network. Most CRS is tariffed (or contracted) on a distance-insensitive, flat, monthly charge. There are many exceptions, of course. Some carriers charge by the kilocells input at the source site (not all of which are delivered), but CRS is almost universally distance insensitive. Most CRS providers give it a catchy name, but it remains CRS nonetheless.

With CRS, the network neither supports nor provides the ATM Adaption Layer (AAL), which is reasonable, since the AAL is needed only at the endpoints. The problem is that the AAL that supports CRS is beyond the service provider’s control. (The presence of AAL on the endpoints does not mean that the AAL is not part of the basic ATM architecture, however.)

With CRS, the user endpoint equipment controls and even defines the service delivered over the ATM network. The service provider might have a hard time proving that a complaint of inadequate service is really the fault of incompatible or underpowered AALs at the endpoints, not the service provider’s ATM network.

In fact, an ATM network supporting only CRS is not really “ATM service” at all. The ATM architecture extends to the AAL Layer. Excluding the AAL Layer from the service provider’s offering is a bit like GM or Ford selling you a car engine and frame, but making you install the ignition system, build the body, and paint it. Although the result would be considered a Chevy or a Ford, you couldn’t find the door handle!

Using CRS to Link LANs

Using CRS to Link LANs

A CRS limitation is the lack of service provider control over what the endpoints are trying to accomplish with ATM. One way to attack the problem is to limit, define, or merely understand, exactly what the CPE on a CRS might be.

In fact, it is possible to extend CRS into another “flavor” of service offering: LAN interconnection with CRS, where the service provider’s ATM network replaces the customer’s private-line network between routers (or even bridges). In most cases, the service provider installs and maintains the CPE. Several vendors offer equipment that serves this purpose admirably. Usually, the CPE is nothing more than a small ATM switch (usually called an “edge switch”) with a few Ethernet or even token ring LAN ports and an ATM WAN port that complies with some physical interface for the ATM UNI specification. The ATM network provides unprecedented speeds compared to most affordable private-line solutions, making this service quite attractive to customers.

This LAN interconnection service does not enhance the underlying CRS service in any way. The customer’s routers still route, and the bridges still bridge. These devices are not really part of the ATM network at all, which is considered both the strength and weakness of this kind of CRS. The ATM network forms a conduit between sites, albeit a very fast one. The ATM edge switches provide a source and sink for the ATM cells, but do little else in this type of CRS.

Several ATM service providers have profited for years with this scenario. Some market the underlying ATM connectivity in terms of “fractional Ethernet speeds.” That is, ATM connections between sites are available at 2.5 Mbps, 5 Mbps, and so on. This is a brilliant marketing plan, since LAN users are much more comfortable with LAN terms than WAN terms, even when speeds alone are involved. Pricing is usually on a flat, monthly rate, again based on the premise that the customer is replacing a number of point-to-point private lines.

The ATM network has no control over when and where the routers will send data or the amount of traffic presented to the network per unit of time. Usually the ATM network has reserved adequate buffering and bandwidth to handle the peak fractional Ethernet rate (e.g., 5 Mbps) day or night. This might seem wasteful of ATM network resources, and in the long run, it is, but it works right now.