Learning Center
Plans & pricing Sign in
Sign Out

A proposed framework of QoS management over multicast transport


A proposed framework of QoS management over multicast transport

More Info
									 "A proposed framework of QoS management over multicast transport"

         Maryam Roshanaei,

         Martin Tunnicliffe,

         Kingston University, UK.


This paper describes a framework of QoS management for one-to-many multicast communications in

the context of a new multicast transport protocol called the Enhanced Communication Transport

Protocol (ECTP). ECTP is a transport protocol designed to support Internet multicast applications, such

as audio and video, which is currently being standardised in ITU.T SG7. ECTP operates over IP

networks that have IP multicast forwarding capability.

This framework consists of QoS management operations: “Negotiation, Monitoring and Maintenance”

and ECTP connection management functions: “Connection creation, Data Transfer and Termination”.

We propose a mapping architecture for QoS management operations over ECTP connection

management functions to address the QoS needs of multicast applications.

Keywords- Quality of Service (QoS) management, Enhanced Communication Transport Protocol

(ECTP), Resource ReSerVation Protocol (RSVP).


QoS management is considered an important user demand and therefore receives wide attention,

especially in the areas of computer network and real time multimedia systems.

Since service characterises in existing systems are fixed when they are built, they often do not give

users any real influence over the QoS they can obtain. On the other hand, multicast applications (such

as Multimedia) and their users can differ enormously in their requirements for the rate of services and

resources available to them at the time of use of application systems. Therefore there is an increasing

need for modified services that can be tailored for the end users' specific requirements [1].

For multicast applications, particularly those relying on real time multimedia data, it is essential to

introduce a new multicast transport protocol, which provides a guaranteed QoS level system-wide,

including end-systems, communication systems and networks.

Most of the research on the multicast transport has been concentrated on providing the reliability

control such as error recovery and congestion control.

One the other hand, while a variety of transport protocols (e.g. UDP, RTP) have been designed to

enhance the current network with QoS management, still the problem of achieving a reliable QoS for

multicast applications has not been satisfactorily resolved therefore this paper have proposed a new

multicast transport protocol to over come this problem.[2].

This paper presents a framework of QoS management for one-to-many communication in the context of

IP multicast. We propose a mapping architecture for QoS management operation over ECTP

connection management functions to address the QoS needs of multicast applications.

This paper is organized as follows: We study ECTP connection management behaviour and QoS

management functionality in ECTP. We propose a mapping architecture of QoS management over

ECTP connection using resource-reserving protocol (RSVP).


Enhanced communication transport protocol (ECTP) is a tree-based multicast transport protocol [3]

designed to support Internet multicast applications running over IP multicast [5] capable networks.

ECTP operates over IPv4/IPv6 networks that have the IP multicast forwarding capability.

                                 MULTICAST APPLICATIONS

                  PROTOCOL (ECTP)

                                     IP MULTICAST

                                       Figure (1): ECTP Model*

                         *Source- ITU-T X.ectp-2 | ISO/IEC 14476-2

ECTP features "tight management of multicast sessions" from the viewpoint of senders. Tight

management in the multicast sessions happens when the sender is at the heart of group

communications. The sender can perform overall management of the multicast connection

establishment, group membership and Quality of Services (QoS) perceived by end users with the help

of Internet Group Management Protocol (IGMP) [4] and IP multicast routing protocols [5].


In ECTP, the connection management functions have been described in three phases: "Connection

creation phase", "Data transmission phase", "Connection termination phase", which are as follow:


The potential receivers are incorporated into the multicast group, called an “enrolled group”.

Verification processes and group key distribution may be performed together during the enrolment. IP

multicast addresses and port numbers must also be announced to the receivers. These enrolment

operations may rely on the well-known protocols such as SAP/SDP (Signalling) [7], HTTP (Web Page

announcement) and SMTP (E-mail) [8]. The specific enrolment mechanisms are outside the scope of

this paper.

Enrolled receivers can then join/leave the multicast-capable network with the help of the IGMP and IP

multicast routing protocols. ECTP is targeted to support tightly controlled multicast connections: For

example, the connection creation and termination functions are explicitly supported, together with QoS

negotiation. In addition, connection pause and resumption functions are also provided.

The ECTP sender is designated as the “connection owner”, responsible for the overall management of

the connection. This node governs the connection creation and termination, connection pause and

resumption and late joiners and leavers. The ECTP sender activates the connection creation process by

sending a connection creation message. Some or all the enrolled receivers may respond with

confirmation messages to the sender. The connection creation is completed when the sender receives

the confirmation messages from all of the active receivers. Some or all of the enrolled group receivers

will join the connection. The receivers that have joined the connection are called "active receivers". An

active receiver can leave the connection by sending a leaving request to the sender.

An enrolled receiver that is not active can participate in the connection as a late-joiner. The late-joiner

sends a join request to the sender, in response to which the sender transmits a join confirm message.

This indicates whether the join request is accepted or not.


 The sender begins to transmit multicast data. For data transmission, an application data stream is

 sequentially segmented and transmitted by means of data packets to the receivers. Receivers deliver

 the received data packets to the applications in the same order the sender transmitted them.

 During the data transmission, if severe network congestion is indicated by the QoS management

 functions (negotiation, monitoring and maintenance), the sender suspends the multicast data

 transmission temporarily. During this period, no new data is delivered, while the sender transmits

 periodic null data messages to indicate that the sender is “alive”. After a pre-specified time has

 elapsed, the sender resumes the multicast data transmission.


 Connection termination happens when termination messages are sent to all the receivers, after all the

 multicast data are transmitted. The connection may also terminate due to a fatal protocol error such as

 a connection failure.

      CONNECTION CREATION                     Multicast Data                     Connection Termination

                                                               QoS Monitoring
                       QoS Negotiation
                                                               QoS Maintenance

                                  Fig (2): ECTP Connection Lifetime*
                               *Source- ITU-T X.ectp-2 | ISO/IEC 14476-2
 Figure (2) shows the ECTP transport connection lifetime. During the transport connection, ECTP

 provides QoS management functions for the stable management of the QoS for the connection users.

 Such QoS management functionality can be achieved with QoS negotiation, monitoring, and

 maintenance operations.


QoS management is concerned with the support of QoS parameters, which are to be maintained within

certain limits between two or more users. Section (3.1) and (3.2) discuss QoS management parameters

and classifications.


Multicast applications have varying performance requirements. Therefore to design a service that

provides guaranteed QoS satisfaction, it is important to determine the QoS parameters that the

applications are interested in and the range of “target” values for each chosen parameter.

The following are the most important of QoS parameters from the point of view of multicast

applications [10,11]:

  THROUGHPUT – This reflects how much information the network is able to deliver during a

     certain time interval.

 TRANSIT DELAY – This represents end-to-end transmission time from a sender to a receiver. For

    obvious reasons, most real-TIME applications are sensitive to transit delay.

 TRANSIT DELAY JITTER - Jitter is the variation of network delay. It occurs when the packets from

    the same application experience different network delays along the transmission route. The major

    threat of jitter is that it makes the traffic “bursty”. The resulting high bit rate bursts create

    congestion at bottlenecks in the transmission route.

 DATA LOSS RATE - When network congestion occurs, packets may be dropped due to over-

    flowing buffers or because they arrive too late to be of use. Those dropped packets directly affect

    the viewing quality at the receiving end. The data loss rate is defined as a ratio of the amount of

    lost data to the amount of transmitted data.

Depending on application requirements, some QoS parameters may not be used for a particular

connection. For example, a non-real time application may not impose the transit delay requirement. On

the other hand, other QoS parameter(s) may be defined for specific applications.

In ECTP connection management, the sender configures the target values for each QoS parameter

from the application requirements. The sender proposes the desired target values for each QoS

parameter to all receivers by multicast. These are as follow [12]:

 Controlled highest quality (CHQ),

 Operating target (OT),

 Lowest quality allowed (LQA),

There are different target values for each QoS parameter. Table (1) shows that the sender can

configure the following target values for each QoS parameters.

              QoS parameter
                                 Throughput         Transit delay     Transit delay Jitter   Data loss rate
           Target value
                 CHQ                 
                  OT                                                                          
                 LQA                                                                          
                                 Table (1): Targets values used by each QoS parameter.


In ECTP, QoS management functions can be grouped into three operations: “Negotiation”,

“Maintenance” and “Monitoring”. These are as follows:

 NEGOTIATION- QoS negotiation is a static QoS management function “responsible for analysing

    the activity components and selecting a composite of the individual QoS levels supportable by the

    components, which is sufficient to realise the QoS of the complete activities” [13].

    QoS negotiation is performed in the ECTP connection creation phase. The ECTP sender proposes

    the desired target values such as CHQ, OT, LQA, for each QoS parameter to all receivers. Each

    receiver may refer to these target values for resource reservation such as RSVP.

    After an ECTP connection is created, QoS monitoring and maintenance operations are performed

    for the multicast data transmission [12].

 MAINTENANCE- QoS maintenance is a dynamic QoS management function. To maintain an

    agreed level of QoS it is often not sufficient to dedicate resource to an activity at QoS negotiation

    time. Instead, dynamic QoS maintenance is frequently required to ensure that the required

    performance of individual system components is kept within bound [13].

    The QoS maintenance function is performed in the ECTP data transmission phase, where each

    receiver is required to measure the parameter values experienced and report these values back to

    the sender. Then, based on the measured values, target values and negotiated values, the receiver

    determines a “status value” for each parameter. Finally, the sender aggregates the parameters’

    status values reported from all receivers [12].

 MONITORING- QoS Monitoring is also a dynamic QoS management function which is used to

    allow each level of the system to track the ongoing QoS levels achieved by the lower layers and

    compare them with the initial requirement [13].

    The QoS monitoring function is performed in the ECTP data transmission phase. Based on the

    monitored parameters’ status values, the sender takes the following QoS maintenance actions [12]:

    1. Adjustment of data transmission rate where ECTP uses a fixed-sized window-based flow
    2. Connection pause can be performed to suspend the multicast data transmissions so as to
       prevent the connection quality from being more severely degraded.
   3. Connection termination terminates a connection when all multicast data have been

To enable QoS management functions in ECTP connections, the QoS negotiation function must

provide resource reservation to guarantee an end-to end connection.

QoS negotiation uses target values in QoS parameters to make a reservation, using RSVP [14]. These

target values should be mapped onto the RSVP objects’ traffic descriptors to make the reservation


Throughput and delay target values in ECTP QoS parameters are the only parameters that can be used

by the RSVP objects’ traffic descriptor. The remaining ECTP QoS parameters (such as delay jitter and

data lost rate) cannot be explicitly supported by RSVP. This is because RSVP signalling provides a

guarantee of transit delay only by signalling the reservation of a bandwidth corresponding to the


We propose an architecture to map the ECTP QoS parameters’ target values onto RSVP traffic

descriptors to provide guaranteed QoS for end-to-end connection. This architecture assumes the non-

negotiation mode, in which the QoS parameter values proposed by sender are enforced to all receivers.

ECTP QoS parameters' target values and RSVP objects' traffic descriptors can be described as follows:

1.      Throughput target values: CHQ, OT and LQA,
2.      Transit delay target values: OT and LQA,
1.      Token rate (r),
2.      Bucket depth (b),
3.      Peak rate (p),
4.      Slack term (S),
An interface between ECTP and RSVP is required so that the ECTP QoS parameter values are passed

to the RSVP processor. The RSVP object (Sender_Tspec) will be delivered to receivers via RSVP

PATH messages. It is expected that these messages will be transmitted almost simultaneously with the

issue of the ECTP packet. Figure(3) shows the relationship between ECTP QoS parameters and RSVP

traffic descriptors.

           Multicast Application                                           Multicast Application

           ECTP parameters & PATH trigger                                PATH & RESV Status
          ECTP/UDP                      RSVP                     RSVP               ECTP/UDP
                          RESV Status                                    RESV trigger

                           IP                                                 IP

                       Figure (3)- Relationship between ECTP QoS parameters and
                       RSVP Traffic descriptors       7
The mapping procedures can be described as follow:

1. Throughput target values can be mapped onto RSVP traffic descriptors (Sender_TSpec and

FLOWSPEC) as follows[12]:

 CHQ throughput = p

where p is the Peak rate in RSVP (Sender_Tspec),

 OT throughput = r

where r is the Token rate in RSVP (Sender_Tspec),

 LQA throughput > R

where R is the reserved bandwidth in RSVP (FLOWSPEC),

Upon arrival of the RSVP PATH message at a receiver, the information in the RSVP (Sender_TSpec

and ADSPEC) objects will be passed across the RSVP API to the ECTP application.

The application interprets the arriving information, and uses it to select the resource reservation

parameters. These parameters are composed into an RSVP (FLOWSPEC) object and will be returned

to the sender via the RSVP RESV messages.

2. Transit delay target values can be mapped onto RSVP (FLOWSPEC) traffic descriptors as

    follows [12]:

 OT transit delay = required end-to-end delay.

    Note that the bandwidth reservation R is calculated in the fashion that the end-to-end delay bound.

 LQA transit delay – OT transit delay = Slack term S.

At each RSVP-aware node in the network, the FLOWSPEC contained in RESV messages is used to

request an appropriate resource reservation for the desired QoS level. State merging, message

forwarding, and error handling will proceed according to the rules of the RSVP protocol. Finally, the

merged FLOWSPEC object is delivered to the ECTP sender to indicate a successful resource


Table (2) summarizes the ECTP QoS parameters' target values and RSVP objects' traffic descriptors’

mapping functionality.

                ECTP                Target             RSVP traffic       Description on how to map or use
            QoS parameters      Parameter values        descriptor
             Throughput              CHQ                p in Tspec             Directly mapped onto p

                                      OT                r in Tspec             Directly mapped onto r

                                     LQA                R in Rspec    R must not be smaller than LQA throughput

             Transit delay            OT                R in Rspec    OT transit delay is set to the required end-
                                                                                     to-end delay
                                     LQA                S in Rspec       LQA – OT transit delay is set to S

Table (2)- ECTP QoS parameters target values and RSVP traffic descriptor mapping functionality


This work uses OPNET simulation tool to implement this mapping architecture. The implementation

procedure will produce a testbed with different scenarios to test the capability of the ECTP transport

protocol relative to UDP in the context of QoS management. The testbed will consist of two scenarios,

which are as follows:

 Client and receiver with RSVP,

 Client and receiver without RSVP,

These scenarios will be tested on the voice application.


This paper presents a framework and mapping architecture of QoS management in the ECTP transport

protocol to provide an end-to end QoS for multicast applications. We have discussed the ECTP

connection functionality together with QoS management parameters and their classification. Finally,

we proposed a mapping architecture to enable QoS management within the ECTP connection phases.

[1]-Comer, Douglas E, "Internetworking with TCP/IP v.1 principles, protocols and architecture",

Second Edition, Chapter (1), 1991

[2]-Tanenbaum A, "Computer Networks", third Edition, Chapter (1),(2), 1996

[3].-Levin B, Garcia-Luna-Aceves J.J, " A comparison of reliable multicast protocols", Multimedia

Systems, 1998

[4]- RFC (966), "Host Groups: A Multicast Extension to the Internet Protocol", IETF, December 1985,

[5]- Williamson, Beau, "Developing IP Multicast networks". Indianapolis: Cisco Press, 2000

[6]- Project Editor: Seok Joo Koh, "ECTP Specification, ITU-T Recommendation X.606/ISO/IEC

FDIS 14476-1 (ECTP-1)", 2000,

[7]- RFC (2327),"SDP: Session Description Protocol", IETF, April 1998

[8]-RFC (1945), " Hypertext Transfer Protocol- HTTP/1.0", IETF, May 1996

[9]-RFC (821), "Simple Mail Transfer Protocol- SMPT", IETF, August 1982

[10]-"QoS protocols and architectures", QoS forum White paper,, July1999

[11]- RFC (2212)," Specification of Guaranteed Quality of Service", IETF, September 1997

[12]-Project Editor: Seok Joo Koh , "ECTP Specification, ITU-T Recommendation X.606/ISO/IEC

FDIS 14476-2 (ECTP-2)", 2001,

[13]-E. Cristian, E. Borcoci, A. Constantin," Multimedia oriented-Transport architectures and QoS

management", Research Report No: 06-LOR, Institute National Des Telecommunication, 1999

[14]-R. Braden, D.Estrin, D.Zappale, "The Design of the RSVP protocol", USC/Information Science

Institute, June 1995

[15]- RFC (2205),"Resource ReServation Protocol (RSVP)- Version1 Functional Specification",

IETF, September 1997


To top