ISO/IEC 14476-6:2010
(Main)Information technology — Enhanced communications transport protocol: Specification of QoS management for n-plex multicast transport — Part 6:
Information technology — Enhanced communications transport protocol: Specification of QoS management for n-plex multicast transport — Part 6:
ISO/IEC 14476-6:2010 provides a specification of QoS management for accomplishing a desired quality of service in n-plex multicast transport connections. For this purpose, it describes the QoS management operations in n-plex multicast transport connections such as QoS negotiation, QoS monitoring and QoS maintenance. ISO/IEC 14476-6:2010 is an integral part of ECTP-5 (ITU-T Rec. X.608 | ISO/IEC 14476-5). All of the protocol components, including packet formats and protocol procedures specified in ITU-T Rec. X.608 | ISO/IEC 14476-5, are also valid in ISO/IEC 14476-6:2010.
Technologies de l'information — Protocole de transport de communications amélioré: Spécification de la gestion de QoS pour le transport n-plex en multidiffusion — Partie 6:
General Information
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 14476-6
First edition
2010-05-01
Information technology — Enhanced
communications transport protocol:
Specification of QoS management for
n-plex multicast transport
Technologies de l'information — Protocole de transport de
communications amélioré: Spécification de la gestion de QoS pour le
transport n-plex en multidiffusion
Reference number
©
ISO/IEC 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2010 – All rights reserved
CONTENTS
Page
1 Scope. 1
2 Normative references . 1
3 Definitions . 1
3.1 Terms defined in Rec. ITU-T X.605 | ISO/IEC 13252 . 1
3.2 Terms defined in Rec. ITU-T X.606 | ISO/IEC 14476-1. 1
3.3 Terms defined in Rec. ITU-T X.606.1 | ISO/IEC 14476-2. 2
3.4 Terms defined in Rec. ITU-T X.608 | ISO/IEC 14476-5. 2
4 Abbreviations . 2
4.1 Packet types. 2
4.2 Miscellaneous . 3
5 Conventions . 3
6 Overview. 3
7 Components for QoS management. 5
7.1 Base header. 5
7.2 QoS parameters . 6
7.3 QoS extension element. 7
7.4 Error bitmap element . 9
7.5 Packets used for QoS management . 9
7.6 Packet format . 10
8 Procedures for QoS management. 11
8.1 QoS negotiation. 11
8.2 QoS monitoring . 13
8.3 QoS maintenance . 15
9 Timers and variables . 17
9.1 Timers . 17
9.2 Operation variables. 17
Annex A – Implementation considerations. 19
A.1 A scenario of interworking between ECTP-6 and RSVP . 19
Bibliography. 21
© ISO/IEC 2010 – All rights reserved iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 14476-6 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems, in collaboration with
ITU-T. The identical text is published as ITU-T Rec. X.608.1 (11/2008).
ISO/IEC 14476 consists of the following parts, under the general title Information technology — Enhanced
communications transport protocol:
⎯ Part 1: Specification of simplex multicast transport
⎯ Part 2: Specification of QoS management for simplex multicast transport
⎯ Part 3: Specification of duplex multicast transport
⎯ Part 4: Specification of QoS management for duplex multicast transport
⎯ Part 5: Specification of N-plex multicast transport
⎯ Part 6: Specification of QoS management for N-plex multicast transport
iv © ISO/IEC 2010 – All rights reserved
Introduction
ECTP is designed to support tightly controlled multicast connections in simplex, duplex and n-plex applications. This
part of ECTP (Recommendation ITU-T X.608.1 | ISO/IEC 14476-6) specifies the quality of service (QoS) management
functions for the n-plex multicast transport protocol (ECTP-5: Recommendation ITU-T X.608 | ISO/IEC 14476-5).
In the n-plex multicast connection, the participants include one TC-Owner and many TS-users. TC-Owner will be
chosen among the TS-users before the connection begins. TC-Owner is at the heart of multicast group communications.
It is responsible for overall connection management by governing the connection creation and termination, multicast
data transport, and the late join and leave operations. The multicast data transmissions are allowed by TS-users as well
as the TC-Owner. Each TS-user is allowed to send multicast data to the group only if it gets a token from the
TC-Owner. That is, the multicast data transmissions of TS-users are controlled by the TC-Owner.
For the stable QoS management of the n-plex multicast connection, this Specification provides the QoS management
functions such as QoS negotiation, QoS monitoring and QoS maintenance.
The target QoS parameters are negotiated between the TC-Owner and TS-users before the connection creation. During
the connection, the status of the connection is monitored by TS-users, and the monitoring result is delivered to Sending
TS-users and the TC-owner via control packets. According to the QoS monitoring result, Sending TS-users may adjust
their data transmission rate, and the TC-owner may pause or terminate the connection.
This QoS management Specification can be used in multicast applications that want to support various QoS
requirements and the corresponding billing/charging models.
© ISO/IEC 2010 – All rights reserved v
INTERNATIONAL STANDARD
RECOMMENDATION ITU-T
Information technology – Enhanced communications transport protocol:
Specification of QoS management for n-plex multicast transport
1 Scope
This Recommendation | International Standard provides a specification of QoS management for accomplishing a
desired quality of service in n-plex multicast transport connections. For this purpose, this Specification describes the
QoS management operations in n-plex multicast transport connections such as QoS negotiation, QoS monitoring and
QoS maintenance. This Recommendation | International Standard is an integral part of ECTP-5 (Rec. ITU-T X.608 |
ISO/IEC 14476-5). All of the protocol components, including packet formats and protocol procedures specified in
Rec. ITU-T X.608 | ISO/IEC 14476-5, are also valid in this Recommendation | International Standard.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
– Recommendation ITU-T X.601 (2000), Multi-peer communications framework.
– Recommendation ITU-T X.602 (2004) | ISO/IEC 16513:2005, Information technology – Group
management protocol.
– Recommendation ITU-T X.605 (1998) | ISO/IEC 13252:1999, Information technology – Enhanced
Communications Transport Service Definition.
– Recommendation ITU-T X.606 (2001) | ISO/IEC 14476-1:2002, Information technology – Enhanced
Communications Transport Protocol: Specification of simplex multicast transport.
– Recommendation ITU-T X.606.1 (2003) | ISO/IEC 14476-2:2003, Information technology – Enhanced
Communications Transport Protocol: Specification of QoS management for simplex multicast transport.
– Recommendation ITU-T X.607 (2007) | ISO/IEC 14476-3:2008, Information technology – Enhanced
communications transport protocol: Specification of duplex multicast transport.
– Recommendation ITU-T X.608 (2007) | ISO/IEC 14476-5:2008, Information technology – Enhanced
communications transport protocol: Specification of N-plex multicast transport.
3 Definitions
3.1 Terms defined in Rec. ITU-T X.605 | ISO/IEC 13252
This Recommendation | International Standard is based on the concepts developed in Enhanced Communications
Transport Service (Rec. ITU-T X.605 | ISO/IEC 13252):
a) QoS parameters;
b) QoS negotiation;
c) QoS arbitration.
3.2 Terms defined in Rec. ITU-T X.606 | ISO/IEC 14476-1
This Recommendation | International Standard is described based on the concepts and terms developed in the
specification of simplex multicast transport on ECTP-1 (Rec. ITU-T X.606 | ISO/IEC 14476-1):
a) application;
b) packet;
Rec. ITU-T X.608.1 (11/2008) 1
c) sender;
d) receiver;
e) tree;
f) parent;
g) child.
3.3 Terms defined in Rec. ITU-T X.606.1 | ISO/IEC 14476-2
This Recommendation | International Standard is described based on the concepts and terms developed in the
specification of simplex multicast transport on ECTP-2 (Rec. ITU-T X.606.1 | ISO/IEC 14476-2).
a) QoS monitoring;
b) QoS maintenance.
3.4 Terms defined in Rec. ITU-T X.608 | ISO/IEC 14476-5
This Recommendation | International Standard is described based on the concepts and terms developed in the
specification of n-plex multicast transport on ECTP-5 (Rec. ITU-T X.608 | ISO/IEC 14476-5).
a) TCN (TC-Owner):
An n-plex multicast connection has a single TCN. The TCN is responsible for connection management
including connection creation/termination, late join, connection maintenance, and token management.
For example, in teleconferencing applications, the TCN may act as the 'conference server', which may be
used for control of the conferencing without sending multicast data. In the example of a 'multi-user
on-line game' application, the TCN may act as the 'game-control server'.
b) SU (Sending TS-user):
A TS-user who gets a token from the TCN. Only the SU is allowed to send multicast data to the group.
In other words, before sending multicast data, each user must request a token from the TCN.
c) LO (Local Owner):
For a given subset of participants, an LO becomes a root of a locally configured shared tree in the local
group. Each LO is also connected to other LOs in inter-group trees. Each LO will control the tree
configuration for the local group. It will also perform error recovery as the parent for the local group.
d) Token:
It represents the right for a TS-user to transmit multicast data. A TS-user who has a token is called an
SU. The tokens are managed by the TC-Owner.
e) Multicast data channel:
The TCN or an SU can send multicast data to all the other group members over an IP multicast address.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply:
4.1 Packet types
ACK Acknowledgment
CC Connection Creation Confirm
CR Connection Creation Request
CSR Connection Status Report
CT Connection Termination Request
DT Data
JC Late Join Confirm
JR Late Join Request
TGC Token Get Confirm
TGR Token Get Request
2 Rec. ITU-T X.608.1 (11/2008)
TSR Token Status Report
4.2 Miscellaneous
ADN Active Descendant Number
CHQ Controlled Highest Quality
Diffserv Differentiated Services
ECTP Enhanced Communications Transport Protocol
ECTS Enhanced Communications Transport Services
IP Internet Protocol
LQA Lowest Quality Allowed
MSS Maximum Segment Size
OT Operating Target
QoS Quality of Service
RSVP Resource Reservation Protocol
5 Conventions
None.
6 Overview
This Recommendation | International Standard provides a specification of QoS management for n-plex multicast
transport connections. This Specification describes the following QoS management operations:
a) QoS negotiation, including reservation of network resources:
For QoS negotiation, this Specification assumes that a desired QoS level for multicast application service
can be expressed in terms of a set of QoS parameters. QoS negotiation is performed via an exchange of
control packets between the TCN (TC-owner) and TS-users for the multicast data channel. The TCN
proposes the target values of QoS parameters obtained from the application's requirements in order for
TS-users to send or receive multicast data, and each TS-user can propose modified values based on its
system and/or network capacity and the application's requirements. The TCN arbitrates the modified
values proposed by TS-users. Target values for QoS parameters can be used as input parameters for
reservation of network resources.
b) QoS monitoring:
QoS control in ECTP-6 is based on feedback of control packets from TS-users. The feedback messages
from TS-users enable the TCN to keep track of the number of TS-users and also to monitor the
connection status for the multicast data channel. QoS monitoring is designed to allow TS-users and the
TCN to diagnose the connection status in terms of QoS parameter values, and thus to take the necessary
actions for maintaining the connection status at a desired QoS level. The monitored connection status
will be reported to the application on the TCN side. The information conveyed could provide statistics
useful for billing purposes, for example.
c) QoS maintenance:
Based on feedback information from TS-users, the TCN and SUs (Sending TS-users) take one or more
actions so as to maintain the connection status at a desired QoS level. These QoS maintenance actions
include adjustment of the data transmission rate, connection pause and resume, troublemaker ejection
and connection termination operations. These QoS monitoring and maintenance functions, based on
monitored parameter status, provide rate-based congestion control.
In the connection creation phase, the TCN informs TS-users whether QoS management is enabled. If QoS management
is enabled, the TCN must also specify whether or not QoS negotiation will be performed in the connection. QoS
monitoring and maintenance operations are performed only if QoS management is enabled.
Figure 1 illustrates these QoS management operations for the n-plex multicast connection. In the figure, the protocol
operations marked as dotted lines are specified in Rec. ITU-T X.608 | ISO/IEC 14476-5 (ECTP-5).
Rec. ITU-T X.608.1 (11/2008) 3
Figure 1 – QoS management in the n-plex connection
In this figure, it is noted that the basic control operations of the n-plex multicast connection are described in ECTP-5,
such as control tree creation, tree-based reliability control, control tree maintenance and token control. In this
Specification, the QoS negotiation, monitoring and maintenance operations for the n-plex multicast connection will be
introduced.
From the requirements of the applications, the TCN will determine the target values for each QoS parameter. The
procedures for mapping the requirements of an application to these target parameter values are outside the scope of this
Specification. Application programs could be used to carry out such mappings.
QoS negotiation is performed in the connection creation phase. The TCN proposes the desired target values for each
QoS parameter, used when sending multicast data to TS-users and receiving multicast data from SUs by multicast, via
the CR packet. For the throughput parameter, three target values are specified: Controlled Highest Quality (CHQ),
Operating Target (OT) and Lowest Quality Allowed (LQA). For the other parameters, such as transit delay, transit
delay jitter and data loss rate, only two target values are specified: OT and LQA.
If QoS negotiation is enabled, each TS-user can propose modifications to the TCN's proposed parameter values. These
modified values will be determined by considering the system capacity at the TS-user side and network environment.
The following restrictions are imposed for modification of the parameter values by TS-users:
a) OT values must not be modified by TS-users;
b) the values modified by TS-users must be within the LQA and CHQ values proposed by the TCN.
The parameter values modified by TS-users are delivered to the TCN via CC messages. The TCN arbitrates different
parameter values for various TS-users by taking a default range of values.
Figure 2 shows an abstract sketch of QoS negotiation that can occur in ECTP-6. From the requirements of the
application, a set of target QoS parameter values for the multicast data channel will be configured at the TCN. The TCN
informs TS-users about the target values for sending multicast data to TS-users and receiving multicast data from an SU
(step 1). Based on these target values, each TS-user begins to make resource reservations with the help of RSVP [4] [5]
or Diffserv [6] (step 2). If QoS negotiation is enabled in the connection, each TS-user may propose modified values for
QoS parameters based on its system and/or network capacity and the requirements of the application for the multicast
data channel (step 3). From these modified parameter values, the TCN determines the arbitrated values for sending
multicast data to other TS-users and receiving multicast data from other TS-users (step 4). These arbitrated values are
delivered to TS-users via subsequent TSR or JC packets and will be used for QoS monitoring and maintenance.
4 Rec. ITU-T X.608.1 (11/2008)
Figure 2 – a) QoS negotiation procedures; b) Multicast data transport in ECTP-5
After an ECTP connection is created and, consequently, if QoS management is enabled, the QoS monitoring and
maintenance operations are performed for a multicast data channel. For QoS monitoring, each TS-user is required to
measure the QoS parameter values experienced in the multicast data channel. Based on the measured values and the
negotiated values, a TS-user determines a status value for each parameter as an integer: normal (0), reasonable (1),
possibly abnormal (2) or abnormal (3). These status values will be delivered to the parent node via ACK packets along
the control tree. Each TS-user aggregates the parameter status values reported by its child nodes and forwards the
aggregated value(s) to its own parent using ACK packets. Finally, these status values are delivered to the SUs and
the TCN.
Based on the monitored status values, an SU and the TCN invoke QoS maintenance actions to maintain the connection
status at a desired QoS level. Specific rules are pre-configured to trigger QoS maintenance actions such as data
transmission rate adjustment, connection pause and resume, troublemaker ejection and connection termination. These
actions will be taken by observing how many TS-users are in an abnormal or possibly abnormal state.
7 Components for QoS management
This clause describes the ECTP-6 protocol components required for QoS management operations. All of the
components are extended from those already defined in Rec. ITU-T X.608 | ISO/IEC 14476-5.
7.1 Base header
Figure 3 shows the base header specified in Rec. ITU-T X.608 | ISO/IEC 14476-5 (in case of ECTP-5 over IP). Note
that the two 1-bit fields (Q and N) are inserted into the 'Reserved' field of the original base header of ECTP-5.
Rec. ITU-T X.608.1 (11/2008) 5
0 123
01 23 456 7 0 1 2 3 456 70 123 4 5 6 7 0 1 2 345 67
CT Packet type
Next element Version Checksum
Source port Destination port
Packet Sequence Number (PSN)
Payload length QN
FTReserved oken ID
X.608.1(08)_F03
Figure 3 – Base header in ECTP-5
For QoS management, a TCN specifies the following two fields in the 'QoS' and 'N' bits:
0 1 2 3 4 5 6 7
F Reserved N
a) QoS is a flag bit to indicate whether QoS management is enabled (1) or not (0) in the connection. If this
bit is set to '1', all the procedures for QoS management are invoked. The default value is '0';
b) N (Negotiation) is a flag bit to indicate whether QoS negotiation is enabled (1) or not (0) in the
connection. If this bit is set to '1', each TS-user is allowed to propose its own parameter values for the
multicast data channel. The default value is '0'.
The QoS bit must be set to '1' (QoS enabled) before the N bit is valid. There are three possible cases.
a) QoS bit set to '1' and N bit set to '0' indicates that QoS is to be used in the connection, and QoS values
will be imposed by the TCN. TS-users cannot negotiate it.
b) Both bits set to '1' indicates that QoS is to be used in the connection, and QoS parameter values may be
negotiated between TS-users and the TCN.
c) QoS bit set to '0' indicates that QoS is not to be used in the connection. The N bit is not used in this case.
7.2 QoS parameters
In this Specification, the following four QoS parameters are defined for an n-plex connection:
a) throughput (bytes per second);
b) transit delay (milliseconds);
c) transit delay jitter (milliseconds);
d) data loss rate (percent).
The throughput parameter represents the amount of application data output over a specific time period. Target
throughput means a throughput value required for desired display of application data. In multicast data transport,
applications generate multicast data and the TCN or SUs will transmit them based on the target throughput value(s).
The actual data reception rate at a TS-user's side will depend on the data transmission rate, network conditions, end
system capacity, and so on.
For throughput, the TCN shall configure the following target values:
a) CHQ throughput;
b) OT throughput;
c) LQA throughput.
The following inequalities must be enforced: LQA throughput ≤ OT throughput ≤ CHQ throughput.
The transit delay represents end-to-end transmission time from a sender to a receiver. For desired QoS of a multicast
data channel, the TCN may configure the following target values:
a) OT transit delay;
b) LQA transit delay.
6 Rec. ITU-T X.608.1 (11/2008)
QoS
The following inequalities must be enforced: OT transit delay ≤ LQA transit delay.
Transit delay jitter represents variations in the transit delay values. For desired QoS of a multicast data channel, the
TCN may configure the following target values:
a) OT transit delay jitter;
b) LQA transit delay jitter.
The following inequalities must be enforced: OT transit delay jitter ≤ LQA transit delay jitter.
Data loss rate is defined as the ratio of the amount of lost data over the amount of total transmitted data. For desired
QoS of a multicast data channel, the TCN may configure the following target values:
a) OT loss rate;
b) LQA loss rate.
The following inequalities must be enforced: OT loss rate ≤ LQA loss rate.
7.3 QoS extension element
QoS extension is a newly defined element for QoS management in this Specification. All the extension elements used in
ECTP-6 are listed below.
Table 1 – Extension elements
Extension element Encoding value (4 bits) Length of extension element (bytes)
No element 0000 0
Connection 0001 4
Error bitmap 0010 Varied
Timestamp 0100 12
Token 0110 Varied
LO information 0111 Varied
QoS 0101 28
The QoS extension element specifies the maximum segment size (MSS) and the target values for ECTP-6 QoS
parameters, which are described in 7.2. As shown in Figure 4, the QoS element has a length of 28 bytes.
Figure 4 – QoS extension element
The following parameters are specified:
a) Next element (4 bits) – Indicates the type of the next element immediately following this QoS element.
b) Version (4 bits) – Defines the current version of this element. Its current version is encoded as '0011':
1) 0001 – simplex multicast connection (for ECTP-1 and ECTP-2);
2) 0010 – duplex multicast connection (for ECTP-3 and ECTP-4);
3) 0011 – n-plex multicast connection (for ECTP-5 and ECTP-6).
Rec. ITU-T X.608.1 (11/2008) 7
c) QoS Flags – Is a flag byte to specify if each of the QoS parameters, the MSS and the data channel type
are used in the connection. Encoding of this byte is depicted in the following figure. If a bit is set to '1',
then the corresponding QoS parameter, MSS or data channel type will be used. The default value is '0'
for each bit. If the 'F' bit of QoS Flags is set to '1', then the values of the QoS parameters are configured
for a multicast data channel sending multicast data. If the 'G' bit of QoS Flags is set to '1', then the values
of the QoS parameters are configured for a multicast data channel receiving multicast data. It should be
noted that both the 'F' bit and the 'G' bit cannot be set to '1' at the same time:
0 1 2 3 4 5 6 7
A B C D E F G R
1) A – throughput;
2) B – transit delay;
3) C – transit delay jitter;
4) D – data loss rate;
5) E – maximum segment size (MSS);
6) F – multicast data channel for sending multicast data;
7) G – multicast data channel for receiving multicast data;
8) R – reserved for future use.
d) Maximum segment size (MSS) – Represents the maximum size of an ECTP segment or packet in units of
bytes. If the 'E' bit of QoS Flags is set to '1', the MSS is subject to negotiation. Otherwise, the default
MSS value of 1024 will be used.
e) Throughput values – Each value is a 32-bit unsigned integer in bytes per second. The following target
values are valid only if the 'A' bit of QoS Flags is set to '1':
1) CHQ throughput – upper limit for throughput;
2) OT throughput – target throughput for desired display of multicast data;
3) LQA throughput – lower limit for throughput.
f) Transit delay values – Each value is a 16-bit unsigned integer representing milliseconds. The following
target values are valid only if the 'B' bit of QoS Flags is set to '1':
1) OT transit delay – target transit delay for desired display of multicast data;
2) LQA transit delay – maximally allowed transit delay.
g) Transit delay jitter values – Each value is a 16-bit unsigned integer representing milliseconds. The
following target values are valid only if the 'C' bit of QoS Flags is set to '1':
1) OT transit delay jitter – target transit delay jitter for desired display of multicast data;
2) LQA transit delay jitter – maximally allowed transit delay jitter.
h) Data loss rate values – Each value is an 8-bit unsigned integer ranging from 0 to 100 representing a
percentage. The following target values are valid only if the 'D' bit of QoS Flags is set to '1':
1) OT loss rate – target loss rate for desired display of multicast data;
2) LQA loss rate – maximally allowed loss rate.
i) Reserved – Is reserved for future use.
In the connection phase, if QoS is enabled, the TCN can propose the target values of QoS parameters, used for sending
multicast data and receiving multicast data, to TS-users via the CR packet. This CR packet format is as follows:
CR packet = base header + connection element + QoS element + QoS element
In the above CR packet, the first QoS element is used for sending multicast data and the second QoS extension element
is used for receiving multicast data. The value of the 'F' bit of QoS Flags in the first QoS element is '1', and the 'Next
Element' byte in the first QoS element indicates the QoS element for receiving multicast data.
The QoS element is used for the TCN to inform the TS-users about the target values for QoS parameters by sending a
CR packet in the connection creation phase. In QoS negotiation, the QoS element is also used when a TS-user proposes
8 Rec. ITU-T X.608.1 (11/2008)
its own modified values to the TCN. The negotiated QoS values will be announced to late-joiners via the JC packet and
to existing TS-users via TSR packets.
These QoS values are also referred to in the QoS monitoring and maintenance operations.
7.4 Error bitmap element
For QoS monitoring, each TS-user is required to measure the parameter values that have been experienced. A measured
parameter value is mapped to a parameter status value. A status value is an integer such as 0, 1, 2 or 3. A larger status
value indicates a worse status for the connection.
The status values are delivered to SUs via ACK packets. The error bitmap element of the ACK packet contains the
status values for QoS parameters used in the connection.
The error bitmap element specified in Rec. ITU-T X.608 | ISO/IEC 14476-5 is shown below. In the figure, the
'parameter status' byte is newly defined in this Specification for QoS.
0 12 3
01 2 3 4 5 6 7 01 23 4 5 6 7 012 34 56 7 0 12 3 4 567
Bitmap length Valid bitmap length
Next element Reserved Parameter status
Error bitmap
X.608.1(08)_F05
Figure 5 – Error bitmap element
The 'parameter status' byte has the following structure:
0 1 2 3 4 5 6 7
A B C D
a) A – represents two bits to indicate the status value for the measured throughput;
b) B – represents two bits to indicate the status value for the measured transit delay;
c) C – represents two bits to indicate the status value for the measured transit delay jitter;
d) D – represents two bits to indicate the status value for the measured packet loss rate.
A status value consisting of two bits has one of the following values:
a) 00 – indicates '0' as a status value;
b) 01 – indicates '1' as a status value;
c) 10 – indicates '2' as a status value;
d) 11 – indicates '3' as a status value.
The detailed mapping schemes from a measured parameter value to a status value are described in 8.2.3.
7.5 Packets used for QoS management
Table 2 lists the ECTP-5 packets used for QoS management. Note that the CSR packet is newly defined in this
Specification for QoS management.
Rec. ITU-T X.608.1 (11/2008) 9
Table 2 – ECTP-5 packets used for QoS management
Extension element
Packet type
LO
Connection Error Bitmap Timestamp Token QoS
Information
DT O
CR O O
CC O
TSR O O O
ACK O
JC O O
CSR O
The CR packet contains a QoS element. This is used by the TCN to propose (or impose) the target values of QoS
parameters used in the connection. These values can be referenced by resource reservation mechanisms and protocols,
such as RSVP, if they are enabled in the network. If QoS negotiation is enabled, each TS-user responds to TCN with its
own proposed values for QoS parameters via a CC packet. The TCN will arbitrate the returned proposals, and the
arbitrated values for the QoS parameters will be delivered to TS-users via TSR packets. For a late joiner, the target QoS
parameter values currently being used in the connection (whether imposed or negotiated originally) are notified via a JC
packet (see 8.1).
The target or negotiated values will be referred to in QoS monitoring and maintenance operations. ACK packets are
used to convey the status values for QoS parameters experienced on the TS-user side (see 8.2).
The status values of QoS parameters are aggregated by TS-users along the control tree and finally delivered to SUs.
Using this information, an SU determines the connection status and periodically reports it to the TCN via a CSR packet.
A DT packet contains a Timestamp element which is used to measure end-to-end transit delay.
7.6 Packet format
In this Recommendation | International Standard, one control packet is defined.
Table 3 – ECTP-6 packets newly defined for QoS management
Full name Acronym Transport From To
Connection Status Report CSR Unicast SU TCN
The encoding value and packet structure are shown for each of the ECTP-6 packets in Table 4. The extension elements
are attached to the base header in the order specified in the table.
Table 4 – Format of ECTP-6 packets
Encoding Extension elements or user data Length Operational
Packet type
value (packet structure) (bytes) protocol stage
CSR 0100 0001 Error Bitmap 48 QoS monitoring
7.6.1 Connection Status Report (CSR)
The CSR packet is used by an SU to inform the TCN of the current connection status. SUs can determine the current
connection status by exploiting parameter status values obtained from ACK packets. These values must also be reported
to the TCN so that it can perform further connection maintenance actions such as connection pause/resume and
termination. An SU sends the CSR packet to the TCN over the following source and destination addresses:
a) Source IP: IP address of the SU.
b) Source Port: local port number of the SU.
c) Destination IP: IP address of the TCN.
d) Destination Port: group port number.
10 Rec. ITU-T X.608.1 (11/2008)
The CSR packet contains a 16-byte base header and a 32-byte error bitmap element with an empty 'Error Bitmap' field.
The base header of a CSR packet must be encoded as follows:
a) Next Element: '0010' (error bitmap element);
b) CT: '11';
c) Packet Type: '0100 0001' (CSR);
d) Checksum: to be calculated;
e) Source Port: local port number of the SU (or connection ID);
f) Destination Port: group port number (or connection ID).
All fields other than those specified above will be set to '0' and ignored at the receiver side.
The error bitmap element must be encoded as follows:
a) Next element: '0000'.
b) Parameter status: a connection status value determined by the SU: 00, 01, 10 or 11 (see 7.4).
All fields other than those specified above will be set to '0' and ignored at the receiver side.
8 Procedures for QoS management
In ECTP-6, QoS management includes the following operations:
a) QoS negotiation, possibly with reservation of network resources;
b) QoS monitoring;
c) QoS maintenance.
QoS negotiation is performed in the connection creation phase, while QoS monitoring and maintenance operations are
done in the data transmission phase.
If QoS management is enabled in the connection, QoS monitoring and maintenance operations are performed by
default. On the other hand, QoS negotiation is enabled only when the N bit in the 'QN' byte of the ECTP-5 base header
is set to '1'.
8.1 QoS negotiation
The TCN transmits a CR packet to all TS-users to start the connection creation phase. The CR packet contains the
proposed (or imposed) target values for each QoS parameter such as CHQ, OT and LQA for the multicast data channel.
Each TS-user can refer to these target values for resource reservation (see 8.1.3). If QoS negotiation is enabled in the
connection, the negotiation procedures are activated (see 8.1.1). The imposed or negotiated target values are
subsequently used in QoS monitoring and maintenance (see 8.2 and 8.3).
If QoS negotiation is enabled in the connection, each TS-user can propose a new modified value for the multicast data
channel to send and receive multicast data in response to a target parameter value proposed by the TCN. To propose a
new value, a TS-user is required to be able to identify the system or network resources to be used. For example, a
modified throughput value may be assessed from line rates of transmission links accessible at the TS-user site
(e.g., DSL, cable modem, wireless networks, and so on). The modified value may also be determined by considering the
end user's requirement for receiving and sending multicast data at a TS-user site. It is possible for an end host to use a
software program to determine the modified parameter value for negotiation, based on network and system resources, as
well as end user's requirements. However, in real world scenarios, it is not easy to precisely identify the resource
capacity of the networks involved with a receiver. Accordingly, at least in the near future, QoS negotiation will be done
based on the end user's requirements at the application level or on the system capacity of the end host.
In this Specification, a TCN is required to specify via the QoS extension element whether each QoS parameter is
subject to negotiation (see 7.3). For parameters that are negotiable, a TS-user can propose modified values. If a TS-user
does not wish to modify a QoS parameter, it will just return the same QoS element received from the TCN.
8.1.1 Negotiation procedures
If QoS negotiation is enabled in the connection, each TS-user responds to the TCN with a CC packet containing the
modified target values for the respective QoS parameters.
This clause describes the QoS negotiation procedures for the throughput parameter, which has three target values: LQA,
OT and CHQ. The negotiation procedures for the other parameters such as delay, jitter and loss rate are all the same
except that these parameters have no CHQ values.
Rec. ITU-T X.608.1 (11/2008) 11
During QoS negotiation, TS-users must not modify the OT value for each parameter. The detailed procedures for QoS
negotiation are described below and illustrated in Figure 6.
Figure 6 – QoS negotiation procedure
a) The TCN proposes target parameter values for the multicast data channel to send and receive multicast
data
From application requirements and system and/or network capacity, the TCN determines the target
parameter values for multicast data: LQAo, OTo, CHQo, where LQAo < OTo < CHQo, and then
transmits a CR packet with two QoS extension elements for sending multicast data to TS-users and
receiving multicast data from TS-users.
b) TS-users can modify the parameter values for the multicast data channel sending and receiving multicast
data
In response to the target values proposed by the TCN, each TS-user i can propose the modified values for
sending and receiving multicast data: LQA and CHQ. OTo value must not be changed. Thus, the
i i
following inequalities are enforced: LQAo < LQA < OTo < CHQ < CHQo for each TS-user i. Each
i i
TS-user delivers the modified values to the TCN via a CC packet with two QoS extension elements for
sending and receiving multicast data.
c) The TCN arbitrates the modified parameter values for sending multicast data to other TS-users and
receiving multicast data from other TS-users
TCN arbitrates the modified parameter values proposed by TS-users as follows:
CHQmin = min CHQ , for each TS-user i;
i
LQAmax = max LQA , for each TS-user i.
i
LQAmax and CHQmin are the negotiated parameter values that have resulted from QoS negotiation.
d) The TCN announces the negotiated parameter values
TCN announces LQAmax, CHQmin and OT values to TS-users via TSR and JC packets.
For delay, jitter and loss rate parameters, an LQAmin value will be obtained instead of LQAmax, since CHQ values are
not used and OT value < LQA value for these parameters. That is,
LQAmin = min LQA , for each TS-user i.
i
Note that QoS negotiation is not performed for late-joining TS-users. The TCN just notifies the negotiated parameter
values to the late-joining TS-user via a JC packet.
12 Rec. ITU-T X.608.1 (11/2008)
Note that the negotiated QoS parameter values will be referred to in the QoS monitoring and maintenance operations
and are not modified in the data transport phase.
8.1.2 MSS negotiation
The MSS represents the maximum packet size, which depends on the maximum transmission unit (MTU) for link layer
transmissions. Typical MTU values are 1500 bytes for Ethernet, 1492 bytes for IEEE 802, 4352 bytes for FDDI, 576
bytes for X.25, and so on. The MTU determines the frame size for link layer transmissions, and hence the MSS value.
The default MSS value in ECTP-5 is 1024 by
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...