ATM packet scheduler

Details ATM packet scheduler ATM packet scheduler

1999-12-28

2003-11-25

Kizou, Hassan (Department: 2662)

Multiplex communications

Pathfinding or routing

Switching a message which includes an address header

Reexamination Certificate

active

06654376

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to arrangement and method of adapting voice and data traffic into 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 key 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 Post Telephone and Telegraph Administrations (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.
A 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. 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 key feature of AAL1 is that it enables the timing relationship between the transmitter and receiver to be maintained over the asynchronous network. In contrast, AAL5 has been predominantly designed to support data services. As such it provides a mechanism to segment long data packets into fixed length ATM cells and 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 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 acceptable voice characteristics. To resolve this problem 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 key 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).
AAL2 has introduced a number of new issues to ATM scheduling and congestion control. These arise primarily from the characteristics of the traffic sources that AAL2 has been designed to support.
Traffic Classes Overview
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 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]—Constant Bit Rate (CBR), Real Time Variable Bit Rate (rt-VBR), Non real time Variable Bit Rate (nrt-VBR), Available Bit Rate (ABR) and Undefined Bit Rate (UBR).
However by its nature only the CBR and rt-VBR classes are appropriate for AAL2.
CBR
The CBR 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 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.
Policing of Connections
Once a connection has been established the ATM network commits to delivering it within the pre-specified QoS bounds providing the connection adheres to its traffic contract. The connection will be policed by the network at certain key interface points (typically the UNI and any inter-operator NNIs)—any cells that do not comply with the contract can be either discarded or tagged.
The Generic Cell Rate Algorithm (GCRA) (commonly known as a leaky bucket algorithm) has been defined to perform the policing function in ATM. The GCRA is generically specified through the use of two parameters—the Increment (INC) and Limit. The Increment specifies the anticipated period between conforming cells whilst the Limit specifies the allowed ‘relaxation’ from this increment for cells that arrive earlier than anticipated.
For a CBR connection the Increment is simply the reciprocal of the PCR. Due to the statistical effects of multiplexing sources together, jitter is introduced into a connection at all stages in the network (including at source as seen by the UNI). The allowable jitter, at each policed interface (e.g. a UNI or NNI), is termed the Cell Delay Variation Tolerance (CDVT). It is this parameter that is used for the GCRA Limit value in a CBR connection.
The generic GCRA algorithm can be summarised by the following pseudo-code:
if (cell_arrive_time > TAT)
/* TAT is Theoretical Arrival Time */
{
cell_conforms;
TAT = cell_arrival_time + INC,
}
else if (cell_arrival_time > TAT − Limit)
{
cell_conformant;
TAT = TAT + INC;
}
else
cell_non_conformant;
Thus for a CBR connection the minimum interval between successive cells is equal to 1/PCR−CDVT. Any cells outside of this, can be marked as non-conformant and subsequently discarded if desired.
A rt-VBR connection on the other-hand must conform to both the PCR and SCR components of its traffic contract. To police this, two GCRAs operating in parallel are used to ensure compliance (each cell must comply to both GCRAs for the cell to be conformant). The first GCRA polices the peak rate of the connection (thus Increment=1/PCR, Limit=CDVT) whilst the second polices for the sustained rate. The sustained rate GCRA rate algorithm is defined by the parameters (Increment=1/SCR and Limit=BT+CDVT) where BT is the Burst Tolerance of the connection and is calculated by:
BT
=(
MBS
−1) (1
/SCR
−1
/PCR
)
AAL2 will be used primarily to support CBR Voice and VBR Voice traffic sources (although it can also support other delay sensitive traffic as well as data). It is important to note here the distinction between the individual AAL2 traffic sources and the underlying traffic class of the VCC bearer (CBR or rt-VBR VCC). In AAL2 it will be quite normal to use a CBR VCC to aggregate together a number of VBR Voice traffic sources or to use a rt-VBR VCC to support a mixture of CBR Voice and VBR Voice traffic sources.
A CBR Voice source is characterised by a periodic emission of constant rate data. CBR Voice sources include traditional 64 kb/s PCM (as typically carried by AAL1) or may arise through the use of constan

Affiliated with

Also associated with

Rating

ATM packet 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 ATM packet scheduler, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and ATM packet scheduler will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3119757