| ★ wanayoo — archive 1999 http://data.com/Tutorials/Juggling_ATM_Traffic.html | Nouvelle recherche | Portail wanayoo |
|
|
|
 Browse By... Technology/Topic Vendor Back Issues Content LAB TEST CENTER TECH TUTORIALS GLOBAL NETWORKS N.P.N. PRODUCT LEADERS OPINIONS/COLUMN Viewpoint INDUSTRY PIPE Visitor's Center FAQs Contact the Editors Free Newsletter Subscriptions Marketing Services Industry Front & Center Reader Service Custom Publishing Real World Seminars Vendor Strategies 
|
|
|
|
Figure 1: Tracking ATM TrafficConstant bit-rate (CBR) traffic is guaranteed a fixed amount of bandwidth. Bandwidth is also guaranteed for variable bit-rate (VBR) traffic, although in this case the amount varies. Whatever bandwidth remains is dedicated to available bit-rate (ABR) traffic--with no guarantees. 
|
The second of those categories is variable bit rate (VBR) service, designed for applications whose information transfer is bursty. There are two key concepts here: sustainable cell rate and maximum burst size. The former is the connection's maximum average throughput; the latter, the maximum number of cells that can be transmitted at the peak cell rate during a burst. The basic idea is that bursts--transmissions at rates higher than the sustainab le cell rate--can occur but must be offset by periods of lower transmission so that the average cell rate remains no higher than the sustainable cell rate.
VBR comes in two flavors: Real-time VBR service has been defined by the ATM Forum's UNI (user to network interface) 3.1, and nonreal-time VBR service by the forum's version 4.0 traffic management draft spec. The real-time VBR service can be a good way of carrying delay-sensitive traffic while using less bandwidth than CBR services require; for example, voice applications that use compression and silence suppression run well over real-time VBR service. Nonreal-time VBR service doesn't provide delay guarantees; applications that would run well over it include airline reservations, banking transactions, and process monitoring.
Traffic that requires no service guarantees can use unspecified bit rate (UBR) service to take advantage of "background" bandwidth. This would be fine for applications that generate background images (such as news and we ather pictures), file transfers, and e-mail. UBR service is a good way of handling applications that have built-in retransmission schemes so that they can tolerate cell loss. Although the ATM Forum's Traffic Management Working Group has defined some aspects of UBR, traffic management is left up to switch vendors. The performance of applications that use UBR service can be improved significantly by switch vendors who implement packet-level discard functions.
The fourth service category--available bit rate (ABR)--has generated a good deal of interest. The idea is to have flow-control mechanisms to allocate background bandwidth fairly among applications that don't have rigorous cell-transfer delay tolerances but do have low cell-loss requirements.
ABR is the service that's most likely to be used for LAN interconnect and other internetworking applications. The ATM Forum Traffic Management Working Group is currently in the final stages of hammering out some specifications for it.
For all kinds of service, ATM networks should be designed to maximize the utilization of resources while meeting users' performance expectations; in a nutshell, this is the role of traffic management. The basic idea behind traffic management is that users should be able to tell the network what service they require for a connection. Conversely, the network must be able to monitor and control traffic according to agreements with users.
To do all these things, the first requirement is a service contract. At bottom, this is an agreement between the user (or the user's application) and the network about the quality of service and traffic characteristics generated by the user and supported by the network. For permanent virtual circuits (PVCs), the network vendor's network management system tells the switches to establish the PVC according to a predefined service contract. For switched virtual circuits (SVCs), user applications make service requests through their ATM UNI directly to the ne twork as defined in the SVC parts of the ATM Forum's UNI specs.
Once the SVC request has been made, the network must determine if the connection request can be accepted, a process that involves signaling between the switches over a network-to-network interface (NNI). Standard signaling mechanisms are defined by a number of specifications, including the broadband intercarrier interconnect (B-ICI), the interim interswitch signaling protocol (ISSP), and the private-NNI (PNNI) , interface currently under development by the ATM Forum.
The switches also need some mechanism for connection admission control, the process of deciding whether to accept or reject the connection. At present, these computations are specific to each switch vendor's implementation. But in general, connection admission control decisions are made on the basis of whether bandwidth, virtual channel identifier (VCI) values, and all links needed to establish a route to the destination are available.
The availability of swi tch resources like buffers also is a factor. There are also parameters specific to particular service categories, such as the projected cell-transmission delay or cell-delay variation. Existing connections should not be affected as a condition for accepting the new connection.
Routing methodologies, executed during the connection admission control process, are essential to meeting users' service and traffic requirements. ATM networks use either of two routing methodologies: hop-by-hop or source routing. Hop-by-hop routing, used in the ISSP, requires each switch to make a routing decision for a received connection request.
If the source and destination users are attached to the same switch, no further routing decisions must be made; otherwise, the source switch has to choose an exit link for the destination address specified in the connection request. One way to do this is to use next-hop static routing tables containing next-hop entries that define the shortest loop-free routes to the destinat ion. The switch can exploit this information (along with output parameters from its connection admission control algorithms) to select primary and backup routes.
Once the routing decision has been made, the switch sends this information over the signaling interface to the next network switch on the selected route. This process is repeated until the destination switch has been reached.
Source routing requires source switches to have access to network topology status in order to suggest the best routes to a destination. Topology status is maintained in a topology database and kept current via periodic broadcasts by each network node to its adjacent switches.
When a source switch receives a connection request, it uses the topology database to estimate the best routes to the destination. Once the originating switch verifies its ability to accommodate the computed route, it updates the appropriate tables for the connection and
sends the connection request to the next switch on the selected route. Each switch along the way executes its connection admission control mechanism, updates its status tables, and forwards the connection request until the destination switch has been reached.
Because topology databases are updated periodically and update messages are not instantaneous, they don't reflect the network's status immediately; therefore, the route chosen through source routing could be invalid by the time a connection request got to a specific network node, aborting the connection request. To keep the connection request active, the ATM Forum's PNNI committee is considering a capability called "crankback." Under it, a switch that can't accommodate the connection request notifies the previous switch on the route, and the switch then sends the connection request over an alternative route.
The end result is the establishment of a connection between source and destination. But traffic management doesn't stop there. Traffic shaping schemes are defined t o monitor (and possibly modify) cell streams on a connection. Policing schemes merely monitor.
The most universal class of traffic algorithms used for traffic shaping and traffic policing is the so-called leaky bucket, called for by ATM Forum specifications. (The forum actually calls this the generic cell-rate algorithm.) The name "leaky bucket" is derived by way of analogy to a bucket that is filled by irregular spurts of water but lets a steady stream of water drain from a hole in the bottom.
Traffic shaping is a way to convert the user's data stream to a stream conforming to the service contract. If a user's source traffic doesn't conform to the terms of the traffic contract made with the network, traffic shaping can be used to bring it into conformance.
For example, real-time VBR traffic whose peak rate bursts are higher than the contracted peak cell rate can be modified to extend the duration of the burst by spreading the cells over time. (This can be done if it doesn't violate bu rst tolerance and other parameters associated with the original contract.) Modifications of this sort help networks maximize the amount of traffic they can handle. Usage parameter control is the formal ATM term used for policing, which protects network resources from malicious or unintentional behavior by monitoring connection traffic for conformance to the service contract.
Traffic monitoring and control are important, but ATM networks also need ways to avoid congestion and to control the flow of traffic through a network. How this is accomplished depends in part on the service category.
CBR and VBR services were designed to avoid network congestion conditions when implemented with robust connection admission controls and usage parameter controls. With these types of traffic, the network knows exactly what it is being asked to carry; the big question is whether it can accommodate a request. If the analysis is performed correctly, the net should be able to avoid congestion for CBR and VBR traffic.
But congestion control may become a problem when UBR traffic is assigned to spare bandwidth. The best approach for avoiding congestion on UBR connections in networks that don't support packet-level discard is to overcommit such switch resources as cell buffers and to have conservative discard thresholds in the buffer pools.
But UBR service is being supplanted by ABR service as the preferred way of using excess network capacity. The ATM Forum is defining flow-control protocols for handling congestion on ABR connections. Such rate-based flow control is basically a closed-loop feedback system in which the traffic source and destination use congestion state information provided by the network to alter ingress traffic so as to match available network resources and thus minimize cell loss.
There are four options for rate-based flow control. All rely on specialized resource monitor cells that convey information about the state of the conne ction and generally provide a control loop. The simplest rate-based mechanism is called explicit forward congestion indication (EFCI) marking. This is an end-to-end scheme, so there are no intermediate flow-control points on the connection between the end-stations. Here, the network signals congestion--or impending congestion--to a destination station using the EFCI bit in the header of the connection's data cells. The destination station then goes ahead and stores the latest EFCI state.
In addition, the resource monitor cells travel in the forward direction--from the source to the destination, the same direction as the data flow. When a resource monitor cell arrives at the destination, the destination sets the resource monitor cell direction indicator to backward, reflects the latest EFCI state in the congestion-indication bit, and returns the resource monitor cell to the source station. This permits the source to use the information it obtains from the resource monitor cells to adjust its cell-trans mission rate. Many ATM products on the market today support EFCI marking.
Another end-to-end option for flow control in ABR services is relative rate marking. Under this scheme, a switch can set the congestion-indication bit or the no-increase bit in a forward or backward resource monitor cell; however, the switch may not change one of these bits from on to off. When a source receives the congestion-indication bit on in a backward resource monitor cell, the source decreases the maximum allowed cell-transmission rate. The no-increase bit, set by a switch that senses impending congestion, prevents the source from increasing its allowed cell rate.
Explicit rate marking, a third and more effective end-to-end option, uses another resource monitor field: the explicit rate field. Initially, the source station sets its maximum cell-transmission rate, the explicit rate, to an initial cell-rate value negotiated with the network at connection setup. (Typically, the end-station requests that the initial c ell rate be the peak cell rate.)
Such network elements as queuing points within the switches may reduce the explicit rate in forward or backward resource monitor cells to match available resources. When the source station receives the adjusted explicit rate in a backward resource monitor cell, it must reduce its maximum cell-transmission rate to the explicit rate or minimum cell rate--whichever is higher. Explicit rate marking is the next option that will be implemented by many ATM product vendors.
ABR flow control can be made even more effective by breaking the control loop into two or more segments, an option called virtual source/virtual destination control (see Figure 2). In this approach, the source and destination end-stations continue to work as described earlier, but intermediate control points--virtual source and virtual destination points--are added to the network.
Figure 2: Virtual Control for Real CongestionVirtual source/virtual destination control keeps tabs on congestion on every hop. Intermediate network nodes act as virtual sources and destinations, sending back congestion information via RM (resource monitor) cells. 
|
Virtual sources and destinations function in the same way that end sources and destinations do: A backward resource monitor cell received at a virtual source is processed only by that virtual source and isn't propagated backward. In addition, there is a special provision for uniquely identifying virtual path connection resource monitor cells so that they are not confused with resource monitor cells of virtual channel connections of the virtual path.
These schemes represent the state of the art in traffic management and congestion control specifications. Still, network managers also might want t o pay attention to some areas that haven't been specified by the forum and standards organizations, since those areas can affect how well an ATM network performs when congested.
For example, one thing to look at is how switches provide buffering and priority queuing to supply the appropriate service for different traffic types. Another area of interest is the way switches manage individual virtual path and virtual channel cell flows. Finally, the way a switch discards cells that constitute a particular packet (packet-level discard) must be taken into account. This is particularly useful for providing a significant performance improvement for UBR service.
As for buffering, a fundamental design choice is whether to place buffers at the ingress or egress side of the switching fabric, or both. The problem with buffering at the input is potential vulnerability to head-of-line blocking; that is, when an output link for head-of-line cells gets blocked, the remaining cells als o are blocked from traversing the switch fabric, even if they're destined for other unblocked links. To avoid this problem, many switches undertake buffering and queuing at the output port side of the switching fabric.
The next thing to look at is the priority and queuing strategy. Some switches provide configurable options for priority and queuing; others hardwire a particular type of priority and queuing into the switch. One approach would be to have a five-priority system, with one priority for each service category and a separate queue for traffic of a given priority. CBR traffic would receive the highest priority, followed by real-time VBR rate, nonreal-time VBR, ABR, and finally UBR. Cell-delay variations would be smallest to largest for highest to lowest priorities, respectively.
By using a four-priority system that shares buffer space at the lowest priority between ABR and UBR traffic but always services ABR first, vendors can satisfy network managers who want to discourage UBR traffi c. The scheme would also purge UBR to make room for ABR traffic when buffer depletion threatens.
Similarly, net managers could implement a three-priority system, with CBR and real-time VBR sharing the highest priority, followed by nonreal-time VBR, and then ABR and UBR.
Net managers also might want to consider how a switch services traffic within a given priority, though this generally isn't a user-configurable option. For example, how does a switch ensure that connections within a given priority end up receiving their fair share of bandwidth?
Finally, it makes sense to look at how switches discard the cells comprising a packet; in networks that carry a lot of packet data, the way this function is handled can have a big effect on overall performance--particularly that of UBR traffic.
Many data applications use UBR service, and more and more vendors are offering ABR service. Both of these use ATM adaptation layer 5 (AAL5) protocols.
As the name implies, an AAL is meant to permit specific types of traffic to be transmitted and received among end-systems by adapting the user traffic to the ATM layer. AAL5, which is the the standard for systems that require connection-oriented service for sending and receiving variable-length packets, is commonly used for data applications, including interconnect schemes like LAN emulation and TCP/IP over ATM.
AAL5 protocol data units typically are packets that require multiple ATM cells to transport them across the network. If the network discards one cell of an AAL5 packet while letting the others flow through, the network's performance declines because the entire packet must be retransmitted. To minimize this problem, some switches implement a capability called packet-level discard, which comes in two flavors: early packet discard (for the best performance improvement) and partial packet discard.
By defining a buffer threshold that warns of impending buffer depletion, the switch can implement early packet discard. Here pack ets are discarded in their entirety before entering the buffer pool, making it more likely that a packet with some cells already occupying buffers will have enough space for the rest of its cells. Only the packet with discarded cells must be retransmitted by its higher-level protocol, reducing the number of connections affected by the congestion and thus reducing congestion overall.
If severe congestion occurs and a buffer pool becomes depleted, partial packet discard can minimize the number of connections that experience cell loss. In this case, the remaining cells of an AAL5 packet that has partially entered the depleted buffer space can be discarded as they arrive, even when buffers become available again. This limits the number of connections affected by the congestion, in turn reducing the number of AAL5 packet retransmissions and improving the network's overall efficiency.
[ Home ]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|||||||||||
|
|||||||||||
|
 |
|
|
