Distributed traffic scheduler

Details Distributed traffic scheduler Distributed traffic scheduler

2000-10-27

2004-12-21

Patel, Ajit (Department: 2664)

Multiplex communications

Pathfinding or routing

Switching a message which includes an address header

Reexamination Certificate

active

06834053

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to traffic scheduling and congestion monitoring in an ATM network.
BACKGROUND OF THE INVENTION
The services that are carried in today's telecommunications network can be categorised into two main types; real time and non-real time services. The typical examples of these two types are respectively voice telephony and computer data. The two services have very different characteristics and requirements and therefore have traditionally been carried over disjoint network technologies. However to increase flexibility and to decrease costs, there is a major drive by PTTs and network operators to integrate real-time and non-real time services within one homogeneous network. The asynchronous transfer mode (ATM) has been specifically designed to enable this common transport.
A key component of ATM is the adaptation function. This provides the mechanism that adapts the carried service to and from the ATM domain. Several adaptation layers have so far been defined to accommodate the various traffic types that may be transported. For example, ATM Adaptation Layer 1 (AAL1) is designed to adapt constant bit rate services (predominately voice or video) into fixed length ATM cells. A feature of AAL1 is that it enables the timing relationship between the transmitter and receiver to be maintained over the asynchronous network. In contrast, ATM Adaptation Layer 5 (AAL5) has been designed predominantly to support data services. As such it provides a mechanism to segment long data packets into fixed length ATM cells and also provides a mechanism to enable the integrity of the reassembled data packet to be validated after transmission across the network. AAL5 is also being used in certain applications to carry voice services (particularly in computer desktop applications) where AAL5 technology is readily available.
Both AAL1 and AAL5 adapt the carried service into a stream of fixed length ATM cell payloads. However for certain compressed voice services, the length of the standard ATM cell payload (48 bytes) is too large and its use would lead to a large packetisation delay that in turn would affect existing network delay budgets and provide acceptable voice characteristics. To resolve this problem ATM Adaptation :Layer 2 (AAL2) has been defined. AAL2 supports a multiplex of user channels within a single virtual channel connection (VCC). Each user channel is carried in a stream of mini-packets. The length of the mini-packet payload for each channel can be defined according to the packetisation delay that can be tolerated. AAL2 differs from AAL1 and AAL5 in two ways. Firstly it enables a single VCC to support multiple diverse services (a number of simultaneous voice, video and data channels can be multiplexed together to reduce packetisation delay), and secondly it introduces a new switching layer above the ATM layer (i.e. the function of switching a mini-packet connection from one AAL2 VCC to another AAL2 VCC).
To support the full range of telecommunication services operators need to provide these three adaptation layers in an efficient manner. There also needs to be a mechanism to enable the interworking between services carried over different adaptation layers (for example to enable a PSTN user carried via AAL1 to communicate with a desktop voice user hose computer only supports AAL5). To increase flexibility further and to scale networks there is also a requirement to support AAL2 switching. This has introduced problems with the design and efficient operation of ATM schedulers. The purpose of a scheduler is to despatch ATM cells into the network at a controlled rate which minimises congestion and maximises the efficient use of the network resources. The need to handle numerous queues of different traffic classes supported on different ATM adaptation layers has made scheduling a complex and difficult operation.
By way of background, there follows an outline summary of the main ATM traffic classes currently in use.
ATM Traffic Classes
To accommodate the differing behaviours and QoS requirements for a variety of traffic sources, a set of traffic classes is defined in ATM. Each traffic class is designed to describe the characteristics and requirements of a particular type of voice or data service. Five traffic classes have been defined by the ATM Forum [ATMF TM4]-CBR, rt-VBR, nrt-VBR, ABR and UBR.
CBR
The CBR (constant bit rate) traffic class has been designed to support periodic traffic sources that have real-time requirements (i.e. they are delay sensitive). The traffic contract for a CBR connection is entirely specified by its Peak Cell Rate (PCR). The PCR specifies the peak emission rate of ATM cells (and thus implicitly the period between successive cells). All cells within the connection should conform to the PCR. Although the connection is described as CBR, it is perfectly admissible to transmit cells at lower than the PCR, or even to halt emission entirely.
Since the class is real-time, the ATM network commits to delivering cells within a specified delay and jitter bound (CTD and CDV).
rt-VBR
The real-time VBR (variable bit rate) class has been defined to support variable rate real time services (such as certain video streams). A rt-VBR connection is specified in terms of its Sustained Cell Rate (SCR), its Maximum Burst Size (MBS) and its PCR. The SCR defines the mean rate of the connection, the PCR defines the peak rate of any burst and the MBS defines the relationship between the two. Again, as this is a real time connection, the ATM network commits to delivering the service to specified delay and jitter bounds.
nrt-VBR
Specified in an equivalent manner to rt-VBR (PCR, SCR and MBS) this class is provided for the non real-time delivery of delay insensitive variable rate services. There is no delay or jitter commitment made by the ATM network for the delivery of this service.
ABR
In ABR (available bit rate) the source varies its bandwidth usage in accordance to current network congestion which is signalled either implicitly or explicitly through the use of Resource Management (RM) cells.
The key parameters of an ABR connection include:
PCR—peak cell rate
MCR—minimum cell rate (can be zero)
ICR—initial cell rate (start-up rate)
ACR—actual cell rate
CDF—Cell Decrease Factor
CIF—Cell Increase Factor
CRM—missing RM cell count
The connection source transmits two types of cells: data cells and RM cells. The RM cells are transmitted to the receiver where they are looped back to the transmitter. In either direction, each node within the connection can signal its congestion state by inserting information into the RM cell (additionally each intermediate node in the connection can also generate its own RM cells).
The source monitors for the return of the RM cell and changes its connection rate according to the congestion indications contained within it (congestion can be either implicitly or explicitly defined). The RM cells can be sent either as part of the current, contracted rate (set by the ACR—in which case CLP=0) or additionally out-of-rate RM cells can also be sent (CLP=1) at a default rate no greater than 10 per second.
The source uses the following procedure to dictate its behaviour:
On start-up set the ACR to ICR (default PCR)
The first cell sent is always a Forward_RM (which includes an indication of the ACR) at each cell transmission interval send either a:
forward_RM (i.e a RM initiated by the source) if no forward_RM cells have been sent either within a pre-determined time limit (default 100 ms) or a pre-determined number of cell events (default 32 cells)
or send a backward_RM (i.e a RM initiated at the far-end that is being ‘turned around’ by the source) if there is a backward_RM waiting to be sent AND a backward_RM has-not been sent since the last forward_RM was sent OR there is no data cell waiting
or else send a data cell (if one exists)
prior to sending the forward_RM the new ACR rate is computed:
if no forward_RM has been sent since a specified time (the ACR Decrease Time Factor (ADTF)−default value 0.5 s

Affiliated with

Also associated with

Rating

Distributed traffic scheduler does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Distributed traffic scheduler, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Distributed traffic scheduler will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3337984