MIND
1.2
IST-2000-28584 MIND
D1.2
Top-level architecture for providing seamless QoS, security, accounting
and mobility to applications and services
Contractual Date of Delivery to the CEC: 30 November 2002
Actual Date of Delivery to the CEC:
Author(s):
29 November 2002
see Author List
Participant(s): see Author List
Workpackage: WP1 - Applications and Services
Est. person months: 45 PM
Security:
Pub.
Nature:
R
Version:
1.0 (2 digits separated by a dot. The first digit is 0 for draft, 1 for project approved
document, 2 or more for further revisions requiring approval by the project)
Total number of pages: 317
Abstract:
This document investigates concepts and architectures for providing seamless QoS, security, accounting,
billing and mobility to applications and services using IP based networks. While the basic architecture BRENTA (presented in the BRAIN Project) - is a pure End-System-Centric QoS architecture, several
major and important enhancements are introduced to cover network aspects, AAA and Ad Hoc
requirements. Extensions to BRENTA are developed to include a full specification of an End-to-End
Negotiation Protocol for negotiating application layer QoS parameters and capabilities. Further, different
operating system QoS specific functionalities are studied, in order to analyse how ESI (an important
interface within BRENTA) functionality can be mapped to Windows and Linux platforms. The support of
terminals operating in an Ad Hoc environment is discussed considering necessary extensions to
BRENTA. A Domain Model defining different administrative network domains is derived from the use
cases of MIND Deliverable D1.1. Based on this model, an analysis of appropriate security aspects is
performed. Possible interactions between service and transport domains for setting up multi-stream
multimedia QoS-aware sessions are studied. A generic billing and accounting architecture is derived and
its relation to the service and transport domains is shown, based on some specific scenarios. Finally this
document includes an overview of the giving support to help specifying and evaluating application and
service level trials conducted by WP6 trials.
Keyword list: MIND, BRAIN, BRENTA, Beyond 3G, IP, E2ENP, Quality of Service, QoS, User,
Service, Application, Multimedia, Wireless, QoS Negotiation, QoS Framework, QoS Management,
End-to-End Negotiation, Adaptation Path, Service Domain, Transport Domain, Ad Hoc, AAA,
Security, Accounting, Billing, Scenario, Use Case, Domain Model
Page 1
MIND
http://www.unik.no/personer/paalee/
1.2
Page 2
MIND
1.2
Executive Summary
Distributed multimedia applications and services have stringent requirements with respect to the QoS as
in-time delivery of data is crucial for successful operation. Multi-homed terminals contribute to the
heterogeneity, which makes it even harder to provide consistent end-to-end QoS as the user wants to
perceive it. In this deliverable, the BRAIN End Terminal Architecture (BRENTA – developed in the ISTBRAIN project) is extended to provide seamless QoS, security, accounting, billing and mobility to
applications and services. The major challenge is to handle a heterogeneous environment, where
ubiquitous and mobile end-terminals communicate with each other.
Based on BRENTA several enhancements dealing with heterogeneous devices and Ad Hoc aspects are
proposed. An E2ENP is specified, which can be used by terminals to negotiate a common set of
capabilities, quality ranges and QoS parameters for multi-session, multi-stream, multimedia applications.
E2ENP is a meta-protocol based on the IETF protocol SIP (a protocol for media session establishment)
and extends the IETF protocol SDPng (a XML based session capability description protocol). Further, the
QoS support available for different operating systems is studied, namely the Linux and the Windows
platforms. This is required in order to provide a mapping between the ESI primitives to platform specific
QoS application programming interfaces. Additionally, various enhancements of BRENTA to deal with
Ad Hoc aspects are considered.
A Domain Model identifying the administrative domains within the network architecture is defined. The
basic Domain Model describes the MIND access network architecture in a generalised way that allows
flexible development of this architecture. The Domain Model considers various network configurations as
they can be formed without listing example configurations. The relations of the identified administrative
domains is expressed via reference points, which describe mutual trust relations, positions for protocol
stacks and interaction interfaces between them.
The Domain Model is then used in various aspects. It is extended further to include interworking between
Service and Transport administrative domains. Thus the service providers are enabled to manage and
control the resource consumption of the customers when establishing multimedia communications.
Additionally, a security analysis is conducted based on proposed protocol stacks at various reference
points within the Domain Model. The security analysis helps to identify potential threats and proposes
several security mechanisms. Finally, accounting and billing aspects are analysed in order to provide an
abstract accounting and billing architecture.
Finally, support for the user trials (Work Package 6) is provided by Work Package 1. Here, the focus is on
the MIND implementations within the domain of BRENTA. In particular, requirements are derived for
the implementations and some parts of the prototype are described, namely QoS enabled applications,
Traffic Control aspects and their interworking with the ISABEL application and finally QoS signalling
between ISABEL and the local mobility protocol BCMP.
Annex A provides a full-fledged specification of the E2ENP. Based on a requirement analysis, it details
the proposed extensions to SDPng, necessary for the negotiation of application level QoS parameters,
capabilities and adaptation paths for setting up multi-stream multimedia sessions. Some use cases with
SIP to demonstrate the E2ENP negotiation process are shown. Message sequence charts for various
scenarios (different possible message exchange sequences) are provided. The authors have followed and
participated to the discussions in the IETF MMUSIC WG concerning QoS and capabilities negotiation
and the on-going SDPng specification. However, in this work the drafted specification, based on an
original use of SDPng, partially diverges from the current status of the discussion in MMUSIC. The
major aim considered here is the better understanding of the E2ENP concepts in more concrete terms,
without waiting for the SDPng specification to be finalised. To this extent, it is planed in any case to
harmonise the E2ENP specification with the final SDPng version, or even contribute to the preparation
thereof, once the E2ENP concepts have been properly reviewed and have reached stable status after a
necessary testing phase.
Page 3
MIND
1.2
Authors
Partner
Name
Phone / Fax / E-mail
Siemens
Andriani, Susi
Phone: +49 89 722 59597
Fax:
+49 89 722 21882
E-mail: susi.andriani@icn.siemens.de
Agora Systems
Armuelles, Ivan
Phone: +34 679 877 087
Fax:
+34 91 336 7333
E-mail: ivan@dit.upm.es
Ericsson
Bascuñana Muñoz,
Alejandro
Phone: +34 91 339 4400
Fax:
+34 91 339 4001
E-mail: ecealbm@madrid.es.eu.ericsson.se
Siemens
Guenkova-Luy,
Teodora
Phone: +49 731 502 4148
Fax:
+49 731 502 4142
E-mail: guenkova@vs.informatik.uni-ulm.de
T-Nova
Hellwig, Christian
Phone: +49 30 3497 3514
Fax:
+49 30 3497 3515
E-mail: christian.hellwig@t-systems.com
T-Nova
Kollecker, Lars
Phone: +49 30 3497 3454
Fax:
+49 30 3497 3455
E-mail: lars.kollecker@t-systems.com
Siemens
Kassler, Andreas
Phone: +49 731 502 4146
Fax:
+49 731 502 4142
E-mail: kassler@informatik.uni-ulm.de
Agora Systems
Ruiz, Pedro M.
Phone: +34 91 533 5857
Fax:
+34 91 534 8477
E-mail: pedro.ruiz@agoratechnologies.com
SONY
Mandato, Davide
Phone: +49 711 5858 797
Fax:
+49 711 5858 468
E-mail: Mandato@sony.de
Page 4
MIND
1.2
Partner
Name
Phone / Fax / E-mail
NTT DoCoMo
Prasad, Anand R.
UPM
Dr. Robles Valladares, Phone: +34 91 549 5700
Tomás
Fax:
+34 91 336 7333
E-mail: trobles@dit.upm.es
NTT DoCoMo
Schoo, Peter
Phone: +49 89 5682 4211
Fax:
+49 89 5682 4300
E-mail: schoo@docomolab-euro.com
T-Nova
Tessier, Serge
Phone: +49 30 3497 3114
Fax:
+49 30 3497 3115
E-mail: serge.tessier@t-systems.com
T-Nova
Tirla, Octavian
Phone: +49 30 3497 2356
Fax:
+49 30 3497 2357
E-mail: octavian.tirla@t-systems.com
NTT DoCoMo
Wang, Hu
Phone: +49 89 5682 4214
Fax:
+49 89 5682 4300
E-mail: wang@docomolab-euro.com
Phone: +49 89 5682 4112
Fax:
+49 89 5682 4300
E-mail: prasad@docomolab-euro.com
Page 5
MIND
1.2
Table of Contents
1. Introduction ............................................................................................... 12
1.1
Purpose and Scope of this document ......................................................................................... 12
1.2
Structure of this Document........................................................................................................ 12
1.3
BRAIN Background .................................................................................................................. 13
1.3.1 Quality of Service Architectures ....................................................................................... 13
1.3.2 BRENTA Review ............................................................................................................. 14
2. BRENTA Refinements............................................................................... 17
2.1
The End-to-End Negotiation Protocol ....................................................................................... 17
2.1.1 E2ENP Terms Definition .................................................................................................. 18
2.1.2 The Concept ...................................................................................................................... 19
2.1.2.1
Coping With Unstable Environment Conditions ................................................... 20
2.1.2.2
Hierarchical QoS Specification.............................................................................. 20
2.1.2.3
Inter-stream QoS Constraints................................................................................. 20
2.1.2.4
Planning Counteractions Ahead............................................................................. 20
2.1.2.5
Independence from Network Aspects .................................................................... 21
2.1.2.6
Mapping of the Quality Settings on Codec Definition........................................... 21
2.1.2.7
Third-Party-Assisted Negotiation .......................................................................... 22
2.1.3 The Features...................................................................................................................... 22
2.1.4 Related Work .................................................................................................................... 24
2.2
Service Interface Implications ................................................................................................... 26
2.2.1 QoS support in Linux OS.................................................................................................. 26
2.2.1.1
Queuing Discipline ................................................................................................ 27
2.2.1.2
Classes ................................................................................................................... 27
2.2.1.3
Filters ..................................................................................................................... 28
2.2.1.4
Policing .................................................................................................................. 29
2.2.1.5
Traffic Control ‘tc’................................................................................................. 29
2.2.1.6
Framework for QoS Developing in Linux ............................................................. 30
2.2.2 QoS support in Microsoft Windows OS............................................................................ 34
2.2.2.1
The Host Protocol Stack ........................................................................................ 35
Page 6
MIND
1.2
2.2.2.2
QoS Service Provider............................................................................................. 39
2.2.2.3
Traffic Control API................................................................................................ 40
2.2.2.4
Traffic Control Providers....................................................................................... 40
2.2.2.5
Subnet Bandwith Manager and Admission Control Service.................................. 42
2.2.3 Linux and Windows Comparison with Respect to QoS Support ...................................... 42
2.2.3.1
QoS Support in Linux ............................................................................................ 42
2.2.3.2
QoS Support in Microsoft Windows...................................................................... 43
2.2.4 Mapping BRENTA Service Primitives ............................................................................. 43
2.3
2.2.4.1
Enhanced Socket Interface and BRENTA Architecture. ....................................... 43
2.2.4.2
Modelling the Enhanced Socket Interface ............................................................. 44
2.2.4.3
QoS Mechanisms Supported in BRENTA............................................................. 44
2.2.4.4
ESI Service Primitives ........................................................................................... 45
2.2.4.5
ESI QoS Parameters............................................................................................... 48
2.2.4.6
Mapping ESI to RAPI Function Calls.................................................................... 49
2.2.4.7
Mapping ESI calls to GQoS Function Calls .......................................................... 51
Ad Hoc and QoS Aspects .......................................................................................................... 55
2.3.1 MIND Project Vision ........................................................................................................ 55
2.3.2 Features of Mobile Ad Hoc Networks .............................................................................. 56
2.3.2.1
General Features of Ad Hoc Networks .................................................................. 56
2.3.2.2
QoS Issues ............................................................................................................. 56
2.3.2.3
Roles of an Ad Hoc Node ...................................................................................... 57
2.3.2.4
Basic Requirements of Ad Hoc End Terminals ..................................................... 58
2.3.3 QoS Architecture Proposals .............................................................................................. 59
2.3.3.1
Integrated Services on Ad Hoc Networks.............................................................. 59
2.3.3.2
Differentiated Services in Ad Hoc networks ......................................................... 61
2.3.3.3
End-to-End Adaptive Applications........................................................................ 62
2.3.4 Terminal Architecture Approach Design for Ad Hoc Node.............................................. 63
2.3.4.1
MANET Terminal Architecture and the IETF....................................................... 63
2.3.4.2
Adaptive Cross-layer Design ................................................................................. 63
2.3.5 BRENTA Features in the Context of Ad Hoc Networks .................................................. 64
Page 7
MIND
1.2
2.3.5.1
Considering Modifications in BRENTA................................................................ 65
3. Domain Model ........................................................................................... 67
3.1
Usage Scenarios......................................................................................................................... 67
3.1.1 Train Scenario ................................................................................................................... 68
3.1.2 Identification of Roles in the Train Scenario .................................................................... 68
3.2
Principles of the Domain Model................................................................................................ 70
3.2.1 Administrative Domain..................................................................................................... 70
3.2.2 Domain and Reference Point ............................................................................................ 71
3.2.3 Map of Roles to Domains ................................................................................................. 71
3.3
Domain Model for Train Scenario............................................................................................. 71
3.3.1 Basic Domain Model ........................................................................................................ 72
3.3.1.1
AN Content............................................................................................................ 72
3.3.1.2
SPN Content .......................................................................................................... 73
3.3.1.3
LN Content ............................................................................................................ 73
3.3.1.4
AAAB Content ...................................................................................................... 73
3.3.1.5
Reference Points .................................................................................................... 73
3.3.1.6
Trust Model ........................................................................................................... 75
3.3.2 Domain Model Including Mobile Ad Hoc Networks........................................................ 75
3.3.2.1
IAN content ........................................................................................................... 75
3.3.2.2
LN Content ............................................................................................................ 76
3.3.2.3
AN Content............................................................................................................ 76
3.3.2.4
Reference Points .................................................................................................... 76
3.3.2.5
Trust Model ........................................................................................................... 77
4. Interworking Service Domain/Transport Domain ................................... 78
4.1
Application Specific Domain Model Refinements .................................................................... 78
4.2
Service Domain and Transport Domain .................................................................................... 79
4.2.1 Application Plane.............................................................................................................. 81
4.2.2 Transport Plane ................................................................................................................. 81
4.2.2.1
Control Plane ......................................................................................................... 81
4.2.2.2
User Plane.............................................................................................................. 81
Page 8
MIND
1.2
4.2.3 Interactions between Service Domain and Transport Domain.......................................... 81
4.3
Service and Transport Validating Facilities............................................................................... 84
4.3.1 Registration Processing..................................................................................................... 84
4.3.2 Service Validating Facility................................................................................................ 87
4.3.3 Transport Validating Facility ............................................................................................ 90
4.4
Interworking Scenarios.............................................................................................................. 91
4.4.1 No Coupling...................................................................................................................... 92
4.4.2 Loose Coupling ................................................................................................................. 94
4.4.3 Tight Coupling .................................................................................................................. 96
4.4.4 Integrated .......................................................................................................................... 99
5. Security Analysis .................................................................................... 103
5.1
Methodology ........................................................................................................................... 103
5.2
Threat Analysis........................................................................................................................ 105
5.2.1 Identification of Assets ................................................................................................... 106
5.2.1.1
Context for Roles/Domains and Assets Identification ......................................... 106
5.2.1.2
Asset Identification .............................................................................................. 106
5.2.1.3
Assets for Roles and Domains in the Train Scenario........................................... 107
5.2.2 Identification of Threats.................................................................................................. 110
5.2.2.1
Catalogue of Threats............................................................................................ 110
5.2.2.2
From LN’s Point of View .................................................................................... 111
5.2.2.3
From IAN’s Point of View .................................................................................. 113
5.2.2.4
From AN’s Point of View.................................................................................... 113
5.2.2.5
From SPN’s Point of View .................................................................................. 114
5.2.2.6
From NP’s Point of View .................................................................................... 115
5.2.2.7
From VASP’s Point of View ................................................................................ 116
5.2.3 Summary of Threat Analysis .......................................................................................... 117
5.3
Protocol Stacks ........................................................................................................................ 118
5.3.1 Protocol Stacks and Reference Points ............................................................................. 118
5.3.2 AAAB Considerations .................................................................................................... 119
5.4
Security Mechanisms............................................................................................................... 121
Page 9
MIND
1.2
5.4.1 The Internet Approach .................................................................................................... 121
5.4.1.1
Mobile IP and IPSec ............................................................................................ 121
5.4.1.2
Mobile Router Support with Mobile IP ............................................................... 121
5.4.1.3
Global Connectivity for IPv4 Mobile Ad Hoc Networks .................................... 122
5.4.1.4
Extensible Authentication Protocol over IP (EAPoIP) ........................................ 122
5.4.1.5
Secure Socket Layer (SSL).................................................................................. 122
5.4.2 Wireless and Architecture-Specific Approaches............................................................. 123
5.4.2.1
GSM and UMTS.................................................................................................. 123
5.4.2.2
CHOICE Service Platform................................................................................... 123
5.4.2.3
802.1x .................................................................................................................. 123
5.4.3 Merging the Two Worlds ................................................................................................ 124
5.4.3.1
GSM SIM Key Generation for Mobile IP............................................................ 124
5.4.3.2
Windows for SMART Cards ............................................................................... 124
5.4.3.3
IEEE 802.1X RADIUS Usage Guidelines........................................................... 124
5.4.3.4
Inter-working Between IP Security and Performance Enhancing Proxies for
Mobile Networks ................................................................................................. 125
6. Accounting and Billing ........................................................................... 126
6.1
Value Chain Analysis .............................................................................................................. 127
6.2
Mobile Internet Roles Analysis ............................................................................................... 128
6.3
Domain Model Implementation............................................................................................... 132
6.4
Billing and Accounting Architecture....................................................................................... 133
6.4.1 Architecture Skeleton...................................................................................................... 133
6.4.2 Security measures for intra-domain and inter-domain accounting.................................. 134
6.5
Billing requirements ................................................................................................................ 134
6.6
Cost Allocation Model............................................................................................................. 135
6.6.1 Accounting Records ........................................................................................................ 135
6.7
Accounting & Billing Issues Related to Chapter 4.................................................................. 135
7. Support of User Trials ............................................................................ 138
8. Conclusion .............................................................................................. 141
9. References............................................................................................... 144
Page 10
MIND
1.2
10. Abbreviations .......................................................................................... 149
11. Figures and Tables ................................................................................. 153
11.1 Figures ..................................................................................................................................... 153
11.2 Tables ...................................................................................................................................... 155
12. Annex ....................................................................................................... 156
Page 11
MIND
1.2
1. Introduction
1.1 Purpose and Scope of this document
The objective of Work Package 1 (WP1) is to define and improve mechanisms for the rapid creation and
seamless provision of broadband Internet Protocol (IP) services and applications, to develop new business
and service models and to help specifying and evaluating application and service level trials conducted by
Work Package 6 (WP6) Trials. The purpose of this document is to report specific results from WP1
conducted during the Mobile IP based Network Developments (MIND) project. This results are also
based on the work done in BRAIN [BD12], [BD22].
This deliverable concentrates on the following aspects:
•
It analyses and refines a selected subset of BRain ENd Terminal Architecture (BRENTA)
features taking into account new developments like personal area networks, Ad Hoc networks,
and Quality of Services (QoS) aspects
•
It proposes an approach on how QoS can be supported in beyond 3G systems.
•
It investigates, defines and specifies suitable mechanisms for authentication, security and
accounting for the highly diverse usages of network that will take place within future mobile
networks.
•
It describes potential interactions between Service Domain and Transport Domain necessary in
order to negotiate end-to-end QoS including application plane and transport plane aspects
•
It investigates the billing and charging concepts in a MIND network
•
It helps to specify and evaluate application and service trials conducted by WP6, testing both
standard and especially adapted applications and services
These goals result in the main objective of the MIND project and are based on the BRAIN system
architecture studies, which enable full coverage of seamless IP-based services and security mechanisms
for users in hot spot areas and on the move. The main focus is to facilitate the rapid creation of broadband
multimedia services and applications that are fully supported and customised when accessed by future
mobile users from a wide range of wireless access technologies, such as Universal Mobile
Telecommunication System (UMTS), High Performance Radio LAN version 2 (HIPERLAN/2) and
Wireless Local Area Network (WLAN).
Experiences and knowledge gained in this process is then transferred to standardisation efforts in Europe
and beyond. In a follow up project, this specification can then be used to build a prototype system in order
to demonstrate the usability of this kind of a concept.
This document, Top-level architecture for providing seamless QoS, security, accounting and mobility to
applications and services, presents ideas of how to facilitate the rapid creation of broadband multimedia
services and applications. In addition to well known existing services, new kind of services will be
possible with the combination of wireless and broadband. This document provides also a security
analysis, the End-to-End Negotiation Protocol (E2ENP), and appropriate accounting and billing aspects
with a view on the evolved Domain Model (DM) that was derived from one of the usage scenarios.
This document should be of relevance for application designers and network designers in the area of
mobile communications.
1.2 Structure of this Document
This deliverable D1.2 is intended to provide an analysis from the application layer point of view of future
beyond 3G scenarios, BRENTA refinements, security analysis, and appropriate accounting and billing
aspects.
This deliverable is composed of a core report and an Annex A. While the core report covers all the major
work, the Annex A specifies a QoS negotiation protocol in detail.
Page 12
MIND
1.2
First, the core report takes a very brief look at the work done within the BRAIN project and tries to
analyse what has been missing when defining the BRENTA architecture. Here, we take into account new
developments and standardisation efforts like capability and QoS negotiation, personal area networks, Ad
Hoc networks, and QoS aspects. More specifically, in Chapter 2 we introduce the concepts of an E2ENP
that can be used to negotiate capabilities, application layer QoS parameters and alternative QoS contracts
for setting up multi-stream multimedia sessions. Then, we take a look at the extended service interface
defined in the BRAIN project and analyse how this can be realised with current off-the-shelf operating
systems like Linux or Win32. Finally, Chapter 2 explores issues and challenges that arise when running
BRENTA on Ad Hoc nodes. Based on usage scenarios developed in the BRAIN project, Chapter 3
derives a Domain Model (DM) that contains reference points. This DM is used throughout the rest of this
document. In Chapter 4, the DM is extended to cover Service Domain / Transport Domain interworking
scenarios necessary for setting up multimedia conferences. In Chapter 5 the DM is used to perform a
security analysis to identify potential threats and propose security mechanisms. Chapter 6 continues with
introducing accounting and billing aspects. Based on a value chain analysis and the DM, a reference
scenario of Chapter 4 is selected and extensions to cover accounting and billing aspects are proposed.
Chapter 7 describes the support given for the user trials of the MIND project and summarising this
deliverable and Chapter 8 gives the overall conclusion of this document.
The Annex A covers an in detail specification of the E2ENP. The E2ENP can be used to negotiate
Application level QoS, capabilities and adaptation paths for multistream multimedia sessions. It is based
on extensions to the Session Description Protocol new generation (SDPng) and uses Session Initiation
Protocol (SIP) as transport mechanism. Here, we first start with an use case and requirement analysis.
Based on the requirements we define a set of extensions to SDPng as an Extensible Markup Language
(XML) constructs and give various examples, how the E2ENP can be used together with SIP.
1.3 BRAIN Background
1.3.1 Quality of Service Architectures
In a distributed scenario, the user will communicate with another user at a certain quality that he would
like to express to the system that manages the communication process. We refer to this quality as end-toend QoS as the user wants to perceive it. For accessing services, the users utilise end-systems where
applications run. These applications use services provided by the operating system, use several
communication sessions, protocols and finally Input/Output (I/O) devices that are used by the end-system
to send (and receive) data over the network (access and core) to (from) the remote user.
In order to provide end-to-end QoS as the user wants to perceive it, QoS has to be managed at the endsystem (end-system QoS), which involves local resource management. But also, the network resources
have to be managed which results in management of network QoS. Only the combination of end-system
and network QoS provides QoS enabled end-to-end communication to the applications and the user (see
Figure 1-1). When providing distributed applications with end-to-end services that have well defined QoS
constraints, managing all technical aspects of QoS in one overall approach requires one single integrated
service management architecture. This should both include (communication) resources within the
networks, operating systems and (communication) devices within end-systems.
A QoS architecture consists of a set of QoS configurable interfaces that allow to formalise QoS in the
end-system and network, and a framework for integrating QoS control and management mechanisms
[AUR98]. While QoS control and management are functional similar, QoS management mechanisms
operate on a slower timescale [AUR98]. Collections of control and management units are thus necessary
to process the data flow through a computer system. The computer system can be a single machine or a
network-connected one. A QoS framework can export a QoS configurable interface to the applications
whose flows it manages. The QoS framework can include mechanisms such as media adaptation of the
streams (see for example [KKS01]) that it manages. At the same time it can also take care of the network
flow management, such as priority control and filtering of the flows.
Page 13
MIND
1.2
Figure 1-1 Coverage of a QoS Framework
A QoS Framework or architecture can be organised according to different criteria. The structure of the
QoS framework may encompass the network level, the application level or both of them. Frameworks that
take into account only the network level mainly address issues like flow management and network
resource management, using admission control at the network edges or packet handling mechanisms
inside the network. A typical example would be the Integrated Services (IntServ) architecture [BCS94].
Architectures that encompass only the application level are assuming that the underlying network is QoSenabled. They typically provide adaptation mechanisms at the application level to provide the correct QoS
for the media flows and adapt to QoS delivery based on network level treatment.
QoS architectures can be also distinguished according to the degree of integration. An integral QoS
architecture considers all the components that lay within and interact with a certain flow, i.e. all endsystems, network elements and all functional entities on the transmission path from the source to the sink.
On the other hand, a non-integral QoS architecture manages only parts of the end-to-end path, e.g. the
network or the end-systems only. Also, a QoS framework might be limited to the end-system thus
providing local resource management. A different kind of QoS framework might only manage network
resources or the resources of the local network subsystem, whereas other kind of architectures are
completely integrated into applications and provide reaction mechanisms based on monitoring
information. A typical example of a non-integral QoS architecture that covers the end-system is the
BRENTA [BD12]. In this document, BRENTA will be refined to include Ad Hoc aspects with respect to
network QoS, application layer QoS, capability/QoS negotiation and security/billing aspects. Together
with the BRAIN/MIND Work Package 2 (WP2) work ([BD22], [MD21] and [MD22]), BRENTA
provides an integrated QoS architecture that also covers network layers QoS aspects.
1.3.2 BRENTA Review
Future end terminal architectures for systems beyond 3G are envisioned to provide multimedia
applications with pre-defined QoS levels (based on profile information), which allow the applications to
adapt in a pre-determined way in front of fluctuating transmission quality or even service disruption.
Fulfilling this requirement means that all the peers participating in a given telecommunication session
(including eventually service providers) shall coordinate their efforts:
Page 14
MIND
1.2
•
By deciding how to deal with service adaptation/disruption, and
•
In managing the overall resources (i.e. inclusively the local peer and the network resources)
accordingly.
The conceptual work carried out during the BRAIN project concerning the BRAIN QoS Framework and
the BRENTA ([BD12], [BD22]) defines mechanisms to specify and manage QoS End-to-End including
mobile end-systems and IP based wireless access networks in the transmission path. One of the key points
is to manage QoS end-to-end from the users and media point of view and provide well-defined adaptation
strategies in the case that QoS at the network level cannot be guaranteed for the whole session. This is
likely to occur in mobile environments, because of potential handovers (horizontal and vertical) and error
rate patterns of wireless links in contrast to fixed networks.
Key features of BRENTA design are:
•
Modularity – Guarantees that existing/legacy applications can be used as they are, whereas more
complex middleware solutions can be gracefully introduced later as soon as they are available;
•
Openness – Allows BRENTA being interoperable with other architectures (e.g. active networks).
Furthermore, since BRENTA is mostly designed based on existing protocol standards (among
others – Internet Engineering Task Force (IETF)), this would guarantee future interoperability
with other standard applications of this kind and the easy integration of new features following
the successive development of these standards;
•
Flexibility – Allows coping with different media types by e.g. supporting downloadable codecs.
Furthermore, QoS-enabling components featuring standardised interfaces may also be
downloaded from a server during runtime in order to enhance the system.
In order to address both existing and future applications, BRENTA (see Figure 1-2) introduces a
classification of applications based on the degree of QoS awareness they feature. The components of the
BRENTA architecture and their functionality are thoroughly described in the BRAIN project deliverables
([BD12], [BD22]).
In the following sections we assume that the various peers participating in multiparty communication
sessions may generally take the role of media stream-sender and/or receiver. Additionally, we assume
some intermediate components may passively assist peers with the connection establishment and
management, e.g. by providing service and/or peer discovery functionality. The session management
features of BRENTA are further enhanced.
To this extent, the concept of E2ENP is introduced, which BRENTA applications Type C and/or
BRENTA QoS Brokers may advantageously use for negotiating capabilities and QoS Contracts and coordinating resource reservations among multiple peers. The goal of this protocol is to allow peers to cope
with otherwise unpredictable events resulting from QoS changes / QoS violations, by enabling the mobile
users' applications to efficiently and timely react to those events, by planning proper counteractions
ahead, in a coordinated manner with the remote end-peers. In this manner, whenever QoS changes / QoS
violations occur, agreements on how to most effectively adapt to the mutated conditions can be timely
reached among the peers.
This protocol can be implemented directly within the applications Type C and/or the BRENTA QoS
Broker, or (better) as part of the BRENTA Session Manager (SM). The SM can hold the E2ENP by using
the signalling means offered by existing Session Layer Protocols, like SIP, and piggybacking the protocol
information by leveraging the SDPng. The logic handling the information to be negotiated and the local
and network resource reservation mechanisms (the latter, as offered by the Enhanced Socket Interface
(ESI) and Local Manager interfaces) shall be in any case implemented by the applications Type C and/or
the BRENTA QoS Broker.
Page 15
MIND
1.2
Figure 1-2 Architecture of the BRAIN End Terminal – BRENTA
Additionally to extending the BRENTA SM functionality the ESI is being further developed with respect
to the application within different operating systems (Windows, Linux). To achieve this, the QoS
architectures implemented in these OSs were analysed and their interfaces were identified in order to find
out the QoS specific functionality applicable for such a generalised interface like ESI. The ESI QoS
functionality within a BRENTA should integrate these respective OS functionalities in order to provide
interoperability for different possible QoS aware applications.
Page 16
MIND
1.2
2. BRENTA Refinements
This chapter addresses the detailed analysis of a selected subset of the BRENTA features, chosen based
on their importance as enabling technologies for meeting the demanding requirements set forth in the
BRAIN and MIND projects:
•
The E2ENP, which is a protocol that peer BRENTA Applications Type C / QoS Brokers can
advantageously use for coordinate their efforts to achieve the desired QoS level in spite of
unstable environmental (terminal and/or network) conditions. In Section 2.1 the E2ENP
conceptual model is analysed in detail, whereas a thorough description of scenarios,
requirements, and complete specification of the protocol can be found in Annex A. Impact of
Authentication, Authorisation and Accounting (AAA) and security are discussed in Chapter 4.
•
The Enhanced Socket Interface (ESI), an interface abstracting transport-level QoS control and
data plane protocols. In Section 2.2 Linux/Win32 platform implications on potential
implementation of ESI are analysed in detail.
•
Finally, the overall BRENTA is revised considering the novel requirements stemming from the
MIND scenarios dealing with mobile Ad Hoc networks (Section 3.2).
2.1 The End-to-End Negotiation Protocol
The Internet has proven to be a successful architecture for delivering a broad set of electronic services
(including - among many others - telephony, electronic messaging, and audio/video (A/V) services), not
only to sedentary but also to nomadic users.
Micro/macro IP mobility and wireless IP technologies in fact pave the way to the full integration of the
Internet with the second and third generation of mobile phone systems. In order to achieve this goal, next
generation IP networks and applications will have to address the increasingly important challenges of
wireless access, mobility management, the provision of QoS, and multimedia services.
A paramount problem that mobile users will face within this context is how to cope with limited amounts
of resources at the end-systems and within the network, under unstable environmental conditions. It is
expected that mobile users will no longer be able to rely on their QoS contracts being supported over the
whole duration of a session by the network infrastructure, due to various reasons like: wireless link
quality degradations, handovers, limited amount of resources. By assuming proper resource overprovision
in the backbone, one can expect that these problems will most likely be concentrated in the access
network, especially in the radio part thereof and even on the end-systems.
Since users typically have business relationships with specific network providers (e.g. a subscription with
an Internet Service Provider (ISP) or a prepaid phone card), two possible types of handover may occur:
•
Horizontal handovers: occur within a given administrative domain of a network provider, and
within the same type of access network;
•
Vertical handovers: occur across two different types of access networks and/or across the
administrative boundary between two network providers.
When dealing with handovers, users must be prepared to face changes in network resource availability,
depending not only on the type of access network, but also on the type of business relationships the users
may have with the various network providers. In some extreme cases, the users might try to access the
network owned by a network provider, with whom the user has no business relationship at all, or which
offers limited amount of resources. Pricing aspects also play a key role.
Within this context, multiparty multimedia applications will need an effective and efficient way of
handling QoS fluctuations at the network layer.
In particular, the sheer negotiation of capabilities (like codecs) is hereby regarded as necessary but not
sufficient for meeting the users' QoS expectations. Intelligent, adaptive applications can in fact provide
predictive QoS on an end-to-end basis only if end-peers are able to negotiate also QoS aspects directly
affecting the application performance, according to the users' QoS expectations. This combined
Page 17
MIND
1.2
information enables applications effectively choosing the best adaptation strategy in reaction to a given
QoS fluctuation [BRA01].
Coping with the aforementioned issues, this document presents a concept for negotiation of capabilities
and QoS at the application level, triggered by QoS requirements of the end-user (the E2ENP concept),
which can be realised by either deriving a new specific protocol, or enhancing existing ones. As an
example of the latter option, a possible E2ENP implementation based on extensions of SDPng [KUT01] ,
[KUT02] and on the use of SIP [ROS01] is also discussed.
2.1.1 E2ENP Terms Definition
Adaptation Path (AP): An ordered set of QoS contracts that end-systems use for employing adaptation
strategies in a pre-planned way. The nominal QoS contract indicates the one the end-system should
preferably try to enforce. Should this not (or no longer) be possible, the AP offers alternative QoS
contracts (and, optionally, specific rules for choosing them) for degrading the QoS level in a controlled
way. Alternatively, by monitoring the system resources and discovering free resources, the AP allows the
respective upgrading of the QoS level by using higher-graded QoS contract/-s.
Application Level QoS: An end-system internal representation of QoS specification (e.g. XML
description) derived from User Level QoS specification. Typically, application level QoS is expressed as
a set of parameters that are subject to negotiation with the peer. Such parameters should, together with the
capabilities to be used, allow a peer to derive parameters necessary for resource management for the local
terminal and for the network. Some examples are framerate, framesize, visual quality and so on.
Capability: The ability to perform certain tasks and/or to handle certain information types. A single
capability is associated with a certain amount of hardware and/or software resources (each handling a
given information type) and can be configured to produce different QoS levels. On the other hand a given
QoS level can be associated with different capability sets (e.g. different codecs can offer the same QoS
level).
Intermediate Components (IM): Any network element situated on the signalling and/or the data path
between two end-systems and which can understand the protocol the end-systems use (at least on the
network level). Examples are: routers, proxies, independent services, etc.
Mediator: The role an end-peer can take for redirecting incoming calls to another end-peer(s) according to
some settings in the user profile. A part of this role is to provide QoS satisfaction for the user(s) in a way
the Mediator itself (considering the end-peer's multimedia capabilities) cannot handle.
Peer: A service or an end-device (associated with an end-user). This term has equivalent meaning with
the terms end-peer and party, which are interchangeably used throughout this document.
QoS change: The change of the QoS contract initiated by the service user or by an application within the
context of a predefined AP.
QoS contract: An agreement between a service user and a service provider, specifying QoS requirements
and constraints, as well as the policies required to keep track of a single QoS level during the given
service execution.
QoS level: A discrete region of the multidimensional QoS space characterising a service. Users perceive
distinct QoS levels as the result of applying certain QoS contracts to the given services.
QoS parameter: A functional representation of a single characteristic of a given QoS aware service (e.g.
network bitrate, network overall end-to-end delay, but also parameters like video frame rate, video frame
size, audio sampling rate, number of audio channels, etc.), which identifies a measurable QoS related
quantity.
QoS profile: A collection of data specifying the end-peer preferences in terms of QoS, concerning the
usage of a given service. The QoS profile is the end-system internal representation of the user's QoS
preferences within a QoS aware system. The QoS profile can contain one or several Application Level
QoS specifications.
Page 18
MIND
1.2
QoS violation: The violation of one or several QoS contracts within an AP, caused by the network and/or
Service Provider and/or local system. The violation indicates a media session state (i.e. resources
consumption), which has not been predefined in the AP.
Transport Level QoS: A set of parameters related to resource management level in the protocol stack and
for controlling access to network resources. Typically such parameters set defines the amount of data the
user is injecting in the network for a given data flow together with the expected treatment that it should
receive on an end-to-end basis within the network.
User Level QoS specification: The QoS as users expect to perceive, eventually expressed in non-crisp
terms by non-expert users. This QoS specification is an application-specific issue, depending on user
interface aspects.
2.1.2 The Concept
This section defines requirements for an efficient end-to-end QoS signalling mechanism for dealing with
multiparty, multimedia services. This concept also embraces the case of multi-streams applications like
online-games combined with A/V sessions.
The "handling of QoS" shall be achieved through the negotiation of hardware/software configuration
information and the negotiation and enforcement of QoS contracts, which are derived from the user
preferences:
•
QoS contract shall capture user's QoS expectations, as well as network provider policies for
enabling a comprehensive QoS adaptation process (this means for instance to control that the
QoS levels fit into the predefined policies, or to control the amount of resources by up/downgrading QoS upon detection of QoS changes / QoS violations);
•
QoS contract shall also capture configuration information concerning network resources, as well
as the resources and capabilities of the involved QoS aware end-systems (for instance, some
codecs like variable bit rate video-codecs can be differently pre-set to produce different QoS
directly perceivable by the user: the sheer definition of codecs is thus not sufficient for
determining the amount of local and network resources to reserve when QoS should be
supported).
Before starting a negotiation, each end-peer shall derive the negotiable QoS contracts from existing
information concerning both users' QoS expectations and type/amount of available resources, by possibly
applying the following refinement/validation process:
1.
Users specify the User Level QoS;
2.
Applications derive Application Level QoS by mapping User Level QoS into QoS
contracts detailing specific aspects (e.g. video frame rate, video frame size, image
quality, etc);
3.
The mapping of Application Level QoS on the end-system capabilities (i.e. the endsystem hardware and software configuration - e.g. supported codecs), originates QoS
contract Sketches, which represent the Application Level QoS that the end-system can
theoretically support;
4.
The validation of QoS contract Sketches against network provider policies for
supporting QoS, originates Validated Application Level QoS contracts. These valid
contracts constitute a common vocabulary, which the local and the remote end-systems
can use for negotiating the establishment of QoS aware communications, and for
efficiently dealing with QoS re-negotiations thereof. Those Application Level QoS,
which have failed the validation, could still be used in special cases like vertical
handovers, dynamic end-system changes (e.g. due to end-system up-/downgrading), etc.
For the sake of simplicity, this document refers thereinafter to "Validated Application Level QoS
contracts" as "Application Level QoS". These are the negotiable QoS contract end-peers are expected to
deal with during QoS negotiations and QoS re-negotiations.
In order to allow end-peers reserving network resource in a coordinated manner, during the negotiation
process the sender side can derive network-level QoS contracts (e.g. the Traffic Information (TI) and
Page 19
MIND
1.2
Sensitivity Information (SI) information presented in [BOS02] ) from the negotiable Application Level
QoS.
2.1.2.1 Coping With Unstable Environment Conditions
In order to allow users achieving QoS with limited amounts of resources at the end-system and in the
network, under unstable environment conditions, the application developers and the users shall be
prepared to increase renegotiation speed, for instance by proactively planning proper actions at
negotiation time. As aforementioned, QoS Contract information is complementary to capability
information. As such, the E2ENP may advantageously negotiate QoS Contracts and capabilities
independently. For instance some codecs might be dynamically downloadable: having negotiated QoS
contracts independently of such codes, allows end-peers saving time (critical aspect of re-negotiations),
by simply referencing the pre-negotiated QoS contracts and binding the newly available codecs with
those contracts.
2.1.2.2 Hierarchical QoS Specification
Grouping streams is mainly useful for allowing QoS aware applications to handle groups as a whole when
balancing quality to resource availability under certain environmental conditions. For instance, in online
gaming applications it can make sense to augment the gaming experience by allowing each player to keep
in audio/visual contact with the other players. To this extent, it is possible to distinguish (and therefore
treat differently) various groups of streams, each grouping all the streams between the given player and
another player. The description of these groups of streams is subject to negotiation.
Furthermore, the developers and the users of multiparty multimedia applications dealing with multiple
streams may advantageously arrange streams by recursively applying the grouping process, based on
high-level criteria aiming to improve resources orchestration among multiple streams. For instance, a
player can arrange the A/V streams by identifying multiple concurrent instances of audio- or
videoconferences, one with the own team members and one with each other team. This optional form of
streams grouping is managed locally by the end-peers (and thus is not subject to negotiation).
The resulting hierarchical structure is topologically equivalent to a tree, where each leaf represents a
stream, and each internal node represents a group of streams (or, recursively, of groups).
2.1.2.3 Inter-stream QoS Constraints
Multi-media applications may deal with multiple streams of different types (i.e. audio, video, and data).
To this extent, users of such applications may wish to specify their QoS preferences for each single
stream, but also any parameter that might determine inter-stream behaviour. Typically, videoconference
applications deal with voice and video streams, which must be synchronised (time synchronisation). If the
media codec and stream format itself does not provide means for synchronising; it is a requirement that
inter-stream correlation information is available and negotiated.
This correlation can be generalised by introducing the specification of QoS constraints applicable to a
given bundle of streams (QoS correlation). The decision of what level of correlation should be enforced at
the QoS level among a set of streams, depends on the scenario and the requirements of the application.
The introduction of the time synchronisation and QoS correlation aspects augment the overall possibilities
to specify and manage QoS within a QoS aware system.
2.1.2.4 Planning Counteractions Ahead
A possible way to cope with otherwise unpredictable events resulting from QoS changes / QoS violations,
is to enable the mobile users' applications to efficiently and timely react to those events, by planning
proper counteractions ahead, in a coordinated manner with the remote end-peers. In this manner,
whenever QoS changes / QoS violations occur, agreements on how to most effectively adapt to the
mutated conditions can be timely reached among the peers.
These counteractions include:
•
Negotiating multiple alternative QoS levels for a stream;
Page 20
MIND
1.2
•
Negotiating multiple alternative QoS levels for a group of streams, to capture time
synchronisation, QoS correlation, and other inter-stream QoS constraints;
•
Co-ordinating local-, remote-, and network-resource management.
2.1.2.5 Independence from Network Aspects
The end-peers are in general connected over one or a multiplicity of interconnected networks, including
also IM. In terms of SIP the SIP-proxies are considered as IM. The IMs as such are in position to inspect
and change the passing through them protocol payloads thus interfering with protocols like E2ENP, e.g.
such SIP based proxies are the 3rd Generation Partnership Project (3GPP) proxies [3GPPSIP] (see also
for details Chapter 4). E2ENP is supposed to operate based on an abstraction of the underlying network
and in order to provide real end-to-end negotiation and conformance of the so delivered QoS information,
E2ENP defines some behaviour rules and restrictions on the IMs functionality.
Since the IMs offer services that not only may influence the information that end-peers eventually
negotiate via E2ENP, but also may enforce the results of the E2ENP process, IMs should be informed
about the decision made by the end-peers.
IMs may be informed by providing them with some standard-profile information before the start of
E2ENP, and/or by publishing the agreed QoS contracts, e.g. via a directory service.
In order to satisfy the user QoS expectations and the network provider QoS policies, the following is
suggested:
•
The E2ENP should be able to be used in combination with (but independently from) IM, which
may result effective in preparing and/or guaranteeing the QoS contracts agreed by the end-peers;
•
The exchange of information (e.g. profiles, security, authentication, provider policies, etc.) not
directly affecting the E2ENP-process, rather influencing the information that is going to be
negotiated, should be carried out before the E2ENP starts.
In general the flows carrying E2ENP messaging (the signalling-path) and the flows carrying the actual
streams (the data-path) could be routed differently, depending not only on network-related issues, but also
on application/service specific reasons. Thus the E2ENP signalling-paths and the corresponding datapaths between any two given end-peers should be in general considered different.
Every time a signalling-path and/or data-path is built, there may be some IMs (proxies, directory services,
etc.) located along the path, whose usage is application-specific, and which might "understand" some of
the protocols used by the end-peers. Some of these entities might thus be able to "interfere" with the
E2ENP, thus disrupting the very "End-to-End" nature of the E2ENP. In order to avoid this threat, it is
suggested that:
•
With respect to the E2ENP, Intermediate Components should operate based only on information
provided - directly or indirectly - by the peers, in order to carry out application specific tasks;
•
Exception cases when the involvement of the IMs is inevitable, should also be considered. Thus
the IMs should be allowed to interfere with the E2ENP only by explicitly notifying the end-peers
about the occurred problems, and only when end-peers misbehave, e.g. by disregarding system
policies and/or in case of system failure conditions.
2.1.2.6 Mapping of the Quality Settings on Codec Definition
When user-defined audio quality settings are associated with codecs according to the standard static
payload-type definitions of the codecs [SCH01] , each QoS level can be mapped to one audio payload
type expressing such QoS level. On the other hand a single variable bit rate video-codec can produce
multiple QoS levels with respect to the quality of the single video frame and - in some cases - the quality
of the colour of a single frame.
A user-defined QoS level can be applied to a video by defining a compression percentage for the
performance of the video codec. However, some video codecs have different number of compression
levels. When an application based on the users requirements selects a constant video quality and accepts a
variable bit rate coder, the application would derive from the QoS level "visually perceivable quality =
Page 21
MIND
1.2
X", an unique number expressing the compression level for the video codec. Thus, in order to better apply
QoS settings to a codec, it is suggested that:
•
Applications should share a numbering range for the user perceivable quality specification
(overall “visual quality” and eventually, if applicable, “colour quality” – i.e. some codecs do not
support “colour quality”), in order to be able to uniquely map video quality to a given codec;
•
The numbering range for the user perceivable quality specification should have enough
resolution to uniquely map to the compression levels of a given codec.
2.1.2.7 Third-Party-Assisted Negotiation
End-peers may leverage services like directory, allocation, presence, etc. for redirecting connections over
alternative end-systems, which can more appropriately meet users' QoS expectations because of more
appropriate capabilities.
In these cases, end-peers should be able to negotiate on behalf of other end-peers, according to specific
user profile information. This type of negotiation is called third-party-assisted negotiation. By third-partyassisted negotiation a pure Mediator should only facilitate the delegation of a connection without actively
taking part in it.
2.1.3 The Features
To cope with QoS Violations and/or QoS Changes, peers normally engage in QoS negotiations and
renegotiations processes. More specifically, we name End-to-End QoS Full Negotiation the process that
peers perform - either before or at the actual start of a session - in order to agree on a given QoS-level to
be enforced for the given session and streams, eventually by redefining some of the originally proposed
configurations of QoS specifications, coming from previously performed negotiations (further also named
pre-negotiations). By End-to-End QoS Full Re-Negotiation we refer to the process that peers trigger upon
detection of either QoS Changes or QoS Violations, in order to agree on a given QoS-level to be enforced
for the given session and streams, eventually by redefining some of the originally proposed configurations
of QoS specifications.
As aforementioned, BRENTA allows peers pro-actively negotiating APs among themselves before the
actual media streams are established, in order to effectively and efficiently react to QoS Violations and/or
QoS Changes, whenever these occur. To this extent, the E2ENP is an application-level protocol that
BRENTA Applications Type C or BRENTA QoS Brokers can use for co-ordinating with peer ones. The
E2ENP allows mobile peers to cope with unstable environment conditions, by enabling their applications
to efficiently and timely react to QoS changes and/or violations, by pre-planning the possible
counteractions ahead.
The E2ENP allows peers negotiating off-line APs for each level of the aforementioned tree model, so that
at runtime they can perform negotiation and re-negotiations by simply exchanging QoS Contract
identifiers. The E2ENP is based on a non-iterative negotiation process, whereby peers simply exchange
among themselves information on a set of pre-negotiated APs.
Furthermore, the E2ENP includes a specific procedure for effectively enforcing QoS contracts, by
applying the so-called “Economy Principle”. According to this principle, local and peers' resources are
reserved before any network resource reservation is made. This is motivated by the fact that network
resources are shared among a multiplicity of users, and thus are more expensive than terminal resources.
The E2ENP comprises four key phases, which can be concatenated within the lifetime of a given session.
Alternatively, the first two phases may be executed independently of the latter two and at different times,
but strictly following the given order. More specifically, the phases are:
•
End-to-End QoS Pre-Negotiation Phase
Peers perform this phase before the actual start of a communication session, and independently
of the session itself, in order to reach an agreement on which capabilities (i.e. codecs and QoS
mappings of those codecs) peers should later use for a media session. Peers are thus able to
establish a common vocabulary (i.e. the common capabilities and QoS setups), a priori of any
specific business (i.e. media session). Thus the peers express their basic possibilities and wishes
for supporting any media session in the future. During this phase, the negotiation initiator (the
Page 22
MIND
1.2
offerer) proposes a bid to the negotiation responders (the answerers), which in turn reply with a
counteroffer (i.e. a subset of the proposed bid coming from the offerer).
•
Multi-stream QoS Correlation and Time Synchronisation Enforcement Phase
An optional phase concerning the establishment of dependencies among the multiple streams of
a given multimedia session. A given peer applies this phase only if QoS correlation and/or time
synchronisation constraints are required. A central control entity (e.g. a conference call bridge)
could also employ this phase, should the various peers agree upon delegating such entity to carry
out complex negotiations.
•
End-to-End QoS Compact Negotiation Phase
Peers can perform this phase either before or at the actual start of a session, in order to agree on
how the QoS APs at the different QoS abstraction levels (e.g. stream, group of streams, etc.) look
like for this specific session and about which QoS-level to enforce for the given session and
streams, based on results of previously applied phases. This Compact Negotiation is
considerably quicker compared to the case of an End-to-End QoS Full Negotiation process, since
only references of pre-negotiated information are actually exchanged among the peers. At
completion of this process, peers have agreed upon the QoS Contracts that they are going to
enforce.
•
End-to-End QoS Compact Re-Negotiation Phase
Peers can trigger this phase upon detection of QoS Violations or QoS Changes, so as to agree on
a new QoS-level to enforce for the given session, based on results of a previously applied Endto-End QoS Pre-Negotiation / End-to-End QoS Negotiation. This process is considerably faster
compared to the case of the End-to-End QoS Full Re-Negotiation one, since only references of
pre-negotiated information are actually exchanged among peers. This phase can be applied
several times during the lifetime of any given session. In cases of QoS violation the End-to-End
QoS Compact Re-Negotiation Phase delivers eventually new additional capabilities and updated
APs descriptions in order to adapt to the unexpectedly occurred environmental changes, due to
both upgrading or downgrading of the capabilities of the end-peer or due to network throughput
fluctuations, which have not been taken in account in the previously negotiated capabilities and
APs.
The payloads of the three initial key phases of E2ENP result in End-to-End QoS Full Negotiation
payload. End-to-End QoS Full Negotiation is performed before or at the actual start of a multimedia
session. The combination of the payloads of all E2ENP phases result in End-to-End QoS Full ReNegotiation payload. End-to-End QoS Full Re-Negotiation is performed within the lifetime of a running
multimedia session.
The E2ENP interacts with the resource management functions during all the four phases. More
specifically, the E2ENP interacts with the local and network resource management functions during both
the third and forth phase, according to the "Economy Principle". The rules for handling the
joining/leaving of peers to a conference service are heavily dependent on the type of management applied
to the given communication sessions. This can eventually involve external mechanisms and protocols,
which are outside of the scope of the E2ENP.
The E2ENP is envisioned to be implemented as an application level protocol for both peer-to-peer and
multiparty scenarios, by considering existing models [ROS03] . A possible E2ENP implementation can
be realised by combining special extensions of SDPng [KUT02] with a particular use of SIP. The idea is
to use a new specific extension of SDPng for modelling the E2ENP information, and to piggyback such
information on SIP PDUs [ROS01] .
The following list indicates the proposed SDPng extensions.
•
An important part of the implementation is the use of modularity for the elements by applying
SDPng and extensions of it. This would enable to use SDPng with and without the new
extensions.
•
The modularity of the SDPng extensions should enable the end-to-end negotiating parties to
quickly reach agreements on common codecs, payload types and codec parameterisations thus
possibly optimising the decisions on commonly supported QoS contracts.
Page 23
MIND
1.2
•
For describing the QoS contracts it is necessary to have SDPng elements for mapping the
Application Level QoS descriptions onto the codecs and the payload types. A single QoS
contract would be in these terms the QoS settings of a single media stream.
•
It is suggested to enrich at the sender side the negotiated Application Level QoS contracts with
the TI and SI information presented in [BOS02] , for allowing the end-peers to perform resource
reservation in a coordinate manner.
•
It is necessary to distinguish between the different streams (audio, video) and data types (data,
control) in the definition of the QoS contracts for a communication session.
•
Considering the video codecs, the parameterisation indicated in [SCH01] is not sufficient to fully
characterise the given codec from a QoS perspective. That is why it is necessary to introduce
codec parameterisation attributes like frame-rate, frame-size, colour-quality-range, overallquality-range, etc. which should be uniquely interpreted by the end-systems.
•
It is necessary to introduce descriptions and parameterisations for non-streaming data.
•
It is necessary to provide means for managing user, system, and provider policy information at
least by defining which of the proposed QoS contracts the QoS aware system may support
during a negotiation.
•
For defining APs new SDPng elements are needed for formally configuring the adaptation
process correspondingly, in accordance with the envisioned QoS changes and/or violations.
•
For defining stream grouping it is necessary to introduce new SDPng elements with respect to
(eventually hierarchical) group definition, and QoS correlation / time synchronisation aspects.
The following SIP features for implementing the E2ENP processes are identified:
•
Signalling for carrying out the pre-negotiation, negotiation and re-negotiation.
•
Means for co-ordinating resource management among multiple parties (common example given
in [MAR02] ).
•
Transporting and recognising the E2ENP content expressed as SDPng content.
We have followed and participated to the discussion in the IETF Multiparty Multimedia Session Control
Working Group (MMUSIC WG) concerning QoS and capability negotiation and the on-going SDPng
specification. However, in our work we drafted a specification based on an original use of SDPng, which
partially diverges from the current status of the discussion in MMUSIC. We took this decision, for the
sake of explaining the E2ENP concepts in more concrete terms, without waiting for the SPDng
specification to be finalised. To this extent, we plan in any case to harmonise our specification with the
final SDPng version, or even contribute to the preparation thereof, once the E2ENP concepts will have
been properly reviewed after a necessary testing phase.
2.1.4 Related Work
This section discusses existing solutions and/or proposals in the field of QoS aware end-to-end
negotiations, and highlights the shortcomings of the respective existing signalling mechanisms (in-band –
Real Time Transport Control Protocol (RTCP), out-band – SIP) and description methods (SDPng) for
QoS.
The authors of [SCH01] and [PER97] describe possibilities of quick re-negotiations via in-band
signalling. However this kind of signalling concerns only change of codecs and the redundant support of
differently coded media without considering the respective effects when QoS should be supported.
The authors of [MAR02] and [MAR01] present a multi-phase call-setup mechanism that makes network
QoS and security establishment a precondition to sessions initiated by the SIP and described by the
Session Description Protocol (SDP). Thus the resource management is done only for the network
resources. However [MAR02] , [MAR01] do not consider pre-negotiation of QoS and the integration of
local and peer resource management.
The authors of [ROS02] describe a complete model for one-to-one capability negotiation with SDP.
However this model has problems by the definition of mutually referred information and information on
Page 24
MIND
1.2
grouping streams because of the flat structure of the SDP. Additionally this model concerns only
capability negotiation but no QoS support and QoS adaptation.
Ongoing work in [KUT01] identifies the requirements of a framework dealing with session description
and endpoint capability negotiation in multiparty multimedia conferencing scenarios.
Depending on user preferences, system capabilities, or other constraints, different configurations can be
chosen for the conference. The need of a negotiation process among the end-peers for determining a
common set of potential system configurations and for selection of one or many common configurations
to be used is identified, but not described. The authors of [KUT01] also identify the need for network
resource reservation coupled with session setup.
The proposal in [KUT01] deals only with capability negotiations and does neither consider a negotiation
protocol for determining a common set of QoS configuration nor integrate local, peer and network
resource reservation.
The most recent versions of SDPng proposal [KUT02] provide detailed XML Schema specification and a
prototype of the Audio Codec and Real Time Transport Protocol (RTP) Profiles. Additionally [KUT02]
describes a capability negotiation process for establishing of a common capability vocabulary between
end-peers. However the proposal in [KUT02] still does not consider the QoS specific issues.
In [BOS01] an End-to-End User Perceived Quality of Service Negotiation is described, with the
assumption that some IMs and services may strongly be involved in the end-decision about the negotiated
QoS information of the end-peers. The decision about QoS configurations in [BOS01] may be taken over
some standard "contract types". Although [BOS01] mentions that signalling and data packet may flow
along different paths throughout the network, the authors of [BOS01] suggest that some IMs along the
negotiation path may influence the negotiation, though in general having nothing to do with the data.
According to such a protocol model the network is not transparent.
The negotiation process presented in [BOS01] does not allow incremental negotiations, and furthermore
[BOS01] leverages static APs with fixed transitions among capability configurations/network-level QoS
contracts only.
The model of [BOS01] suggests negotiations of QoS only at stream level without considering some
stream dependencies like groups and stream hierarchies.
The most recent work on the problem of User Perceived QoS [BOS01] introduces SDPng schema for
defining traffic throughput and sensitivity information. This information considers only the network
reservation process without taking in account the necessity for local (peer) QoS specific configurations
and reservations. The model in [BOS02] is not taking in account the Application Level QoS definitions,
with respect to codec configuration and a flexible adaptation process. However the E2ENP can
incorporate this proposal, by allowing senders to derive TI/SI from Application Level QoS contracts, and
to forward this information as part of a proposal/counter-proposal to the receiver(s). The model of
[BOS02] is static in terms of adaptation, insofar as it reuses the fixed prioritisation of alternative options
derived from SDP, thus losing the powerful flexibility featured by XML. The description of the payload
types in [BOS02] is not in accordance with the payload types as described in [SCH01] , since the codec
parameterisation of the audio codecs is already pre-defined for the static payload types. One interesting
aspect in [BOS02] is the introduction of QoS Class format as a form of predefined interoperable
application level QoS definition. However such a definition would also need high level QoS specification
considering the usage of different possible QoS configurations of a single codec/payload type.
Recent discussions between the authors of [BOS02] and MIND representatives paved the way for a new
proposal [ROJ02] , which partially takes into the account the aforementioned differences between the
MIND approach and the [BOS02] one.
Section 2.1 describes the QoS negotiation protocol being proposed in MIND. The following section
describes some implication for potential realisation of the abstract service interface between the
application oriented, SIP supporting E2ENP and the network infrastructure.
Page 25
MIND
1.2
2.2 Service Interface Implications
We will describe how to map the Enhanced Socket Interface (ESI) service primitives to function calls
defined in widely used Operating Systems (OSs), e.g., Linux and Microsoft Windows, to request QoS
service provision. This is necessary to identify the viability of future implementations of ESI. ESI is a
service interface used by applications to request QoS support independent of the network QoS
architecture, system platform and transport service provider. ESI is a flexible interface allowing
applications to request Soft and Hard QoS support, i.e., to request QoS in qualitative and quantitative
ways. The last requires the use of an end to end signalling to reserve the resource requested by
applications along the network, and the former basically depends on a previous agreement of the transport
provider to deliver the data based on a per hop behaviour.
We developed the mapping of ESI functions based on Windows and Linux systems due to their
popularity and the availability of related information. Actually, both operating systems are installed in
almost different kind of terminal systems (fixed, portable and mobile) and dominate a considerable
market place. Therefore, we start the section analysing how the QoS is offered in both OS and which
interfaces were developed to provide Hard and Soft QoS on both platforms, e.g. Generic QoS (GQoS),
Linux Traffic Control (TC) and Resource Reservation Protocol Application Programming Interface
(RAPI). Finally, we describe in detail the ESI service primitives and perform the mapping between these
service primitives and the Linux and Windows functions.
2.2.1 QoS support in Linux OS
As mentioned in the introduction, the QoS support in Linux is based on some basic components that
(together) define how the outgoing packets must be treated. Figure 2-1 shows how the kernel handles
packets received from the network or from the upper layers. If the terminal is acting as a router, each
incoming packets are examined and then forwarded to the network on a different interface, or they are
passed up to the higher layers in the protocol stack if the terminal acts as an end system. These layers may
also generate data units on their own and send to the lower layers for further processing (encapsulation,
routing and transmission). Forwarding process in the figure includes the selection of the next hop,
encapsulation, selection of the output interface, etc.
Once the forwarding process is done packets are queued on the corresponding output interface and this is
the point where traffic control acts. Traffic Control decides if packets are queued, the order in which the
packets are sent (it depends on the priority of certain flows), delay the emission of the packets (to limit
the transmission rate) or if they are dropped, etc. Once traffic control releases a packet for sending, the
device driver emits it on the network.
Input de-multiplexing
Upper Layers
Traffic Control
Forwarding
Output queuing
Figure 2-1 The Packet Flow in the System
Each network device has a queuing discipline associated to specify how enqueued packets must be
treated. Elaborate queuing disciplines may use filters to distinguish among different classes of packets
and process each class using prioritisation. Figure 2-2 illustrates a complex queuing discipline with to
delay priorities. Packets which are selected by the first filter are go to the high-priority class, the rest of
the packets go to the low priority-class. The packets in the high-priority queue are sent before the packets
in the second queue. The first queue implements a token bucket filter to enforce a rate of high-priority
packets at fixed rate, e.g., 2 Mbps. It allows a more fair usage of the outgoing bandwidth. The rest of the
packets are enqueued by a First In First Out (FIFO) queueing discipline.
In general, packets are enqueued using the enqueue function of a queuing discipline. It runs one filter after
the other until one of them indicates a match. Then, it queues the packets for the corresponding class
(usually it means to invoke the enqueue function of the queuing discipline of the filters “owned by that
class”. Packets that do not match any of the filters are typically related to some default class.
Page 26
MIND
1.2
Network Interface
TCH_H_ROOT
TCH_H_INGRESS
1:0
Filter
Queuing Discipline 2:0
(TBF, “High priority traffic”)
Class 1:1
1:1
Filter
Queuing Discipline 3:0
Filter
(FIFO, “Low priority traffic”)
Class 1:2
Queuing Discipline 1:0
1:2
Top level Queuing Disc. on egress
TCH_H_ROOT
TCH_H_INGRESS Ingress Queuing Discipline
Point of insertion of Class
Point of insertion of Queuing Discipline
Figure 2-2 An Elaborate Queuing Discipline with Multiple Classes
One of the advantages of the QoS support in Linux is the flexibility with which the combination of
queues and classes can be set up, i.e., each discipline queuing may have different number of classes; these
classes don’t store packets by their selves, but instead, use another queuing discipline for this purpose,
which in turn, may have a number of classes and so on.
2.2.1.1 Queuing Discipline
In Linux OS, each network device has a queue associated with it. There are a dozen of queuing
disciplines supported in Linux, some of them are: Priority, First In First Out (FIFO), the queuing
discipline by default; Class Based Queue (CBQ), Token Bucket Flow (TBF), Clark-Shenker-Zhank
(CSZ), Traffic Equaliser (TEQL), Random Early Detection (RED), Asynchronous Transfer Mode (ATM),
etc.
Queuing disciplines and classes are tied. The presence of classes and their semantics are fundamental
properties of the queuing disciplines. Filters, in contrast, can be arbitrarily combined with queuing
disciplines and classes.
Each queuing discipline uses a set of functions to control its operation. Enqueue, dequeue, requeue and
drop functions handle the packets in the queue. Init, change, reset, dump and destroy functions are used
for the initialisations, change, diagnostic and removal of the queuing discipline.
Instances of queuing disciplines are identified by 32-bit numbers split into a major and minor numbers of
16 bits each one (usual notation is major:minor). The minor number is always zero for queuing disciplines
with the exception of ingress queuing disciplines (ffff:fff1). Major numbers must be unique per network
interface, but there may be some other queuing discipline with the same number on other interface. The
user should assign a major number in the range 1 to 7fffh; major number 0 means unspecified and a major
number out of the range is automatically allocated by the kernel. When creating a queuing discipline the
message sent to the kernel contains the identification number and parent (the insertion point). The value
of the insertion point can be one of the special values for the top level queuing discipline on egress or for
the ingress queuing discipline, or can be the number of an existing queuing discipline.
2.2.1.2 Classes
As mentioned before, queuing disciplines and classes are tied to one another. When enqueue function is
called, the queuing discipline applies the filter to determine the class to which the packet belongs, then, it
calls the enqueue function of the inner queuing discipline that is owned by this class. Classes are identified
by the Class ID and the internal ID. The Class ID is of the type u32 and it is assigned by the user. It is
structured as major:minor with the major number corresponding to their instance of the queuing discipline,
and the minor identifying the class within the instance (it can be in the range 0 to ffffh). The Internal ID is
Page 27
MIND
1.2
of type unsigned long and it is assigned by the queuing discipline and is unique within the queuing
discipline. Like queuing disciplines, classes have parents.
Queuing disciplines with classes provide some functions to manipulate classes: graft, leaf, change and delete
are some of the functions used to manipulate the classes within the queue disciplines that support classes
(some of them do not support classes).
2.2.1.3 Filters
Filters are used by a queuing discipline to assign incoming packets to one of its classes. Filters classified
packets based on certain properties of the packet: Type of Service (TOS) byte, IP addresses, port
numbers, etc. These are kept in filter lists that can be maintained per queuing discipline or per class (it
depends on the design of the queuing discipline). The filter list is ordered by priority in ascending
ordering and the entries of the list are keyed by the protocols for which they apply like User Datagram
Protocol (UDP), Transmission Control Protocol (TCP) and Internet Protocol (IP), etc. Filters for the same
protocol on the same filter list must have different priority values.
Filters may have an internal structure compound of elements that are referenced by a handle of 32 bits
long. Handle 0 points to the filter itself. Filters, like classes, have an internal ID of unsigned long. Handles
and internal IDs are unique per filter instance and the internal organisation of a filter can be arbitrary.
Different from classes, filters or their elements have no identifiers that refer directly to a specific filter or
element on an interface. The class identifies them or queuing discipline for which they are registered, the
protocol, their priority among filters or the handle in the case of filters elements.
The classification of packets is activated when the enqueue function of a queuing discipline is invoked.
Then, the protocol to which the packets belong to is determined and the filters corresponding to this
protocol are applied in order of priority. Within each filter all the internal elements are traversed in an
attempt to classify the packets. If the packet is classified, the enqueue function of the queuing discipline
owned by the class is invoked. This process is shown in Figure 2-3.
MATCH
NO MATCH
Queuing Discipline / Classes
Filter priority 1
Filter priority 2
Element Handle = A
Element Handle = X
Element Handle = B
Element Handle = Y
OK
UNSPECK
Figure 2-3 Matching a Structure of Filters (each filter with a list of elements)
There are to types of filters, these are based on the scope of the packets their instances can classify:
generic and specific filters. The former only needs one instance of the queuing discipline to classify
packets for all classes; the latter need one or more instances of a filter or its internal elements per class to
identify packets belonging to this class.
Filters are controlled by functions like init (initialise), destroy (remove), change (modify properties),
classify (performs the classification), dump (diagnostic), etc.
Page 28
MIND
1.2
2.2.1.4 Policing
Policing is used to monitoring if the user is acting according the contracted QoS services, i.e., his traffic
does not exceed certain bounds. In Linux, four type of policing mechanism are implemented: policing
decision by filters, refusal to enqueue a packet, drop a packet from an inner queuing discipline (e.g., in
order to create space for packets of a more important class in CBQ queuing discipline) and drop a packet
when enqueuing a new one (i.e., older packet is discarded to make space for a new packet).
2.2.1.5 Traffic Control ‘tc’
Traffic Control ‘tc’ is the user level program used to manipulate individual traffic control elements, i.e., to
create and associate queues with the output devices in Linux, to set up various kinds of queues and
associate classes with each of those queues and it can also is used to set up filters based on the routing
table, u32 classifiers, Resource Reservation Protocol (RSVP) classifiers and others. As already
mentioned, it uses netlink sockets as a mechanism to communicate with the kernel networking functions.
The usage for tc is:
tc [ OPTIONS ] OBJECT { COMMAND | help }
where
OBJECT := { qdisc | class | filter }
OPTIONS := { -s[statistics] | -d[details] | -r[raw] }
The Object could be a queuing discipline(qdisc), class(class) or a filter(filter).
Figure 2-4 shows a diagram of the tc implementation [VM00] . The interface between the kernel and the
user space is achieved using netlink sockets. rtnetlink is used to exchange traffic control objects between
the user level and the kernel level. rtnetlink is based on netlink. At boot time, a device list (for all queuing
disciplines supported by the system) and all filters supported by the system are initialised. When a user
issues a tc command such as “tc qdisc add …” “tc class add ...”, netlink sockets are opened with the
kernel and the parameters are sent as rt_attributes.
/root > tc qdisc add dev eth0 ...
user application
write(...);
request/reply
user
kernel
Netlink socket
Traffic
Control
eth1
TCP
device
driverin
devin
IPin
IPout
Devout
device
driverout
eth0
Inet socket
ingress
Figure 2-4 The Operation of tc
The control is finally transferred to rtnetlink_rcv() routine which calls the required routines in the kernel
to set up the queues, classes and filers. These routines acknowledge the request through netlink_ack().
tc does not provide a programming interface, it provides the socket interface. To provide a programming
interface (API) in Linux it is possible to provide system call interfaces to set up queues, classes and filters
[VM00] . A system call is the transmission of a process from user mode to system mode. When a user
Page 29
MIND
1.2
issues a system call, the process goes into system mode and executes in the kernel mode (system mode)
and returns back to the user mode, in other words, a system call maps a user call to a kernel function
which does something on user’s behalf and returns control to the user.
2.2.1.6 Framework for QoS Developing in Linux
Figure 2-5 shows how elements of Linux traffic control (classes, filters, queuing disciplines and policing
mechanism) are related to the architectural models of QoS developed in the Working Groups of Internet
Engineering Task Force (IETF) [ALM98].
For the design these QoS architectures in Linux some new components must be added if required closely
following the original design. For example, a design of Differentiated Services in Linux [ALM99]
required three new components: a queuing discipline to extract and to set Differentiated Services Code
Points (DSCP), a classifier which uses this component and a new queuing discipline (Generalized RED).
There are some RVSP implementations in Linux [BER99] for IPv4 and IPv6 based in its QoS support
components.
2.2.1.6.1 Diffserv extensions to Linux traffic control
The traffic control framework explained above offers most of the functionality required for implementing
the support to Differentiated Services (DiffServ) and Integrated Services (IntServ) architectures.
In Linux Traffic Control some extensions were necessary to support DiffServ following the existing
design of TC. This component were new queuing disciplines (sch_dsmark and sch_gred), a new classifier
(cls_tcindex) for interior nodes of a DiffServ domain and a new field (tc_index) to the packet buffer
descriptor where the result of classification of packets is stored.
DiffServ is one of the two actual QoS architecture. It is based on a field carried by packets in the IP
header. This field is called Differentiated Services Code Point (DSCP).
Classification
IntServ node
Metering
Queuing / Scheduling
Meter
Classifier
Packet Scheduler
Flows
Meter
DiffServ Traffic
conditioner
Classifier
DiffServ node
(BA)
Classifier
Marker
Shapper / dropper
(Behavior) Aggregates
Classifier
Linux Kernel
Traffic Control
Queuing/Sched.
Mechanism
Filter
Police
Class
Figure 2-5 Relation of Elements of IntServ and DiffServ Architecture to Traffic Control in Linux
Page 30
MIND
1.2
PHB
Classifier
& Meter
PHB
Marking
PHB
PHB
Figure 2-6 General DiffServ Forwarding Path in a Node
DiffServ applies different transmission and forwarding behaviours depending on which DSPC a packet
carried, i.e., when packets arrive or entry to a DiffServ domain, the ingress node will have to policy,
shape and/or mark those packets before the transmission of the packet to the next hop. Marking, in this
context, refers to assigning a value to the DSCP field. This will be the mark/value that the internal nodes
on the domain will look at to determine which behaviour or QoS level applies. DiffServ doesn’t take care
of individual flows, instead of this, it performs flow aggregation by means of the DSCP field applying
different per hop behaviours to each flow aggregation.
The general structure of the forwarding path in a DiffServ node is shown in Figure 2-6. In a DiffServ
domain the nodes could be boundary or interior nodes. Each class of node performs classification when
packets arrive. The result of classification may be used in different places along the DS process before the
packet is released to the network, therefore, the DiffServ code of Linux supplies a structure called sk_buff,
including a new field called skb->tc_index where the result of initial classification is stored to be used in
several points in DS treatment. The skb->tc_index value will be initially set by the sch_dsmark queuing
discipline, retrieving it from the DSCP field of every received packet. In addition, a classifier will read all
or part of skb->tcindex value and will use it to select classes. The classifier used in an interior node is
cls_tcindex. In boundary nodes and hosts micro-flow classifications must be done using multi-field
classifiers, e.g., cls_rsvp or cls_u32. Finally, the Generalized Random Early Detection (GRED) queuing
discipline (sch_gred) provides a configurable number of drop priorities which are selected by the lower
bits of skb->tc_index.
Buffer of packets (skb)
IP header
Initial DS field marking
(remarking)
Skb->tc_index
Initial value of tc_index
cls-rsvp
(microflow
classifier)
TOS field
sch_gred (GRED queing discipline)
sch_dsmark
(queuing discipline)
Skb -> tc_index
Figure 2-7 Micro-flow Classification in DiffServ Sources
Figure 2-7 shows the traffic control process using sch_dsmark (diffserv marker) for the initial packet
marking when entering a DiffServ domain, e.g., when applications send packets. The classification and
rate control is performed by a micro-flow classifier cls_rsvp, in this case, which is designed to identify
RSVP flows. This classifier determines the initial TC index which is then stored in skb->tc_index.
Subsequently, further processing is performed by an inner queuing discipline. Note that this queuing
discipline may read and even change skb->tc_index.
When a packet leaves sch_dsmark, skb->tc_index is examined and the DiffServ field of the packet is set
accordingly.
Page 31
MIND
1.2
In Capable-capable sources, as in ingress routers, any classification and traffic conditioning can be
administratively configured. An application may choose to mark packets when they are generated, e.g., it
can be done using the IP_TOS socket option available on Linux. An application’s choice of DS field values
can always be refused or changed by traffic control before a packet reaches the network (remarking).
A normal recipe for creating a configuration is found in [HUB02]: first, attach sch_dsmark to the output
interface, then define the structure of the queuing discipline(s) inside sch_dsmark; number the classes and
decide on a numbering scheme to use for skb->tc_index; identify which packets go to which classes and
configure the classifier(s) of sch_dsmark accordingly.
2.2.1.6.2 IntServ extensions to Linux traffic control
Integrated Services (IntServ) is the other protocol architecture, developed by the IETF, to provide QoS
over the Internet. The term IntServ [BRA94] means for an Internet Service model that includes best-effort
service, real-time service, and controlled link sharing. Controlled link sharing allows dividing traffic into
a few classes and assigning to each a minimum percentage of the link bandwidth under conditions of
overload, while allowing unused bandwidth to be available at other times.
IntServ requires applications to signal their service requirements to the network through a reservation
request. Currently it uses Resource ReSerVation Protocol (RSVP) [BZ97] as its end-to-end signalling
protocol. Using RSVP, packets passing through a gateway host can be expedited based on policy and
reservation criteria arranged in advance. Unfortunately, the IntServ/RSVP architecture does not scale to
the global Internet.
The RSVP protocol is used by a host to request specific QoS from the network for particular application
data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s)
of the flows and to establish and maintain state to provide the requested service. These requests will result
in resources being reserved in each node along the data path. The protocol performs the signalling
necessary to make a resource reservation for a simplex (unidirectional) data flow sent to a unicast or
multicast destination address. Since it distinguishes senders from receivers, the same application may act
in both roles. RSVP assigns QoS to a specific multipoint-to-multipoint data flow known as a session. A
session is defined by a particular transport protocol, IP destination address, and destination port. A
sender, a data source, is defined by an IP source address and a source port. A given session may have
multiple senders and multiple receivers if the destination is a multicast address.
QoS requests are made by the receivers and it contains a flowspec together with a filter spec. The
flowspec includes an Rspec, which defines the desired QoS and is used to control the packet scheduling
mechanism in the router or host, and also a Tspec which defines the traffic expected by the receiver. The
filter spec controls packet classification to determine which sender's data packets receive the
corresponding QoS.
The fundamental design of the RSVP protocol is based upon research performed in 1992-93. The
Information Sciences Institute (ISI), funded by the US Defense Research Projects Agency (DARPA),
performed research, development, and technology transfer on RSVP, providing more of the ideas turned
into the practice on the Internet. The ISI implementation of RSVP contains code for a workstation used as
a host or router. It includes an RSVP daemon program (rsvpd), an RSVP API (bellow introduced), RSVP
interfaces for some multicast applications and some test tools. This code has been ported to a variety of
system platforms like Linux [ALE99]. The ISI implementation has been the basis for a variety of
implementations [GF98].
The RSVP Application Programming Interface (RAPI) [BH98] is an Application Programming Interface
(API) that allows an application to request enhanced QoS to a local RSVP control program, usually a
user-level daemon program. The latter will use the RSVP protocol to propagate the QoS request through
the routers along path(s) for the data flow. Each router may accept or deny the request, depending upon
its available resources. In the case of failure, the local RSVP control program will return the decision to
the requesting application via the API. The RAPI is based on a client library linked with the application
and the procedures of the RSVP client library module interact with the local RSVP daemon program
through a Unix-domain socket.
With the use of RAPI, an application uses calls to define a session for sending a single unidirectional data
flow or receiving such a data flow, to register as a data sender and/or to make a QoS reservation as a data
Page 32
MIND
1.2
receiver, also, the application can close the session and delete all of its resource reservations. As before
mentioned, RSVP performs the signalling necessary to make a resource reservation for a simplex data
flow sent to a unicast or multicast destination address. Although, the same application may act in both
roles as RSVP distinguishes senders from receivers.
Host
Application
RSVP Client
Library (rutines)
RSVP daemon
RSVP daemon
RAPI
User
Kernel
Router
Unix pipe
Data
RSVP messages
Classifier
& Scheduler
Data
RSVP
Classifier
& Scheduler
Data
Figure 2-8 RAPI’s Implementation Model
There are three protocol interfaces involved in invoking RSVP via the RAPI, each one identified by the
corresponding term in its code:
•
Procedure Call Interface to Application: The procedure call interface to applications and the data
structures use the term “RAPI_” in that interface. All the procedures used are included in a
library routine librsvp.a (compiled form rapi_lib.c and rapi_fmt.c).
•
Application to Daemon Protocol interface: the code for the local protocol across the Unix socket
between the librsvp.a routines and the RSVP daemon rsvpd uses the term “API_”.
•
RSVP Protocol: In the Internet, the RSVP protocol is used between RSVP daemons.
These interfaces are logically independent; therefore they can be modified separately. Figure 2-8 shows a
diagram of RAPI’s implementation model.
The defined function calls of RAPI are the following (the application should include the file rapi_lib.h and
rsvp_intserv.h to use these calls):
•
The rapi_session(): it defines an API session for sending a single simplex data flow or receiving
such a data flow. A single API session, defined by a single rapi_session call, can define only one
sender at a time. The rapi_session call allows the application to specify an upcall routine that will
be invoked by signals of RSVP state change and error events. If the API session is created
successfully, the call returns an opaque session pointer different from zero for use in subsequent
calls related to this API session
•
The rapi_sender(): An application must use a rapi_sender call if it intends to send a flow of data for
which receivers may make reservations. rapi_sender call defines, redefines or deletes the
parameters of that flow. If there is a synchronous error, rapi_sender returns a RAPI error code;
otherwise, it returns zero. This call may be issued more than once for the same API session; the
most recent one takes precedence.
•
The rapi_reserve(): the rapi_reserve procedure is called to make, modify or delete a resource
reservation for a session. The call may be repeated with different parameters, allowing the
application to modify or remove the reservation; the latest call will take precedence. Depending
Page 33
MIND
1.2
upon the parameters, each call may or may not result in new admission control calls, which
could fail asynchronously.
•
The rapi_release(): the rapi_release call removes the reservation, if any, and the state corresponding to
a given session pointer. This call will be made implicitly if the application terminates without
closing its RSVP sessions. If the session pointer is invalid, the call returns a corresponding
RAPI error code; otherwise, it returns zero.
It’s useful to add that rapi_sender and rapi_reserve calls may be repeated with different parameters to
dynamically modify the state at any time or they can be issued in null forms that retract the corresponding
registration. A single API session, defined by a single rapi_session call, can define only one sender at a
time. More than one API session may be established for the same RSVP session. For example, suppose
an application sends multiple UDP data flows, distinguished by source port. It will call rapi_session and
rapi_sender separately for each of these flows.
Notifications of RSVP errors and state change events in RAPI are notified to application to execute upcall
routine. The upcalls are specified indirectly and synchronously by rapi_session using the pointer Event_rtn.
The method followed for notifications and error events is:
•
The application issues the RAPI library call rapi_getfd() to learn the file descriptor of the Unix
socket, connected to the RSVP daemon, used by the API.
•
Then read events are detected in this file descriptor.
•
When a read event on the file descriptor is signalled, the application calls rapi_dispatch(). If this
call encounters an error, rapi_dispatch() returns a RAPI error code, otherwise, it returns zero. This
drives the API to execute the upcall routine if appropriate.
A synchronous error in a RAPI library routine returns an appropriate error code. Asynchronous RSVP
errors are delivered to the application via the RAPI upcall routine. Text messages for synchronous and
asynchronous error codes will be found in the file rapi_err.h.
There are five types of upcalls: PATH_EVENT and RESV_EVENT signal the arrival or change of path state
and reservation state, respectively, and deliver the relevant state information to the application;
PATH_ERROR and RESV_ERROR upcalls signal the corresponding asynchronous errors and PATH_CONFIRM
upcalls signal the arrival of a confirmation message.
The first rapi_session() call in a particular instance of the RAPI library opens a Unix-domain RAPI socket to
the RSVP daemon and passes the session registration request across it. If the application (or the daemon)
crashes without properly closing the RAPI socket, the other side will be notified to perform a cleanup. In
particular, if the user process terminates without explicitly closing the RAPI session, the daemon will
delete the corresponding reservation state from the routers.
As mentioned before, implementations of RSVP daemon codes for Linux were developed, e.g. [ALE99],
but actually they are poorly documented. For this implementation different interfaces between the RSVP
daemon and Linux Traffic Control were programming, for example, an interface to queuing discipline
and class manipulation, to packet scheduling, admission control and policing functions, etc. Currently,
there are some initiatives to enhance the Linux TC to make it more extensible, create a more user-friendly
configuration language, provide interfaces for straightforward interaction with network management, etc
[TCng]. As we explain, Traffic Control activities on Linux can only be defined from the user level with
'tc', the application that enables the set-up of QoS parameters using a command line interface, therefore a
user application cannot utilise the available structures dynamically in the course of program execution.
[VM00] and [OLS02] are some API implementations in progress to provide this capability.
2.2.2 QoS support in Microsoft Windows OS
Microsoft deploys two groups of QoS components: elements that reside in the host protocol stack and
elements that realised QoS policing functions in the network (Subnet Bandwidth Manager and Admission
Control Service) [MIC99a]. These components can be classified also in three categories depending in
which parts of the communications these components have a greatest influence [MIC02] : applicationdriven QoS components, network-driven QoS components and policy-driven QoS components. This is
shown in Figure 2-9.
Page 34
MIND
1.2
The list of component implemented by Microsoft include protocols, applications programming interfaces,
functional modules for traffic control as packets classifier and schedulers, etc. to achieve an integrated
technology for QoS support. These components are described in the following paragraphs.
RSVP
enabled router
LAN
Applications-Driven
QoS Component
Server
Directory
Information
Store
ACS Server
(ACS/SBM)
RSVP
Session
LAN
Host
Network-Driven
QoS Component
Policy-Driven
QoS Component
(shared subnets)
Figure 2-9 Areas of Influence of the Windows 2000 QoS Components
Table 2-1 List of the QoS Components According to its Areas of Major Influence
Application-Driven
QoS Application Programming Interface
Traffic Control API (TC API)
RSVP Service Provider
Resource Reservation Protocol Service
Traffic Control Modules
Network-Driven
802.1p
Differentiated Services
L2 Signalling
Subnet Bandwidth Manager
Resource Reservation Protocol
Policy-Driven
Admission Control Services (ACS)
Local Policy Module (LPM)
Policy information
RSVP
Local Policy Module API (LPM AP)
2.2.2.1 The Host Protocol Stack
Microsoft designs a host protocol stack for QoS-aware and QoS-non aware applications. The applicationdriven QoS components are shown in Figure 2-10. In Figure 2-11 its functional relationship is presented
with more details. Each component is described in the following points.
2.2.2.1.1 Generic QoS API
At the end system all the session oriented application can use a QoS Application Programming Interface
to request quality guarantees. This API is called Generic QoS API (GQoS). All QoS aware applications in
Windows invoke QoS services of the underlying QoS Service Provider (QoSSP) via the GQoS API as
shown Figure 2-11[MIC00a]. GQoS is a subset of the QoS of the Winsock21. GQoS commands carry
QoS parameters and they can be used to invoke QoS services from the operating systems.
1
Winsock is an API that allows Windows-based applications to access the transport protocols. It simplifies
application development in the upper layers by handling the details of network data exchange at the lower layers.
Winsock Kernel interface provides access to the Transport Driver Interface (TDI) allowing to write new transport
drivers that are independent of the network card, also, to write network applications to use TDI rather than relying on
a certain protocol, such as NetBIOS or IPX (Afd.dll).
Page 35
MIND
1.2
Applications
Winsock GQoS API
QoS Service
Provider
Traffic Control API
Protocols
(e.g. TCP/IP, IPX)
Packet
scheduler /marker
LAN & WAN
netcards
Figure 2-10 Windows Host Protocol Stack
3rd Party Management
Application
GQOS API
RSVP Services
(rsvp.exe)
Application
RSVP Service
Provider (.dll)
Windsock
Traffic Control
API (traffic.dll)
Transport Device Layer
Afd.dll
Generic Packet
Classifier
(Msgcp.sys)
TCP/IP
Tcpip.sys
QoS Packet
Scheduller
NDIS
Ndis.sys
Network Interface
Figure 2-11 Detailed Architecture of GQoS
The API is very abstract, the applications can request the QoS they need with little knowledge of the QoS
mechanism available or the underlying network medium, i.e. the technology used for the QoS supporting
is transparent for the applications. GQoS only specifies one of the following service types:
•
Quantitative QoS:
o
Guaranteed: for low and bounded latency applications, and
o
Controlled Load: for jitter tolerant applications.
Page 36
MIND
•
1.2
Qualitative: for applications that require better than best-effort services without quantity their
requirements [Mic00b].
2.2.2.1.2 Opening QOS-enabled Sockets with GQoS:
GQoS consist of programming elements like functions, structures and objects [BER98] . Although GQoS
is supposed to be protocol independent, the reality is that they assume the IP protocol (the same with
QoSSPs and TC). However, the GQoS API was made to assure that the QoS API specification is
independent of a specific protocol as practically realisable.
To open a socket supporting QoS in GQoS the following steps are defined:
1.
Enumerate the available protocols.
2.
Choose the protocol that supports QoS in the available set.
3.
When a proper protocol is found, then establish a connection to another socket application.
The first step involves the use of the WSAEnumProtocols(). This function is used to discover information
about the collection of transport protocols installed on the local computer. A list of protocols is returned
and all the information about each one is stored in a structure called WSAPROTOCOL_INFO (a structure
per protocol). The available protocols for QoS support are identified by a specific flag (dwServiceFlags1).
When an appropriate protocol is found then is possible to open a QoS enable connection. QoS is invoked
relative to a particular socket. This socket is said to be a QoS socket. There are different calls to specify a
QoS socket, e.g., WSAConnect, WSAJoinLeaf, WSAAccept and WSAIoctlQOS-enabled connections are
unidirectional. To enable a connection with service guarantees for both sending and receiving from a host,
two individual QOS-enabled flows are required.
QoS-enabled connections are unidirectional. To enable a connection with service guarantees for both
sending and receiving from a host, two individual QoS-enabled flows are required.
2.2.2.1.3 Quantitative QoS service
In Microsoft Windows, to provide a Quantitative QoS service, network resources are reserved according
to an application’s QoS request subject to bandwidth management policy. This service uses an explicit
end-to-end signalling. The QoSSP used is IntServ with RSVP signalling. Quantitative applications, i.e.,
applications that require quantitative QoS, are expected to (minimally) quantify their requirements in their
call to WSAConnec, WSAJoinLeaf, WSAAccept, etc. Each of these functions invokes the RSVP SP on the
application's behalf, and begins the process of establishing QoS between the receiver and sender. Each of
these functions includes a parameter, the QualityOfService structure (QoS structure), that provides the
application with the capability of providing QoS-specific parameters. SendingFlowspec and
ReceivingFlowspec structures are included in this QoS structure to specify the QoS parameters of its sent
and received traffic. The definition of QualityOfService structure in GQoS is:
Typedef struct _QualityOfService {
FLOWSPEC SendingFlowspec;
FLOWSPEC ReceivingFlowspec;
WSABUF ProviderSpecific;
} QoS;
The FLOWSPEC structure provides the QoS parameters to the RSVP SP allowing the QoS-aware
applications to invoke, modify, or remove QoS settings for a given flow. It contains a set of token bucket
parameters like the permitted rate at which data can be transmitted over the life of the flow (TokenRate),
the upper limit during that time (PeakBandwith), the maximum acceptable delay between transmission of
a bit by the sender and its receipt by one or more intended receivers (latency), the jitter (DelayVariation),
etc. The definition of the FLOWSPEC structure in GQoS is
typedef struct _flowspec {
uint32 TokenRate;
uint32 TokenBucketSize;
uint32 PeakBandwidth;
uint32 Latency;
uint32 DelayVariation;
SERVICETYPE ServiceType;
uint32 MaxSduSize;
Page 37
MIND
1.2
} FLOWSPEC, *PFLOWSPEC, *LPFLOWSPEC;
Recalling, QoS technology and parameters are unidirectional, enabling different transmission parameters
for sender and receiver. Additionally, RSVP semantics are receiver-centric, in that resources are not
reserved until the receiver sends out a RESV message. Due to this unidirectional approach, differences
exist in the behaviour of the receiver and the sender. In general, the transmission of special RSVP
message (PATH/RESV) begin at the time Winsock 2 GQoS has determined that the application intends to
invoke QoS in a specific direction (sending or receiving) and all information required for the generation
of the messages is available.
Sending hosts inform the RSVP SP of QoS-specific parameters in order to enable the RSVP SP to interact
with other QoS components on the sending host's behalf. QoS-specific parameters are provided to the
QoSSP through the SendingFlowspec member of the QoS structure (in the Table 2-2) is shown the
mapping of parameters to derive a RSVP SenderTspec from the SendingFlowspec). These QoS-specific
parameters are based on the application's knowledge of the data transmission characteristics appropriate
for the application. Senders may use preinstalled QoS templates that include QoS-specific parameters
with appropriate transmission characteristics based on the type of application. Senders may configure
additional traffic control parameters such as handling nonconforming packets. Additionally, they may
monitor RSVP SP events like the arrival of RESV messages, or monitor status information to stop the
transmission when there are no QoS-enabled receivers for the transmission.
Table 2-2 Mapping of Parameters from the Winsock2 QoS Flowspecs to RSVP Tspecs and Rspecs
GQoS FLOWSPEC
TokenRate
TokenBucketSize
PeakBandwidth
MinimumPolicedSize
MaxSduSize
DelayVariation
Latency
Tspec
TokenBucketRate
TokenBucketSize
PeakRate
MinimumPolicedUnit
MaximumPacketSize
Rspec
Rate
DelaySlackTerm
As a receiver on a QoS-enabled connection, the applications must be aware of the occurrence of events
such as the establishment of the QoS-enabled connection, i.e., the arrival of a PATH message. A receiver
must provide QoS-specific parameters to the RSVP SP through ReceivingFlowSpec parameter of the QoS
structure and if an application is notified of the arrival of a PATH message, it must retrieve the pertinent
QoS information (such as the sender's Tspec and the Adspec generated by intermediate nodes in the data
path). Information provided in the PATH message may be used by the application to define or modify its
initial QoS-specific parameters to match the sender's Tspec. If the receiving application is interested in
the traffic offered by the sender, it triggers the respective RESV RSVP message. the RESV message will
return to the sender unless specific network policies deny the reservation or there is a lack of resources in
intermediate devices. After the reception of a RESV message, the sender application may then send data.
Data sent that complies to the constraints of the established QoS-specific parameters is considered
conforming data. Data that falls outside those parameters, nonconforming data, is handled differently
relegating it to a best-effort transmission or discarding these.
On receivers, for Controlled Load Service, the application may decide to specify only the ServiceType
parameter in the ReceivingFlowspec. In this case, the QoSSP copies the SenderTspec from matching
PATH messages, to the ReceiverTspec sent with the RESV messages. Alternatively, the receiving
application may specify any of the Tspec parameters in the ReceivingFlowspec. For Guaranteed Service,
the QoSSP will copy the SenderTspec from corresponding PATH messages to the ReceiverTspec sent
with the RESV messages. The application cannot supersede Tspec parameters in this case.
2.2.2.1.4 Qualitative QoS service
The Qualitative QoS service type is suited for applications that require better than Best Effort service, but
are unable to quantify their requirements. There is no need for reservations and signalling. This type of
service is accomplished in Windows QoS architecture by DiffServ mechanism. The minimum
requirements for supporting qualitative QoS are somewhat simpler than for quantitative QoS. There is no
need to quantify traffic. Applications need only include the requested service type
Page 38
MIND
1.2
SERVICETYPE_QUALITATIVE in the basic QoS parameters (FLOWSPEC structure) and fill the
remaining structure elements with default QoS_NOT_SPECIFIED values. Also, applications need to
invoke QoS as a sender (and not as a receiver). All other QoS functionality is automatically handled by
the operating system: start the Winsock2 provider, query the Winsock providers to find the QoSSP, call
the provider to open a QoS socket, specifying the QoS structure that points to the policy element and
connect the socket.
The OS and the network take care of the rest. The operating system formats the request to the network.
Network agents act on the request and returns a DCLASS object if necessary [Ber00]. If a DCLASS
object is returned, the OS marks the packets with the corresponding DSCP DiffServ Codes on the socket
accordingly.
2.2.2.1.5 Status indications from the QoSSP to applications
Windows QoS framework makes certain information available to applications that register interest in
obtaining event-related QoS information. The event categories available to applications are:
•
Policy-based or administratively-based information that impacts QOS provisioning for a
given flow.
•
Errors that occur upon set-up, or during the life of a QOS-enabled flow
•
Information regarding acceptance or rejection of QOS requests by the QoSSP module or by
the network. Rejection of a QOS request may indicate a transient failure.
•
Significant changes in the service quality provided by the network (when in contrast with
previously negotiated QOS parameters), such as from flow pre-emption in the network.
•
Status regarding the presence of a QOS peer to send or receive a particular flow.
GQoS provides this status information through the FD_QoS event suite. Applications that take advantage
of QoS capabilities (whether sending or receiving data) should use FD_QoS events to monitor the
occurrence of event notifications of QoS. All FD_QoS events are edge-triggered, i.e., a message is posted
exactly once when a QoS change occurs. Additional messages are not forthcoming until the provider
detects a further change in quality of service, or the application re-negotiates the flow's quality of service.
Applications that either send or receive QoS-enabled data can listen for FD_QoS events using the
WSAAsyncSelect or WSAEventSelect functions. Both use the FD_QoS event to allow an application to
receive asynchronous notifications of status from the QoSSP when the QoS changes. When a significant
QoS event occurs on a specified socket, the QoSSP posts a message or signals the event, as appropriate.
The appropriate status codes may be retrieved by calling WSAEnumNetworkEvents or other appropriate
Win32 calls. In addition, the application should issue a WSAIoctl (SIO_GET_QoS) function/opcode pair
in order to retrieve a QoS structure that indicates the current QoS parameters. The application should
inspect these parameters to determine the degree of the QoS change.
2.2.2.1.6 Modifying the QoS parameters
The WSAIoctl(SIO_SET_QOS) function/opcode pair is useful for modifying QOS parameters subsequent
to the establishment of the connection with a connection-oriented function call. This call (WSAIoctl) can
be invoked by an application, at any time to change (or initialise) the QOS parameters on a socket.
SIO_SET_QOS, an operational code of WSAIoctl, associates the specified QOS structure with the socket.
2.2.2.1.7 Closing QoS connections
There are a number of ways to close a QoS-enabled connection. Generally, any event that closes a socket
also ends RSVP SP servicing on the socket. The closesocket, shutdown, WSAConnect with a NULL peer
address and WSAIoctl are examples of functions that could generate these kinds of events. Shutdown
function partially disable a socket, i.e. shutting down only the receive capabilities leaves the QoS-enabled
send capabilities for the socket intact. In general, any event that closes a socket will also terminate
RSVP/TC.
2.2.2.2 QoS Service Provider
The underlying QoS Service Provider (QoSSP) is the entity that responds to the GQoS API. It provides
the following services:
Page 39
MIND
1.2
•
RSVP signalling: to communicate QoS parameters and negotiate network usage with receiver
end systems and network devices.
•
QoS policy support: to identify the Microsoft Windows NT operating system user and
applications inserting a Kerberos encrypted Windows NT user ID into RSVP signalling
messages and, also, application ID via the GQoS API, so policy can be applied in the network.
•
Invocation of traffic control: to enforce policy by invoking traffic control in accordance with the
network’s response to the signalling. Greedy traffic control is enable only if approved by the
network by RSVP signalling. Non greedy traffic control is enabled in immediate response of
application’s request for QoS.
2.2.2.3 Traffic Control API
The Traffic Control API (TC API) provides the QoSSP with a high degree of control over traffic control
functionality in the kernel. TC API is an interface that separates the traffic control consumers from the
traffic control providers, i.e., in Figure 2-11, the QoSSP is a TC consumer and the packet scheduler is a
TC provider. More TC providers implemented in Windows are listed in Section 2.2.2.4 (Table 2-3).
TC functionalities include the ability to create flows that affect transmitted traffic and to define
classification criteria that determine the set of packets directed engaged to each flow. To do so, TC API
comprises two fundamental APIs: CreateFlow and CreateFilter. With CreateFlow a flow is created in the
kernel network stack. A flow has certain characteristics that are applied to all packets on the flow: packet
scheduling, queuing discipline and packet marking. Therefore, CreateFlow comprises a marking
behaviour (media-specifics marks or tags) and a packet scheduling behaviour depending of the
characteristics associated to the created flow.
CreateFilter is used to attach filter to a flow. A filter determines the classification patterns, i.e., the set of
packets that will directed to the associated flow. As in Traffic Control of Linux OS, filters can be specific
or generic. Filters are expressed in form of an IP 5-tuple and a mask. A Generic Packet Classifier (GPC)
is used for the purpose of packet classification and scheduling parameters are expressed using the tokenbucket model.
TC API is also scriptable and remotely accessible. It enables third-party traffic management applications
and QoSSP to invoke traffic control on behalf applications that are unable to do so, or a system
administrator to control the QoS provided to applications.
2.2.2.4 Traffic Control Providers
Traffic control providers include kernels modules that implement fine grained traffic control functionality
in response to the traffic control API. They are listed in Table 2-3.
Table 2-3 List of Traffic Control Providers Implemented by Microsoft
Packet scheduling
802.1p2 marking
DSCP marking
ISSLOW link layer fragmentation
ATM VC control and cell scheduling
Besides the listed TC providers, Microsoft is planning to include traffic control providers for cable
modem drivers, P1394 and other media-specific drivers.
2.2.2.4.1 Packet Scheduler
The packet scheduler is used to provide traffic control over drivers and network cards for Ethernet, Token
Ring, FDDI and LAN Emulation that have no inherent packet scheduling capability. It is implemented as
an intermediate driver providing traffic control functionality over standard Local Area Network (LAN)
2
802.1p is a traffic handling mechanism to for supporting QoS in LANs. It defines a field in the layer-2 header of
IEEE 802 frames that can carry one of eight priority values. LAN devices should treat the packets accordingly.
Page 40
MIND
1.2
adapters and WAN drivers (Integrated Services over slow links or ISSLOW functionality). Packets are
scheduled on separate QoS queues as created via the TC API. It also is responsible for influencing the
marking of DSCPs and media-specific priority tags.
The scheduling components of the packet scheduler are:
•
A conform analyser that checks the conformance of the packets to a traffic descriptor,
•
A shaper to delay packets until they can be emitted per traffic descriptor, and
•
A sequencer which feeds packets to the network interface in the order of priority from the
queues that it manages
Table 2-4 Mapping between Service Type and the Configuration Mode of the Packet Scheduler
Service Type
Network Control
Guaranteed Service
Controlled Load
Qualitative
All other traffic
Mode
Priority
Borrow mode Highest priority
Shape mode
High priority
Borrow mode Medium priority
Borrow mode
Low priority
Borrow mode Lowest priority
Flows may be individually configured in the packet scheduler in the following modes:
•
Borrow mode: allow flows to borrow resources from higher priority flows that are temporarily
idle.
•
Shape mode: delays packets until they conform to a specified traffic descriptor.
•
Discard mode: discard packets that do not conform to a specified traffic descriptor.
The packet scheduler implements a mapping from requested service type (explained in Section 2.2.2.1.3
and 2.2.2.1.4) to one of these aforementioned modes and to an internal priority level. Table 2-4 shows this
mapping defining by default (it may be overridden):
The Network Control service type is reserved for use by critical traffic management applications. These
services are not available through the GQoS API, it may be requested via the TC API.
2.2.2.4.2 Marking Behaviour
The QoS aware applications request certain type of service (Guaranteed Service, Controlled Load or
Qualitative) for a traffic flow via the GQoS. The QoSSP generates an RSVP signalling request to the
network for the specified service type. This request could be refused by Policy Decision Points (PDPs) in
the network. If no refused the request, the QoS SP will request the TC to mark packets on the
corresponding flow. The host operating system marks the packets on a flow to direct these packets to
certain aggregate traffic handling classes in different parts of the network, i.e., by way of marking, the
host operating system can expect to obtain a certain level of service on behalf of applications by cooperating with network policy mechanism.
Packets will be marked based on a mapping from requested service type to a corresponding DSCP or
802.1p mark (Table2-5).
Page 41
MIND
1.2
Table 2-5 Default Mapping Between Service Type Requested and DSCP and 802.1p mark
Service Type
Network Control
Guaranteed Service
Controlled Load
Qualitative
All other traffic
DSCP
303 (6)4
28 (5)
18 (3)
0 (0)
0 (0)
802.1p
7
5
3
0
0
2.2.2.5 Subnet Bandwith Manager and Admission Control Service
The Subnet Bandwidth Manager (SBM) and the Admission Control Services (ACS) are Microsoft’s
implementation of Policy Enforcement Point (PEP) and PDP functionality; both are QoS policy
components of shared network resources. ACS uses the Active Directory (Figure 2-9) service as a policy
data store and single point of management. Devices as switches and routers act as PEP/PDP intercepting
RSVP signalling messages.
The SBM protocol, defined by IETF, defines how agent in the subnet elects a Designated SBM (DSBM)
which then is responsible for the use of shared resources of the subnet. The DSBM advertises it presence
in the network. All devices sending RSVP Path messages must route these through the DSBM.
ACS of Microsoft combines the resource-based admission control functionality of an SBM with policy
based admission control using the Active Directory. It leverages the capability of SBM to include itself in
the RSVP reservation path and, therefore, effect admission control. When PATH and RESV messages are
intercepted, a Local Policy Module extracts the policy-related objects from the RSVP message and
compares the requesting user ID and the resources requested with privileges configures in the Active
Directory.
2.2.3 Linux and Windows Comparison with Respect to QoS Support
In precedent sections have been described the development and implementation of the QoS support in the
well Linux and Microsoft Windows OSs. In this section some brief thoughts are included in a manner of
comparison between these platforms to encourage their use for future BRENTA implementations.
2.2.3.1 QoS Support in Linux
The QoS support in Linux kernel provides the framework for the implementation of various IP QoS
technologies like IntServ and DiffServ (as depicted in Figure 2-5). QoS in Linux is basically based on
Traffic Control, the control of the transmission behaviour of packets in the outgoing in the outgoing
interfaces. Therefore, QoS in Linux is essentially implemented using queue disciplines, classes and filters.
Currently, a command line interface called “tc” is the only tool used for QoS configuration, although
there are some initial efforts to define an API to provide dynamic QoS configuration capabilities to
applications. Despite of this limitation, several implementations have been developed to port adopted QoS
APIs like RAPI and the implantation of end and intermediate nodes of standard QoS mechanism like
DiffServ and IntServ. Several features encourage the use of this OS for experimental purposes like the
possibility to make changes to its source code freely. The conceptual architecture of Linux was designed
in an extensible fashion, i.e., the system portions that requires the most development were implemented
using a data abstraction technique: each network protocol and device driver, for example, is implemented
as a separate module that supports a common interface, due it, new modules could be added
independently or with minimal interaction between the developers of other modules. This principle of
design has motivated the participation of a large number of volunteer developers in the improvement of
the OS performance and services.
3
Hex value.
4
Three of the six bits of DSCP comprise the formerly IP Precedence Field. The corresponding IP precedence field
value is shown in parenthesis.
Page 42
MIND
1.2
2.2.3.2 QoS Support in Microsoft Windows
One of the most interesting features of Winsock 2 architecture is the Service Provider Interface (SPI). SPI
can be used to extend an existing base service provider by implementing a Layered Service Provider
(LSP), for example, QOS in Windows is implemented as a LSP over the TCP/IP protocol stack. Transport
providers (or protocol stacks) are services that allow setting up connections, transmit data, apply flow
control, error control, etc. There are two types of transport service providers in Windows: base and
layered service providers. Base service providers implement the actual details of a transport protocol
(setting up connections, transferring data, and exercising flow control and error control) and are typically
available from operating system vendors and transport stack vendors. Layered service providers,
developed by mean of SPI functions, implement only higher-level custom communication functions and
rely on an existing underlying base provider for the actual data exchange with a remote endpoint.
Extending base transport functionality using a layered transport service provider is a very attractive and
powerful idea: this service architecture allows third-party service providers to be plugged in without the
need for application developers to rewrite their code and without the need to replace dynamic link
libraries.
GQoS, the QoS application programming interface of Windows, takes advantage of this layered service
provider model: first, a QoS-aware application must find an appropriate layered service provider that
supports a specific QoSSP (e.g., RSVP) and, once this is found, the standard Winsock 2 APIs can be
invoked to create a socket and specify QoS information. A particular feature of GQoS is that the same
socket is used for both, for data transfer and QoS setup/notifications. Attempting to use two sockets for
the purpose of segregating QoS setup/notification functionality from the actual data transfer functionality
(with QoS applied on the transfer) is not supported.
2.2.4
Mapping BRENTA Service Primitives
In this section is presented the description and mapping of the ESI service primitives to function calls
defined in the OSs described in previous sections. ESI was conceptually defined during the BRAIN
project to provide to BRENTA applications the ability to request QoS in quantitative and qualitative
ways. First, the ESI and its relation to other BRENTA component is explained, then, its QoS service
primitives are reviewed and finally the mapping of these primitives to widely used APIs Linux and
Microsoft OSs are accomplished.
2.2.4.1 Enhanced Socket Interface and BRENTA Architecture.
The ESI is a QoS supporting transport service interface defined for BRENTA to use well-known transport
primitives (e.g. open, close, listen, etc) and enhance it by additional primitives to give applications of
BRENTA the ability to use QoS. ESI is a generic interface i.e. independent of any platform, QoS
architecture and transport service provider. With this interface, applications in BRENTA should be able
to request some QoS level for their connections in a transparent manner from the type of QoS mechanism
supported by the network and mobility associated features. Thereby, it allows the programmers to
develop applications against this interface irrespective of the platform, QoSSP implementation in endsystems or networks.
The required mapping of the parameters and primitives to specific QoS service and transport provider is
held by an Enhanced Service Layer (ESL). This layer is located between the application and transport
layer (as shown in Figure 2-12) and it consist of two main functionalities: a QoS Mapper and a Primitive
Mapper. The former is in charge of translate QoS specifications requested from the ESI to QoS
parameters which the used QoSSP is able to understand; and the last translates ESI primitives to
corresponding implementation-dependant primitives provided by the underlying protocol stack. In
BRENTA, the specific Transport and the QoSSP are representing by a BRAIN-Service Interface below
the ESL. Besides these layers, the IP layer and sub network technology interfaces complete the QoS
data/networking plane of the terminal architecture.
Page 43
1.2
Legacy Applications
QoS- Aware Applications
Enhanced Socket Interface
Primitive Mapper
Entity
Service Provider
QoS Mapper Entity
LMI
Enhanced
Service
Layer
BRAIN Service Interface
TCP
IP(v4/v6)
Further transport of QoS
or Service Provider
UDP
Mobility support
Subnetwork technologies ( i.e., Hiperlan/2, UMTS, Bluetooth )
Local Management Functionality
User Provider
MIND
Figure 2-12 Enhanced Socket Interface and General BRENTA Architecture
Through a Local Management Interface (LMI), management related information that resides in a Local
Management Entity (LME) could by accessed to QoS-related configuration and administration of the
system. The last is part of the QoS & Resource Management plane of BRENTA.
2.2.4.2 Modelling the Enhanced Socket Interface
The ESI is represented using the model of service primitives, in which a service is specified by a set of
primitives. These primitives (function calls) indicate a service to carry out some action or to inform about
an action taken by a peer entity. The services could be confirmed or unconfirmed. In a confirmed service,
a set of primitives is used to indicate to a corresponding peer entity that it has received information and it
has to send back a confirmation. In an unconfirmed service, there is no confirmation. The set of
primitives used in each type of services is shown in Figure 2-13.
In ESI, the confirmed and unconfirmed services are extended by primitives supporting local error cases
inform of indications from service providers, e.g., for each Service.request there is a
ServiceErrorRequest.indication. Besides of these services, a Notification Service is useful when a
network entity between the communicating peer generates information. It can be modelled by a Service
indication as shown Figure 2-14.
2.2.4.3 QoS Mechanisms Supported in BRENTA
In BRENTA there are two basic mechanisms for QoS support:
• Hard QoS reservation: network resources are reserved according to an application’s QoS request
and subject to bandwidth management policy. This mechanism requires an explicit end-to-end
signalling; therefore it is developed by a confirmed serviced. Indications of QoS violations could be
informed to upper layers by the way of a notification service.
• Soft QoS reservation: network resources might be reserved according to a previous negotiated
service legal agreement. The information is forwarded according to a per hop behaviour attached to
the delivered information and the upper layer does not know if the requested QoS is realised in any
form. This mechanism is supported by an unconfirmed service.
Page 44
MIND
1.2
Layer N
Layer N-1
service
.req ues
t
service.c
Service
User
Layer N-1
Confirmed Service
Layer N
servic
e.ind ic
atio
o nfirm
.respo
service
Service
Provider
n
nse
Service
Provider
Service
User
Network
Layer N
Layer N-1
Layer N-1
service
.req ues
t
Service
User
Unconfirmed Service
Layer N
servic
e.ind ic
atio
Service
Provider
Service
Provider
n
Service
User
Figure 2-13 Abstract Model of Confirmed and Unconfirmed Services
Layer N-1
service.i
nd icatio
Layer N
n
Network
Service
Provider
Service
User
Notification Service
Figure 2-14 Abstract Model of Notification Service
2.2.4.4 ESI Service Primitives
The services used in BRENTA to support Hard QoS reservation are the following:
•
SetQoS, a confirmed service to request QoS to be associated with the given flow.
•
With this service, a reservation in all the participant nodes between the sender and the receiver
(both inclusive) has to be accomplished returning a positive acknowledge if the end-to-end QoS
can be granted or a negative one if not. This service is composed by the set of primitives of a
confirmed service as used to model the ESI services. This service can only be offered if an
appropriate signalling is supported by the QoSSP (e.g., RSVP).
•
SetQoSViolation Notification
•
During establishing a QoS aware flow with SetQoS service an error in any network entity can
occur due to admission or policy control or simply due the fact that the network entity cannot
grant the requested QoS. This error is informed to one of the participated sides depending of the
QoSSP capabilities and how the used protocol handle violations during establishing of a QoS
Page 45
MIND
1.2
aware flow in the network. The notification service only involves an indication.primitive as
shown in Figure 2-14.
•
QoSViolation Notification
•
After establishing a QoS aware flow there might be changes of the QoS between the sender and
the receiver. Therefore, QoSViolation notification is used to inform to participating peers that
the established QoS cannot longer be provided. The destination of the notification and the
information about the violation is delivered depending of the QoSSP implementation.
•
ChangeQoS, confirmed service
•
This service was defined for changing of the reserved resources between the sender and the
receiver after the establishing a QoS aware flow with SetQoS service according changes of
flow’s QoS requirement. This service can only be offered if an appropriate explicit end-to-end
signalling QoS Service provider is available.
•
ChangeQoSViolation Notification
•
ChangeQoSViolation Notification service provides an indications of errors during the change of
QoS aware connection. The error could be produced in any network entity due to admission or
policy control or simply due the lack of resources.
•
The unconfirmed service used in BRENTA to support Soft QoS reservations is AssignQoS
•
AssignQoS, an unconfirmed service
•
AssignQoS support the delivering of packets based on specific QoS parameters without the
reservation of resources in the network, therefore, no signalling is required. It invokes QoS
treatment for a given flow according the QoSSP capabilities. ChangeQoS service cannot apply to
QoS aware flows established with AssignQoS service. The flow’s QoS characteristics established
with the AssignQoS can be changed by a repeated call of the same primitive including the new
QoS parameters.
•
For both, the Hard and Soft QoS reservations, the resources established for the QoS support are
released with RealeseQoS:
•
ReleaseQoS
This service is used for both kind of flows, either associated with an end-to-end signalling protocol or not.
If the QoS aware flow was established with an end-to-end QoS signalling, this service is used as an
unconfirmed service. If a signalling was not involved then is dependent of the QoSSP’s nature to release
the requested QoS.
All the described services and its respective primitives are summarised in the Table 2-6.
Table 2-6 Service Primitives of the Enhanced Socket Interface
Service Primitives
Meaning
Direction
SetQoS, confirmed service
Associated Info: flow, QoS parameters
•
SetQoS.request
Request QoS to be associated with a given User Æ Provider
flow
•
SetQoS.indication
Indicates a New QoS connection
Provider Æ User
•
SetQoS.reponse
Response with probably modified QoS
User Æ Provider
•
SetQoS.confirm
Confirmation of the requested QoS flow. Provider Æ User
Received QoS can differ from the requested
one.
Page 46
MIND
1.2
•
SetQoSRequestError.indication
Indicates a local error due to SetQoS.request Provider Æ User
primitive call
•
SetQoSRespondError.indication
Indicates a local error due to SetQoS.respond Provider Æ User
primitive call
SetQoSViolation, notification
Associated Info: flow, type of violation
•
SetQoSViolation.indication
Indicates a violation during establishing a Provider Æ User
QoS aware flow with the SetQoS service
QoSViolation, notification
Associated Info: flow, type of violation
•
QoSViolation.indication
Indicates a violation for an already QoS Provider Æ User
aware flow.
ChangeQoS, confirmed service
Associated Info: flow, QoS parameters
•
ChangeQoS.request
Request the change of the QoS for an already User Æ Provider
QoS aware flow
•
ChangeQoS.indication
Indicates that the QoS for the specific flow Provider Æ User
has to be changed to new QoS
•
ChangeQoS.respond
Respond with probably modified QoS
•
ChangeQoS.confirm
Confirmation of the requested change for an Provider Æ User
already established QoS flow
•
ChangeQoSRequestError.indication
Indicates
a
local
error
due
ChangeQoS.request primitive call
•
ChangeQoSRespondError.indication
Indicates a local error due to ChangeQoS.respond Provider Æ User
primitive call
User Æ Provider
to Provider Æ User
ChangeQoSViolation, notification
Associated Info: flow, type of violation
•
ChangeQoSViolation.indication
Indicates a violation during the change of an Provider Æ User
already QoS aware flow with the SetQoS service
AssignQoS, unconfirmed service
Associated Info: flow, QoS parameters
•
AssignQoS.request
Assign QoS Parameters to a given flow
User Æ Provider
•
AssignQoS.indication
Indicates a new QoS established flow
Provider Æ User
•
AssignQoSRequestError.indication
Indicates
a
local
error
due
ChangeQoS.request primitive call
QoSViolation, notification
Page 47
to Provider Æ User
MIND
1.2
Associated Info: flow, type of violation
•
QoSViolation.indication
ReleaseQoS, unconfirmed service
Indicates a violation for an already QoS aware Provider Æ User
flow.
Associated Info: flow
Associated Info: flow
•
ReleaseQoS.request
Request the release of resources associated with a User Æ Provider
given flow
•
ReleaseQoS.indication
Indicates the release
corresponding peer
of resources by
the Provider Æ User
2.2.4.5 ESI QoS Parameters
The QoS parameters are used by QoS-enabled applications to specify requirements to QoS service
providers. In [BRAIN2.2] were proposed the QoS parameters used in the primitives above mentioned. In
order to support different kinds of QoSSPs, the parameters were defined according the following goals:
•
Generic definition: the generic definition of QoS parameters allows the application codes need
not to be changed each time the applications are running on different platforms or when the
QoSSP must be changed.
•
Adoption of well-known concepts: the familiar concept of flowspec was adopted to invoke
correct QoS treatment on a given flow.
•
Reduction of QoS violations: the idea of parameter intervals was introduced where appropriate
to provide more freedom in the election of the QoSSP and to reduce the QoS violation messages
(notifications and indications).
The QoS parameters were specified as intervals. The lower limit of intervals was denoted
minimum_acceptable_limit and the upper limit was named desirable_limit. When the QoS support is
required, the QoSSP may start with any suitable value within the limits specified by the QoS parameters.
It will try to stay with this value as long as possible or may change the initial value if more resources
become available. Also, the QoS parameters were distinguished between sending and receiving because
must of the applications show asymmetric characteristics. These parameters are the following:
•
SendingFlowspec: specifies QoS parameters of a particular flow for the sending direction.
•
ReceivingFlowspec: specifies QoS parameters of a particular flow for the receiving direction.
•
ServiceProviderSpecific [optional]: presents additional QoS parameters related to the QoSSP for
a given flow.
In more detail, FlowSpec is used to define in quantitative or qualitative form the requirements for QoS,
the type of service and the amount of traffic that the application will transmit. The FlowSpec consist of
Token Bucket model parameters, latency, jitter, service type, and others described in the following table
(Table 2-8).
Most of the applications can provide all their QoS requirements without using the
ServiceProviderSpecific parameters, but if the application must include additional information, like the
packet loss rate desirable for the given service, the requested dropping priority and/or the forwarding
priority for a given flow, the requested behaviour of a packet shaper used by traffic control mechanisms
and others, these parameters could be used to provide the required specific additional information to the
QoSSP.
Page 48
MIND
1.2
Table 2-7 Parameters that Compose the ESI Flowspec
Parameter
Token Rate
Token Bucket Parameters
Definition
Permitted rate at which data can be transmitted
over the life of the flow
Maximum quantity of credits of a flow regardless
of time
Burst limit, i.e., the higher limit on time-based
transmission permission for a given flow
Maximum acceptable delay between the
transmission of a bit and its reception
Delay variation. It determine the amount of buffer
needed at the receiving side of the flow.
Maintain with reasonable effort the level of QoS
specified with the FlowSpec without guarantees
on packet delivery.
Provide a best effort service type as expected
under unloaded conditions along the data path.
Isolate a given flow from the effect of other flows
as possible. For apps that require deterministic
QoS.
Maximum packet size allowed in the packet flow
TokenBucketSize
PeakBandwidth
Latency
(microseconds)
Jitter
(microseconds)
ServiceType
Best Effort
Controlled Load
Guaranteed
MaxSduSize
(bytes)
Minimum packet size for which the requested
QoS will be provided
MinimumPolicedSize
(bytes)
2.2.4.6 Mapping ESI to RAPI Function Calls
The set of primitives of ChangeQoS and SetQoS service maps to RAPI calls rapi_sender() and
rapi_reserve() in the same way because the last are used for both, the establishment and the change of
parameters of reserved resources. The Table 2-8, included below, explains the mapping in more detail.
The ChangeQoS and SetQoS indication and confirm primitives are notifications of the service provider to
the user providers, therefore these notifications could be mapped to the events used by the RAPI. First, it
is necessary to define a session using the rapi_session() call and specifying the address of an upcall
routine that will with be invoked when a notification is done. A rapi_getfd() call is used to obtain the file
descriptor associated with the Unix Socket connected to the RSVP daemon. When a read event is
signalled to the file descriptor, then rapi_dispatch() is called to invoke the upcall routine. The upcall
routine is generically named event_upcall_routine() in the table and its address was specified in
rapi_session(). The upcall routing executes a specific procedure depending of the type of event. In Table
2-8 just the event related with the specific indication or confirmation is shown. The same procedure is
required for the registration of asynchronous errors like SetQoS/ChangeQoSViolations.
Table 2-8 Mapping of ESI confirmed service primitives and violation notifications to RAPI Calls
BRENTA Service
Primitives
SetQoS & ChangeQoS
RAPI calls
Description
Related parameters
Corresponding calls,
upcalls & notifications
confirmed services
•
SetQoS.request
•
ChangeQoS.request
rapi_sender( )
Request QoS and define the QoS Required
parameters
are
parameters of a sender’s flow
session ID, source address,
source port, sender template,
sender
Tspec,
Adspec,
data_TTL, policy data
Page 49
MIND
•
SetQoS.indication
•
ChangeQoS.indication
1.2
event_upcall_routine
(…,EvenType,…);
EvenType
RAPI_PATH_EVENT
•
SetQoS.reponse
•
ChangeQoS.respond
•
SetQoS.confirm
•
ChangeQoS.confirm
rapi_reserve()
SetQoSRequestError.
indication
•
Make, modify or delete a resource
reservation for a session. It may
be
repeated
with
different
parameters,
allowing
the
application
to
modify
the
reservation.
The parameters depend of the
type of event. In this case,
sender template, sender Tspec
and Adspec are considered.
Session ID, receive
address, style ID,
extension,
host
style
RSVP policy, Filter Spec
number, Filter Spec List,
Flowspec number, Flowspec
list
Similar to the above indication, the The used parameters
confirmation is done with the Flowspecs and FilterSpec
reception of a RESV message. It
signals a RAPI_RESV_EVENT
event type.
event_upcall_routine
(…,EvenType,…);
EvenType
RAPI_RESV_EVENT
•
The upcall routine executes an
specific procedure depending of
the type of event. The received
type of event must be a
RAPI_PATH_EVENT
which
indicates that a PATH message
= form a remote node has arrived or
the local path state has changed.
are
=
Provided by an RAPI error
code
returned
by
a
rapi_sender() call if there is
a synchronous error
Examples of local error may be: no RAPI error code (defined in
explicit end-to-end signalling rapi_err.h), error flags and
capable QoS service provider is error values.
available, request not allowed
because the host is in the role of a
receiver, etc.
Provided by an RAPI error
code
returned
by
a
rapi_reserve() call if there is
a synchronous error
Examples of local error may be: no RAPI error code
explicit end-to-end signalling rapi_err.h
capable QoS service provider is
available, request not allowed
because the host is in the role of a
sender, etc
event_upcall_routine
(…,EvenType,…);
This type of event indicates that an Error
code
and
value,
asynchronous error has been found filterspec_list, flowspec_list,
in the sender information specified sender template, sender Tspec,
in a rapi_sender call. It contains an
error code and a corresponding
value to specify the error.
ChangeQoSRequestError.
indication
•
SetQoSRespondError.
indication
•
ChangeQoSRespondError.
defined in
indication
Asynchronous
Violation notifications
•
SetQoSViolation.
indication
•
ChangeQoSViolation.
indication
•
SetQoSRespondError.
EvenType
RAPI_PATH_ERROR
=
This type of event indicates that an Error code, error value,
asynchronous reservation error has Flowspec
list,
flowspec,
occurred when a rapi_reserve was FilterSpec_list, filter_spec
done.
event_upcall_routine
(…,EvenType,…);
indication
•
ChangeQoSRespondError.
Indication
EvenType
RAPI_RESV_ERROR
=
The error codes are defined in
rapi_err.h
Page 50
MIND
1.2
The mapping of the ESI primitives and RAPI calls for the release of reservations is shown in Table 2-9.
Table 2-9 Mapping of the ESI primitives and RAPI Calls for the Release of Reservations
BRENTA Service
Primitives
ReleaseQoS
unconfirmed service
RAPI calls
Description
Related parameters
Corresponding calls,
upcalls & notifications
•
ReleaseQoS.request
rapi_release()
This call removes the reservation and
the state corresponding to a given
session.
•
ReleaseQoS.indication
…
A path or reservation event upcall also
indicates the arrival of teardown
messages. The identification of a
PATH tear or a RESV tear message
depend of the values of the parameters
event_upcall_routine
(…,EvenType,…);
EvenType
=
RAPI_
RAPI_PATH_EVENT or
•
The list of senders
is empty.
•
The
flowspec
object is empty in
the case of a
RESV_EVENT.
RAPI_RESV_EVENT
2.2.4.7 Mapping ESI calls to GQoS Function Calls
There are a variety of ways that an application can communicate its QoS requirements for a socket to the
QoS service provider using GQoS interface. It depends on the type of the communication (point to point
or multipoint) and the type of transport protocol. To provide an example of the mapping between the ESI
service primitives to GQoS calls, we assume a common UDP application sending/receiving unicast flows
with QoS support from the RSVP QoSSP for the explanation.
The first step in QoS-enabling the application is to request at least Winsock version 2.0. As mentioned in
Section 2.2.2.1.2 to establish a connexion with QoS support is required to enumerate the available
protocols using WSAEnumProtocols. When the UDP protocol with QoS support protocol (RSVP) is
found, WSASocket call can be used to open a QoS Socket, passing a pointer to the
WSAPROTOCOL_INFO structure (that defines the characteristics of the socket to be created) with the
XP1_QoS_SUPPORTED flag. Then several calls could be used to invoke the RSVP SP on the
application's behalf, and begins the process of establishing QoS between the sender and receiver.
Notifications like indications, confirmations and asynchronous errors are registered using a set of
functions. First, WSAAsyncSelect() register the type of event in which the application is interest by
means of lEvent parameter which value must be FD_QoS. Then, WSAEnumNetworkEvents() call is used
to discover which network events have occurred. The socket's internal record of network events is copied
to the structure referenced by lpNetworkEvents in this call. The iErrorCode array of this structure
contains the corresponding notification. After the notification is evaluated, applications could inspect the
arrived QoS parameters to determine the changes associated with the notification. To achieve this task,
WSAIoctl call could be used to retrieve the QoS structure associated with the event if the SIO_GET_QoS
parameter is specified. The QoS parameters are stored in lpvOUTbuffer.
In Table 2-10 is shown the mapping of ESI service primitives and GQoS API calls. SetQoS and
ChangeQoS primitives map to GQoS calls using the same functions as shown because these functions
develop both, the establishing and the change of resource reservations.
Page 51
MIND
1.2
Table 2-10 Mapping of ESI Confirmed Service Primitives and Violation Notifications to GQoS
Calls.
BRENTA Service
Primitives
GQoS API
SetQoS & ChangeQoS
Corresponding calls, upcalls
& notifications
Description
Related parameters
confirmed services
•
•
SetQoS.request
ChangeQoS.request
WSAconnect();
This call provides the QoS Socket created via
parameters of a sender’s flow WSASocket(), Peer host
(sending flowspec).
address, the lpSQoS structure
This socket is used for both task,
data transfer and QoS setup. A
lpSQoS structure is used to specify
the sending flowspec with its
traffic
characteristics.
The
transmission of PATH messages
begins when the sender star to send
data
•
•
SetQoS.indication
ChangeQoS.indication
WSAEnumNetworkEvents(…
,lpNetworkEvents,…);
WSAIoctl
(…,SIO_GET_QoS,
pvOUTbufferl,…);
WSAEnumNetworkEvents call is
used to discover which network
events have occurred. The socket's
internal record of network events
is copied to the structure
referenced by lpNetworkEvents.
The iErrorCode array of this
structure
contains
a
WSA_QoS_SENDER when a
PATH message has arrived.
The parameters depend of the
type of event. In this case,
Sender template, sender Tspec
and Adspec are evaluated from
the sending flowspec of the
QoS structure.
WSAIoctl (SIO_GET_QoS) call
retrieves the QoS structure
associated with the event. These
are stored in lpvOUTbuffer.
•
•
SetQoS.respond
ChangeQoS.respond
WSAconnect();
Similar to SetQoS and ChangeQoS
requests. WSAconnect() requests
QoS and define the QoS
parameters for the requested flow
using the same socket for data
transfer. A lpSQoS structure is
used to specify the receiving
flowspec
with
its
traffic
characteristics. The transmission of
PATH messages begins when the
sender star to send data.
The transmission of RESV
messages begins when GQoS has
determined that the application
intends to invoke QoS. Generally,
the
transmission
of
RESV
messages may be triggered either
by the receipt of a PATH message
or by the creation of a socket.
Page 52
Socket
created
via
WSASocket(),
Peer
host
address, peer host address, the
lpSQoS structure with the
relevant QoS (the receiving
flowspec must be settled with
the
requested
traffic
characteristics).
MIND
•
•
SetQoS.confirm
ChangeQoS.confirm
1.2
WSAEnumNetworkEvents(…
,lpNetworkEvent,…s);
WSAIoctl
(….,SIO_GET_QoS,
lpvOUTbuffer,…);
•
SetQoSRequestError.
indication
•
ChangeQoSRequestError
.
indication
•
SetQoSRespondError.
indication
•
ChangeQoSRespondErro
r.
Indication
Similar to SetQoS and ChangeQoS
indications,
GQoS
provides
confirmations
that
can
be
registered by a set of function
calls. It’s necessary to register the
FD_QoS event types. When
WSA_QoS_RECEIVERS
is
returned in iErrorCode array of
lpNetworkEvents it indicates that a
reservation state has changed in
the sender host. This occurs when
a RESV message has arrived. Then
the app. must get the information
from the QoS structure stored in
lpvOUTbuffer.
The parameters depend of the
type of event. In this case,
Sender template, sender Tspec
and Adspec are evaluated from
the receiving flowspec of the
QoS structure.
The used parameters
Flowspecs and FilterSpec
WSAConnect(); returns a
SOCKET_ERROR if it fails,
the specific error code can be
retrieved
by
calling
WSAGetLastError().
WSAConnect();
returns
a No parameters are required.
SOCKET_ERROR if it fails, the
specific error code can be retrieved
by calling WSAGetLastError().
This call returns the last network
error that occurs. It provides the
error code of the failure.
WSAEnumNetworkEvents(…
,lpNetworkEvents,…);
The FD_QoS event triggered by No parameters are required.
the reception of a message
describes the kind of error that
occurs in a network element.
WSAIoctl
(…,SIO_GET_QoS,
pvOUTbufferl,…);
Some of the following failures can
be registered in the case of an error
event arrives:
are
Local Error indications
Asynchronous
Violation notifications
•
SetQoSViolation.
indication
•
ChangeQoSViolation.
Indication
- error due to lack of resources:
WSA_QoS_ADMISSION_FAILURE
rejected for administrative
reasons:
WSA_QoS_POLICY_FAILURE
- unknown or conflicting style
WSA_QoS_BAD_STYLE
.
- problem with some part of the
flowspec:
WSA_QoS_BAD_OBJECT
- problem with some part of the
filterspec
WSA_QoS_TRAFFIC_CTRL_ERROR
- general error
WSA_QoS_GENERIC_ERROR
For qualitative applications, those that do not know their specific traffic requirements, but for which data
delivery is very important, GQoS, in co-ordination with network policy elements (described in Section
2.2.1.5), influences the marking of transmitted packets. The FLOWSPEC structure, that describes the QoS
flow parameters (Section 2.2.2.1.3), provides a SERVICETYPE parameter in which is possible to define
a qualitative service type, named SERVICETYPE_QUALITATIVE. This service type should supply an
application ID policy element in the ProviderSpecific field of the QualityOfService structure, which
enables policy servers on the network to identify the application and assign an appropriate QOS to the
application request by returning a DCLASS object [BER00] . All fields in the SendingFlowspec can be
set to QOS_NOT_SPECIFIED. The MaxSduSize of sending can be specified by the sending application
if it knows the size; otherwise, the media Maximum Transmission Unit (MTU) size will be used.
Page 53
MIND
1.2
The QoS Packet Scheduler (QoS PS) performs traffic policing on the sending traffic against the
SendingFlowspec, does DSCP marking on the conformant traffic according to its service type and its
DCLASS object, and then submits the packets to the driver of the network interface card to transmit them
on the link. The QoS PS Scheduler implements the QoS traffic control elements, such as packet
scheduling and marking (Section 2.2.2.4). Bear in mind, that flows using qualitative service types are
configured by default in borrow mode with an internal low priority level in the PS. There are cases in
which the default mapping may be ignored using TC API functions (Section 2.2.2.3) for applications that
require further or specific control over traffic control, though, this procedure bypass the policy
mechanism of the QoSSP and corresponding network policy elements and does not fully describe
marking in response to the GQoS API.
Table 2-11 Mapping of AssignQoS Unconfirmed ESI Primitive and GQoS Calls
BRENTA Service
Primitives
AssignQoS,
GQoS API
Description
Related parameters
Corresponding calls,
upcalls & notifications
unconfirmed service
•
AssignQoS.request
WSAconnect();
Flowspec->
ServiceType=Servicetype
_qualitive
•
AssignQoS.indication
not possible
This call provides the QoS parameters Socket
created
via
of a sender’s flow (sending flowspec).
WSASocket(),
Peer
host
address, the lpSQoS structure
This socket is used for both, data
transfer and QoS setup. The lpSQoS
structure is used to specify the sending
flowspec with its traffic characteristics
and request a qualitative service type.
All the parameters must be set to
QOS_NOT_SPECIFIED.
A related QoS Event notification is not
available.
In Table 2-11, the GQoS procedures equivalent to the AssignQoS ESI function is presented. The use of
DiffServ as a QoSSP does not provide an indication to the peer end system of the establishing of a QoS
aware flow, therefore the corresponding mapping to AssignQoS.indication is not possible.
There are a number of ways to close an QOS-enabled connection. Generally, any event that closes a
socket also ends RSVP SP servicing on the socket. Examples of events that cause the RSVP SP to stop
providing QOS functionality on a socket include the use of closesocket, that causes the socket handle to
become de-located so that the application can no longer reference, and shutdown to disable sends or
receives on a socket. In general, shutting down a socket connection involves an exchange of protocol
messages between the two endpoints, this is known as a shutdown sequence. Two general classes of
shutdown sequences are possible when closing a socket: graceful and abortive. In a graceful shutdown
sequence, any data that has been queued but not yet transmitted can be sent prior to the connection being
closed. In an abortive shutdown, any unsent data is lost. The occurrence of a shutdown sequence (graceful
or abortive) can be used to provide an FD_CLOSE indication to the associated applications representing
that a shutdown initiated at the peer host is in progress.
One technique that can be used to minimise the chance of problems occurring during connection
teardown is to avoid relying on an implicit shutdown being initiated by closesocket. Instead, first, use of
shutdown function that causes an FD_CLOSE indication to be received by the peer application indicating
that all pending data has been received. Immediately after FD_CLOSE indication, the peer application
could send any remaining response data to its corresponding application, invoking the shutdown function
to indicate that it has no more data to send and finally requesting the socket closing. Lastly, the
corresponding application can close its socket safely from data loss.
In Table 2-12 is shown the mapping of the RealeseQoS service primitives and shutdown Winsock2 calls
that initiates the shutdown sequence.
Page 54
MIND
1.2
In Section 2.2 we described the QoS support in Linux and Windows Operating Systems which was chose
for future implementation of the Enhanced Socket Interface of BRENTA. Also, the mapping of the ESI
functions to LINUX and Windows function calls was done. The following section shows how different
aspects of mobile Ad Hoc networks affect the support of QoS and how it influences the BRAIN End
Terminal Architecture.
Table 2-12 Mapping of the ESI Primitives and GQoS Calls for the Release of Reservations
BRENTA Service
Primitives
AssignQoS,
GQoS API
Description
Related parameters
Corresponding calls,
upcalls & notifications
unconfirmed service
•
AssignQoS.request
WSAconnect();
Flowspec->
ServiceType=Servicetype
_qualitive
•
AssignQoS.indication
not possible
This call provides the QoS parameters Socket created via
of a sender’s flow (sending flowspec).
WSASocket(), Peer host
address, the lpSQoS structure
This socket is used for both, data
transfer and QoS setup. The lpSQoS
structure is used to specify the sending
flowspec with its traffic characteristics
and request a qualitative service type.
All the parameters must be set to
QOS_NOT_SPECIFIED.
A related QoS Event notification is not
available.
2.3 Ad Hoc and QoS Aspects
Mobile Ad Hoc Networks (MANETs) consist of a collection of mobile wireless nodes that dynamically
create a network without the assistance of any infrastructure or administrative support. Integration of
MANETs with fixed access networks has a special interest to MIND project for the extension of Mobile
IP based networks that offer broadband multimedia services. In this sense, the participants of WP1 had
identified a set of usage scenarios based on user activities, derived business models and a methodology
for flexible service provision [MIT02], [TOM02].
In these scenarios, the user has access to different services through a diversity of interconnected networks
(fixed, wireless access and Ad Hoc networks) using an adapted end-terminal. The terminal is a Personal
Wireless Assistant (PWA) based on an end-terminal architecture defined in the BRAIN project [BD22].
The BRENTA was designed in BRAIN for providing applications with QoS adaptation and transparent
mobility management mechanisms.
2.3.1 MIND Project Vision
MIND provides a vision of a path towards wireless communications beyond 3G systems in which
interconnected IP-based networks will be accessed through a variety of technologies. Current and future
networks will be heterogeneous showing fair performance variations. Lack of network resources in
wireless environments will limit and affect the behaviour of the applications and the experience of the
users of available services.
The lack of information about the global behaviour of the network, mobility of terminals, vertical and
horizontal handovers between different network technologies and operators would make difficult to
establish a predictable end-to-end QoS provision. Then, knowledge about the usage of resources by
applications, adaptation mechanisms in multimedia distributed applications, resource and mobility
management at the terminal will help to provide this predictable end-to-end QoS provision. An end
terminal with some of these qualities has been defined in BRAIN and must be adapted or modified to the
new scenarios defined in MIND.
Page 55
MIND
1.2
In MIND, the traditional access networks of wireless communications systems (consisted in static,
planned and secure nodes) might be extended by wireless mobile nodes that are not managed by the
original network operator. These mobile nodes constitute mobile Ad Hoc and self-organising networks.
2.3.2 Features of Mobile Ad Hoc Networks
Ad Hoc networks are self-creating, self-organising and self-administering. They are created solely by the
interactions among their constituent wireless mobile nodes. Only such interactions are used to provide the
necessary control and administration functions on such networks.
MANETs can be created and used “any time and anywhere”. They do not operate under the limitations of
a fixed topology in hostile and infrastructureless environments offering exclusive benefits, e.g., robust
adaptation to changing network conditions and topologies. These advantages raised interest among
military and rescue organisations first and then some commercial applications emerged (e.g., home and
office networking).
2.3.2.1 General Features of Ad Hoc Networks
The main challenge that MANETs has to overcome is the unpredictability of his network topology. The
topology of these networks not only depends on the freely variable mobility of each node; it also depends
on the radio electrical environment behaviour (radio interference’s, multi-path propagation, signal fading,
etc) that affects the links among them.
Since the nodes in a MANET may move often, it is necessary to deploy and use efficient routing protocol.
These must be able to find rapidly loop-free path between a source-destination pair. The search of
legitimate routes is a task that must be resolved before the occurrence of an important topology change.
Numerous routing protocols have been developed for MANET to resolve this problem and deal with other
typical problems described in the following paragraphs ([FEE99], [RT99], [MIS99], [MAN]).
There are several interesting problems that affect and challenge the mobile Ad Hoc networking at
different layers of the protocol stack. Beginning at the physical layer, the channel bandwidth is a scare
vital resource. It has limited bandwidth and hostile transmission characteristics commented above.
The lack of fixed infrastructure in MANET means that there is no dedicated entity to manage the channel
resources for network like the base station does at the radio access network. It induces the “hidden
terminal problem” that invalidate the usage of traditional carrier sensing techniques. Therefore, carefully
designed distributed medium access techniques must be used for management of channel resources. In
addition, Medium Access Control (MAC) protocols should be fair sharing the bandwidth resources
avoiding the disproportionate usage of the channels by some node and must provide mechanisms for fast
recovery from the packet collisions.
Due to the unpredictability of the topology changes in MANET it is necessary to employ very effective
routing protocols at the network layer, i.e., the amount and frequency of the information exchanged in
each topology update by these routing protocols are critical considerations due to the impact on the whole
network resources and QoS provisioning. At the transport layer of MANET, packet losses can occur by
transmission errors and congestion as well as the node mobility. The traditional implementation of TCP
deal with the losses related with congestion increasing the performance of the transport service on the
fixed network, but affects negatively the throughput in other mobile networks. New transport protocols or
modification have to be made to detect other types of packet losses than congestion ([LS01], [CRVP01]).
Other important aspects must be taken into account in a whole development and implantation of a
MANET like security and power consumption management. It is necessary to incorporate mechanisms to
protect both, the data transmitted on the wireless link and relayed by intermediate nodes and the
operational integrity of the routing protocols against deliberate attacks. The reduction of the expense of
energy is an important issue at all layers of the protocol stack of the mobile node powered by batteries
[TOH01] .
2.3.2.2 QoS Issues
All the challenges described above that must be overcome in MANET affect the service transportation
provided for the data traffic in terms of delay, available bandwidth, probability of packet loss, etc. These
Page 56
MIND
1.2
parameters define the degree of the End-to-End Quality of Service Transportation provided by the nodes
and are affected by additional factors than the overhead of the routing protocol and the time of routing
convergence. The accurate information of the current local and global network state and the
computational complexity of route selection with the best QoS offer must be taken into consideration.
At link-level, it is necessary to develop and employ retransmission schemes due to the error-prone nature
on wireless links. The choice of the retransmission scheme depends on the nature of packets being
retransmitted (i.e., TCP connection and UDP media flows could have different delay requirements), the
delay of the wireless channel and the energy consumption policy.
At network level, a loop-free path between a source-destination pair is impossible to find if the changes in
the network topology occur too frequently that the topology updates can’t be propagated to all pertinent
nodes. Then, it is necessary that the topology changes occur sufficiently slow to allow the distribution of
all topology updates at specific interval of time. This degree of stability, know as combinatorial stability,
is a critical consideration for QoS in MANET[CHEN99]. There are a lot of Ad Hoc routing protocols
proposed to work under different degree of stability, but in general, these are classified in two groups:
proactive and reactive protocols. Proactive protocols exchange information periodically to detect changes
in the topology of the network. The amount and frequency of each topology update may produce a
significant overhead reducing the resources available in the whole network. The reactive protocol search a
path just when is required preserving the available bandwidth but increases the route acquisition time and
the end-to-end delay for the QoS provisioning. QoS Routing process is another interesting routing
solution (actually discussed in WP2). QoS routing process find a suitable path to be used by a flow with
requested QoS guarantees using link state information, but the route computation with this strategy may
take too long or may be complex. Another routing method to reduce QoS violations in Ad Hoc networks
is the simultaneous use of alternatives routes, especially if these routes are disjoint, to increase the
throughput of a flow [KT00]. In general, the global state information exchanged during the topology
update may never be accurate. Moreover, routing in Ad Hoc networks consume network bandwidth, CPU
capacity and other local resources and increase the delay jitter experienced that must be kept under a
bound to satisfy the real-time traffic.
After finding a route (by mean of Ad Hoc routing protocols) it could be necessary to implement a QoS
mechanism to take advantage of the localised resource of QoS flows. It could be done per flow basis
using traditional signalling mechanisms like RSVP, but this protocol is not suitable in MANET;
reservations by this protocols could take too much time to establish a path with enough resources in
MANET with high mobility. Also, it introduces overhead to the network. By the other hand, QoS support
by means of service differentiation (applying the same per hop behaviour to similar marked packets) scale
better and does not overhead the network.
At higher layers, new transport protocols are necessary or modification have to be made to react properly
distinguish between loss of packet caused by transmission errors (as well as the node mobility) rather than
congestion (the regular problem in fixed networks). By way of a session negotiation the applications can
agree to use some special encoding techniques improving the packet loss recovery, e.g., using Priority
Encoding Transmission [KT00].
2.3.2.3 Roles of an Ad Hoc Node
In Ad Hoc networks, the node could operate as (i) an end terminal and (ii) router, both at the same time.
Mainly, in the interconnection of this kind of node is supported the current topology of an Ad Hoc
network. Due its relaying capabilities, the energy expense of the mobile node powered by batteries is an
important issue that affects the topology of the network and, also, the offering of QoS [TOH01] .
Therefore, it is convenient to use the shortest path between a source-destination pair to minimise the
overall power consumption during the routing process or use an alternative route in which intermediate
nodes have enough power to expend supporting this activity for enough time.
Sometimes, the latter is difficult or limited when just only one node acts as (iii) a gateway between the Ad
Hoc network and a fixed radio access network. In MIND project, this gateway allows the exchange of
packets between Access Networks to the Internet and the Ad Hoc network, the use of external
administrative functionalities (e.g. DNS) and the seamless handoff of visiting mobile nodes. Taking these
considerations into account, a mobile node acting as a gateway could become a bottleneck or a single
point of failure without sufficient local resources. Considering all these constrains, it is important to
Page 57
MIND
1.2
extend the power economy requirement to other layers of the protocol stack to guarantee End-to-End QoS
provision.
2.3.2.4 Basic Requirements of Ad Hoc End Terminals
After the description of the main features of Ad Hoc networks, some basic requirements could be derived
for Ad Hoc terminal in the context of MIND project:
•
Usability: In general, the mobile users have a little technical knowledge about the related issues
above mentioned. They are not expert; therefore the operation of end terminals must be as intuitive as
possible in Ad Hoc environments. Autoconfiguration by means of DHCP or IPv6 stateless
autoconfiguration are useful approach to resolve this issue, but in some situations, some degree of
configuration could be available to adjust the use of the terminal to the user’s preference.
•
Service Discovery: When power ups a terminal in an Ad Hoc network or at the end of a handover
process to a MANET of a mobile node, the visiting node don’t know the available services and where
they are located, then a service discovery mechanism must be necessary to find them. If access to
home network resources is used to request these services, the running applications on mobile host
experience increased latency (such as name server, file server, etc.) through multiple links and
routers. Therefore, these services could be provided as near as possible to the Ad Hoc node. Nodes
must co-operate to provide these services in a decentralised way or with the assistance of a fixed
infrastructure in which the Ad Hoc network is attached to. It will provide faster access to network
resources and reduce load on routers and networks.
•
Capabilities of adaptation: Frequent changes in the network topology due to the error-prone nature
of the wireless links and the (intra and inter network) mobility of the nodes makes necessary to
introduce adaptation mechanism to adapt the application behaviour to the resource availability of the
network. Therefore, adaptive media transport must be included for continues media stream
•
Partition and merges: Frequent changes of the topology could produce partitions of the Ad Hoc
network disrupting active session. Partition in Ad Hoc networks context means the division of a
whole network in two or more isolated parts [CN01]. An interesting example was introduced in the
leisure scenario described in [MIT02], [TOM02]. Nodes in the Ad Hoc network should cooperate to
re-establish the disrupted sessions and services with or without the assistance of additional
infrastructure (fixed wireless or wired networks) when partitions or merges occur.
•
Relaying foreign traffic: Nodes have to develop different roles in Ad Hoc networks. They act as end
systems as well as intermediate nodes (routers). For relaying foreign traffic, routing functionalities
must be introduced in BRENTA to assure this facility. As described before (in features of Ad Hoc
networks), the routing process in MANETs deal with the stability of the network topology and
scalability. Therefore, the routing process must be fast for updating the network topology before of a
new topological event and the amount of information distributed per node must be as reduced as
possible to avoid the waste of scarce bandwidth. Broadcast and Multicast routing capabilities
carefully designed for Ad Hoc network also should be included.
•
Gateway functionality: The vision of MIND project is the extension of the traditional wireless access
network with Ad Hoc networks. To achieve this between both networks, gateway functionality must
be developed by Ad Hoc nodes. This is another additional function that Ad Hoc nodes require to
perform. Due to the mobility of the node and power limitation, an Ad Hoc gateway is more
vulnerable than other Ad Hoc nodes. Acting as a single point of interaction between both networks
the Ad Hoc gateway becomes a bottleneck or single point of failure, also. So, alternative Ad Hoc
gateways (avoid single gateway) in the MANET should be necessary to guarantee the integration
with the whole Internet.
•
Quality of Service support: BRENTA supports different kinds of applications, but specially, it is
designed for real time interactive multimedia communications. To assure the support of these kinds
of services in the Ad Hoc portion of the network where communication pairs reside, Quality of
Service support should be offered for End-to-End QoS support.
Page 58
MIND
1.2
•
Mobility Management functionality: End systems in MIND have the capacity to change their point of
attachment to the network while they are moving. In a heterogeneous environment of networks the
mobility management must be included in the MANET to guarantee the continuous operation of the
active session of nodes arriving or leaving the attached Ad Hoc network. This requirement involves
the ability of the end terminal to detect the change of network, the presence of Foreign Agents and
the registration/deregistration to mobility agents.
•
Management of energy consumption: Limited energy resources is one of the major constrains in Ad
Hoc networks with autonomous mobile nodes. Routing, encoding techniques, high compression for
bandwidth conservation, radio transmission and another tasks developed by the Ad Hoc nodes
increase their energy consumption. Therefore, methods for energy conservation should be used in
each layers and functionalities of the system architecture. Increasing the shared information between
layers of the host protocol stack is useful in order to predict the possible changes in the available
resources and provide adequate QoS service to applications.
Additional basic requirements have to take into consideration security and accounting aspects that are
treated with more detail in the next chapters. Most of the aforementioned requirements are part of the
research activities developed in WP1, WP2 and tested in WP6.
2.3.3 QoS Architecture Proposals
There are two complementary proposed approaches for providing QoS support in traditional networks
that are subject of study to adapt these in mobile fixed an Ad Hoc networks. An approach based on
resource reservation provide QoS support by performing admission control and reserving resources for
flows on an end-to-end basis. A differentiated service approach provides QoS support by providing
individual packets with different per-hop behaviours at a given node based on a type of service markings
(e.g., DSCP) on individual packets. In this section we explain some of the proposed adaptation of these
approaches to Ad Hoc networks.
2.3.3.1 Integrated Services on Ad Hoc Networks
a) Dynamic Resource Reservation Protocol (dRSVP)
Dynamic Resource Reservation Protocol [MST01] is an approach to provide QoS in Ad Hoc networks by
mean of modifications to RSVP. With this solution, resource reservations are requested defining ranges
of values for reservation parameters, rather than a single value for each of the parameters used to describe
the required QoS service. This approach show that treating a reservation as a request for service
“somewhere” within a specified range, it is possible to provide the necessary flexibility to deal with all
type of network dynamics, e.g., changes in network topology due node movement or changeable link
layer behaviour and the variable demand of resources by applications. Hence, as available resources
change, the network can readjust allocations within the reservation range.
Several extensions were made to RSVP to develop the concept of dRSVP: an additional flow
specification in RESV messages and an extra traffic specification in PATH messages are used to describe
ranges of traffic flows during the reservation process; a measurement specification from the receiver and
the sender, added to RESV message and ResvNotification respectively, to be used by intermediate nodes
in the data path to learn about downstream and upstream resource bottlenecks and define the appropriate
amount of local resources to be allocated during the reservation process; also, the last feature required
new admission control processing and bandwidth allocation.
In order to support the inclusion of range-based reservation an extended API was implemented allowing
to QoS aware application to be capable of adapting at run time to varying network.
b) In-band signalling system for QoS Support in Ad Hoc Network (INSIGNIA)
INSIGNIA is an in-band signalling system that supports adaptive reservation-based services in mobile Ad
Hoc networks [INSIG]. INSIGNIA is a general-purpose approach to delivering QoS in mobile Ad Hoc,
i.e., it interoperates transparently with several routing Ad Hoc protocol employed in the MANET.
Reservation based on this signalling system, responds dynamically to topology and resource changes in
an appropriate manner allowing fast establishing, restoring, adapting, and removing of end-to-end
reservations. The key components of INSIGNIA are its in-band signalling system that offers a faster
Page 59
MIND
1.2
reservation process than classic reservation mechanism (e.g., RSVP), and reservation and adaptation
algorithms specifically designed to deliver adaptive service. The resource management is soft-state
avoiding the overhead with the use of extra signalling for the release of resources.
The signalling system supports a number of protocol commands carried in-band with the data and
encoded using the IP option field of IPv4 datagrams. This in-band information is snooped as data packets
traverse intermediate Ad Hoc nodes and used to maintain soft-state reservations in support of flows. As
depicted in Figure 2-15, the INSIGNIA IP option supports the establishment of adaptive reservationbased services and includes service mode, payload type, bandwidth indicator, and bandwidth request
fields. A packet carrying a reservation request has its service mode set to reservation mode (RES) and its
payload set to base QoS (BQ) or enhanced QoS (EQ). Each IP packet is self-contained in that it carries all
the necessary state information to establish and maintain reservations. This information includes an
explicit bandwidth request.
Bottleneck Node
a)
MIN
MAX
d
MIN
MAX
s
QoS report message
b)
New Route
INSIGNIA IP option field
RES/BE
BQ/EQ
MAX/MIN
Service Payload Bandwidth
Mode
type
indicator
Service Mode
RES: Reservation
BE: Best effort
MAX
MIN
Bandwidth
Request
Bandwidth Indicator
MAX: route support EQ
MIN: route doesn’t support EQ
Payload Type
BQ: Base QoS
EQ: Enhanced QoS
Figure 2-15 a) Fast Restoration of Reservations with INSIGNIA, b) INSIGNIA IP Option Field
When a reservation packet is received at a destination, the status of the reservation phase is determined by
checking the service mode bit in the IP option field. It could be set to RES for reservation or BE for best
effort or no reservation. The INSIGNIA IP option also includes a bandwidth indicator bit that can be set
to MAX or MIN representing maximal reservation or minimal reservation service mode. More
information about the interpretation of the INSIGNIA option field and the command protocols is
available at [LAZC99]. A source node continuously sends packets with the reservation request bit set
until the destination node completes the reservation set-up phase by informing the source node of the
status of the reservation establishment using a QoS reporting mechanism.
INSIGNIA also performs fast restoration, when the availability of resources or data-path changes, Figure
2-15. Consequently, reservation-based flows are often re-routed within the lifetime of ongoing sessions.
The goal of restoration is to re-establish reservations as quickly as possible. Re-routing active flows
involves the Ad Hoc routing protocol, admission control, and resource reservation for nodes along the
“new path.” Fast restoration mechanisms also call for the removal of old reservation state at nodes along
the “old path.”
Insignia supports end-to-end adaptation monitoring network dynamics and adapting flows in response to
observe changes based on a user-supplied adaptation policy. Flow reception quality is monitored at the
destination node and reported to the sender; based on adaptation policy, actions are taken to adapt flows
Page 60
MIND
1.2
under certain observed conditions. For example, one adaptation policy could be to scale down adaptive
flows to their base QoS requirements in response to degrade conditions or to always scale up adaptive
flows whenever resources become available. The action taken is conditional on that is programmed into
the adaptation policy by the application; the application is free to program its own adaptation policy,
which is executed by INSIGNIA through interaction of the destination and source nodes.
Despite the original features introduced in INSIGNIA and the tested improvements on performance of
UDP and TCP applications, the storage and processing overhead for each intermediate Ad Hoc node is an
undesirable feature in this kind of system, since the nodes have to build and maintain state information
which increases with the number of flows.
2.3.3.2 Differentiated Services in Ad Hoc networks
Aggregate mechanism for traffic handle, like provided by DiffServ QoS architecture seems to be
lightweight model for the intermediate nodes of Ad Hoc networks since individual state flows are
aggregated into set of flows. This could be a potential model for MANETs, but the definition of
traditional component of a DiffServ domain, like the ingress, the egress and core routers is no clear
because of the variable topology of the network. More over, the concept of the Service Level Agreement
that defines the contract between the costumer and the clients is not applicable in Ad Hoc networks,
because there is no a service provider. In that case, the problem of providing QoS guarantees becomes
very complex. Every one in the network would try to use the resources, as much is possible.
Under this condition, the classification of traffic into priorities to perform the aggregation of flows makes
sense if priorities can be assigned at the application level that cannot be modified by the user and, also it
could rely on the situations where the network is used. For example, a network used for rescue operations
can have voice traffic with different priorities depending upon the urgency of the message.
Despite of these limitations, DiffServ seems to fit well to the Ad Hoc networks features that make to have
sense the implementation of this architecture over MANETs: the suitability of lightweight protocol in the
core of the MANET, the easy implementation of some per hop behaviours like Assured Services that
provides more qualitative than quantitative guarantees and the functionalities that develop the Ad Hoc
node as router and host. Next, some models based on service differentiation are commented.
a) Flexible Quality of Service Model for MANET (FQMM)
Taking these aspects into account, a QoS model was developed for small to medium networks that defines
three kinds of nodes as DiffServ. In this architecture called Flexible Quality of Service Model for
MANET (FQMM), the “ingress node” is the host that send data, classifying, marking and policing
packets; the “interior nodes” are the nodes that forward the marked packets via a certain Per Hop
Behaviour, and the “egress node” is a destination node [XSLC00]. Regardless of its DiffServ orientation,
this model proposes a hybrid per-class and per-flow provisioning scheme. Traffic of highest priority (the
small fraction of the traffic) is given per-flow provisioning while other priority classes are given per-class
provisioning. A traffic conditioner is put at the ingress node to policy the originated traffic according to a
traffic profile that keep consistent differentiation between sessions which could be per-flow or peraggregate of flows and adapts to the dynamic behaviour of the network.
Assured Services is the Per Hop Behaviour implemented in the core of the network to provide service
differentiation since throughput is the QoS parameter of interest. The flows used to test the model are
TCP sessions with a given target rate and the traffic profile is configured according to this parameter. The
traffic conditioner at the ingress node marks the packets as IN if the outgoing data of a particular flow
conforms to the traffic profile, otherwise as OUT with a probability. The interior nodes adopted FIFO
scheduling and RED with In/Out bit buffer management scheme. With the combination of the traffic
conditioner at the edge of the network and RIO queue discipline at the core, the service differentiated is
provided.
b) Stateless Wireless Ad Hoc Networks (SWAN)
Taking a different approach from the precedent models, SWAN is a stateless network model that argues
the use of distributed control algorithms to deliver service differentiation in MANETs in a simple,
scalable and robust manner [ACVS02]. This proposed architecture handle both real time UDP traffic, and
best effort UDP and TCP traffic without the need for the management of per-flow state information in the
Page 61
MIND
1.2
network. Also, SWAN supports per-hop and end-to-end control algorithms that primarily rely on the
efficient operation of TCP/IP protocols. In particular, SWAN uses local rate control for best-effort traffic,
and sender-based admission control for real-time UDP traffic. Explicit Congestion Notification (ECN) is
used to dynamically regulate admitted real-time sessions during network changes caused by mobility or
traffic overload conditions.
The rate regulation of best effort traffic in SWAN is developed by a classifier and a shaper that operate
between the IP and best effort MAC layers. The classifier is capable of differentiating real-time and best
effort packets, forcing the shaper to process best effort packets but not real-time packets. The purpose of
the shaper is to delay best effort packets in conformance with the rate calculated by the rate controller.
Each node in the mobile Ad Hoc network independently regulates best effort traffic. The rate controller
determines the departure rate of the shaper using a rate control algorithm based on feedback from the
MAC. This feedback measure represents the packet delay measured by the MAC layer. Each node
increases its rate control gradually every period of T seconds (additive increase with increment rate of c
Kbps) until the packet delays become excessive. The rate controller detects excessive delays when the
packets have greater delays than a threshold delay. As soon as the rate controller detects excessive delays,
it backs off the rate (multiplicative decrease by r percent). The threshold delay d is based on the real-time
delay requirements of applications in wireless network, and the period T, in which the shaping rate is
adjusted, could be small enough to be responsive to the dynamics of mobile Ad Hoc networks. In this
way, bandwidth and delay bound requirements of real-time traffic can be adequately adjusted, while best
effort traffic can efficiently utilise any remaining bandwidth. However, to fully support real-time traffic,
local rate control of best effort traffic is insufficient. There is also a need to support admission control.
The admission control in SWAN is based on the sender; to admit new session, the source node sends a
probing request towards the destination node to measure the end to end bandwidth availability. The
probing request packet is a UDP control packet that each intermediate node intercepts and updates a field
if the value registered is more than local bandwidth. The local bandwidth is determinate listening to
packets sent within their radio transmission range. Finally, the destination node sends a probing response
packet back to the source node with the bottleneck field copied from the probing request message
received by the destination node. Once the source node receives the probing response packet, it can
execute the simple source-based admission control test by comparing the end-to-end bandwidth
availability and the bandwidth requirement for the new real-time session.
2.3.3.3 End-to-End Adaptive Applications
In absence of QoS mechanism at lower layers of the TCP/IP architecture, multimedia applications can
take advantage of feedback information provided by their peers to dynamically adapt to the reported
network conditions proper of Ad Hoc networks. In this extent, sender multimedia application could use
QoS feedback information from the receivers to select the most appropriate A/V coding scheme. The
selection of alternative coding schemes is based on the principle of media scaling by which the bit-rate
(the quality) of an audio or a video stream is varied to be consistent with the available bandwidth.
Applications, as presented in [KAZ99], constantly monitors the QoS parameters of received flows (e.g.,
packet lost, delay jitter, etc) deriving this information from the sequence number of packets and related
timestamp information reported by the Real Time Transport Protocol. The QoS parameters are frequently
reported to the sender application to be aware of the conditions at the receiver end and to take a decision
with respect to the current delivery of the flows, i.e., to leave unchangeable the actual transmission
parameters or to change them, for example, reducing the sampling rate value of the audio source or
reducing the packet size.
Also, applications in QoS models as dRSVP and INSIGNIA (Section 2.3.3.1) are provided with APIs that
facilitate the reception of QoS information from the network and peer applications to adapt its behaviour
to the current status of the network following different the application’s adaptation policy. For example,
in INSIGNIA approach, after receiving a QoS report from the destination, the source could decide to
scale down and starts transmitting the Enhanced QoS packets in best effort mode (i.e., the service mode
bit is set to BE) or will scale back by dropping the EQ packets because it is not able to tolerate best effort
delivery.
Page 62
MIND
1.2
2.3.4 Terminal Architecture Approach Design for Ad Hoc Node
In this section we describe the current tendencies in architectural design of Ad Hoc node, which take care
of the challenges presented in Ad Hoc networks.
2.3.4.1 MANET Terminal Architecture and the IETF
Besides the effort to define suitable QoS models in Ad Hoc networks, some proposals for end terminal
architectures for Ad Hoc networks were proposed recently to overcome the challenges described above.
In the context of IETF MANET WG (the working group related with the developing and evolving of
routing protocols for Ad Hoc network) a different design philosophy for Ad Hoc node architecture was
discussed. It was argue that the differences in resource constrains of Ad Hoc network and the Internet
lead the necessity of reducing the horizontal communication requirements of the protocols and the
increasing some of the vertical communication requirements within the protocol stack.
Designing the protocol stack in this fashion allow a logical coupling of the layers, i.e., the increased
vertical communication permits upper-layer protocols to bind more closely with lower-layer protocols, in
this manner, some of the inefficiencies of the traditional horizontal communication could be removed. In
this extent, some proposals where done developing special interfaces between link and IP layers showing
possible improvement of the performance during the data transfer. Also, a layer 3 protocol named Internet
MANET Encapsulation Protocol (IMEP) was implemented following this philosophy [JIC99]. IMEP
augments IP functionality of the host to support IP forwarding through a multi technology “routing
fabric”.
Application Layer
Application Layer
Application Layer
Application Layer
Physical Layer
Physical Layer
Physical Layer
Physical Layer
a)
b)
Figure 2-16 a) Fixed Internet Protocol Design b) MANET Protocol Design Approach
The difference between the Internet design and the MANET design philosophies is depicted in Figure
2-16. The strict protocol-layer separation that guide the development in Internet minimise the shared
evolution of the adjacent layers and simplifying the protocol design, despite it this increase the amount of
information interchanged among corresponding layers. The design approach proposed in MANET runs
counter to that traditional design and is unwelcome when interoperability with the existing network is
desired. Due this constrain, this last approach is commonly adopted in lower layers (e.g., IP and link
layers) which extent of interoperability is limited.
2.3.4.2 Adaptive Cross-layer Design
Following the ideas introduced in the MANET working group, additional arguments were derived from
the analysis of different QoS support approach in Ad Hoc networks that sustain the philosophy of a crosslayer design [GW02]. However the Internet paradigm simplified the network design and led to robust
scalable protocols, the inflexibility of these paradigm results in suboptimal performance for Ad Hoc
wireless networks. In order to affront the set of issues described in Section 2.3.2.2, an adaptive crosslayer protocol design that supports adaptation and optimisation across multiple layers of the protocol
stack would be necessary.
In an adaptive cross-layer protocol stack, for example, the link layer can adapt rate, power and coding to
meet the requirements of the application given the current channel and network conditions. The MAC
layer can adapt based on underlying link interferences conditions, bit priorities and delay constrains.
Adaptive routing protocols can be developed based on current link, network and traffic conditions. Lastly,
the application layer can utilise a notion of Soft QoS that adapts to the underlying network conditions to
Page 63
MIND
1.2
deliver the highest possible application quality. Hence, is important that network protocols at layer could
be within an integrated and hierarchical framework to take advantage of the interrelation between them.
Adaptation of each layer of the protocol stack should compensate for variations at that layer based on the
time scale of these variations, i.e., variations experienced at the link layer are in various orders faster than
changes experienced at application layer. This difference between the time scales of network variations
suggests that each layer should try to compensate at that layer first. If it results unsuccessfully, then
information should be exchanged with other layers. Adaptation at this next layer may then at least
mitigate the problem that could not be resolved through local adaptation. Although the benefit is could be
reached with an adaptive cross-layer design, this integrated approach of propose represent a bigger
challenge of protocol design.
The QoS architectures presented in precedent sections could be good examples for the validation of the
adaptive cross-layer design philosophy. For example, end-to-end adaptive multimedia applications could
be benefit from network layer if QoS reporting functions were incorporated to this layer or it could
provide a suitable path between the pairs. Similar advantage could be obtained if the link layer could
provide better than best effort service and QoS reporting functions for the rate controller in SWAN
model. INSIGNIA, also, uses a MAC protocol with service differentiation support to send packets related
to QoS reports, reservation and routing control with a higher priority than packets that tolerate a best
effort service.
We can conclude this section arguing that QoS support solutions and its end terminal architecture
examined in Section 2.3.3 trend to some degree of adaptive cross layer design. Providing QoS support in
Ad Hoc networks is accomplished attempting to resolve the following problems [MST01]:
•
The QoS routing problem: how to find a route through the network that is capable of supporting
a requested level of QoS.
•
The QoS maintenance problem: how to ensure that new routes that can support existing QoS
commitments are available or can by quickly found when network topology changes.
•
The variable resource problem: how to respond to changes in available resources, either as the
result of changes in network topology or link variations within a given route.
An integral solution could attempt to resolve all these problems, but as we show there are QoS
architectures that do not depend on QoS routing to provide a better service, e.g., FQMM, SWAN and the
implementation of the principle of media scaling. However, these proposals could obtain benefits if QoS
routing is present. Also, solutions to the variable resource problem obviate the need to solve the QoS
maintenance problem, but these require different methods of adaptation by means of feedback from pair
entities (as the case of INSIGNIA) or lower layers (as in SWAN), admission control mechanisms and
policies for the dynamic regulation of traffic injected to the network.
2.3.5 BRENTA Features in the Context of Ad Hoc Networks
After a review of the QoS aspects in Ad Hoc networks and the examination of the current proposed
solutions, an evaluation of BRENTA design is made in the context of Ad Hoc networks in the present
section.
Key features of BRENTA design are introduced in Section 1.3.2. The main characteristics of its design
are: modularity, openness and flexibility. If a decision is taken to adopt any of the presented solutions,
there could be some concerns in introducing still novel and not adopted proposals to deal with QoS issues
in Ad Hoc networks; it could affect the openness feature of BRENTA. It is desirable to maintain the
layering paradigm adopted in BRAIN, instead the current trends in using a whole adaptive cross-layer
design in ad hoc networks although we are faced with a number of new problems. In BRENTA, divisions
were made between the different layers of the protocol stack to allow the required independence between
them adding suitable inter-layer interfaces that provide generic information about capabilities being
exchanged across the interfaces using a generic set of parameters.
To this extent, the WP1 is proposing the E2ENP which peer BRENTA applications of type C and QoS
brokers can use for coordinate their attempts to achieve the desired QoS level despite variable conditions
in terminal and networks. In the other hand, it is possible to take advantage of the flexibility and
modularity of BRENTA because it makes possible to use new downloadable codecs proper for variable
transmission media and additional complex middleware could be introduced also.
Page 64
MIND
1.2
Some goals were taken into account when designing BRENTA [BD22] that benefit its use in Ad Hoc
networks as the inclusion of mechanisms for (among others):
•
Local resource management: LMI is provided to the applications to allow the interaction with
the operating system to discover available network and local resources and provides control
functions that allow fine grain control over the behaviour of the terminal. The LMI provides
access to a stack management that contains management objects that represent single
functionalities of the stack and their state
•
Network resource management: the ESI (Section 2.2.4.1) is provided to manage the network
resources that is necessary to provide service guarantees to applications, and
•
QoS orchestration: a QoS broker is in charge to manage and co-ordinate local, network and
remote resources in order to provide predictable End-to-End QoS.
2.3.5.1 Considering Modifications in BRENTA
The mentioned goals identified for provide QoS support to mobile terminals in wireless fixed networks in
BRAIN should be extended to provide QoS support in the extent of mobile Ad Hoc networks. This
implies the possible extension of functionalities and modules that compose the current BRENTA
architecture (as depicted in Figure 2-17 inside dotted boxes).
Application
Type B or C
Application
Type D
Application
Type A
Service User
QoS Broker
GUI
BRAIN
QoS Broker
Local
Management
Interface
Enhanced
Service
Layer
Primitive Mapper
Entity
QoS Mapper Entity
BRAIN Service Interface
TCP
IP Layer
Management
Objects
Link Layer
Management
Objects
Stack Manager at
UDP
Further transport or QoS
Service Provider
IP(v4/v6) with Mobility and Ad Hoc routing support
Service Provider
ES Layer
Management
Objects
Enhanced
Socket Interface
Subnetwork technologies ( e.g., Hiperlan/2, UMTS, Bluetooth )
Data/Networking Plane
QoS and Resource
Management Plane
Figure 2-17 Components Subject to Extension to Adapt BRENTA to Ad Hoc network for QoS
Support
When a mobile terminal is participating in an Ad Hoc network, it requires managing its local resources to
properly interact in the network, therefore additional management objects should be provided in the LMF
to cover new Ad Hoc aspects, also new functions related to the LMI should be added to gain access to
them, e.g. to perform local admission control in ad hoc fringe that benefits the transmission of locally
generated flows instead of others traffic [MD22]. The LMI and the LMF are part of the QoS and
Resource Management plane.
Page 65
MIND
1.2
At the Data/Networking plane, a routing protocol proper for traffic relaying in Ad Hoc network should be
included, also. In [MD21] is available a detailed analysis and comparison of different Ad Hoc routing
protocols that could be considered to develop this function. A QoS SP suitable to Ad Hoc network
domains should be included, which extend the BRAIN service interface. It will affect the ESL in the
sense that the Primitive Mapper and the QoS Mapper entities (Section 2.2.4.1) will be in charge to map
the ESI primitives and relative parameters to the corresponding primitives and parameters that controls
the QoS SP for the Ad Hoc networks.
Also, new primitives could be added or modification could be made to the current primitive in ESI to
allow to adaptive applications to rapidly adapt to the changes in network resources of the Ad Hoc network
domain (as in INSIGNIA and dRSVP approaches).
Page 66
MIND
1.2
3. Domain Model
The purpose of the Domain Model (DM) is to describe the MIND access network architecture in a way
that allows further developments and refinements of that architecture. As such the DM gives an
abstraction of the MIND architecture. Mainly two issues are relevant and should be expressed by means
of the DM. It is considered necessary:
•
To find a way to describe the various network configurations of routers as they can be formed
without listing example configurations;
•
To identify the responsibilities of which operators of nodes can/should care, which, as a result of
any technical realisation, encompasses restrictions on the usable devices, functionalities, etc.;
This includes responsibilities that these operators have to obey offline (e.g. subscriptions,
approval procedures, etc.).
On the other hand, the DM should describe sufficiently precisely the resulting MIND access network
architecture, so that suggestions for security and accounting mechanisms or the E2ENP can be expressed.
These suggestions are concerned about:
•
The trusts that needs to be achieved in flexible network configurations amongst administrative
domains are key; which
•
Subsequently raises requirements on the technical realisation, but also on the responsibilities that
may also be obeyed but cannot (yet) be expressed in specific functionality (e.g. certification of
routers according to specific standards);
Based on the nomadic worker scenario the DM is described. This scenario is one out of three that have
been produced in MIND earlier [MIT02], [TOM02]. The other two are referred to as the leisure time and
the medical care scenarios. The domain model described here has not been proven to cover the leisure
time and the medical care scenarios. However, the DM has been discussed in the MIND Project and the
developers of the network architecture agreed that it is a suitable abstraction.
In this section, first the usage scenario is described based on which the DM has been
developed (Section 3.1). Before the DM is presented, Section 3.2 presents the main properties to which
the constituent of domain models in general is related. The Section 3.3 presents subsequently the DM in
two forms: one is the basic DM, which encompasses (mobile) access networks; the other includes Ad Hoc
networks. Later in this document (Chapter 4) the domain model is again extended to cover further aspects
relevant to the E2ENP.
3.1 Usage Scenarios
There are three usage scenarios that originally come from Information Society Technologies (IST)
BRAIN project [BRAIN1.2], then are extended and deployed in MIND. The scenarios demonstrate how
the new technology, especially the most innovative elements of MIND proposal, could be integrated in
everyday life and integrate new attractive services. Mobility, inclusion of mobile Ad Hoc sub-networks in
the general MIND network and many kinds of value added services (e.g. security, billing, location-based
services, QoS, etc.), most of these new features are covered by the scenarios. On the other side, usage
scenarios describe real environments, in which the future mobile communication systems will be operated
by different service providers co-operatively, and the rich set of information and communication services
can be accessed by users. Therefore, the scenarios are a good start to identify MIND network domain
models, which must be studied from both business model and network technology points of view.
1.
Leisure time: A scenario which demonstrates that users may wish to be connected to
HIPERLAN/2 for low cost and high bandwidth in the home or shopping mall but will also want
to be connected to cellular technologies (e.g. UMTS or GPRS – General Packet Radio Service)
from the same terminal and access the same services. In particular, the users in this scenario
require support for vertical handover between the two technologies.
2.
Nomadic worker: In this scenario we have looked at a future corporate worker, demonstrating
that HIPERLAN/2 may be used as part of office Intranets providing integration with fixed
Intranets. The scenario also produces the idea of profiles – when on company business, a worker
Page 67
MIND
1.2
requires different preferences, charging strategies etc., than when on personal business, but will
want to use only one terminal and access the same basic services such as E-mail.
3.
Medical care: This scenario demonstrates a specialised application of the BRAIN system. The
main point arising from this scenario is that users can have very different priorities for the supply
of the same quality service – in this case the patient being monitored requires absolute priority.
Because of the complexity of each scenario, only a piece of scene in the Nomadic worker scenario has
been used as a sample for further study of domain model in this chapter. The selected short scenario is
described in the following. After that, the business roles of all the participants involved are identified.
3.1.1 Train Scenario
The selected scenario is called “train scenario”. A compact description of this scenario is given below
with no important detail ignored. Please refer to [MIND1.1] for a complete description.
1.
Stephanie is on the train from Frankfurt to Munich for a business trip, she will organise an intrain meeting with colleagues from other companies;
2.
Her PWA (Personal Wireless Assistant) informs her that the train service provider is running a
wireless communication network (e.g. HIPERLAN/2), which is also connected to the Internet;
3.
Stephanie logs into the train network by entering her secure pre-paid account number and sets up
a video conference to the project leader to sort out some minor details;
4.
Her employer is charged by her service provider for the usage of all the services she is using;
5.
The service provider is obliged to pay specified percentages of the charged fees to the holder of
the train network (Deutsche Bahn AG, extended network provider), network provider (TMobile), application service provider (Oracle) and content provider (SAP), respectively;
6.
The network provider and the extended network provider have a contract of the network
connectivity between them;
7.
When the other members gradually join Stephanie in the train, they attach their mobile terminals
to hers to setup a secure wireless Ad Hoc network using the early received temporary session
key which she sent;
8.
Some colleagues connect their terminals to her terminal in order to access the train network and
the Internet because they do only feature short range radio technology (e.g. Bluetooth). In this
case, Stephanie is charged for the usage of the Internet access she is offering for her partners;
9.
By the time they arrive at Munich central station they suspend the session.
According to value chain of MIND business model, the end user, who connects to the access network
through other user’s mobile terminal which features routing functionality, should pay both the basic
charges to the access network provider and an additional fee to the user who relays his packets. This has
been observed, though it is not covered by the train scenario since Stephanie provides the routing service
to her colleagues for free.
3.1.2 Identification of Roles in the Train Scenario
Roles of each participant involved in the scenario are identified in this section. It is an important base to
describe the domain model and further to analyse security threats. Objective is to remove ambiguities on
who participates in the scenario, what responsibilities do they have and which kind of assets should be
considered and protected, etc.
Roles in MIND scenarios generally refer to the characteristic and expected behaviour of individuals, with
special consideration of their responsibilities, rights and interests in our investigations. A role can be
regarded as an abstracted entity that always behaves in a specific way. Table 3-1 lists all the roles that
appear in MIND scenarios.
Page 68
MIND
1.2
Table 3-1 Roles in MIND Scenarios
Abbr.
Role
Description of role
U
User
A user is who really uses the various services.
S5
Subscriber
S has a contract with and pays the bill to his Service Provider.
SP
Service Provider
SP sells prepaid account to or has contract with S and facilitates the
end users to use a set of information and communication services,
which he makes profit of.
ANP
Auxiliary
Network Provider
An individual, whose device acts as a mobile router and provides
access service to the wireless networks of Extended Network Provider
for end users in the scenario, is an ANP.
ENP
Extended
Network Provider
ENP maintains his hot-spot wireless networks and provides access
service to U or ANP.
NP
Network Provider
NP maintains cellular networks and backbone networks and provides
network connectivity to ENP.
ASP
Application
Service Provider
ASP provides various application services, e.g. video conference.
CP
Content Provider
CP provides content service.
I6
Intruder
Intruder aggressively compromises the security goals and regulations.
Only external intruders are categorised as Intruder in this document.
Participants are persons, organisations, or corporations who are involved in the observed scenario. Each
participant can be usually be classified to at least one role; however, in some cases a participant can also
hold two or more different roles. In the scenario, Stephanie acts in two roles, as a User and as an
Auxiliary Network Provider, because she offers routing service to her colleagues who cannot access the
train wireless network directly. Each role’s corresponding participants are identified in Table 3-2.
5
In a very common case, a User and a Subscriber can be the same person.
6
Further investigation is required to differentiate various intruders with clear definitions, like eavesdropper, network
hacker, cracker, etc. On the other side, only external intruders are categorized as Intruder, because every other
participant mentioned above may become an (internal) intruder, which means he can aggressively compromise the
security goals and regulations if he likes to. This document presumes that every other role, besides Intruder, has
potentiality to violate predefined security goals by abusing its functionality. Therefore, breaching security is an
intrinsic part of each role and does not necessarily has to move to another role – Intruder.
Page 69
MIND
1.2
Table 3-2 Identified Roles of Participants in the Train Scenario
Participant
Role
Remark
Stephanie7
U and
ANP
Stephanie is charged for her colleagues and her own usage of the
access service provided by the train network operator.
other colleagues
U
Stephanie’
employers
S
T-Mobile
SP
Deutsche Bahn AG
ENP
It operates the in-train wireless communication network.
T-Mobile
NP
It operates the cellular network and the backbone network.
Oracle
ASP
ASP provides a video conference application service in the scenario.
SAP
CP
CP provides electronic format contents, e.g. technical documents that
are useful for the meeting.
eavesdropper,
hacker, etc.
I
In the scenario Stephanie’s employer pays the bill for her or
reimburses what she has paid for the usage of the services.
3.2 Principles of the Domain Model
The basic principles and constituents of domain models are presented in this section. A more detailed
description of domain model structure has been given in [PET02] that is based on the International
Standard of the Reference Model of Open Distributed Processing ([RM-ODP1], [RM-ODP2]).
3.2.1 Administrative Domain
Domains are basically groups of objects being in the relation to a controlling object. The domain model
here is centred around the notion of administrative domains and their characteristic is the autonomy of the
controlling object that may participate in co-operations with their surrounding, i.e. network
infrastructures.
•
As to the maximum atomicity, each administrative domain is taken by a single business role. We
do not distinguish between different types of business roles within one administrative domain.
The granularity chosen is the administrative domain.
•
Usage of means to minimise dependencies for efficient administration and management effort
within each domain is subject to that domain only (autonomy).
•
The aggregation of administrative domains by a single stakeholder is not relevant at the current
point of time.
In this sense, the domain is understood in the following.
7
For the sake of a rather complete study including all kinds of roles, Stephanie is identified to be an ANP even
though her colleagues do not pay for their usage of service.
Page 70
MIND
1.2
3.2.2 Domain and Reference Point
•
A Reference Point (RP) describes the relation between two domains. It can be used to identify
the included protocol stack8 but also the non technical relation, like a trust relation.
•
Each domain identifies an autonomous part of the infrastructure – an administrative domain.
•
For each domain, the internal structure of the domain with which it interacts is completely
invisible and cannot be determined. Only the identity of the foreign domain and the supported
specific RP are known. Different instances of the same type of domain cannot be distinguished.
•
For example, an access network domain appears to a service provider network as a single unit
with a single identity, however complex its internal structure is.
3.2.3 Map of Roles to Domains
The roles, which have been identified in Section 3.1.2 mainly from a business model point of view,
should be mapped to administrative domains, which represent the entities in MIND network. This helps to
relate the individuals and organisations that appear in the scenario to their technical representations. Table
3-3 describes the map between roles and domains. Each domain will be elaborated later. Some of the
roles, as, for example, the “subscriber” have not yet been described in the domain model because we
focus the study on access network and Ad Hoc networks.
Table 3-3 Map of Roles to Domains
Roles
Domain
User
Leaf Network (LN)
Subscriber
not yet considered in the Domain Model
Service Provider
Service Provider Network (SPN)
Auxiliary Network Provider
Intermediary Access Network (IAN)
Extended Network Provider
Access Network (AN)
Network Provider
not yet considered in the Domain Model
Application Service Provider
not yet considered in the Domain Model
Content Provider
not yet considered in the Domain Model
Intruder
not yet considered in the Domain Model
3.3 Domain Model for Train Scenario
In the BRAIN project, the network scenario can be quite simple, related closely to current SecondGeneration and Third Generation (2/3G) cellular networks. It turns out that if we use appropriate
terminology in this model, it covers quite a variety of MIND features as well, with quite self-contained
generalisations. Finally, these components can be decomposed internally in several ways, without
affecting the overall domain model. This decomposition covers some more MIND generalisations and
also other aspects of public mobile/wireless access, e.g. as being considered for WLAN/3G interworking
in the European Telecommunication Standards Institute (ETSI) Broadband Radio Access Network
(BRAN) [ROH02].
8
The identified protocols of each RP in a domain model can be generally be classified as user plane protocols and
control plane protocols. The former are those used for signalling, session management etc. while the latter are used
for actual data transmission. However, different classifications of the two planes of protocols are adopted for
different purposes, e.g. E2ENP and security analysis.
Page 71
MIND
1.2
3.3.1 Basic Domain Model
Figure 3-1 depicts the basic domain model. The domains with abbreviated names and the reference
points, which define the relationships and interaction interfaces or protocols used between domains, are
elaborated in the following sections. Some participants in the scenario, like the content providers, and the
Internet itself are excluded from the domain model because they are not involved in any trust relationship
which is specific to the mobile wireless case, and any ‘standard’ relationships would involve the Service
Provider Network (SPN) and fixed-side of the Access Network (AN) anyway.
Figure 3-1 Basic Domain Model
Three elementary components of the basic domain model are:
•
Access Network (AN)
•
Service Provider Network (SPN)
•
Leaf Network (LN)
From security and accounting points of view, another domain – Authentication, Authorisation, and
Accounting Broker (AAAB), which acts as an enabler of authentication, authorisation, and accounting
functionality between AN and SPN – is introduced into the basic domain model.
3.3.1.1 AN Content
The Access Network domain consists of Access Routers (ARs), gateway routers to other networks ("the
Internet"), and AAA Local servers (AAALs), as well as a routing infrastructure to link them all together
and network management infrastructure to manage it. There is no constraint or requirement regarding the
number of access routers within an AN. However, there is at least one AR in an AN.
Everything within an AN trusts (can be made to trust) everything else as much as it needs to. This implies
that an AN domain must
•
be immune i.e. robust to interference which would change its behaviour, size and structure;
•
be configured with an identity which says securely which AN it is part of;
It also implies that a domain model describing the internal structure of AN, which is a self-contained
domain in the basic domain model, will be meaningful. The internal structure of AN should be opaque to
other domains except through the predefined reference points. A variety of security techniques could be
considered to enable the requirements which are identified by studying the domain model for AN.
However, both the domain model and the security techniques used for AN internally are out of range of
this discussion.
Different ANs know nothing about each other, hence there’s no reference point between them.
Page 72
MIND
1.2
3.3.1.2 SPN Content
The Service Provider Network domain is the location of user subscription information, which is used in
authentication, authorisation, and further processing of accounting information related to individual users.
Logically, it consists of AAA Home servers (AAAHs) and associated customer care equipment and not
much else.
3.3.1.3 LN Content
A LN is an autonomous constellation of Mobile Nodes (MNs) which are supposed to communicate
together under given circumstances related to the nature of the formation and perpetuation of the LN.
The definition/description of Leaf Network domain is based on its reference points to AN and SPN (a
black-box definition) instead of a direct description of its content. Actually many mobile equipments
(MNs), which may belong to different users (we do not distinguish between user and subscriber in this
discussion), can be included in a LN. However, the essential idea of LN is: at any time there ’is only one
MN of LN being connected to AN and only one subscription contract being used by the MN for the
connection. In the simplest case, a LN contains of a single MN and only one subscription contract is used.
Usually, a LN is associated in the long term with a single SPN – its service provider. We do not
distinguish between the LN and its user. (This way, scenarios which involved several users with different
subscriptions sharing the same equipment would imply having to extend this model. The case of several
users sharing one subscription is covered, however – the relationships between the users are handled
within the LN and are not visible externally.)
LNs as defined in MIND primarily include networks attached to people (Personal Area Network or PAN,
i.e. a network composed by all Internet appliances carried by people, like a PDA, a mobile phone, a
digital camera, a laptop, etc.). For any given LN, only a single SPN is involved at any time. (It can have
more than one subscription to even different SPNs, but only one of them is used for connections at any
time and the switch between different subscriptions happens rarely, therefore they are not considered in
MIND project.)
In the basic domain model, different LNs know nothing about each other, therefore there is no reference
point between LNs.
3.3.1.4 AAAB Content
AAA Broker (AAAB) is an intermediary agent, trusted by a group of AAA servers which belong to ANs
or SPNs. It can obtain and provide security services from/to those AAA servers. It is an enabler of AAA
functionality between AN and SPN. It does not take any responsibility for transfer of accounting,
charging, or billing between AN or SPN. For more information about the AAAB domain please refer to
Section 5.3.2.
3.3.1.5 Reference Points
3.3.1.5.1 LN to SPN
A LN has a subscription relationship with a single SPN (which actually means only one subscription
relationship is considered at any given time and the relationship does not change in the whole period of
the scenario), which is supported by dynamically configured key information to allow authentication and
authorisation to take place.
The LN pays its SPN for service as agreed in the subscription contract, based on accounting information
generated by the AN to which it is attached. When speaking about ‘services’ delivered to the LN, we
intend indeed the total opaque sum of the services delivered to each and every MNs forming the LN.
These services could be generic (i.e. broadcast) or specific to a given MN or amount of MNs. As a side
remark: It is dubious for the moment or at least unclear whether a SPN in the traditional understanding of
the term would consider the (revolutionary) service of hosting such as LN profile as a viable business or
not.
Page 73
MIND
1.2
3.3.1.5.2 LN to AN
A LN attaches to an AN by going through an authentication procedure which sets up the relationship
between the AN and the LN with help of SPN. An AN relies on the authorisation allowance of the SPN in
its decision to open for a requesting LN. AN produces accounting information of LN’s usage of access
service and then sends it to SPN.
One LN could attach to more than one AN (‘multihoming’), but these relationships are independent. On
the other hand, an AN can simultaneously support relations to zero, one or more LNs which have been
authenticated and authorised.
3.3.1.5.3 AN to SPN
AN and SPN relate to each other according to ‘obvious’ roaming relationship/contract. The working
assumption in BRAIN was that this was implemented using an IETF AAA architecture and protocols, but
actually many protocols could be used to implement the same reference points. This also implies a trust
relation should be setup between AN and SPN before AN provide access service to any LN of the SPN.
As usually included in the roaming contract between AN and SPN, accounting records flow from AN to
SPN, and money flows in the opposite direction.
An AN could simultaneously be related to several SPNs. Each such relation to an individual SPN
supports the exchange of information between one or more LN and the SPN, if the LNs have been
authorised by that SPN. A SPN can simultaneously be related to more than one AN. If a SPN is related to
any AN, then it provides its LNs with wireless access via one AN. The reference to each other can be
derived by the support of one or more AAA Broker domains.
Prerequisite for each relation between an AN and a SPN is a trust relation between both domains. This
trust relationship is established by an appropriate mutual authentication that can be verified and mutual
authorisation that determines the support being provided in each of the domain. An AN may support the
exchange of information between LNs and a SPN, but may not offer sufficient accounting information, so
that a SPN refrains from establishing the necessary trust relationship to that AN.
3.3.1.5.4 AN to AAAB and SPN to AAAB
AAAB presents SPNs to setup roaming relationships with ANs and present ANs to setup roaming
relationships with SPNs. AAAB acts as an enabler of the AAA functionalities. It helps SPN to
authenticate and authorise its LNs connected to ANs and helps ANs to send accounting information to
SPNs. There 'is a trust relationship between the AAAB and the domains it serves. This could be a rather
weak one, e.g. the presence of one AAAB in the DNS might be sufficient.
As for an AAAB domain the differences of one AN and one SPN will not be relevant, the RP to both can
be identical.9
3.3.1.5.5 SPN to SPN
SPNs may exchange accounting information, e.g. if charges are split amongst them. In this case a kind of
trust should be setup between each other. The home SPN is that SPN domain to which a LN has a
subscription. This is subject of the RP LN-to-SPN. SPNs might know about each other via AAA
brokerage or hierarchical groupings of roaming partnerships. The nature of that relationship is just to
relay AAA data between AN and home SPN.
9
When we say that two different types of reference points are identical, we are discussing mainly from
the security point of view. A brief explanation is: if the protocol stacks of network and transport layers
(IP/TCP layer) and the trust relationships of the two reference points (RPs) are identical, respectively, the
two RPs are regarded as identical. The above layers (e.g. application layer) are not considered in this
chapter.
Page 74
MIND
1.2
3.3.1.5.6 AAAB to AAAB
An AAAB can setup trust relationships with other AAABs to relay the roaming relationships. AAA
information flow between different AAABs.
3.3.1.6 Trust Model
All of the identified reference points in the basic domain model imply a trust relationship between the
related domains. The trust model coincides therefore with the basic domain model where each reference
point details the bilateral trust relationship. This trust relationship may be either direct or indirect.
3.3.2 Domain Model Including Mobile Ad Hoc Networks
In MIND project, user’s terminal, which is usually regarded as a LN connected to an AN, may support
routing functionality and provide access service to other users who cannot connect to AN directly or
would like to use this mobile Ad Hoc networks for any other reasons. The users who actually use the
access services for their own benefits will be charged through their subscriptions to their SPNs. The basic
domain model described in the former section cannot cover this case since the mobile Ad Hoc network is
not a self-contained LN. Theoretically, there can be a variety of domain models that can support the
scenario in MIND project. However, a rather feasible model is presented in this section.
Figure 3-2 Domain Model with Mobile Ad Hoc Networks
A new domain, Intermediary Access Network (IAN), formerly called Intermediary Network, is
introduced into this domain model. IAN and some other slightly changed domains are described below.
3.3.2.1 IAN content
Intermediary Access Network (IAN) domain is actually a ‘subscriber owned equipment’ providing
routing and access service to the MNs (LNs), which cannot directly access to AN for whatever reasons, or
other IANs. IAN provides routing and access services after going through the authentication and
authorisation process performed by its SPN and AN, especially it should be permitted by AN to provide
the services to others. A strong trust relationship between IAN and AN is required.
In case the routing functionality provided by an IAN is a part of a MN owned by a user, who also uses the
MN to make use of the service provided by AN (or other IANs) for her/his own benefits (acting as a LN),
the MN (including its owner) is then regarded as a combination of two domains: a LN and an IAN
domain. In other words, a MN which supports normal functionalities, usage of which should be paid by
the owner of the MN, and routing functionality, usage of which should be paid by the LNs who use this
service, are separated into two domains in this domain model: IAN and LN.
If an IAN should have a local AAA server (AAAL) is still arguable. However, in the above domain
model there is no AAAL placed on IANs.
Page 75
MIND
1.2
IAN is able to verify if the IANs and LNs that are directly connected to itself have already been
authenticated and authorised by the AN to which it is connected directly or indirectly. IAN does not
provide routing service to any IAN or LN which is not authenticated or authorised by the AN. However,
IAN may provide facilities for the LNs or IANs when they are in the authentication and authorisation
phase.
3.3.2.2 LN Content
The definition and description of LN used in the basic domain model basically hold here. One point worth
to mention is: LN is the functionality which serves its user’s request for access services provided by AN
or IANs and the costs are paid by the user through the subscription to its SPN.
3.3.2.3 AN Content
AN performs AAA functionalities for all the IANs and LNs, which are connected to it directly or
indirectly.
3.3.2.4 Reference Points
Most of the reference points which appear in the basic domain model remain the same. Only changed and
new reference points are described here.
3.3.2.4.1 LN to LN
LNs can connect to and communicate with each other with the transmission not going through the access
network. A kind of trust relationship is required to be setup before their communication, whether online
or offline (offline refers to the case that at least one of the communication partners cannot connect to its
SPN). The offline trust may not be as strong as an online trust. There ’is no charging generated directly
from this communications. One LN can connect to zero, one or many other LNs simultaneously if it ’is
technically feasible.
3.3.2.4.2 LN to IAN and IAN to IAN
IAN provides access and routing services to LNs and other IANs. The general AAA functionalities are
not involved in these reference points even though the AAA information may be transmitted through
IANs. This implies there ’is no AAAL on any IAN. One LN can connect to one or many IANs. One IAN
can connect to one or many IANs and LNs. The routing algorithm decides how the packets can be
transmitted in the Ad Hoc networks.
LNs and IANs may use the routing service provided by other IANs that are permitted by the same AN in
case that they cannot connect to AN directly. On the other hand, they (LNs and IANs) do not use the
services provided by untrusted IANs and IANs do not provide routing services to untrusted LNs or IANs.
The trust relationships amongst IANs and between LN and IAN are rather weak in comparison to those
between IAN or LN and AN.
3.3.2.4.3 IAN to AN
An IAN is entitled to 1) use the access service provided by AN, 2) provide routing and access services to
other IANs and LNs, after go through authentication and authorisation processes. Authenticating an IAN
can be related to the authentication process, which is carried out for the LN that is on the same MN of
IAN. On the other side, authenticating an IAN can be independently done, especially when no LN is
attached to this IAN. However, to clarify the latter case further work is needed.
IAN forwards the packets it received from other IANs and LNs to AN according to the routing algorithms
of mobile Ad Hoc networks. IAN is not charged for its usage of the access service provided by AN.
Actually, the LNs are going to be charged. One IAN connects to only one AN and one AN may connect
to zero, one or many IANs.
Page 76
MIND
1.2
3.3.2.4.4 LN to AN
Extended based on the ‘LN to AN’ reference point in the basic domain model, two different cases are
covered by this reference point: 1) LN is connected to AN directly, 2) LN is connected to AN by the way
of other IAN(s) since there is no direct connection between them.
The AAA processes for a LN are always performed by its SPN and AN to which it ’is connected,
especially the accounting for LN’s usage is done by AN. A trust relationship is setup between LN and AN
as mentioned in the basic domain model.
3.3.2.5 Trust Model
Similar to the basic domain model, all of the identified reference points imply a trust relationship between
the related domains. However, some trust relationships can be rather weak, for example, LN trusts IAN
because the latter has been authenticated/authorised by AN, with which LN has no direct trust
relationship. The trust relationship between LN and AN is based on another two trust relationships: 1)
between LN and SPN, 2) between AN and SPN.
Page 77
MIND
1.2
4. Interworking Service Domain/Transport Domain
The MIND Domain Model (DM) introduced in Chapter 3 describes administrative domains and the
reference points between them. The major administrative responsibilities, which may appear in a mobile
network scenario, in cases of provider owned networks and subscriber owned access networks (Ad Hoc
scenarios) are identified and the interconnections between these domains are described. One aim of the
DM is the identification of the protocols passing through the respective domains, as well as the study and
the determination of the specific AAA and security features of those protocols both in cases of existing
and novel protocol stacks.
Within this chapter, we describe the interactions between Service Domain and Transport Domain in order
to negotiate true end-to-end QoS including application plane and transport plane aspects. Enhancements
to the basic DM are introduced, considering the separation of the model into different planes respective
the application and transport issues of the QoS negotiation and delivery. We use an application level
negotiation and co-ordination protocol, denoted as End-to-End Negotiation Protocol (E2ENP) and
introduced in Section 2.1, to explain several QoS specific actions (e.g. QoS contracts validation,
reservation, QoS adaptation, etc.). Within this chapter, we introduce several general scenarios, that
describe the problems in providing end-to-end QoS management and analyse how this issue may coincide
with the security and the AAA problem. Some specific functionalities of the networks intermediaries with
respect to E2ENP are being identified and discussed. This chapter considers the utilisation of the DM for
the purpose of some generalised functional entities that are specific for the E2ENP application and the
end-to-end QoS delivery.
Compared with the general domain model (Chapter 3) this chapter takes in account only interactions of
the respective network components for establishing multimedia sessions (call-setup procedures). It is
assumed, that basic connectivity has already been established beforehand by some mechanisms, which
may be derived from Chapter 3. This procedure is necessary for providing true end-to-end QoS as the
user wants to perceive it. The simple connectivity without any reservation and local resource coordination allows only best-effort calls, if the network should be considered a bottleneck.
4.1 Application Specific Domain Model Refinements
Within Chapter 3, the basic MIND domain model was introduced. Within this section, we review the
basic DM under the view of the E2ENP. For each element in the DM, we identify potential application to
the E2ENP. The DM is depicted in Figure 4-1.
Figure 4-1 MIND Extended Domain Model
Page 78
MIND
1.2
From the E2ENP point of view, the domains of the DM are responsible for:
•
Leaf network (LN) – The LN depicts one or many end-device/-s, which may or may not be
mobile nodes and can belong to different users. The connection establishment within the scope
of mobile, multimedia communication between two or more LNs can be performed by the means
of E2ENP at application level. LN can establish a connection to the global network using either
the IAN (Ad Hoc scenario) or AN (mobile, sedentary scenario), since IAN and AN provide the
respective access points and services. The LN can utilise the IAN/AN services by following the
IAN/AN registration and AAA rules and mechanisms. These rules and mechanisms can be
established and provided by SPN, which administrates the end-user information in sense of a
service provider. Throughout this chapter, the term LN is used to depict an end-device (also endpeer).
•
Intermediary Access Network (IAN) – The IAN is “subscriber owned equipment”, which
supports its own user with application services and may provide also external users with such
services (e.g. acting as multimedia transcoding service) and with access to the global network in
Ad Hoc scenarios. From the E2ENP point of view, the IAN incorporates both LN protocol agent
functionality and proxy functionality. The IAN can be configured by the respective service
provider, which credentials it is allowed to accept, in case IAN is the connection point to the
global network. If no service provider is involved it is the responsibility of the user of the IAN
capable device to determine which credentials he/she wants to accept.
•
Access Network (AN) – The combination of network devices (e.g. routers, gateways, etc.) for
accessing the global network. In the sense of E2ENP, the ANs together with SPN would provide
physical devices where registries and proxies are executed.
•
Core Network (CN) – The network devices (e.g. routers, gateways, etc.) interconnecting different
ANs. In some cases the CN can also include cellular (UMTS) sub-networks. The CNs together
with SPN/ASPN represents the proxies on the boundaries of different provider domains in sense
of E2ENP.
•
Service Provider Network (SPN) – The SPN is the user-profile administration domain, which
defines the subscription rules and stores the user specific AAA information together with profile
information and rules for accessing different services. In sense of E2ENP the SPN is a registry,
which may be externally questioned on user specific AAA information by validation and
validation verification procedures.
•
Application Service Provider Network (ASPN) – The ASPN is responsible for the application of
the protocol and the service specific rules. The ASPN may provide protocol specific AAA
mechanisms. In sense of E2ENP this can be SIP [RFC3261] specific AAA functionality, since
one of the possible E2ENP solutions is a meta-protocol based on SIP. 10
•
Authentication, Authorisation, Accounting Broker (AAAB) – The AAAB provides third party
trust relationship establishment functionality between different AAA services. Since neither SIP,
nor E2ENP currently consider the implementation of such a brokerage domain, this functionality
should be provided over some other AAA specific protocol. This AAA services are considered
as given by describing the respective E2ENP scenarios and indicated as “AAA Functionality”.
Since E2ENP is an application level protocol, it depends on an already successfully established network
configuration and relies on the network management of the lower protocol levels to establish
connectivity. From the point of view of E2ENP, the AN, CN, and IAN have similar functionality in terms
of routing and proxying. The application level functionality in those entities depends on the SPN
functionality and rules, and on the interrelation with other AAA specific protocols and mechanisms.
4.2 Service Domain and Transport Domain
In this section, we introduce a fundamental function split between connectivity (transport) and services.
In a global view, a provider may not only provide pure connectivity but may also offer services to its
10
Currently E2ENP does not consider proxy specific E2ENP functionality. This problem is left for future studies.
This chapter only mentions some of the issues which may affect E2ENP by performing proxy functionality without
going into detail.
Page 79
MIND
1.2
customer. Therefore, we can split each domain in a transport domain, which is responsible for packet
forwarding, and a service domain, which provides higher layer services for the customer. Figure 4-2
below shows the interaction between the services and the transport within a single provider domain.
Figure 4-2 The Current Internet Model in the View of the Domain Model
The Service Domain includes all higher layer services (e.g. AAA services – registration, user profile
management, application services – SIP, E2ENP protocol support, etc.). Thus the Service Domain spans
over SPN and ASPN domains. Since the Service Domain may include services of multiple sub-providers,
the Service Domain may encompass multiple SPNs and ASPNs.
The IAN/AN/CN provide the network infrastructure indicated as Transport Domain. The functionality of
a Transport Domain can be different due to different interconnection scenarios, e.g. Ad Hoc, mobile
usage, sedentary usage, access network provisioning, network relaying, etc. The Transport Domains
which only relay connections include only CNs.
Each Transport Domain may implement its own QoS provisioning and management mechanism at
transport layer (i.e. packet forwarding across the domain), which makes the provisioning of true end-toend QoS extremely hard. Considering the example in Figure 4-2,
•
Transport Domain 1 could manage its internal resources and provide end-to-end QoS (only
across Transport Domain 1) based on IntServ architecture. Therefore, each router in
IAN/AN/CN would host a RSVP (Resource ReSerVation Protocol) [RFC2205] daemon to
reserve per application flow resources. RSVP would be passed from the ingress router in
Transport Domain to the egress router towards Transport Domain 2.
•
Transport Domain 2 could be an over-provisioned core network and provide end-to-end QoS
(only across Transport Domain 2) based on excess resource availability. Therefore, RSVP would
not be processed within this domain. Another option could be that Transport Domain 2 is based
on Multi Protocol Label Switching (MPLS) or Asynchronous Transfer Mode (ATM)
infrastructure and the RSVP messages initiated by the LN are used to map the users request for
transport resources to MPLS tunnels. An option could be to use pipes across the Transport
Domain 2 that adapt its capacity dynamically based on users requests for transport resources.
•
Transport Domain 3 could provide end-to-end QoS (only across Transport Domain 3) based on
Differentiated Service (DiffServ) architecture. Therefore, some central reservation agent in
Transport Domain 3 would inspect reservation messages and configure each routers traffic
Page 80
MIND
1.2
conditioning and marking mechanisms in IAN/AN/CN using e.g. Common Open Policy Service
Protocol (COPS).
Based on the differentiation in service domain and transport domains, two different planes are identified
that carry signalling data and user data – Application Plane and Transport Plane.
4.2.1 Application Plane
The Application Plane carries application specific signalling messages for e.g. call setup. For example, a
message exchange is necessary to negotiate a common set of codecs and capabilities between peers, to
negotiate the supportable QoS for those codecs, etc. The protocols specific for this plane are e.g. SIP
based on the model described in [OA02], or E2ENP as an extension of these mechanisms, etc. The
Application Plane corresponds to the high level application controls and can be considered as part of the
Control Plane defined in the Domain Model 3 “Domain Model”.
The authentication mechanisms at the Application Plane correspond to the mechanisms of the respective
protocols, e.g. in case of SIP this would be the SIP specific authentication as described in [RFC3261].
Since E2ENP is XML based, the authentication mechanism of E2ENP may contain XML Signatures
[XMLSIG] as identified in [GUE00] 11.
4.2.2 Transport Plane
The Transport Plane is divided into two sub-planes: the control plane (transport level QoS signalling) and
the user plane (media transport). The Transport Plane belongs partially also to the Control Plane as
defined in the Domain Model and to the User Plane (see Section 3.2.2 - footnotes). This separation is
determined by the specific protocols used at the Transport Plane.
4.2.2.1 Control Plane
The Control Plane (see Section 3.2.2 - footnotes) within the Transport Plane carries the signalling
messages necessary for reservation of network resources. For example, RSVP or signalling protocols for
MPLS tunnel establishment (Constraint-based Routed Label Distribution Protocol (CR-LDP), Resource
ReserVation Protocol - Traffic Engineering (RSVP-TE)) belong to this plane. Interworking between
Transport Plane and Application Plane for coupling call-setup and network resource reservation can be
achieved using e.g. E2ENP specific commands based on the model presented in [SIPRES07]. The Control
Plane may also carry authentication data that can be used to authorise resource reservation requests.
4.2.2.2 User Plane
The User Plane (see Section 3.2.2 - footnotes) consists of the media carrier protocols and mechanisms at
the Transport Plane, e.g. the Transmission Control Protocol / Internet Protocol (TCP/IP) suite. For
multimedia streams transported over IP based networks, in particular the RTP/RTCP is important, which
uses UDP to carry compressed realtime data. The E2ENP allows to negotiate how these mechanisms
should be configured within the end-system.
4.2.3 Interactions between Service Domain and Transport Domain
In the current internet model, the Service Domain with respect to the QoS application signalling is either
absent or can be based on the SIP infrastructure, i.e. QoS signalling is either available only at the
Transport Domain (transport QoS) or with the means of SIP can also be carried out in the Service Domain
(application QoS) ahead of establishing QoS specific calls at the Transport Domain. The applications can
negotiate application level QoS and configurations (like codecs and media stream quality) via SIP, using
the model proposed in [OA02]. In those cases where SIP is used, co-ordination of call signalling and
transport resource reservation is done at the LN nodes based on the model proposed in [SIPRES07].
LN-to-LN QoS signalling for transport resources is done on the Transport Domain using RSVP. The
packet flow follows the same path from Transport Domain to Transport Domain as the QoS signalling.
When each Transport Domain implements its own QoS provisioning mechanisms and its own resource
11
This E2ENP feature is currently left for future studies.
Page 81
MIND
1.2
allocation policy, a consistent end-to-end QoS treatment is not possible. Also, there is currently no
mechanism to select specific alternative Transport Domains on the basis of the QoS that the user at the
LN requested. Finally, as there is no interaction between Service Domain and Transport Domain with
respect to QoS signalling (in essence, there is no Service Domain), so a provider is not able to control the
LNs QoS requests. Thus the provider has problems to control the QoS levels offered to the customers
within this domain. The only possibility to control and guarantee the QoS levels of the already running
connections in this case is simply to reject the new incoming resource reservation requests. Clearly, a
business model for managing the internal available resources of the provider is needed. It would allow the
provider to control the QoS offered to the customers. This model would help to provide consistent end-toend QoS and would enable the easier “charging of the customers” management for the offered services.
For example, a provider would only like to accept resource reservation requests, if these have been
properly authorised beforehand. Thus the provider can assume, that the customer is not oversubscribing
resources in contradiction to the user contract policy rules with this provider. The provider can therefore
manage its internal resources by monitoring the customers resource requests and verifying if the customer
is compliant with the contract. Since only properly authorised requests are admitted to resource
reservation processing, the provider always has an overview on the available resources.
In Figure 4-3, the provider may want to establish rules for using his/her Transport Domains, though the
Transport Domains may actually belong to different providers and could be leased, e.g. AOL using the
infrastructure of the Deutsche Telekom, France Télécom, SPRINT, etc.
Figure 4-3 Responsibilities within a Single Provider Domain
In order to achieve controlled QoS reservations, there has to be interworking between the Service Domain
and the Transport Domains. A Service Domain would now be able to actively participate in call setup
procedures and authorise requests for transport resources directed towards the Transport Domains. The
details depend on usage scenarios that are described throughout the rest of this chapter. The Service
Domain would need mutual authentication of the domains SPN and ASPN, by using some AAA
Functionality, in order to be able to enforce authentication between different applications. Additionally,
the Service Domain can use the AAA Functionality to enforce the application AAA rules also on the
network infrastructure considering the infrastructure specific rules (IAN/AN/CN). For example, the
Service Domain would authorise requests for resources, which are carried either implicit (through the
specification of codecs and application layer QoS parameters) or explicit (as an explicit request for
specific resource reservations) in the call setup messages using the AAA Functionality.
Page 82
MIND
1.2
There are three possibilities, how such an authorisation for resources is established:
1.
The Service Domain authorises resources using the AAA Functionality during call setup. Once
the call is established at application plane and the LN requests resource reservation, the
Transport Domain would query the AAA Functionality, if the resource request has been granted.
This requires interaction between Service Domain and the AAA Functionality and between
Transport Domain and the AAA Functionality.
2.
The Service Domain authorises resources using the AAA Functionality during call setup and
instructs, during call setup, the Transport Domain to grant the resources. Once the call is
established at application plane and the LN requests resource reservation, the Transport Domain
knows already, if the resource request can be granted. This requires interaction between Service
Domain and the AAA Functionality and between Service Domain and Transport Domain.
3.
The Service Domain authorises resources using the AAA Functionality during call setup and
derives an authorisation token. Once the call is established at application plane and the LN
request resource reservation, the LN has to include the token in the resource reservation requests.
The Transport Domain then knows based on the token, if the resource request can be granted.
This requires interaction between Service Domain and the AAA Functionality and a token
passing mechanism between LN and Transport Domain.
The details of the procedures can be found in the scenario sections below. In addition to resource
reservation authorisations, there is a need to activate resource reservations that have been established
based on authorisation information (as described above). This is particularly important, if billing
mechanisms have to be integrated. This is necessary, as only after a completed call-setup (indicated in the
case of SIP by receiving a 200 OK for an initial call setup INVITE) the complete information regarding
which QoS has been reserved is available at both the offerer and the answerer [OA02]. Thus, an
activation of already reserved resources during the call setup makes sense only if both parties accept the
call setup, and only then actual billing should start. The details of the procedures can be found in the
scenarios Section 4.4. Nevertheless, the Transport Domain may use the AAA Functionality to correctly
identify the credentials of the services using the respective network nodes, but the network nodes should
follow the rules of the respective Service Domain. When two different service providers are involved in
the establishment of the communication between two or several end-systems within their domains, the
responsibilities are similar to the situation above (see Figure 4-4).
In case of communication within multiple Services Domains (SPN/ASPN) the respective domains have to
either mutually identify their credentials by using the AAA Functionality or make sure that the
authorisation tokens can be understood and interpreted by all transport domains involved in the end-toend transmission.
Page 83
MIND
1.2
Figure 4-4 Responsibilities within Multiple Provider Domains
4.3 Service and Transport Validating Facilities
Within this section, we are interested in specific functionality within the providers’ service and transport
domains to assure that the users correctly validate and utilise the QoS contracts respective their QoS
profiles (the single steps of the validation process are described in Section 2.1). This functionality can be
both assigned to the Service Domain and the Transport Domain intermediaries. The mechanisms for
applying this functionality at the different domains and planes depends on the considered actions (e.g.
QoS signalling, reservation, etc.) and on the respectively used protocols.
Some examples for clarifying the idea about these AAA control intermediaries are shown considering SIP
Proxy functionality and RSVP resource reservation mechanisms. Discussions on how E2ENP could be
used also in 3GPP scenarios are provided in Section 4.4.
4.3.1 Registration Processing
Figure 4-5 and Figure 4-6 show the parties involved in peer registration and validation of QoS contracts
as identified for E2ENP in Section 2.1.
Since E2ENP can be used only after connectivity has been successfully established, the registration
functionality is considered to be a part of the Service Domain, which is responsible for registering the
LNs by an initial contact with the network (Home/Roaming-Provider system). The Service Domain
manages the user profile and the registration information of the user. If the Service Domain is a RoamingProvider it may retrieve the respective user profile information from the home system of the respective
LN by using the AAA Functionality or generate its own user QoS profile respective the registration
credentials delivered by the user by registration. The user authorises himself by the Service Domain over
some user specific authorisation information (e.g. Subscriber Identity Module (SIM) of the LN). The
Service Domain may supply the user with authentication tokens for accessing the Service and the
Transport Domains of the respective provider. In case of SIP, the Service Domain can include SIP
Registrar among other services.
The authentication tokens generated and provided by the Service Domain are used by the Service and the
Transport Domains to identify the respective user and his/hers credentials to use certain QoS levels (QoS
Page 84
MIND
1.2
profile). The tokens at the Service Domain can be associated with the usage of certain codecs and the QoS
configurations thereof. The tokens at the Transport Domain can be associated with an upper bound
limitation of the bandwidth consumption and the priority of the traffic (e.g. packet loss, jitter, etc.) of a
given user either on a per flow basis or for the given user as a whole. These tokens are typically based on
subscription information, e.g. user X is only allowed to use up to 128 kBit/s video streams, or user X is
only allowed to use codec X1, X2, X3, or user X is only allowed to use the bronze QoS class.
The LN, by having correctly registered at the Service Domain, may establish connections to the Service
and the Transport Domains for performing multimedia calls. The LN may include the authentication
tokens provided by the Service Domain during registration to validate its QoS contracts for accessing the
Service Domain (for negotiating with peer LNs) and for performing reservations at the Transport Domain.
The Validating Facilities are associated with the first proxy accessible by a LN, which has AAA control
functionality. The Validating Facilities either verify, if the LN has correctly validated its QoS contracts
according to the provider policies of the currently used network by call setup establishment, or mark the
E2ENP payloads with the validation tokens themselves. The Validating Facilities prove the validity of the
E2ENP payloads (the QoS contracts) and the associated protocol credentials (e.g. SIP and/or E2ENP
authorisation tokens at Application Plane, or RSVP authorisation tokens at Transport Plane). The
implementation of the Validating Facility at application and transport plane is different due to the
protocol specification needed for validation. The Validating Facility is a functional entity that can be
mapped to one or several physical devices.
The E2ENP payload checks are performed only at the first accessible home/roaming-home access-proxy.
All other proxies should check only the credentials of the messages (e.g. only the SIP authorisation tokens
for the E2ENP payloads). This requirement is necessary for backward compatibility, processing
simplification and compatibility with standard SIP proxies [RFC3261] (non-E2ENP proxies).
Figure 4-5 Registration and AAA Controls in a Single Service Domain
The associations indicated with numbers on Figure 4-5 have the following meaning:
1.
LN1 starts a call set up and this call is intercepted by the Service Validating Facility 1 (this could
be an enhanced SIP proxy) within the Service Domain 1.
Page 85
MIND
1.2
2.
If both LN1 and LN2 are at their home domain the Service Validating Facility 1 can check the
respective QoS usage credentials and tokens at the local registry. In case one of the LNs is in a
visiting domain, the Service Validating Facility 1 would need to prove the credentials at some
foreign system by using the AAA Functionality.
3.
After proving the credentials the Service Validating Facility 1 forwards the call.
The answer to the call undergoes the same procedure (1 to 3) in the reverse direction.
4.
After getting an answer, the LN1 starts reservation set up at the transport plane and this call is
intercepted by the Transport Validating Facility 1 (this could be an enriched bandwidth broker)
within the Transport Domain 1.
5.
If both LN1 and LN2 are at their home domain, the Transport Validating Facility 1 can check the
respective QoS usage credentials and tokens at the local registry. In case one of the LNs is in a
visiting domain, the Transport Validating Facility 1 would need to prove the credentials at some
foreign system by using the AAA Functionality.
6.
Once the network resources are validated, resources are reserved at the respective IAN/AN/CN.
7.
After proving the credentials, the Transport Validating Facility 1 forwards the reservation
message.
If two way connections should be established, LN2 needs to perform the steps from 4 to 7 in the reverse
direction, otherwise the LN2 responds with a reservation confirmation message. For this scenario it is
assumed that the LN1 initiates the call.
In cases that multiple service and transport domains are involved, the Validating Facility verifies the
payload content validity before letting it through the provider domain border (Figure 4-6). The Service
Validating Facility corresponds to SIP enhanced proxies (E2ENP proxies), which may understand and
interpret the body of the message. The Validating Facility guarantees for the correct behaviour of the LN
by inter-/intra-domain connections. This means „really“ valid E2ENP payloads and „really“ allowed
reservation processing at the application plane. For the validation purposes both Service and Transport
Validating Facilities can use either the local registries (for identifying LNs at their home system) or the
AAA Functionality for identifying foreign LNs, which are either visiting or are at home at the foreign
domain.
As we will see later, there are scenarios (see Sections 4.4.3 and 4.4.4), where reservations of network
resources are performed from the Application Plane and thus all Application Plane Validating Facility
(also called Service Validating Facility) should be able to interpret the E2ENP payloads in order to be
able to enforce them. This means that the Service Validating Facility of the domains where the LNs are
currently connected is responsible for the reservations. Additionally, all the proxies on the way of the
E2ENP message should be E2ENP and SIP stateful proxies, since the processing state should be known at
all stages of the session life, due to the reservation processing at those proxies.
However, when using non-integrated scenarios (see Sections 4.4.1 and 4.4.2), the E2ENP and SIP proxies
can be stateless.
Page 86
MIND
1.2
Figure 4-6 Registration and AAA controls in Multiple Service Domain
During the verification process, the Validating Facility uses the AAA Functionality for verification of the
tokens associated with the QoS specific payloads for QoS levels indication (E2ENP, see “Security
Considerations” in Annex A and network resource reservation (RSVP).
4.3.2 Service Validating Facility
Figure 4-7 shows a negotiation scenario at application plane as defined in Section 2.1, which is based on
the SIP Offer/Answer model [OA02]:
The scenario corresponds to the SIP specific AAA functionality [RFC3261] where the Service Validating
Facility can be a SIP enhanced proxy, which understands the E2ENP payloads.
Note, that in the standard E2ENP scenario as defined in Section 2.1, the provider has to trust the LN, as
the LN is responsible for validating the offer, i.e. the LN must make sure that the offer does not violate
the rules of the provider, which have been supplied at login during step 1. In those cases where the LNs
do not correctly validate their payloads (e.g. a user tries to setup a video conference at high quality but the
contract with the provider only allows a low quality conference), the Service Validating Facility would
challenge the LN to correctly validate and authenticate its contracts (Figure 4-8 and Figure 4-9) as
specified by [RFC3261]. If multiple Service Validating Facilities are involved they need to have trust
relationship between them established, because only the first Service Validating Facilities checks the
compliance of the Offer/Answer with the contract/-s and all others only verify the correctness of the
credentials.
Page 87
MIND
1.2
Figure 4-7 QoS Contract Validation and Negotiation at the Application Plane
Figure 4-8 Wrong Validation by the Offerer
Page 88
MIND
1.2
Figure 4-9 Wrong Validation by the Answerer
The scenarios above (Figure 4-7, Figure 4-8, and Figure 4-9) assume that Application and Transport
Planes are decoupled. In contrast, more integrated scenarios assume that transport QoS control and
resource reservations interact with the Service Domain (see Sections 4.4.3 and 4.4.4). In such cases a
common negotiation scenario as defined by 3GPP [3GPPSIP] should be used. In order to validate the
offer and the answer, the offer and the answer have then to carry either codec/quality descriptions and the
Service Validating Facility must be able to derive transport QoS parameters necessary for fulfilling the
offer/answer or the offerer/answerer must include transport QoS parameters in addition to codec/quality
descriptions.
According to the SIP proxy definition [RFC3261] and the E2ENP Intermediate Component behaviour as
defined in Section 2.1, the intermediaries are not allowed to change the contents of the message bodies.
The SIP and E2ENP definitions suppose that the provider trusts its users and it is responsibility of the
user to correctly apply QoS according to known policies of the provider. On the other hand the 3GPP SIP
[3GPP] usage model supposes that the provider does not trust the end-user for the validation process and
the provider actively participates in the validation process. The 3GPP Proxy - Call Session Control
Function (P-CSCF) and Serving - Call Session Control Function (S-CSCF) proxies change the contents of
the SIP message bodies by removing the payloads (e.g. capabilities, QoS contracts) which are notsupported by the provider for the given session based on provider policies and user contractual issues.
The 3GPP solution contains several problems with respect to a conformant application of SIP:
1.
2.
The 3GPP SIP solution works only in 3GPP conformant environment.
•
With 3GPP, the message body contents must not be end-to-end encrypted.
•
3GPP SIP would cause security problems in cases of mixed “original SIP” / “3GPP SIP“
environment, since SIP own security for message integrity is no more applicable. According
to [RFC3261], SIP User Agents can perform integrity checks also of the message body, if
the message body is within the secure part of the SIP message. Additionally, the 3GPP own
security mechanisms may cause denial of service by “original” SIP Proxies.
The 3GPP SIP solution is not really suitable for supporting fast vertical handovers (provider
and/or technology handovers). The 3GPP P-CSCF and S-CSCF proxies limit the possibility for
QoS adaptation by changing the negotiated message bodies. In fact, the CSCFs remove the
codec configurations that is currently not supported in the current providers domain. Therefore,
the principal capabilities of the offerer’s LN would never reach the answerer (as some of them
may have been removed by the CSCF). The same holds true for the capabilities/QoS wishes of
the answerer as some of these would be removed by intermediate CSCFs. Therefore, at the end
of a negotiation round, both LNs – the offerer and the answerer – only have a picture of what can
Page 89
MIND
1.2
be enforced with respect to codecs/capabilities and media qualities, given the currently attached
CSCFs. But the offerer/answerer has no knowledge about what would be possible in the best
case, where only the LNs are the limiting factor. This situation would lead to full re-negotiations
during vertical handovers when, e.g. moving from a GPRS network to a wireless LAN, which is
contradictory with the E2ENP idea for speeding up the re-negotiations. By already running
sessions, the E2ENP User Agents exchange only reference tokens to pre-negotiated data, in
order to limit the time of a QoS violation situation.
Therefore the E2ENP should be applied to 3GPP based solutions in integrated scenarios (see Sections
4.4.3 and 4.4.4) as a relaxed version of the 3GPP SIP solution. In this case, an E2ENP proxy would
validate the message body contents by only marking the QoS contracts (pre-negotiation, negotiation) as
applicable or non-applicable as defined in Section 2.1, including its authentication key in the SIP
Authentication-Info header field [RFC3261]. This authentication key would be saved at the LNs for the
needs of re-negotiation procedure by horizontal handovers, since re-negotiation procedures also need to
be authenticated as belonging to the same call sequence and the proxies (Service Validating Facility of
the respective access networks) should control that the LNs correctly switch between the QoS states by
verifying the references in the re-negotiation message. The proxies (Service Validating Facilities) in the
integrated scenarios are stateful and they can recognise which reference corresponds to which negotiated
data (the Service Validating Facilities of the access network would have to store the QoS contracts for all
negotiations). The proxies of the intermediate networks would only have to verify the authentication keys
of the messages, since as mentioned above the Service Validating Facilities guarantee for the correct
behaviour of the clients.
In case of vertical handovers, the E2ENP user agents at the LN would send complete negotiation
information. The complete description reaches only the first access proxy (Service Validating Facility) in
the chain, thus causing proxy state migration between the access network Service Validating Facilities.
The new access Service Validating Facility gets the complete information about the session from the LN,
also with the blocked states descriptions. Being intercepted by the SIP/E2ENP proxy (Service Validating
Facility) this information would be respectively marked and authenticated (proxy validation). The proxy
would then return the changed information to the initial LN using “401 Unauthorised” [RFC3261]. The
peer can then send only a reference to the data marked with the respective proxy authentication key. Since
the proxy/Service Validating Facility is stateful and the other negotiation partners already know about the
complete session description from the initial negotiation, both the proxies and the partner LNs would
know how this reference is to be interpreted. Common scenario by roaming and vertical handovers is
described for 3GPP Registration and Call setup/management procedures in foreign networks [3GPPSIP] .
According to the 3GPP scenario only the proxies (P-CSCF, S-CSCF) of the access network change the
contents of the message bodies, since the end-to-end resource management is only responsible of the
access networks. Therefore, by vertical handovers only the access network Service Validating Facilities
are affected by the state migration. By vertical handovers a re-negotiation process continues after the first
proxy authorisation procedure with sending a complete set of contract references end-to-end to be
respectively marked by the access network Service Validating Facilities of the both communication
partners as applicable or not-applicable. The access network Service Validating Facilities are already
informed about what is being negotiated ahead and can understand the contents of the references. This
marking process delivers the LNs the knowledge which previously blocked contracts are available for the
new provider connection and can respectively be used by the initial vertical handover re-negotiation and
the following re-negotiations within the new access network/-s.
When adopting the E2ENP solution for 3GPP as described above, a validation procedure at the LN side
with respect to Provider specific issues would not be needed. The Registry would then no longer supply
the LNs with tokens necessary for the validation. It is the Service Validating Facility which performs the
validation. This solution would lead to two additional messages between the Service Validating Facility
and the LN for exchanging correctly validated and authenticated data. In addition, the re-negotiation by
vertical handovers has two phases: Contract blocking/de-blocking phase and standard re-negotiation
signalling as described in Section 2.1.
4.3.3 Transport Validating Facility
The functionality of the Transport Validating Facility (Figure 4-10) corresponds to the RSVP resource
reservation processing at the network nodes. According to [RFC2205] , the receiver starts the reservation
process, which ends by the sender of the media data.
Page 90
MIND
1.2
Figure 4-10 QoS Reservation at the Transport Plane
It is only the access networks first RSVP daemon or bandwidth broker in the reservation path which
needs to check the reservation authentication token of the LN (and decide to initiate a reservation based
on the authentication information), since the reservation message is forwarded hop-by-hop with hop-byhop mutual authentication of the neighbouring routers on the reservation path. This means that every
router participating in a reservation should know the authentication tokens of its neighbours and
respectively be able to apply them (by message forwarding) and verify them (by message reception).
The authentication token is applied by the LN in the non-integrated scenarios (Sections 4.4.1 and 4.4.2)
and by the reservation/activation proxies in the integrated scenarios (Sections 4.4.3 and 4.4.4).
4.4 Interworking Scenarios
In this section we elaborate on four scenarios that present interworking of call setup and resource
reservation in the network. The scenarios are denoted as “No Coupling”, “Loose Coupling”, “Tight
Coupling” and “Integrated” according to the amount of interactions between call setup and resource
reservation. The E2ENP protocol can be applied only to some of them, since also legacy applications
(that do not use SIP) are taken in account. The four scenarios consider different interworking possibilities
between the DM (Chapter 3) domains. The general view on the discussed scenarios is summarised in
Table 4-1
.
Page 91
MIND
1.2
Table 4-1 E2ENP Scenarios Respective the MIND AAA Components
Scenario
Name
LN
Application
Plane
Signalling
party
LN
QoS Policy Export LN
Resources
3rd
Transport
synchronisation activation/ call control
possible
Plane
(Service DomainÆ
Signalling Transport Domain)
deactivation
No Coupling No
Yes
Yes
No
No
No
Loose
Coupling
Yes
Yes
Yes
Yes
No
No
Tight
Coupling
Yes
Yes
Yes
Yes
Yes
Yes
Integrated
Yes
No
No
No
Yes
Yes
The following sections describe these features in detail.
4.4.1 No Coupling
In the “No Coupling” scenario (Figure 4-11) we assume that there is no session setup signalling or that
the session setup signalling is not intercepted by application plane entities. In this case, no interactions
(neither directly nor indirectly via LN) between Service Domain and Transport Domain take place. Thus,
the Service Domain can not authorise or activate/de-activate Transport Domain resource reservations. The
only communication concerning resources occurs between LN and Transport Domain via a resource
reservation signalling protocol like RSVP. The “No Coupling” scenario is applicable to e.g. legacy
applications.
Figure 4-11 General Architecture for Applying the No Coupling Scenario
Page 92
MIND
1.2
LN 1
Transport Domain 1
Service Domain 1
Service Domain 2
Transport Domain 2
LN 2
1: register()
2: register_ACK()
3: register()
4: register_ACK()
5: Negotiate Application Level QoS
6: Negotiate Application Level QoS
7: RSVP_PATH
8: RSVP_PATH
9: RSVP_PATH
10: RSVP_RESV
12: RSVP_RESV
14: RSVP_RESV
11: reserve_resources()
13: reserve_resources()
15: call_setup_done
16: call_setup_done
17: call_setup_done
Figure 4-12 No Coupling Scenario - Call Setup and Network Reservation are not Coupled
In this scenario the Service Domain is responsible only for the registration of the LN. The QoS signalling
is used only at the Transport Plane. Figure 4-12 shows message sequences, where LNs register at the
Service Domains, negotiate directly using legacy mechanisms and reserve resources using Transport
Domains.
There is no communication between the LN and the Service Domain except for the registration. Every
communication necessary to establish resource reservations is handled via Transport Plane signalling (e.g.
using RSVP) directly between LN and Transport Domain. Nevertheless, there is the possibility that the
Service Domains registration information is available by some mean at the Transport Domain. This would
allow the Transport Domain to check, if a resource reservation request of a specific LN would be
processed or not. For example, a Transport Domain could then be able to block reservations of a customer
who is not registered. Note, that there are two options to solve this problem:
•
The Service Domain and the Transport Domain exchange information about registered LN. Once
a LN is registered at the Service Domain, the Transport Domain would process resource
reservation requests for the specific LN. Note, that this is only applied once during registration
and not for each call setup.
•
The Service Domain provides authorisation tokens for the LN to be used for resource
reservations for the associated Transport Domain. The Transport Domain would have to know
the authorisation tokens and only process reservation messages that contain the correct token.
More specifically:
o
LN gets policy token/-s from the Registry by authorising itself over its user
authorisation key e.g. Subscriber Identity Module (SIM). If by registration the system
does not generate policy tokens, these tokens can be added by the respective first access
proxy.
o
LN authenticates itself with the policy token/-s before the Transport Domain or the first
access proxy authenticates its user by first verifying the user’s identity at the local
registry.
o
The SPN/ASPN associated with the transport can verify the policy token/-s at the local
Registry servers and/or can use the AAA Functionality to access foreign registries,
before SPN activates the transport AN/CN (reservation, forwarding).
Page 93
MIND
1.2
4.4.2 Loose Coupling
The Loose Coupling scenario (Figure 4-13) corresponds to Internet applications, where the application
signalling (e.g. SIP, E2ENP) and the data transport can take different paths (Figure 4-13). The services
controlling the negotiation at application plane and the reservation processes at transport plane are
different, associated with different SPN/ASPN at the Application Plane. This is also a typical SIP
[RFC3261] / E2ENP scenario with reservation co-ordination at the LNs according to [SIPRES07] and
where the application plane and the transport plane signalling is completely separated. There is no
interaction between Service Domain and Transport Domain during call setup signalling.
The authorisation of resource reservation requests is performed by generating authorisation tokens at the
Service Domain and passing those authorisation tokens to the LNs during call setup procedure in the
application plane (in the session offer or session answer, respectively). The LNs include these tokens into
the QoS reservation requests sent to the Transport Domain. The Transport Domains resource reservation
agents check the validity of the tokens using internal policies that they may have imported from the
Service Domain earlier or that have been statically configured at start-up. In contrast to authorisations
used in the “Tight Coupling” scenario below, such policies are not generated and forwarded per session.
Instead, activation and deactivation of resource reservations has either to occur via direct signalling
between LNs and Transport Domain, if the reservation protocol used offers such a possibility, or
automatically at resource reservation/teardown, if the protocol does not offer such features (as in case of
standard RSVP).
The AAA/Reservation process is the following:
•
LN gets policy token/-s from the Registry by authenticating itself over its e.g. SIM, LOGIN
INFO (by e.g. REGISTER).
•
LN includes the policy token for validating the QoS requests at the Service Domain SPN/ASPN
(e.g. INVITE) – SIP Proxies with authorisation (Service Validating Facility). Access network
Service Domains may indicate for each codec/capability/quality level if it is supported or not, in
case they have knowledge about the policies of the end-to-end traffic support in the Transport
Domains (But this might not be the case in a typical SIP model scenario).
Figure 4-13 General Architecture for applying the Loose Coupling Scenario
Page 94
MIND
1.2
Figure 4-14 Loose Coupling Scenario - Negotiation and Reservation Model
•
LN includes the policy token in reservation requests to the Transport Plane (IAN/AN)
•
The transport plane IAN/AN (router reservation managers in Figure 4-14) can verify the policy
token/-s at the local Registry servers and/or uses the AAA Functionality to access foreign
registries, or use static configuration information.
•
The IAN/AN/CN take care for correct authentication token change between different Transport
Domains by performing the reservation hop-by-hop.
The overall message exchange for the call setup procedure is summarised in the next Figure 4-15 based
on the E2ENP model. It is assumed, that the LNs registered beforehand (the registration procedure is not
shown in the Figure 4-15) and E2ENP-capable access-network proxies may indicate, which
codecs/configurations are supported or not (similar to the 3GPP model).
The LN initiates the session setup by sending an ‘invite’ message containing a session offer to the E2ENP
Proxy in the Application Plane (Service Domain) it is registered with. The E2ENP proxy authorises the
request and optionally indicates which codec/configurations/QoS levels are applicable or non-applicable
as defined in Section 2.1, including its authentication key in the SIP Authentication-Info header. This is
denoted as process (offer). The proxy then propagates the E2ENP QoS request (potentially modified
offer*) to the next E2ENP proxy and so on. Each proxy processes the codec/configurations/QoS levels.
Afterwards the last proxy informs the answering LN about the session E2ENP QoS request (indicated as
offer**). The answering LN drafts an answer as QoS response from the information that it has received
with the session offer and its local capabilities and resource availability. This answer is passed along to
the last proxy, who then again processes the answer similar as the offer has been processed and authorises
it. The authorised answer* is passed finally to the first hop proxy of the offerer, who in turn indicates
which codec/configurations/QoS levels are applicable or non-applicable of the answerers description and
authorises the answer. Finally, the E2ENP QoS response arrives at the offerer (as answer**), who has
now complete knowledge of what codec/configurations/QoS levels are applicable or non-applicable by
which party. The offerer LN sends RSVP PATH message to the answerer LN that returns a RSVP RESV
message. The RSVP message contains the authorisation tokens received during the E2ENP QoS response.
Finally, when the offerer LN receives the RSVP RESV message, it sends a “E2ENP command-readyreservation” message to the answerer indicating the successful completion of the network resource
reservation, which is answered using a ready_reservation_ACK (200 OK of an initial INVITE). The call
setup ends using a call_setup_done (SIP ACK) as defined in Section 2.1.
Page 95
MIND
1.2
LN 1 (Offerer)
Transport Domain 1
Service Domain 1
Service Domain 2
Transport Domain 2
LN 2 (Answerer)
1: Invite(offer)
2: process(offer)
3: invite(offer*)
4: process(offer*)
5: invite(offer**)
7: propose(answer)
9: propose(answer*)
11: propose(answer**)
12: process(answer**)
13: RSVP_PATH
6: process(offer**)
8: process(answer)
10: process(answer*)
14: RSVP_PATH
15: RSVP_PATH
17: RSVP_RESV
19: RSVP_RESV
21: RSVP_RESV
16: ResoureCfm()
18: reserve_resources()
20: reserve_resources()
22: ResourceCfm()
23: E2ENP_command_ready_reservation
24: E2ENP_command_ready_reservation
25: E2ENP_command_ready_reservation
27: ready_reservation_ACK
26: ProcessReservation()
28: ready_reservation_ACK
29: ready_reservation_ACK
30: ProcessReservation()
31: call_setup_done
32: call_setup_done
33: call_setup_done
Figure 4-15 Call Setup for the Loosely Coupled Scenario
4.4.3 Tight Coupling
The Tight Coupling scenario (Figure 4-16) corresponds to the 3GPP model, where the LNs implement the
reservation protocol (e.g. RSVP) themselves but the Service Domain interacts with the Transport Domain
during call setup for reservation processing. Here, the Service Domain ASPN are related both to QoS
Signalling and resource reservation activation and should be integrated (Resource reservation
activation/deactivation should be performed from within the Application Plane). The QoS signalling is
performed both at the Application (e.g. SIP, E2ENP) and the Transport Planes (e.g. RSVP) and the LNs
coordinate resource reservations using [SIPRES07], which is also the model for E2ENP (see Figure
4-18).
Call setup signalling and resource reservation signalling are tightly coupled. In contrast to the “Integrated
scenario” described below, a reservation request for network resources is sent directly using Transport
Plane signalling (RSVP or a similar protocol) from the LN to the Transport Domains reservation agents.
A tight coupling between the Application Plane and the Transport Plane is given because the resource
reservation is authorised and resource reservations are activated by the Service Domain (e.g. E2ENP or
SIP proxy) through special messages to the Transport Domain. In case of session teardown, the Service
Domain can also directly teardown reserved resources by sending a teardown request to the Transport
Domains resource reservation agents rather than leaving this task to teardown requests issued by the LN.
Page 96
MIND
1.2
Figure 4-16 General Architecture for applying the Tight Coupling Scenario
The initial session offer and answer exchange between LN, Service Domain and Transport Domain is
very similar to the “Loosely coupled scenario”, with the main difference being that the Service Domain
entities (E2ENP proxies) authorise resources based on actual resource availability of the Transport
Domain. This requires an interaction during the authorisation process between Service Domain and
Transport Domain. The Figure 4-17 below illustrates the call setup process. Again, it is assumed that a
registration procedure has been carried out beforehand and the 3GPP model is assumed, where proxies
may modify the session offer (but only indicate if applicable or not, they do not remove session
descriptions).
The resource reservation itself is achieved directly between the LNs and the Transport Domain via RSVP
signalling. The LN sends a RSVP_PATH message which is propagated along the Transport Domains to
the peer LN. The peer LN answers with a RSVP_RESV message. Each Transport Domain reserves the
resources upon receipt of this message. This can only be done successfully if the resources have been
authorised beforehand by the Service Domain.
The confirmation of the reservation and the resource reservation activations are performed after the
offerer sent a “E2ENP command-ready-reservation” message to the answerer indicating the successful
completion of the network resource reservation, which is answered using a “ready_reservation_ACK”
(200 OK of an initial INVITE). Whenever the “ready_reservation_ACK” for the “E2ENP commandready-reservation” is received at an E2ENP proxy, it activated the resource reservations with the transport
domain.
Page 97
MIND
1.2
LN 1 (Offerer)
Transport Domain 1
Service Domain 1
Service Domain 2
Transport Domain 2
LN 2 (Answerer)
1: Invite(offer)
2: admit(resources)
3: admit_ACK
4: process(offer)
5: invite(offer*)
6: admit(resources)
7: admit_ACK
8: process(offer*)
9: invite(offer**)
11: propose(answer)
10: process(offer**)
12: authorize(resources)
14: authorize_ACK
13: update(policy)
15: propose(answer*)
16: authorize(resources)
17: update(policy)
18: authorize_ACK
19: propose(answer**)
20: process(answer**)
21: RSVP_PATH
22: RSVP_PATH
23: RSVP_PATH
25: RSVP_RESV
27: RSVP_RESV
29: RSVP_RESV
24: ResoureCfm()
26: reserve_resources()
28: reserve_resources()
30: ResourceCfm()
31: E2ENP_command_ready_reservation
32: E2ENP_command_ready_reservation
33: E2ENP_command_ready_reservation
35: ready_reservation_ACK
36: activate(resources)
37: activate_ACK
38: ready_reservation_ACK
39: activate(resources)
40: activate_ACK
41: ready_reservation_ACK
42: ProcessReservation()
43: call_setup_done
44: call_setup_done
45: call_setup_done
Figure 4-17 Call Setup for the Tightly Integrated Scenario
Page 98
34: ProcessReservation()
MIND
1.2
Figure 4-18 Tight Coupling Scenario - Negotiation and Reservation Model
The AAA/Reservation/Activation process is the following:
•
LN gets policy token/-s from the Registry by authenticating itself over its e.g. SIM, LOGIN INFO
(by e.g. REGISTER). If by registration the system does not generate policy tokens, these tokens can
be added by the respective first access proxy as described above.
•
LN includes the policy token for validating the QoS requests at the service plane SPN/ASPN (e.g.
INVITE) – SIP Proxies with authorisation (Service plane Validating Facility) or the first access
proxy authenticates its user by first verifying the user’s identity by the local registry.
•
LN includes the policy token in reservation requests to the Transport Plane IAN/AN or the first
access proxy authenticates its user by first verifying the user’s identity by the local registry.
•
The transport plane IAN/AN can verify the policy token/-s at the local Registry servers and/or uses
the AAA Functionality to access foreign registries. The IAN/AN/CN takes care for correct
authentication token change between different Transport Domains by performing the reservation
hop-by-hop. The integrated service and transport plane ASPN can perform flow activation and flow
teardown at the transport plane SPN. Additional control on transport AN/CN.
4.4.4 Integrated
This scenario is denoted as ‘Integrated Scenario’ because session setup signalling and resource
reservation signalling are integrated. In this scenario, the LN only communicates with the Service
Domain who in turn communicates with its associated Transport Domains. There is no direct
communication between the LNs and the Transport Domain.
The Integrated scenario (Figure 4-19) corresponds to the 3GPP model, where the LNs do not implement
the reservation protocol themselves. Instead, the Service Domain SPN/ASPN implement QoS signalling,
traffic activation and reservation on behalf of the LNs. Reservation and resource activation/deactivation is
performed from the Application Plane within the Service Domain. The reservation co-ordination
[SIPRES07] is still necessary so that the reserving proxies can inform the LNs about the reservation
results (Figure 4-21). In addition to marking and authenticating the QoS contracts, the proxies add
information about the reserved network resources in their answers to the LNs. The scope of this
reservation marking can be performed according to the XML-syntax described in [BOS02] as suggested
in Section 2.1.
Page 99
MIND
1.2
Figure 4-19 General Architecture for Applying the Integrated Scenario
The Figure 4-20 illustrates the call setup procedure for the integrated scenario. Again, it is assumed that
the LNs registered before at the corresponding service domain. In the ‘Integrated Scenario’ the offerer LN
initiates the session setup by sending an ‘invite’ message containing a session offer to the Service Domain
it is registered with (Service Domain 1). The Service Domain checks if enough resources are available at
the associated Transport Domain (Transport Domain 2) and process the codec/capabilities/qualities as
already explained above. It then propagates the session offer (denoted as offer* as the service domain
annotated which capabilities are supported) to the next Service Domain, in our case the Service Domain
2. The Service Domain 2 performs the same checks with its Transport Domain 2 and again processes the
offer. Afterwards it informs the answerer LN 2 about the session invitation. The LN2 prepares an answer
from the information that it has received within the session offer and its own capabilities/codecs. This
answer is passed along to Service Domain 2 who then reserves the resources with the Transport Domain
according to this session proposal. The Transport Domain is also updating its policies to accommodate
the resource reservation.
The Service Domain 2 then passes the session answer to the Service Domain 1, who in turn reserves the
resources with the Transport Domain 1. After the resource reservation, the Service Domain 1 sends the
session proposal to LN1.
The LN1 answers to this proposal by sending a “E2ENP_command_ready_reservation” message to the
LN2 via the Service Domains. The LN2 then answers with a “ready_reservation_ACK” to the Service
Domain 2. The Service Domain 2 activates the resources with Transport Domain 2 and propagates the
message to Service Domain 1 who in turn activates the resources with Transport Domain 1. After the
activation, the Service Domain 1 sends the “E2ENP_command_ready_reservation” message to the LN1.
Page 100
MIND
1.2
LN 1 (Offere Transport Domain
Service Domain
Service Domain
Transport Domain LN 2 (Answere
1: Invite(offer)
2: admit(resources)
3: admit_ACK
4: process(offer)
5: invite(offer*)
6: admit(resources)
7: admit_ACK
8: process(offer*)
9: invite(offer**)
11: propose(answer)
10: process(offer**)
12: reserve(resources)
14: reserve_ACK
13: update(policy)
15: propose(answer*)
16: reserve(resources)
17: update(policy)
18: reserve_ACK
19: propose(answer**)
20: process(answer**)
21: E2ENP_command_ready_reservation
22: E2ENP_command_ready_reservation
23: E2ENP_command_ready_reservation
25: ready_reservation_ACK
24: ProcessReservation()
26: activate(resources)
27: activate_ACK
28: ready_reservation_ACK
29: activate(resources)
30: activate_ACK
31: ready_reservation_ACK
32: ProcessReservation()
33: call_setup_done
34: call_setup_done
35: call_setup_done
Figure 4-20 Call setup for the Integrated Scenario
The AAA/Reservation/Activation process is the following:
•
LN gets policy token/-s from the Registry by authenticating itself over its e.g. SIM, LOGIN
INFO (by e.g. REGISTER). If by registration the system does not generate policy tokens, these
tokens can be added by the respective first access proxy as described in Section 4.3.
•
LN includes the policy token for validating the QoS requests at the service plane SPN/ASPN
(e.g. INVITE) – SIP Proxies with authorisation (Service plane Validating Facility) or the first
access proxy authenticates its user by first verifying the user’s identity by the local registry.
•
SPN/ASPN activates/deactivates reservation process at and transport AN/CN (e.g. COPS
processing).
•
The SPN/ASPN can verify the policy token/-s at the local Registry servers and/or uses the AAA
Functionality to access foreign registries.
•
The integrated service and transport plane ASPN can perform flow activation and flow teardown
at the transport plane SPN. Additional control on transport AN/CN.
Page 101
MIND
1.2
Figure 4-21 Integrated Scenario - Negotiation and Reservation Model
Page 102
MIND
1.2
5. Security Analysis
With Ad Hoc networks and vertical hand-over techniques deployed in MIND, the business models used
in the scenarios are complicated and very different from the ones generally known in mobile networking.
The increased problem complexities require a structured approach to solve the task of sketching security
solutions. The methodology used here consists of two straightforward stages: After and based on the
identification of security goals, reference points and protocol stack, security threat analysis (first) and
mechanisms (second) are delineated. In threat analysis, the assets of each participant, which must be
legally protected, are investigated and expressly described in order to clarify all the targets of possible
threats. Then appropriate technical or operational security mechanisms can be designed and adopted at the
correct level of the protocol stack modelling in order to assure that the scenarios are able to work without
compromise of defined security goals. This adoption is coherent with the methodology and architecture
found in MIND Deliverable 2.2.
Although a specific section of this document deals with accounting, we found it appropriate to discuss a
little in this place about AAA since its fundamental role is the support and justification of any trust
distribution model. And, in turn, security with parties that have no trust relationship is an oxymoron.
5.1 Methodology
From security engineering point of view, the security tools, processes, and measures are designed and
deployed to protect the predefined functional and security goals of the object system (here it is MIND
networks) against security vulnerabilities and threats. Therefore, a rather good understanding of the
functional and security goals, which stand as the basic security requirements, is certainly necessary. Since
MIND includes not only the technology of radio interface and mobile communication networks, but also
a few quite promising usage scenarios, an Open Distributed Processing (ODP) approach of analysing the
object system is definitely very helpful.
The Figure 5-1 gives an idea of how to understand MIND networks from different viewpoints, which are
inspired by ODP and helpful to identify security issues in each aspect. This figure is referred by the
methodology we adopt.
Figure 5-1 Different Viewpoints to Understand MIND Networks
Page 103
MIND
1.2
The objective of security analysis is to investigate security vulnerabilities of MIND scenarios and
networks, and then propose appropriate security mechanisms to achieve the predefined security goals.
The methodology is detailed here and some illustrative results of the security analysis are provided.
The authors would like to remind that the rest of this section indeed presents a general methodology,
which should not get confused with the concrete approach followed by the project team. Indeed, the
methodology was followed but somehow adapted and mapped to the numbering section (5.x) of this
chapter.
1. Define security goals
Security goals should be proposed based upon the system requirements, the limitation of current
techniques and the understanding of the system.
The security goals to be identified will represent the mix of interests that the involved roles have in
confidence, integrity and accountability. This defines the threat analysis’ scope. It is limited and it
does not encompass e.g. privacy management. The goals are to be elaborated and seen in the context
of accounting with respect to connectivity services, but not with respect to application oriented
services being used.
2. Identify assumptions: detail scenario and value chain
Describe the investigated scenario from asset point of view, e.g. who owns what in the scenario and
how the assets are exchanged and transferred, which is partially defined in the business value chain.
This is done in Section 5.2.
3. Identify roles & assets
Identify the appropriate roles of each participant in the scenarios. A role generally refers to the
characteristic and expected social behaviour of an individual, with special consideration of its
responsibilities, rights, and interests in our investigations and can be regarded as an abstracted entity
that always behaves in a specific way.
Identify the involved assets of each role in the scenarios. Assets are actually what the security
mechanisms are going to protect. Usually, the value of each asset presents itself in different ways,
like the confidentiality and integrity of a secret document, each of which needs to be studied and
determined if it must be protected. In order to organise the identification and presentation of assets, a
grouping is suggested in terms of asset categories. Additionally, as far as this is possible the number
of roles can be reduced when interests of roles do allow for this kind of grouping.
This results in a matrix of (asset categories) x (roles), which serves to understand the completeness
of assets to be identified. Risks and vulnerabilities shall later on be reduced by means of adequate
security, i.e. through authentication, authorisation, data integrity, logging/auditing or administration.
Sets of assets are therefore identified having an eye on these security services.
It can be expected that some of the identified sets of assets will be more important than other assets.
Also, there will be basic security mechanisms assumed allowing, for example, having authentication
and authorisation. Their selection is meaningful, as it is realistic since the systems used in the MIND
scenarios will not be widely open and unprotected. Their selection is also helpful, as on one side this
reduces the threats to be considered and on the other side will help to identify the properties of the
selected basic security mechanisms. Asset categories of MIND scenarios include electronic data,
cost, service usage, infrastructure resources, reputation, etc. This task is also done in Section 5.2.
4. Develop domain model (domains & reference points), map roles to domains
A domain model identifies different administrative domains and their respective responsibilities, the
reference points, which describe trust, relationships and interaction interfaces between them.
Technical realizations of domains encompassing functionalities and restrictions on network
components are also described in domain model. Therefore, domain model is very important when
analysing security threats and to prove proposed security and accounting mechanisms.
Administrative domains, representing functional or non-functional responsibilities and obligations
and their relationships in terms of reference points have been used to define domain models. To
Page 104
MIND
1.2
present network architecture on a high level, they abstract from technical realizations, restrictions on
network components and even domain internal details.
Roles will later be mapped to domains, which one role is allowed to hold two or more domains
simultaneously. This task is done in Chapter 3.
5. Identify protocol stacks at reference points
The protocol stacks at reference points are identified. The general communication protocols can be
roughly divided into two categories: control signalling and user data transmission. Security specific
protocols are not necessarily required to be identified at this stage. Section 5.3 deals with that aspect.
6. Perform threat analysis: who causes what threat to asset of whom
After roles/domains and their assets have been identified, the only thing left to threat analysis is to
connect asset to the other domains and then determine if this threat is possible in theory if possible,
how it may be carried out? Since value of an asset may be presented in more than one way, the
threats attacking any aspect of the value should be studied separately. Based on the assumption that
each participant does not trust any other participants, the threat(s) from every other participant to
each asset of the specific participant should be studied.
The consequences of threats are typically described as vulnerabilities. Examples of such threats are
denial of service, eavesdropping, masquerading (“spoofing”), replay, modification of information,
etc. In most cases a ranking according to a probabilistic model (probability of risk x costs of vulnerabilities) should be formulated. Instead of that, a prioritisation model will be used in MIND.
Threat analysis could be found at the very end of Section 5.2.
7. Identify necessary security services/mechanisms to counter the threats
Some general security services/mechanisms (authentication, authorisation, integrity, non-repudiation,
etc.) are proposed to counter the identified threats. This gives hints for later proposing security
solutions. This is the aim of Section 5.4.
8. Evaluate protocol stacks from security point of view
The protocols are evaluated from two sides: which threats can be countered by the protocols and
what new security vulnerabilities are introduced when deploying the protocols. This evaluation will
help further proposal of security solutions.
9. Propose security solutions
To prevent the threats, which may break the security goals, some security mechanisms and protocols
shall be used. These countermeasures should be carefully observed especially the prerequisites of
each mechanism to assure it can work properly.
With consideration that the deployed security mechanisms and protocols will not only be a part of the
whole system, but also the most possible targets of intruders, it is necessary to do security analysis
again after new security mechanisms or protocols have been proposed and deployed in the system.
The two latest aspects are left open to further investigations, as reminded in Section 5.4.
5.2 Threat Analysis
In this section we will first identify the assets of roles and domains identified in Chapter 3 and then
perform threat analysis. The presumed business model of threat analysis is presented in [TOM02] with an
exception of value chain that NP and SPN are not responsible directly of each other. Thus SPN does not
pay any charges to NP. We think that SPN will pay to AN and AN will pay to NP both for the services it
receives and on behalf of SPN.
Page 105
MIND
1.2
5.2.1 Identification of Assets
5.2.1.1 Context for Roles/Domains and Assets Identification
A security threat in risk assessment is one that is regarded as a possible danger to one asset of a
participant, which is generally taken by one of the (other) participants. A security threat comprises three
basic components: who threats what by which means. As a consequence this leads to identification of
roles (who), assets (what) and then technical means (which means). In order to organise the identification
and presentation of assets, a grouping is made in terms of asset categories.
This results in a matrix of (asset categories) x (roles) (Figure 5-4), which serves to understand the
completeness of assets to be identified.
Å asset categories Æ
Å roles Æ
< identified sets of assets >
Figure 5-2 Matrix of Asset Categories and Roles
Although we only discuss roles in this section, we will also use domains for threat analysis. Mapping of
roles to domains is given in Chapter 3.
Risks and vulnerabilities shall later on be reduced by means of adequate security mechanisms. These are
authentication, authorisation, data integrity, logging/auditing or administration. Sets of assets are
therefore identified having an eye on these security services.
Within the scenarios of WP1, it can be expected that some of the identified sets of assets will be more
important than other assets. Also, there will be basic security mechanisms assumed allowing, for
example, having authentication and authorisation. Their selection is meaningful, as it is realistic since the
systems used in the MIND WP1 scenarios will not be widely open and unprotected. Their selection is also
helpful, as on one hand this reduces the threats to be considered and on the other hand will help to
identify the properties of the selected basic security mechanisms.
5.2.1.2 Asset Identification
Assets considered in the MIND scenarios can be generally identified as
• Information/data12;
• Cost;
• Service usage;
12
Data here mainly means the user’s data and not related to the network management. It can be in different forms, in
a file or transmitted through the network. There are other data, like management information (usage record),
control signalling information (routing information). From OSI 7 layers point of view, the management and control
signalling of high layer usually are processed as part of normal user data in low layer. However, the network
management and control information are still separated from user’s data and have been put into the infrastructure
resource category even though overlap cannot be completely avoided.
Page 106
MIND
1.2
• Infrastructure resource; (e.g. hardware and software of communication system, network
management and control signalling, security subsystem, metering/charging record)
• Reputation13;
• Other assets;
An asset discussed here should be owned by a specific participant in the scenario. A few general
descriptions of common properties of assets are:
• The value of asset, which is meaningful to its owner, must not be decreased by any intervention
of the other participants without a permission of the owner, especially if the asset is a kind of
information, it must not be disclosed to any other (non-trusted) participants, because disclosure
will naturally lead to depreciation of the information. Therefore, asset itself must not be
consumed or destroyed by any other participants without permission of its owner.
• Asset’s value is not a simple concept. From different points of view, different kinds of value of
an asset can be evaluated. For example, a secret file has at least two different types of values:
confidentiality and integrity, both of which are important in the analysis. A clear description
distinguishing different type of values is necessary.
• Owner of an asset may change during the observed scenarios. The transfer of an asset’s
ownership usually accompanies another asset’s ownership transfer, e.g. when Stephanie is
working in the train with her PWA wirelessly communicating with her colleagues, the
ownerships of the usages of many kinds of services are transferred to her from their providers
respectively and are consumed by her immediately, the ownership of the money in her prepaid
account is also transferred to her Service Provider simultaneously. When the asset is transferred
to other participants, generally it is for exchanging for some other equal value assets. The
exchanging should be done fairly with respect to the contract between them or under the public
understanding. We assume such transfer takes place through a given transaction.
• An analysis of the relationships between different assets may also be important and interesting;
5.2.1.3 Assets for Roles and Domains in the Train Scenario
The assets and some remarkable properties of each participant in the observed scenario are listed in the
following. The security mechanisms and services, which can protect the identified assets (in general), are
mentioned after them in brackets.
5.2.1.3.1 LN (Leaf Network)
• The electronic data/file of LN’s work, which belongs to LN and the employer that is the actual
subscriber (S); these data/file are stored in the PWA and/or transmitted through the
communication networks;
o The data can only be viewed by the participants who need to know; in detail, the content
(and even the existence) of the data/file of their work must be kept secretly to everyone
except themselves and their colleagues who have been authorised to view the data.
(classification of data, authentication of participants)
o The data must not be changed by any unauthorised participants, especially in
communications (integrity of the data).
• The information which may describe the configuration or other properties of the PWA, etc., like
the existence, size or name of working data/file, or privacy, must only be disclosed to the
participants who need to know;
• The services delivered by the providers, for which LN/S have paid. The services can be access,
content, application, etc. with QoS levels specified in respective SLAs. Availability is an issue in
the SLA;
13
Reputation of a participant/role simply describes that she does not want anyone else to doubt if she breaks the
security regulations, which means she violates someone else’s assets.
Page 107
MIND
1.2
o The delivered services must be charged correctly, which means not be charged more,
with respect to the contract and SLA between LN and SPN; (quality and quantity of the
service versus the money deducted from the prepaid account, logging/auditing)
o The delivered services must not be consumed by any other participants without LN’s
permission; (authorisation)
o The services can be divided into clusters (access, content, application services), some of
which are out of scope of our analysis.
• The money in LN’s prepaid account, which must not be transferred to any other participants
without her permission; (authorisation)
• Temporary session key; since it is the key to join the Ad Hoc networks, it should be kept secretly
from anyone who is not authorised to join the meeting.
• the secret data which a participant exchanges with his/her company by accessing the Internet
through other IAN;
o The data can only be viewed by him/her and must be kept secretly to anyone else,
especially to IAN (Stephanie). (classification of data, authentication of participants)
o The data must not be changed by any unauthorised participants, especially in
communications (integrity of the data).
•
LN’s reputation; this asset simply describes that Stephanie does not want anyone else to doubt if she
breaks the security regulations, which means she violates someone else’s assets (non-repudiation).
5.2.1.3.2 IAN (Intermediary Access Network)
• IAN’s own sensitive data; which must not be stolen by anyone else when she is acting as an IAN.
• Network resources which will be provided to LN; anyone who wants to use these resources
should be authenticated at first to assure that the corresponding charge can be collected
(authentication).
• Reputation
5.2.1.3.3 S (Subscriber)
• Its employee’s working data, which is usually very important (valuable) and is managed by its
employee, Stephanie (LN); (authentication and integrity)
• Contents of the contract is the privacy of S, which is out of range of MIND;
• The services delivered to its employee, with respect to the contract; (quality and quantity of the
service, logging/auditing)
• The money reimbursed to its employees for the costs of usage of network services;
o The type of services, which will be reimbursed, should be agreed by the employer (S) in
advance; (authorisation)
o The reimbursed money should only cover the costs of the service usage which supports
her work for the employer (S); (logging/Auditing)
• Reputation; (non-repudiation)
Note: We may assume an utopian trustfully relationship between employee and workers. Without this
assumption, some security mechanisms should be deployed to regulate the interactions between S
and LN.
5.2.1.3.4 SPN (Service Provider Network)
• The charge from S for the delivered service, which may be deducted directly and nearly instantly
from LN/S’s prepaid account or be settled by LN/S periodically;
• The service fees which will be paid to AN, NP, and VASP because of the service usage of its S;
Page 108
MIND
1.2
o SPN should assure that the service fees it will pay to the other providers are worth the
usage of services which S/LN received; (quality and quantity of the service,
logging/auditing)
o The service usage metering records which contain the metering/charging information
and can be regarded as voucher of the usage of service;
• Reputation; (non-repudiation)
5.2.1.3.5 AN (Access Network)
• Network resources which will be provided to LN; anyone who wants to use these resources
should be authenticated at first to assure that the corresponding charge can be collected;
(authentication)
• The charge for LN’s usage of its network resources, which will be compensated by her SPN;
(logging/Auditing)
• The access service and other auxiliary services, e.g. network management, provided by NP with
QoS level specified in the SLA;
o The usage of services must be charged correctly, which means not be charged more,
with respect to the contract and SLAs between AN and NP; (QoS with respect to SLA
& fees, logging/Auditing)
o The usage of services must not be consumed by any other participants without
permission (authentication).
• Some other assets involved in the contract between itself and the NP;
• Network resource/service which is charging free for authenticated participants.
o The free charging network resource/service may include some network management
service and some introductory or basic information; Though they are charging free,
some of them are very important to the network operating, e.g. DNS (Domain Name
Service) which LN may use before she starts the video conference.
o Only permitted/authenticated participants can use this service/ resource;
o The participants who use this network resource/service have to obey some regulations,
e.g. generally too much usage of free charging service is prohibited because of potential
Denial of Service Attack.
• Metering data;
• Reputation; (non-repudiation)
5.2.1.3.6 NP (Network Provider)
• Network resources which will be provided to LN; anyone who wants to use these resources
should be authenticated at first to assure that the corresponding charge can be collected; or
perhaps from the NP point of view, this access service is provided to the AN and it does not care
whether the service has been consumed by which LNs, then there’s no necessity to authenticate
LN (authentication).
• The charge for LN’s usage of its network resources, which will be compensated by SPN.
However, in threat analysis we assume that this part of charge will be paid by AN on behalf of
SPNs, i.e. it is not necessary to ask SPN to contact NP and vice versa.
• The access service and other auxiliary services, e.g. network management service, which will be
provided to AN with QoS level specified in SLA.
o The usage of services must be charged correctly, which means not be charged less, with
respect to the contract and SLAs between AN and NP; (QoS with respect to SLA &
fees)
o The usage of services must not be consumed by any other participants without
permission (authentication).
• Metering data;
Page 109
MIND
1.2
• Reputation; (non-repudiation)
• Some other assets with respect to the contract between itself and AN
5.2.1.3.7 VASP (Value Added Service Provider)
• Application service and content which will be provided to LN; anyone who wants to get these
content should be authenticated at first to assure that the corresponding charge can be collected;
(authentication);
• The charge for LN’s usage of its content service, which will be compensated by SPN;
• Metering data;
• Reputation (non-repudiation)
5.2.2 Identification of Threats
In this section we present threat analysis for assets of a given domain or role with intruder (I) and other
domains or roles as attacker. While identifying the threats:
1.
We do not consider threats inside a domain i.e., threat of component(s) against other
component(s) in the same domain
2.
When two or more domains are administrated by one organisation, new type of threats against
other domains may exist, but are not yet considered in this analysis.
5.2.2.1 Catalogue of Threats
Table 5-1 is a catalogue of some of the security threats known and considered to be relevant. We will use
this catalogue while performing threat analysis in the following sections.
Table 5-1 A Catalogue of Threats
Threat
Passive Threat
Eavesdropping
Traffic Analysis
Reroute (man in the
middle)
Active Threat
Denial of Service
Session stealing Attacks
(Takeover, Connection
hijacking)
Masquerading; " Source
NAT" (“Spoofing”)
Replay Attacks
Modification of
Information
Network Flooding
Repudiation
Unauthorised access
Theft of Service Attacks
A potential violation of security
To listen in the line to get detailed information (Passwords, etc)
To find out which kind of communication takes place
Reroute from data streams over the own computer with the goal to
analyse the data streams
Threat with an overflow of requests to a network node. This can be
based on real or false requests, which can bring the node down.
Monitoring of the air-interface by a mobile node and his Core
Network. By recognizing an interesting communication, the attacker
flooded the mobile node with useless packets and the mobile node
stops the session. At the same time the attacker sends packets to the
core node and continues the session.
Concealing the source by using a wrong origin IP- address . NATGateways.
Interception of registration request/replay messages and send them
later with wrong Care-of-Addresses
Threats to the integrity of information could include unauthorised
message modification, message deletion, message misrouting including
rerouting, message replay, and/or the insertion of false messages.
Part of "Denial of Service"
The interception of password and authentication information of a
mobile node to get access to Mobile IP services of a service provider.
Disclosure of
information
Time falsification
Page 110
MIND
1.2
5.2.2.2 From LN’s Point of View
In general, confidentiality of LN’s electronic data that is transmitted through the communication network
or stored on its PWA may be its most important concern. Besides, LN also fears an unjustified bill, either
too high for a service he has used or for services he has not used at all. From the LN's point of view, the
threats that exist are:
Asset
Attacking
domain/role
Threat
Possible
security service
Eavesdrop the LN’s data from the air
Confidentiality
Collect general information of the LN to help
further attacks, e.g. OS version, filename, open
ports, etc.
Privacy and
management
Eavesdrop LN’s data when it passes through
Confidentiality
Tamper LN’s data when it passes through
Integrity
Collect general information of LN to help further
attacks
Privacy and
management
Eavesdrop LN’s data when it passes through
Confidentiality
Tamper LN’s data when it passes through
Integrity
Collect general information of LN to help further
attacks
Privacy,
management
Eavesdrop LN’s data when it passes through
Confidentiality
Tamper LN’s data when it passes through
Integrity
Collect general information of LN to help further
attacks
Privacy,
management
Eavesdrop LN’s data from the air
Confidentiality
Collect general information of LN to help further
attacks
Privacy,
management
Masquerade as NIP to eavesdrop/tamper LN’s data,
e.g., install a roguish access point in public area
Authentication
Fraudulently charge LN, either too high for a
service it has used or for services it has not used at
all
Non-repudiation
IAN
Fraudulently charge LN, either too high for a
service it has used or for services it has not used at
all
Non-repudiation
AN
Fraudulently charge LN, either too high for a
service it has used or for services it has not used at
all
Non-repudiation
SPN
Other LN
IAN
Data/
information
AN
NP
I
Costs
Page 111
MIND
1.2
VASP
Fraudulently charge LN, either too high for a
service it has used or for services it has not used at
all
Non-repudiation
Make LN to use its service without permission of
LN, e.g. to install a roguish agent on LN
Access control,
(firewall)
Deny to serve LN14
Authentication,
integrity
Defraud LN by providing quality-insufficient
services
Non-repudiation
IAN
Impersonate LN
Integrity,
Authentication
and nonrepudiation
Inject erroneous routes in the LN
Integrity
Cause denial of service e.g. ping very often which
leads to battery down or in some other way
Integrity
Impersonate as IAN to gather information about LN
Integrity and
Authentication
Impersonate as the LN
Integrity,
Authentication
and Nonrepudiation
deny to serve LN
Authentication,
Integrity
Other LN
Usages
service
of
AN
defraud LN
services
by
providing
quality-insufficient
Non-repudiation
SPN
defraud LN
services
by
providing
quality-insufficient
Non-repudiation
VASP
Defraud LN by providing quality-insufficient
services
Non-repudiation
Interfere LN’s usage of service, e.g. DoS attack,
user de-registration request spoofing
Authentication,
Integrity
I
Cause denial of service to LN
Masquerade as LN to request service
Authentication
I
Intrude LN’s Personal Wireless Assistant
Access control
Other LN
Intrude LN’s Personal Wireless Assistant
Access control
Resources
14
The judgement of whether it is a security threat depends on the agreement between IAN and AN. In case that IAN
is allowed to provide routing service only to the LNs it likes, this is not a threat.
Page 112
MIND
1.2
Reputation
I
Masquerade as LN to commit other attacks
Authentication
Other LN
Masquerade as LN to commit other attacks
Authentication
IAN
Masquerade as LN to commit other attacks
Authentication
5.2.2.3 From IAN’s Point of View
IAN’s main concern is to collect billings from SPN correctly and in time.
Asset
Attacking
domain/role
Threat
Possible
security service
LN
Reject a correct billing by claiming that the bill is
not correct
Non-repudiation
SPN
Reject a correct billing by claiming that the bill is
not correct
Non-repudiation
LN
Tries to use services it is not allowed to use
Authorisation
Prevent IAN from providing promised QoS to LN,
e.g., send wrong routing information to LN
Integrity
Costs
Other IAN
Usages
service
Impersonate IAN
Integrity,
Authentication
and nonrepudiation
Prevent IAN from providing promised QoS to LN
Integrity
Cause denial of service to IAN
Integrity
Prevent IAN from providing promised QoS to LN
Integrity
Masquerade as LN to request IAN’s service
Authentication
Tamper IAN’s usage metering records
Integrity
Intrude IAN’s system to e.g. change router or
routing characteristics
Authorisation
Tamper IAN’s usage metering records
Integrity
Intrude IAN’s system to e.g. change router or
routing characteristics
Authorisation
Masquerade as IAN to commit other attacks
Authentication
of
AN
I
I
Resources
LN
Reputation
I
5.2.2.4 From AN’s Point of View
AN’s main concern is to collect billings from SPN correctly and in time. One point is not included in the
following table: the assets involved in the contract between itself and NP.
Page 113
MIND
1.2
Asset
Attacking
domain/role
Threat
Possible security
service
LN
LN rejects a correct billing from SPN by claiming
that the bill is not correct
Non-repudiation
SPN
SPN reject a correct billing by claiming that the bill
is not correct
Non-repudiation
LN
Tries to use services it is not allowed to use
Authorisation
IAN
Tries to access service it is not allowed to access
Authorisation
Prevent AN from providing promised QoS to LN
Integrity
Masquerade as LN to request services of AN
Authentication
Tamper AN’s usage metering records
Integrity
Intrude AN’s system to e.g. change router or
routing characteristics
Authorisation
I
Masquerade as AN to commit other attacks
Authentication
IAN
IAN does not provide the QoS requested by LN and
blames AN
Non-repudiation
Costs
Usages
service
of
I
Resources
I
Reputation
5.2.2.5 From SPN’s Point of View
Usually SPN does not trust its LNs, therefore to collect billings from LN without contention may be its
main concern. However, attacks against its LN by other participants are definitely unacceptable since the
affected LNs mostly will change their subscriptions to other SPN, which means profits lost of the SPN.
Asset
Attacking
domain/role
Costs
LN
IAN
Threat
Possible
security service
Doesn't pay for its account
Management
Defraud SPN by falsely claiming that a bill is not
correct
Non-repudiation
Defraud SPN by presenting wrong accounting
information for a subscriber’s LN
Non-repudiation
Masquerade as a subscriber of SPN to request NIP
or VASP services in order to obtain service fees
from subscribers via the SPN
Authentication,
Management
Page 114
MIND
1.2
Defraud SPN by presenting wrong accounting
information for a subscriber’s LN
Non-repudiation
Masquerade as a subscriber of SPN to request NIP
or VASP services in order to obtain service fees
from subscribers via the SPN
Authentication,
Management
Defraud SPN by presenting wrong accounting
information for a subscriber’s LN
Non-repudiation
Masquerade as a subscriber of SPN to request NIP
or VASP services in order to obtain service fees
from subscribers via the SPN
Authentication,
Management
Other SPN
Defraud the SPN by presenting wrong accounting
information for its LN
Non-repudiation
VASP
Masquerade as a subscriber of SPN to request NIP
or VASP services in order to obtain service fees
from subscribers via the SPN
Authentication,
Management
I
Masquerade as a subscriber of SPN to request NIP
or VASP services in order to obtain service fees
from subscribers via the SPN
Authentication,
Management
IAN
Defraud SPN’s subscribers by providing qualityinsufficient services
Integrity,
Management
AN
Defraud SPN’s subscribers by providing qualityinsufficient services
Integrity,
Management
NP
Defraud SPN’s subscribers by providing qualityinsufficient services
Integrity,
Management
VASP
Defraud SPN’s subscribers by providing qualityinsufficient services
Integrity,
Management
I
Preventing NIP or VASP from providing promised
QoS to LN
Integrity
I
Tamper SPN’s usage metering records
Integrity
LN
Cause any other problem such that people do not
use the SPN
Authentication
I
Cause any other problem such that people do not
use the SPN
Authentication
AN
NP
usages
service
of
Resources
Reputation
5.2.2.6 From NP’s Point of View
As mentioned in Section 5.2.1.3.6 the charge for usage of NP’s network resources will be compensated
by AN on behalf of SPNs. Therefore, the threats against NP are mainly related to the contract between
itself and AN.
Page 115
MIND
1.2
Asset
Attacking
domain/role
Costs
Usages
service
of
Threat
Possible security
service
AN
Reject a correct billing by claiming that the bill
from SPN is not correct
Non-repudiation
AN
Tries to use services it is not allowed to use
Resources
I
Reputation
I
Authorisation
Tamper NP’s usage metering records
Integrity
Intrude NP’s system to e.g. change router or routing
characteristics
Authorisation
Cause problem e.g. degradation of service quality,
leading to customers not using services of NP
Authentication
5.2.2.7 From VASP’s Point of View
Attacking
domain/role
Asset
Costs
Usages
service
of
Resources
Threat
Possible security
service
LN
Reject a correct billing from SPN by claiming that
the bill is not correct
Non-repudiation
SPN
Reject a correct billing by claiming that the bill is
not correct
Non-repudiation
I
Masquerade as LN to request service of VASP
Authentication
LN
Tries to use services it is not allowed to use
Authorisation
I
Prevent VASP from providing promised QoS to LN
Integrity
I
Tamper ASP’s usage metering records
Integrity
I
Cause problem e.g. degradation of service quality,
leading to customers not using services of VASP
Authentication
SPN
Cause problem e.g. degradation of service quality,
leading to customers not using services of VASP
Integrity
Reputation
Page 116
MIND
1.2
5.2.3 Summary of Threat Analysis
A summary of all the threats from and to various roles or domains and Intruder (I) are given in Table 5-2.
Table 5-2 Summary of Threats.
Page 117
MIND
1.2
5.3 Protocol Stacks
This section identifies the protocol stacks at network layer for reference points (RPs) of the train scenario
domain model (Figure 2-2). Threat analysis done in Section 5.2 can be used to find the weakness of
protocols at each RP this information can then be used to modify the protocols to counter the threats.
We focus our work on mobility and security issues so signalling protocols related to QoS are not
considered here.
5.3.1 Protocol Stacks and Reference Points
The protocol stacks can be divided in two categories (Figure 5-3): control plane protocols (CPs) and User
Plane protocols (UPs). The formers are those used for signalling, session management etc. while the latter
are used for actual data transmission.
Control plane protocol stacks can either be Ad Hoc protocols, which can lie at any point in protocol stack
from above Layer-1 onwards or Mobile Node – BRAIN Access Router (MN-(B)AR) which lies over Ad
Hoc protocols.
User plane protocol stack can be same for all RPs. By TCP/IP (Transmission Control Protocol / Internet
Protocol) protocol suite in user plane protocol stack we mean any protocol defined by Internet
Engineering Task Force (IETF) that can be used for data transmission.
Figure 5-3 Control Plane and User Plane Protocol Stacks.
Figure 5-4 Control Plane Protocol Stacks at Various Reference Points
Page 118
MIND
1.2
In Figure 5-4 the protocol stacks at different RPs are given. Please note that even if the protocol stacks at
various RPs are identical it does not implicate at all that the RPs themselves are the same. Threat analysis
is in any case needed in order to evaluate in which terms multiple RPs differentiate one with each others.
5.3.2 AAAB Considerations
The Domain Model (Figure 5-1) introduced above contains the concept of AAAB. For the sake of clarity,
this section extracted from [GLA00] introduces the role and functions of such a component and is a first
step towards the identification of protocols or protocol requirements that should be put into this protocol
stack model.
In order to be pragmatic and since AAA, as security, is almost never a feature per se but rather an add-on
feature (in case of AAA it enables roaming outside a restrictive area), we consider AAA used in
conjunction with a network layer mobility management protocol like Mobile IP, our illustrative protocol
in the rest of this section. In other words and for stating the rational: It is because of mobility that we need
roaming. Although a specific section of this document deals with accounting, we found it appropriate to
discuss in that place about AAAB since its fundamental role is the support and justification of any trust
distribution model.
It should be emphasised that MIND indeed uses another mobility management protocol (BCMP) but for
the sake of our discussion here around AAAB benefits and function we can in a first approximation
confuse them.
The MIND Domain Model assumes that the various components of the domain trust each other.
Depending on the security model used, this configuration can cause a quadratic growth in the number of
trust relationships, as the number of AAA authorities (AAAL and AAAH) or, respectively with respect to
Figure 5-1, the number of ANs and SPNs increases. Any AAA proposal (i.e. the ones discussed in the
IETF) must solve this problem. Using brokers solves many of the scalability problems associated with
requiring direct business/roaming relationships between every two administrative domains. In order to
provide scalable networks in highly diverse service provider networks in which there are many domains
(e.g., many service providers and large numbers of private networks), and multiple layers of brokers must
be envisaged.
Integrity or privacy of information between the home (SPN) and serving domains (AN) may be achieved
by either hop-by-hop security associations or end-to-end security associations established with the help of
the broker infrastructure. A broker may play the role of a proxy between two administrative domains that
have security associations with the broker, and relay AAA messages back and forth securely.
Alternatively, a broker may also enable the two domains (SPN and AN) with which it has associations,
but the domains themselves do not have a direct association, in establishing a security association, thereby
bypassing the broker for carrying the messages between the domains. This may be established by virtue
of having the broker relay a shared secret key to both the domains that are trying to establish secure
communication and then have the domains use the keys supplied by the broker in setting up a security
association.
Assuming that AAAB accepts responsibility for payment to the serving domain on behalf of the home
domain, the serving domain is assured of receiving payments for services offered. However, the
redirection broker will usually require a copy of authorisation messages from the home domain and
accounting messages from the serving domain, in order for the broker to determine if it is willing to
accept responsibility for the services being authorised and utilized. If the broker does not accept such
responsibility for any reason, then it must be able to terminate service to a mobile node in the serving
network. In the event that multiple brokers are involved, in most situations all brokers must be so copied.
This may represent an additional burden on Foreign Agents and AAALs.
Though this mechanism may reduce latency in the transit of messages between the domains after the
broker has completed its involvement, there may be many more messages involved as a result of
additional copies of authorisation and accounting messages to the brokers involved. There may also be
additional latency for initial access to the network, especially when a new security association needs to be
created between AAAL and AAAH (for example, from the use of IPSec keying mechanisms). These
delays may become important factors for latency-critical applications.
Page 119
MIND
1.2
IAN
AAA
B
LN
AN
AAAL
AAAB:
AN:
IAN:
LN:
SPN:
SPN
AAAH
Reference Point
Authentication Authorization and Accounting Broker
Access Network
Intermediary Access Network
Leaf Network
Service Provider Network
Figure 5-5 AAA Entities in the MIND Domain Model and Reference Point.
The AAAB in Figure 5-5 is the broker's authority server. The broker acts as a settlement agent, providing
security and a central point of contact for many service providers and enterprises.
The AAAB enables the local and home domains to cooperate without requiring each of the networks to
have a direct business or security relationship with all the other networks. Thus, brokers offer the needed
scalability for managing trust relationships between otherwise independent network domains. Use of the
broker does not preclude managing separate trust relationships between domains, but it does offer an
alternative to doing so. Just as with the AAAH and AAAL, data specific to Mobile IP control messages
must not be processed by the AAAB. Any credentials or accounting data to be processed by the AAAB
must be present in AAA message units, not extracted from Mobile IP protocol extensions.
The following requirements discuss use of brokers in the particular case of authorisation for roaming dialup users but could be extended for our project framework.
•
Allowing management of trust with external domains by way of brokered AAA.
•
Accounting reliability. Accounting data that traverses the Internet may suffer substantial packet
loss. Since accounting packets may traverse one or more intermediate authorisation points (e.g.,
brokers), retransmission is needed from intermediate points to avoid long end-to-end delays and
unnecessary network traffics.
•
End to End security. The Local Domain and Home Domain must be able to verify signatures
within the message, even though the message is passed through an intermediate authority server.
Since the AAAH in the home domain may be sending sensitive information, such as registration keys, the
broker must be able to pass encrypted data between the AAA servers.
The need for End-to-End security results from the following attacks which were identified when brokered
operation uses RADIUS [RIG97] (see [ABO99] for more information on the individual attacks):
•
Message editing
•
Attribute editing
•
Theft of shared secrets
•
Theft and modification of accounting data
•
Replay attacks
•
Connection hijacking
•
Fraudulent accounting
Page 120
MIND
1.2
These are serious problems that cannot be allowed to persist in any acceptable AAA protocols and
infrastructure and the MIND solution framework as found in Chapter 4 or in the MIND Deliverable 2.2
document does not allow them to occur.
5.4 Security Mechanisms
After the respective descriptions of the situation of mobile networking environment and the potential
menace, this section proposes counter measures that could be adopted by the various parties identified in
Section 5.2.
As the Internet moves towards a picture where mobility is predominant, we can identify two opposite
approaches adopted by engineers and protocol developers: either they choose to adopt (or re-shape)
existing standard Internet protocol, more or less trying to save the original end-to-end paradigm, or they
create an entirely set of standards applicable only to the wireless world (and, more generally, only to a
specific architecture). In-between solutions are seldom. We use this taxonomy through the three following
sections and conclude about pertinence regarding applicability to MIND.
We found it inappropriate to come again with a newly security solution that in turn will be only MINDspecific. Instead of an explicit action plan, a suggestive list is therefore submitted; there are namely just
too many (well defined indeed) solutions found in the literature, projects, and standardization areas for
securing the mobile ubiquitous networking environment.
As the Internet moves towards a picture where mobility is predominant, we can identify two opposite
approaches adopted by engineers and protocol developers: either they choose to adopt (or re-shape)
existing standard Internet protocol, more or less trying to save the original end-to-end paradigm, or they
create an entirely set of standards applicable only to the wireless world (and, more generally, only to a
specific architecture). We use this taxonomy in the rest of this section and conclude with the possibility of
merging both approaches.
5.4.1 The Internet Approach
The so-called Internet approach is best represented by the IETF. But also around this forum, various
approaches (merely incarnated by working groups) could be selected for the one wanting to secure all or
only some segments, either according to threats or reference points of the mobile computing framework.
We here present a non-exhaustive listing of existing solutions, whose maturity is highly variable.
5.4.1.1 Mobile IP and IPSec
Mobile IP is a layer 3 protocol and an IETF standard [PER02] designed to serve the mobile users who
wish to connect to the Internet and maintain communications as they move around. Mobile IP is based on
the idea of IP-in-IP encapsulation and use of a Home Agent (HA) to forward packets from a mobile host's
original location to its current location i.e. its IP care-of-address which can be collocated to the MN itself
or points towards a local attendant in the visited network called Foreign Agent (FA). The version for IPv6
networking, Mobile IPv6 is not yet finalized.
IP Security (IPSec) [ATK95] is a generic name for the concept of “full” security services (data origin
authentication, connectionless data integrity authentication, data content confidentiality, anti-replay
protection) and a method of protecting IP datagrams for IPv4 as well as IPv6 nodes.
An Internet Draft [TES02] highlights some of the issues that should be considered when IPSec and
Mobile IP inter-work with each other. This work finds some applications in the following fields: VPN
traversal requirement [ADR02], IPSec Remote access client co-located with a Mobile Node, IPSec
security Gateway running in parallel with a Home Agent or a Mobile Internet Protocol (MIP) Proxy
[IYE02] .
5.4.1.2 Mobile Router Support with Mobile IP
Another Internet draft [KNI02] (and, subsequently, another problem) addresses how to support mobile
networks with Mobile IP or Mobile IPv6 and proposes a solution for it. Within the context of this
document, a Mobile Router is defined as a node which operates as a Mobile Node as detailed in Mobile
Page 121
MIND
1.2
IP or Mobile IPv6, but has the additional capability of routing between its point of attachment (Care-of
Address), and a network fragment (subnet) which moves with the mobile router.
Providing a generic scalable solution for the address ownership problem may prove to be complicated. A
problem is, how can a mobile router or an intermediate agent efficiently authorise multiple fixed and
mobile nodes to communicate with their peers, when all these may be from multiple different domains,
and the mobile router is not an end node for their communication. Other solutions using inter-domain
routing protocols may be possible, depend on the willingness of the routing infrastructure to trust mobile
routers.
5.4.1.3 Global Connectivity for IPv4 Mobile Ad Hoc Networks
Belding-Royer et al. elaborate in [BEL01] Mobile Ad Hoc Networking (MANET) and mobile networking
(i.e. the problem raises by a network that moves as a whole).
This document describes how to provide Internet connectivity to mobile Ad Hoc networks (an Ad Hoc
network is a group of wireless mobile computers (or nodes), in which individual nodes cooperate by
forwarding packets for each other to allow nodes to communicate beyond direct wireless transmission
range). It describes a mechanism whereby the Ad Hoc On-Demand Distance Vector (AODV) Routing
protocol can cooperate with the Mobile IP protocol such that mobile nodes within an Ad Hoc network,
which are out of direct transmission range of a Foreign Agent, can obtain a care-of address and register
with the Foreign Agent to obtain Internet connectivity. Mobile IP is used for mobile node registrations
with a Foreign Agent, while AODV is used for routing within the Ad Hoc network and for obtaining
routes to the Foreign Agent. Once a MANET node has a care-of address, it may send data packets to
destinations in the Internet by routing through the Foreign Agent.
5.4.1.4 Extensible Authentication Protocol over IP (EAPoIP)
Extensible Authentication Protocol over IP (EAPoIP) [ENG02] is basically a variation of the Extensible
Authentication Protocol (EAP). Unlike EAP, it runs over IP. EAPoIP is intended primarily for
authentication of hosts in an access domain. EAPoIP assumes that the host has established a link-layer
connection to an access router and has configured a valid IPv4 or IPv6 address for itself on the subnet by
DHCP, by address auto-configuration, or by other means. Dynamically configurable firewalls may be
used to shield unauthenticated and unauthorised hosts on the access subnets from resources in the inner
parts of the access domain. This solution elaborates on Protocol for carrying Authentication for Network
Access (PANA), which is a general authentication protocol (requires using PPP framing for the data
packets and 802.1x provides EAP authentication limited to IEEE 802 link layers) between a user's device
and a device at the network access point developed within the IETF PANA working group. The network
access device itself might be a client of the AAA infrastructure.
A PANA Authentication Agent (PAA), which is an Authentication Server located somewhere in the
access domain, authenticates the host. The host may also authenticate the PAA.
5.4.1.5 Secure Socket Layer (SSL)
On the contrary to Mobile IP and IPsec, Secure Socket Layer (SSL co-founded here with TLS defined in
[DIE99]) is a protocol running above transport layer which provides encryption, source authentication
and integrity protection of application data over insecure public network. SSL is commonly perceived as
being too heavyweight for weaker CPUs and low bandwidth high latency wireless networks, though
improvements are perceived both in PDA’s technology side as well as wireless network speed one.
Moreover, even if none of the popular wide-area wireless data services today offer SSL on a handheld
device, developers [SUN01] have implemented SSL client on small wireless devices.
Those ‘Internet’ standards are widely adopted and are justified by the success of the IP Protocol. Though ,
they are not well suited for a world were the end-to-end paradigm is barely applicable (many players on
the MIND playground may deploy some type of ‘walled-garden’). Somehow, we believe that the highly
unpredictable nature of the MIND environment as well as the atomisation of trust distribution induced by
the rich MIND domain model (not to mention the inherent limitation of the mobile computing
environment like e.g. battery life) make those protocols inappropriate.
Page 122
MIND
1.2
5.4.2 Wireless and Architecture-Specific Approaches
Far previous to the Internet activity around security and mobility, the wireless world, in particular GSM,
standardized solution relying on the security module (or Subscriber Identity Module) for authentication to
the network based on a long-term subscriber authentication key before a user is allowed to use any service
from that network. The security module is required to encrypt the voice call with the symmetric key
generated in the Subscriber Identity Module (SIM). The SIM therefore is an integral part of the GSM
architecture, providing security data storage and cryptographic processing.
Besides cellular solutions, the so-called Wireless Fidelity (Wi-Fi) sector also provides proprietary
solution addressing the threats described above. So we kindly point the reader to the references found in
the subsequent section below.
5.4.2.1 GSM and UMTS
Providing services to networks is the most common use for security modules today. The Universal
Subscriber Identity Module (USIM) is the 3G version of the SIM to work with the Universal Mobile
Telecommunications System (UMTS) network. It supports 3G protocols and is backward compatible to
support 2G authentication methods for access to 2G networks. Although the USIM is not regarded as a
physical entity, it is seen as a logical application that resides on a Universal Integrated Circuit Card
(UICC). The UICC contains one or more USIMs and possibly other applications (e.g. credit card
functionality or WIM). By inserting the USIM-card into a UMTS terminal, the user is recognised by the
UMTS network and can be addressed on this terminal via his personal telephone number (MSISDN).
5.4.2.2 CHOICE Service Platform
‘CHOICE’ [BAH02] is a service platform on which any number of network providers can offer network
services, enabling users to choose the kind of services that best feed their need.
Here, the lack of an implicit trust relationship between the users and the public network is solved by the
fact that the AAA infrastructure is agnostic of the authentication protocols used (all users may not prefer
the same way of authentication). CHOICE namely supports multiple authentication modes like E-Cash
systems, credit card, digital certificates and so on. Once authenticated CHOICE returns a key used for
encryption/decryption services, a key_id (an index into an array of valid (key, token) pairs) and a security
token to the user’s mobile device for identification purpose (the token is the value that is tagged to very
packets before encrypting it with the key). The client module receives and stores the (key, token) pair and
sets the default gateway to an advertised Gateway address. The mobility management is solved in the
sense that when living the public network area, the client, though restoring default network setting still
has the un-expired (key, token) pair stored in a table indexed by the advertised network identifier which
can be re-used by further reconnection to the public network.
5.4.2.3 802.1x
802.1x [802.1x] defines a standard mechanism for Port-based network access control that makes use of
the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of
authenticating and authorizing devices attached to a LAN port that has point-to-point connection
characteristics, and of preventing access to that port in cases in which the authentication and authorisation
process fails.
As described in MIND, IEEE 802 LANs are often deployed in environments that permit unauthorised
devices to be physically attached to the LAN infrastructure, or permit unauthorised users to attempt to
access the LAN through equipment already attached. Examples of such environments include corporate
LANs that provide LAN connectivity in areas of a building that are accessible to the general public, and
LANs that are deployed by one organisation in order to offer connectivity services to other organisations
(for example, as may occur in a business park or a service office building). In such environments, it is
desirable to restrict access to the services offered by the LAN to those users and devices that are
permitted to make use of those services. 802.1x
Those ‘wireless’ solutions suffer from what is considered as advantages from the Internet point of view:
They are too proprietary and do not encompass a global picture like ours. Therefore, as we stated in the
previous section, we cannot adopt these solutions for the MIND framework.
Page 123
MIND
1.2
5.4.3 Merging the Two Worlds
This section proposes some solutions developed to bridge specific architecture to the whole Internet
picture frame, in a similar movement to the one perceived, in the mobile telecommunication place, with
the recent 3GPP’s ‘All-IP’ initiative.
Of course, reading the critics previously addressed to the Internet as well as the wireless world, the need
of such bridging initiative was evident and it is not so pertinent to conclude with saying that the truth is
‘somewhere in the middle between the two worlds’. But the facts are quiet ‘têtus’ and here they show, as
the existence of proposals and products listed below proves it, that indeed combining in an intelligent way
benefits from the two sides (Internet and wireless) is the solution for the secured MIND framework.
5.4.3.1 GSM SIM Key Generation for Mobile IP
The document from Haverinen [HAV01] specifies a mechanism for Mobile IP network access
authentication and key distribution using the GSM Subscriber Identity Module (SIM). The mechanism
uses new subtypes of the generalized key distribution extensions for Mobile IP Registration Request and
Registration Reply. After the registration keys have been generated, the default Mobile IP authentication
with these keys can be used (MD5 in prefix + suffix mode). The keys can be used for several subsequent
registrations. However, there are lifetimes for the keys and before the lifetimes expire, new keys can be
generated with the same procedure.
So the SIM feature is only used for key generation (the credential of the SIM card are not use for
authenticating Mobile IP registration messages).
By using the SIM key exchange, no other pre-configured security association besides the SIM card is
required on the mobile node.
5.4.3.2 Windows for SMART Cards
In contrast to GSM there will be a multitude of different types of terminals in UMTS, e.g. multi-mode or
multi-band handsets, notebook-like communicators or UMTS-laptops with camera, speakers, and
microphone all equipped with a USIM-card (see above). There will be terminals too where more than one
USIMcard can be inserted. This means that some terminals (e.g. fax terminals) shall be used by several
UMTS-customers simultaneously. The USIM stores the identity of the subscriber (user), operator, and
service provider and (at least one) user service profile. This service profile defines the services that a
customer is subscribed to, the time and the network where he can use them. LAN services have also
adopted the use of security modules for secure log on. The security module like in the GSM world
authenticates the user to the network in order for the user to use the services offered by the network. The
security module can also be used to sign e-mails and hold encryption keys to encrypt e-mails and other
data. An example of this is the Windows for smart cards platform [WIN01] . It allows smart card
authentication and encryption with the current windows operating systems. Windows for smart cards can
be programmed for one or more users, a user can not have concurrent account usage, and smart cards will
be used to authenticate a user on to a PC or a network. The security credential such as a password or a
biometric value is stored on the smart card, this is compared to the template stored on the network as with
an ordinary secure log-on system.
5.4.3.3 IEEE 802.1X RADIUS Usage Guidelines
IEEE 802.1X (see above) enables authenticated access to IEEE 802 media, including Ethernet, Token
Ring, and 802.11 wireless LANs. Although RADIUS support is optional within IEEE 802.1X, it is
expected that many IEEE 802.1X Authenticators will function as RADIUS clients.
The document draft [CON02] provides suggestions on RADIUS usage by IEEE 802.1X Authenticators.
Support for any AAA protocol is optional for IEEE 802.1X Authenticators, and therefore this
specification has been incorporated into a non-normative Appendix within the IEEE 802.1X specification.
IEEE 802.1X does not require use of a backend authentication server, and thus can be deployed with
stand-alone switches or access points, as well as in centrally managed scenarios.
Page 124
MIND
1.2
In situations where it is desirable to centrally manage authentication, authorisation and accounting (AAA)
for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In
such situations, it is expected that IEEE 802.1X Authenticators will function as AAA clients.
This document provides therefore suggestions on RADIUS usage by IEEE 802.1X Authenticators.
Support for any AAA protocol is optional for IEEE 802.1X Authenticators, and therefore this
specification has been incorporated into a non-normative Appendix within the IEEE 802.1X specification.
As a testimony of the good work between standardisation bodies, this document is currently being revised
as part of the IEEE 802.1aa effort, and is being presented to the IETF for informational purposes.
5.4.3.4 Inter-working Between IP Security and Performance Enhancing Proxies for Mobile
Networks
Motivated by the convergence of Internet and wireless multimedia and in an attempt to make IP more
suitable to 3G mobile networking, [ASS02] suggest a scheme that allows the coexistence of IPSec and
Performance enhancing proxies (or PEPs). The usage of PEPs, though improving TCP/IP performance
over wireless link, compromises end-to-end security. PEP module acts on the TCP headers and
manipulates the flow of acknowledgements. Within the UMTS architecture, PEP is usually implemented
in the RNC.
In most cases PEP can handle traffic applying security protocol above the transport layer such as SSL.
However, only a limited number of applications (mostly Hyper Text Transfer Protocol over Secure
Socket Layer (HTTPS)) include support for the use of transport layer security nowadays. IPSec, on the
contrary, can be transparently used by any application. The major problem of inter-working between PEP
and IPSec is that PEP cannot act on traffic protected by IPSec because it cannot examine the encrypted
TCP headers of IP packets.
The solution described in [ASS02] is roughly an intelligent switch that recognizes and discriminates IP
Packets: If IP packets are unencrypted, the PEP can read the TCP headers. In the encrypted IP packet
case, there are two options: either the packets bypass the PEP module and are directly forwarded to the
mobile hosts, in which case PEP will not bring any benefits; or the user can trust the PEP in the middle,
and IPSec can be used between each end system and the PEP. In general, though, the end user cannot
trust PEPs, or the trust distribution is too heavy weight, and this is not as secure as end-to-end security, as
many security experts believe, primarily because the traffic might be exposed when it is decrypted for
processing.
Research activities are underway for investigating the possibility of changing the implementation of
IPSec to more easily use PEP.
All these proposals, trying to merge two worlds, broadly speaking, have in common the fact that they
force heterogeneous building components to talk with each other. This of course requires mapping
functions and protocols, meaning in turn Inter Working Function, Gateway and common interfaces.
The wise conclusion sounds therefore: If you are an actor of the MIND domain model, in order to open
yourself to a secured mobile communicating scenario you should be ready to accept the necessary
compromising with other entities you are not usually used to communicate with.
Page 125
MIND
1.2
6. Accounting and Billing
Accounting consists traditionally of the operations of metering resource consumption, collection of
metered data and definition of pricing schemes to perform the charging and finally, the billing of
customers. Usually these operations take place within the domain administrated by the same authority
(Figure 6-1).
Figure 6-1 Information Flow in the Accounting Process
However, the traditional accounting architectures developed today do not pay special attention to mobility
problems through heterogeneous networks or through different administrative domains, and to the
inclusion of Ad Hoc sub-networks, as considered in the MIND scenarios. Existing accounting
architectures do not cover the future mobile multimedia users requirements, where a customer may have
the ability to move easily from place to place, from access provider to access provider and retain access to
a rich set of information and communication services like, for example, receiving information during his
session about the current costs (hot billing) and where there will be multiple business relationships among
the actors. The basic characteristics of such a system from the end-user point of view are location
independence, device independence, motion independence, and ease of use.
Because the MIND scenarios include such provocative challenges, an administrative domain model was
build in order to trace the boundaries, the roles and the responsibilities between the various players (see
also Chapter 3 for details).
The Accounting and Billing issues have been introduced in [ALEJ02], analysing the problem only from
the transport domain point of view. Main differences between service layer accounting and transport layer
accounting are related to the different roles of each of the players in both layers and to the differences in
negotiating and metering the events. There exist many distinctions between how to perform the
accounting in both layers, and there are multiple relationships among the service and transport domain
providers.
Page 126
MIND
1.2
Figure 6-2 MIND Basic Domain Model
In this chapter, an accounting and billing high level architecture will be outlined for an integrated telecom
environment following the value chain model explained in [ALEJ02]; moreover, the possible scenarios of
collaboration between service layer players and transport layer will be analysed ones following the
domain model approach exposed in [ALEJ02].
The methodology to be used will be the following: The value chain provided in [ALEJ02], will be
analysed from the point of view of the business relationship among players, and the conclusions will be
mould in the Domain Model (Figure 6-2). Later on a first accounting and billing architecture skeleton for
the MIND domain model will be proposed and an example will be extracted from Chapter 4 related to
interworking scenarios.
As will be explained below, relationships among Applications Service Providers (ASP), Service
Providers Networks (SPN), Core Network providers (CN), and Access Providers (AP) for a specific
service, will be driven by a business model; a high level accounting architecture cannot be defined
without studying first the business relationship among those entities.
6.1 Value Chain Analysis
The main purpose of the value chain analysis is to provide a guideline for the discussion about the
business relationship among the players in a service and transport collaborative environment. This value
chain will be the main driver model for the selection of the business model that will be proposed in the
next section.
In this value chain several actors can be identified.
The first actor that takes part is the end user. In the value chain the end user has two roles, end-user and
subscriber. The end user will use the service, receive the bill, and pay for it. In the value chain it can be
observed how the user pays to the service provider for the use of both service and transport services. So, it
is supposed that the network provider and the service provider will deliver just one unified bill, and in the
value chain the service provider delivers the bill to the end user.
The Value Chain (Figure 6-3) shows how net revenues paid by the end-user are shared between the wellknown providers. The percentages base on the present split in mobile Internet world.
Page 127
MIND
1.2
Figure 6-3 MIND Basic Value Chain for the Nomadic Working Scenario
Currently the service provider offers service or a bundle of services and earns the money from the enduser. From these revenues he has to pay the network provider (i.e. Access and Core Network provider),
the ASP and the content provider. In our example the network provider gets a share of 10% of the whole
revenue. With this amount he has to cover all his costs and has to realise profit. The application provider
who develops software for service-applications receives 20% of the service providers’ income for
supplying the special applications. The content provider receives 40% for his service what is the major
part of the income.
The mentioned percentages should only be used for orientation. It is very hard to estimate how the
revenue for services discussed in this paper will be split in future times. But it is quite clear that market
shares will move. All European network providers have to recognise that margins in core business of
voice communication become even smaller. The smaller margins and the current competitive situation of
network providers will substantially influence the telecommunications industry in the next years.
6.2 Mobile Internet Roles Analysis
This section deals with general business models driving a relationship between services providers and
transport providers. An accounting architecture is strongly related to the business relationships among the
companies involved in the delivering of that services, as was shown in the last section, and the role of
each of the entities involved in these relationships. In this section a role analysis of the operator will be
explained and later on an analysis of the possible business relationship will be provided.15
15
Definition of operator – public land mobile network (PLMN): A network that is established and operated by an
administration or by a recognized operating agency (ROA) for the specific purpose of providing land mobile
telecommunications services to the public. Note: A PLMN may be considered as an extension of a fixed network,
e.g. the Public Switched Telephone Network (PSTN) or as an integral part of the PSTN. Institute for
Telecomunications Science.
Page 128
MIND
1.2
Before analysing different business relationship scenarios, it is mandatory to introduce the basic business
roles that define how a company is perceived when working with services within a mobile internet
environment, i.e. ASP, Service Network Provider’s entities and operators, etc. Generally speaking
transport providers have had the role of the traditional telecom operators, and service providers have been
Internet ASPs. Nowadays transport providers want to provide value added service too, and the business
models described below help to understand how that relationship can be managed.
Operators are going to play different business roles depending on the services offered. The following
roles can be identified (Figure 6-4):
•
Bit-Pipe Provider, meaning that the operator just provides connectivity enabling end-to-end
communication between external Service Providers and end-users.
•
Channel Provider, meaning that the operator provides enabler services (Positioning, Messaging,
…) and eventually Charging Services to external Service Providers who directly interact with the
end-users (i.e. handle the customer relationship for those services),
o
•
Application Service Provider, meaning that the operator will have the role of Applications
Service Provider too. This role can be a super-set of the channel provider model when the
ASP is the operator. In the picture it can be assimilated to the channel provider role.
Service Provider, meaning that it is the operator who acts as the counterpart for services to endusers.
Service Provider
From those three business roles the most attractive to operators as well as the most challenging to
implement in his full extent is that of the Service Provider, and that is the reason why this scenario
requires more attention.
It is extremely important to understand that this is the general scenario that operators are facing where
obviously Service Provider is not equivalent to Walled-Garden. Service Provider is a business role
towards the subscriber and Walled-Garden is just one out of a lot of different types of environment
allowing operators to implement this role.
Figure 6-4 Business Roles
Page 129
MIND
1.2
Operators will implement this Service Provider role in different ways for different cases, with the
following possible configurations:
•
ASP Configuration: Services exploited in this configuration are hosted by ASPs but offered by
the operator to the end-users. This configuration has in turn several variants according to
organisational, ownership and trust models.
•
Walled-garden: Services in the Walled-garden are directly run by the operator and hosted in
operator’s sites.
Summarising operators will play the role of Service Providers towards their subscribers no matter who
hosts these services and this must be transparent to the end-user. The architectural implications of the
implicit need of the operator to create the necessary trust for the end-user in scenarios where Services can
be hosted by operators, distributed across the global group or hosted and operated by partners and yet
guaranteeing End-to-End Service Assurance to the end-user is the key issue to concentrate on.
Channel Provider
In a number of cases operators play today, and will play in the future, the Channel Provider role. This is
the business scenario advisable for the case of external Service Providers with a huge branding
themselves and a broad customer base of their own. The operator itself can be an Application Service
Provider to other operators or Service Providers.
Bit-Pipe Provider
Finally, of course, operators may in some cases just play the bit-pipe provider role, which is not restricted
at all. This provides with traffic revenues and market penetration on the mobile side.
It is important to remark that the Channel Provider role and the Bit-Pipe Provider role can be, but are not
in general, strategies or steps towards the Service Provider role. All business roles and configurations
must coexist and the one applied for a particular service or case will be that judged most appropriate
according to business, strategic, competence, and technical criteria.
The first priority for the operators to supporting a variety of business models is derived from the fact that
operators cannot compromise to a given architectural solution for the Service Layer that makes it
impossible for them to distribute services in different domains as they like or restricts the right to
implement different business models. Such freedom is mandatory when different approaches for different
types of customer segments, services, and markets where operators need to gain market share of data
services must be possible. This is in the end an ambitious structural requirement on the solution: that
different business models can be flexibly supported and coexist.
There are several ways of combining these business roles in a real services environment. Some of the
relationships among players are illustrated in the Table 6-1 following. Partners belonging to the same
company or group of companies are coloured and shaded in the same way. The role of the traditional
mobile telephony operator is marked in green (or diagonal) cells.
Table 6-1 Partners Business Relationship
Case 1
Case 2
Case 3
ASPN
SPN
CN
AN
Page 130
Case 4
Case 5
Case 6
MIND
1.2
The meaning of the relationship of each of the columns in the table can be analysed matching with the
business roles explained above for a service. The role of the partnerships can change depending on the
type of service delivered.
Case 1
In this relationship model the role of the operator can be associated to the bit pipe provider. The
business model consists of one or several companies providing application or services. Other
entities provide SPN services while others provide CN and AN services (operator). Then it can
be concluded that the user should have a contract for each of the companies outlined above from
where he uses his services. This is not a good model for beyond 3G systems (including users and
operators) in the case that the user could have at least two or more contracts and then the value
chain is very fragmented.
Case 2
This model for the operator could be assimilated to the channel provider and to the bit pipe
provider, where the operator acts as SPN, CN, and AN and provide services as OSA/PARLAY
to third ASPN companies. This model can be seen as similar to the model 6 because the
OSA/PARLAY services can be offered to other companies using an Application Service
Provider located within the same operator. In this case the ASPN will pay to the operator the use
of its services.
Case 3
This is the implementation where the operator plays all roles for a service. In this model the
operator matches the Service Provider role in a Walled-garden environment. The operator offers
all value chain services. From the point of view of a business approach this model alone is not a
good approach because of the limitations not allowing to third possible access network providers
(i.e. big mall centres, airports, etc.) to use their own access networks and because of the lack of
applications provided by third parties providers.
Case 4
From the point of view of the operator this model is related to a pure big pipe provider role,
where the operator provides only transport services to the user and other companies provide
other services and play other roles. Each of the providers has its own legal entity and the
relationship with the end-user is, generally speaking, different. The problem inherent to this
model for the operator is similar to the problems explained in the case one, where the user could
sign a contract with several providers.
Case 5
For this relationship model, the operator matches with the big pipe provider role and with
channel provider one, but the main difference with case one is that the transport provider does
not provide the access network either, having a more restricted role in the business relationships.
In this business model, the operator can sign agreements with third parties to be provided with
access networks and with applications to his customers. But again the problem raises when the
user signs different contracts with the companies.
Case 6
This case is matched, from the point of view of the operator, to the Application Service Provider
model. The operator plays the role of ASP just to provide other SNP with services. One example
of this roles are the OSA/PARLAY services. This case is an extension of case 2.
The way in which relationships among different actors in the telecom and IT world are managed will be
the key for the success in future scenarios. It seems clear that companies inside the mobile world will be
forced to have agreements among them just to offer to their customers a wide variety of services,
applications, contents, and access technologies.
Page 131
MIND
1.2
6.3 Domain Model Implementation
In this section, a general case for an operator will be analysed from the point of view of the extended
domain model, mixing the best cases exposed in the last section (Section 6.2).
From the Domain Model’s point of view, the cases that fit best with the model are 3 and 5. If both cases
are mixed then the operator will play the role of a Service Provider with contract with third parties.In the
following this case is introduced in the extended domain model (Figure 4-1). Colours and shadows are
completing the domain model and will not only illustrate the functional relationships among the partners
but also the business relationships among them.
The extended business domain model reflects the functional and business relationships that from the
MIND point of view represents the key for success in the future market. The vision is extracted from the
value chain analysis and from the business relationship related to the service provider model explained in
Section 6.2.
Figure 6-5 Extended Business Domain Model
In Figure 6-5 can be seen how different actors in a telecom environment are linked. The entities with
diagonal shadowing are the same operator or companies with a strong business relationship (i.e. global
operators or strong telecom companies). The entities with blue plain shadowing are third parties
companies, who have business relationships with the main operator. This schema is chosen because it fits
with the value chain proposed in D1.1 and with the business relationship model chosen in Section 6.3. In
this domain model, the operator plays the roles of: Service Provider, Bit pipe provider, and application
service provider.
Main advantages of this model are the following:
•
The user has a contract with just one company, avoiding multiple subscriptions and multiple
billings.
•
The user has the freedom when he selects the access network that he wants to use. The main
contractor should negotiate with access network providers, for example railway companies,
airports, etc.
•
The user has access to multiple applications service providers and multiple contents negotiated
by the main contractor.
•
The user can have services like single sign on, integrated security, etc. because of the special
application service provider relationship with the operator.
•
The operator can open his network to third parties developments, and can offer to the
Applications Service providers a wide range of services and access to a huge amount of endusers,
Page 132
MIND
1.2
•
The operator can offer different types of access technologies to their users, i.e. Wireless LAN,
Bluetooth, etc.
•
Operators can sign agreements with companies just to provide a global connection worldwide.
6.4 Billing and Accounting Architecture
6.4.1 Architecture Skeleton
The accounting architecture that will be developed in this section is an abstract model built for the basic
domain model (Figure 6-2). The skeleton architecture manages interactions between network devices
(belonging to LN, AN, or SPN), accounting servers, and billing servers. The network device collects
resource consumption data in the form of accounting metrics. This information is then transferred to an
accounting server (AAAL). Typically this is accomplished via an accounting protocol, although it is also
possible for devices to generate their own session records.
The accounting server (AAAL) then processes the accounting data received from the network device.
This processing may include summarisation of interim accounting information, elimination of duplicate
data, or generation of session records.
The processed accounting data is then submitted to a billing server, which typically handles rating and
invoice generation, but may also carry out auditing cost allocation or capacity planning functions.
Session records may be batched and compressed by the AAAL server prior to submission to the billing
server in order to reduce the volume of accounting data and the bandwidth required to accomplish the
transfer. In order to support the prepaid charging, a near real time transfer of billing records should be
possible.
One of the functions of the AAAL server is to distinguish between inter and intra-domain accounting
events and to route them appropriately. If the users identifier corresponds to the local domain, then the
session record is treated as an intra-domain accounting event. Otherwise, it is treated as an inter-domain
accounting event.
Intra-domain accounting events are typically routed trough the AAAL server to the Local Billing server
(BL), while inter-domain accounting events will be routed to the AAAH. While it is not required that
session record formats used in inter and intra-domain accounting is the same, this is desirable, since it
eliminates translations that would otherwise be required.
The metering device which meters the network resource traffic will typically speak an accounting
protocol to the AAAL, which may then either convert the accounting packets to session records, or
forward the accounting packets to another domain. In either case, the AAAL that sorts the session
records or accounting messages by destination typically achieves domain separation.
Figure 6-6 illustrates the billing and accounting architecture.
Additional security services may be required when data is being transferred between administrative
domains. For example, when information is being collected and analysed within the same administrative
domain, integrity protection and authentication may be used in order to guard against collection of invalid
data. In inter-domain applications confidentiality may be desirable to guard against snooping by third
parties.
Page 133
MIND
1.2
Network
Device
Metering
Accounting
Protocol
Local
Accounting
Server
(AAAL)
Intra-domain
session
Inter-domain session
records or accounting
protocol
Home
Accounting
Server
(AAAH)
Data collection,
pricing,
charging
Inter-domain
session records
records
Local Billing
Server (BL)
Billing
Home Billing
Server (BH)
Billing
Figure 6-6 Billing and Accounting Architecture
6.4.2 Security measures for intra-domain and inter-domain accounting
Inter-domain accounting differs from intra-domain accounting in several important ways. Intra-domain
accounting involves the collection of information on resource consumption within an administrative
domain, for use within that domain. In intra-domain accounting, accounting packets and session records
typically do not cross administrative boundaries. As a result, intra-domain accounting applications
typically experience low packet loss and involve transfer of data between trusted entities.
In contrast, inter-domain accounting involves the collection of information on resource consumption
within an administrative domain, for use within another administrative domain. In inter-domain
accounting, accounting packets and session records will typically cross administrative boundaries. As a
result, inter-domain accounting applications may experience substantial packet loss. In addition, the
entities involved in the transfers cannot be assumed to trust each other.
Since inter-domain accounting applications involve transfers of accounting data between domains,
additional security measures may be desirable. In addition to authentication, replay, and integrity
protection, it may be desirable to deploy security services such as confidentiality and data object integrity.
6.5 Billing requirements
When accounting data is used for billing purposes, the requirements depend on whether the billing
process is usage-sensitive or not:
•
Since by definition, non-usage-sensitive billing does not require usage information, because the
billing process is not based on usage information, in theory all accounting data can be lost
without affecting the billing process. However, wholesale data loss is not acceptable because this
could affect other tasks like auditing.
•
For usage-sensitive billing processes, which depend on usage information, packet loss may mean
paying loss. Therefore, an archival accounting approach is needed to enable the billing process
to conform to financial reporting and legal requirements.
In conclusion, because in usage-sensitive systems, accounting data translates into revenue, the security
and reliability requirements are greater. Due to financial and legal requirements such systems need to be
able to survive an audit, in order to verify the correctness of an invoice submitted by a service provider, or
the conformance to usage policy, service level agreements, or security guidelines. Thus security services
Page 134
MIND
1.2
such as authentication, integrity, and replay protection are frequently required. Confidentiality and data
object integrity may also be desirable. Application-layer acknowledgements are also often required so as
to guard against accounting server failures. In addition, usage-sensitive systems may also require low
processing delay.
6.6 Cost Allocation Model
With the convergence of telephony and data communications, there is increasing tendency in applying for
networks the cost allocation and billback procedures actually in use with telecommunications networks.
Cost allocation models often have profound behavioural and financial impacts. As a result, systems
developed for these purposes are typically as concerned with reliable data collection and security as are
billing applications. Due to financial and legal requirements, archival accounting practices are frequently
required in this application.
6.6.1 Accounting Records
Typically, a single accounting record is produced per session, or in some cases, a set of interim records
that can be summarised in a single record for billing purposes. However, to support deployment of
services such as wireless access or complex billing regimes, a more sophisticated approach is required.
It is necessary to generate several accounting records from a single session when pricing changes during a
session. For instance, the price of a service can be higher during peak hours than off-peak. Peak hours are
not the only factor requiring this approach. For instance, in mobile access networks the user may move
from one network to another while still being connected in the same session. If handover causes a change
in the tariffs, it is necessary to account for resource consumed in the first and second areas. Another
example is where modifications are allowed to an ongoing session. For example, it is possible that a
session could be re-authorised with improved QoS. This would require production of accounting records
at both QoS levels.
For a session continuing from one tariff period to another, it becomes necessary for a device to report the
packets sent during both periods. In most cases, the network device will determine when multiple session
records are needed, as the local device is aware of factors affecting local tariffs, such as QoS changes and
handovers.
In inter-domain accounting or when local domains do not have tariff information the home domain should
control the generation of accounting records. The centralised control of accounting record production can
be realised, for instance, by having AAAH servers requiring re-authorisation at certain times and
requiring the production of accounting records upon each re-authorisation.
In conclusion, in some cases it is necessary to produce multiple accounting records from a single session.
It must be possible to do this without requiring the user to start a new session or to re-authenticate. The
production of multiple records can be controlled either by the AAAL or AAAH servers.
6.7 Accounting & Billing Issues Related to Chapter 4
In this section, an example will be provided taken from Chapter 4, and an event management will be
proposed in an integrated environment. In this example, the two partners are the service provider network
and the transport provider network.
Page 135
MIND
1.2
Figure 6-7 Flow Chart in an Integrated Environment
As can be seen, the applications located in the Application Service Provider Network, use the Service
Provide Network just to negotiate the capabilities at the service domain and the service layer control the
resources reservation and the resources activation. This model fits with case 7 that was discussed above.
In the following picture it can be seen within a red ellipse.
In Figure 6-7 can be seen how the accounting events are introduced following the reservation and
activation events. These events happen within the service provider and within the transport provider. An
integrated accounting and billing architecture need to be given in order to deliver to the user just one bill
and a unified information.
The following architecture, Figure 6-8, customised from the generalised one proposed in Section 6.4.1
provides a first solution about how to manage the accounting issues in those environments.
In this example, it will be supposed that the company that administrates the service provider and the
transport provider are one and the same, or they are federated companies. This business model
corresponds to the service provider model, the service provider and the transport provider are the same
entity. In this case the AAAB has to negotiate the interchange of information between service layer AAA
and transport layer AAA in a trusted environment, both from the same company or federated one.
In the architecture AAAL will be the AAA from the transport layer, this is the domain which has
metering devices, and the AAAH will be the AAA of the services domain. The service domain will
deliver the bill, so all the accounting packets generated in the transport layer will be diverted to the billing
server located at the service layer. This billing service will be completely transparent for the user.
Page 136
MIND
1.2
Network
Device
Accounting
Protocol
Local
Accounting
Server
(AAAL)
Transport Layer
Metering
Service Layer
Inter-domain session
records or accounting
protocol
Home
Accounting
Server
(AAAH)
Data collection,
pricing, charging
Inter-domain
session
records
Home Billing
Server (BH)
Billing
Figure 6-8 Accounting and Billing Architecture.
This model that offers a lot of advantages to users and operators, seems to be the best to work in the given
environment, and represents a possible way in which the telephony operators could plan future business.
Page 137
MIND
1.2
7. Support of User Trials
The MIND Work Package 6 was in charge of the deployment of a trial network infrastructure and the
demonstration of the MIND network and service concepts. This section describes the collaboration
between WP1 and WP6 in order to describe the implemented parts of the BRAIN service concepts that
were implemented and demonstrated by WP6.
One of the most important contributions from the IST Project BRAIN was the BRAIN End Terminal
(BRENTA) [BRA01] from legacy applications to future middleware solutions; Openness, to being
interoperable with other architectures and IETF protocols; and Flexibility, to cope with multi-stream,
multi-session multimedia data, and to enable a dynamical upgrade of the system during runtime. The
problem is that most of the advanced BRENTA functionalities are based on the ESI and it is a very
resource consuming task to be accomplished both in WP1 or WP6. Thus, WP1 has assisted WP6 during
the “Trials pre-study” phase identifying different ways to implement some of the service concepts,
analysing the different WP6 approaches to implement these concepts and offering theoretical solutions to
these problems. WP6 has found it very difficult to demonstrate all of the BRAIN service concepts as most
of the components would have required implementation from the scratch. So in WP1, we have studied
different alternatives to simulate part of these service concepts using and integrating existing
technologies.
As showing all the service concepts would be very costly, WP6 has finally focussed on an extended
version of the ISABEL [ISA01] application supporting auto-adaptation facilities and interfaces towards
QoS and micro-mobility brokers. The use of interfaces from the applications towards these brokers allows
us to overcome the limitation of not having an ESI. Thus, WP6 has selected as the service concepts to
demonstrate end-to-end QoS, multimedia adaptive applications, and user perceived QoS.
The main concepts to be demonstrated during MIND trial have been identified from the original BRAIN
scenarios. According to [MIN63], the demonstrations which have been performed have achieved the
following goals:
•
To integrate a trial environment including systems such as WLAN (e.g. HIPERLAN/2), UTRA
and IPv6 based core network test beds.
•
To validate and evaluate basic functions and protocols specified by BRAIN: vertical (at IP layer)
and horizontal handover mechanisms and QoS related aspects.
•
To show some key mobile applications and service aspects selected from the scenarios
developed in the BRAIN project.
The MIND trial concepts have been defined in Deliverable 6.1 and the trial infrastructure of the various
test-beds was defined in Deliverable 6.2. Tested issues include the ISABEL application and adaptation
mechanisms to varying connectivity conditions, QoS management in the BRAIN access network,
mobility management with the Brain Candidate Mobility Protocol (BCMP) and Hierarchical Mobile IP
(HMIP) protocols and vertical handover between various link technologies.
The next section is describing the MIND implementations as follows:
•
Audio-/ Video encoder switching depending on available bandwidth (ISABEL)
•
Graphical user Interface (GUI) to switch between certain predefined QoS profiles (QoS Broker)
•
Monitoring of available bandwidth of the interfaces – WIC / LMT (QoS Interface)
•
Micro mobility protocol (BCMP)
•
Communication between application and routing protocol (Mobility Interface)
ISABEL CSCW is a configurable Computer Supported Cooperative Work application supporting
synchronous group collaboration over IPv4/6. ISABEL sessions support effectively multipoint
configurations with over 15 interactive points. In each session, all participants can share the relevant
Page 138
MIND
1.2
videos, audios, presentations, whiteboard, application, etc. in easily controlled configurations. For the IST
project MIND, a light version of ISABEL has been used which comprises only audio and video
capabilities. Some interfaces have been developed, in order to enable the application react to changes in
network characteristics and enforce QoS parameters, as well as proactively prevent major disruptions
caused by handoffs.
As previously commented, the BRENTA design within BRAIN is split in two major planes: the usual
data networking plane, and the QoS- and resource-management one. Further one of the key points in
BRENTA is the idea of auto-adaptation when QoS violations occur. To overcome the limitation of not
being able to implement the ESI, WP1 proposed to WP6 to implement a QoS interface between the
application and a new entity called QoS-Broker. The QoS Broker is in charge of abstracting the
application from the specific QoS network mechanisms. This QoS Broker was implemented and included
in the adaptive application ISABEL and is able to change the QoS capabilities of audio and video stream
in real-time in a mobile environment. This means, the server which is hosting the QoS profile is
delivering this profile to each access router.
The QoS interface implemented between the application and the lower layers is able to process
information related to the actual bandwidth of the network in use, extracted from lower layers. Testing the
advantages of such interface involves testing over a wireless network or UMTS, where changes in
bandwidth are common or can be forced. Two implementations were developed in order to provide the
application with the needed layer 2 data, WIC (Wireless Interface Control) for the WLAN interface and
an extension of the LMT (Local Management Tool) for the UMTS interface.
One of the used mobility protocols was the BRAIN Candidate Mobility Protocol, for which a software
implementation was already available at KCL from BRAIN. So the intention was to port the software
functions on a hardware platform by performing the necessary modifications. The main functionalities
developed are the BCMP Handover Management and BCMP Path Updates. This function of the protocol
includes the various types of supported handovers, planned, unplanned, and inter-Anchor.
The Mobility interface was implemented on top of BCMP. BCMP is required to inform about the
characteristics of the network, which are being used, as well as the new network situation prior to or after
a vertical handover has taken place. BMCP is intended for micro-mobility, so it may operate with
traditional macro-mobility protocols such as MIP for such vertical handover.
Specific tests: Concerning the tests, small standalone test-beds of routers have been built and several
micro- and macro mobility protocols have been installed to provide mobility. The first set of tests of the
quality of service has been done on a mobile network without any QoS support. The second set of tests
has been done on the base-line architecture. These have enabled us to quantify the benefits offered by
each further concept. Each of the concepts has been tested in a scenario where a handover occurs. Key
measurements have performed including packet delay, loss, and jitters. These measurements have been
taken on two flows - a real-time QoS enabled flow and a high priority QoS enabled flow - as the load of
background best effort traffic increases.
Interconnection of test-beds: In order to demonstrate all implementations together in an almost realistic
environment, we have connected three of the standalone test-beds via an IPv6 tunnel through the internet;
the first from ASSA at Madrid where the Home Agent was located, the second at Berlin, where the
standalone test-bed from T-Systems Nova and Siemens was located. Here, the vertical handover was
demonstrated at IP-layer between WLAN-UMTS which was triggered by the QoS interface developed in
MIND. The third test-bed was situated at KCL in London, here the extended micro mobility protocol
BCMP was tested. For all the tests, the adaptive application ISABEL lite was used in order to show very
clear the results of the implementation work in MIND. The Video session was running on two mobile
nodes, one in London and the other in Berlin, whilst performing horizontal and vertical handover on both
sites.
Implementing the whole BRAIN terminal architecture has shown to be impossible within the MIND WP6
framework. This was mainly caused due to the need of implementing most of the components from
scratch. WP1 has assisted WP6 in evaluating the difficulty of implementing these layers and finding
alternatives to show using existing technology some BRAIN concepts.
Page 139
MIND
1.2
Finally WP6 uses existing technology to get the same functionality than some of the BRENTA
components. Thus, a videoconferencing application like ISABEL is being extended to support micromobility and QoS interfaces which provides these functionalities allowing us to test BRAIN concepts.
The results look very promising and indicate that running sensitive services, e.g. multimedia services with
the ISABEL application, in a wireless access network with mobile hosts are indeed possible with very
good quality.
Page 140
MIND
1.2
8. Conclusion
The MIND project aims to facilitate the rapid creation of broadband multimedia services and applications
that are fully supported and customised when accessed by future mobile users from a wide range of
wireless access technologies. This MIND project also extends the concepts of IP mobile networks. This
includes new network topologies, like Ad Hoc, self-organising and meshed networks and to enhance the
support for Quality of Service, Ad Hoc networks, and self-organisation at all layers. The MIND project
also includes QoS support in IP-based mobile networks and the investigation of the spectrum
requirements for systems beyond 3G. Further the project researches the use of WLAN and an IP-based
access networks as a complement to UMTS for high bandwidth provision in hot spot areas.
This document has introduced enhancements to the BRENTA architecture with respect to the application
layer QoS session protocols (E2ENP). Different operating systems are being studied with respect to their
interfaces for QoS support, necessary for the application of the systems beyond 3G. A domain model
provides the view of the administrative domains within the BRAIN/MIND architecture. Further
enhancements to this model show the utilisation of the QoS application level protocols, the possibilities
for applying accounting and billing within the BRAIN/MIND architecture and the security issues of the
BRAIN/MIND model. The problem, addressed in this document, is to decide how MIND systems can be
used, what users can or cannot expect from such systems. We present therefore a top-level architecture
for which we describe selected functional entities, but also the effort that has been spent for the trial of the
MIND project. The results are presented in the following. Subsequently, the conclusions on the material
presented in this document are drawn.
The study of the session negotiation features of the BRENTA Session Manager (SM) has led to the
introduction of the End-to-End QoS Negotiation Protocol (E2ENP) (Section 2.1). The requirements of
this protocol are discussed. The E2ENP is a signalling mechanism for effectively and efficiently
performing end-to-end QoS negotiations/re-negotiations and resource management co-ordination, when
dealing with multiparty multimedia services under unstable network conditions. Special features are the
negotiation of common vocabulary and adaptation paths, which describe alternative QoS contracts to be
applied, when QoS violations occur. Furthermore, the E2ENP allows developers and/or users to capture
and enforce time synchronisation and QoS correlation (and even more complex) constraints among
multiple streams, thus allowing adaptation at different levels. This is envisioned to be a key benefit in
terms of QoS for current and future applications. By modularly extending SDPng, and by properly
defining SIP usages, the authors expect that the induction of the E2ENP concept smoothly blends with
legacy solutions, along the path towards the next generation of QoS aware multiparty, multimedia
services. The authors have followed and participated in the discussion in the IETF MMUSIC WG
concerning QoS and capabilities negotiation and the on-going SDPng specification. However, in this
work a specification based on an original use of SDPng is drafted, which partially diverges from the
current status of the discussion in MMUSIC. This decision is taken for the sake of explaining the E2ENP
concepts in more concrete terms, without waiting for the SDPng specification to be finalised. Additional
SDPng inherent problem by the convergence of the E2ENP and the SDPng descriptions is, that SDPng is
too RTP-centric. This makes it difficult to introduce general QoS definitions (within SDPng) from the
application point of view, which are applicable for bigger variety of codecs and not only for the RTP
specific profile. Furthermore, the SDPng stream configuration definition is quite fix, when it comes to
describing vertical handovers and session mobility. The E2ENP specification gives some hints on how
this SDPng problems could be fixed. To this extent, the authors plan in any case to harmonise the E2ENP
specification with the final SDPng version, or even contribute to the preparation thereof, once the E2ENP
concepts have been properly reviewed after a necessary testing phase. The complete specification of the
E2ENP can be found in Annex A.
The study of the possible Enhanced Socket Service (ESI) enhancements with respect to the usage within
different operating systems (Section 2.2) leads to the definition of the service primitives for this interface.
These primitives can be mapped to functional interface calls for QoS support in popular operating
systems like Linux and Windows. ESI is a QoS supporting transport service interface independent of any
platform, QoS architecture, and transport service provider. It is used in BRENTA to enhance well-known
transport primitives by introducing primitives to give applications the ability to use the available QoS
service provider. We explained in detail how the QoS is provided in Linux and Windows OSs and
introduced different interfaces like Traffic Control of Linux (TC), ISI RAPI and GQOS that have been
proposed and implemented in these OSs to request Quantitative and Qualitative QoS. Finally the mapping
Page 141
MIND
1.2
of ESI services primitives to these functions calls are done to demonstrate the viability of a future
implementation.
Extensions to the BRAIN project have been studied and developed within MIND introducing the Ad Hoc
network features Section 2.3. Due to the spontaneous creation of these networks, their decentralised
management and fast variable topology configurations, the provision of QoS in these networks represent a
considerable challenge at each level of the end system architecture. The QoS issues have been described
and their influences on the end system have been identified.
In Chapter 3 the Domain Model has been introduced for the purpose to describe in an abstract way the
MIND access network architecture to leave out technical details irrelevant for the work presented in this
document, while still describing sufficiently and precisely the resulting MIND access network
architecture. It helps in the analysis of threats and payment relations so that suggestions for security,
accounting and billing mechanisms or the E2ENP have been expressed. In general, the DM supports a
methodological approach to reason about the relations between involved roles, and the resulting impacts
of these relations on the technical solutions shall support their interaction when interoperating.
The usage scenarios that have been described in another document [MIT02], [TOM02] guided developing
the DM as presented here to model the administrative region of a controlling object and its ability to cooperate with its surrounding. In a first stage a minimalistic view is taken resulting in the basic domain
model. It concentrates on the user devices, the access network, and the domain that holds a subscription
relation to the user. In a subsequent step this domain model is extended to cope also with the mobile Ad
Hoc networks. Based on this domain model further refinements are presented in other chapters of this
document.
Within Chapter 4, we have presented the E2ENP and showed its relations to the MIND domain model.
We have introduced the concept of Service Domain and Transport Domain and studied interactions
thereof. Refinements to the DM have been introduced with respect to their specific functionality for
negotiation signalling and reservation processing. Four possible scenarios, based on the tightness of
interactions between Transport Domain and Service Domain during call setup have been introduced and
discussed. These scenarios can serve as a basis for developing different heterogeneous scenarios in cases
of different provider architectures and for interoperability between these architectures.
Subsequently, and based on the identification of security goals, reference points and protocol stacks, a
security threat analysis and mechanisms resulting from this analysis were delineated in Chapter 5. Some
considerations around AAA infrastructure are also included. We paid much attention to the initial
description of our methodology, since a careful description of the security problem is the necessary
milestone towards a useful security mechanism.
The chapter concludes that even if they are starting to be considered through various initiatives, security
mechanisms are still lacking at addressing the whole problematic of MIND. These early activities are
promising for future projects since they prove that attention is paid to enhance MIND networks with
respect to security.
One should mention that the security analysis performed in this chapter is not suited for pure Ad Hoc
network, where participants are cut off from any upper infrastructure and, without previous knowledge
and trust among each other, decide to spontaneously create a mesh network. This issue is challenging and
requires more effort and time to be addressed.
Chapter 6 has followed a business case approach based on the value chain given in [ALEJ02]. Starting
from this, a model of the relationship among different players from the service and transport scene was
chosen. Roles of involved parties have been studied in order to identify the mechanism that drives the
associations within the entities identified in the domain model. Derived from the value chain and business
analysis, a choice for one particular model considered as the most realistic scenario for the future was
made. Because the DM developed before was based on the nomadic worker scenario it does not include
all possible cases that could be imagined. However, an abstract skeleton for Accounting and Billing
architecture has been introduced in order to give an idea about how the money flows for service and
resource consumption across different environments could be handled. Although an instance of the
architecture exemplifying the integrated scenario provided in Chapter 4 was finally introduced to light on
the abstract skeleton, this should not be shown as a restriction while other scenarios could take place in
practice.
Page 142
MIND
1.2
Finally in Chapter 7 the Work Package 6 was in charge of the deployment of a trial network infrastructure
and the demonstration of the MIND network and service concepts. The collaboration between WP6 and
WP1 has shown, that the results are looking very promising and indicate that running sensitive services,
e.g. multimedia services with the ISABEL application, in a wireless access network with mobile hosts are
indeed possible with very good quality.
Page 143
MIND
1.2
9. References
[3GPPSIP]
3GPP TS 24.228 V5.1.0, Signalling flows for the IP multimedia call control based on
SIP and SDP, Technical Specification, June 2002.
[802.1x]
IEEE Standards for Local and Metropolitan Area Networks: Port based Network
Access Control, IEEE Std 802.1X-2001, June 2001.
[ABO00]
B. Aboba, J. Arkko, D. Harrington, “Introduction to accounting management”, RFC
2975, October 2000
[ABO99]
Aboba, B. and J. Vollbrecht, “Proxy Chaining and Policy Implementation in Roaming”,
RFC 2607, June 1999
[ACVS02]
Gahng-Seop Ahn, Andrew T. Campbell, Andras Veres and Li-Hsiang Sun, Supporting
Service Differentiation for Real-Time and Best-Effort Traffic in Stateless Wireless Ad
Hoc Networks (SWAN). IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL.
1, NO. 3, JULY-SEPTEMBER 2002
[ADR02]
Adrangi, F., Leung, K., Kulkarni, M., Patel, A., Zhang, Q., Lau., J. „Problem Statement
and Requirements for Mobile IPv4 Traversal Across VPN Gateways“ draft-ietfmobileip-vpn-problem-statement-00.txt (work in progress), March 2002
[ALE99]
Alexey Kuznetsov. RSVP and traffic scheduling distribution based on ISI 4.2a4 for
Linux 2.1.108. http://www.linuxgrill.com/anonymous/fire/alexey/rsvp/
[ALEJ02]
Alejandro Bascuñana, Octavian Tirla, Serge Tessier, Peter Schoo. Accounting
management in heterogeneous mobile access networks: The MIND approach. The
13TH IEEE International symposium on personal, indoor and mobile radio
communications, PIMRC 2002
[ALM98]
Almesberger, W. “Linux Traffic Control – Implementation Overview”. November 30,
1998
[ALM99]
Almesberger, W. “Differentiated Services in Linux”. June 25, 1999
[ASS02]
Assaf, N. et al., Interworking Between IP Security and Performance Enhancing Proxies
for Mobile Networks, IEEE Communication Magazine, May 2002
[ATK95]
Atkinson R., “Security Architecture for the Internet Protocol“, RFC 1825, August 1995
[AUR98]
Aurrecoechea, C., Campbell, A.T. and L. Hauw, "A Survey of QoS Architectures",
ACM/Springer Verlag Multimedia Systems Journal, Special Issue on QoS Architecture,
Vol. 6 No. 3, pg. 138-151, May 1998
[BAH02]
Bahl, P., PAWNs: Satisfying the need for ubiquitous secure connectivity and location
services, IEEE Communication Magazine, February 2002
[BCS94]
R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an
Overview, IETF RFC 1633, June 1994.
[BD12]
BRAIN Project, Concepts for Service adaptation, scalability and QoS handling on
mobility enabled networks, Deliverable D1.2, The BRAIN project IST-1999-10050,
March 2001.
[BD22]
BRAIN Project, BRAIN architecture specifications and models, BRAIN functionality
and protocol specification, Deliverable D2.2, The BRAIN project IST-1999-10050,
March 2001.
[BEL01]
Belding-Royer, E. et al., “Global Connectivity for IPv4 Mobile Ad Hoc Networks”,
draft-royer-manet-globalv4-00.txt (work in progress), November 2001
[BER00]
Bernet, Y. “RFC2996: Format of the RSVP DCLASS Object”. IETF Network Working
Group, November 2000
[BER98]
Bernet, Y. et al. “Winsock Generic QOS Mapping. Version 3.1” Windows Networking
Group. September 1998
[BER99]
Berson, S. “RSVP Software”. March 1999, http://www.isi.edu/div7/rsvp/release.html
Page 144
MIND
1.2
[BH98]
R. Braden and D. Hoffman. “RAPI -- An RSVP Application Programming Interface.
Version 5”. IETF Internet Draft. August 11, 1998
[BOS01]
L. Bos, et al: A Framework for End-to-End User Perceived Quality of Service
Negotiation, IETF Internet-Draft, Work-in-progress,<draft-bos-mmusic-sdpqosframework-00.txt>.
[BOS02]
L. Bos, et al: SDPng extensions for Quality of service negotiation, IETF Internet-Draft,
Work-in-progress,<draft-bos-mmusic-sdpng-qos-00.txt>.
[BRA01]
IST-1999-10050 BRAIN Deliverable 1.2, “Concepts for Service adaptation, scalability
and QoS handling on mobility enabled networks”, 31.03.2001 http://www.ist-brain.org
[BRA94]
Braden, R. et al. “RFC1633: Integrated Services in the Internet Architecture - an
Overview”. IETF Network Working Group, June 1994
[BRAIN1.2]
Andreas Kassler, et al, Concepts for Service adaptation, scalability and QoS handling
on mobility enabled networks, IST-1999-10050 BRAIN, Deliverable D1.2
[BRAIN2.2]
Alberto Lopez, et al, BRAIN architecture specifications and models, BRAIN
functionality and protocol specification , IST-1999-10050 BRAIN, Deliverable D 2.2
[BZ97]
Braden, R. and L. Zhang. “RFC2209: Resource ReSerVation Protocol (RSVP) -Version 1 Message Processing Rules”. IETF Network Working Group, September
1997.
[CHEN99]
Shigang Chen. Routing Support for Providing Guaranteed End-to-End Quality-ofService. PH. D. Thesis. University of Illinois at Urbana-Champaign. USA. 1999.
[CN01]
K. Chen and K. Nahrsted. “An integrated data lookup and replication scheme in mobile
Ad Hoc networks”. Computer Science Department. University of Illinois at UrbanaChampaign.
[CON02]
Congdon, P., Aboba, B. et al., “IEEE 802.1X RADIUS Usage Guidelines”, draftcongdon-radius-8021x-20.txt (work in progress), June 2002
[CRVP01]
Chandran, Kartik et al. A Feedback-Based Scheme for Improving TCP Performance in
Ad Hoc Wireless Networks. IEEE Personal Communications. February 2001.
[DIE99]
Dierks, T., Allen, C., “The TLS Protocol Version 1.0”, RFC 2246, January 1999
[ENG02]
Engelstad, P., “Extensible Authentication Protocol over IP (EAPoIP)”, draft-engelstadpana-eap-over-ip-00.txt (work in progress), January 2002
[FEE99]
L. M. Feeney. A Taxonomy for Routing Protocols in Mobile Ad Hoc Networks. SICS
Technical Report T99/07. Swedish Institute of Computer Science. October, 1999
[GF98]
Gene Gaines and Marco Festa. “A Survey of RSVP/QoS Implementations. Update 2.”
IETF RSVP Working Group. July 1, 1998.
http://www.isi.edu/rsvp/DOCUMENTS/ietf_rsvp-qos_survey_02.txt
[GLA00]
Glass, et al, “Mobile IP AAA Requirements”, RFC 2977, October 2000
[GUE00]
T. Guenkova-Luy et al, Efficient End-to-End QoS Signalling - concepts and features,
IETF Internet-Draft, Work-in-progress, <draft-guenkova-mmusic-e2enp-sdpng-00.txt>
[GW02]
Andrea Goldsmith and Stephen Wicker. Design Challenges for Energy-Constrained Ad
Hoc Wireless Networks. IEEE Wireless Communications. August 2002.
[HAV01]
draft-haverinen-mobileip-gsmsim-02.txt
[HUB02]
Hubert B., et all. “Linux Advanced Routing & Traffic - Control HOWTO” April 4,
2002.
[INSIG]
The INSIGNIA Project of Columbia Univ., http://comet.columbia.edu/insignia/
[ISA01]
The ISABEL application. http://.isabel.dit.upm.es
[IYE02]
Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A., Zhang, Q., Lau, J. „Mobile
IPv4 Traversal Across IPsec-based VPN Gateways“ draft-adrangi-mobileip-vpntraversal-02.txt (work in progress), June 2002.
Page 145
MIND
1.2
[JIC99]
Lusheng Ji, Mary Ishibashi and M. Socott Corson. “An approach to Mobile Ad Hoc
Network Protocol Kernel Design”. IEEE Wireless Communications & Networking
Conference (WCNC). 1999.
[KAZ99]
Manthos Kazantzidis et al. "Experiments on QoS Adaptation for Improving End User
Speech Perception over Multi-hop Wireless Networks". Proceedings of QoS Mini
Conference in conjunction with IEEE ICC'99. Canada, 1999
[KKS01]
A. Kassler, C. Kücherer, A. Schrader, Adaptive Wavelet Video Filtering, in: Proceeding
of the QofIS 2001, Coimbra, Portugal, September 2001.
[KNI02]
T.J. Kniveton et al., “Mobile Router Support with Mobile IP”, draft-kniveton-mobrtr02.txt (work in progress), July 2002
[KT00]
Kapoor, Ashish and Pankaj Thakkar. Multimedia over Ad Hoc Networks. Indian
Institute of Technology. Delhi. 2000.
[KUT01]
D. Kutscher et al., “Requirements for Session Description and Capability Negotiation”,
IETF Internet-Draft, Work-in-progress, <draft-kutscher-mmusic-sdpng-req-01.txt>.
[KUT02]
D. Kutscher et al. “Session Description and Capability Negotiation”, IETF InternetDraft, Work-in-progress, <draft-ietf-mmusic-sdpng-05.txt>.
[LAZC99]
Seoung-Bum Lee, Gahng-Seop Ahn, Xiaowei Zhang and Andrew T.
Campbell"INSIGNIA",draft-ietf-manet-insignia-01.txt,Work in Progress, November
1999.
[LS01]
Liu, Jian and Suresh Singh. ATCP: TCP for Mobile Ad Hoc Networks. IEEE Journal
on Selected Areas in Comunications, Vol. 19, No. 7, July 2001
[MAN]
IETF Mobile Ad Hoc Networks Working Group.
http://www.ietf.org/html.charters/manet-charter.html
[MAR01]
W.Marshall et al., “SIP Extensions for Resource Management”, IETF draft <draft-ietfsip-manyfolks-resource-00>, November 2000.
[MAR02]
W. Marshall et al., “Integration of Resource Management and SIP - SIP Extensions for
Resource Management”, IETF SIP working group, Work-in-progress, <draft-ietf-sipmanyfolks-resource-07.txt>.
[MBJ01]
Maltz, David B. et al. Lessons from a Full-Scale Multihop Wireless Ad Hoc Network
Testbed. IEEE Personal Communications. February 2001.
[MD21]
MIND Project, MIND access network architecture, requirements, supporting multihomed terminals, Deliverable D2.1, The MIND project IST-2000-28584, 2002.
[MD22]
MIND Project, MIND protocols and mechanisms specification, simulation and
validation, Deliverable D2.2, The MIND project IST-2000-28584, 2002.
[MIC00]
“Enabling Quality of Service Windows Sockets-based Mission-Critical Applications”.
Microsoft Corporation. May 2000.
http://www.microsoft.com/windows2000/techinfo/howitworks/communications/traffic
mgmt/enablingqos.asp
[MIC00a]
Windows 2000 Network Architecture, Microsoft Corporation.
http://www.microsoft.com/windows2000/techinfo/reskit/enus/default.asp?url=/WINDOWS2000/techinfo/reskit/en-us/cnet/cnad_arc_sagr
[MIC00b]
Windows 2000 Network Architecture, Microsoft Corporation.
http://www.microsoft.com/windows2000/techinfo/reskit/enus/default.asp?url=/WINDOWS2000/techinfo/reskit/en-us/cnet/cnad_arc_sagr .
[MIC02]
Microsoft Corporation. 2002.
http://msdn.microsoft.com/library/default.asp?url=/library/enus/qos/qos/qos_documentation_structure.asp
[MIC99a]
Microsoft Windows 2000 Server - An Overview of QoS, Microsoft Corporation. 1999
[MIN61]
MIND project, Work Package 6, Deliverable 6.1: “MIND trials concepts”.
http://www.ist-mind.org/
Page 146
MIND
1.2
[MIN63]
MIND project, Work Package 6, Deliverable 6.3: “MIND Stand-alone testbeds reports”.
Http://www.ist-mind.org
[MIND1.1]
Andreas Kassler, et al, Scenarios beyond 3G, flexible service creation and business
models for an IP based broadband wireless solution, IST-2000-28584 MIND,
Deliverable D1.1
[MIS99]
P. Misra. Routing Protocols for Ad Hoc Mobile Wireless Networks. Student Report.
CIS of The Ohio State University. 1999
[MIT02]
E. Mitjana, D. Wisely, Research item: Towards scenarios and business models for the
wireless world Contribution to WWRF#5
[MST01]
Mirhakkak, M; Schult, N.; and Thomson, D. Dynamic Bandwidth
management and adaptative applications for a variable Bandwidth wireless
environmet. IEEE Journal Selected Areas in Communications, Volume:19, Issue:
10, Oct 2001.
J.Rosenberg, H.Schulzrinne: An Offer/Answer Model with SDP, IETF Internet-Draft,
Work-in-progress, <draft-ietf-mmusic-sdp-offer-answer-02.txt>
[OA02]
[OLS02]
David Olshefski et al. “TC API, Beta 1.5 - Work in Progress”. May 16, 2002.
Http://oss.software.ibm.com/developerworks/projects/tcapi
[PER97]
C. Perkins et al., “RTP Payload for Redundant Audio Data”, IETF RFC 2198, Network
Working Group, September 1997.
[PER00]
Perkins, Charles E. (Editor). Ad Hoc Networking. Addison-Wesley. USA. 2001.
[PER02]
Perkins, C., “Mobility Support for Ipv4”, FC 3220, January 2002
[PET02]
Peter Schoo, Requirements on Domain Model, IST-200028584/DoCoMo/WP1/PI/I/013/c1, WP1-DoCoMoS013-1c-PI.doc
[RAD98]
Radhakrishnan, S. “Linux - Advanced Networking Overview Version 1”. Information
and Telecommunications Technology Center. University of Kansas. August 1998
[RFC2205]
IETF RFC 2205, Resource ReSerVation Protocol (RSVP) - Version 1 Functional
Specification, R. Braden et al, Network Working Group, September 1997.
[RFC3261]
IETF RFC 3261, SIP: Session Initiation Protocol, J. Rosenberg et al, Network Working
Group, June 2002.
[RIG97]
Rigney, C., Rubens, A., Simpson, W. and S. Willens, “Remote Authentication Dial In
User Service (RADIUS)”, RFC 2138, April 1997
[RM-ODP1]
ITU-T X.901 | ISO/IEC 10746-1 ODP Reference Model Part 1. Overview,
http://www.dstc.edu.au/Research/Projects/ODP/standards.html
[RM-ODP2]
ITU-T X.902 | ISO/IEC 10746-2 ODP Reference Model Part 2. Foundations, H
Http://www.dstc.edu.au/Research/Projects/ODP/standards.html
[ROB02]
Ròbert Párhonyi, “Status of the provider based architecture (PBA arch)”, January 2002
[ROH02]
Robert Hancock, Towards a MIND Domain Model, IST-200028584/SM/WP2/PI/659/a1, WP2-SM659-1a.doc
[ROJ02]
J. Rojas et al., “Requirements for the QoS negotiation at the Application Layer”, IETF
Internet-Draft, Work-in-progress, <draft-rojas-mmusic-qosreq-00.txt>, June 2002.
[ROS01]
Rosenberg et al. “SIP: Session Initiation Protocol”, IETF RFC 3261, Standards Track,
June 2002.
[ROS02]
J.Rosenberg, H.Schulzrinne, “An Offer/Answer Model with SDP”, IETF Internet-Draft,
Work-in-progress, <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>.
[ROS03]
J. Rosenberg et al., “Models for Multi Party Conferencing in SIP”, IETF SIPPING
working group, Work-in-progress, July 2001
[RT99]
E. Royer, C-K Toh. A Review of Current Routing Protocols for Ad Hoc Mobile
Wireless Networks. IEEE Personal Communications. April 1999
Page 147
MIND
1.2
[SCH01]
H. Schulzrinne et al., “RTP Profile for Audio and Video Conferences with Minimal
Control”, Columbia U., Work-in-progress, <draft-ietf-avt-profile-new-12.txt>.
[SIPRES07]
G. Camarillo et al.: Integration of Resource Management and SIP, IETF SIP working
group, Work-in-progress, <draft-ietf-sip-manyfolks-resource-07.txt>
[SUN01]
Mobile Information Device Profile (MIDP); Http://java.sun.com/products/midp
[TCng]
Traffic Control Next Generation. http://tcng.sourceforge.net/
[TES02]
Tessier, S., “Guidelines for Mobile IP and IPSec VPN Usage“, draft-tessier-mobileipipsec-00.txt (work in progress), June 2002
[TOH01]
C.-K. Toh. Maximun Battery Life Routing to Support Ubiquitos Mobile Computing in
Wireless Ad Hoc Networks. IEEE Communications Magazine. June 2001
[TOM02]
T. Robles, E. Mitjana, P. Ruiz, Usage scenarios and business opportunities for systems
beyond 3G (Paper available at IST MOBILE & WIRELESS SUMMIT2002) IST
Summit 2002 Thessaloniki, Greece, June 2002
[VM00]
Vaddi, G. and Malipatna, P. “An API for Linux QoS support”. Information and
Telecommunications Technology Center. University of Kansas. February 2000.
http://www.ittc.ukans.edu/~pramodh/courses/linux_qos/mainpage.html
[WIN01]
Windows for smart cards,
Http://www.microsoft.com/windowsce/smartcard/start/intro.asp
[XMLSIG]
Donald E. Eastlake et al, XML-Signature Syntax and Processing, W3C
Recommendation 12.02.2002
http://www.ittc.ukans.edu/~pramodh/courses/linux_qos/mainpage.html
[XSLC00]
Hannan XIAO, Winston Seah, Anthony Lo and Kee Chua. “A Flexible QoS Model for
Mobile Ad Hoc Networks” VTC2000-spring, Tokyo, 2000.
Page 148
MIND
1.2
10. Abbreviations
3GPP
3rd Generation Partnership Project
(B)AR
(BRAIN) Access Router
AAA
Authentication, Authorisation and Accounting
AAAB
Authentication, Authorisation and Accounting Broker
AAAH
AAA Home server
AAAL
AAA Local server
ACS
Admission Control Services
AN
Access Network
ANP
Auxiliary Network Provider
AODV
Ad Hoc On-Demand Distance Vector
AP
Adaptation Path
API
Application Programming Interface
AR
Access Router
ASP
Application Service Provider
ASPN
Application Service Provider Network
ATM
Asynchronous Transfer Mode
BCMP
Brain Candidate Mobility Protocol
BQ
Base QoS
BRAIN
Broadband Radio Access for IP Based Network
BRAN
Broadband Radio Access Network
BRENTA
BRain ENd Terminal Architecture
CBQ
Class Based Queue
COPS
Common Open Policy Service Protocol
CNP
Core Network Provider
CP’s
Control Plan
CP
Content Provider
CPU
Central Processing Unit
CR-LDP
Constraint-based Routed Label Distribution Protocol
CSCW
Computer Supported Cooperative Work
CSZ
Clark-Shenker-Zhank
DARPA
Defence Research Projects Agency
Dev
Device
DiffServ
Differentiated Services
DM
Domain Model
DNS
Domain Name Service
dRSVP
Dynamic Resource Reservation Protocol
DSBM
Designated Subnet Bandwidth Manager
DSCP
Differentiated Services Code Point
E2ENP
End to End Negotiation Protocol
Page 149
MIND
1.2
EAPoIP
Extensible Authentication Protocol
EAD
Extensible Authentication Protocol
ECN
Explicit Congestion Notification
ENP
Extended Network Provider
EQ
Enhanced QoS
ESI
Enhanced Socket Interface
ESL
Enhanced Service Layer
ETSI
European Telecommunication Standards Instituts
FA
Foreign Agent
FIFO
First In First Out
FQMM
Flexible Quality of Service Model for MANET
GPC
Generic Packet Classifier
GPRS
General Packet Radio Service
GQoS
Generic Quality of Service
GRED
Generalised Random Early Detection
GUI
Graphical User Interface
HA
Home Agent
HIPERLAN/2
High Performance Radio LAN, version 2
HMIP
Hierarchical Mobile IP
HTTPS
Hyper Text Transfer Protocol over Secure Socket Layer
I
Intruder
IAN
Intermediary Access Network
IEEE
Instituts of Electrical and Electronic Engineers
IETF
Internet Engineering Task Force
IM
Intermediate Components
IMEP
Internet MANET Encapsulation Protocol
INSIGNIA
IN-band SIGNalling support for QOS In mobile Ad Hoc networks
IntServ
Integrated Services
IP
Internet Protocol
ISI
Information Sciences Institute
ISSLOW
Integrated Services over SLOW links
IST
Information Society Technologies
LAN
Local Area Network
LMF
Local Management Functionality entity
LMI
Local Management Interface
LMT
Local Management Tool
LN
Leaf Network
LSP
Layered Service Provider
MAC
Medium Access Control
MANET
Mobile Ad Hoc NETworks
MIND
Mobile IP Network Developments
MIP
Mobile IP
MMUSIC WG
Multiparty Multimedia Session Control Working Group
MN
Mobile Node
Page 150
MIND
1.2
MN-(B)AR
Mobile Node-BRAIN Access Router
MPLS
Multi Protocol Label Switching
MSISDN
Mobile Subscriber ISDN Number
MTU
Maximum Transmission Unit
NP
Network Provider
OS
Operating System
PAA
PANA Authentication Agent
PAN
Personal Area Network
PANA
Protocol for carrying Authentication for Network Access
P-CSCF
Proxy - Call Session Control Function
PDA
Personal Digital Assistant
PEP
Policy Enforcement Point
PEP
Performance Enhancing Proxy
PS
Packet Scheduler
PWA
Personal Wireless Assistant
QoS
Quality of Service
QoSPS
QoS Packet Scheduler
QoSSP
QoS Service Provider
RAPI
Resource ReSerVation Protocol Application Programming Interface
RED
Random Early Detection
RES
REServation mode
RM-ODP
Reference Model of Open Distributed Processing
RNC
Radio Network Controller
RP
Reference Point
RSVP
Resource ReSerVation Protocol
RSVPD
Resource ReSerVation Protocol daemon
RSVP PATH
RSVP commando method for establishing reservation path
RSVP RESV
RSVP commando method for reservation confirmation
RSVP-TE
Resource ReserVation Protocol - Traffic Engineering
RTCP
RTP Control Protocol
RTP
Real-time Transport Protocol
S
Subscriber
SBM
Subnet Bandwidth Manager
S-CSCF
Serving - Call Session Control Function
SDP
Session Description Protocol
SDPng
Session Description Protocol new generation
SI
Sensitivity Information
SIM
Subscriber Identity Module
SIP
Session Initiation Protocol
SIP ACK
SIP session establishment acknowledgement method
SLA
Service Level Agreement
SM
Session Manager
SP
Service Provider
SPI
Service Provider Interface
Page 151
MIND
1.2
SPN
Service Provider Network
SSL
Secure Socket layer
SWAN
Stateless Wireless Ad Hoc Networks
TBF
Token Bucket Flow
TC
Traffic Control
TCP
Transmission Control Protocol
TCP/IP
Transmission Control Protocol / Internet Protocol
TDI
Transport Driver Interface
TEQL
Traffic Equaliser
TI
Traffic Information
TOS
Type of Service
U
User
UDP
User Datagram Protocol
UICC
Universal Integrated Circuit Card
UMTS
Universal Mobile Telecommunications System
UP
User Plan
USIM
Universal Subscriber Identity Module
UTRA
UMTS Terrestrial Radio Access
VASP
Value-Added Service Provider
VPN
Virtual Private Network
WAN
Wide Area Network
WG
Working Group
WIC
Wireless Interface Control
Page 152
MIND
1.2 / 0.1
11. Figures and Tables
11.1 Figures
Figure 1-1 Coverage of a QoS Framework.................................................................................................14
Figure 1-2 Architecture of the BRAIN End Terminal – BRENTA ............................................................16
Figure 2-1 The Packet Flow in the System.................................................................................................26
Figure 2-2 An Elaborate Queuing Discipline with Multiple Classes..........................................................27
Figure 2-3 Matching a Structure of Filters (each filter with a list of elements)..........................................28
Figure 2-4 The Operation of tc...................................................................................................................29
Figure 2-5 Relation of Elements of IntServ and DiffServ Architecture to Traffic Control in Linux .........30
Figure 2-6 General DiffServ Forwarding Path in a Node...........................................................................31
Figure 2-7 Micro-flow Classification in DiffServ Sources.........................................................................31
Figure 2-8 RAPI’s Implementation Model.................................................................................................33
Figure 2-9 Areas of Influence of the Windows 2000 QoS Components ....................................................35
Figure 2-10 Windows Host Protocol Stack ................................................................................................36
Figure 2-11 Detailed Architecture of GQoS...............................................................................................36
Figure 2-12 Enhanced Socket Interface and General BRENTA Architecture............................................44
Figure 2-13 Abstract Model of Confirmed and Unconfirmed Services......................................................45
Figure 2-14 Abstract Model of Notification Service ..................................................................................45
Figure 2-15 a) Fast Restoration of Reservations with INSIGNIA, b) INSIGNIA IP Option Field ............60
Figure 2-16 a) Fixed Internet Protocol Design b) MANET Protocol Design Approach .........................63
Figure 2-17 Components Subject to Extension to Adapt BRENTA to Ad Hoc network for QoS Support 65
Figure 3-1 Basic Domain Model ................................................................................................................72
Figure 3-2 Domain Model with Mobile Ad Hoc Networks........................................................................75
Figure 4-1 MIND Extended Domain Model ..............................................................................................78
Figure 4-2 The Current Internet Model in the View of the Domain Model ...............................................80
Figure 4-3 Responsibilities within a Single Provider Domain ...................................................................82
Figure 4-4 Responsibilities within Multiple Provider Domains .................................................................84
Figure 4-5 Registration and AAA Controls in a Single Service Domain ...................................................85
Page A.153
MIND
1.2 / 0.1
Figure 4-6 Registration and AAA controls in Multiple Service Domain ...................................................87
Figure 4-7 QoS Contract Validation and Negotiation at the Application Plane .........................................88
Figure 4-8 Wrong Validation by the Offerer..............................................................................................88
Figure 4-9 Wrong Validation by the Answerer ..........................................................................................89
Figure 4-10 QoS Reservation at the Transport Plane .................................................................................91
Figure 4-11 General Architecture for Applying the No Coupling Scenario...............................................92
Figure 4-12 No Coupling Scenario - Call Setup and Network Reservation are not Coupled.....................93
Figure 4-13 General Architecture for applying the Loose Coupling Scenario ...........................................94
Figure 4-14 Loose Coupling Scenario - Negotiation and Reservation Model............................................95
Figure 4-15 Call Setup for the Loosely Coupled Scenario .........................................................................96
Figure 4-16 General Architecture for applying the Tight Coupling Scenario ............................................97
Figure 4-17 Call Setup for the Tightly Integrated Scenario .......................................................................98
Figure 4-18 Tight Coupling Scenario - Negotiation and Reservation Model.............................................99
Figure 4-19 General Architecture for Applying the Integrated Scenario .................................................100
Figure 4-20 Call setup for the Integrated Scenario...................................................................................101
Figure 4-21 Integrated Scenario - Negotiation and Reservation Model ...................................................102
Figure 5-1 Different Viewpoints to Understand MIND Networks...........................................................103
Figure 5-2 Matrix of Asset Categories and Roles.....................................................................................106
Figure 5-3 Control Plane and User Plane Protocol Stacks. ......................................................................118
Figure 5-4 Control Plane Protocol Stacks at Various Reference Points ...................................................118
Figure 5-5 AAA Entities in the MIND Domain Model and Reference Point...........................................120
Figure 6-1 Information Flow in the Accounting Process .........................................................................126
Figure 6-2 MIND Basic Domain Model...................................................................................................127
Figure 6-3 MIND Basic Value Chain for the Nomadic Working Scenario..............................................128
Figure 6-4 Business Roles ........................................................................................................................129
Figure 6-5 Extended Business Domain Model.........................................................................................132
Figure 6-6 Billing and Accounting Architecture ......................................................................................134
Figure 6-7 Flow Chart in an Integrated Environment...............................................................................136
Figure 6-8 Accounting and Billing Architecture. .....................................................................................137
Page A.154
MIND
1.2 / 0.1
11.2 Tables
Table 2-1 List of the QoS Components According to its Areas of Major Influence ..................................35
Table 2-2 Mapping of Parameters from the Winsock2 QoS Flowspecs to RSVP Tspecs and Rspecs.........38
Table 2-3 List of Traffic Control Providers Implemented by Microsoft ....................................................40
Table 2-4 Mapping between Service Type and the Configuration Mode of the Packet Scheduler ............41
Table 2-5 Default Mapping Between Service Type Requested and DSCP and 802.1p mark ....................42
Table 2-6 Service Primitives of the Enhanced Socket Interface.................................................................46
Table 2-7 Parameters that Compose the ESI Flowspec..............................................................................49
Table 2-8 Mapping of ESI confirmed service primitives and violation notifications to RAPI Calls .......................49
Table 2-9 Mapping of the ESI primitives and RAPI Calls for the Release of Reservations ......................51
Table 2-10 Mapping of ESI Confirmed Service Primitives and Violation Notifications to GQoS Calls. ..52
Table 2-11 Mapping of AssignQoS Unconfirmed ESI Primitive and GQoS Calls ...............................................54
Table 2-12 Mapping of the ESI Primitives and GQoS Calls for the Release of Reservations ................................55
Table 3-1 Roles in MIND Scenarios ..........................................................................................................69
Table 3-2 Identified Roles of Participants in the Train Scenario................................................................70
Table 3-3 Map of Roles to Domains ..........................................................................................................71
Table 4-1 E2ENP Scenarios Respective the MIND AAA Components.....................................................92
Table 5-1 A Catalogue of Threats ............................................................................................................110
Table 5-2 Summary of Threats.................................................................................................................117
Table 6-1 Partners Business Relationship ................................................................................................130
Page A.155
MIND
1.2 / 0.1
12. Annex
Page A.156
MIND
1.2 / 0.1
ANNEX A – End-To-End Negotiation Protocol Specification
Table of Contents
A.1. ........................................................................................... Scope of this Annex A 5
A.2. ................................................................................................. Definition of Terms 6
A.3. ......................................................................................Use Cases for the E2ENP 10
A.3.1 The communicating parties ....................................................................................................... 10
A.3.1.1
The negotiation parties ............................................................................................. 10
A.3.1.2
Supporting parties..................................................................................................... 10
A.3.2 The connection structures and modes........................................................................................ 11
A.3.3 Some examples of communication scenarios ............................................................................ 12
A.3.3.1
One-to-one communication scenario – A session switch situation........................... 12
A.3.3.2
One-to-many communication – lecture case............................................................. 13
A.3.3.3
Many-to-many communication................................................................................. 13
A.3.3.3.1 A simple case of videoconference ......................................................................... 13
A.3.3.3.2 A complex case of videoconference ...................................................................... 14
A.3.3.3.3 Some additional aspects of the multiparty communication.................................... 15
A.4. ...................................................................................... Requirements for E2ENP 17
A.4.1 Handling of QoS........................................................................................................................ 17
A.4.2 Coping with unstable environment conditions .......................................................................... 17
A.4.3 Multimedia Applications: Time-Synchronization and QoS Correlation issues ......................... 17
A.4.4 Hierarchical QoS Specification ................................................................................................. 18
A.4.5 End-to-End Negotiation Protocol .............................................................................................. 19
A.4.5.1
Planning counteractions ahead: pre-negotiation of alternative QoS contracts.......... 19
A.4.5.1.1 Coping with Handover Scenarios .......................................................................... 20
A.4.5.1.2 Adaptation Path...................................................................................................... 21
Page A.157
MIND
1.2 / 0.1
A.4.5.1.3 QoS Context........................................................................................................... 23
A.4.5.1.4 The (re)negotiation process.................................................................................... 24
A.4.5.2
Planning counteractions ahead: distributed resource management........................... 25
A.4.5.2.1 Interaction between local, remote, and network resource reservation ................... 26
A.4.5.3
Independence from network aspects......................................................................... 28
A.4.5.4
Mapping of the quality settings on codec definitions ............................................... 29
A.4.5.5
Management of different video frame types ............................................................. 30
A.4.5.6
Resource Management Policy and its Negotiation ................................................... 30
A.4.5.7
Third-Party-Assisted Negotiation ............................................................................. 31
A.4.5.8
Consideration of possible failure conditions............................................................. 32
A.4.6 List of Requirements ................................................................................................................. 32
A.5. ................................................................................... Current Trends and Needs 36
A.6. ...................................................................... Proposed Solution for the E2ENP 37
A.6.1 Assumptions .............................................................................................................................. 37
A.6.1.1
One-to-one communication ...................................................................................... 37
A.6.1.2
One-to-many communication ................................................................................... 38
A.6.1.3
Many-to-many communication................................................................................. 38
A.6.2 The E2ENP Phases .................................................................................................................... 38
A.6.2.1
The End-to-End QoS Pre-Negotiation Phase............................................................ 39
A.6.2.2
The Multi-stream QoS Correlation and Time Synchronization Enforcement Phase 40
A.6.2.3
The End-to-End QoS Compact Negotiation Phase ................................................... 40
A.6.2.4
The End-to-End QoS Compact Re-Negotiation Phase ............................................. 41
A.6.2.4.1 Fast Vs. Structured Re-negotiation ........................................................................ 41
A.6.2.4.2 The use of spare contracts...................................................................................... 42
A.6.2.5
Resource management .............................................................................................. 42
A.6.3 The underlying model: hierarchical Finite State Machine......................................................... 42
A.6.4 The negotiation process ............................................................................................................. 43
A.6.5 Incremental Negotiations - Concept of Micro-phases ............................................................... 44
A.6.6 Protocol features to meet the requirements................................................................................ 44
Page A.158
MIND
1.2 / 0.1
A.7. .......................................................... Proposed Implementation of the E2ENP 48
A.7.1 User-Level QoS and Application-Level QoS Specification ...................................................... 48
A.7.2 Transport level QoS Specification............................................................................................. 50
A.7.2.1
The Traffic Information – TI .................................................................................... 50
A.7.2.2
The Sensitivity Information – SI .............................................................................. 51
A.7.3 E2ENP as SDPng extension ...................................................................................................... 51
A.7.3.1
Overview .................................................................................................................. 52
A.7.3.2
The <e2enp:purpose> element.......................................................................... 53
A.7.3.2.1 The <e2enp:session> element ................................................................................ 54
A.7.3.2.2 The <e2enp:use> element ................................................................................ 54
A.7.3.2.3 The <e2enp:description> element.......................................................................... 55
A.7.3.2.4 The <e2enp:caching> element ............................................................................... 56
A.7.3.2.5 The <e2enp:mediation> element............................................................................ 56
A.7.3.3
The <e2enp:alternative_service> element ................................................................ 58
A.7.3.3.1 An example for the usage of the <e2enp:alternative_service> element58
A.7.3.4
Information that users pre-negotiate among themselves on a peer-to-peer basis...... 60
A.7.3.4.1 The <e2enp:qosdef name="capabilities"> element................................................ 61
A.7.3.4.2 The <e2enp:qosdef name="contracts"> element ................................................... 63
A.7.3.5
QoS Context- and stream grouping-related information, pre-negotiated among users
on a peer-to-peer basis ...................................................................................................... 68
A.7.3.5.1 The <cfg> element............................................................................................... 69
A.7.3.5.2 The <e2enp:qoscfg> element................................................................................. 74
A.7.3.6
Enforcement of QoS correlation and time synchronization constraints at higher
levels of abstraction .......................................................................................................... 78
A.7.3.6.1 Session Level ......................................................................................................... 78
A.7.3.6.2 Application Level .................................................................................................. 79
A.7.3.7
Support for the End-to-End QoS Compact Re-Negotiation Phase ........................... 80
A.7.3.7.1 The <e2enp:enforce> element ....................................................................... 80
A.7.3.7.2 The <e2enp:block> element............................................................................ 83
A.7.3.7.3 The <e2enp:unblock> element ....................................................................... 83
Page A.159
MIND
1.2 / 0.1
A.7.3.8
Other E2ENP elements ............................................................................................. 84
A.7.4 Possible sources of failure and the ways of error recovery by the E2ENP phases .................... 84
A.7.4.1
No common profile base........................................................................................... 84
A.7.4.2
Non-expired pre-negotiated data is no longer valid.................................................. 85
A.7.4.3
The called peer does not supports all of the negotiation modes (push/pull/push-pull)86
A.7.4.4
The received message is malformed ......................................................................... 86
A.7.4.5
A third party interferes with the negotiation wishing to start a negotiation.............. 86
A.7.4.6
Components do not understand E2ENP or the version of the E2ENP...................... 87
A.7.4.7
A communication peer lies within a screened sub-network (Proxies, Firewalls) or the
network is not transparent................................................................................................. 87
A.7.5 E2ENP addressing ..................................................................................................................... 87
A.8. ...................................................................................Examples for using E2ENP 89
A.8.1 Videoconference scenarios ........................................................................................................ 89
A.8.1.1
One-to-one communication scenario ........................................................................ 90
A.8.1.1.1 Pre-Negotiation...................................................................................................... 90
A.8.1.1.2 Negotiation and resource reservation..................................................................... 98
A.8.1.1.3 Re-negotiation and resource reservation.............................................................. 111
A.8.1.2
One-to-many communication scenario ................................................................... 116
A.8.1.2.1 Pre-Negotiation.................................................................................................... 116
A.8.1.2.2 Negotiation and resource reservation................................................................... 117
A.8.1.2.3 Re-negotiation...................................................................................................... 119
A.8.2 Third-Party-Assisted Negotiation Scenario ............................................................................. 120
A.8.2.1
Pre-negotiation........................................................................................................ 121
A.8.2.2
Negotiation ............................................................................................................. 121
A.8.2.3
Re-negotiation ........................................................................................................ 122
A.8.3 Many-to-many communication scenario ................................................................................. 122
A.8.4 Some examples on failure cases .............................................................................................. 127
A.8.4.1
One-to-one communication .................................................................................... 127
A.8.4.2
One-to-many communication ................................................................................. 128
A.8.4.3
Third-party-assisted E2ENP ................................................................................... 129
Page A.160
MIND
1.2 / 0.1
A.9. ........................................................................................Security Considerations 132
A.10.
Related Work ............................................................................... 133
A.11.
Conclusions ................................................................................. 140
A.12.
References ................................................................................... 141
Page A.161
MIND
1.2 / 0.1
A.1. Scope of this Annex A
This Annex provides the technical specification of the End-to-End Negotiation protocol (E2ENP)
described in Chapter 2. The E2ENP can be used to negotiate Application level QoS, capabilities and
adaptation paths for multistream multimedia sessions. It is based on extensions to the SDPng and uses SIP
as transport mechanism. The intention is not to define a brand new protocol whatsoever; rather hereby it
is attempted to map a set of requirements (given in Chapter 2) detailing the aforementioned idea onto
existing protocols.
In particular, one should note that the negotiation of capabilities (like e.g. codecs) is hereby regarded as a
separate issue, complementary to the negotiation of user's QoS preferences and profile information.
Intelligent, adaptive applications and/or middleware can thus make effective use of any such information
negotiated end-to-end by the peers, in order to choose the best adaptation strategy in reaction to a given
QoS change/violation [BRAIN]. Furthermore, both the application and the transport level QoS are
considered as two orthogonal issues of the QoS delivery. These two dimensions are important part of the
resource reservation synchronisation and the QoS management at all abstraction levels of the QoS supply.
The concept hereby described has been originally identified in [BRAIN], together with a reference
architecture. In this document the authors elaborate on that proposal, and draw a set of requirements.
Based on such requirements, a reference solution is then proposed, namely the End-to-End Negotiation
Protocol based on SIP/SDPng technology, including detailed examples. The requirements and the
proposed solution are finally compared against the state of the art.
The authors have followed and participated to the discussion in the IETF MMUSIC WG concerning QoS
and capabilities negotiation and the on-going SDPng specification. However, in this work a specification
based on an original use of SDPng is drafted, which partially diverges from the current status of the
discussion in MMUSIC. This decision is taken for the sake of explaining the E2ENP concepts in more
concrete terms, without waiting for the SDPng specification to be finalized. To this extent, the authors
plan in any case to harmonise the E2ENP specification with the final SDPng version, or even contribute
to the preparation thereof, once the E2ENP concepts will have been properly reviewed after a necessary
testing phase.
Page A.162
MIND
1.2 / 0.1
A.2. Definition of Terms
In addition to the terms given in Section 2.1.1 here additional terms relevant for the specification of the
E2ENP in this Annex are defined.
•
Answerer
The Answerer is a participant of a signalling session (e.g. a SIP-session), which generates a response
to a proposed multimedia session description of an Offerer (see Offerer). The response contains a
description of the conditions under which the proposed session description of the Offerer can be
supported. [SDPOA00], [SDPOA02]
•
Association
A group of streams associated with a given peer. As sub-case of streams grouping, an Association
groups all the streams originating from and/or terminating on the given user's terminal device, and
connecting to a given peer within the given session. Therefore the specification of Association shall
include an identifier of the peer (e.g. a URL, a phone number, or a pair of IP-address and port
number).
•
Association or Groups Adaptation Paths
Modelled as an Adaptation Path, a configuration of alternative associations or groups, along with
their QoS Contexts and steam-level QoS Contracts, can be used for allowing applications and/or
middleware to take adaptation strategies in a pre-planned way.
•
Connection Mode
The Connection Mode refers to an actual data stream exchanged by the peers. This information is the
media (audio, video, etc.) directly perceivable by the end-user. The Connection Mode states who are
the sender and who are the receiver parties of the media streams.
•
Data Path
The network path taken by the media data (audio, video, text, etc.).
•
Economy Principle
The Economy principle dictates the order of resource reservation. As network resources are shared
and are thus more expensive as terminal resources, it is better to first reserve resources on all
terminals and then proceed with network resource reservation.
•
End-to-End QoS Pre-Negotiation
A process that end-peers can perform before the actual start of a session, and independently of the
session itself, for exchanging - in a non-obliged manner - information about configurations of QoS
specifications, deduced from their QoS profiles.
These configurations include Adaptation Paths, so that the end-peers can proactively agree on the
way to react to possible QoS changes or QoS Violations in an effective and efficient manner.
The pre-negotiation message-exchange has informational character for the end-peers, and is used not
only for informing each other ahead about the capabilities and performance possibilities applicable to
the given set of peers, but also for reaching agreements on redefining some of those configurations.
In this way, the peers are thus able to establish a common vocabulary, a priori of any specific
business.
Page A.163
MIND
1.2 / 0.1
The results of this process are scoped in time, and can be used multiple times within their validity
interval.
•
End-to-End QoS Compact Negotiation
A process that end-peers can perform either before or at the actual start of a session, in order to agree
on a given QoS level to be enforced for the given session and streams, based on results of a
previously applied End-to-End QoS Pre-Negotiation process, (assumed the validity of those results
still applies at the time this process is run).
This process is considerably faster compared to the case of the End-to-End QoS Full Negotiation,
since only references of pre-negotiated information are actually exchanged among peers.
At completion of the End-to-End QoS Compact Negotiation process, the end-peers have agreed on
the QoS profiles they are going to use for the communication.
•
End-to-End QoS Full Negotiation
A process that end-peers can perform either before or at the actual start of a session, in order to agree
on a given QoS level to enforce for the given session and streams, eventually by redefining some of
the originally proposed configurations of QoS specifications.
At completion of the End-to-End QoS Full Negotiation process, the end-peers have agreed on the
QoS profiles they are going to use for the communication.
•
End-to-End QoS Compact Re-Negotiation
A process that end-peers can trigger upon detection of either a QoS change or a QoS Violation, in
order to agree on a given QoS level to be enforced for the given session, based on results of a
previously applied End-to-End QoS Pre-Negotiation process, (assumed the validity of those results
still applies at the time this process is run).
This process is considerably faster compared to the case of the End-to-End QoS Full Re-Negotiation
one, since only references of pre-negotiated information are actually exchanged among peers.
At completion of the End-to-End QoS Compact Re-Negotiation process, the end-peers have agreed
on new QoS profiles they are going to use for the communication.
•
End-to-End QoS Full Re-Negotiation
A process that end-peers can trigger upon detection of either a QoS change or a QoS Violation, in
order to agree on a given QoS level to be enforced for the given session and streams, eventually by
redefining some of the originally proposed configurations of QoS specifications.
At completion of the End-to-End QoS Full Re-Negotiation process, the end-peers have agreed on
new QoS profiles they are going to use for the communication.
•
Flow
A flow is a set of packets passing an observation point in the network during a certain time interval.
All packets belonging to a particular flow have a set of common properties derived from the data
contained in the packet and from the packet treatment at the observation point [Quit00]. As an
example, all packets for a given flow should have the same 5-tuple (Protocol ID, Source Network
Address, Destination Network Address, Source Port Number, Destination Port Number).
Simple streams (i.e. those without multiplexed layers) and layers get mapped to flows at transport
layer, where they are used for reservation. One flow can carry one layer of a given stream, or a given
simple media stream en-bloc.
Page A.164
MIND
•
1.2 / 0.1
Group of Streams
Based on various criteria, streams can be logically grouped for enforcing some constraints. For
instance:
-
Grouping all audio streams for enforcing translation
-
Grouping all streams opened by a given user on a multi-user terminal, in order to
enforce quotas
A group may also contain only one stream.
Groups are useful for representing bundles of Streams, which QoS aware applications can handle as
a whole when trading off quality to resource availability, among a multiplicity of equivalent bundles
and within a given QoS Context. Each group is associated with a QoS Context.
•
Layer
Streams can be coded into multiple Layers, where each Layer enhances incrementally the level of
detail relative to the given base information (carried by the so-called Base Layer). This means that
adding Layers can progressively increase the level of detail of the base information. Each layer can
be mapped to a given flow.
•
Negotiation Mode
The Negotiation Mode refers to the signalling path and the negotiation information used by the peers
for exchanging information on the management and the control of the data streams. The Negotiation
Mode states who are the Offerer and who are the Answerer parties by the negotiation.
•
Offerer
The Offerer is a participant of a signalling session (e.g. a SIP-session), which generated a multimedia
session description the Offerer wishes to use by opening the multimedia session. This description is
conveyed to the Answerer (see Answerer). [SDPOA00], [SDPOA02].
•
QoS Context
An arrangement of QoS parameters that shall be enforced throughout a given set of streams. A QoS
context is a logical entity modelled as a specialization of the QoS contract concept. QoS contexts can
be recursively defined in a hierarchical scheme.
•
QoS Contract Type
Captures the structure of a class of QoS Contracts, by identifying how individual QoS Contracts
specify the QoS properties over a given set of QoS parameter types (also known as dimensions in
[Frolu98]). Each parameter type consists of a name and a domain of values. QoS specifications can
be simply intended as a set of constraints over said domains, one per parameter type.
•
QoS Specification
General term for identifying set of QoS parameters and constraints specified by a user for a given
service.
•
Session
Page A.165
MIND
1.2 / 0.1
A set of lasting connections between two or more peers (user end-devices or servers), usually
involving the exchange of many packets of “associated information” (the information of a session is
concerned with a certain topic) among the peers.
"A multimedia session is a set of multimedia senders and receivers and the data streams flowing from
senders to receivers. A multimedia conference is an example of a multimedia session." [Handl98].
Here two types of session with respect to their context are being recognized:
o Media Session – The Media Session has the context of transferring user perceivable
data between peers
o Signalling Session – The Signalling Session has the context of negotiation of media
session settings and stays in general invisible for the end-user. SIP and other signalling
protocols can be used to perform a signalling session. The Signalling session is visible
for the application and may become visible for the user only if the application requires
some user intervention or user event generation (e.g. popping up a GUI-window with
requirement to press one or another virtual button.).
Note: Some protocols (e.g. RTP - Real-time Transfer Protocol) can carry both the media data and the
media description thus performing in parallel the media transfer and the signalling.
•
Signalling Path
The network path taken by the signalling messages.
•
(Media) Stream
The continuous unidirectional exchange of information between two peers at application level.
Different types of Streams may exist: audio, video, data, text, or any combination thereof. A given
party may act as a pure stream Source (i.e. it exclusively sends out information), as a pure stream
Sink (i.e. it collects streamed information from the other party)16, or as both stream Source and
stream Sink (typical of a conversational mode)17. One stream can be mapped to one or multiple
flows.
16
A typical example is a Video on Demand service.
17
A typical example is a videoconference service.
Page A.166
MIND
1.2 / 0.1
A.3. Use Cases for the E2ENP
This section describes different possible communication scenarios, which can occur in a multimedia
environment, and which will benefit from the use of an End-to-End QoS negotiation protocol that
negotiates capabilities and application layer QoS parameters for multistream multimedia applications.
The section first introduces key definitions of the parties and the components considered for the
communication, as well as the structures that they build to form the communication architecture.
The described architectures are associated with some specific services. Different communication modes
the participants use for negotiating QoS are considered. For defining the use cases, the following aspects
are taken into account:
•
Who the communicating parties are.
•
Who initiates the connection.
•
How many the communicating parties are.
•
What kind of structure the communicating parties build.
•
What kind of connection mode (unicast/multicast) it is used.
Some examples are finally provided to show the working idea of the scenarios.
A.3.1 The communicating parties
A.3.1.1
The negotiation parties
The end-system communicating parties - Offerers and Answerers - are the active components of any endto-end negotiation. According to the definitions set forth in Section A.2, the Offerers and the Answerers
are peers.
The Offerer is the party, which starts the connection negotiation process.
The Answerers are the parties contacted by the Offerer, which the Offerer wishes to establish a
connection with.
The various parties may take in the actual communication an active role, as a sender (i.e. sending or
sending/receiving streams), or a passive role, as a receiver (i.e. receiving streams).
A.3.1.2
Supporting parties
Another type of communication party is the Intermediate Component.
These components can differ in terms of complexity to various extents and can be employed on different
levels of the network connection.
The intermediate components can be all the devices (proxies, router, etc.) and services within the network
(e.g. SIP Proxy, Naming, Allocation, Presence, etc.).
It is considered that the supporting parties for the building of the negotiation connection between two
end-peers are the out-band intermediate components.
The assumption of the E2ENP is that intermediate components take part in the negotiation process to a
limited extent, rather, they may influence some of the negotiated information before or after the
Page A.167
MIND
1.2 / 0.1
negotiation has taken place. Intermediate components in the service domain participating in the
negotiation process should only indicate, if they support a given QoS level or not. They should not change
the description itself. That is why it is necessary to consider intermediate components with respect to their
functionality and influence on the negotiated information. The problem that arises when intermediate
components change quality descriptions can be explained by the following example. Let us assume that a
mobile node A has to access networks available, UMTS and WLAN. The contract with UMTS would
allow a maximum data-rate of 128 kbps. Let us assume that A negotiates with peer B to setup a session
using MPEG-4, 25 fps, CIF size at 768 kbps and there is no restriction wrt. local resource availability (so
A and B can handle a MPEG-4 stream, at 25 fps, CIF size). If the intermediate component (a SIP proxy
with subscription information) changes the session description to allow only 128 kbps (which would
require a decrease in frame rate to 10 fps and in frame-size to QCIF), the peer B would never know that
peer A would like to setup a session using MPEG-4, 25 fps, CIF size at 768 kbps. Let us assume now, that
after the session has been established, peer A performs a handover to a corporate WLAN. It would take a
full round of negotiation to increase the quality of the already established session from MPEG-4, 10 fps,
QCIF size at 128 kbps to MPEG-4, 25 fps, CIF size at 768 kbps. If, instead, peer A would in his offer
indicate a set of alternate quality levels together with several sets of transport layer QoS parameters,
intermediate components would simply mark the QoS level they support at transport layer (in this
scenario, while connection to UMTS is established, only the 128 kbps would be marked as supported).
After a handover, peer A would only tell peer B to switch to the MPEG-4, 25 fps, CIF size at 768 kbps
because he already knows that both peers support it and that his contract with the WLAN provider does
also allow him to use 768 kbps. It is important to note, that intermediate components would not change
the values (especially not the application level QoS description) as otherwise the peers could never
establish knowledge about the quality levels that the peers could support without considering the network
as limiting factor.
A.3.2
The connection structures and modes
By establishing a connection it is important to state:
1.
The Negotiation Mode describes the sequence of exchanging capability- and QoS contract
information and which party sends first its contract. To this extent the following modes should
be differentiated:
a.
Push mode is used when an Offerer makes an offer to the Answerer about how the
connection settings should be made and declares ahead its capabilities and QoS wishes.
The push mode can be used with one-to-one telephone-like (VoIP) communication.
b.
Pull mode is used when an Offerer calls the Answerer without declaring wishes about
the connection settings. The Offerer retrieves this information from the Answerer and
adapts its wishes upon the received profile. This mode can be used for different services
like “video on demand” or by “virtual lecturing” when the central peer (“VoD-server”
or the lecturer) predefine profiles to be used.
c.
In some cases it may be necessary to use push-pull mode whenever the Offerer not
only makes an offer about the connection settings to the Answerer, but also retrieves
simultaneously the Answerer's settings.
2.
The Connection Mode - The knowledge which peer is the sender and which the receiver serves
to establish, which of the negotiation modes (push/pull) is more reasonable to use by starting a
negotiation
3.
How the connection works? (Especially in cases where there are more then one participant.)
a.
As a multicast to a group of receiver parties
b.
As a unicast to every receiving party
Page A.168
MIND
1.2 / 0.1
4.
What is the number of the communication parties? – Upon this information it can be established
which of the negotiation modes (push/pull) is more reasonable to use and in what sequence the
negotiation sub-processes would take place. The communication parties can form the following
connection structures:
a.
One-to-one – This can be a telephony case between two parties. A typical service
example here is VoIP (see example in Section A.3.3.1).
b.
One-to-many – This is the case of VoD-service or on-line lecturing (see example in
Section A.3.3.2).
c.
Many-to-many – A typical example here is the virtual conferencing (see example in
Section A.3.3.3).
A.3.3 Some examples of communication scenarios
In this section some examples to better recognize the needs of a negotiation protocol are introduced. Since
the very simple peer-to-peer (one-to-one) communication is already thoroughly discussed in the literature
[SDPOA00], [SDPOA02] the following scenarios consider some more complex communication patterns.
The scenarios describe some typical situations that may occur by dynamic communications and by multiparty connections. The influence of the mobility of devices and persons with respect to mobile networks
is shown. Some ideas of possible information dependencies and the way of describing this are introduced.
The examples show some aspects of the multiparty communication in which the usage of intermediate
components as passive communication parties may be involved.
A.3.3.1
One-to-one communication scenario – A session switch situation
This example shows the idea of how the future phone-like communication can be arranged (Figure A.1):
Figure A.1: Call Relocation
Mary receives on her internet-enabled watch a call from her friend Kate. The call carries a message
indicating “who is calling”(Caller’s identification) and “what the call is all about” (i.e. subject
information -, e.g. Kate wants to tell about her new boyfriend).
Mary’s watch cannot show the high-resolution pictures since its monitor is quite small and monochrome,
so it starts automatically to search a device, which can do that. It connects to the home central server and
finds out that Mary's profile indicates she is authorized to use a smart terminal device in her room. The
watch contacts the room device for relocating the session and informs Mary that there is a call waiting
for her at “her room”-terminal device. Therefore, Mary moves to her room to pick up the call.
Page A.169
MIND
1.2 / 0.1
Meanwhile Kate knows that Mary has accepted her call but needs some time for the relocation (this
information is forwarded by an appropriate protocol). She also knows that Mary will be able to accept
the call on a video-enabled terminal device, so that they could exchange the pictures.
Once in her room Mary can access her smart terminal device to speak with her friend.
M.: ”Hi, Kate! Well, you have a new boyfriend”
K.: ”Hi, I have also some great pictures of him” ….
Kate can finally send to Mary digital pictures and even short video clips of her preferred rock band.
This scenario relates to the case of a Personal Area Network (PAN), whereby third-party-assisted
negotiation of capabilities and QoS needs to be carried out on an end-to-end basis. This means that Mary's
terminal shall be able to negotiate on behalf of the fresh discovered smart device (proxying mechanism).
Alternatively, the negotiation process could be carried out directly by Mary's room smart terminal device
with Kate's one: in such a case, the relocation mechanism would completely hand over the new device the
complete connection establishment process (redirect mechanism).
As a sub-case of this scenario, is of course also possible that no relocation is required at all, in which case
the negotiation process could be carried out directly by Mary's terminal device with Kate's one. Such a
sub-case corresponds the very simple one-to-one communication as described in [SDPOA00],
[SDPOA02]. This case is shown on Figure A.8 together with the negotiation phases of the signalling
protocol.
A.3.3.2
One-to-many communication – lecture case
The following is a virtual lecturing scenario showing the one-to-many communication (Figure A.2):
Prof. T. Martin is in Rome attending a conference, while at that very same time he should have his usual
lecturing schedule at the university of Berlin. He has arranged with his students that he would be giving
the lecture on line, by taking advantage of a free slot in the conference schedule, and has thus announced
that the session will start at 14:00 o’clock.
To this extent, Prof. T. Martin has configured his hotel-room computer to support several different
sending profiles corresponding to the devices of his students. At 13:00 o’clock his PDA informs him that
the first students have started a negotiation for opening a connection session with his computer in his
hotel-room. Prof. T. Martin goes to his room and at 13:55 o’clock he makes a round the table check of
the participants before finally starting the lecturing session.
The lecturing connection carries identification information as being of academic importance and that is
why it is not charged for, or the charges are accounted on a university account.
Page A.170
MIND
1.2 / 0.1
Figure A.2: Virtual lecturing
This example describes the case of one-to-many communication. Such kind of communication is
equivalent also to the case of a “video on demand”-service, with the major difference that in the example
described above the transmission is live rather than pre-recorded as in the VoD case. Therefore, each
receiver in the present example will be able to receive only the same information at (nominally) the same
time.
A.3.3.3
Many-to-many communication
A.3.3.3.1
A simple case of videoconference
This example can be treated as a very simple form of a conference (Figure A.3):
Figure A.3: A simple conference example
Caroline and Martha are employees of a fashion design corporation in Los Angeles. They are working on
a joined project concerning a new collection with their French colleague Miranda. Every week the ladies
make a videoconference on the current state of the development of the collection. Caroline and Martha
send their designs to Miranda for check and approval. Since Miranda is travelling quite a lot and has not
enough time for writing nice reports for her boss, she has authorized her secretary to arrange her models
review in order to prepare a presentation for the boss. When the conference finally starts takes place
Miranda, Caroline and Martha can start exchanging audio and video content, as well as still-images and
text messages concerning the models. The secretary is listening on line writing minutes of the conference
as well as Miranda remarks.
This scenario addresses the case of information originating from different sources. This is the case of a
group of related information streams, whereby the users may require correlation among exchanged
streams (e.g. at the secretary endpoint).
Page A.171
MIND
A.3.3.3.2
1.2 / 0.1
A complex case of videoconference
The second example of communication groups is the following (Figure A.4):
Susanne Jones is making a public opened PhD pre-exam and she has invited her dad to passively
participate to her online examination session, by giving him a session connection key for joining the
examination session as a listener. She is making an on-line presentation, which is multicasted to her
supervisors and to a group of listeners. The initial arrangements of the session are made between
Susanne’s terminal and the supervisors’ terminals, since the supervisors exchange on-line notes about the
presentation, in order to be able to guide Suzanne for her real exam and to point out the positive and the
negative sides of this presentation. The remarks are written directly over the presentation pages or on a
common white board. The notes are conjoint with the running presentation and the initial arrangements
define this correspondence (correlation).
As soon as the initial arrangements are met the exam starts.
The listeners can join at a later moment since they do not interfere with the running exam as active
participants. Any of the listeners joining the session can get information on the current rating of the
presentation. Susanne’s dad terminal joins the session signing to get the presentation itself and the
ratings, which her PhD supervisors give.
The terminal makes the corresponding arrangements with the Susanne’s terminal and the terminals of the
supervisors, according to preset profiles corresponding to the wishes of Suzanne's dad, so that he joins
the presentation multicast and gets the ratings as unicasts.
For this scenario to properly operate it is necessary to have a notion of how to group the single streams
and who the interested parties for a running stream are.
In such scenarios it is important to define groups of participants and groups of streams in a session. It is
possible also that hierarchical grouping structures for communication are formed.
This scenario also shows that sometimes not only real-time traffic but also non-real-time traffic should be
treated as high priority traffic: for example, the stream of subtitles carrying live-translation of the exam
for a foreign participant, is to be considered as pseudo-real-time, insofar as if it did not pace with the
content - or did not get delivered at all - it would be of no use. In this case, the non-real-time traffic (subtitles) is associated to a given degree with the real-time one (live video).
This scenario can also apply to network games and online conferences with several working groups.
Considering the complexity of such a scenario it may or may not be necessary to make certain
prearrangements and planning of the multiparty connection.
Page A.172
MIND
1.2 / 0.1
Figure A.4: A conference example
A.3.3.3.3
Some additional aspects of the multiparty communication
The example (Figure A.5) of this section shows some aspects of the multiparty communication
considering also the usage of some services that support the discovery of the communication parties and
services and the start of the negotiation.
Figure A.5: Intermediate services
Dr. R. Harris is travelling from Frankfurt to Paris and has to take join a videoconference with his French
colleagues concerning the performance of a brain operation of a patient in Paris. His colleagues are
sending him on-line current monitoring information of the patient. They make also a discussion about the
performance of the operation in order to be able to start as soon as Dr. R. Harris arrives at the hospital
in Paris.
As Dr. R. Harris enters the train and wirelessly plugs his terminal into the train LAN. The train server is
now informed that Dr. R. Harris is present within the train LAN.
Albert Frank - one of Dr. R. Harris' assistants - gets on the train in Strasbourg. By entering the train he
also wirelessly plugs his terminal on the train LAN and thus discovers that his boss is already in the train,
in some other wagon (the train is completely booked, and therefore Albert had no chance to reserve a
seat close to Dr. R. Harris).
Page A.173
MIND
1.2 / 0.1
F. Albert issues a call to join the running conference, too. The terminals of Dr. R. Harris and A. Frank
build an ”ad hoc”-network and use the terminal of Dr. R. Harris as a connection to the “outside world”
re-transmitting the conference streams to the terminal of A. Frank.
This scenario is an example of virtual presence by using the train server as a discovery service. But it is
also possible to have some other intermediate services like Naming, Allocation, etc. services, or devices
like Proxies or Registrars. In this case the intermediate components only support the building of the
connection between the end-peers without actively participating in the negotiations that the end-peers
perform.
Page A.174
MIND
1.2 / 0.1
A.4. Requirements for E2ENP
This section first discusses the issues concerning how to handle QoS in multimedia applications dealing
with multiple type and number of streams concurrently. The key aspects of this proposal, the prenegotiation of application-level QoS and the co-ordination of distributed resource management according to the so-called “Economy Principle” - are then presented in detail.
The requirements identified in this section are collected in Section A.4.6, in a requirement list containing
also information about dependencies among the identified requirements.
"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119." [RFC2119]
A.4.1 Handling of QoS
This section identifies a set of general requirements concerning the handling of QoS in multiparty,
multimedia services, eventually dealing with multiple types and number of streams concurrently and the
handling process itself.
Requirement 1. The “handling of QoS” SHALL be achieved through the negotiation and enforcement of
QoS-contracts, which contain configuration and constraints information.
Requirement 2. The QoS-contract SHALL capture configuration information concerning network resources,
as well as the resources and capabilities of the involved QoS-aware end-systems.
For instance, some codecs can be differently preset to produce different perceivable QoS the user can
directly perceive: the sheer definition of codecs is thus not sufficient for determining the amount of
network resource to reserve.
Requirement 3. The QoS-contract SHALL capture user’s QoS expectations, as well as network provider
policies, in order to enable a comprehensive QoS adaptation process.
This means for example to control that the QoS-levels fit into the predefined policies, or to control the
amount of resources by up-/downgrading QoS and detection of QoS- changes/violations.
A.4.2 Coping with unstable environment conditions
The Internet has proven to be a successful architecture for delivering a broad set of electronic services
(including - among many others - telephony, electronic messaging, and audio/video services), not only to
sedentary but also to nomadic users.
Micro/macro IP mobility and wireless IP technologies in fact pave the way to the full integration of the
Internet with the 2nd and 3rd generation of mobile phone systems. In order to achieve this goal, next
generation IP networks and applications will have to address the increasingly important challenges of
wireless access, mobility management, the provision of Quality of Service (QoS), and multimedia
services.
A paramount problem that mobile users will most likely face within this context is how to cope with
limited amount resources at the end-systems and in the network, and unstable environment conditions.
Requirement 4. Developers and users of mobile and/or fixed terminals MAY deal with unstable environment
conditions, especially when enforcing QoS.
Page A.175
MIND
1.2 / 0.1
A.4.3 Multimedia Applications: Time-Synchronization and QoS Correlation
issues
Multi-media sessions may contain several streams of basic types (i.e. audio, video, and data). As an
example, one session for a given user's perspective could consist of two video streams and four audio
streams generated from different peers (or even from one peer in a surround scenario). The given user
would then wish to specify the QoS s/he wants to get for each single stream, and in addition any
parameter that might determine the inter-stream behaviour. Typically, videoconference applications deal
with voice and video streams, which must be synchronized at the end-terminal. Non-synchronized
videoconferences may not be satisfactory in some scenarios.
Additionally, some level of correlation may be required between some or all of the aforementioned
streams, on a time and/or QoS basis. This correlation constitutes a generalization of the time
synchronization problem. For instance, electronic game applications and/or media-rich interactive
applications might feature bundles of audio and video streams, which are associated with objects to be
presented to the user. For example, a moving and/or rotating cube can be displayed on a monitor with its
faces textured with images from video streams; and different audio streams, each associated with a cube
face, can be played whenever the corresponding face is oriented to a certain direction.
To this extent, applications shall be able to guarantee not only that related streams are played within given
temporal relationships (sheer time-synchronization), but also that the combined QoS of a given bundle of
streams lies within some given constraints (QoS correlation). For instance, just continuing the game
application example, it might make no sense to have some facets of the cube being displayed in black and
white videos, and the others as high quality colour videos at higher frame rates, even though the images
were completely synchronized from a sheer temporal perspective. It would rather make more sense to
display all facets displaying black and white movies at the highest available frame rate, thus avoiding the
pointless consumption of resources to get colour images to the detriment of the frame rate at which said
images would be displayed.
Of course the decision of what level of correlation should be enforced at QoS level among a set of
streams is left to the developers' and even to the user's discretion.
Therefore multi-stream applications may require in addition to the specification of timing relationships
among groups of streams, also a specification of QoS correlation. Actually this distinction is not
completely identifying two orthogonal aspects, since time-synchronization can be regarded as a special
case of QoS correlation. In the case that a given media stream is composed of a number of distinct
transport layer flows (e.g. as generated by multi-layered codecs), these issues are even more obvious.
Requirement 5. Developers and users of multimedia applications dealing with multiple streams MAY
augment their QoS specifications by including QoS correlation and time-synchronization
aspects.
A.4.4 Hierarchical QoS Specification
One should note that the bundling of streams is not only application- or user- dependent, but it can also be
structured according to a hierarchical scheme.
For instance, in videoconference applications it can make sense to distinguish (and therefore treat
differently) different groups of streams, so as to identify multiple concurrent instances of the
videoconference and, within each videoconference session, the various associations of the given user with
multiple peers (each association being a bundle of correlated streams).
This proposal thus models multi-stream Time Synchronization and QoS Correlation constraints as highlevel QoS Contracts, associated with the list of the affected streams. Furthermore, it allows recursively
bundling such high-level QoS Contracts among themselves, thus leading to a hierarchical QoS
Specification scheme, i.e. equivalent to a tree. Each such leaf represents a stream and has a QoS Contract
associated. Parent node are associated with a high-level QoS Contract, specifying for their children QoS
levels in terms of multi-stream, Time Synchronization and QoS Correlation constraints.
Page A.176
MIND
1.2 / 0.1
Furthermore, users may prioritise and grant different amounts of resources to various (multimedia)
applications. This is especially important for handheld devices with limited resources, like memory,
battery-power [BRAIN]. This approach leads to even higher-level Time Synchronization and QoS
Correlation constraints, which are to be enforced locally by the terminal device. The corresponding highlevel QoS Contracts extend the tree data model at the root. Such additional high-level QoS Contracts are
however not meant to be negotiated with peers. Rather, each peer can enforce high-level QoS Contracts
independently. Alternatively, high-level QoS Contracts can be enforced globally throughout a given
closed set of peers, once a coordinator has been selected.
Requirement 6.
Developers and users of multimedia applications dealing with multiple streams MAY
advantageously structure their QoS specifications in a hierarchical manner.
A.4.5 End-to-End Negotiation Protocol
A possible way to cope with QoS violations and QoS changes is to enable the mobile users' applications
to efficiently and timely react to those events, by planning counteractions ahead.
In this manner, whenever QoS violations occur, agreements on how to most effectively adapt to the
mutated conditions can be timely reached among the peers.
The overall solution combining these two planning mechanisms is hereby-called End-to-End Negotiation
Protocol (E2ENP).
Requirement 7.
A.4.5.1
The E2ENP SHALL include mechanisms and means for planning ahead proper
counteractions, coping with otherwise unpredictable events resulting from QoS violations
(e.g. handovers) or QoS changes (e.g. user changing profile information when roaming).
Planning counteractions ahead: pre-negotiation of alternative QoS contracts
The hierarchical QoS specification can be enhanced for helping peers deciding how they should react
during overload situations, in order to be compliant with the users' preferences.
Requirement 8.
The E2ENP SHALL include mechanisms and means for quickly and efficiently performing
QoS negotiations and QoS re-negotiations.
The idea is to plan ahead a set of QoS contracts, so as to cope with current and future resource
availability.
Requirement 9.
The E2ENP SHALL include mechanisms and means for specifying and negotiating
multiple alternative QoS levels.
Requirement 10. Each QoS level SHALL be described by a specific QoS contract.
Since the user expresses his/her QoS preferences through the means offered by an application, it is up to a
QoS aware application to express the user perceivable QoS in an appropriate manner. With this respect it
is considered that the User Level QoS specification is an application-specific issue, which depends on
user interface aspects. With respect to the building and negotiation of QoS contracts between end-peers the Application Level QoS - a system internal representation (e.g. XML description) derived from UserLevel QoS specification is used. In these terms, QoS contracts are intended in the rest of this document as
Application Level QoS contracts.
Requirement 11. Bid QoS contracts SHALL describe Application Level QoS from receiver’s perspective.
QoS information derives from the knowledge of available resources. Since any given user-perceivable
quality may be achieved by using different resources (e.g. codecs), it is necessary to gather information
about resources in order to be able to create QoS contracts. Furthermore, information about resources is
also used for carrying out resource reservations.
Page A.177
MIND
1.2 / 0.1
Requirement 12. The E2ENP MUST derive QoS information (peer, local, network supportable QoS) from
knowledge about available resources.
The elements of a negotiated set of QoS contracts can be efficiently referenced during QoS renegotiations, by associating each element with a unique identifier.
Requirement 13. The E2ENP SHALL include mechanisms and means for uniquely referencing each QoS
contract during QoS negotiations and QoS re-negotiations, in order to keep signalling
minimal.
Special features of the end-applications and services may require different signalling sequences for
exchanging capability and QoS contract information among peers. The following modes are envisioned:
o
Push mode: used when an Offerer sends a bid to the Answerer. The Answerer selects a subset thereof
and sends back a counter-proposal. This mode (equivalent to the “offer-answer” model in
[SDPOA00], [SDPOA02]) can be used for instance in one-to-one VoIP services.
o
Pull mode: used when an Offerer calls the Answerer without sending any bid. The Offerer retrieves a
bid from the Answerer and selects a subset thereof. This mode (equivalent to the use of the
DESCRIBE method in [SRL98]) can be used for instance in “video on demand” services. Common
scenario is also described in the Offer/Answer enhancement with provisional acknowledgements
[100rel06].
o
Push-pull mode is used whenever the Offerer not only sends a bid to the Answerer, but also retrieves
simultaneously the Answerer's information. This information might be a counter-proposal (e.g. the
“offer/counter-proposal/answer” model in [Bos02] – this model considers a three way SIP message
exchange, e.g. INVITE, 200OK, ACK with different SDPng bodies) and/or an additional bid
concerning the streams that the Answerer wishes to receive from the Offerer. Common scenario is
also described in the Offer/Answer enhancement with provisional acknowledgements [100rel06].
Requirement 14. The E2ENP SHALL include mechanisms and means for enforcing various negotiation
modes (push, pull, push-pull), since services may require different negotiation schemes.
Since the changing conditions (e.g. handovers) may occur in an unpredictable manner, in order to achieve
efficiency it is necessary that any of the peers discovering a change might immediately trigger an
adaptation process and inform the other peers, irrespectively of its role in the communication process.
This means that peers should apply symmetrically the E2ENP signalling protocol.
Requirement 15. The E2ENP SHALL be symmetrical with respect to QoS re-negotiation signalling.
If E2ENP is expressed by the means of SIP [SIPBIS09], [RFC3261] , the SIP INVITE method used in a
SIP dialog can be utilized for such symmetrical signalling.
Failure cases of the protocol also constitute an important example of symmetry.
Requirement 16. The E2ENP SHOULD be able to offer the same possibility to signal both internal and
external failure conditions, exceptions, and errors occurring by any of the peers involved in
the E2ENP signalling.
Requirement 17. The E2ENP SHOULD offer mechanisms for error recovery.
A.4.5.1.1
Coping with Handover Scenarios
Mobile users must be prepared to experience dramatic QoS violations whenever handovers occur, but also
to advantageously leverage any potential improvement, whenever during such handovers the users access
networks with more resources and/or less restrictions.
Page A.178
MIND
1.2 / 0.1
Given that users typically have business relationships with a specific network provider (e.g. a subscription
with an ISP or a prepaid card with a Telecom operator), three possible types of handover may occur:
•
Horizontal Handover: the handover takes place within a given administrative domain of a network
provider, and within the same type of access network.
•
Vertical Handover:
the handover takes place between two different types of access networks
and/or across the administrative boundary between two network providers.
When dealing with handovers, users must be prepared to face changes in network resource availability,
depending not only on the type of access network accessed, but also on the type of business relationships
the users may have with the various network operators accessed. In some extreme cases, the users might
try in fact to access the network owned by a network operator, with which the users have no business
relationship at all, or which can restrict users' access or limit the amount of resources allotted to said
users. Pricing aspects also play a key role.
All this means that the users must be prepared to experience dramatic QoS Violations whenever
handovers occur, but also to advantageously leverage any potential improvement, whenever during such
handovers the users access networks with more resources and/or less restrictions.
The E2ENP assumes that the validation process for the contracts is preventively enforced by other means,
therefore the E2ENP uses already validated contracts.
Requirement 18. The E2ENP SHALL assume that users will have preventively validated their preferred set
of QoS contracts against what their preferred access network provider can actually support.
A.4.5.1.2
Adaptation Path
Following the rationale set forth in the previous paragraph, peers could manage to agree not only on a
given QoS Contract, but also on alternative ones, which can be advantageously used whenever the
network and/or terminal resource availability changes over time.
In such a way, each peer would exactly know which alternative QoS Contract (and under what
conditions) shall be enforced, in order to cope with a critical QoS Change or with any QoS Violation with
respect to the currently enabled QoS Contract. In addition, transport layer QoS parameters could be part
of a single application layer QoS Contract.
The concept of Adaptation Path prescribes the specification of alternative QoS Contracts in addition to
the nominal one, along with a set of rules indicating which alternative QoS contract should be enforced
upon which circumstance.
The alternative QoS Contracts typically describe lower levels of QoS compared to the one specified by
the nominal QoS Contract. More specifically, adaptation policies will identify well-defined adaptations of
the nominal QoS Contract to a set of alternate degraded QoS specification (i.e. lower levels of QoS), in
correspondence to well-defined sets of QoS changes and/or violations, as monitored by the overall
middleware [Loyal].
In this writing, it is preferred to follow the terminology indicated in [BRAIN], whereby Adaptation Path
(AP) is used instead of Degradation Path, in order to highlight that adaptation could actually be used also
to upgrade a given quality, should more resources become available at a later time (e.g. in the case of
hand-over).
The concept of Adaptation Path enriches the notion of alternative QoS contracts, by identifying a default
QoS contract and a set of rules indicating which alternative QoS contract should be enforced upon which
circumstance.
Page A.179
MIND
1.2 / 0.1
The alternative QoS contracts typically describe lower QoS levels compared to the default one.
Adaptation policies identify well-defined adaptation steps from the currently enforced QoS level to one of
the alternate QoS levels, in correspondence to well-defined QoS violations.
Requirement 19. The E2ENP SHALL allow users negotiating Adaptation Paths (AP).
Requirement 20. Each element of an AP SHALL be a prioritised, uniquely-identifiable QoS contract.
Requirement 21. Each AP SHALL define a default QoS contract that SHALL be enforced when starting
streaming.
Requirement 22. An AP COULD include the specification of rules defining the circumstances under which
different QoS contract, out of the given AP, shall be enforced.
A.4.5.1.2.1
Stream Adaptation Path
Requirement 23. The E2ENP SHALL include mechanisms and means for specifying APs at stream level.
A.4.5.1.2.2
Group Adaptation Path
By applying the AP at any level of the aforementioned hierarchical QoS specification, the adaptation
process can be further improved by including both time-synchronization and QoS correlation
specifications.
In this model, each alternative time-synchronization and QoS correlation specification is associated with a
specific QoS Contract.
The use of alternative QoS Contracts structured in a hierarchical format so as to capture various
correlation aspects, allows in fact peers agreeing a priori (at pre-negotiation time) on a common,
structured "QoS vocabulary", without requiring the intervention of the network provider during the prenegotiation process.
To this extent, peers may advantageously use profile information pre-negotiated with network providers
at subscription time18, whenever participating to the End-to-End pre-negotiation process.
The enforcing of QoS correlation and/or time synchronization constraints implies the logical grouping of
streams, based on various criteria. For instance:
•
grouping all audio streams for enforcing synchronized translation;
•
grouping all streams opened by a given user on a multi-user terminal, in order to enforce quotas.
A group of stream could eventually contain just one stream: in such a case, the basic stream QoS Contract
would simply be augmented with higher-level (e.g. application specific) QoS constraints.
Groups are mainly useful for representing bundles of streams, which QoS aware applications can handle
as a whole when trading off quality to resource availability, among a multiplicity of equivalent bundles in
a given set of environmental conditions.
To this extent, peers can proactively agree not only on the AP of each individual stream, but also on
alternative compositions of the given whole bundle, along with specific QoS correlation and/or time
synchronization constraints for each of the resulting configurations.
18
In case of roaming, network providers could make provisions (via Service Level Agreements) that the users' profile
information still holds (entirely or partly) when the users visit a new network domain.
Page A.180
MIND
1.2 / 0.1
Consequently, the applications (and/or middleware) will be able to adapt to given QoS changes and/or
violations, based on predefined rules, dictating which streams should be adapted19, and which new QoS
correlation and/or time synchronization constraints should be enforced in the new situation.
Requirement 24. The E2ENP SHALL allow end-peers negotiating Group APs, expressed in terms of
alternative configurations of a given group of streams.
A.4.5.1.2.3
NULL-Stream
It is also reasonable to define a “NULL”-stream20 QoS Contract for taking into account, during the
adaptation process, the possibility that in critical situations some of the streams of a group might be no
longer supported. In this way, one can prevent the complete re-negotiation of the QoS settings of the
whole group of streams, thus leaving those streams within the group running, for which the boundary
conditions are still valid. The definition of the boundary conditions is application specific and depends on
the context of the session. In general the application of the NULL-stream within a group should not affect
the context of the session. This means that the still running streams of a stream-group within a session
should be meaningful enough for the end-parties to keep the stream-group upright and not cancel it and
re-negotiate it anew. Thus the application of the “NULL”-stream is just a tool for avoidance of full renegotiations and serves the meaningful adaptation of a stream-group.
For example, let us consider the case of a group of stream containing an audio and a video stream. The
corresponding Group AP may then include an option, whereby the video-stream is associated with a
“NULL”-stream QoS Contract, in order to account for the occurrences of marginal conditions like
dropping of the bandwidth under a given threshold. In such a case the video stream would be stopped but
the audio would continue being streamed.
Requirement 25. The E2ENP SHOULD allow end-peers negotiating NULL-stream QoS contracts in Group
APs.
Requirement 26. The application of the “NULL”-stream MUST NOT affect the context of the running
session.
The consideration for starting and stopping streams explicitly over the negotiation protocol is also
mentioned in [Even00]. Thus it is possible to control the media encoding/decoding utility at a peer even
without having in-band RTCP signalling.
A.4.5.1.2.4
Association Adaptation Path
The association is a particular type of stream grouping, associating all of the streams between the given
user and a given peer. This form of grouping is the most intuitive one and probably the most used one.
Requirement 27. The E2ENP SHALL allow end-peers negotiating APs for Associations of streams.
19
Including actions like stopping or restarting a stream.
20
The idea behind the NULL-stream is to allow end-peers implicitly triggering a "PAUSE-STREAM" command due
to a detected QoS violation/change. By saving information about the negotiated QoS levels before the pause
occurred, one could use such information for correctly and quickly renegotiating QoS at a later time, should the QoS
violation/change condition do not exist any more.
For instance, let us assume that Mary is watching video clips on her mobile device, and that she has indicated in her
user profile that, should the connection quality decrease, she would prefer to pause the video streaming so as to save
resources for listening to the musical score. During a handover, a QoS violation occurs and the device consequently
signals the VoD-server to pause the video stream. The VoD-server pauses the video streaming and saves prenegotiated QoS information, in order to be able to resume the stream as soon as the handover is completed, according
to the pre-negotiated QoS (including time synchronization issues with respect to the audio stream). Mary's device
also has to remember the existence of the video stream in order not to full-renegotiate QoS for it anew, when
resuming it.
Page A.181
MIND
A.4.5.1.3
1.2 / 0.1
QoS Context
A QoS Context identifies an arrangement of QoS parameters that shall be enforced throughout a given
group of streams. A QoS Context is a logical entity modelled as a specialization of the QoS Contract
concept.
This means that whatever the QoS specification of individual streams might be, the QoS Context forces a
set of QoS constraints to be applied to all of the streams belonging to the given group.
QoS Contexts can also capture those QoS parameters derived from the QoS Contracts of the individual
streams belonging to the groups associated with the given QoS Contexts [ISOX641]. Examples are the
total amount of memory or the average bandwidth used by the given set of streams.
To sum up, QoS Contexts deal stream grouping, QoS correlation, and time-synchronization issues,
focusing more precisely on the specification of:
•
common QoS level for a group of streams;
•
derived QoS parameters;
•
QoS parameters indirectly affecting QoS specifications of bundled streams.
Of course, the decision about what level of QoS correlation and/or time synchronization should be
enforced among a group of streams, may be taken not only by the developer but also by the user.
Requirement 28. The E2ENP SHALL allow end-peers negotiating QoS Contexts.
A.4.5.1.3.1
QoS Context Hierarchy
According to the aforementioned hierarchical model, tree-based hierarchies of QoS contexts may be
defined: QoS Contexts can be recursively defined out of other lower-level ones.
The leaves of any such tree data structure would then be represented by the Stream APs: associated with
the individual streams belonging to a given group of streams.
Any internal node of any such tree data structure would instead be represented by a QoS Context, which
indirectly affects the QoS specification of all the streams, belonging to the sub-tree rooting from that
internal node. This means that QoS Contexts can thus address specific QoS parameters that indirectly
affect all of the underlying streams (e.g. system-level reliability issues).
Furthermore, at higher level in any such tree data structure, QoS Contexts can be recursively defined out
of other lower-level ones.
In this way, any such tree data structure may be used for aggregating not only individual streams, but also
a multiplicity of already defined group of streams, based on QoS correlation, and time-synchronization
criteria.
Requirement 29. The E2ENP SHALL allow end-peers negotiating QoS Contexts associated with
aggregations of streams at various levels of abstraction.
Each QoS Context can be assigned a priority, which QoS aware applications can use to determine the
relative importance of sibling QoS Contexts.
Requirement 30. The E2ENP SHALL allow end-peers negotiating relative priorities among those QoS
Contexts, which happen to be siblings in a given tree-based hierarchy of QoS Contexts.
Page A.182
MIND
A.4.5.1.3.2
1.2 / 0.1
Specification of Group Adaptation Paths in terms of QoS Contexts
By leveraging the concepts of QoS Context and hierarchical QoS specification, peers may enforce the
aforementioned concept of Group AP (GAP).
Of course the enforcing of QoS correlation and time-synchronization constraints is possible only when
the peers involved in the negotiation process agree a priori on a given business (which application to use,
whom to contact, which other sessions are to be opened etc.).
Practically, in most of the cases users enforce these constraints locally and do not disclose this
information to their peers. The only case where these constraints may be enforced throughout a given set
of peers is only when third party control units, like a Conference Control Unit, are provided (typically in
the case of online conference scenarios).
Requirement 31. The E2ENP SHALL allow end-peers negotiating uniquely-identifiable QoS Contexts, each
associated with a specific element of a Group AP (GAP).
Requirement 32. Each GAP SHALL define a default QoS Context that SHALL be enforced when starting
streaming.
A.4.5.1.4
The (re)negotiation process
The (re)negotiation process typically involves an Offerer and one or multiple Answerers, and can be
performed in one shot or on an iterative basis [Loyal].
The Offerer offers a bid to the Answerers, who examine it and return a counter-offer to the Offerer. The
latter collects the counter-offers and determines the one (if any), which satisfies the requirements of all
the involved parties. Once such optimal counter-offer has been sorted out, the Offerer sends it as a new
bid to each Answerer.
In an iterative scheme, the process could at this point restart, should one of the Answerer still do not
accept the new bid. The iterative approach must however be constrained with an upper limit of iteration,
and it is in any case quite complex and not efficient.
The re-negotiation by the multiparty connection scenarios should be made by possibility on a single basis
like by the one-to-one re-negotiation, since the occurrence of changes by a single communication party
might not influence the connections of the other parties involved, i.e. if a peer discovers problems by its
connection this does not mean that other peers also have problems with their connections. Therefore by
multiparty connections it is better to re-negotiate the independent streams on a single basis, in order
minimize the necessary signalling. The streams of a group (dependant streams) may also be re-negotiated
on a single basis in case this re-negotiation does not influence the contexts of the group.
Requirement 33. The E2ENP SHALL enforce basic, non-iterative pre-negotiation, negotiation, and renegotiation schemes.
Requirement 34. The E2ENP MAY allow more complex negotiation schemes only by employing third-party
control units (e.g. Conference Control Units).
Requirement 35. In general the E2ENP SHOULD be used for performing negotiations and re-negotiations
only between the end-peers involved in a session. Should this requirement be not
applicable due to service specific reasons, the previous requirement would take
precedence..
Requirement 36. By complex negotiation scenarios (e.g. conference like) the end-peers engaged in a E2ENP
process MAY publish the already pre-negotiated QoS Contracts and user profile
information in some registration services thus allowing a short negotiation process for the
later joining parties.
Page A.183
MIND
1.2 / 0.1
Requirement 37. It SHOULD be possible to re-negotiate a single stream of a group, if this is not
contradictory with the context of the group, in order to minimize the signalling for the renegotiation.
Requirement 38. In case a stream is being correlated with other streams, it SHOULD be the responsibility of
the correlating party to perform re-negotiation with all affected parties.
A.4.5.1.4.1
The role of senders/receivers
The negotiation rationale hereby proposed is to allow the receivers specifying what QoS level they want
to receive.
The difference between this proposal and current trends (e.g. SDP/SDPng) consists in that the latter do
not focus primarily on QoS negotiation, rather on capability negotiation. For instance, both SDP and
SDPng allow a sender giving information to the receiver(s) about format and transport information that
the sender intends to use for sending.
Trying to match E2ENP with this well-known approach, the aforementioned rationale can be relaxed as
follows: both senders and receivers can specify what QoS level they want to send/receive at stream level,
but only receivers are allowed to specify what APs/high-level QoS level they want to enforce for
receiving. This because is more likely that the receivers do care of QoS correlation and time
synchronization constraints among multiple received streams, whereas this is not generally of relevance
for senders.
Requirement 39. The E2ENP SHALL allow both senders, receivers, and sender/receivers specifying what
QoS level they want to send/receive at stream level.
Requirement 40. The E2ENP SHALL allow only receivers and sender/receivers specifying what Group APs
/ QoS Contexts they want to enforce.
However, the extension of this proposal to allow senders specifying QoS correlation and time
synchronization constraints among the streams they send is left for further study.
A.4.5.2
Planning counteractions ahead: distributed resource management
Peers can follow a specific procedure for effectively enforcing the negotiated QoS specification, not only
at connection establishment time, but also whenever QoS violations take place.
To this extent, [BRAIN] suggests to coordinate the actual reservation of local resources as well as
network resources, in order to avoid waiting for network resource reservation until the resources at all the
end-points are reserved. More precisely, the term economy principle is used in the present document to
describe the order of reservation described in [Nahr95].
Therefore it is proposed to integrate the aforementioned QoS pre-negotiation, QoS negotiation, and QoS
re-negotiation processes, with the economy principle: the idea is to reserve the more expensive resources
at the last step. As network resources are shared among several clients and typically one has to pay for
them, it is better to first reserve resources on all end-systems and then resource network resources as the
last step.
The sequence of actions looks then like the following:
1.
First, local resources are reserved.
2.
Then negotiation with the peer entity leads to a configuration that can be mapped to resource
requirements at the peer, which are then reserved.
3.
Finally, reservation of network resources is done in the last step, because network resources are
expensive and shared among multiple users.
Page A.184
MIND
1.2 / 0.1
Requirement 41. The E2ENP SHALL provide mechanisms and means for enforcing the co-ordination of
distributed resource management.
Requirement 42. According to the "Economy Principle", remote resources at the peer SHALL be reserved
only after local resources have been successfully reserved.
Requirement 43. According to the "Economy Principle", network resources SHALL be reserved only after
local resources have been successfully reserved at all peers.
Sometimes it is not necessary to perform network resource reservation, because of the fact that the access
network can be over-provisioned (e.g. LAN). The negotiation process on the other hand needs at least
fake execution of the reservation coordination to synchronize the reservation process at the negotiating
parties in cases that not all the negotiating peers belong to an over-provisioned network. The resource
reservation coordination process for the E2ENP can thus utilize the mechanisms described in
[SIPRES07] in order to be able to cope with the network reservation coordination in cases of overprovisioned networks. By the negotiation process a QoS precondition can be set for informing the
negotiation partner/-s of the necessity of performing network reservations.
Although E2ENP claims explicitly that the Economy Principle is required always, the application of
[SIPRES07] is a desired concept allowing both end-to-end and segmented reservations. In the latter case,
enforcing the Economy Principle might be not always desirable. In fact there might be in situations where
reservation can be as well done locally on beforehand with no cost/major impact on session
establishment. For instance, some users might be attached to an intranet or wireless LAN, where network
resource reservation might be free and starving other users might be flexibly handled. Therefore the
original E2ENP shall accommodate this case and rely on the applicability of the Economy Principle to
allow the aforementioned case.
One should though note that the E2ENP does not imply that a direct interface to reservation entities is
available: it is up to the applications/QoS Broker to access those entities. If the latter wishes to do a "prereservation" of network resources, it might well do that, but the E2ENP signalling would still give the
right timing to the applications/QoS Broker, informing it when the reservations at all sides have been
accomplished, according to the Economy Principle: which signal the users the exact moment they have
finally reached the level of QoS desired (even though best effort communications might well have been
started on beforehand, should the applications/QoS Broker specify so).
A.4.5.2.1
Interaction between local, remote, and network resource reservation
In order to properly coordinate local, peer, and network resource reservation according to the
aforementioned "Economy Principle" between more than two peers, special care must be taken while
specifying the corresponding protocol, in order to provide consistency (which also leads to better resource
utilization) and avoid deadlocks. Consistency will lead also to better resource utilization.
The rest of this section presents two example scenarios, motivating these requirements.
A description of the general prerequisites applying to the example scenarios is given first. These
prerequisites illustrate the problem domain. However, they do not limit the applicability of the scenario.
A.4.5.2.1.1
Prerequisites of the Example Scenarios
Assume there are three equivalent terminal devices, each equipped with the same video codec. The
processing power of the terminal devices is such that each of them is able to manage 25 frames per
second for either sending or receiving.
That is, the CPU power allows to either process 25 fps in the transmitting mode (capture, compress,
packetise and send) or in the receiving mode (receive the packets, re-assemble, decompress and render).
However, the terminal has not enough resources to simultaneously send and receive 25 fps.
Page A.185
MIND
1.2 / 0.1
Also, it is assumed, that the resource consumption scales linearly with the number of frames per second.
As an example, the terminal devices may simultaneously send a stream at 10 fps and receive a different
stream at 15 fps so as to process 25 fps in total.
A.4.5.2.1.2
Scenario 1: consistency
This scenario shows why it is necessary to provide consistency.
Let us assume that at time t0 peer A initiates a negotiation with peer B for managing peer A sending a
stream to peer B at a frame rate of 15 fps (see Figure A.6).
Figure A.6: Consistency example
Peer A successfully reserves local resources for processing 15 fps, sends the negotiation request to peer
B, which already has a ongoing similar session that consumes 20 fps with a different peer. Thus peer B
reserves resources for 5 fps for processing the incoming stream because that is all it can support. This
information is propagated back to peer A, which releases previously reserved resources for sustaining the
negotiated frame rate value of 5 fps, and then starts reserving network resources equivalent to 5 fps at
time t1.
Assume that the network is not the limiting factor and finally peer A, peer B, and the network are able to
sustain 5 fps for the given session.
If at any point between t0 and t1 peer C wants to create a session with peer A, peer A would only be able
to allow peer C to admit 10 fps (=25 fps - 15 fps) locally.
However, if peer A receives the request from peer C at any point in time after t1, peer A would be able to
admit at least 20 fps (=25 fps - 5 fps) for the new session with peer C, because the resource requirements
for the first session have dropped due to constraints imposed on peer B, which are outside the control of
peer C.
From this scenario the requirement is derived, that any such protocol that manages local, remote, and
network resources between two peers shall not serve requests for resource requirements from another
peer, until the protocol has succeeded in establishing an on-going communication session. This
requirement is denoted as consistency.
Page A.186
MIND
1.2 / 0.1
Requirement 44. The E2ENP SHALL enforce a consistent application of the “Economy Principle” among
multiple peers.
A.4.5.2.1.3
Scenario 2: avoidance of deadlocks
This scenario shows why it is necessary to avoid deadlocks, i.e. why the ENEP must assure that there is
no Hold-and-Wait condition or that such a condition may be present only for a limited amount of time.
Let us assume that peer A wants to send a video stream at 25 fps to peer B and vice versa (see Figure
A.7).
Figure A.7: Deadlock example
At time t0, peer A reserves the local resources, and sends the negotiation request to peer B, which receives
this request at time t2. Meanwhile, peer B reserves the resources at time t1 for sending a stream to peer A.
Peer A receives this request at time t3.
Therefore, peer A waits for the response from peer B starting from time t0, whereas peer B waits for the
response from peer A starting from time t1. As a consequence, when both peers try to reserve their local
resources at time t2 (peer B) and time t3 (peer A) for serving the remote requests, they will both fail.
From this scenario, the requirement follows, that any protocol that manages local, remote and network
resources between two peers shall avoid deadlock situations or at least allow them to occur only for a
limited amount of time, after which the protocol shall be able to recover in any case.
Requirement 45. The E2ENP MUST ensure that at any given time the application of the “Economy
Principle” does not lead to deadlock conditions.
Requirement 46. The E2ENP MUST ensure that recovery mechanisms are put in place in order to cope with
possible colliding applications of the “Economy Principle”.
Page A.187
MIND
A.4.5.3
1.2 / 0.1
Independence from network aspects
The end-peers are in general connected over one or a multiplicity of interconnected networks, including
different intermediate components.
Requirement 47. The E2ENP SHOULD operate based on an abstraction of the underlying network.
Intermediate components offer services that not only may influence the information that peers eventually
negotiate via e2enp at later time, but also may enforce the results of the e2enp process. For example,
some specialized SIP proxies would be able to reserve network resources on behalf of the peers.
Intermediate components SHOULD be informed about the decision taken by the end-peers. The way of
informing intermediate components MAY be by supporting them with some standard-profile information
before the start of E2ENP and/or by publishing the agreed QoS contracts on some registration service.
Requirement 48. The E2ENP SHOULD be able to be used in combination with (but independently from)
intermediate components, which may result effective in preparing and/or guaranteeing the
QoS Contracts agreed by the end-peers.
Some of the QoS related issues like security, authentication, provider policies, etc. represent the boundary
conditions for creating QoS contracts. Such kind of profile information can restrict the amount of the
resources (peer, network) usable but do not influence the performance of those resources as long as the
multimedia process runs within the setup boundaries. These conditions only influence the end-to-end
negotiated information in terms of validation of the QoS contracts and SHOULD be applied before a
negotiation for setting up a session. Additionally an end-peer can apply locally and within its
administrative domain policies which are of no interest to the corresponding negotiating parties, since
their local policies might be different. The end-peers are interested only in the result of applying the
policies and overloading the E2ENP with policy information might result in ineffective performance.
Requirement 49. The exchange of information (e.g. profiles, security, authentication, provider policies, etc.)
not directly affecting the E2ENP-process, rather influencing the information that is going
to be negotiated, SHOULD be carried out ahead of the E2ENP start.
In general the flows carrying E2ENP messaging (the path-path) and the flows carrying the actual streams
(the data-path) could be routed differently, depending not only on network-related issues, but also on
application/service specific reasons.
Requirement 50. The E2ENP paths-paths and the corresponding data-paths between any two given endpeers SHOULD be in general considered different.
Every time a path-path and/or data-path is built, there may be some intermediate components (router,
proxies, etc.) located along the path, whose usage is application-specific, and which might "understand"
partly the protocols used by the end-peers. These entities would be in a position to "interfere" also with
the E2ENP, thus disrupting the very "End-to-End" nature of the E2ENP.
In order to avoid this threat, hereby a requirement is set forcing the out-band intermediate components to
be always passive with respect to E2ENP:
Requirement 51. With respect to the E2ENP, the out-band intermediate components SHOULD operate
based only on information provided - directly or indirectly - by the peers, in order to carry
out application specific tasks.
For instance, this can be achieved by putting an explicit remark in E2ENP messages indicating that the
out-band intermediate components should never alter E2ENP content during the E2ENP process. Or by
publishing some of the E2ENP-related information ahead in a registry service, which the out-band
intermediate components may then question for planning actions.
Page A.188
MIND
1.2 / 0.1
Exception cases when the involvement of the out-band intermediate components is inevitable are covered
by the following requirement:
Requirement 52. The out-band intermediate components SHOULD be allowed to interfere with the E2ENP
only by explicitly signalling the end-peers and only in cases of end-peer misbehaviour,
when the end-peer(s) disregard system policies, and/or by system failure conditions.
A.4.5.4
Mapping of the quality settings on codec definitions
When user-defined audio quality should be applied to a codec according to the standard payload-type
definitions of the codecs [RTP-Prof], one specific quality can be mapped to just one payload type
expressing this quality.
There is a unique one-to-one mapping between an audio quality and a capability (payload type).
On the other hand a single video codec can produce multiple qualities. The quality of a compressed video
denotes the quality as passed to the encoder (codec). It represents the overall visual quality of the single
frames. This means that by applying some user-defined quality to a video it is possible to define this
quality as a compression percentage for the performance of the video codec. Additionally it is possible for
some codecs (e.g. WaveVideo, format name – “WAVI”)[WAVI] to specify the overall visual quality of
the chrominance planes of the single frames thus separating between the overall luminance quality and
the colour quality. The colour quality can also be expressed as a percentage. The different video codecs
have different number of compression levels. When a user specifies visually perceivable quality this
quality should be uniquely mapped to a number expressing the compression level of the video codec. If
the user specifies his perceivable quality as a number or a range of numbers, this setting should have
enough resolution to map uniquely to a certain compression level of a codec. Thus two requirements
concerning the video quality setting are defined:
Requirement 53. The numbering range for the user perceivable quality specification (overall visual quality
and colour quality, if the colour quality is applicable) SHOULD be uniquely
understandable for the application and the E2ENP in order to be able to uniquely map
video quality to a given codec.
Requirement 54. The numbering range for the user perceivable quality specification (overall visual quality
and colour quality, if the colour quality is applicable) SHOULD have enough resolution to
uniquely map to the compression levels of a given codec.
A.4.5.5
Management of different video frame types
Since some codecs support different format for the video frames (e.g. H.261 and H.263 from ITU-T) it is
necessary to be able to support also such different frame format descriptions by the parameterisation of
the codecs. Such a requirement is defined and respective parameters are described for SDP in [Even00].
These parameters – MB(Macro Block), GOB (Group of Blocks) and arbitrary slices – can also be adopted
for E2ENP, following the requirement of [Even00].
These different frame type descriptions are useful for controlling the respective codec supporting such
parameters without using the underlying in-band signalling (e.g. RTCP) and by running a re-negotiation
process.
A.4.5.6
Resource Management Policy and its Negotiation
Peers should pre-negotiate a resource management policy, in order to avoid instabilities at runtime
whenever handling QoS re-negotiations.
Otherwise, should two or multiple peers, joined to - say - a videoconference, detect a usage of resources
violating some proprietary resource management policy, the decisions that each peer would independently
take could influence the remaining ones, in way that might contradict the decisions that those other peers
Page A.189
MIND
1.2 / 0.1
may concurrently try to take. This would lead to "oscillations" in the resource configuration space, which
would impact on overall system performance and user-perceived QoS.
For the same reason, only the sender should take the decision to trigger the re-negotiation process. Should
however a receiver detect concurrently a degradation of resource availability, it could trigger a renegotiation, and any eventual collision with other peers (including the sender) would be resolved by
grating the right to continue this process to the sender only.
To this extent, a set of well-defined resource management policies is proposed, which the peers can agree
upon by negotiation. In this way, the peers can still independently manage at runtime their own resources,
but in a coordinated manner.
Such policies should cover any logical combination of, at least, the following aspects:
•
Optimisation of memory resources
•
Optimisation of processing power
•
Optimisation of network resource performance
•
Optimisation of power consumption
More specifically, the optimisation of power consumption is correlated with all other types of resource
management: e.g. a memory swap drains power.
Should a policy not specify explicitly the optimisation of power consumption, the policy would thus
optimise the usage of other types of resource, without caring much of power (this may make sense e.g. for
a desktop PC permanently plugged to the mains, which would have plenty of power to optimise any type
of resources except power).
Should a policy do specify explicitly the optimisation of power consumption, this policy criterion would
affect all other optimisation criteria.
The use of policies allows applications and/or middleware to flexibly take their own adaptation decisions,
as long as the conditions imposed by the negotiated QoS contracts and resource management policies are
met. Therefore the definition and negotiation of priorities for QoS Contracts are not required.
Furthermore, also the definition and negotiation of priorities for codecs/capabilities are not required21.
Requirement 55. The E2ENP SHALL provide mechanisms and means for specifying and pre-negotiating
resource management policies.
Requirement 56. Resource management policies SHALL include, but be not limited to, any logical
combination of the following criteria: Optimisation of memory resources, Optimisation of
processing power, Optimisation of network resource performance, Optimisation of power
consumption.
Requirement 57. The applications and/or middleware using the E2ENP may autonomously prioritise list of
codecs/capabilities, based on pre-negotiated resource management policies and current
resource availability
21
The reason for such a prioritisation would be in fact due to the fact that capabilities like codecs consume resources
differently from one another. Besides, codecs that typically perform less well than other, may still more
conveniently optimise resource usage when used in specific configurations.
Page A.190
MIND
A.4.5.7
1.2 / 0.1
Third-Party-Assisted Negotiation
The dynamical communication environment requires not only adaptability by the establishment and the
management of the data connections, but also by performing of negotiations. The scenario in Section
A.3.3.1 shows such special negotiation case of the one-to-one communication, where the peer-to-peer
data connection is being “third-party-assisted” negotiated. Such kind of negotiation may take advantage
of using registration, allocation, presence, etc. services, thus allowing the more thorough satisfaction of
the users requirements for QoS and the possibility to discover and utilize multiple devices within the
vicinity of a user.
By starting a negotiation the called device may discover that it has no possibility to handle the call. Since
the device cannot adapt, the call may simply not happen. One kind of adaptation which can be applied in
this case without changing the capabilities of the peer would be to delegate the call to another peer
according to a profile definition of the user. Such functionality is named here Mediator and describes the
ability of a peer to negotiate on behalf of some other peer and according to a preset user profile definition
This type of negotiation is called “third-party-assisted negotiation”.
The Mediator participates actively in the negotiation between two peers but does not take part into the
data connection. If the Mediator should actively participate into a data connection it would additionally
need bridging functionality which in some cases may result in necessary transcoding, thus running into
multiparty connection and requiring the negotiation there of. Additional problem of a Mediator situated
on the data path may be that the device causes a bottle-neck, thus negatively influencing the possibility to
support the required QoS. Considering these problems, such kind of adaptability may only be preformed,
if all the peers (Mediator inclusive) exchange information on their capability profiles (e.g. device bitrate
throughput), this means that multiparty connection should be negotiated which is being later on discussed.
Thus for the case of negotiation mediation it is considered that the Mediator does not participate in the
data media streaming.
The facilitating functionality of a Mediator is triggered when an Offerer issues a call which the device
cannot handle. In this case the Mediator searches for an appropriate Answerer and delegates the call by
also informing the user and asking for acceptance of the delegation state. Consequently the Offerer and
the Answerer receive profile information about each other over the Mediator, thus speeding up the
discovery and the direct negotiation process between them at later time.
The Mediator functionality needs to be able to use additional services supporting its facilitating
capability. The specific application of such services is out of scope of this document, here it is recognized
only the advantage of their usage and how the E2ENP is being there from affected.
The Mediator should take care not to refer session information unknown to the one (Offerer) or the other
(future Answerer) party for which the mediation is being done. The Mediator should be allowed to
perform the facilitation by eventually restructuring the session information coming from a peer, when
information about multiple sessions is only referred by calling the Mediator, but not explicitly contained
in the message. Thus the Mediator cares for completing the information set about a session by the parties
for which the facilitation is being done. The Mediator does not change the contents of the session
information but eventually adds complete description parts to its calls, in order to round up the
information set by the other negotiation parties.
Requirement 58. By third-party-assisted negotiation a pure Mediator SHOULD only facilitate the
delegation of a connection without actively taking part in it.
Requirement 59. A Mediator MAY leverage services like directory, allocation, presence etc. for preparing
E2ENP message content only.
Requirement 60. The Mediator SHOULD be able to generate new E2ENP content out of the original ones,
without changing the content of the information but just restructuring it for the needs of
the facilitation.
Page A.191
MIND
A.4.5.8
1.2 / 0.1
Consideration of possible failure conditions
By taking into account SIP and SDPng as protocols upon which the E2ENP could be mapped onto, it is
necessary to point out that SIP is a non-symmetrical protocol with respect to the message exchange
between the affected peers. The SIP Offerer - Answerer model gives no possibility for signalling errors,
failure conditions or exceptions (unexpected state-changes) at their occurrence at the Offerer’s side. The
E2ENP requires several SIP-message round-trips within its phases and every one-way message of a
round-trip should be proved both on its correctness and acceptability at all involved peers in the E2ENP
signalling. Additionally, state changes of the end-peers within the runtime of a E2ENP-phase should be
considered. These changes may concern a peer being involved into:
•
higher priority negotiation/-s;
•
the starting of higher priority internal processes of the peer, which affect the resource
management and the E2ENP profile settings;
•
hardware- and/or software-crashes, resulting in resource drop-outs.
To this extent an E2ENP implementation based on SIP/SDPng should carry, within its SDPng body,
error-codes indicating failures occurring at the Offerer and reasons for the failure and/or the SIP errorcode for both the Offerer and the Answerer.
It should also be considered that some intermediate components interacting with end-peers along the
E2ENP signalling path might cause disturbances of the protocol if they do not understand it. In this case,
there should be mechanisms for detecting and recovering such disturbances.
Requirement 61. The E2ENP SHOULD be able to offer the same possibility to signal both internal and
external failure conditions, exceptions, and errors occurring by any of the peers
involved in the E2ENP signalling.
The requirements on E2ENP symmetry (see Section A.4.5.1) also partially cover the problem with
treating the E2ENP errors.
A.4.6 List of Requirements
ID
Description
[1]
The “handling of QoS” SHALL be achieved through the negotiation and enforcement of QoScontracts, which contain configuration and constraints information.
[2]
The QoS-contract SHALL capture configuration information concerning network resources, as
well as the resources and capabilities of the involved QoS-aware end-systems.
[3]
The QoS-contract SHALL capture user’s QoS expectations, as well as network provider
policies, in order to enable a comprehensive QoS adaptation process.
[4]
Developers and users of mobile and/or fixed terminals MAY deal with unstable environment
conditions, especially when enforcing QoS.
[5]
Developers and users of multimedia applications dealing with multiple streams MAY augment
their QoS specifications by including QoS correlation and time-synchronization aspects.
[6]
Developers and users of multimedia applications dealing with multiple streams MAY
advantageously structure their QoS specifications in a hierarchical manner.
[7]
The E2ENP SHALL include mechanisms and means for planning ahead proper counteractions,
coping with otherwise unpredictable events resulting from QoS violations (e.g. handovers) or
QoS changes (e.g. user changing profile information when roaming).
Page A.192
MIND
1.2 / 0.1
[8]
The E2ENP SHALL include mechanisms and means for quickly and efficiently performing
QoS negotiations and QoS re-negotiations.
[9]
The E2ENP SHALL include mechanisms and means for specifying and negotiating multiple
alternative QoS levels.
[10]
Each QoS level SHALL be described by a specific QoS contract.
[11]
Bid QoS contracts SHALL describe Application Level QoS from receiver’s perspective.
[12]
The E2ENP MUST derive QoS information (peer, local, network supportable QoS) from
knowledge about available resources.
[13]
The E2ENP SHALL include mechanisms and means for uniquely referencing each QoS
contract during QoS negotiations and QoS re-negotiations, in order to keep signalling minimal.
[14]
The E2ENP SHALL include mechanisms and means for enforcing various negotiation modes
(push, pull, push-pull), since services may require different negotiation schemes.
[15]
The E2ENP SHALL be symmetrical with respect to QoS re-negotiation signalling.
[16]
The E2ENP SHOULD be able to offer the same possibility to signal both internal and external
failure conditions, exceptions, and errors occurring by any of the peers involved in the E2ENP
signalling.
[17]
The E2ENP SHOULD offer mechanisms for error recovery.
[18]
The E2ENP SHALL assume that users will have preventively validated their preferred set of
QoS contracts against what their preferred access network provider can actually support.
[19]
The E2ENP SHALL allow users negotiating Adaptation Paths (AP).
[20]
Each element of an AP SHALL be a prioritised, uniquely-identifiable QoS contract.
[21]
Each AP SHALL define a default QoS contract that SHALL be enforced when starting
streaming.
[22]
An AP COULD include the specification of rules defining the circumstances under which
different QoS contract, out of the given AP, shall be enforced.
[23]
The E2ENP SHALL include mechanisms and means for specifying APs at stream level.
[24]
The E2ENP SHALL allow end-peers negotiating Group APs, expressed in terms of alternative
configurations of a given group of streams.
[25]
The E2ENP SHOULD allow end-peers negotiating NULL-stream QoS contracts in Group APs.
[26]
The application of the “NULL”-stream MUST NOT affect the context of the running session.
[27]
The E2ENP SHALL allow end-peers negotiating APs for Associations of streams.
Page A.193
MIND
1.2 / 0.1
[28]
The E2ENP SHALL allow end-peers negotiating QoS Contexts.
[29]
The E2ENP SHALL allow end-peers negotiating QoS Contexts associated with aggregations of
streams at various levels of abstraction.
[30]
The E2ENP SHALL allow end-peers negotiating relative priorities among those QoS Contexts,
which happen to be siblings in a given tree-based hierarchy of QoS Contexts.
[31]
The E2ENP SHALL allow end-peers negotiating uniquely-identifiable QoS Contexts, each
associated with a specific element of a Group AP (GAP).
[32]
Each GAP SHALL define a default QoS Context that SHALL be enforced when starting
streaming.
[33]
The E2ENP SHALL enforce basic, non-iterative pre-negotiation, negotiation, and re-negotiation
schemes.
[34]
The E2ENP MAY allow more complex negotiation schemes only by employing third-party
control units (e.g. Conference Control Units).
[35]
In general the E2ENP SHOULD be used for performing negotiations and re-negotiations only
between the end-peers involved in a session. Should this requirement be not applicable due to
service specific reasons, the previous requirement would take precedence.
[36]
By complex negotiation scenarios (e.g. conference like) the end-peers engaged in a E2ENP
process MAY publish the already pre-negotiated QoS Contracts and user profile information in
some registration services thus allowing a short negotiation process for the later joining parties.
[37]
It SHOULD be possible to re-negotiate a single stream of a group, if this is not contradictory
with the context of the group, in order to minimize the signalling for the re-negotiation.
[38]
In case a stream is being correlated with other streams, it SHOULD be the responsibility of the
correlating party to perform re-negotiation with all affected parties.
[39]
The E2ENP SHALL allow both senders, receivers, and sender/receivers specifying what QoS
level they want to send/receive at stream level.
[40]
The E2ENP SHALL allow only receivers and sender/receivers specifying what Group APs /
QoS Contexts they want to enforce.
[41]
The E2ENP SHALL provide mechanisms and means for enforcing the co-ordination of
distributed resource management.
[42]
According to the "Economy Principle", remote resources at the peer SHALL be reserved only
after local resources have been successfully reserved.
[43]
According to the "Economy Principle", network resources SHALL be reserved only after local
resources have been successfully reserved at all peers
[44]
The E2ENP SHALL enforce a consistent application of the “Economy Principle” among
multiple peers.
[45]
The E2ENP MUST ensure that at any given time the application of the “Economy Principle”
does not lead to deadlock conditions.
Page A.194
MIND
1.2 / 0.1
[46]
The E2ENP MUST ensure that recovery mechanisms are put in place in order to cope with
possible colliding applications of the “Economy Principle”
[47]
The E2ENP SHOULD operate based on an abstraction of the underlying network.
[48]
The E2ENP SHOULD be able to be used in combination with (but independently from)
Intermediate Components, which may result effective in preparing and/or guaranteeing the QoS
Contracts agreed by the end-peers.
[49]
The exchange of information (e.g. profiles, security, authentication, provider policies, etc.) not
directly affecting the E2ENP-process, rather influencing the information that is going to be
negotiated, SHOULD be carried out ahead of the E2ENP start.
[50]
The E2ENP paths-paths and the corresponding data-paths between any two given end-peers
SHOULD be in general considered different.
[51]
With respect to the E2ENP, the out-band intermediate components SHOULD operate based
only on information provided - directly or indirectly - by the peers, in order to carry out
application specific tasks.
[52]
The out-band intermediate components SHOULD be allowed to interfere with the E2ENP only
by explicitly signalling the end-peers and only in cases of end-peer misbehaviour, when the endpeer(s) disregard system policies, and/or by system failure conditions.
[53]
The numbering range for the user perceivable quality specification (overall visual quality and
colour quality, if the colour quality is applicable) SHOULD be uniquely understandable for the
application and the E2ENP in order to be able to uniquely map video quality to a given codec.
[54]
The numbering range for the user perceivable quality specification (overall visual quality and
colour quality, if the colour quality is applicable) SHOULD have enough resolution to uniquely
map to the compression levels of a given codec.
[55]
The E2ENP SHALL provide mechanisms and means for specifying and pre-negotiating
resource management policies.
[56]
Resource management policies SHALL include, but be not limited to, any logical combination
of the following criteria: Optimisation of memory resources, Optimisation of processing power,
Optimisation of network resource performance, Optimisation of power consumption.
[57]
The applications and/or middleware using the E2ENP MAY autonomously prioritise list of
codecs/capabilities, based on pre-negotiated resource management policies and current resource
availability.
[58]
By third-party-assisted negotiation a pure Mediator SHOULD only facilitate the delegation of a
connection without actively taking part in it.
[59]
A Mediator MAY leverage services like directory, allocation, presence etc. for preparing
E2ENP message content only.
[60]
The Mediator SHOULD be able to generate new E2ENP content out of the original ones,
without changing the content of the information but just restructuring it for the needs of the
facilitation.
[61]
The E2ENP SHOULD be able to offer the same possibility to signal both internal and external
failure conditions, exceptions, and errors occurring by any of the peers involved in the E2ENP
signalling.
Page A.195
MIND
1.2 / 0.1
A.5. Current Trends and Needs
Before we continue to define the E2ENP we briefly take a look at desiderata within the internet and the
telecom communities (IETF – Internet Engineering Task Force, ETSI – European Telecommunication
Standards Institute) with respect to capabilities and QoS support, the negotiation of session descriptions
and the requirements set fort to provide those. Some hints of how E2ENP can meet these requirements are
discussed.
The current possibility to describe sessions with SDP are recognized as cumbersome and inefficient
[MMUS_53], [SDPngT00], especially when it comes to session descriptions for different purposes to be
used with different protocols. The MMUSIC considers a transition from SDP to SDPng using a new more
flexible syntax (XML) for their descriptions. With respect to the desiderata that SDPng should support
different scenarios and work with different carrier protocol profiles [SDPngT00], the E2ENP can meet
this requirement over the proposed header of SDPng for supporting different profile dependant SDPng
dialects. Additionally the security relevant protocol elements as a general problem of SDPng
[MMUS_53] can also be incorporated in such a general SDPng header. [MMUS_53] sets the
requirements:
•
SDPng must be simpleSDPng must not yield too large messages
•
SDPng mechanism must be extensible
Additionally [SDPOA02] and [SDPngT00] recognize the need of retrieving and pre-negotiating session
relevant information before the start of any common business and the necessity of intra-messagereferencing. Since E2ENP as an extension to SDPng is also based on XML and includes PDU header,
E2ENP can support due to this inter- and intra-message-referencing different protocol phases and reduces
the signalling due to the possibility of exchanging keys of already pre-negotiated information instead of
exchanging complete descriptions anew with every new message. According to [MMUS_53] SDPng
should support:
•
Single round-trip negotiation as in offer/answer
•
Multiparty negotiations
•
Possibly QoS
E2ENP as a parallel model of the Offer/Answer model [SDPOA02], incorporating the ideas of
[SDPOA02] but enhancing it with QoS, would be usable both as a peer-to-peer and a multiparty
negotiation model at application level.
ETSI [ETSIWS02] desiderata include:
•
The separation of the user and the application level QoS
•
The separation of the application and transport levels
•
Signalling at both application and network levels incorporating SIP [SIPBIS09], [RFC3261] and
H.323 [H323]
With respect to these requirements E2ENP is a pure application level protocol which can support QoS at
application level and be used to control and synchronize the signalling at network level. Considering the
requirement of ETSI for support of QoS Classes, E2ENP can also support such descriptions if they are
standardized and available, due to the flexibility of the E2ENP description with XML. But the question of
QoS Classes stays open, especially in cases of video support, since video codecs can be configured in
many different ways and some of the video codecs generate dynamic streams. The configuration of video
in sense of QoS might lead to enormous multiplicity of profiles, which in general is not a flexible and
simple solution. ETSI raises the question of Firewalls, with this respect E2ENP with SIP is an acceptable
Page A.196
MIND
1.2 / 0.1
solution, since E2ENP is an interpretable and not executable protocol and can be by necessity analysed
also by the Firewall-Proxies.
Page A.197
MIND
1.2 / 0.1
A.6. Proposed Solution for the E2ENP
In order to meet the requirements set forth in the Chapter A.4, we hereby propose a new protocol called
End-to-End QoS Negotiation Protocol (E2ENP), based on extensions to SIP/SDPng.
A.6.1 Assumptions
Before proceeding with the description of the E2ENP concept, some keys assumptions, completing the
generic description of actors and scenarios provided in Section A.3, are hereby presented.
A.6.1.1
One-to-one communication
The usage of the communication modes (push, pull and push-pull) may be situation and application
dependant with respect to the senders and the receivers. Some standard usages of the modes are here
described:
•
If the Offerer has no notion how the profile of the Answerer looks like, the Offerer may use
“pull” mode to first retrieve the settings of the Answerer and eventually adapt Offerer’s own
settings.
•
If the Offerer has no possibilities to adapt (or whatever other reason), the Offerer may “push”
her/his settings to the Answerer thus eventually enforcing her/him to adapt and using “push”–
mode.
•
If adaptation at the both sides may be necessary the “push-pull” mode might be used to enable
three-way exchange of the Offerer’s proposal. This mode can be used for agreeing on two way
communication.
By an assumption that the “receivers” should tune into given “senders”, the “receivers” should be those
who adapt. If the “senders” should match given “receivers”, the adaptation takes place by the “senders”.
There are three scenarios for the case of the simple one-to-one communication considering which party is
the Offerer and which the Answerer, which party is Sender or Receiver and if the both parties may send
and receive:
•
Sender (Offerer) – receiver (Answerer)
In general both “push” and “pull” modes can be used for this scenario according to the adaptation
possibilities and rules of the sender and/or the receiver. If the Offerer is the one who should adapt,
the Offerer should use a “pull”-mode, otherwise “push” mode should be used. The usage of “pushpull” mode may also be applied but by expected one-way data stream this would only complicate the
signalling protocol and with be contradictory with the requirement for E2ENP-simplicity.
•
Receiver (Offerer) – sender (Answerer)
Also in this case both “push” and “pull” modes can be used according to the adaptation possibilities
and rules of the sender and/or the receiver. If the Offerer is the one who should adapt, the Offerer
should use a “pull”-mode, otherwise “push” mode should be used. The usage of “push-pull” here is
also not recommendable for the same reasons as the scenario above.
•
Sender-receiver (Offerer) – sender-receiver (Answerer)
When all peers plan to both send and receive streams, the Offerer gathers information about the
Answerer’s receiving capabilities and QoS desires, before the Offerer issues an invitation to the
given Answerer.
Page A.198
MIND
1.2 / 0.1
In this way, by invitation time the Offerer can send to the Answerer a proposal including:
-
information about the Offerer’s capabilities for sending and receiving streams;
-
Offerer’s own desired QoS specification for receiving streams, tailored on Answerer’s
preferences; and
-
QoS proposals for sending streams, tailored on Answerer’s preferences.
The Answerer replies then to the Offerer with a subset of the Offerer’s bid.
This scenario most probably uses the “push-pull” mode since a bi-directional communication should
be established.
A.6.1.2
One-to-many communication
By one-to-many communication not all the combinations of connection modes and negotiation modes are
possible and reasonable. For instance, the "Single Receiver and Many Sender " scenario can cause
overloading at receiver side, and this is why this case should be treated by forcing the receiver carrying
out multiple negotiations on a separate basis with every sender, like in the "Sender (Offerer) – receiver
(Answerer)" scenario described in Section A.6.1.1.
Some well-known connection scenarios corresponding to the one-to-many scenario are:
•
pure multicast: receivers "tune" into given senders by selecting a given multicast group, based on
pre-disseminated information (e.g. via SAP). In this case the sender acts as a sort of Offerer.
•
This scenario would work like the "Receiver (Offerer) – sender (Answerer)" scenario described
in Section A.6.1.1. This allows flexibility of joining and leaving the session. The Answerer can
then adapt the session on a single basis for every participant, but taking into account also the
resources used by already existing sessions. Had instead the sender taken the role of Offerer,
some of the receivers might not have been able to cope with such requirements.
In both cases, the Offerer (either sender or receiver) could advantageously use offline pre-negotiated
information for speeding up the communication setup at run time. Eventually this could be carried out
through user agents [FIPA], or through a broker (but these cases are outside the scope of this document).
All the scenarios where the single party is a receiver should be considered as one-to-one negotiation since
some separate resource management for every incoming stream may be necessary.
A.6.1.3
Many-to-many communication
This case could be treated like the superposition of multiple negotiations, as described in Section A.6.1.1
and Section A.6.1.2, should the peers agree at the beginning on the choice of a conference leader, who
orchestrated the negotiations for joining/leaving the session and managed the running of it. The peers
could also make some a priori arrangements about how to configure the communication environment
before they negotiate the real connections. The parallel and/or sequential negotiation runs between the
negotiating peers are application dependent and thereof out of the scope of this writing.
A.6.2 The E2ENP Phases
The E2ENP comprises four key phases, namely (Figure A.8):
1.
End-to-End QoS Pre-Negotiation Phase;
2.
Multi-stream QoS Correlation and Time Synchronization Enforcement Phase;
Page A.199
MIND
1.2 / 0.1
3.
End-to-End QoS Compact Negotiation (with Economy Principle)22 Phase; and
4.
End-to-End QoS Compact Re-Negotiation (with Economy Principle)23 Phase.
All the four phases can be concatenated within the lifetime of a given media session. Alternatively, the
first two phases may be executed independently of the latter two and at different times, but strictly
following the given order. As a consequence, given that the results of the various E2ENP phases are valid
within a limited amount of time, the corresponding validity timescales may differ from phase to phase.
Figure A.8: Phases and actors of the E2ENP
A.6.2.1
The End-to-End QoS Pre-Negotiation Phase
More specifically, the End-to-End QoS Pre-Negotiation Phase can be executed a priori, and the results
can then be applied to the remaining phases of multiple successive communication sessions at later times.
This phase is characterized by a process that end-peers can perform before the actual start of a media
session, and independently of the session itself. The goal of this phase is to enable the exchange - in a
non-obliged manner - of information among peers, concerning configurations of capabilities and QoS
Contracts, as deduced from their QoS profiles.
These configurations include Adaptation Paths, so that the end-peers can proactively agree on the way to
react to possible QoS changes or QoS Violations in an effective and efficient manner. Optionally, this
phase allows each couple of peers negotiating Group Adaptation Paths at Association level, i.e. enforcing
QoS correlation and time Synchronization across all the streams established between the given couple of
peers.
22
Or, more shortly, "Fast Negotiation".
23
Or, more shortly, "Fast Re-negotiation".
Page A.200
MIND
1.2 / 0.1
This information exchange has informational character for the involved peers, and is used not only for
informing each other ahead about the capabilities and performance possibilities applicable to the given set
of peers, but also for reaching agreements on redefining some of those configurations.
In this way, the peers are thus able to establish a common vocabulary, a priori of any specific business.
The usage of the pre-negotiation phase should actually be connected with some context for which the prenegotiation is reasonable. In general it should be considered that if there is a business, there might be
preferences how this business should be preformed and these preferences might be exchanged and
considered before the start of the peers’ common business. The so created common vocabulary might be
interoperable between different applications like electronic phone-books24, time-tables25, etc.
In order to support interworking of service domain and transport domain, it might be necessary to include
QoS definitions at transport layer for negotiations at application layer (see Chapter 4 of this deliverable).
Then, service domain validating entities (like enhanced SIP proxies) should be able to mark a given QoS
definition as compliant with the contract or non-compliant. Depending on the different scenarios in
Chapter 4, according actions can be taken. It is however important to note, that in contrast to [Bos01] and
[Bos02], service domain entities are not allowed to change the QoS definition provided by the endsystem. This is necessary as the end-system might have reserved proper resources on the local terminal
for handling given QoS levels at transport layer. If the service domain entities change QoS parameters
provided by the end-system the end-system can not coordinate terminal and network resources.
End-terminals may already provide proposed QoS contracts at transport layer in initial session
descriptions. Service domain entities may, during pre-negotiation phase, indicate if they support a given
transport layer QoS contract or not, e.g. based on subscription information. An end-terminal should not
try to enforce during negotiation a session quality that requires network resources, where the service
provider already indicated that it does not support this amount of resources, because it is highly possible
that the transport domain will not support this level when reserving network resources during call set-up.
A.6.2.2
Phase
The Multi-stream QoS Correlation and Time Synchronization Enforcement
The Multi-stream QoS Correlation and Time Synchronization Enforcement Phase is optional, insofar as it
is required only if peers are planning to establish multiple streams needing to be correlated and
synchronized. The individual peers solely apply such a phase. As an exception, a separate entity (e.g. an
intermediate component like a conference call bridge) could also employ this phase, should the various
peer delegate it to carry out complex negotiations among them26.
A.6.2.3
The End-to-End QoS Compact Negotiation Phase
The third phase is characterized by a process that end-peers can perform either before or at the actual start
of a media session, in order to agree on a given QoS level to be enforced for the given session and
streams, based on results of a previously applied End-to-End QoS Pre-Negotiation process.
24
A phone-book might contain not only the phone-number entries but also the pre-negotiated QoS, corresponding the
quality preferences of the owner of the saved number.
25
A monthly audio-conference concerning some joint venture might have pre-negotiated QoS parameters which are
long term saved for the time of the existence of this joined venture.
26
The case of intermediate components is out of the scope of this writing, and it is only mentioned for the sake of
completeness.
Page A.201
MIND
1.2 / 0.1
This process is considerably faster compared to the case of a End-to-End QoS Full Negotiation27, since
only references of pre-negotiated information are actually exchanged among peers.
At completion of the End-to-End QoS Compact Negotiation process, the end-peers have agreed on the
QoS profiles they are going to use for the communication.
Also in this phase (and during re-negotiation, see next section), service domain entities may indicate if
they support a given QoS definition at transport layer. Note, that the reason is different compared to the
pre-negotiation phase. During the pre-negotiation phase, service domain entities may check a transport
layer QoS contract with its compliance with a user profile (e.g. a user may have a profile that allows him
to use max. 64 kbps for each call). During compact negotiation phase, short before the streaming process
is established, the service domain entities (if they have knowledge about actual network resource
utilization by tightly coupling service and transport domain) may temporarily block a QoS contract at
transport level, even if the contract would be supported by the users subscription information, given a
very high load in the network. By blocking e.g. low priority sender/receivers, more resources can be
given to higher priority sender/receivers and the service domain can thus implicitly influence resource
distribution. Again, a QoS contract should not be changed by intermediate entities, only indications could
be provided, if the contract is supported or not.
End-terminals may already provide proposed QoS contracts at transport layer in initial session
descriptions. Service domain entities may, during pre-negotiation phase, indicate if they support a given
transport layer QoS contract or not, e.g. based on subscription information. An end-terminal should not
try to enforce during negotiation a session quality that requires network resources, where the service
provider already indicated that it does not support this amount of resources, because it is highly possible
that the transport domain will not support this level when reserving network resources during call set-up.
A.6.2.4
The End-to-End QoS Compact Re-Negotiation Phase
The fourth phase is characterized by process that end-peers can trigger upon detection of either a QoS
change or a QoS Violation, in order to agree on a given QoS level to be enforced for the given media
session, based on results of a previously applied End-to-End QoS Pre-Negotiation process.
This process is considerably faster compared to the case of a End-to-End QoS Full Re-Negotiation28,
since only references of pre-negotiated information are actually exchanged among peers.
At completion of the End-to-End QoS Compact Re-Negotiation process, the end-peers have agreed on
new QoS profiles they are going to use for the communication.
The End-to-End QoS Compact Re-Negotiation Phase can be applied several times during the lifetime of
any given media session.
A.6.2.4.1
Fast Vs. Structured Re-negotiation
Based on the requirements set forth in Section A.4.5.6, peers can pro-actively pre-negotiate a common
resource management policy, in order to avoid instabilities whenever the conditions leading to renegotiations are met.
27
A process that end-peers can perform either before or at the actual start of a session, in order to agree on a given
QoS level to enforce for the given session and streams, eventually by redefining some of the originally proposed
configurations of QoS specifications. At completion of the End-to-End QoS Compact Negotiation process, the endpeers have agreed on the QoS profiles they are going to use for the communication.
28
A process that end-peers can trigger upon detection of either a QoS change or a QoS Violation, in order to agree on
a given QoS level to be enforced for the given session and streams, eventually by redefining some of the originally
proposed configurations of QoS specifications. At completion of the End-to-End QoS Compact Re-Negotiation
process, the end-peers have agreed on new QoS profiles they are going to use for the communication.
Page A.202
MIND
1.2 / 0.1
To this extent, peers can perform re-negotiations at two different levels:
•
a fast, in-band signalling process (by e.g. changing at runtime in the RTP packet header the RTP
payload type, without affecting the currently enforced application-level QoS Contracts); and
•
a more structured process, based on the End-to-End QoS Re-negotiation Phase (whenever the
former process is not sufficient to cope with a given QoS Violation/Change).
More specifically, peers can dynamically choose to use any payload type applicable for a given user-level
QoS Contract, as described below. This choice would reflect in an instance of the usual RTP in-band
signalling as a form of very fast re-negotiation. Whereas, should QoS Violations or QoS Changes occur,
requiring enforcing a new user-level QoS Contract, the End-to-End QoS Re-negotiation Phase would take
place.
The RTP Payload Type field contained in the RTP headers may be used by senders for signalling in-band
to their receivers the decision to use another (negotiated) codec. This is a form of re-negotiation, which
per se would be transparent to the E2ENP. However peers using this in-band signalling may still
advantageously use E2ENP for reacting effectively and efficiently to QoS violations/changes. Within this
context, we can easily harmonize the use of in-band RTP signalling, by forcing peers to validate the new
proposed codec against any pre-negotiated information, not only in terms of capabilities but also of QoS
Contracts).
This means that the sender would first of all validate (and pre-book resources accordingly) the new
capability, as well a new QoS Contract (optimising the use of that capability), with respect to the prenegotiated information. On the other hand, each receiver would validate the new capability signalled inband by the sender, against the pre-negotiated information.
There may be cases, where the receiver detects that not enough resources are available for activating the
given codec, whereas the sender has already switched codec and sent packets encoded with it. The
receiver can therefore not decode those packets, or decode them at a lower QoS level (e.g. at lower
speed/frame-rate). To work around this problem, we can assume the receiver chooses the latter option
(decoding at lower QoS level), but signals explicitly to the sender to select a lower QoS level (via E2ENP
compact re-negotiation), for example an intermediate one (assuming pre-negotiated information is
available). To this extent it is necessary to mention that losing or not interpreting a single video packet,
for the time of the QoS switch between the sender and the receiver, is not so critical, since from the
perspective of the human user the missing single video frame is not easily noticed. Thus the user
perceived video QoS should not be considered severely affected by such minor video disturbances. On
the other hand losing or not interpreting a single audio packet results in audible cracks which should be
considered a violation from the user perspective. A possible solution to this problem can be the sending of
redundant audio data with the same or different quality in the same audio packet as described in
[RFC2198]. The packets carry thus the audio data twice and if a single audio packet gets lost the
following one redundantly supersedes the lost data. For supporting the user perceived audio QoS such
duplicated information should be delivered with respect to the agreed capabilities and QoS contracts
between the peers, thus enabling the sender to deliver in parallel differently coded audio data. The
receiving of single audio packets with lower quality should not be considered a violation from the user
perspective, since a human would rare perceive such changes as e.g. singularity switches between mono
and stereo, if the mono signal is played simultaneously on all the audio boxes of the device. In general
terms the accumulation of audio and video singularity disturbances should be considered a violation and
should be allowed only for the time of a running re-negotiations. The treatment of the occurring media
singularities is a problem of the realization of the resource management; the tolerance and control
mechanisms, etc. and may be application and heuristics dependant.
Key issues for realizing the mechanism described above, are:
•
The in-band signalling does not suffice to allow peers agreeing on QoS Contracts to enforce: the
complete re-negotiation mechanism is in fact achievable by using more structured approaches, like
the E2ENP. However, as an alternative to using E2ENP, the receiver may monitor the current QoS
level, eventually by leveraging RTCP monitors, and thus identify which of the pre-negotiated QoS
Contracts the sender is currently enforcing.
Page A.203
MIND
•
1.2 / 0.1
Network resource reservations: should not be committed until both peers have agreed on what codec
and what QoS Contract to enforce. The E2ENP guarantees this, thanks to the "Economy Principle".
A.6.2.4.2
The use of spare contracts
Based on requirements set forth in Section A.4.5.1.1, all those QoS Contracts not supported by the given
users' preferred network provider could be advantageously considered as spare ones.
These contracts would have to be negotiated, insofar as the Offerer and the Answerer could
advantageously agree a priori on similar contracts, so as to take into account agreements between the
other peers and their currently used network providers.
When a vertical handover occurs, either peer can try to validate all of her/his contracts, including the
spare ones, which might eventually become applicable with respect to the new network provider and/or
new type of access network.
This means that the peer detecting a QoS Violation/Change can, upon finding that some spare contracts
are now validated, initiate a End-to-End QoS Compact Re-Negotiation Phase, not only for indicating the
new QoS Contract to enforce, but also to “unblock” said pre-negotiated spare contracts.
Furthermore, one should note that after a vertical handover some of the previously valid contracts might
be no longer applicable. This means that the “blocking” of such contracts should also be taken into
account during the End-to-End QoS Compact Re-Negotiation Phase.
A.6.2.5
Resource management
The E2ENP interacts with the local resource management functions during all the four phases. More
specifically, the E2ENP interacts with the local and network resource management functions during both
the End-to-End QoS Compact Negotiation Phase and the End-to-End QoS Compact Re-Negotiation
Phase, according to the "Economy Principle", and based on the resource management policies prenegotiated during the End-to-End QoS Pre-negotiation Phase.
A.6.3 The underlying model: hierarchical Finite State Machine
Given the hierarchical structure of the QoS specification prescribed by the requirements set forth in
Section A.4, we hereby envision that a model meeting nicely those requirements is the one based on the
concept of hierarchical Finite State Machine (FSM) [Booch99].
In such a model, each QoS Contract corresponds to a state of a hierarchical FSM. At the lowest level of
this hierarchical structure, states map to QoS Contracts of individual streams. The nominal QoS Contract
(i.e. the one, which the user wishes to enable by defaults) corresponds to the Initial state of the FSM
associated with the given Adaptation Path.
Each Adaptation Path corresponds to an elemental FSM, whereby states are mutually exclusive.
States and/or complete elemental FSMs can be nested within higher-level states, which in turn are
associated with QoS Contracts, as indicated above: this represents the concept of QoS Context.
Within a given higher-level state, concurrent nested FSMs can co-exist: this represents a group of
Adaptation Paths being correlated by given QoS Context.
Each transition of such hierarchical FSM describes a peculiar change of QoS Contract in reaction to a
given event, e.g. a QoS violation. The transitions are triggered whenever specific predicates evaluate to
true: this translates in our model to comparing the values of specific monitored QoS parameters against
the corresponding values stated in the given QoS Contracts.
Page A.204
MIND
1.2 / 0.1
Transitions are associated eventually with high-level actions (e.g. drop an existing stream or start a new
stream). These actions can eventually cause the generation of events to the users indicating a temporary
out of service condition, e.g. due to a hand over occurrence.
Differently from QDL [Loyal], the specifications of QoS Contracts (and, to a limited extent, of QoS
Contexts) and of the hierarchical FSM are de-coupled from each other. This introduces modularity and
thus flexibility to the design: one can combine a given QoS Contract with different adaptation policies,
and adaptation policies can be configured with different hierarchical FSMs.
A.6.4 The negotiation process
The negotiation process employed by the E2ENP basically consists of running a non-iterative negotiation
process at connection establishment time, whereby peers simply exchange among themselves a set of
state identifiers, with respect to the hierarchical FSM representing a given pre-negotiated Adaptation
Path.
The Offerer will propose a bid, and each Answerer will validate the bid against its own adaptation
policies, and respond accordingly with a counter-offer. This model limits the scope of the counter-offers
to the definition of a subset of the original bid (in order to limit the complexity of the problem). This
translates at Answerer-level into:
•
a QoS Contract conformance verification [Frolu98] applied to each item in the bid, with respect to
the pre-negotiated QoS Contract Types and QoS Contracts; should the contracts be expressed in an
XML document, conformance verification could be achieved e.g. by enforcing a pre-defined, specific
XML Document Type Definition (DTD) or by customized verification upon a known XML-schema
definition.
•
an optional set of pruning operations applied onto the structure of the original pre-negotiated
hierarchical FSM.
One should note that whenever a new peer joins a group of already communicating peers, the new
peer might act as the Offerer of a new E2ENP process29, following the same mechanisms described
above. Furthermore, any ad hoc creation, modification, or removal of QoS Contexts and/or streams
after that the negotiation process has been successfully completed (and not taken already into account
as a QoS change within the negotiated Adaptation Path), would trigger a new instance of the
negotiation process.
More specifically, one should note that the user might deliberately cause a QoS change on an already
running multimedia application, for example in order to increase or decrease the overall level of QoS,
or some part of it only. This negotiation would reflect in a change in the QoS Contracts associated
with the Adaptation Path, but could also reflect on the structure of Adaptation Path itself.
Since the negotiation process is quite expensive, any successive incremental reapplication of the
E2ENP or parts thereof can cause inefficiencies. To this extent one should however note that:
•
in a video-on-demand scenario, both parties simply agree a priori on an Adaptation Path for a
predetermined set of streams, in order to cope with QoS violations or QoS changes. The variability of
the aforementioned ad hoc changes therefore does not apply to this case.
•
the Offerer can eventually already take into account events like the creation, modification, or removal
of QoS Contexts and/or stream within the Adaptation Path it bids.
29
Eventually starting from the End-to-End QoS Compact Negotiation Phase, should the new peer already have prenegotiated information with the communicating peers.
Page A.205
MIND
•
1.2 / 0.1
after the initial negotiation, all peers can more quickly converge to negotiation agreements compared
to the case of the initial negotiation, since the majority of them are using an already negotiated
hierarchical FSM.
The rules for handling these situations are however heavily dependent on the type of management
applied to the given communication sessions. For instance, in the case of conference services, this
translates into choosing specific conference control policies and protocols. Therefore, the sheer
E2ENP functionality is devised in such a way that it delegates these high level session management
tasks to external mechanisms and protocols, which are thus outside of the scope of this writing.
A.6.5 Incremental Negotiations - Concept of Micro-phases
By extending the E2ENP phased-approach, refinements are envisioned, as the introduction of microphases. This means that peers can incrementally update pre-negotiated information, e.g. for adjusting prenegotiated information in case of vertical handovers, whereby the new access network
technology/capacity and/or new network provider can offer different QoS levels, compared to the prenegotiated ones. To this extent, is necessary a modular description of negotiable items, so that those,
which are not affected by the changes, are kept valid. This means that for such items no full renegotiation would be then necessary, with evident benefits in terms of performance with respect to the
QoS Changes/Violations treatment.
This concept is left for further study. More specifically, aspects like impact on pre-existing state machines
describing pre-negotiated APs must be considered in detail.
A.6.6 Protocol features to meet the requirements
This section describes some general ideas about the E2ENP functionality together with some
implementation-specific issues concerning the process of specifying valid QoS contracts and the E2ENP
negotiation. With this respect new SDPng elements for implementing the E2ENP concept are proposed.
The E2ENP MAY allow end-peers partially performing negotiations about their QoS settings in a nonobliged manner well ahead of the actual communication establishment, in order to co-ordinate long term
relationships and/or agendas among themselves.
The results of such “end-to-end pre-negotiations” MAY thus be used to improve efficiency of the actual
end-to-end negotiation process, by leveraging some results of end-to-end pre-negotiations. Additionally,
the E2ENP COULD allow end-peers negotiating multi-streams aspects, as detailed in the previous
sections.
The E2ENP SHALL allow any of the end-peers performing end-to-end re-negotiations, upon detection of
either a QoS change or a QoS Violation. This process SHALL leverage the results of the previously
applied end-to-end negotiation process.
The E2ENP SHALL negotiate QoS contracts derived as follows (Figure A.9):
1.
Users specify the “User level QoS” – The QoS as users expect to perceive, eventually expressed in
non-crisp terms by non-expert users.
2.
Applications derive “Application Level QoS” by mapping “User level QoS” into QoS contracts
detailing specific aspects (e.g. frame-rate).
3.
The mapping of Application Level QoS on the end-system capabilities (i.e. the end-system hardware
and software configuration - e.g. supported codecs), originates QoS contract Sketches, which
represent the Application Level QoS that the end-system can theoretically support.
4.
The validation of “QoS contract Sketches” against local and network specific policies for supporting
QoS, originates “Validated Application Level QoS contracts”. The validation process assumes the
applying of QoS Broker/QoS Agent trading policies with respect to security, technology policies,
provider policies, etc. The description of these policies is system internal representation and out of
Page A.206
MIND
1.2 / 0.1
scope for the protocol. It is the Broker/Agent who generates the correct results for the negotiation out
of the Contract Sketches and the policies. For the matching between the contracts and the policies an
algorithm as described in [RFC2533], [RFC2703] can be used. The policies are the boundary
conditions for the current applicability of the “Application Level QoS contracts”. The “Validated
Application Level QoS contracts” are in fact indications if a certain contract is currently applicable or
not, and if it would be applicable under some other conditions, corresponding policy changes like e.g.
by vertical handovers.
Figure A.9: Deriving contracts from User Profile and System Configuration Information and validating
them.
The “Application Level QoS contracts” constitute a common vocabulary, which the local and the remote
end-systems can use for negotiating the establishment of QoS aware communications. Those “Application
Level QoS” which have failed the validation, can still be used in special cases like vertical handovers,
dynamic end-system changes (e.g. due to end-system up-/downgrading), etc.
Transport level QoS parameters (necessary for reserving network resources) may be optionally included
in the session negotiation process. This enables intermediate entities to verify if the proposed sessions’
network resource requirements are within the contract that the user has with its provider. The providers
intermediate components may then check the compliance with the contract and indicate, if they support
the session description or not. It is important to note, that the E2ENP is NOT used to reserve network
resources. Rather, this is an integral step in the overall session establishment but delegated to a signalling
protocol like RSVP or NSIS. Nevertheless, the proposed E2ENP allows the coordination of terminal
resource management and network resource management based on the economy principle.
The E2ENP uses only “Validated Application Level QoS contracts”. The process for obtaining them is
considered as given, since it can be implementation-dependent. For the sake of simplicity, this document
refers to “Validated Application Level QoS contracts” as “Application Level QoS”.
A possible E2ENP implementation can be realized by combining special extensions of SDPng
[SDPNG03], [SDPNG04] with a particular use of SIP.
Page A.207
MIND
1.2 / 0.1
With respect to the QoS contract validation and the negotiation processes, the following additional
features are proposed for SDPng/E2ENP:
o
An important part of the implementation is the use of modularity for the elements by applying SDPng
and extensions of it.
o
Compared to the existing SDPng proposal, it is assumed that it is better to distinguish codec
definitions from the RTP payload type definitions and codec parameterisation [SDPNG03],
[SDPNG04], [RTP-Prof]. The negotiating peers would then be able to quickly converge on
agreements, by pruning first all the codecs that are not supported by all peers. Once the commonly
agreed set of codecs has been identified, the negotiating parties can handle the negotiation of payload
types and codec parametrizations. This would result in a new element of SDPng having two separate
elements – one for capabilities description and one for stream level valid QoS contracts
o
For the description of the QoS contracts it is necessary to have an SDPng element for mapping the
Application Level QoS descriptions on the codecs and the payload types. A single QoS contract is in
these terms the QoS settings of a single media stream.
o
It is necessary to distinguish between the different streams (audio, video) and data types (data,
control) by the definition of the contracts for a communication session.
o
Considering the video codecs, the parametrization indicated in [RTP-Prof] is not sufficient to fully
characterize the given codec from a QoS perspective. That is why it is necessary to introduce codec
parametrization attributes like frame-rate, frame-size, colour-quality-range, overall-quality-range, etc.
which should be uniquely interpreted by the end-systems.
o
It is necessary to introduce descriptions and parametrizations for non-streaming data.
o
With respect to the negotiation process it is necessary to introduce an attribute for the QoS contract
indicating if the contract is currently applicable or not applicable and if the contract could be
supported in the near future by changing local system conditions and for the time being of the
running communication. The same attribute can also be used to indicate the support of a given codec.
o
Considering the network validation process it is necessary to introduce an element for the contracts
showing if the QoS contract is respectively blocked or unblocked from a given provider and
eventually carrying a signature of the respective provider to let the network (intermediate
components) verify but not change the contracts.
o
For the means of the common vocabulary it is necessary to introduce an SDPng/E2ENP element
describing the system internal QoS optimisation policy in order to let the communication parties have
additional knowledge on the common adaptation process by running session.
o
For the means of the common vocabulary it is necessary:
a.
To introduce an element describing the system internal QoS optimisation policy in order to
let the communication parties have additional knowledge on the common adaptation process
by a running session.
b.
To introduce elements within the contract for the means of network optimisation. It is
suggested to use common elements to those presented in [Bos02] for the description of the
traffic information. The sender would add this element to a negotiated contract to inform the
receiver on how to reserve network resources. It is the sender that can calculate this
information upon the knowledge of a codec performance and the eventual different layers of
compression that some codecs support. Additionally, the receiver can also add traffic
information to the negotiated contract. In this case the meaning of this information is the
restriction of the service provider on the usage of his/her networks and/or the
technologically possible limit of the access network of the receiver. This is statistical
information which can be retrieved from the service-provider/technology policy applied to
the receiving peer. The sender can then calculate the traffic for the receiver and determine if
the provider/technology policy of the receiver can be covered or not.
Page A.208
MIND
1.2 / 0.1
o
For defining stream grouping it is necessary to introduce specific SDPng/E2ENP elements with
respect to group formation (correlation of the streams) and synchronization aspects.
o
For defining Adaptation Paths it is necessary to introduce specific SDPng/E2ENP elements in order
to formally describe the respective adaptation process in accordance with possible QoS changes
and/or violations.
The following SIP features for implementing the E2ENP processes have been identified:
•
Signalling for carrying out the negotiation and re-negotiation
•
Means for applying the economy principle
•
Enforcing consistency and avoiding deadlocks
Additionally the E2ENP SHOULD be explicitly mentioned by name in the SIP-messages, in order to
avoid the interference of the intermediate components (SIP Proxies) in the E2ENP-sessions. This can be
made in accordance with the definition of the SIP “Subject”-header and the “Content-Type”-Header
[RFC2543], [SIPBIS09] and [RFC3261].
Page A.209
MIND
1.2 / 0.1
A.7. Proposed Implementation of the E2ENP
This section presents possible ways of implementing the proposed solution, by leveraging existing
protocols like SIP and SDPng.
To this extent, the SIP protocol will be used in novel modes but will remain substantially unchanged;
whereas extensions and some changes of the SDPng specification are hereby proposed so as to meet the
requirements set forth in Section A.4. The functionality of E2ENP using SDPng and SIP is shown in
Figure A.10 below.
Figure A.10: Applying E2ENP over SIP
The idea is to extend the usage of SIP and to enhance the SDPng specification (which is currently being
studied within the IETF MMUSIC WG) to include E2ENP requirements, with minimal and modular
changes. This is not yet a full-fledged specification, rather a detailed explanation of the hereby-proposed
idea, aiming to raise interest and stir discussion within the technical community.
The E2ENP Agent simply carries out all the E2ENP signalling procedures: therefore it is up to the
Adaptive Application (or middleware) to enforce the model being negotiated with the E2ENP, and to
enforce resource reservation/release, based on the synchronization signalling handled by the E2ENP
Agent.
Hereby both application level and transport level QoS parameters are considered as two orthogonal issues
of the quality of service. The exact mapping between those two dimensions is carried out by the
application/QoS Broker within the process of QoS supply by monitoring the available system resources
(both local and remote) and applying different system policies (technological, provider, etc.). The
importance of utilizing both application level and transport level QoS in parallel is discussed with respect
to the controls which E2ENP performs for fluently synchronising the resource management process at all
abstraction levels of QoS delivery.
Page A.210
MIND
1.2 / 0.1
A.7.1 User-Level QoS and Application-Level QoS Specification
Users are typically interested in defining what information they want to exchange with peers and with
which quality30, independently of how their requests will be actually carried out by their terminal devices
and the network.
Therefore we expect that users will express their wishes by detailing content description and QoS
contracts. We name this type of QoS specification as User-Level QoS Specification.
Furthermore, we expect that users may want to define a set of QoS contracts as associated with a set of
multiple different contents and/or services.
To this extent, we expect that users will be willing to either specify these QoS contracts on the fly or,
more advantageously, predefine and stored them in so-called user profile information databases.
Applications or middleware will translate the User-Level QoS Specification into Application-Level QoS
Specification, which we hereby consider as input for the E2ENP31. This information can also be pretranslated to save time for the negotiation process.
The following XML document is an example of how application-level QoS contracts can be specified: in
this example, only QoS contracts for audio and video streams are indicated, but the extension to include
other types of streams (like data or control streams) is straightforward. For each type of stream, a set of
application-level QoS parameters are specified in terms of nominal values, nominal sets, or operative
ranges.
The parameters indicated in the QoS contracts for audio streams reflect the audio codec parameters
indicated in [RTP-Prof], with the difference that user profile information will describe ranges rather than
fixed configurations of those parameters. On the other hand, the parameters indicated in the QoS contracts
for audio streams do not reflect the [RTP-Prof] prescriptions; rather, QoS parameters suggested in
[BRAIN] are used.
<profile name="my-preferred-stream-level-QoS-contracts">
<e2enp:contract name="my-audio-contract-1" type=”audio”
sampling_rate_set="4000,8000" channel_set="1"/>
<e2enp:contract name="my-audio-contract-2" type=”audio”
sampling_rate_range="8000,12000" channel_set="1,2"/>
<e2enp:contract name="my-audio-contract-3" type=”audio”
sampling_rate_range="12000,16000" channel_set="1"/>
<e2enp:contract name="my-audio-contract-4" type=”audio”
sampling_rate_range="16000,44100" channel_set="1"/>
<e2enp:contract name="my-video-contract-1" type=”video”
frame_rate_range="10,15" frame_size_set="CIF"
color_quality_range="9100,9700" overall_quality_range="9500,9800" />
<e2enp:contract name="my-video-contract-2" type=”video”
frame_rate_range="15,20" frame_size_set="QCIF,CIF"
color_quality_range="9700,9850" overall_quality_range="9800,9900"/>
30
Especially if they will have to pay not only for the content but also for QoS.
31
We are in fact interested in specifying QoS as the user perceives it [BOS]. We do not care, how the user expresses
this. Clearly, there needs to be a mapping from the users preferences to a set of QoS parameters, which define the
quality of the end-to-end transmission process. We call this set of parameters the application level QoS. This
mapping is application specific and out of scope.
Page A.211
MIND
1.2 / 0.1
<e2enp:contract name="my-video-contract-3" type=”video”
frame_rate_range="20,25" frame_size_set="QCIF"
color_quality_range="9850,9900" overall_quality_range="9900,9960"/>
<e2enp:contract name="my-video-contract-4" type=”video”
frame_rate_range="25,30" frame_size_set="CIF"
color_quality_range="9900,9970" overall_quality_range="9960,9990"/>
</profile>
XML Example A. 1
In user profiles, users may specify QoS with different levels of granularities: specific target values or
operative ranges, either as discrete sets or as continuous intervals.
The frame_size_set indicates the size of the represented frames. It can be both specified as a
standard frame-size (CIF, QCIF, SIF, etc.) or a width-height resolution in pixel (e.g. 352x288).
The frame_rate_set denotes an interval for specifying target frame rate of the peers. For example, if
the frame rate is set to 20 fps, the sender should be able to compress, packetise and send 20 frames per
second. The receiver should be able to decode and render 20 fps. Additional information on the video
codecs mapping with respect to the frame size can be found in [WP-Cod].
The color_quality_range and the overall_quality_range indicate a range of possible
levels of compression for a single frame which may be available for a given codec. The higher the
produced compression of the video data, the lower is the quality. The [RFC2327] suggest expressing the
quality with numbers between 0(lowest quality) and 10(highest quality), indicating that this should be the
quality of a single frame. However, this resolution is quite small considering that the existing codecs and
the codecs to be developed in the future may have more than 10 compression levels. The so defined range
[RFC2327] does not fulfil the requirements from Section A.4.5.4, therefore the proposal for a broader
quality range between 0 and 10000, where 0 is the lowest quality and 10000 the highest. This range
should be applied to both the color_quality_range and the overall_quality_range. Since
the quality of the chrominance planes of a single frame are not relevant for every codec the
color_quality_range should be considered optional.
A.7.2 Transport level QoS Specification
Transport level QoS parameters are related to resource management level in the protocol stack, for
controlling access to network resources (typically using a signalling protocol like RSVP). This section
analyses the necessary information important for enabling service domain entities to validate
transport/network resources for multimedia streams (or even reserve them according to the scenarios in
Chapter 4). Note, that a separation of application level QoS and transport level QoS is required due to the
following observation, i.e. the same degree of application level QoS can be achieved by different levels of
transport level QoS by changing the codec. For example, the same audio quality can be delivered using
PCM codec at 44,1 kHz, 16 bit, stereo resulting in a data rate of 172 kbps or using MPEG Layer 3 audio
codec which results in 19 kbps. However, significantly more terminal resources are required when using
MPEG layer 3 audio codec. For video, the situations is even more complex. Also, a given transport level
QoS can be mapped to many different application level QoS parameters. This also depends on the codec
used and even, for video, on the complexity of the source material (i.e. video streams incorporating
multiple flows). Therefore, it is only the sending host that can derive a proper transport layer QoS from a
application layer QoS description for video together with the codec to be used.
Two types of QoS parameter sets are required, one that describes the amount of traffic that is going to be
injected in the network (Traffic Information or TI, according to [Bos02]) and one set that describes the
treatment that the packets receive from the network (Sensitivity Information or SI, according to [Bos02]).
In contrast to [Bos02], where a codec corresponds to one TI level, we have to support multiple TI per
codec. Also, one TI level supports multiple codecs. In our terms, only the combination (codec, application
layer QoS) results in a single TI parameter set. The end-system should be able to specify per media
stream and per <codec, application QoS, TI>-combination an ordered set of acceptable SI QoS levels. Per
Page A.212
MIND
1.2 / 0.1
<codec, application QoS, TI> a list of SI levels is possible. Similar of [Bos02], the end-system may
propose an ordered list of preferred SI values per TI. However, we both associate tags with TI and SI to
later reference them in different phases of negotiations. The TI and SI parameter are specified by prenegotiation separately from the <codec, application QoS> mappings, since only at the beginning of a
media session (i.e. negotiation) it is possible to estimate the available resources (both local and network)
for associating the traffic information with the application level QoS information.
A.7.2.1
The Traffic Information – TI
The Traffic Information (TI) parameter sets (compare to [Bos02]) identifies the amount of traffic that the
application is injecting for the given multimedia stream into the network. The following parameters are
characterizing TI:
•
peak bit rate (pbr)
•
sustainable bit rate (sbr)
•
maximum packet size (mps)
•
maximum burst size (mbs)
•
QoS type (qtp). – The QoS type defines the type of service that the application requires, for
example GUARANTEED_SERVICE, CONTROLLED_LOAD or BEST_EFFORT
This information is enough to provide intermediate entities (e.g. enhanced SIP proxies) knowledge about
the amount of network resources required by the multimedia data flow and the tightness of QoS guarantee
to apply. If the end-system details this requirements in the session setup message, there is no need for
service domain control entities to derive these parameters from codec descriptions (which is very hard for
real-time video).
A.7.2.2
The Sensitivity Information – SI
The Sensitivity Information (SI) parameter (compare to [Bos02]) identifies the expected treatment that the
network should provide to all packets that belong to a flow with a given TI. The following parameters are
characterizing SI:
•
maximum end-to-end delay in ms (me2ed)
•
maximum end-to-end delay variation (me2edv)
•
maximum packet loss ratio (mplr)
A given combination of (TI, SI) uniquely identifies the transport layer QoS on an end-to-end basis. It can
also be used as an input for signalling protocols like RSVP. Also, proper DiffServ code-points could be
derived from a given (TI,SI) combination. In addition, similar formats like the one in [Bos02] can be
defined. This is for future study.
A.7.3 E2ENP as SDPng extension
This section describes an SDPng extension proposal32 taking into account the requirements set forth in
Section A.4.
32
For the sake of simplicity and readability, in this document we follow the convention of indicating characters like
“&” as is, instead of the escaped version (i.e. “&amp;” for “&”) mandated by the XML standard.
Page A.213
MIND
1.2 / 0.1
The goal is to define modular extensions to SDPng. This can be achieved by introducing a set of new
elements within the new namespace "e2enp". The new elements can be defined either as part of a new
version of SDPng, or in a separate SDPng profile named E2ENP, containing the corresponding XML
schema [XMLSC]. Such a new E2ENP profile would thus feature a header like the following:
<xml:schema targetNamespace="http://www.iana.org/sdpng/e2enp"
xmlns:e2enp="http://www.iana.org/sdpng/e2enp"
xmlns:sdpng:"http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="http:www.iana.org/sdpng" schemalocation="sdpng.sd"/>
XML Example A. 2
In any case, some changes to the current SDPng proposal - including the Audio Codec and RTP profiles defined in [SDPNG03], [SDPNG04] and [SDPNG05] are hereby proposed. If accepted, these changes
would therefore affect the original SDPng (and Audio Codec and RTP profiles) XML schema.
The decision whether to move to a new version of SDPng or to define an extension thereof is left for
discussion.
The new namespace "e2enp" shall be indicated in the root element of the SDPng document (i.e. the
<desc> element).
Additional reasons for assigning attributes to the root element of SDPng is the desiderata that SDPng
[SDPNG04], [MMUS_53] should work with several different protocols, support security, be simple and
effective, etc. Over the attributes of the root element it would be possible to define a general header of the
protocol for indication of different SDPng profiles corresponding the needs of the SDPng carrier and the
purpose of this carrier. This separation of the SDPng description purpose in the header can result in
effective processing over customized parsers understanding different SDPng dialects that correspond
different processing purposes, like e.g. negotiation of capabilities, negotiation of QoS in network terms,
negotiation of QoS in application level terms, a combination there of, etc. Additionally such profile
definitions would enable the generation of compact SDPng messages respective the profile needs and
would help the unique differentiation of common elements belonging to different profiles.
Some of the carrier protocols like e.g. MEGACO [MEGACO] do not indicate the type of the carried
content, due to this reason the indication of SDPng profile within a header would help that also such
protocols may perform unmistakably with different attachments.
Since security is a general task within SDPng the elements belonging to security can also be assigned to a
general SDPng header.
Additional problem by both SDPng and E2ENP is how to de-reference XML-Object descriptions which
belong to one and the same or to many different documents. XML has a simple referencing mechanism
for referencing complete XML elements by their name. The problem with this referencing occurs in cases
when not the complete XML element, but only parts of it should be referenced. One bigger problem is the
de-referencing of objects within different documents. There is an XML recommendation [XLINK] for
linking different documents in one, but there is still no existing parser implementing this
recommendation. Additionally, XLink allows two parallel interpretations, namely:
•
Linking of the multiple XML documents into one document and post-processing it to a custom
object (Java, C++, etc.)
•
Pre-processing every XML document separately and generating an aggregated custom object
afterwards.
Page A.214
MIND
1.2 / 0.1
Furthermore an XML processing agent can as well use only well-formed XML messages and implement
by itself the validation logic or the validation logic can be directly implemented within the multimedia
application / QoS broker. The advantage in this case is that the application / Broker can directly work
with its custom objects and use different external representation agents (e.g. XML, SDP, SDPng) by
exploiting the same information contents for different purposes (e.g. negotiation, policy management,
reservation, etc.). In this case there would be only a simple XML Schema definition which is specific for
a certain message type, i.e. only single documents (messages) would be proved for validity without dereferencing at XML level (This corresponds the second XLink implementation possibility).
Due to listed above referencing problems and the still unstable state of the SDPng draft we currently do
not introduce E2ENP XML-specific schema but only well-formed XML examples. The further
convergence of SDPng and E2ENP might as well lead to some schema definition changes and is a topic
of further studies and discussions.
A.7.3.1
Overview
First of all, this proposal introduces the use of a new element <e2enp:purpose>, in order uniquely
identify the E2ENP content as associated with specific E2ENP phases, according to the requirements set
forth in Section A.4. Since the E2ENP information is meant to be piggybacked via SIP standard methods,
this approach allows extending the usage possibilities of SIP, by defining an E2ENP SDPng-based metaprotocol, without changing SIP semantics and grammar.
Furthermore, in order to enforce the E2ENP features, this proposal:
•
defines other two new elements, <e2enp:qosdef> and <e2enp:qoscfg>
•
allows the various resulting sections to be independently delivered by SIP (or other signalling
session protocols) via piggybacking, at different times and via different methods, according to
the various E2ENP phases.
This proposal introduces small changes to the SDPng <cfg> element, and provides detailed guidelines
how the information contained in that element should be linked to the other new elements.
This proposal revises also the SDPng <constraints> element semantics, since the
<e2enp:qoscfg> element, which allows specifying QoS correlation and time synchronization
constraints (according to the model proposed in Section A.6.3), already covers most of the corresponding
features.
This proposal thus attempts to define as much as possible modular extensions of SDPng, so as to allow
easy interoperability with applications not supporting said extensions.
A.7.3.2
The <e2enp:purpose> element
SIP is defined as a signalling session protocol for establishing communication between peers. It considers
in general only the initiation of the connection, leaving aside the usage and/or application-specific
features. These features are described with the means of SDP or SDPng.
In some cases it is necessary for the application to have some additional information about how to treat
the SDP/SDPng information delivered over SIP, especially considering that from application perspective,
the protocol runs as in a modular way33.
33
“The modular way” does not always fulfil the ACID (atomicity, consistency, isolation, durability)-characteristics of
transactions, which is why this SIP procedure should NOT be in general considered a transaction.
Page A.215
MIND
1.2 / 0.1
Since the E2ENP requires three different information exchanges among peers (namely, the End-to-End
QoS Pre-negotiation, End-to-End QoS Negotiation, and End-to-End QoS Re-negotiation phases), it is
necessary to differentiate inside the protocol the corresponding procedures.
E2ENP can explicitly carry the signalling about the type of phase, the start/stop of the given phase, and/or
the resource reservation status, independently of SIP (or whatever signalling session protocol is used for
piggybacking E2ENP information). To this extent, we hereby define a SDPng-based meta-protocol, by
introducing a new XML elements, to be present in all the E2ENP-related SDPng information, at the very
beginning of the E2ENP content, as a form of PDU header. This new element is a different form of a
header compared to the SDPng general header discussed above (Section A.7.2) and serves only the
differentiation of the E2ENP phases and the possibility to reference those.
The following example shows a possible instantiation of the <e2enp:purpose> element:
<?xml version='1.0' encoding='utf-8'?>
<desc xmlns="http://www.iana.org/sdpng"
xmlns:e2enp="http://www.mind.org/e2enp" >
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="36000"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841001" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="request" name="pre-negotiation"
mode="push"/>
<e2enp:caching cache_results="true"/>
</e2enp:purpose>
<!-- the rest of the message code here -->
</desc>
XML Example A. 3
For simplicity reasons the framing <desc> element is omitted in the all following XML examples.
A.7.3.2.1
The <e2enp:session> element
The <e2enp:session> element uniquely identifies the given E2ENP phase described in the
remaining portion of E2ENP PDU content, and the final results of such phase. The definition of the
<e2enp:session> element is based on the <owner> element proposed in [SDPNG03], [SDPNG04].
It is envisioned to negotiate and use compact session identifiers derived (e.g. via hash) from the
<e2enp:session>, in order to limit the size of E2ENP PDUs: in such a case, the
<e2enp:session> (with the calculated hash) would be used as is in the first PDU of any given
E2ENP phase, or concatenation thereof; afterwards, only the hashed version would be then used.
Page A.216
MIND
1.2 / 0.1
Additionally, it is envisioned to use digests within the <e2enp:session> element for uniquely
identifying every E2ENP session, for more information see Section A.9.
One may notice that this element might be more precisely renamed as <e2enp:phase>, since it
describes an individual E2ENP phase. However, one SIP session may exchange multiple phases, e.g. in
case of push-pull negotiation mode. Therefore there is no one-to-one correspondence between E2ENP
phase and <e2enp:session> element. When multiple contiguous phases are coalesced into one SIP
session, the <e2enp:purpose> element indicates the last one of a series of contiguous phases.
Therefore the E2ENP phase indicated in the <e2enp:session> element of any given
<e2enp:purpose> element is the last one compared to the E2ENP phase sequence.
A.7.3.2.1.1
The <e2enp:expires> child element
The <e2enp:expires> child element indicates for how long the E2ENP information corresponding to
the given <e2enp:session> element is to be considered as valid.
Upon response to the Offerer, each Answerer shall start a timer, set to the value specified in the
<e2enp:expires> element. Should this timer expire, the Answerer should move the corresponding
E2ENP information in a "zombie" state.
In turn, the Offerer shall refresh the given E2ENP information before said timer expires.
Only when no media or signalling sessions referring to that E2ENP information exists anymore, can the
Offerer and/or Answerer silently discard the "zombie" information.
This rationale applies also to the case of other E2ENP information referring to the given obsolete E2ENP
information (see next paragraph): as long as any valid (i.e. not in a "zombie" state) E2ENP information
referring to the given "zombie" one exists, the Offerer and/or Answerer can not silently discard said
"zombie" E2ENP information.
A.7.3.2.2
The <e2enp:use> element
The E2ENP information, which the <e2enp:session> element refers to, can be used in other
instances of E2ENP content, in order to refer to items not defined in the given E2ENP content. The
E2ENP Agent assumes that the correct reference resolution is carried out by the application/ middleware
using the E2ENP services. To this extent, the name of the referenced item could be either completely
specified (thus indicating the <e2enp:session> element pointing to the results of the corresponding
previous E2ENP phase), or not completely specified. In the latter case, the application/middleware or the
XML parser might be designed so as to search any unresolved item within the results of previous phases.
The <e2enp:use> element, allows creating a list of references to known pre-existing instances of the
<e2enp:session> element. Therefore the <e2enp:use> element can be used for:
•
Allowing peers agreeing on which previous E2ENP Phase results to enforce in the given E2ENP
Phase
•
Allowing application/middleware or the XML parser searching any unresolved item in the saved
results of the previous E2ENP Phases uniquely identified by the <e2enp:use> element.
•
Keeping track of active sessions.
For instance, the E2ENP content describing an instance of the End-to-End QoS Negotiation Phase for a
given couple of peers shall reference information pre-negotiated ahead, by indicating in the
<e2enp:use> construct of the <e2enp:purpose> element, the unique <e2enp:session>
element of that pre-negotiated information. This referencing would be of course not necessary (and thus
the <e2enp:use> element would be not present), should the E2ENP content - relative to both phases be jointly piggybacked in one SIP message (i.e. case of phases carried out consecutively in time).
Page A.217
MIND
1.2 / 0.1
A.7.3.2.2.1
The use of the <e2enp:expires> child element
The presence of the <e2enp:expires> child element in the listed <e2enp:session> elements is
not mandatory. If present, though, the meaning would slightly differ from the normal use of the
<e2enp:expires> child element: its presence would in fact signify for how long the given referenced
<e2enp:session> element should be considered as valid (i.e. rest time of validity of the E2ENPsession), from the perspective of the <e2enp:session> element referencing it. Of course, a given
<e2enp:session> element may reference others for a time window no longer than the original value
of the time specific in of the <e2enp:expires> child element of the referenced sessions.
A.7.3.2.3
The <e2enp:description> element
The <e2enp:description> element indicates the nature of the E2ENP information, the given
<e2enp:purpose> element refers to. The "type", "name", and "mode" attributes of the
<e2enp:description> element are defined as follows:
type:=”request” | ”response”
The "type" attribute identifies who is the Offerer and who is the Answerer of a given E2ENP phase.
name:=”standard” | ”pre-negotiation”| ”negotiation” |
”re-negotiation”| ”start-reservation” | ”ready-reservation”|
”cancel-reservation” | ”cancelled-reservation” | ”expire” |
"taken-over"
The "name" attribute defines the type of E2ENP phase, whose description is contained in the remaining
part of the E2ENP content:
• “standard” – standard use of the SIP message piggybacking this E2ENP content, according to
[SIPBIS09], [RFC3261].
• ”pre-negotiation” – the SIP message piggybacking this E2ENP content is used for carrying
out the End-to-End QoS Pre-Negotiation Phase.
• ”negotiation” – the SIP message piggybacking this E2ENP content is used for carrying out the
End-to-End QoS Negotiation Phase.
• ”re-negotiation” – the SIP message piggybacking this E2ENP content is used for carrying out
the End-to-End QoS Re-Negotiation Phase
• ”start-reservation” – the SIP message piggybacking this E2ENP content is used for
signalling the start of a reservation process (during either an End-to-End QoS Negotiation Phase or an
End-to-End QoS Re-negotiation Phase).
• ”ready-reservation” – the SIP message piggybacking this E2ENP content is used for
signalling the completion of a reservation process (during either an End-to-End QoS Negotiation Phase or
an End-to-End QoS Re-negotiation Phase).
• ”cancel-reservation” – the SIP message piggybacking this E2ENP content is used for
signalling the request to release previously reserved resources.
• ”reservation-reservation” – the SIP message piggybacking this E2ENP content is used
for confirming the release of previously reserved resources.
Page A.218
MIND
1.2 / 0.1
• ”expire” – the SIP message piggybacking this E2ENP is used for forcing the expiration of the
E2ENP information identified by the given <e2enp:session> element. Contextually, the attribute
time of the <e2enp:expires> child element of the given <e2enp:session> element shall be set
to zero. When this command is used, the E2ENP contents referencing the given <e2enp:session>
element are forced to be released according to the rationale described in Section A.7.3.2.1.1.
• ”taken-over” – this command is used by the Mediator in third-party-assisted negotiations (see
Section A.4.5.7) for notifying to the peer, whom the negotiation is being redirect to, that such redirection
is taking place.
Should some phase concatenated, the "name" attribute would indicate only the latest phase (according to
the order described in Section A.6.2).
Other definitions of the "name" element could be considered in the future.
mode:=”push” | ”pull” | ”push-pull”
The "mode" attribute indicates the negotiation mode, as described in Section A.3.2. This attribute
applies only the attribute "name" is set to "pre-negotiation" or "negotiation".
The defaults values for the "type", "name", and "mode" elements are, respectively, "request",
"standard", and "push".
Additionally the <e2enp:description> element is used to indicate if the reservation process should
be coordinated at all participating peers or not.
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
<e2enp:description type="request" name="start-reservation"
coordination=”true”/>
</e2enp:purpose>
XML Example A. 4
The attribute “coordination” is the indicator for performing the coordination process, it can take
only two values “true” (if it coordination is required) and “false” (if not), see also Section
A.8.1.1.2.1.3
A.7.3.2.4
The <e2enp:caching> element
The <e2enp:caching> element is used to instruct the E2ENP user agent and the QoS aware
application / QoS Broker if the given PDU should be cached or not by processing of the PDUs leasing.
This is necessary if the negotiation/re-negotiation PDUs should be cashed (pre-negotiations are always
cashed). The attribute “cache_results” is the indicator for the cache processing. The negotiation/renegotiation PDUs might be cached in cases of full negotiation/re-negotiation, since those PDUs might
carry information which can be treated as pre-negotiation contents. Additionally, if the multimedia
session description should be considered relative static (i.e. typical negotiation PDU), it can also be long
term saved, e.g. the settings of some chat-room conference environment can be long term leased to save
time by performing multiparty negotiations.
A.7.3.2.5
The <e2enp:mediation> element
The <e2enp:mediation> parameter is optional and can take any of the following values:
Page A.219
MIND
1.2 / 0.1
mediation:=”third-party-assisted" | "external-negotiation”
If it is not applied, the type of the negotiation is simply peer-to-peer. This parameter is used to indicate
that a peer is negotiating on behalf of somebody else. This would be also implicitly indicated over the
header “From” of the SIP message and the element <e2enp:session> of the <e2enp:purpose>
element. The peers negotiating on behalf of somebody else should be generally considered services like
mediating parts of a broker, conferencing services, etc. The mediator uses the parameter
<e2enp:mediation> in order to inform the negotiating parties that it is not the party which is going
to send and/or receive but just a party mediating the negotiation. In this case the mediator should use as
indication of its functionality ”third-party-assisted".
Whenever logging into a network operator (at switch-on time and whenever a vertical handover occurs),
the network operator will validate the user's QoS preferences (already matched against terminal
capabilities) against the network capabilities. However, at this time it is not yet possible to foresee if and
when cases occur whereby two end-peers do not have a chance to agree on a common set of QoS
Contracts whatsoever. In such cases, a solution typically adopted is to insert transcoding units along the
data path.
The possibility to couple such units with SIP proxies and directory services is envisioned, so as to force
the Offerer to use a specific transcoder, or a chain thereof. Whenever the E2ENP session between the two
end peers fails, the Offerer could try to ask support from the network operator or any other service
provider, to provide transcoding services. This means to discover via a directory service any available
transcoder unit(s), meeting the Offerer's given requirements and Answerer's capabilities, and manage
third-party negotiation among the Offerer, the various transcoders in the middle, and the Answerer. The
transcoding service would therefore use the E2ENP analogously to what MEGACO [MEGACO] today
does.
The Transcoding Service would orchestrate the pairing of nodes in the chain of peers, and take care that
resources are properly reserved via the E2ENP economy principle (Similar consideration for resource
release). Should the connection between the two end users span multiple administrative domains and/or
technologies, it may also be possible that transcoding services offered by different providers cooperate,
again by using E2ENP for performing third-party-negotiation. To this extent “externalnegotiation” describes the case whereby the mediator acts as an external third-party, on behalf of an
entity trying to force two peers carry out the E2ENP between themselves. The Transcoding Service
indicated above would control one or multiple such "external mediators" in tandem.
The idea of an external functionality controlling the establishment of a path among several processing
units is well-known in the literature [Mao00]. The goal of the solution hereby proposed is thus to allow
extending the scope of E2ENP protocol to complex cases, whereby intermediate components like
transcoders are required.
The <e2enp:mediation> element might undergo future development with respect to additional
values different from the described above. If active participation of the Mediator in the data streaming
should be considered or if more than one mediation components should take place in the negotiation, e.g.
involvement of Conference Control Units, QoS Broker, etc., this would be indicated via the
<e2enp:mediation> element.
The following example corresponds to the starting message of a SIP session within the E2ENP-session
between the Mediator and the future Answerer:
INVITE sip:mary_fix@195.37.78.173
From: sip:mary_moby@3ffe:1200:3012:c006:290:27ff:fe7d:d024
To: sip:mary_fix@195.37.78.173
.
.
.
.
.
Page A.220
MIND
1.2 / 0.1
Content-Type: application/sdpng/e2enp
.
.
.
.
.
<e2enp:purpose>
<e2enp:session user=”Kate” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
<e2enp:description type="request" name="negotiation"/>
<e2enp:mediation mode=”third-party-assisted”/>
</e2enp:purpose>
XML Example A. 5
According to this example the peer “mary_fix@195.37.78.173” would recognize that the peer
“mary_moby@3ffe:1200:3012:c006:290:27ff:fe7d:d024” is just a Mediator for the peer “43.196.180.1”
whose owner is “Kate”.
A.7.3.3
The <e2enp:alternative_service> element
The SIP-response “300 Multiple Choices ”[RFC2543] might be used for redirecting a connection to
another alternative device if the called peer has no capabilities to handle the call, but may take advantage
of using some allocation and presence services to detect another peer within its vicinity which can handle
the call. The process of allocation of devices and services is out of scope of this writing, but in general
existing technologies like Bluetooth [BLUE] and the SIP support for presence [SIPPRE01] might be
taken into consideration.
According to [SIPBIS09], [RFC3261] “The response (300 Multiple Choices) MAY include a message
body containing a list of resource characteristics and location(s) from which the user or UA can choose
the one most appropriate.” A possible E2ENP structure describing the address and the reference to the
profile settings of an alternative service promoted over a mediator is shown below:
<e2enp:alternative_service type=[TYPE]>
<e2enp:service>
<e2enp:service_id id="my-funny-service" protocol="SIP"
version=[SIP VERSION] address=[SIP ADDRESS]/>
<e2enp:session user="Mary" session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="195.37.78.173"/>
</e2enp:service>
</e2enp:alternative_service>
XML Example A. 6
where
SIP_ADDRESS – corresponds the formation of SIP-conform addresses as defined in [RFC2543].
SIP_VERSION – corresponds the SIP-conform version syntax of SIP as defined in [RFC2543].
The element <e2enp:service> is used to describe the alternative service and to refer to already
known or to carried within this E2ENP-message session-descriptions. This multiple carried descriptions
start with a <e2enp:purpose> element. The element <e2enp:service> can be repeated.
Page A.221
MIND
1.2 / 0.1
In the case of mediation the multiple <e2enp:service> elements can have the same
<e2enp:service_id> but address different session descriptions since the Mediator should both
inform the Offerer and the future Answerer about the corresponding negotiations which the Mediator
performs on one hand with the Offerer and on the other hand with the future Answerer without addressing
unknown information as described in the requirements for the Mediator – see Section A.4.5.7.
If the usage is standard according to [SIPBIS09], [RFC3261] the multiple <e2enp:service> elements
describes multiple alternative services.
The current description of the element <e2enp:alternative_service> is only in sense of E2ENP
and mediated negotiation. Additional description of the usage of <e2enp:alternative_service>
in the sense as defined by [SIPBIS09], [RFC3261] would be considered in the future when SIP-enabled
services are taken into account.
A.7.3.3.1
An example for the usage of the <e2enp:alternative_service> element
<e2enp:purpose>
<e2enp:session user="Mary" session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="195.37.78.173"/>
<e2enp:mediation mode="third-party-assisted"/>
</e2enp:purpose>
<e2enp:alternative_service type=”mediation”>
<e2enp:service>
<e2enp:service_id id="my-funny-service" protocol="SIP"
version="SIP/2.0" address="sip:mary_fix@195.37.78.173"/>
<e2enp:session user="Mary" session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="195.37.78.173"/>
</e2enp:service>
</e2enp:alternative_service>
XML Example A. 7
According to the requirements for the Mediator, it is disallowed to use references to unknown sessions.
That is why by implementing a mediator the <e2enp:use> element of a <e2enp:purpose> element
within a referred session from a <e2enp:service> element should be omitted as in the example
above. The mediator should then take care of collecting all the referred information and put it explicitly
(no references) in the current description/-s.
By performing a direct negotiation between themselves at later time the Offerer and the Answerer address
if necessary sessions of the indirect pre-negotiation over the Mediator.
Figure A.11 shows an example of the usage of the <e2enp:alternative_service> element.
Page A.222
MIND
1.2 / 0.1
Figure A.11: Usage of the <e2enp:alternative_service>
The indication of the sip-address and sip-version in the third message within the
<e2enp:service_id> element (Figure A.11) can directly be used by the Offerer (Kate’s device) to
create the new SIP call to the new Answerer (Mary’s home terminal). This information is necessary
especially in cases when the Offerer does not know about the device where the call is being redirected.
A.7.3.4
Information that users pre-negotiate among themselves on a peer-to-peer basis
Compared to the existing SDPng proposal [SDPNG03], [SDPNG04], we hereby propose to distinguish
codec definitions from RTP payload type definitions and codec parameterisation34. This results in the
definition of a new element, and the redefinition of the Audio Codec and RTP profiles.
With this assumption, negotiating parties can quickly converge on agreements, by pruning first all the
codecs that are not supported by all peers. Once the commonly agreed set of codecs has been identified,
the negotiating parties can, as a further step, handle the negotiation of payload types and codec
parametrizations.
The definition of payload types is based on [RTP-Prof] and the RTP Profile defined in [SDPNG03],
[SDPNG04].
With respect to audio codecs, static payload types are associated with fixed codec parameterisations, as
defined in [RTP-Prof]: therefore only for dynamic payload types a detailed specification of codec
parameterisation35 is required.
Concerning video codecs, the parametrization indicated in [RTP-Prof] is not sufficient to fully
characterize the given codec from a QoS perspective. Two possible solutions are envisioned:
34
For codec parameterisation we hereby intend the list of parameters accompanying the definition of a given codec,
e.g. the sampling rate and the number of channels in the case of audio codecs.
35
To this extent, we propose to use the inline format described in [SDPNG03]
Page A.223
MIND
1.2 / 0.1
1.
To pre-negotiate the names, payload types, and (partly) parameterisations36 of codecs, ahead of
any user-specific pre-negotiation.
This means splitting the End-To-End QoS Pre-Negotiation Phase into two distinct sub-phases: in an
early stage, only pre-negotiation of terminal-related information would take place; this sub-phase
would then be followed by one (or many) user-specific pre-negotiation sub-phases37 at later times,
whereby each of these later sub-phases would map user profile information to the results of former
sub-phase.
The reason for pre-negotiating also codec parametrization in the terminal-related pre-negotiation subphase stems from the fact that the negotiating parties may want to narrow down the range of possible
configurations of video codecs, so as to meet feasibility requirements, with respect to the actual
amount of hardware/software resources of the given peers.
2.
Alternatively, to determine which subsets of the user profile match the given capabilities and the
(potential) amount of local resources, and negotiate only those subsets with peers, along with
codec names and the payload types.
Both alternatives are described with the diagram on Figure A.9. In case of negotiating of only codecs, the
“User level QoS” is non-existent and the “QoS Contracts Sketch” is equal to the “System Configuration
File”. Respectively only the system capabilities would be validated for such a case.
By following this rationale, applications can be designed in a simpler way: either they handle codec
parametrization negotiation in an early sub-phase, or they simply handle the negotiation of user-specific
QoS specification.
The codec descriptions can be assimilated to general-purpose capability descriptions that peers can prenegotiate offline among themselves. Pre-negotiated information can also refer to and/or be incorporated
into SDPng profiles [SDPNG03], [SDPNG04].
Furthermore, we introduce intervals in the original SDPng codec parameterisation, in order to reduce the
number of items to negotiate. This approach allows also defining in an intuitive manner the Adaptation
Paths, as well as avoiding ambiguities, especially with respect to video stream characterization.
A new <e2enp:qosdef> element provides means for expressing both capabilities and stream-level
QoS Contracts in a modular way:
•
an instance of <e2enp:qosdef> element qualified with the attribute "name" set to
"capabilities" describes only the terminal-related information concerning capabilities;
whereas
•
an instance of <e2enp:qosdef> element qualified with the attribute "name" set to
"contracts" describes the various parameterisations of those capabilities matching the given
user profile information (see Section A.7.1), in terms of stream-level QoS Contracts.
The application and/or middleware will select the best codec out of the pre-negotiated <e2enp:qosdef
name="capabilities">, and a subset of QoS Contracts out of the given user profile information.
The resulting information (a subset of the cross-product of the <e2enp:qosdef
name="capabilities"> and of the user profile information - see A.7.1) will then form the
<e2enp:qosdef name="contracts"> element, which deals with stream-level QoS Contracts at
application level. This new element differs from the original information contained in the user profile
36
To this extent, we propose to use the inline format described in [SDPNG03]
37
Leveraging user profile information, as indicated in § A.7.1.
Page A.224
MIND
1.2 / 0.1
information, insofar as specific encoding attributes are now specified. This <e2enp:qosdef
name="contracts"> element will then be exchanged among peers during the pre-negotiation phase.
The pre-negotiation of the two types of <e2enp:qosdef> elements can take place among peers at
different times, irrespective of later actual use, and be scoped in time with different timescales, by using
the <e2enp:expires> element of the <e2enp:purpose> element associated with the given
<e2enp:qosdef> element. The limitation in time of E2ENP information validity is necessary, in order
to avoid using obsolete information at a later time.
A.7.3.4.1
The <e2enp:qosdef name="capabilities"> element
The <e2enp:qosdef name="capabilities"> element allows peers agreeing on a common
subset of capabilities to be employed during later media sessions. This element acts as a container of two
classes of elements, codec definitions and payload type definitions, applied to each type of media (audio,
video, etc.). Definitions from the original Audio Codec, RTP, and Video Codec profiles specified in
[SDPNG03], [SDPNG04] are envisioned to be used, but with some extensions, as indicated below.
<e2enp:qosdef name="capabilities">
<e2enp:audio:codec name="PCMU" scope="applicable"/>
<e2enp:audio:codec name="G729" scope="applicable"/>
<e2enp:audio:codec name="G722" scope="possible"/>
<e2enp:audio:codec name="L16" scope="possible"/>
<rtp:pt name="rtp-avp-0" pt="0" format="PCMU"/>
<rtp:pt name="rtp-avp-18" pt="18" format="G729"/>
<rtp:pt name="rtp-avp-9" pt="9" format="G722"/>
<rtp:pt name="rtp-avp-10" pt="10" format="L16"/>
<rtp:pt name="rtp-avp-11" pt="11" format="L16"/>
<e2enp:video:codec name="H263" scope="applicable"/>
<e2enp:video:codec name="H261" scope="applicable"/>
<e2enp:video:codec name="MPV" scope="possible"/>
<e2enp:video:codec name="MP2T" scope="possible"/>
<rtp:pt name="rtp-avp-34" pt="34" format="H263"/>
<rtp:pt name="rtp-avp-31" pt="31" format="H261"/>
<rtp:pt name="rtp-avp-32" pt="32" format="MPV">
<e2enp:video:codec frame_rate_range="30,30" frame_size_set="SIF"
color_quality_range="0,10000"38 overall_quality_range="0,10000"/>
</rtp:pt>
<rtp:pt name="rtp-avp-33" pt="33" format="MP2T">
<e2enp:video:codec frame_rate_range="30,30"
frame_size_set="720x576" color_quality_range="0,10000"
38
This is due to the fact that MPEG-1 supports a constant data-rate (1.2MB) by different quality.
Page A.225
MIND
1.2 / 0.1
overall_quality_range="0,10000"39
overall_quality_range="9500,9800"/>
</rtp:pt>
<rtp:pt name="rtp-avp-100" pt="100" format="WAVI">
<e2enp:video:codec frame_rate_range="5,30"
frame_size_set="QCIF,CIF" color_quality_range="9100,10000"
overall_quality_range="9100,10000"/>
</rtp:pt>
</e2enp:qosdef>
XML Example A. 8
For the sake of simplicity, this example shows the definition of video codecs both with and without codec
parametrization. Otherwise, the <e2enp:qosdef name="capabilities"> element shall either
contain codec parametrization, or contain none of them.
One can easily note that the information conveyed in this section is now equivalent to a sort of
configuration file of the user's terminal device; this information is user-independent, and thus
complementary to the content of the user profile information described in the user profile information, as
well as to the content of the <e2enp:qosdef> element (derived from said user profile information)
dealing with stream-level QoS Contracts.
A.7.3.4.1.1
The attribute "scope"
The attribute scope indicates in a request (negotiation bid) whether the corresponding E2ENP element is
to be considered as a required (applicable) or desired (possible) option; whereas in a response
(negotiation counter-offer), that attribute indicates whether the corresponding E2ENP element has been
validated (applicable) or rejected (not-applicable).
scope:="not-applicable" | "applicable" | "possible"
The Answerer may also indicate in the counter-offer what capabilities it can support, and to what extent.
If a given capability is supported "as is", only the corresponding identifier is indicated, along with the
scope attribute set to "applicable".
If a given capability is not supported, the corresponding identifier is simply omitted.
If the Answerer proposes in the counter-offer a modified version of the parameterisation of a given
capability in the <e2enp:qosdef name="capabilities"> element (as a subset of the original
bid), the entire description with the updates is returned in both types of <e2enp:qosdef> elements. In
any case, the <e2enp:qosdef> element dealing with stream-level QoS Contracts contains in a
response only updated codec parameterisations (see example in Section A.8.1.1.3.1).
Additionally, the Answerer can indicate a new option (unknown to the Offerer at pre-negotiation time):
this will be marked as "possible". The idea is that the Offerer can thus be informed of a potential
option that could be eventually used later, should the Offerer be upgraded with a new capability matching
that option.
For instance, the Answerer might indicate the support of a codec, which the Offerer currently does not
support. Should the Offerer acquire somehow that given codec (e.g. by downloading a software
component), the Offerer could then upgrade its policies to take into account this new capability.
39
This is due to the fact that MPEG-2 supports a constant data-rate (4MB) by different quality.
Page A.226
MIND
1.2 / 0.1
The value "possible" could also indicate the Answerer's state as being partially busy with respect to a
codec proposed by the Offerer. In this way, the Answerer may take into account its current working load.
This could for instance translate in an answer to the Offerer, indicating that generally the Answerer has
high capacity but that only part thereof is available at the moment. The Offerer may then save this
information for future re-negotiations whenever trying to upgrade the connection to work with a different
QoS level.
Should a capability be removed, or reconfigured at a later time, a new instance of the corresponding
<e2enp:qosdef name="capabilities"> pre-negotiation process would take place among
peers, in order to proactively and timely disseminate information about the given change, so that peers
can employ proper adaptation strategies.
Should the Answerer add a capability as "possible", the corresponding parametrization would be
returned directly in the <e2enp:qosdef name="capabilities"> element, in the element
corresponding to that new capability. In this case, the parametrization simply indicates configuration
information relative to that capability. Should the Offerer be upgraded with this extra capability at later
time, the Offerer could draw some contracts from the configuration information for running a new round
of the pre-negotiation process.
Peers can also renegotiate capabilities following the process described above at any time, in order to
inform each other about any change in capabilities availability.
A.7.3.4.2
The <e2enp:qosdef name="contracts"> element
Continuing the example above, the following XML fragment presents an example of codec
parameterisation in the new <e2enp:qosdef name="contracts"> element, as derived from a
mapping process described in the previous paragraph. This section deals with application-level QoS
Contracts, which are generally applicable to any stream of the type of media identified.
This new element contains a number of complex XML elements:
•
a mandatory <e2enp:policy> element, used for negotiating the resource management policy
to enforce;
•
at most one instance of any of the following parameterised elements:
o
<e2enp:qos_contracts for=”audio”> - describing all QoS contracts for
audio streams
o
<e2enp:qos_contracts for=”video”> - describing all QoS contracts for
video streams
o
<e2enp:qos_contracts for=”data”> - describing all QoS contracts for
data streams
o
<e2enp:qos_contracts for=”control”> - describing all QoS contracts
for controls streams
o
<e2enp:qos_contracts for=”transport”> - describing the necessary
transport resources (see Section A.7.3.4.2.1)
where such QoS Contracts are derived from the mapping of user profile information to capabilities,
as described in Section A.7.3.4. At least one of these elements shall be present. Due to simplicity
reasons only contracts for audio, video and transport are considered. The formal description of the
data and control contracts is left for future study.
<e2enp:qosdef name="contracts">
<e2enp:policy name="Let us optimize ((memory && network) || CPU)">
Page A.227
MIND
1.2 / 0.1
<e2enp:predicate id="predicate-1" first_term="optMemoryUsage"
second_term="optNetworkPerformance" function="and"/>
<e2enp:predicate id="predicate-2" first_term="predicate-1"
second_term="optCpuLoad" function="or"/>
<e2enp:criterion type="expression" idref="predicate-2"/>
</e2enp:policy>
<e2enp:qos_contracts for="audio">
<e2enp:contract name="audio-contract-1"
sampling_rate_set="4000,8000" channel_set="1"/>
<e2enp:contract name="audio-contract-2"
sampling_rate_set="8000,12000" channel_set="1,2"/>
<e2enp:contract name="audio-contract-3"
sampling_rate_set="12000,16000" channel_set="1"/>
<e2enp:contract name="audio-contract-4"
sampling_rate_set="16000,44100" channel_set="1"/>
<e2enp:contract name="audio-contract-5"
sampling_rate_set="44100,64000" channel_set="2">
<!--The contents of spare are described in A.7.3.4.2.4-->
<spare provider_id=”my-funny-provider”>
</e2enp:contract>
<rtp:map contract="audio-contract-1" format="rtp-avp-0"
peer_role="receiver"/>
<rtp:map contract="audio-contract-2" format="rtp-avp-18"
peer_role="receiver"/>
<rtp:map contract="audio-contract-3" format="rtp-avp-9"
peer_role="receiver"/>
<rtp:map contract="audio-contract-4" format="rtp-avp-10"
peer_role="receiver"/>
<rtp:map contract="audio-contract-4" format="rtp-avp-11"
peer_role="receiver"/>
<rtp:map contract="audio-contract-5" format="rtp-avp-125"
peer_role="receiver"/>
</e2enp:qos_contracts>
<e2enp:qos_contracts for=„video“>
<e2enp:contract name="video-contract-1" frame_rate_set="10,15"
frame_size_set="CIF" color_quality_range="9100,9700"
overall_quality_range="9500,9800"/>
<e2enp:contract name="video-contract-2" frame_rate_set="15,20"
frame_size_set="QCIF" color_quality_range="9700,9850"
overall_quality_range="9800,9900"/>
<e2enp:contract name="video-contract-3" frame_rate_set="20,25"
frame_size_set="QCIF,CIF" color_quality_range="9850,9900"
overall_quality_range="9900,9960"/>
<e2enp:contract name="video-contract-4" frame_rate_set="25,30"
frame_size_set="CIF" color_quality_range="9900,9970"
overall_quality_range="9960,9990"/>
Page A.228
MIND
1.2 / 0.1
<e2enp:contract name="video-contract-5" frame_rate_set="30"
frame_size_set="720x576" color_quality_range="9000,10000"
overall_quality_range="9000,10000"/>
<rtp:map nominal=”true” contract="video-contract-1" format="rtpavp-31" peer_role="receiver"/>
<rtp:map contract="video-contract-1" format="rtp-avp-34"
peer_role="receiver"/>
<rtp:map contract="video-contract-1" format="rtp-avp-100"
peer_role="receiver"/>
<rtp:map nominal=”true” contract="video-contract-2" format="rtpavp-31" peer_role="receiver"/>
<rtp:map contract="video-contract-2" format="rtp-avp-34"
peer_role="receiver"/>
<rtp:map contract="video-contract-2" format="rtp-avp-100"
peer_role="receiver"/>
<rtp:map nominal=”true” contract="video-contract-3" format="rtpavp-31" peer_role="receiver"/>
<rtp:map contract="video-contract-3" format="rtp-avp-34"
peer_role="receiver"/>
<rtp:map contract="video-contract-3" format="rtp-avp-100"
peer_role="receiver"/>
<rtp:map nominal=”true” contract="video-contract-4" format="rtpavp-31" peer_role="receiver"/>
<rtp:map contract="video-contract-4" format="rtp-avp-34"
peer_role="receiver"/>
<rtp:map contract="video-contract-4" format="rtp-avp-100"
peer_role="receiver"/>
<rtp:map contract="video-contract-5" format="rtp-avp-33"
peer_role="receiver"/>
</e2enp:qos_contracts>
</e2enp:qosdef>
XML Example A. 9
The description of the color_quality_range and of the overall_quality_range
introduced above in Section A.7.1.
is
In this case the frame_rate_set="10,15" means that the receiver should at most be able to decode
15 fps and at least 10 fps, any decoding resulting in less than 10 fps is considered as a violation of the
contract. The sender does not need to provide more than 15 fps unless a contract change, because of, for
example, the discovery more resources at the receiver side is made and a request for contract change is
done.
A single video QoS contract can correspond to multiple payload types, since different codecs can produce
one and the same visual quality. To this extent the most preferable codec to use is indicated by the
mapping between the QoS contracts and the payload types (parameter nominal=”true”). The
parameter nominal=”true” is not mandatory and is used only in cases when multiple video codecs
are associated with one and the same video QoS contract. This is later on important by indicating with
which video codec the streaming should be started (see also Section A.7.3.5.2).
Page A.229
MIND
1.2 / 0.1
A.7.3.4.2.1
TI/SI Extensions to <e2enp:qosdef name="contracts"> element
The <e2enp:qos_contracts for=”transport”> element within the <e2enp:qosdef
name="contracts"> element allows peers and service domain entities agreeing on a common level
of transport QoS employed during later media sessions. This element acts as a container of TI and SI
elements (see also Section A.7.2). Note, however the difference to the syntax introduced by [Bos02].
<e2enp:qosdef name=”contracts”>
<!--audio and video application contracts according to section
A.7.3.4.2-->
<e2enp:qos_contracts for=”transport”>
<e2enp:contract name="TI-1" pbr="320" sbr="320" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="80" me2edv="10" mplr="2E-2"/>
<suboption name="SI-2" me2ed="120" me2edv="20" mplr="2E-2"/>
<!--The contents of spare are described in A.7.3.4.2.4-->
<spare provider_id=”my-funny-provider”>
</e2enp:contract>
<e2enp:contract name="TI-2" pbr="96" sbr="96" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="80" me2edv="10" mplr="2E-2"/>
<suboption name="SI-2" me2ed="120" me2edv="20" mplr="2E-2"/>
</e2enp:contract>
<e2enp: contract name="TI-3" pbr="64" sbr="64" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="180" me2edv="10" mplr="2E-4"/>
<suboption name="SI-2" me2ed="220" me2edv="20" mplr="2E-4"/>
</e2enp:contract>
</e2enp:qos_contracts>
</e2enp:qosdef>
XML Example A. 10
Note, that this definition is on per stream basis, since the validation and reservation processes are also
performed per media stream.40 This means that every TI definition corresponds the transport parameters
of a single media stream. The information how many streams with the same transport can be opened in
parallel is delivered by the validation process of the negotiation bids/answers (see Section A.6.6 and
Section A.7.3.5.2). This information results from monitoring the local and network resources and proving
the contracts against provider policies, so that the aggregation of all streams does not exceed certain
resource amount.
For the sake of simplicity, this example shows the definition of three alternative transport QoS contracts,
each of them having two SI options. Note that only a specific sub-option (SI) together with the main
option (TI) defines a complete transport layer QoS parameter set. But for specifying a full session
description for call setup, additional information is necessary. This means that the definition of transport
40
When reserving resources for multiple streams, this can be done in parallel, since the aggregated bandwidth is
already determined by the validation process. See also the constraints description in Section A.7.3.5.2.
Page A.230
MIND
1.2 / 0.1
is coupled on the definitions for audio, video, etc. and cannot exist separately, i.e. the transport definition
should follow some application level QoS definition. In cases of pre-negotiation the exchanged
information is only statistical and there is still no need to map the descriptions on the available resources,
therefore the definition of the transport is separated from the definition of the application level QoS for
audio, video, etc. By pre-negotiation the peers exchange information only on the available transport and
application level QoS contracts, for any possible future session setup. The mapping between the transport
and the application level QoS contracts is done by multimedia session establishment (i.e. negotiation),
since only then, having the knowledge of the currently available local and network resources, it is
possible to map the transport to the application level QoS contracts. The association between the transport
and the application level QoS can be done only by having knowledge about the structure of the
multimedia session, which should be established, e.g. the associations between transport and application
QoS for only audio conference is different as the association – for audio/video session.
The element <spare> may be changed by intermediate entities, or the receiver of the message in order
to indicate the usability of the contract within a specific provider domain. The structure of <spare> is
shown in Section A.7.3.4.2.4.
A.7.3.4.2.2
The <e2enp:policy> element
The <e2enp:policy> element conveys the type of policies to negotiate. The "name" attribute
provides a human readable description of the policy.
The optional <e2enp:predicate> child element allows expressing a Boolean predicate involving
two terms, each drawn from the following set:
•
“optMemoryUsage” – indicates the memory usage optimisation policy.
•
“optNetworkPerformance” – indicates the network performance optimisation policy.
•
“optPowerConsumption” – indicates the power consumption optimisation policy.
•
“optCpuLoad” – indicates the CPU load optimisation policy.
Additional values corresponding to other policies can be added in the future.
Alternatively, the value of the predicate terms can be drawn from the set of other instances of the
<e2enp:predicate> element. The type of Boolean function is indicated via the "function"
attribute, which can take any value out of the set: "and", "or". The "not" function is not used, since
the absence of a policy indicates implicitly that such a policy is not used. The <e2enp:predicate>
child element thus allows specifying combinations of the elemental policies listed above. These
combinations indicate specific correlations among the various policies.
The <e2enp:criterion> child element identifies a given policy via the "type" attribute, which
can take any value out of the set indicated above. Furthermore, an instance of this element can enforce an
instance of the <e2enp:predicate> element, by specifying the string "expression" as value of
the attribute "type", and by using an additional attribute "idref" identifying a given instance of the
<e2enp:predicate> element. The <e2enp:criterion> child element is mandatory and only
one instance of it can appear within a given instance of the <e2enp:policy> element.
A.7.3.4.2.3
The <e2enp:contract> element
This element represents the result of the cross-product process described in Section A.7.3.4. Those
Offerer's application-level QoS requirements matching with the available capabilities are hereby copied
from the Offerer's user profile information, and negotiated among peers. It may therefore results that at
the end of the negotiation process, the original application-level QoS requirements of the Offerer are
narrowed down to a subset thereof.
Page A.231
MIND
A.7.3.4.2.4
1.2 / 0.1
The <spare> element
With respect to the requirements set forth in Section A.4.5.1.1 and to the concept of spare contract
introduced in Section A.6.2.4.2, the <spare> child element of the <e2enp:contract> element is
hereby introduced to indicate those spare contracts, which are not supported by the given users' preferred
network provider. By the validation process those contracts are marked with the current provider
identification to indicate that they currently not usable. By handovers the validation of the contracts leads
to the removing of the spare indication for those contracts which are now usable and the contracts which
are not usable are blocked, see also Section A.7.3.7.41
The <spare> child element would be then an optional element, and its presence indicates that the given
contract is not going to be supported by the preferred network operator of the Offerer. The Answerer
similarly filters off those not indicated as not spare, based on her/his agreements with her/his preferred
network operator.
When a vertical handover occurs, either party can try to validate all of her/his contracts, including the
spare ones, which might eventually become applicable with respect to the new network provider. If the
end-peers cannot perform validation themselves, this can be done by the provider proxies as indicated in
Chapter 4 of this document. In any case the spare contracts are marked by validation with the respective
provider identification.
<spare provider_id=”my-funny-provider”>
XML Example A. 11
The <spare> element can be used also in the context of higher level QoS contract within negotiation
bids and answers. In order to mark which elements are blocked/unblocked by handover the elements
described in Sections A.7.3.7.2 und A.7.3.7.3 are used, the <spare> element indicates only at session
start up which elements cannot be currently used due to the provider policies of the home/visited network.
A.7.3.4.2.5
The <rtp:map> element
This element is proposed as an extension of the SDPng RTP Profile [SDPNG03], [SDPNG04], to
represent the association of a given application-level QoS Contracts with a specific format. The payload
type is specified by the "format" attribute, which references instances of the "name" attribute of the
<rtp:pt> element.
The attribute "contract" identifies the associated application-level QoS, by referencing instances of
the "name" attribute of the <e2enp:contract> element.
The attribute "peer_role" indicates whether the given association application-level QoS
Contract/Stream format is proposed by a receiver, a sender, or a sender/receiver, according to the
requirements set forth in Section A.4.5.1.4.1. In this way, not only receivers, but also senders can proactively disseminate information that will be later used for deciding how to handle re-negotiations, based
on APs (see Section A.7.3.5.2).
A.7.3.5
QoS Context- and stream grouping-related information, pre-negotiated among
users on a peer-to-peer basis
The concepts of QoS Context and stream grouping (and, more specifically, Association) presented in
Section A.4.5.1.3 can be modelled by introducing a new element <e2enp:qoscfg>, as an addition of
the <cfg> element.
41
Note, that the indication can be done directly on the object internal representation by the application/QoS Broker, if
the application/Broker de-reference the PDU references at application and not at the protocol level (E2ENP level).
Page A.232
MIND
1.2 / 0.1
More specifically, the <e2enp:qoscfg> element contains Adaptation Path (AP) description for a
given stream, as well as the definitions of Associations (or, more generally, groupings) thereof. Higher
level QoS Contracts capturing QoS correlation and time synchronization constraints among various
groups of streams, as well as (higher-level) APs thereof, can also be specified with this new element, as
explained later in this paragraph and in Section A.7.3.6.
The information contained in the <e2enp:qoscfg> element can be either pre-negotiated among peers,
irrespective of later actual use, or negotiated at connection set-up time (see Section A.8 for detailed
examples).
A.7.3.5.1
The <cfg> element
Within the context of the E2ENP idea, the scope of the SDPng original <cfg> element needs to be
clarified: the <cfg> element simply defines the mapping of formats (e.g. RTP payload types) with
transport-related information; whereas the full definition of APs (in terms of the capabilities and of the
QoS Contracts defined in the <e2enp:qosdef> elements) is totally supported by the new
<e2enp:qoscfg> element as described in Section A.7.3.5.2.
The only difference between this proposal and [SDPNG03], [SDPNG04] is the introduction of additional
attributes in the <rtp:session> element, for specifying which type of network and version thereof is
used (respectively, the "nettype" and "addrtype" attributes). This change affects the SDPng RTP
Profile [SDPNG03], [SDPNG04] as well.
Furthermore, the addresses are expressed by using the syntax proposed for SDP in [Olson01]. The
proposed E2ENP extensions for the <cfg> element are indicated in the example below in bold face.
<cfg>
<component name="audio-stream-1" media="audio”>
<alt name="AVP-audio-0”>
<rtp:session format="rtp-avp-0">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
<alt name="AVP-audio-18”>
<rtp:session format="rtp-avp-18">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
</component>
<component name="video-stream-1" media="video”>
<alt name="AVP-video-34”>
<rtp:session format="rtp-avp-34">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
<alt name="AVP-video-31”>
Page A.233
MIND
1.2 / 0.1
<rtp:session format="rtp-avp-31">
<rtp:udp role="receive" nettype="IN" addrtype="IP6"
addr="3ffe:1200:3012:c006:290:27ff:fe7d:d024" rtp-port="7920"
rtcp-port="7921"/>
</rtp:session>
</alt>
<alt name="AVP-video-98”>
<rtp:session format="rtp-avp-98">
<rtp:udp role="receive" nettype="IN" addrtype="IP6"
addr="::ffff:43.196.180.15" rtp-port="7940" rtcpport="7941"/>
</rtp:session>
</alt>
</component>
</cfg>
XML Example A. 12
Please note that the usage of the <cfg> element is for specifying a given address/port pair for every used
RTP payload type. Since some video codecs (video RTP payload types) can generate one and the same
perceivable QoS, the association video QoS contract – transport parameters in not unique, see also the
mappings described in the <rtp:map> element of the <e2enp:qosdef name="contracts">
(Section A.7.3.4.2). That is why <cfg> element associates not the QoS contracts to transport parameters,
but the RTP payload types (e.g. see “AVP-audio-x”, “AVP-video-y” definitions in the example above).
To this extent the <cfg> element is a reference, indicating how many physical media streams (see
<component> element) would be opened and how these streams are associated with payload types, host
addresses and host ports. This reference is used further for the definition of the stream adaptation paths in
the <e2enp:qoscfg> element (Section A.7.3.5.2). The <component> element can thus represent
different types of configurations of transport-related information, whereby each type of configuration has
a specific meaning and specific application field, although in general all these descriptions can be used in
the re-negotiation process. These types of configurations are:
•
A stream is associated with different payload types but the physical stream is running over one
and the same ingress/egress point.
<component name="video-stream-1" media="video”>
<alt name="AVP-video-34”>
<rtp:session format="rtp-avp-34">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
<alt name="AVP-video-31”>
<rtp:session format="rtp-avp-31">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
Page A.234
MIND
1.2 / 0.1
<alt name="AVP-video-98”>
<rtp:session format="rtp-avp-98">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
</component>
XML Example A. 13
This kind of association gives the possibility to switch between different video payloads, which
generate one and the same visual quality by only using the in-band signalling via RTP as
described in Section A.6.2.4.1 (fast re-negotiation). This description can be used when the QoS
variations are relative small and explicit re-negotiation is not necessary. In such cases, the endpeers do not need in fact to switch between different QoS levels (states), rather they adapt by
only adapting their local resources.
This description can be as well used by explicit re-negotiations when the payload types are
associated with different QoS levels. The usage of single ingress/egress ports in this case leads to
saving of system resources compared to opening multiple ports.
As evident from this example, there is repetition of parameters within every <alt> element. To
this extent, the SDPng description for the fast renegotiation case is not optimal. A short form of
this description is left for further studies.
•
A stream is associated with different payload types and the physical stream is running over
different ingress/egress points on the same host.
<component name="video-stream-1" media="video”>
<alt name="AVP-video-34”>
<rtp:session format="rtp-avp-34">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
<alt name="AVP-video-31”>
<rtp:session format="rtp-avp-31">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7902" rtcp-port="7903"/>
</rtp:session>
</alt>
<alt name="AVP-video-98”>
<rtp:session format="rtp-avp-98">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7904" rtcp-port="7905"/>
</rtp:session>
</alt>
</component>
Page A.235
MIND
1.2 / 0.1
XML Example A. 14
This kind of association is particularly effective when used for the sake of explicit re-negotiation
and in cases when the streaming needs to be prepared ahead. This means the codec cannot switch
directly but needs some time to be prepared (e.g. to perform explicit reservation process by
signalling its beginning and end over E2ENP), thus in the switching time the media stream
packets can be send for a short time in parallel and filtered at the receiver to avoid streaming
stops (e.g. by handovers between different technologies).
•
A stream is associated with different payload types and the physical stream is running over
different ingress/egress points on different hosts.
<component name="video-stream-1" media="video”>
<alt name="AVP-video-34”>
<rtp:session format="rtp-avp-34">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
<alt name="AVP-video-31”>
<rtp:session format="rtp-avp-31">
<rtp:udp role="receive" nettype="IN" addrtype="IP6"
addr="3ffe:1200:3012:c006:290:27ff:fe7d:d024" rtp-port="7920"
rtcp-port="7921"/>
</rtp:session>
</alt>
<alt name="AVP-video-98”>
<rtp:session format="rtp-avp-98">
<rtp:udp role="receive" nettype="IN" addrtype="IP6"
addr="::ffff:43.196.180.15" rtp-port="7940" rtcpport="7941"/>
</rtp:session>
</alt>
</component>
XML Example A. 15
This kind of association can be used for the sake of explicit re-negotiation, in cases when the
streaming needs to be prepared ahead and in cases of session mobility.
•
As additional alternative meaning, it should be considered the definition of mixed usage
possibilities. In this case the <rtp:udp> element should carry an indication about the
respective usage and the <rtp:session> element should allow multiple <rtp:udp> subelements. This special description case is left for further studies.
The usage purpose of this specification of different alternatives is important by strong peer
mobility, when it is expected that the peer can flexibly perform technology handovers and is
session mobility enabled. Eventually, as by the first case of this list (fast re-negotiation) SDPng
description optimisation is necessary. This can be done by assigning payload types to
ingress/egress points and not vice versa as by the typical SDPng definition.
Page A.236
MIND
1.2 / 0.1
Considering the usage of the <cfg> element, it should be noted that the current SDPng description is too
RTP/RTCP-centric. The future configuration descriptions should also consider other types of media
transport.
A.7.3.5.1.1
The use of the "role" attribute
The difference between this proposal and legacy SDP and SDPng consists in that the latter do not focus
primarily on QoS negotiation, rather on capability negotiation. This means that SDP/SDPng allow a
sender giving information to the receiver(s) about format and transport information that the sender intends
to use for sending.
Trying to match E2ENP with this well-known approach, one should note that sheer capability negotiation
is already taken into account in the End-to-End QoS Pre-Negotiation Phase. In fact we can consider the
pre-negotiation phase as sufficiently general for indicating stream-level-only QoS Contracts that peers
may want to use both when sending and receiving. More specifically, the attribute "peer_role" of the
<rtp:map> element of the <e2enp:qosdef name="contracts"> element allows doing that.
These two attributes are however dealing with two different aspects:
•
the "peer_role" attribute used in the <e2enp:qosdef name="contracts"> element
allows receivers formulating APs and high-level QoS Contracts/APs (see Section A.7.3.5.2)
based also on information/preferences disseminated by the senders.
•
Whereas the "role" attribute of the <cfg> element merely allows application/middleware
configure itself to use streams properly (in terms of capability and transport aspects), as
aforementioned. In this case the "role" indicates in what direction the single stream is being
sent.
A.7.3.5.1.2
QoS as precondition for the reservation
As an additional element, it should be considered the usage of QoS preconditions as described in Section
A.4.5.2, in order to be able to coordinate network resource reservations even in cases of over-provisioned
networks and segmented reservations. The peer indicates if QoS reservation coordination is necessary
within the <e2enp:description> element (Section A.7.3.2.3). For the purpose of this coordination
the E2ENP should accommodate the SDP QoS precondition parameters as described in [SIPRES07] for
the SDPng/E2ENP syntax. This would give the peer the possibility to inform its negotiation partners of
the necessity of performing network resource reservations and to coordinate the network reservation by
segmented reservations. In order to express that QoS is precondition for the reservation process, two
additional elements are introduced <e2enp:reservation> and <e2enp:streaming> within the
<component> element (in the example in bold). Using these elements it is possible to indicate for every
media stream if QoS is a precondition for reserving resources for this stream. These elements are
evaluated by the QoS aware application/middleware when managing the reservation process.
<component name="video-stream-1" media="video”>
<e2enp:reservation precondition=”true” initiator="receiver"
status="e2e"/>
<e2enp:streaming generator="receiver"/>
<alt name="AVP-video-34”>
<rtp:session format="rtp-avp-34">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
<alt name="AVP-video-31”>
Page A.237
MIND
1.2 / 0.1
<rtp:session format="rtp-avp-31">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7902" rtcp-port="7903"/>
</rtp:session>
</alt>
<alt name="AVP-video-98”>
<rtp:session format="rtp-avp-98">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7904" rtcp-port="7905"/>
</rtp:session>
</alt>
</component>
XML Example A. 16
The meaning of this example is the following:
•
•
The receiver wants to reserve end-to-end resources for using the stream indicated with
name="video-stream-1"
and
it
initiates
the
reservation
process.
(<e2enp:reservation
precondition=”true”
initiator="receiver"
status="e2e"/>)
o
The attribute “precondition” indicates if the network reservation should be
performed or not. If no network resource reservation is necessary the reservation
element is (<e2enp:reservation precondition=”false”/>). The explicit
indication of the reservation is necessary because E2ENP coordinates the reservation
process in any case, thus both the Offerer and the Answerer can indicate if they need
reservation and coordinate this process even if one or both sides are in over-provisioned
network. By over-provisioned networks only the local resource reservation might need
to
be
coordinated.
If
the
“reservation”
element
is
missing,
<e2enp:reservation precondition=”false”/> is the default value. This
means that only local resources are needed and the local resource reservation at all
peers should be if necessary coordinated.
o
The “initiator” indicates the peer which initiates the reservation (By using
different reservation protocols and architectures the value of the “initiator” can be
"receiver" – for RSVP reservation, “sender” – for IntServ or “network” – for
COPS).
o
The “status” indicates if the reservation is end-to-end, segmented, etc. (respective
values of the “status” attribute can be “e2e”, “segmented”). This attribute is
useful for the QoS Brokers if they should coordinate the reservation process out of the
Service Domain as described in Chapter 4.
The description within the session tag are the parameters for receiving as the receiver wants to
have them and the receiver is the generator of this information (<e2enp:streaming
generator="receiver"/>). The sender should apply by reservation these pre-negotiated
parameters. If the element “streaming” is missing as default should be considered the QoS
parameters as the receiver wants to have them.
These two XML elements are adopted from the SDP syntax of [SIPRES07]. For further information on
the specific usage see [SIPRES07]. It should be noted that E2ENP always coordinates the reservation
Page A.238
MIND
1.2 / 0.1
compared to [SIPRES07], which considers only the network reservation process. This is necessary, since
the end-peer should synchronize their local reservations.
A.7.3.5.2
The <e2enp:qoscfg> element
This element allows defining APs as well as QoS correlation and time synchronization constraints at
various levels of abstractions, starting from stream-level QoS Contracts. Each level of abstraction is
identified by the attribute "name" of this element.
An example of this element at stream-level is indicated in the XML document fragment below.
<e2enp:qoscfg level="stream">
<! --adaptation path for single streams -->
<e2enp:adapath name=“audio1” ref_component="audio-stream-1">
<e2enp:alt nominal=”true” name=“initial” ref_contract=“audiocontract-1” transport-contract=”TI-3” suboption=“SI-1”
scope="applicable"/>
<e2enp:alt name=“choice1" ref_contract=“audio-contract-3”
transport-contract=”TI-3” suboption =“SI-2” scope="applicable"/>
</e2enp:adapath>
<e2enp:adapath name=“video1” ref_component="video-stream-1">
<e2enp:alt nominal=”true” name=“initial” ref_contract="videocontract-1” transport-contract=”TI-2” suboption=“SI-1”/>
<e2enp:alt name=“choice1" ref_contract="video-contract-2”
transport-contract=”TI-2” suboption=“SI-1”/>
<e2enp:alt name=“choice2" ref_contract="video-contract-3” />
<event id="video1-e-1" reason="higher-frame-rate">
<path name="upgrade-1" guard=".ge. 15 .and. .le. 20"
source="video-contract-1" target="video-contract-2"/>
<path name="upgrade-2" guard=".ge. 20" source="video-contract2" target="video-contract-3"/>
</event>
<event id="video1-e-2" reason="lower-frame-rate">
<path name="degrade-2" guard=".ge. 15 .and. .le. 20"
source="video-contract-3" target="video-contract-2"/>
<path name="degrade-2" guard=".le. 15" target="video-contract1"/>
</event>
</e2enp:adapath>
<!-- Possible associations of streams between user A and B -->
<e2enp:context name=”association1-1” scope="applicable">
<e2enp:comp name=”element1” ref_adapath="audio1"/>
<e2enp:comp name=”element2” ref_adapath="video1"/>
<e2enp:constraints>
<e2enp:par name=“lipsync-delay” ref_adapath="audio1" max=”2”/>
Page A.239
MIND
1.2 / 0.1
<e2enp:par name=“aggregated-bw” max=”64000”/>
</e2enp:constraints>
</e2enp:context>
<e2enp:context name=”association1-2” scope="possible">
<e2enp:comp name=”element1” ref_adapath="audio1”/>
</e2enp:context>
<e2enp:adapath name=“associations-A-B”>
<e2enp:alt nominal=”true” name=“initial”
ref_context="association1-1”/>
<e2enp:alt name=“choice1" ref_context="association1-2”/>
</e2enp:adapath>
</e2enp:qoscfg>
XML Example A. 17
The following subparagraphs detail each element appearing in this element.
A.7.3.5.2.1
The <e2enp:adapath> element modelling stream-level Adaptation Paths
The first two instances of the <e2enp:adapath> element appearing in the example above allow
defining two distinct Adaptation Paths, by collecting a set of stream-level QoS Contracts, drawn from the
set of <e2enp:contract> elements of the <qosdef name=capabilities"> element, and
associated with receivers only (according to the requirements set forth in Section A.4.5.1.4.1). Note, that
it only makes sense to associate audio QoS contracts with audio adaptation paths and video contracts with
video adaptation paths. The combination of audio and video adaptation paths is explained below. Each
<e2enp:adapath> element is associated with a specific <component> of the <cfg> element, via
the "ref_component" attribute42. By using the E2ENP signalling the peer gets first of all, via the prenegotiation, the information about the preferable codec which should be used for a given stream (Section
A.7.3.4.2)43. Afterwards, by the negotiation (see Section A.7.3.5.1), every payload type is associated with
a media stream and its transport parameters (host, ports). The <e2enp:qoscfg> element references all
these parameters for defining the stream adaptation path within its <e2enp:adapath> sub-elements.
Thus the peers can uniquely indicate which codec should be used as first for the streaming process.
Each QoS Contract is an alternative option in the AP: hence the use of the <alt> construct for defining
them (alt stands for alternative). By assuming the Hierarchical FSM model described in Section A.6.3,
each of these APs represent a distinct FSM, whose initial state is explicitly indicated by the attribute
“nominal” of the given <e2enp:adapath> construct.
By assuming the Hierarchical FSM model described in Section A.6.3, the choice of switching from one
QoS Contract to another within a given AP may be dynamically determined by matching monitored QoS
levels against the set of QoS Contracts defined in the given AP, by using for instance fuzzy logic
[Bhatt99], [BRAIN]. Alternatively the <e2enp:adapath> construct may include a predefined set of
state transitions among those QoS Contracts: in this case, the <event> construct indicates which
42
This attribute is mandatory only for <e2enp:adapath> elements describing stream-level APs.
43
Note, that the association “audio QoS contract” and “audio payload type” is unique, whereas the association “video
QoS contract” and “video payload type” is not unique and the preferred codec for video should be indicated, if
there are multiple available possibilities.
Page A.240
MIND
1.2 / 0.1
transitions should be triggered upon detection of given events44. A given <event> can be associated
with multiple paths, whose triggers determine the one that will be activated.
The individual transitions are described in <path> constructs, which describe the trigger condition
(indicated as guard parameters45) and the QoS Contracts involved in the transition (indicated with the
source and target attributes). The source attribute in the <path> construct is optional, insofar as
there might be cases where the specification of that attribute could be omitted on purpose. In those cases,
in fact, the corresponding transition would originate from whichever state the given Hierarchical FSM is
currently set. In this way, we may model for instance the change of any QoS Contract within a given set,
to a defined one in case the corresponding transition is triggered (a sort of default mechanism). In the
example above, the event <e2enp:video1-e-2>, triggered by the detection of a lower frame rate (see
the <reason> attribute), would force the FSM described by the <e2enp:adapath> construct named
video1 to enforce video-contract-1, no matter which contract was enforced at the time the event
was thrown. In order to achieve interoperability, one should note that the peers should agree upon the
semantic of the reason attribute. Terms like "higher-frame-rate" or "lower-frame-rate"
appearing in the example above should thus be subject to standardization, along with their meaning. This
pre-definition of transitions sets is optional.
The explicit triggering of state change within the FSM by already running media streaming is done by
indicating this state in a re-negotiation process – <e2enp:enforce> element (Section A.7.3.7.1).
Additionally, if the initial session establishment reservation process does not completely succeed, it is
possible, instead of performing new negotiation, to switch to another (not the nominal) already negotiated
state of the FSM. The eventual change of parameters and states on the fly at session begin can be
indicated in the reservation results by also using the <e2enp:enforce> element.
Note, that the adaptation path may only include one element so that there is just one single choice of
quality for the given stream. By defining the adaptation path, it is possible to associate the application
level QoS contracts with the transport service TI/SI definitions (provided in Section A.7.2) since only at
session begin it is possible to estimate (for video) what network resources are required and available. For
an example, see also Section A.8.1.1.2. Additionally, a single TI/SI definition can be assigned to more
than one application level contracts, since different codecs can use one and the same transport resources
but different local resources.
A.7.3.5.2.2
The attribute "scope"
The attribute scope indicates in a request (negotiation bid) whether the corresponding E2ENP element is
to be considered as a required (applicable) or desired (possible) option; whereas in a response
(negotiation counter-offer), that attribute indicates whether the corresponding E2ENP element has been
validated (applicable) or rejected (not-applicable).
scope:="not-applicable" | "applicable" | "possible"
The Answerer may also indicate in the counter-offer what capabilities it can support, and to what extent.
If a given capability is supported "as is", only the corresponding identifier is indicated, along with the
scope attribute set to applicable.
If a given capability is not supported, the corresponding identifier is simply omitted.
44
Like frame-rate-increase or frame-rate-decrease, as in the example above. These events designate
well known monitor notifications, which applications and/or middleware may be designed to take into account. To
this extent, both the name and the semantics of events shall be subject to standardization efforts.
45
For the sake of simplicity, we have introduced a notation for expressing Boolean predicates, where operators are
abbreviations delimited by dot characters. For instance ".ge." means "greater or equal than", ".le." means "less or
equal than", ".gt." means "greater than", ".lt." means "less than", ".eq." means "equal", ".and." means the AND
Boolean operator, etc. This is just a proposal, open for discussion.
Page A.241
MIND
1.2 / 0.1
If the Answerer proposes in the counter-offer a modified version of the parameterisation of a given
capability in the <e2enp:qosdef> element (as a subset of the original bid), the entire description with
the updates is returned in both the <e2enp:qosdef name="capabilities"> and
<e2enp:qosdef name="contracts"> elements. In any case, the <e2enp:qosdef
name="contracts"> element contains in a response only updated codec parameterisations (see
example in Section A.8.1.1.3.1).
Additionally, the Answerer can indicate a new option (unknown to the Offerer at pre-negotiation time):
this will be marked as possible. The idea is that the Offerer can thus be informed of a potential option
that could be eventually used later, should the Offerer be upgraded with a new capability matching that
option.
A.7.3.5.2.3
The <e2enp:context> elements
The <e2enp:context> elements define possible associations of the given streams, and thus allow
defining time-synchronization and/or QoS correlation constraints. As such, the <e2enp:context>
elements basically describe high-level QoS Contract, as defined in Section A.4.4.
In the example above, a video stream and an audio stream are defined as correlated in a given context
(”association1-1”), along with both time-synchronization and QoS correlation constraints defined.
Alternatively, a context including only the audio stream (”association1-2”) could also be used.
A.7.3.5.2.4
The <e2enp:adapath> element modelling higher-level Adaptation Paths
When and how to enforce either contexts, is described in the second instance of the
<e2enp:adapath> element appearing in the example above. In this case, the use of the “nominal”
attribute is evident: the combination (”association1-1”) of an audio stream and a video stream is
indicated as the preferred one. The case where only an audio stream is used (”association1-2”)
would then be considered as a backup case, which can be enforced in order to cope with e.g. QoS
violations. The individual child elements of the <e2enp:adapath> element reference the instances of
the aforementioned <e2enp:context> elements via the "ref_context" attribute.
A.7.3.5.2.5
The <e2enp:context>, <e2enp:adapath> pattern
As a general rule, one can thus notice the recurring occurrence of <e2enp:adapath> and
<e2enp:context> elements referencing each other in an acyclic chain of references.
Alternative <e2enp:context> constructs are grouped in an <e2enp:adapath> construct, which
defines a FSM. This AP and any other (concurrent) ones can then be wrapped in turn within a
<e2enp:context> construct, which sets constraints at a higher level. And we may also have
alternative such <e2enp:context> constructs been defined, which we can then collect in a higherlevel AP. This process can be recursively applied.
A.7.3.6
Enforcement of QoS correlation and time synchronization constraints at
higher levels of abstraction
A given user can enforce higher-level QoS correlation and time synchronization constraints - as a form of
extended user profile information - in order to orchestrate resource utilization (and hence QoS) across
given sets of streams established with different peers.
To this extent, the given user does not need to negotiate this information with the peers.
However, should the given user require to enforce some new constraints at a later time, or discover that
the pre-existing constraints can no longer be met, due to the later joining/leaving of some peers to/from
the currently opened communication sessions, new rounds of the E2ENP might be required, according to
the given conferencing policies (which are outside of the scope of this writing).
Page A.242
MIND
1.2 / 0.1
Eventually, peers may also resort on a third party entity managing pre-negotiations, negotiations, and renegotiations (the “full” ones), including higher level specification concerning QoS Correlation & Time
Synchronization aspects. This entity would act as a sort of QoS Broker [BRAIN][Roble01] (which are
outside of the scope of this writing).
A.7.3.6.1
Session Level
Streams can be associated in various manners. In the following example, we propose the concept of
session, to be intended as e.g. an instance of a videoconference (see Section A.8). To this extent, we
cluster in various manners the associations of streams between the given user (user A) and its peers (B, C,
and D) within the context of the given videoconference session. We then associate the resulting clusters
with QoS Contexts, by using the aforementioned <e2enp:context> constructs.
To this extent, each cluster can be associated with a set of constraints dictating specific levels of
correlations among the various associations of streams belonging to the given cluster. This means that the
constraints affect all the streams belonging to each association, independently of the QoS specifications of
the individual streams belonging to the given association. The <e2enp:context> constructs thus
specify QoS correlation for concurrent bundles of streams. Alternative contexts can then be possible, as
described in the <e2enp:adapath> constructs (one per instance of the video conference).
These <e2enp:adapath> constructs are thus comparable to the description of a FSM, whose states
contain in turn other concurrent <e2enp:adapath> constructs, each describing the bundling of
streams between the given user and a given peer. This recursive model allows using State-charts
[Booch99] as described in Section A.6.3.
<e2enp:qoscfg level="session">
<e2enp:context name=”vc-session-1-1” scope="applicable">
<e2enp:comp name=”element-1” ref_adapath="associations-A-B”/>
<e2enp:comp name=”element-2” ref_adapath="associations-A-C”/>
<e2enp:constraints>
<e2enp:par name=“aggregated-bw” max=”140000”/>
<e2enp:par name=“frame-rate” avg=”8”/>
</e2enp:constraints>
</e2enp:context>
<e2enp:context name=”vc-session-1-2” scope="applicable">
<e2enp:comp name=”element-1” ref_adapath="associations-A-C”/>
<e2enp:constraints>
<e2enp:par name=“frame-rate” avg=”8”/>
</e2enp:constraints>
</e2enp:context>
<e2enp:context name=”vc-session-2-1” scope="possible">
<e2enp:comp name=”element-1” ref_adapath="associations-A-D”/>
</e2enp:context>
<e2enp:adapath name=“videoconference-1” >
Page A.243
MIND
1.2 / 0.1
<e2enp:alt nominal=”true” name=“initial” ref_context="vc-session1-1”/>
<e2enp:alt name=“choice-1" ref_context="vc-session-1-2”/>
</e2enp:adapath>
<e2enp:adapath name=“videoconference-2” >
<e2enp:alt nominal=”true” name=“initial” ref_context="vc-session2-1”/>
<e2enp:alt name=“choice-1" ref_context="vc-session-2-1”/>
</e2enp:adapath>
</e2enp:qoscfg>
XML Example A. 18
A.7.3.6.2
Application Level
Continuing the recursive approach described above, we can further aggregate streams based on a yet
higher-level rationale. For instance, we can associate all the streams managed by all the instances of a
given application, and differentiate the resulting QoS Context from other applications, as well as impose
higher-level QoS correlation specifications.
<e2enp:qoscfg level="application">
<e2enp:context name=”videoconference-tool” scope="applicable">
<e2enp:comp name="choice-1" ref_adapath=”videoconference-1”/>
<e2enp:comp name="choice-2" ref_adapath=videoconference-2”/>
<e2enp:constraints>
<e2enp:par name=“num-active-flows” max=”6”/>
<e2enp:par name=“cpu-load” max=”0.20”/>
<e2enp:par name=“mem-req” max=”110M”/>
</e2enp:constraints>
</e2enp:context>
</e2enp:qoscfg>
XML Example A. 19
This example shows once again the use of the <e2enp:qoscfg> element for expressing the
information described above. In the example we can see how this high-level specification allows easily
expressing constraints on local resource consumption, in line with the BRENTA concept described in
[BRAIN][Roble01].
A.7.3.7
Support for the End-to-End QoS Compact Re-Negotiation Phase
As indicated in Section A.4.5.1, the idea behind the End-to-End QoS Compact Re-Negotiation Phase is to
avoid performing a full re-negotiation during time critical tasks like recovering from a QoS Violation due
to, say, a handover.
According to the solution described in Section A.6.2.4, this goal can be achieved by enabling peers
signalling each other the new (pre-negotiated) QoS Contracts to enforce, and/or by signalling those (prenegotiated) QoS Contracts that - upon handover to a new access network and/or network provider - result
Page A.244
MIND
1.2 / 0.1
applicable and/or no longer applicable. To this extent, specific SDPng-based support for the E2ENP is
required.
A.7.3.7.1
The <e2enp:enforce> element
This new element allows one of the peers (typically the first which detects a QoS Change/Violation – see
Section A.6.2.4.1) signalling the other peers, which QoS Contracts should be enforced, out of the prenegotiated APs.
The idea is to convey signalling information, according to the hierarchical structure of the pre-negotiated
QoS specification: this means to correctly scope each QoS Contract name. At least two alternative
implementations are available: using a name-space for QoS Contracts, using the XPath [XPATH]
standard, or using language for referencing some part of a document, like the not yet standardized
XPointer technology [XPOINT].
The name-space solution is based on assigning fully specified names to QoS Contract, by pre-pending the
names of any higher-level QoS Contract from which the given QoS Contract depends within the given
tree-based QoS Specification, using as separator character e.g. the dot character. This solution requires
however the consistent use of (often quite complex and long) names throughout a multiplicity of E2ENP
elements and of E2ENP PDUs. Furthermore, this solution forces applications to be able to correctly parse
the given name-space.
For instance, with respect to the example shown in Section A.7.3.5, the fully specified name of the
video-contract-2 within the video1 AP, within the association-1-1 QoS Context, out of
the associations-A-B AP, would look like the following:
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association11.video1.video-contract-2”/>
<e2enp:target name="$contract"/>
</e2enp:enforce>
XML Example A. 20
XPath introduces a query language at XML style sheet level, whereby an element of a target XML
document may be referenced by indicating the URI of the target document, and the fully qualified
element name. The structure of the referenced element name is similar to the one described above, with
the exception that the slash character is now used as separator character. XPath compliant, standard XSLT
processor parsing on demand such queries are available.
The XPointer technology (that, as of the underlying invention, has not yet reached the standardization
status) indicates the current trend concerning the unambiguously pointing of elements across various
XML documents.
In this writing we decided to use this latter solution, without any loss of generality compared to the other
one described above (or any other equivalent one), with respect to the concepts described in Section
A.6.2.4.1.
To explain the solution of choice, we introduce the following XML document fragment describing the
same information used in the example above:
<e2enp:enforce>
<xsl:variable name="association">
<xsl:value-of select="//adapath[@name='associations-AB']/alt[@ref_context='association1-1']"/>
</xsl:variable>
Page A.245
MIND
1.2 / 0.1
<xsl:variable name="stream">
<xsl:value-of
select="//context[@name="$association"]/comp[@ref_adapath='video1'
]/"/>
</xsl:variable>
<xsl:variable name="contract">
<xsl:value-of
select="//adapath[@name="$stream"]/alt[@ref_contract='videocontract-2']/"/>
</xsl:variable>
<e2enp:target name="$contract"/>
</e2enp:enforce>
XML Example A. 21
The QoS Contract to enforce is indicated by the element <e2enp:target>.
In this XML document fragment one can easily recognize the use of the name attribute for the root
element of the given tree branch (associations-A-B), whereas the other elements in that branch are
named via the reference attributes (ref_context, ref_adapath, ref_contract) of the
respective parent. This means that only the name of the <e2enp:contract>, <e2enp:context>,
and <e2enp:adapath> elements must be uniquely used across multiple sections/phases, whereas the
names of the XML child elements of the aforementioned elements can be arbitrarily chosen. By using this
methodology, once can enforce signalling not only of stream level QoS Contracts, as in the example
above, but also of any high-level QoS Contract, by terminating the specification above to the given QoS
Context. For instance, the XML document fragment below:
<e2enp:enforce>
<xsl:variable name="association">
<xsl:value-of select="//adapath[@name='associations-AB']/alt[@ref_context='association1-1']"/>
</xsl:variable>
</e2enp:enforce>
XML Example A. 22
could be used for signalling to the other peers that the high level association1-1 should be enforced,
regardless of the currently enforced stream-level QoS Contracts (in this case, default states would dictate
which stream level QoS Contracts to enforce in the new QoS Context).
Furthermore, the <e2enp:enforce> element can also be used for signalling to other peers a specific
AP to enforce, whereby default state would then be used to resolve the remaining lower-level
information. For instance, the following <e2enp:enforce> element:
<e2enp:enforce>
<xsl:variable name="association">
<xsl:value-of select="//adapath[@name='associations-AB']/alt[@name='association1-1']"/>
</xsl:variable>
<xsl:variable name="stream">
Page A.246
MIND
1.2 / 0.1
<xsl:value-of
select="//context[@name="$association"]/comp[@name='video1']/"/>
</xsl:variable>
<e2enp:target name="$stream"/>
</e2enp:enforce>
XML Example A. 23
would force peer A to use "video-contract-1" for the "video1" stream, since that contract
was specified as default in the pre-negotiated <e2enp:qoscfg> element (see Section A.7.3.5).
Since some video codecs (e.g. H.261 and H.263) support frame typing and frame enumeration, it is the
<e2enp:enforce> element which can adopt such features by performing the re-negotiation process.
This would enable such a functionality like “Fast Forward” and “Rewind” by signalling the codec at what
number and kind of frame to start the media after the re-negotiation. This feature can be used in parallel
to RTCP in-band signalling and instead of RTCP, if such an in-band signalling is not available [Even00].
This video frame features can be described as a sub-component of <e2enp:enforce> and with
respect to the codecs which support such media control (media search and frame enumeration) features.
Additionally to performing explicit re-negotiations the E2ENP can also support spontaneous renegotiations which occur on the fly at the end of a negotiation process to convey the results of the
reservation process (especially in cases the reservation resulted with less resources as necessary).
Therefore it might also be necessary to indicate if also the codec is switched on the fly and does not
anymore correspond the default one (as defined in Section A.7.3.4.2).
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association11.video1.video-contract-1.rtp-avp-34”/>
<e2enp:target name="$codec"/>
</e2enp:enforce>
XML Example A. 24
The switching of codecs on the fly at the end of the negotiation process can also be a result of codec
performance failure, which leads to choosing another as the default defined codec. The spontaneous renegotiation for higher-level states of the adaptation path (e.g. contract, stream, association) has the same
contents as by the standard, explicit re-negotiation which occurs after the streaming has begun.
The construct of the example above can be used also by explicit re-negotiation, due to the fact that the
video payload types are not uniquely mapped to video QoS contracts. This would be the case where the
payload types are associated with different ingress/egress streaming points.
A.7.3.7.2
The <e2enp:block> element
Similarly to the case described in Section A.7.3.7.1, the aforementioned XPointer technology can be used
for allowing a peer signalling the others, which QoS Contracts to block, according to the rationale
described in Section A.6.2.4.2.
To this extent, a new element is hereby proposed: the <e2enp:block> element. The following
example depicts the use of such new element.
<e2enp:block>
<xsl:variable name="association">
Page A.247
MIND
1.2 / 0.1
<xsl:value-of select="//adapath[@name='associations-AB']/alt[@ref_context='association1-1']"/>
</xsl:variable>
<xsl:variable name="stream">
<xsl:value-of
select="//context[@name="$association"]/comp[@ref_adapath='video1'
]/"/>
</xsl:variable>
<xsl:variable name="contract">
<xsl:value-of
select="//adapath[@name="$stream"]/alt[@ref_contract='videocontract-2']/"/>
</xsl:variable>
<e2enp:target name="$contract"/>
</e2enp:block>
XML Example A. 25
The QoS Contract to block is indicated by the element <e2enp:target>. By handovers the new
provider can also add such elements for blocking of contracts. The procedure is like the one described in
Chapter 4 (i.e. proxy state migration). The <e2enp:block> element can use as well the alternative
dotted separated notation for indicating the respective contract/-s to block as shown in Section A.7.3.7.1
instead of the XPointer notation.
A.7.3.7.3
The <e2enp:unblock> element
Similarly to the case described in Section A.7.3.7.1, the aforementioned XPointer technology can be used
for allowing a peer signalling the others, which QoS Contracts to unblock, according to the rationale
described in Section A.6.2.4.2.
To this extent, a new element is hereby proposed: the <e2enp:unblock> element. The following
example depicts the use of such new element.
<e2enp:unblock>
<xsl:variable name="association">
<xsl:value-of select="//adapath[@name='associations-AB']/alt[@ref_context='association1-1']"/>
</xsl:variable>
<xsl:variable name="stream">
<xsl:value-of
select="//context[@name="$association"]/comp[@ref_adapath='video1'
]/"/>
</xsl:variable>
<xsl:variable name="contract">
<xsl:value-of
select="//adapath[@name="$stream"]/alt[@ref_contract='videocontract-2']/"/>
</xsl:variable>
<e2enp:target name="$contract"/>
Page A.248
MIND
1.2 / 0.1
</e2enp:unblock>
XML Example A. 26
The QoS Contract to unblock is indicated by the element <e2enp:target>. By handovers the new
provider can also add such elements for unblocking of contracts. The procedure is like the one described
in Chapter 4 (i.e. proxy state migration).
The <e2enp:unblock> element can use as well the alternative dotted separated notation for indicating
the respective contract/-s to unblock as shown in Section A.7.3.7.1 instead of the XPointer notation.
A.7.3.8
Other E2ENP elements
Within the context of the solution presented in this chapter, the semantics of the original SDPng
<constraints> element [SDPNG01] can be interpreted as a form of QoS correlation and/or time
synchronization constraint specification applied to the whole QoS specification described in the
aforementioned new elements.
A.7.4 Possible sources of failure and the ways of error recovery by the E2ENP
phases
The study of the possible SDPng error-codes with respect to E2ENP and their structure should be
thoroughly taken into account. The respective new SDPng XML-elements for describing the E2ENPerror-codes and signalling errors for solving this problem are considered as possible solution but not
shown in the examples for the sake of simplicity. Since E2ENP is applied to SIP via piggybacking,
respective piggybacked error-codes and messages within the SDPng should be taken into account by the
development of the E2ENP. In general the Offerer should consider repeating the calls with reasonsnotification within the SDPng part of the message and the answerer should take advantage of using the
SIP "Status Codes" by also describing reasons in the SDPng message part.
The following is a description of possible errors cases, where some form of notification between the
Offerer and the Answerer is necessary to indicate the changing conditions and the caused disturbances.
The arrow (Æ) indicates possible solutions. The A indicates an answerer and the O an Offerer.
A.7.4.1
No common profile base
1. Push mode
•
The Answerer discovers that the proposal of the Offerer matches none of its capabilities
o
The Answerer has the capabilities to download codecs
ƒ
The Answerer should inform the Offerer that the transaction may last a bit
longer, because she/he needs time for the download and adjustment of his
profile data.
ÆA->O answer with 100 Trying or 183 Session Progress.
o
The Answerer has no capabilities to download codecs
ƒ
If the Answerer is a service Æ A->O answer with 380 Alternative Service if
the Answerer knows such a service. The Offerer may then start a new prenegotiation with the alternative service.
ƒ
Æ The Answerer removes all the Offerers capabilities from the <e2enp:qosdef
name="capabilities"> and makes a counter-offer for the capabilities and the
contracts
(<e2enp:qosdef
name="capabilities">
and
<e2enp:qosdef name="contracts">).
Page A.249
MIND
1.2 / 0.1
ƒ
•
•
If the Offerer can download codecs Æ Offerer downloads codecs,
eventually rearranges profiles, eventually starts a new prenegotiation.
•
If the Offerer cannot download codecs Æ The Offerer should take
into account the usage of a transcoder-service.
Æ The Answerer may also issue 606 Not Acceptable if the Offerer asks for
capability-support that is not available at the moment.
The Answerer discovers that the Proposal of the Offerer matches the Answerer’s capabilities but
the offered contracts cannot be supported.
o
The Answerer trims respectively her/his profile
ƒ
The Answerer should inform the Offerer that the transaction may last a bit
longer because of the profile adjustment.
ÆA->O answer with 100 Trying or 183 Session Progress.
ƒ
o
Æ The Answerer may also issue 606 Not Acceptable if the Offerer asks for
QoS support that is not available at the moment.
The Answerer has no possibility to adjust her/his profile
ƒ
If the Answerer is a service Æ A->O answer with 380 Alternative Service if
the Answerer knows such a service. The Offerer may then start a new prenegotiation with the alternative service.
ƒ
The Answerer makes a counter-offer for the (<e2enp:qosdef
name="contracts">) by trimming the ranges of the contracts of the Offerer or
by proposing completely new ranges Æ It is up to the Offerer to adjust her/his
profile and eventually start a new pre-negotiation.
2. Pull mode
•
The Offerer discovers that the reply of the Answerer matches none of her/his capabilities
o
The Offerer has the capabilities to download codecs
ƒ
o
The Offerer has no capabilities to download codecs
ƒ
•
Æ The Offerer downloads the codecs, adjusts respectively his profile and
starts a new pre-negotiation
Æ The Offerer should take into account the usage of a transcoder-service.
The Offerer discovers that the proposal of the Answerer matches none of her/his “contract”profiles
o
ÆThe Offerer adjusts her/his profile accordingly before creating a counter-offer to the
Answerer
o
ÆThe Offerer start a new pre-negotiation in push-mode in order to enforce the
adaptation of the Answerer
3. Push-Pull mode
Page A.250
MIND
1.2 / 0.1
This case should be treated as a combination of the above two cases.
A.7.4.2
Non-expired pre-negotiated data is no longer valid
It may happen that some of the pre-negotiated and saved data at the Offerer- and/or the Answerer-side
alter due to reasons of changing profile information like:
•
Different users impose their performance policies on the devices (Offerer and/or Answerer)
•
Some higher priority (internal and/or external) processes use the resources so that the prenegotiated profiles are no longer valid
•
Some system configuration changes have taken place, like:
o
Failures by local resource reservation, due to occupation or resource malfunction
o
Failure by network resource reservation if e.g. the network supports only “best effort”
with respect to the lower network QoS levels
o
New codecs and/or hardware sub-devices are being installed thus influencing the
capabilities and the QoS profiles.
The Offerer and/or the Answerer may discover such premature expiry by the time they try to start an
additional pre-negotiation or a negotiation. In such a case the peers should be able to enforce the expiry of
the pre-negotiated data at the side of their communication partners thus pushing it prematurely into
“zombie”-state.
Æ Necessary indication of the premature expiry with following new pre-negotiation. To this extent the
<e2enp:expires> element is set to zero and an additional command expire may be used.
If a profile change occurs within the time of running streaming Æ the side which discovers the violation
should start new Full Re-negotiation E2ENP process.
A.7.4.3
pull)
The called peer does not supports all of the negotiation modes (push/pull/push-
If a called peer receives a message with an indication for a negotiation mode which it does not support a
failure occurs at its side. Æ In such case the Answerer sends 606 Not Acceptable to the Offerer, indicating
in the message body the negotiation mode, which the Answerer supports. The Offerer should start
respectively anew the negotiation phase.
This might be the case by using services, since services should be able to support multiple clients and thus
may have preferences for the negotiation mode.
A.7.4.4
The received message is malformed
Due to peer and/or network failures the body of a SIP message (the SDPng) or the whole SIP message
may be malformed. If the Answerer gets such a message the possible answers may be:
•
400 Bad Request – if the whole SIP message is malformed
•
420 Bad Extension – if only the SDPng message if malformed
If the Offerer gets a malformed message or has received a “malformed-message” notification Æ The
Offerer should repeat the SIP request.
Page A.251
MIND
1.2 / 0.1
A.7.4.5
•
A third party interferes with the negotiation wishing to start a negotiation
The call has the same priority
Æ The peer issues 182 Queued if the peer decides that it can handle the call at later time.
Æ The peer issues 600 Busy if some other peer was quicker with issuing the call and has occupied
all the available capacities of the answering peer. This is especially true by already running
streams when eventual full re-negotiation might be required.
Æ The peer issues 603 Decline if some other peer was quicker with issuing the call and occupied
all the available capacities of the answering peer but the answering peer knows how long the call
shall continue. This is also the case that a similar transaction with respect to priority is being
processed at the moment and the caller has to wait.
Æ
The peer issues 380 Alternative Service if the peer is a service and has information on
common alternative services.
•
The call has higher priority
The Offerer side
Æ
The Offerer should be able to inform the Answerer about the interruption of the
negotiation – some SDPng error code.
The Answerer side
Æ
The Answerer may issue 600 Busy or 603 Decline with some reason indicating the
interruption.
Æ
Depending on the priority of the call and the currently available resources by already
running streams, the peer may perform quick or full re-negotiation, or completely cancel the
streaming.
A.7.4.6
Components do not understand E2ENP or the version of the E2ENP
According to [SIPBIS04]: “Proxies generally do not modify the session description, but MAY do so if
necessary, e.g., for network address translators, and if the session description is not protected by a
cryptographic integrity mechanism”. This means that the Proxies understand the SDPng bodies of the
messages and may change them. In order to protect the E2ENP messages from being altered from
components, which do not understand the protocol, digital signatures and digests should be applied for the
E2ENP-messages. Some additional signalling mechanisms should also be applied in the SDPng for
E2ENP in order to enable the peers to inform each other that an E2ENP-message is being altered by some
network component not concerned in the E2ENP.
The integrity of the messages should be considered a security issue, which is a topic of future studies.
If an Answerer in general understands E2ENP but not the version of it, the Answerer issues 606 Not
Acceptable with SDPng description indicating that the E2ENP version is not supported but that another
E2ENP version is supported. This is also necessary to guarantee backward compatibility of the E2ENP
versions. This means that the XML-part describing the E2ENP version should be uniform for all E2ENP
versions.
A.7.4.7
A communication peer lies within a screened sub-network (Proxies, Firewalls)
or the network is not transparent
The consideration of screened networks is a security issue, which is a topic of future studies. The
following is only a short description on how security may influence the E2ENP error messaging:
Page A.252
MIND
1.
1.2 / 0.1
The screening component does not understand E2ENP but understands SIP/SDPng
In this case a non-E2ENP pre-negotiation with the screening component would be necessary to
make it transparent for the following E2ENP-protocol.
2.
The screening component understands E2ENP
In this case the E2ENP may carry information which concerns the non-transparent components
in form of references to eventually non-E2ENP information (authentication, security, etc.) thus
enabling the non-transparent components to silently check and forward the E2ENP-messages.
The Offerers and the Answerers not interested in this information may simply discard it. This
approach allows silently dealing with non-transparent - with respect to E2ENP – components,
thus making the network explicitly transparent and masking some of the SIP Request Failures
4xx messages, which may negatively influence the E2ENP.
A.7.5 E2ENP addressing
The E2ENP itself does not carry addressing information concerning the identification of the
communicating hosts (e.g. IP address/port), since E2ENP uses the abstraction of the carrier protocol (e.g.
SIP). Nevertheless E2ENP defines an address, the information of which can be won from the carrier
protocol and the <e2enp:purpose> element of the E2ENP. The goal of this address is to uniquely
identify the E2ENP sessions and the communication parties also at the applications using E2ENP.
Therefore the following E2ENP semantic (Table A.1) using augmented Backus-Naur Form (BNF) is
defined.
Table A.1: E2ENP URI Syntax (augmented Backus-Naur Form)
E2ENP-URI
=
"e2enp://" [ userinfo "@" ] hostport
userinfo
=
[ user] [ ":" password ]
user-unreserved
=
"&" / "=" / "+" / "$" / "," / ";" / "?"
escaped
=
"%" HEXDIG HEXDIG
unreserved
=
alphanum / mark
mark
=
"-" / "_" / "." / "!" / "~" / "*" / "'" / "(" /
")"
alphanum
=
ALPHA / DIGIT
user
=
*( unreserved / escaped / user-unreserved)
password
=
*( unreserved / escaped / "&" / "=" / "+" / "$" /
"," )
hostport
=
host / host ":" port
host
=
hostname / hostaddress
hostname
=
*( domainlabel "." ) toplabel [ "." ]
domainlabel
=
alphanum / alphanum *( alphanum / "-" ) alphanum
toplabel
=
ALPHA / ALPHA *( alphanum / "-" ) alphanum
Page A.253
MIND
1.2 / 0.1
hostaddress
=
ipv4-addr / ipv6-addr
ipv4-addr
=
digits"."digits"."digits"."digits
digits
=
1*3DIGIT
ipv6-addr
=
hexpart [ ":" IPv4address ]
hexpart
=
hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq
=
hex4 *( ":" hex4)
hex4
=
1*4HEXDIG
port
=
1*DIGIT
An example of the E2ENP URI:
e2enp://dave:vG$l809@acme.com/
The respective full or partial usage of the E2ENP address components depends on the domain model
(proxying) and the address resolution mechanisms, which are mainly part of the session layer protocol
(e.g. SIP). An application utilizing E2ENP for its signalling should use at least the domain names to
identify the communicating partners, if the session layer protocol is already offering some proxying
and/or redirection mechanisms to identify the network paths. Full E2ENP addresses should be considered
in cases of missing proxying mechanisms and ad-hoc networks.
Page A.254
MIND
1.2 / 0.1
A.8. Examples for using E2ENP
This section presents some examples depicting how the solution proposed in Section A.7 can be used in
practical cases.
The first example deals with videoconference services, whereby one-to-one and one-to-many scenarios
are used. The second example deals with third-party-assisted negotiation scenarios. The third example
depicts the case of a many-to-many scenario.
A.8.1 Videoconference scenarios
More specifically, we consider the case of a given User A, who simultaneously joins two different
videoconferences. User A is NOT acting as a mixer on behalf of the other peers, rather is simply
participating to two different videoconferences. In our terminology, each instance of the videoconference
application is named "videoconference session".
User A will then open the videoconference session #1 with User B and User C, and the videoconference
session #2 with User D (see Figure A.12).
User B and User C might be e.g. part of the same team as User A, whereby – by continuing the online
game example - User D might be an opponent. Team members might want to remain in contact via live
audio/video streams so as to enhance their team experience. On the other hand, User A might also
communicate with the User D so as to enhance the fighting experience. Please note that Figure A.12 does
not explicitly indicate data/control streams: for the sake of simplicity this example focuses only to (but is
in no way limited to) on the case of A/V media.
Furthermore, this example focuses on the level of QoS requested and perceived by User A. Therefore we
limit this example to the negotiation of the level of QoS that User A wishes to obtain for incoming
streams from her/his peers; furthermore, we may well assume that User A has enough information to
enforce QoS correlation and time synchronization on all of the streams included in both videoconference
sessions.
Figure A.12: Video Conference Example
In the rest of this section we apply the following convention:
1.
Message Sequence Charts are first presented, detailing the protocol procedures to be applied.
The E2ENP content is referenced by keywords: bids are referenced with the keyword bid-x,
Page A.255
MIND
1.2 / 0.1
answers with the keyword answer-y, whereby in both cases x and y stand for an incremental
integer positive value.
2.
Detailed description of the E2ENP content is then collected in a separate sub-paragraph.
A.8.1.1
One-to-one communication scenario
A.8.1.1.1
Pre-Negotiation
•
Push mode
Peer A: Receiver/Offerer - Peer B: Sender/Answerer
A: Local-Admission-Control (bid-1.1 - the initial proposal46):
successful
A: OPTIONS (bid-1.1) -> B
B: Local-Admission-Control (bid-1.1):
answer-1.1
B: 200 OK (answer-1.1) ->A
•
Pull mode
Peer A: Receiver/Offerer - Peer B: Sender/Answerer
A: OPTIONS -> B
B: Local-Admission-Control47 (bid-1.2):
successful
B: 200 OK (bid-1.2) ->A
A: Local-Admission-Control (bid-1.2):
answer-1.2 ⊆ bid-1.2
A: OPTIONS (answer-1.2 ) -> B
B: 200 OK ->A
Note (1):
The Offerer may or may not need to notify the answer to the
Answerer with the second OPTIONS method.
For instance, in the case of a Video on Demand scenario, the
Offerer might equivalently use the RTSP DESCRIBE method to
gather information about QoS contracts associated with a given
46
Derived from the cross- product of user profile information and capabilities - see § A.7.3.4
47
Performs cross-product process described in § A.7.3.4.
Page A.256
MIND
1.2 / 0.1
media. In that case, the Answerer (e.g. a VoD server) would not
need to be informed about the Offerer's (i.e. client's) choice, until
the actual streaming is started. In this document we focus however
on SIP-based conference scenarios, whereby peers are to be
considered substantially on an equal footage: each peer intends to
be informed about other peers for later communication. This is
especially true, if e.g. peer B intends to enforce QoS correlation
and time synchronization. Therefore the scenario depicted above
does apply to the example hereby addressed.
•
Push-Pull mode
Peer A: Sender-Receiver/Offerer - Peer B: Sender-Receiver/Answerer
A: Local-Admission-Control (bid-1.3):
successful
A: OPTIONS (bid-1.3) -> B
B: Local-Admission-Control (bid-1.4):
successful
B: Local-Admission-Control (bid-1.3):
answer-1.3 ⊆ bid-1.3
B: 200 OK (answer-1.3 + bid.1.4) ->A
A: Local-Admission-Control (bid-1.4):
answer-1.4 ⊆ bid-1.4
A: OPTIONS (answer-1.4) -> B
B: 200 OK ->A
Note (2):
Upon receiving a bid from the Offerer, the Answerer first of all
validates its own bid (e.g. based on user profile information), and
then the Offerer's bid, by following a sub-case of the Economy
Principle (commit first to local resources, and then to remote
peer's ones).
Since the pre-negotiation is not a typical SIP feature the mapping of the pre-negotiation can as well be
made by using the SIP MESSAGE method. This feature (whether to use OPTIONS or MESSAGE) is left
for further study. Additionally, it should be considered that several subsequent pre-negotiations can take
place for renewing the contracts leasing. Due to these reasons the recommendation of the authors of this
document is to use OPTIONS for the very first E2ENP negotiation. The MESSAGE method should be
then used from the leasing party to notify the owners of the leased information (previous pre-negotiation
contents) that leasing renewal is required. Since the MESSAGE method is also used by negotiation and
re-negotiation (e.g. multiparty scenarios), the specific meaning can be verified by checking the contents
of the respective <purpose> element of the received bid/answer PDU.
Page A.257
MIND
1.2 / 0.1
A.8.1.1.1.1
E2ENP Content
In this section we describe the SIP message bodies indicated with the keywords bid-x, answer-y in the
previous examples.
A.8.1.1.1.1.1
Bid-1.1
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="36000"/>
</e2enp:session>
<e2enp:description type="request" name="pre-negotiation"
mode=”push”/>
</e2enp:purpose>
<e2enp:qosdef name="capabilities">
<e2enp:audio:codec name48="PCMU" scope="applicable"/>
<e2enp:audio:codec name="G729" scope="applicable"/>
<e2enp:audio:codec name="G722" scope="possible"/>
<rtp:pt name="rtp-avp-0" pt="0" format="PCMU"/>
<rtp:pt name="rtp-avp-18" pt="18" format="G729"/>
<rtp:pt name="rtp-avp-9" pt="9" format="G722"/>
<e2enp:video:codec name="H263" scope="applicable"/>
<e2enp:video:codec name="H261" scope="applicable"/ >
<e2enp:video:codec name="WAVI" scope="possible"/>
<rtp:pt name="rtp-avp-34" pt="34" format="H263"/>
<rtp:pt name="rtp-avp-31" pt="31" format="H261"/>
<rtp:pt name="rtp-avp-100" pt="100" format="WAVI">
<e2enp:video:codec frame_rate_range="5,30"
frame_size_set="QCIF,CIF" color_quality_range="9100,10000"
overall_quality_range="9100,10000"/>
</rtp:pt>
</e2enp:qosdef>
<e2enp:qosdef name="contracts">
<e2enp:policy name="Let us optimize ((memory && network) || CPU)">
<e2enp:predicate id="predicate-1" first_term="optMemoryUsage"
second_term="optNetworkPerformance" function="and"/>
48
We prefer to omit the distinction between name and encoding indicated in [SDPNG01], since the encoding can be
used unambiguously as a name, since we have moved codec characterization to the <e2enp:qosdef> section (see
below).
Page A.258
MIND
1.2 / 0.1
<e2enp:predicate id="predicate-2" first_term="predicate-1"
second_term="optCpuLoad" function="or"/>
<e2enp:criterion type="expression" idref="predicate-2"/>
</e2enp:policy>
<e2enp:qos_contracts for=”audio”>
<e2enp:contract name="audio-contract-1"
sampling_rate_set="4000,8000" channel_set="1"/>
<e2enp:contract name="audio-contract-2"
sampling_rate_set="8000,12000" channel_set="1,2"/>
<e2enp:contract name="audio-contract-3"
sampling_rate_set="12000,16000" channel_set="1"/>
<rtp:map contract="audio-contract-1" format="rtp-avp-0"
peer_role="receiver"/>
<rtp:map contract="audio-contract-2" format="rtp-avp-18"
peer_role="receiver"/>
<rtp:map contract="audio-contract-3" format="rtp-avp-9"
peer_role="receiver"/>
</e2enp:qos_contracts>
<e2enp:qos_contracts for=”video”>
<e2enp:contract name="video-contract-1" frame_rate_set="10,15"
frame_size_set="CIF" color_quality_range="9100,9700"
overall_quality_range="9500,9800"/>
<e2enp:contract name="video-contract-2" frame_rate_set="15,20"
frame_size_set="QCIF" color_quality_range="9700,9850"
overall_quality_range="9800,9900"/>
<e2enp:contract name="video-contract-3" frame_rate_set="20,25"
frame_size_set="QCIF,CIF" color_quality_range="9850,9900"
overall_quality_range="9900,9960"/>
<rtp:map contract="video-contract-1" format="rtp-avp-34"
peer_role="receiver"/>
<rtp:map contract="video-contract-2" format="rtp-avp-31"
peer_role="receiver"/>
<rtp:map contract="video-contract-3" format="rtp-avp-100"
peer_role="receiver"/>
</e2enp:qos_contracts>
<e2enp:qos_contracts for=”transport”>
<e2enp:contract name="TI-1" pbr="320" sbr="320" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="80" me2edv="10" mplr="2E-2"/>
<suboption name="SI-2" me2ed="120" me2edv="20" mplr="2E-2"/>
</e2enp:contract>
<e2enp:contract name="TI-2" pbr="96" sbr="96" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="80" me2edv="10" mplr="2E-2"/>
<suboption name="SI-2" me2ed="120" me2edv="20" mplr="2E-2"/>
</e2enp:contract>
Page A.259
MIND
1.2 / 0.1
<e2enp:contract name="TI-3" pbr="86" sbr="86" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="80" me2edv="10" mplr="2E-2"/>
<suboption name="SI-2" me2ed="120" me2edv="20" mplr="2E-2"/>
</e2enp:contract>
<e2enp:contract name="TI-4" pbr="29" sbr="29" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="80" me2edv="10" mplr="2E-2"/>
<suboption name="SI-2" me2ed="120" me2edv="20" mplr="2E-2"/>
</e2enp:contract>
</e2enp:qos_contracts>
</e2enp:qosdef>
XML Example A. 27
Note that <rtp:map> does not contain nominal=”true” attribute (as described in Section
A.7.3.4.2), since the mapping between the video codecs and the video QoS contracts in this case in one to
one. This is valid also for the answer of this bid.
A.8.1.1.1.1.2
Answer-1.1
The counter-offer indicates what capabilities the Answerer supports, and to what extent. If a given
capability is supported "as is", only the corresponding identifier is indicated, along with the scope
attribute set to applicable. The higher level contracts which are taken as they are contain only the
name of the contract as reference to the information coming from the Offerer. Thus the Offerer knows
which contracts are being changed by the Answerer. In any field or element of the contract is changed the
contract should be listed anew from the Answerer, inclusively the fields that are not changed.
If a given capability is not supported, the corresponding identifier is simply omitted (in the example, the
G.729 audio codec, the WAVI video codec.
If a given capability is updated in the <e2enp:qosdef name="contracts"> element, the entire
description with the updates is returned. In any case, the <e2enp:qosdef name="contracts">
contains in a response only updated codec parameterisations. In the example, the PCMU audio codec and
the H.261 video codecs are re-parameterised by the Answerer.
Eventually, the counter-offer may list some capabilities not supported by the Offerer, as described in
Section A.7. In the example, a L16 audio codec and an MPEG-2 video codec.
Counter-offers to the <e2enp:qosdef name="contracts"> part of a bid can be proposed by the
Answerer, independently of the corresponding lines in the <e2enp:qosdef="capabilities">
element, and vice versa. In the example, the scope of the G.722 audio codec is counter-offered as
applicable in the <e2enp:qosdef name="capabilities"> element, but the corresponding
contract in the <e2enp:qosdef name="contracts"> element is kept as is.
As aforementioned, a counter-offer to the contract relative to the PCMU audio codec is proposed in the
<e2enp:qosdef name="contracts"> element, whereas the corresponding bid in the
<e2enp:qosdef name="capabilities"> element is kept as is. This flexibility is due to the
modular definition of the various elements.
Changes with respect to the original bid are indicated in boldface. In this example, the Answerer replies to
the Offerer by indicating that:
Page A.260
MIND
1.2 / 0.1
•
The G729 audio codec cannot be supported (corresponding lines removed)
•
The L16 audio codec could be supported (indicated as "possible" with configuration set)
•
The WAVI video codec cannot be supported (corresponding lines removed)
•
The MPEG-2 video codec could be supported (indicated as "possible" with configuration set)
•
Only network resource optimisation policy shall be used
•
Audio-contract-1: only a subset of the proposed sampling_range can be applied
•
Video-contract-2: only a subset of the proposed frame_rate_range can be applied
• The transport contract TI-1 is omitted by the answerer because such amount of network resources
cannot be accepted by the answerer
• The transport contract TI-2 is marked as <spare> by the answerer or the intermediate entities
because the current provider of the answerer does not support such network level QoS, but in general
the answerer technologically supports it.
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="36000"/>
</e2enp:session>
<e2enp:description type="response" name="pre-negotiation"
mode=”push”/>
</e2enp:purpose>
<e2enp:qosdef name="capabilities">
<e2enp:audio:codec name="PCMU" scope="applicable"/>
<e2enp:audio:codec name="G722" scope="applicable"/>
<e2enp:audio:codec name="L16" scope="possible"/>
<rtp:pt name="rtp-avp-0" pt="0" format="PCMU"/>
<rtp:pt name="rtp-avp-9" pt="9" format="G722"/>
<rtp:pt name="rtp-avp-11" pt="11" format="L16"/>
<e2enp:video:codec name="H263" scope="applicable"/>
<e2enp:video:codec name="H261" scope="applicable"/>
<e2enp:video:codec name="MP2T" scope="possible"/>
<rtp:pt name="rtp-avp-34" pt="34" format="H263"/>
<rtp:pt name="rtp-avp-31" pt="31" format="H261"/>
<rtp:pt name="rtp-avp-33" pt="33" format="MP2T">
<e2enp:video:codec frame_rate_range="30,30" frame_size_set="SIF"
color_quality_range="0,10000" overall_quality_range="0,10000"/>
</e2enp:qosdef>
Page A.261
MIND
1.2 / 0.1
<e2enp:qosdef name="contracts">
<e2enp:policy name="Let us optimize ((memory && network) || CPU)">
<e2enp:criterion type="optNetworkPerformance"/>
</e2enp:policy>
<e2enp:qos_contracts for=”audio”>
<e2enp:contract name="audio-contract-1" sampling-range="5000,7000"
channels="1"/>
<e2enp:contract name="audio-contract-3"/>
</e2enp:qos_contracts>
<e2enp:qos_contracts for=”video”>
<e2enp:contract name="video-contract-1"/>
<e2enp:contract name="video-contract-2" frame_rate_range="15,18"
frame_size_set="QCIF" color_quality_range="9550,9650"
overall_quality_range="9700,9850"/>
</e2enp:qos_contracts>
<e2enp:qos_contracts for=”transport”>
<e2enp:contract name="TI-2" pbr="96" sbr="96" mps="72" mbs="72"
qtp=”GUARANTEED_SERVICE”>
<suboption name="SI-1" me2ed="80" me2edv="10" mplr="2E-2"/>
<suboption name="SI-2" me2ed="120" me2edv="20" mplr="2E-2"/>
<spare provider_id=”my-telecom”>
</e2enp:contract>
<e2enp:contract name="TI-3"/>
<e2enp:contract name="TI-4"/>
</e2enp:qos_contracts>
</e2enp:qosdef>
XML Example A. 28
In this example the contracts "audio-contract-1", "video-contract-1" and "TI-3" are taken
as they are by the Answerer.
A.8.1.1.1.1.3
Bid-1.2 and Answer-1.2
The example in Section A.8.1.1.1 corresponding to these bid and answer differ from the others described
in the previous paragraphs, insofar as the <e2enp:purpose> element indicates in this case the pull
mode.
For the "OPTIONS":
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
Page A.262
MIND
1.2 / 0.1
<e2enp:description type="request" name="pre-negotiation"
mode=”pull”/>
</e2enp:purpose>
For the "Bid-1.2":
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:description type="response" name="pre-negotiation"
mode=”pull”/>
</e2enp:purpose>
… "Bid-1.2" content …
For the "Answer-1.2":
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:description type="request" name="pre-negotiation"
mode="pull"/>
</e2enp:purpose>
… "Answer-1.2" content …
XML Example A. 29
and the final reply from peer B is:
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:description type="response" name="pre-negotiation"
mode="pull"/>
</e2enp:purpose>
XML Example A. 30
Page A.263
MIND
1.2 / 0.1
A.8.1.1.1.1.4
Bid-1.3, Answer-1.3+Bid-1.4, and Answer-1.4
The example in Section A.8.1.1.1.1 corresponding to these bids and answers differ from those described
in Section A.8.1.1.1.1.1 and Section A.8.1.1.1.1.2, insofar as the <e2enp:purpose> element indicates
in this case the push-pull mode.
The "Bid-1.3" shall include as <e2enp:purpose> the following:
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
<e2enp:description type="request" name="pre-negotiation" mode="pushpull"/>
</e2enp:purpose>
XML Example A. 31
More specifically, "Answer-1.3+Bid-1.4" accounts for the case whereby the E2ENP content includes both
the bid and the answer of the Answerer. In order to distinguish the bid from the answer, each of them
shall feature a distinct <e2enp:purpose> element. This means that the push-pull pre-negotiation
results in the interleaving of two pre-negotiation sessions, each with its own identifier.
More concretely, if for instance the "Bid-1.3" features a <e2enp:purpose> element like the one
indicated above, the "Answer-1.3+Bid-1.4" shall then feature two <e2enp:purpose> elements like
the following:
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="36000"/>
<e2enp:description type="response" name="pre-negotiation"
mode=”push-pull”/>
</e2enp:purpose>
… "Answer-1.3" content …
<e2enp:purpose>
<e2enp:session user=”Kate” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.145">
<e2enp:expires time="36000"/>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="request" name="pre-negotiation" mode=”pushpull”/>
</e2enp:purpose>
… "Bid-1.4" content …
Page A.264
MIND
1.2 / 0.1
XML Example A. 32
The Answerer's bid references the Offerer's bid via the <e2enp:use> construct, insofar as the Answerer
formulates its bid based not only on Answerer's preferences (e.g. from user profile information) but also
on the Offerer's bid (and eventually based on QoS correlation and/or time synchronization constraints).
Of course, by following the above example, the "Answer-1.4" shall include as <e2enp:purpose> the
following:
<e2enp:purpose>
<e2enp:session user=”Kate” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.145">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="response" name="pre-negotiation"
mode=”push-pull”/>
</e2enp:purpose>
XML Example A. 33
A.8.1.1.2
•
Negotiation and resource reservation
Push mode
Peer A: Receiver/Offerer - Peer B: Sender/Answerer
A: Local-Admission-Control (bid-2.1):
successful
A: Local-Resource-Reservation (bid-2.1):
successful
A: INVITE (bid-2.1) -> B
B: Local-Admission-Control (bid-2.1):
answer-2.1 ⊆ bid-2.1
B: Local-Resource-Reservation (answer-2.1):
successful
B: 183 Session Progress (answer-2.1) ->A
A: Local-Resource-Reservation (answer-2.1):
Page A.265
MIND
1.2 / 0.1
successful
A: PRACK (command-start-reservation) -> B
B: 200 OK (of PRACK) (command-start-reservation) -> A
A: Network reservation (based on answer-2.1)
B: Network reservation (based on answer-2.1)
A. UPDATE (command-ready-reservation) -> B
B: 200 OK (of UPDATE) -> A
B: 180 Ringing -> A
B: 200 OK (of INVITE) -> A
A: ACK -> B
Note (1):
•
After having pre-booked local resource with respect to "Bid-2.1",
peer A finally reserves the negotiated subset "Answer-2.1", in
order to release any excess resource.
Pull mode
Peer A: Receiver/Offerer - Peer B: Sender/Answerer
A: INVITE -> B
B: Local-Admission-Control (bid-2.2):
successful
B: Local-Resource-Reservation (bid-2.2):
successful
B: 183 Session Progress (bid-2.2) ->A
A: Local-Admission-Control (bid-2.2):
answer-2.2 ⊆ bid-2.2
A: Local-Resource-Reservation (answer-2.2):
successful
A: PRACK (answer-2.2 - see Note (3))-> B
B: Local-Resource-Reservation (answer-2.2):
successful
B: 200 OK (of PRACK) (command-start-reservation) -> A
A: Network reservation (based on answer-2.2)
Page A.266
MIND
1.2 / 0.1
B: Network reservation (based on answer-2.2)
A. UPDATE (command-ready-reservation) -> B
B: 200 OK (of UPDATE) -> A
B: 180 Ringing -> A
B: 200 OK -> A
A: ACK -> B
•
Note (2):
After having pre-booked local resource with respect to "Bid-2.2",
peer B finally reserves the negotiated subset "Answer-2.2", in
order to release any excess resource.
Note (3):
"Bid-2.2" and "Answer-2.1" are substantially equivalent to
(correspondingly) "Bid-2.1" and "Answer-2.1", except for the
<e2enp:purpose> element, which features the attribute
"mode" set to "pull" and, in the case of "Answer-2.2", the
attribute "type" set to "start-reservation".
Push-Pull mode
Peer A: Sender-Receiver/Offerer - Peer B: Sender-Receiver/Answerer
A: Local-Admission-Control (bid-2.3):
successful
A: Local-Resource-Reservation (bid-2.3):
successful
A: INVITE (bid-2.3)-> B
B: Local-Admission-Control (bid-2.4):
successful
B: Local-Admission-Control (bid-2.3):
answer-2.3 ⊆ bid-2.3
B: Local-Resource-Reservation (bid-2.4):
successful
B: Local-Resource-Reservation (answer-2.3):
successful
B: 183 Session Progress (answer-2.3+bid-2.4) ->A
A: Local-Resource-Reservation (answer-2.3):
successful
Page A.267
MIND
1.2 / 0.1
A: Local-Admission-Control (bid-2.4):
answer-2.4 ⊆ bid-2.4
A: Local-Resource-Reservation (answer-2.4):
successful
A: PRACK (answer-2.4- see Note (6))-> B
B: Local-Resource-Reservation (answer-2.4):
successful
B: 200 OK (of PRACK: command-start-reservation) -> A
A: Network reservation (based on answer-2.3+answer-2.4) (Note (7))
B: Network reservation (based on answer-2.3+answer-2.4) (Note (8))
A. UPDATE (command-ready-reservation) -> B
B: 200 OK (of UPDATE) -> A
B: 180 Ringing -> A
B: 200 OK -> A
A: ACK -> B
A.8.1.1.2.1
Note (4):
After having pre-booked local resource with respect to "Bid-2.3",
peer A finally reserves the negotiated subset "Answer-2.3", in
order to release any excess resource.
Note (5):
After having pre-booked local resource with respect to "Bid-2.4",
peer B finally reserves the negotiated subset "Answer-2.4", in
order to release any excess resource.
Note (6):
"Bid-2.3"/"Bid-2.4"
and
"Answer-2.3"/"Answer-2.4"
are
substantially equivalent to (correspondingly) "Bid-2.1" and
"Answer-2.1", except for the <e2enp:purpose> element,
which features the "mode" element set to push-pull and, in
the case of "Answer-2.4", the attribute "type" set to "startreservation".
Note (7):
The “Answer-2.3” is a TSpec for receiving, the “Answer-2.4” is a
TSpec for sending.
Note (8):
The “Answer-2.3” is a TSpec for sending, the “Answer-2.4” is a
TSpec for receiving.
E2ENP Content
In this section we describe the SIP message bodies indicated with the keywords bid-x, answer-y in the
previous examples.
Page A.268
MIND
1.2 / 0.1
A.8.1.1.2.1.1
Bid-2.1
This bid refers to pre-negotiated information, by indicating the session identifier uniquely indicating that
information via the <e2enp:use> construct in the <e2enp:purpose> element. In this example, the
referred information is "Bid-1.1" (see Section A.8.1.1.1.1.1), which was used for pre-negotiating
capabilities and stream-level QoS Contracts. Alternatively, the peers could have pre-negotiated the AP
information contained in this paragraph, directly in "Bid-1.1" in order to speed up the negotiation phase
(see example in Section A.8.1.1.2.1.5).
Note, that in this example, the association between application level QoS and transport level QoS is
performed in the stream adaptation path. For each element in the adaptation path, the application level
QoS contract is referenced (which references a codec/application level QoS description) and associated
with a reference to a transport level QoS contract that describes the amount of network resources to be
used.
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="request" name="negotiation" mode=”push”/>
</e2enp:purpose>
<cfg>
<component name="audio-stream-1" media="audio”>
<alt name="AVP-audio-0”>
<rtp:session format="rtp-avp-0">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
<alt name="AVP-audio-9”>
<rtp:session format="rtp-avp-9">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7840" rtcp-port="7851"/>
</rtp:session>
</alt>
</component>
<component name="video-stream-1" media="video”>
<alt name="AVP-video-34”>
<rtp:session format="rtp-avp-34">
Page A.269
MIND
1.2 / 0.1
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
<alt name="AVP-video-31”>
<rtp:session format="rtp-avp-31">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7920" rtcp-port="7921"/>
</rtp:session>
</alt>
</component>
</cfg>
<e2enp:qoscfg level="stream">
<! --adaptation path for single streams -->
<e2enp:adapath name=“audio1” ref_component="audio-stream-1">
<e2enp:alt nominal=”true” name=“initial” ref_contract=“audiocontract-1” transport-contract=”TI-4” suboption=“SI-1”
scope="applicable"/>
<e2enp:alt name=“choice1" ref_contract=“audio-contract-3”
transport-contract=”TI-4” suboption=“SI-2” scope="applicable"/>
</e2enp:adapath>
<e2enp:adapath name=“video1” ref_component="video-stream-1">
<e2enp:alt nominal=“true” name=”initial” ref_contract=”videocontract-1” transport-contract=”TI-3” suboption=“SI-1”
scope="applicable"/>
<e2enp:alt name=“choice1” ref_contract=”video-contract-2”
transport-contract=”TI-3” suboption=“SI-1” scope=”possible”/>
</e2enp:adapath>
<! -- Possible associations of streams between user A and B -->
<e2enp:context name=”association1-1” scope="applicable">
<e2enp:comp name=”element1” ref_adapath="audio1"/>
<e2enp:comp name=”element2” ref_adapath="video1"/>
<e2enp:constraints>
<e2enp:par name=“lipsync-delay” reference="audio1" max=”2”/>
<e2enp:par name=“aggregated-bw” max=”64000”/>
</e2enp:constraints>
</e2enp:context>
<e2enp:context name=”association1-2” scope="possible">
<e2enp:comp name=”element1” ref_adapath="audio1”/>
</e2enp:context>
<e2enp:adapath name=“associations-A-B” >
Page A.270
MIND
1.2 / 0.1
<e2enp:alt nominal=”true“ name=”initial”
ref_context="association1-1”/>
<e2enp:alt name=“choice1" ref_context="association1-2”/>
</e2enp:adapath>
</e2enp:qoscfg>
XML Example A. 34
A.8.1.1.2.1.2
Answer-2.1
Concerning the SDPng/E2ENP <cfg> element, the Answerer in this example replies to the Offerer by
listing only the transport information upon which agreement has been reached.
Changes with respect to the original bid are indicated in boldface. In this example, the Answerer replies to
the Offerer by indicating that:
• The AVP-video-33 option cannot be supported, due to e.g. IPv6 not supported by the
Answerer (corresponding lines removed).
• association1-1: only a subset of the proposed lipsync-delay can be applied.
• association1-1: only a subset of the proposed aggregated-bw can be applied.
• association1-2: confirmed as applicable.
At this phase, the peers negotiate stream AP and association AP, via the <e2enp:qoscfg> element: in
this example, the Answerer replies with a subset of the bid QoS correlation and time synchronization
constraints (only changed elements are detailed: changes are indicated in boldface).
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="response" name="negotiation" mode=”push”/>
</e2enp:purpose>
<cfg>
<component name="audio-stream-1" media="audio”>
<alt name="AVP-audio-0”/>
<alt name="AVP-audio-9”/>
</component>
<component name=" audio-stream-1" media="video”>
Page A.271
MIND
1.2 / 0.1
<alt name="AVP-audio-34”/>
<alt name="AVP-audio-31”/>
</component>
</cfg>
<e2enp:qoscfg level="stream">
<!-- adaptation path for single streams -->
<e2enp:adapath name=“audio1”/>
<e2enp:adapath name=“video1”/>
<! -- Possible associations of streams between user A and B -->
<e2enp:context name=”association1-1” scope="applicable">
<e2enp:comp name=”element1” ref_adapath="audio1"/>
<e2enp:comp name=”element2” ref_adapath="video1"/>
<e2enp:constraints>
<e2enp:par name=“lipsync-delay” reference="audio1" max=”1.5”/>
<e2enp:par name=“aggregated-bw” max=”56000”/>
</e2enp:constraints>
</e2enp:context>
<e2enp:context name=”association1-2” scope="applicable">
<e2enp:comp name=”element1” ref_adapath="audio1”/>
</e2enp:context>
<e2enp:adapath name=“associations-A-B”/>
</e2enp:qoscfg>
XML Example A. 35
A.8.1.1.2.1.3
Command-start-reservation
To signal the command to a peer to start reserving resources, the E2ENP content will simply feature a
<e2enp:purpose> element with the attribute name set to start-reservation the peer is also
instructed that the reservation should be coordinated, as in the following example:
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
<e2enp:description type="request" name="start-reservation"
coordination=”true”/>
</e2enp:purpose>
XML Example A. 36
Page A.272
MIND
1.2 / 0.1
A.8.1.1.2.1.4
Command-ready-reservation
To signal the peer that reservation has been accomplished, the E2ENP content will simply feature a
<e2enp:purpose> element with the attribute name set to ready-reservation, as in the
following example:
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
<e2enp:description type="request" name="ready-reservation"/>
</e2enp:purpose>
XML Example A. 37
If the reservation ends up with successful reservation the command-ready-reservation contains only
<e2enp:purpose> element. In case the reservation has resulted with less resources as initially
required the command-ready-reservation can convey the results of the reservation using the
<e2enp:enforce> element.
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
<e2enp:description type="request" name="ready-reservation"/>
</e2enp:purpose>
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association11.video1.video-contract-2”/>
<e2enp:target name="$contract"/>
</e2enp:enforce>
XML Example A. 38
A.8.1.1.2.1.5
Leveraging additional pre-negotiated information
As anticipated in Section A.8.1.1.2.1.1, the peers could have pre-negotiated the AP information described
in the rest of this paragraph directly in "Bid-1.1", in order to speed up the negotiation phase. Following is
an example of pre-negotiation bid and answer information (for the simple case of a push mode prenegotiation), and then the negotiation bid and answer (again, push mode). In this example, we omit the
TI/SI information in order to simplify the example.
This example is based on the corresponding ones described in Sections A.8.1.1.2.1.1 and A.8.1.1.2.1.2..
•
Bid-1.1 - with stream AP and Group AP (with respect to stream Associations)
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="36000"/>
Page A.273
MIND
1.2 / 0.1
</e2enp:session>
<e2enp:description type="request" name="pre-negotiation"
mode=”push”/>
</e2enp:purpose>
<e2enp:qosdef name="capabilities">
<e2enp:audio:codec name49="PCMU" scope="applicable"/>
<e2enp:audio:codec name="G729" scope="applicable"/>
<e2enp:audio:codec name="G722" scope="possible"/>
<rtp:pt name="rtp-avp-0" pt="0" format="PCMU"/>
<rtp:pt name="rtp-avp-18" pt="18" format="G729"/>
<rtp:pt name="rtp-avp-9" pt="9" format="G722"/>
<e2enp:video:codec name="H263" scope="applicable"/>
<e2enp:video:codec name="H261" scope="applicable"/ >
<e2enp:video:codec name="WAVI" scope="possible"/>
<rtp:pt name="rtp-avp-34" pt="34" format="H263"/>
<rtp:pt name="rtp-avp-31" pt="31" format="H261"/>
<rtp:pt name="rtp-avp-100" pt="100" format="WAVI">
<e2enp:video:codec frame_rate_range="5,30"
frame_size_set="QCIF,CIF" color_quality_range="9100,10000"
overall_quality_range="9100,10000"/>
</rtp:pt>
</e2enp:qosdef>
<e2enp:qosdef name="contracts">
<e2enp:policy name="Let us optimize ((memory && network) || CPU)">
<e2enp:predicate id="predicate-1" first_term="optMemoryUsage"
second_term="optNetworkPerformance" function="and"/>
<e2enp:predicate id="predicate-2" first_term="predicate-1"
second_term="optCpuLoad" function="or"/>
<e2enp:criterion type="expression" idref="predicate-2"/>
</e2enp:policy>
<e2enp:qos_contracts for=”audio“>
<e2enp:contract name="audio-contract-1"
sampling_rate_set="4000,8000" channel_set="1"/>
<e2enp:contract name="audio-contract-2"
sampling_rate_set="8000,12000" channel_set="1,2"/>
49
We prefer to omit the distinction between name and encoding indicated in [SDPNG01], since the encoding can be
used unambiguously as a name, since we have moved codec characterization to the <e2enp:qosdef> section (see
below).
Page A.274
MIND
1.2 / 0.1
<e2enp:contract name="audio-contract-3"
sampling_rate_set="12000,16000" channel_set="1"/>
<rtp:map contract="audio-contract-1" format="rtp-avp-0"
peer_role="receiver"/>
<rtp:map contract="audio-contract-2" format="rtp-avp-18"
peer_role="receiver"/>
<rtp:map contract="audio-contract-3" format="rtp-avp-9"
peer_role="receiver"/>
</e2enp:qos_contracts>
<e2enp:qos_contracts for=”video“>
<e2enp:contract name="video-contract-1" frame_rate_set="10,15"
frame_size_set="CIF" color_quality_range="9100,9700"
overall_quality_range="9500,9800"/>
<e2enp:contract name="video-contract-2" frame_rate_set="15,20"
frame_size_set="QCIF" color_quality_range="9700,9850"
overall_quality_range="9800,9900"/>
<e2enp:contract name="video-contract-3" frame_rate_set="20,25"
frame_size_set="QCIF,CIF" color_quality_range="9850,9900"
overall_quality_range="9900,9960"/>
<rtp:map contract="video-contract-1" format="rtp-avp-34"
peer_role="receiver"/>
<rtp:map contract="video-contract-2" format="rtp-avp-31"
peer_role="receiver"/>
<rtp:map contract="video-contract-2" format="rtp-avp-100"
peer_role="receiver"/>
</e2enp:qos_contracts>
</e2enp:qosdef>
<e2enp:qoscfg level="stream">
<! --adaptation path for single streams -->
<e2enp:adapath name=“audio1” ref_component="audio-stream-1">
<e2enp:alt nominal=”true“ name=”initial” ref_contract=“audiocontract-1”/>
<e2enp:alt name=“choice1" ref_contract=“audio-contract-3”/>
</e2enp:adapath>
<e2enp:adapath name=“video1” ref_component="video-stream-1">
<e2enp:alt nominal=”true“ name=”initial” ref_contract="videocontract-1”/>
<e2enp:alt name=“choice1" ref_contract="video-contract-2”/>
</e2enp:adapath>
<!-- Possible association of streams between user A & B -->
<e2enp:context name=”association1-1” scope="applicable">
<e2enp:comp name=”element1” ref_adapath="audio1"/>
<e2enp:comp name=”element2” ref_adapath="video1"/>
<e2enp:constraints>
Page A.275
MIND
1.2 / 0.1
<e2enp:par name=“lipsync-delay” reference="audio1" max=”2”/>
<e2enp:par name=“aggregated-bw” max=”64000”/>
</e2enp:constraints>
</e2enp:context>
<e2enp:context name=”association1-2” scope="possible">
<e2enp:comp name=”element1” ref_adapath="audio1”/>
</e2enp:context>
<e2enp:adapath name=“associations-A-B” >
<e2enp:alt nominal=”true“ name=”initial”
ref_context="association1-1”/>
<e2enp:alt name=“choice1" ref_context="association1-2”/>
</e2enp:adapath>
</e2enp:qoscfg>
XML Example A. 39
•
Answer-1.1 - with stream AP and Group AP (with respect to stream Associations)
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="36000"/>
</e2enp:session>
<e2enp:description type="response" name="pre-negotiation"
mode=”push”/>
</e2enp:purpose>
<e2enp:qosdef name="capabilities">
<e2enp:audio:codec name="PCMU" scope="applicable"/>
<e2enp:audio:codec name="G722" scope="applicable"/>
<e2enp:audio:codec name="L16" scope="possible"/>
<rtp:pt name="rtp-avp-0" pt="0" format="PCMU"/>
<rtp:pt name="rtp-avp-9" pt="9" format="G722"/>
<rtp:pt name="rtp-avp-11" pt="11" format="L16"/>
<e2enp:video:codec name="H263" scope="applicable"/>
<e2enp:video:codec name="H261" scope="applicable"/>
<e2enp:video:codec name="MP2T" scope="possible"/>
<rtp:pt name="rtp-avp-34" pt="34" format="H263"/>
<rtp:pt name="rtp-avp-31" pt="31" format="H261"/>
<rtp:pt name="rtp-avp-33" pt="33" format="MP2T">
<e2enp:video:codec frame_rate_range="30,30" frame_size_set="SIF"
color_quality_range="0,10000" overall_quality_range="0,10000"/>
Page A.276
MIND
1.2 / 0.1
</e2enp:qosdef>
<e2enp:qosdef name="contracts">
<e2enp:policy name="Let us optimize ((memory && network) || CPU)">
<e2enp:criterion type="optNetworkPerformance"/>
</e2enp:policy>
<e2enp:qos_contracts for=„audio“>
<e2enp:contract name="audio-contract-1" sampling-range="5000,7000"
channels="1"/>
<e2enp:contract name="audio-contract-3"/>
</e2enp:qos_contracts>
<e2enp:qos_contracts for=”video”>
<e2enp:contract name="video-contract-1"/>
<e2enp:contract name="video-contract-2" frame_rate_range="15,18"
frame_size_set="QCIF" color_quality_range="9550,9650"
overall_quality_range="9700,9850"/>
</e2enp:qos_contracts>
</e2enp:qosdef>
<e2enp:qoscfg level="stream">
<!-- adaptation path for single streams -->
<e2enp:adapath name=“audio1”/>
<e2enp:adapath name=“video1”/>
<!-- Possible association of streams between user A & B -->
<e2enp:context name=”association1-1” scope="applicable">
<e2enp:comp name=”element1” ref_adapath="audio1"/>
<e2enp:comp name=”element2” ref_adapath="video1"/>
<e2enp:constraints>
<e2enp:par name=“lipsync-delay” reference="audio1" max=”1.5”/>
<e2enp:par name=“aggregated-bw” max=”56000”/>
</e2enp:constraints>
</e2enp:context>
<e2enp:context name=”association1-2” scope="applicable">
<e2enp:comp name=”element1” ref_adapath="audio1”/>
</e2enp:context>
<e2enp:adapath name=“associations-A-B”/>
</e2enp:qoscfg>
XML Example A. 40
•
Bid-2.1 - only referencing stream AP and Group AP (with respect to stream Associations)
Page A.277
MIND
1.2 / 0.1
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="request" name="negotiation" mode=”push”/>
</e2enp:purpose>
<cfg>
<component name="audio-stream-1" media="audio”>
<alt name="AVP-audio-0”>
<rtp:session format="rtp-avp-0">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
<alt name="AVP-audio-9”>
<rtp:session format="rtp-avp-9">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7840" rtcp-port="7851"/>
</rtp:session>
</alt>
</component>
<component name="video-stream-1" media="video”>
<alt name="AVP-video-34”>
<rtp:session format="rtp-avp-34">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7900" rtcp-port="7901"/>
</rtp:session>
</alt>
<alt name="AVP-video-31”>
<rtp:session format="rtp-avp-31">
<rtp:udp role="receive" nettype="IN" addrtype="IP4"
addr="43.196.180.1" rtp-port="7920" rtcp-port="7921"/>
</rtp:session>
</alt>
Page A.278
MIND
1.2 / 0.1
</component>
</cfg>
XML Example A. 41
•
Answer-2.2 - only referencing stream AP and Group AP (with respect to stream Associations)
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="response" name="negotiation" mode=”push”/>
</e2enp:purpose>
<cfg>
<component name="audio-stream-1" media="audio”>
<alt name="AVP-audio-0”/>
<alt name="AVP-audio-9”/>
</component>
<component name=" audio-stream-1" media="video”>
<alt name="AVP-audio-34”/>
<alt name="AVP-audio-31”/>
</component>
</cfg>
XML Example A. 42
In this case, both the Offerer and the Answerer implicitly agree on enforcing the pre-negotiated APs, by
starting streaming with the contracts indicated by the “nominal” attribute.
Should either peer decide otherwise due to some conditions applying at the time of the negotiation (and of
the start of streaming, which would apply immediately after negotiation), a reduced version of the
<e2enp:qoscfg> could be included, indicating the new default contract(s).
Remember that the default state corresponds, in the Hierarchical FSM model described in Section A.6.3,
to the initial state of a given (eventually nested) FSM.
A.8.1.1.3
Re-negotiation and resource reservation
In case of re-negotiation, the "mode" attribute of the <e2enp:purpose> element is not used.
Page A.279
MIND
1.2 / 0.1
Peer A: Receiver/Answerer - Peer B: Sender/Offerer
B: detected QoS violation/change50:
select new QoS level to enforce from pre-negotiated APs ⇒ bid-3.1
B: Local-Admission-Control (bid-3.1):
successful
B: Local-Resource-Reservation (bid-3.1):
successful
B: INVITE (bid-3.1) -> A (See Note (3))
A: Local-Admission-Control (bid-3.1):
answer-3.1 ⊆ bid-3.1
A: Local-Resource-Reservation (answer-3.1):
successful
A: 183 Session Progress (answer-3.1 - See Note (4)) ->B
B: Local-Resource-Reservation (answer-3.1)
B: PRACK (command-start-reservation) -> A
A: 200 OK (of PRACK)
A: Network reservation (based on answer-3.1)
B: Network reservation (based on answer-3.1)
B. UPDATE (command-ready-reservation) -> A
A: 200 OK (of UPDATE) -> B
A: 200 OK (of INVITE) -> B
B: ACK->A
50
Note (1):
Both peers reserve resources corresponding to the re-negotiated
QoS levels, by adding any required resource and/or releasing any
excessive resource, with respect to the amount of previously
reserved resources.
Note (2):
For a description of the "Command-start-reservation" and
"Command-stop-reservation" please refer to respectively Section
A.8.1.1.2.1.3 and Section A.8.1.1.2.1.4.
Either peer can initiate this sequence.
Page A.280
MIND
1.2 / 0.1
A.8.1.1.3.1
Note (3):
In this case a re-INVITE (as described in SIP [RFC3261], this is
an INVITE within a dialogue) is used enforce the three-way
acknowledgement, which guarantees that the peers begin
streaming with the new QoS level in a coordinated and safe
manner. This can also be utilized for forcing the peer to use
another terminal or for performing a End-to-End QoS Full Renegotiation.
Note (4):
The "Answer-3.1" in this message features the attribute "type"
set to "start-reservation".
E2ENP Content
In this section we describe the SIP message bodies indicated with the keywords bid-x, answer-y in the
previous examples.
A.8.1.1.3.1.1
Bid-3.1
In this example, with respect to the information already negotiated during previous phases (the last of
which is identified by the <e2enp:session> element wrapped by the <e2enp:use> element of the
<e2enp:purpose> element), peer B requests peer A to enforce an alternative QoS Contract. More
specifically, peer B requests peer A to enforce the stream-level QoS contract "video-contract-2",
instead of the default one "video-contract-1", with respect to the video stream "video1" of the
currently active association, "association1-1". This command is expressed via the “enforce”
element 51.
Furthermore, peer A can discover that video-contract-1 is no longer applicable with the new type
of access network/network provider: therefore peer A signal a "block" for that contract. Should spare
contracts be available and now valid, an “unblock” signal could also be included in this bid.
By associating the transport-contract with audio/video QoS contracts (that contain codec
descriptions and application layer QoS parameters, automatically the right transport contract is referenced
in the re-negotiation process. Due to simplicity reasons for the following re-negotiation examples the
dotted-separation form is used as identified in Section A.7.3.7.1.
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="request" name="re-negotiation"/>
</e2enp:purpose>
51
In this XML fragment the use of XPath is shown in a simplified way, in order to capture the concept of the
<e2enp:enforce> section. A rigorously formal description of the overall hereby-proposed SDPng extensions
will be provided at a later time.
Page A.281
MIND
1.2 / 0.1
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association11.video1.video-contract-2”/>
<e2enp:target name="$contract"/>
</e2enp:enforce>
<e2enp:block>
<e2enp:contract_level path=”associations-A-B.association11.video1.video-contract-1”/>
<e2enp:target name="$contract"/>
</e2enp:block>
XML Example A. 43
Alternatively, peer B can also simply indicate to peer A some higher-level information, whereby peer A
would then resolve the remaining lower-level information by resorting to default values. For instance, the
following <e2enp:enforce> element:
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association11.video1”/>
<e2enp:target name="$stream"/>
</e2enp:enforce>
XML Example A. 44
would force peer A to use "video-contract-1" for the "video1" stream, since that contract
was specified as default in the pre-negotiated <e2enp:qoscfg> element.
Furthermore, peer B can request peer A to switch to a totally different group of streams, selected out of
the pre-negotiated information. For instance, assumed the currently active association of streams between
peer A and peer B is "association1-1", peer B can request peer A to select the
"association1-2", like in the following example of <e2enp:enforce> element:
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association1-2"/>
<e2enp:target name="$association"/>
</e2enp:enforce>
XML Example A. 45
A.8.1.1.3.1.2
Answer-3.1
According to requirement [31], the Answerer should limit its reaction to either approve the Offerer's bid,
or simply choose a lower QoS level, to be selected from pre-negotiated information. Following the
example indicated in the previous paragraph, peer A could then choose either to accept the proposal as is,
or select an alternative option out of the pre-negotiated information, which still satisfies the original bid of
the Offerer.
In the former case, the "Answer-3.1" would look like the following:
<e2enp:purpose>
Page A.282
MIND
1.2 / 0.1
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="response" name="re-negotiation"/>
</e2enp:purpose>
XML Example A. 46
The absence of the <e2enp:enforce> element in the Answerer's response indicated that the Answer
has agreed on the Offerer's bid.
In the case the Answerer (peer A in this example) preferred a lower QoS level, the "Answer-3.1" would
look like the following:
<e2enp:purpose>
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="response" name="re-negotiation"/>
</e2enp:purpose>
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association1-1.video1.
video-contract-3"/>
<e2enp:target name="$contract"/>
</e2enp:enforce>
XML Example A. 47
In this example we assume that a video-contract-3 defining a lower level of QoS compared to the one
defined by the proposed video-contract-1, has been previously negotiated between the two peers (not
shown in the previous examples). Alternatively, peer A can specify a lower level of QoS by specifying
another association, like described in the previous paragraph:
<e2enp:purpose>
Page A.283
MIND
1.2 / 0.1
<e2enp:session user=”Mary” session_id="2890844526"
version="2890842807" nettype="IN" addrtype="IP4"
addr="43.196.180.1">
<e2enp:expires time="3600"/>
</e2enp:session>
<e2enp:use>
<e2enp:session user=”Mary” session_id="2890843112"
version="2890841393" nettype="IN" addrtype="IP4"
addr="43.196.180.1"/>
</e2enp:use>
<e2enp:description type="response" name="re-negotiation"/>
</e2enp:purpose>
<e2enp:enforce>
<e2enp:contract_level path=”associations-A-B.association1-2"/>
<e2enp:target name="$association"/>
</e2enp:enforce>
XML Example A. 48
A.8.1.2
One-to-many communication scenario
A.8.1.2.1
Pre-Negotiation
•
Push mode
Peer A: Offerer - Peers B1 ... Bn: Answerers
A: Local-Admission-Control: (bid-1.1)
successful
A: OPTIONS (bid-1.1) -> Bj
Bj: Local-Admission-Control (bid-1.3):
answer-1.1.Bj
Bj: 200 OK (answer-1.3.Bj) ->A
•
j ∈ {1,n}
Note (1):
the various answers “Answer-1.1.Bj” can coincide, partially
differ, or differ completely from each other. Substantially they
are equivalent to "Answer-1.1" described in Section
A.8.1.1.1.1.2.
Note (2):
after receiving all replies from peer Bj, peer A may enforce QoS
correlation and time synchronization constraints, and thus
renegotiate with peers Bj new lower QoS levels.
Pull mode
Peers A1 … An: Offerers - Peer B: Answerer
Page A.284
MIND
1.2 / 0.1
Aj : OPTIONS -> B
B: 200 OK (bid-1.2) -> Aj
Aj: Local-Admission-Control (bid-1.2):
answer-1.2.Aj
Aj: OPTIONS (answer-1.2.Aj) -> B
Bj: Local-Admission-Control (answer-1.2.Aj):
successful
B: 200 OK (answer-1.2.Aj) -> Aj
j ∈ {1,n}
Note (3):
the various answers “Answer-1.2.Aj” can coincide, partially
differ, or differ completely from each other. Substantially
“Answer-1.2.Aj” are equivalent to "Answer-1.2" described in
Section A.8.1.1.1.1.3. "Bid-1.2" is substantially equivalent to the
one described in Section A.8.1.1.1.1.3 as well.
Note (4):
during local admission control, peer B could enforce QoS
correlation and time synchronization constraints before replying
to each peer Aj, but the various Aj generally carry out this
E2ENP phase independently of each other.
Therefore it is not generally possible to withhold replies to
OPTIONS beyond the corresponding SIP timer duration.
Alternatively, peer B can decide to accept request within a
certain time window, after which peer B can enforce QoS
correlation and time synchronization constraints and
consequently carry out new pre-negotiations with each peer Aj.
In this case, peer B would then take the Offerer role. As an
example, peer B could be a sender like in the lecture scenario
(see Section A.3.3.2), which pre-negotiates QoS with each
receiver first individually, and then eventually reruns some prenegotiation in order to enforce QoS correlation and time
synchronization constraints.
Note (5):
see Note (1) in Section A.8.1.1.1
Pre-negotiating bi-directional connections for the case one-to-many may result in an actual many-to-many
connection; therefore this case is not treated here. As by the pre-negotiation described in Section
A.8.1.1.1 the SIP MESSAGE method can also be used here.
A.8.1.2.2
Negotiation and resource reservation
Bi-directional negotiation is not hereby presented, since this might result in a case of many-to-many
scenario (see Section A.8.3), whereby particular attention to synchronization issues should be paid. The
following scenario are thus valid for the case where the "One" peer of the one-to-many relationship is a
sender (receiver) and each of the "Many" peer of such relationship is a receiver (sender).
•
Push mode
Peer A: Offerer - Peers B1 ... Bn: Answerers
Page A.285
MIND
1.2 / 0.1
A: Local-Admission-Control (bid-2.1 - see Note (1)):
successful
A: Local-Resource-Reservation (bid-2.1):
successful
A: INVITE (bid-2.1) -> Bj
Bj: Local-Admission-Control (bid-2.1):
answer-2.1.Bj ⊆ bid-2.1
Bj: Local-Resource-Reservation (answer-2.1.Bj):
successful
Bj: 183 Session Progress (answer-2.1.Bj) ->A
A: Eventually correlates streams coming from or going to the different Bj
A: Local-Resource-Reservation (answer-2.1.Bj):
successful (Note (2))
A: PRACK (command-start-reservation) -> Bj
Bj: 200 OK (of PRACK) (command-start-reservation) -> A
A: Network reservation (Note (3))
Bj: Network reservation (Note (4))
A. UPDATE (command-ready-reservation) -> Bj
Bj: 200 OK (of UPDATE) -> A
Bj: 180 Ringing -> A
Bj: 200 OK (of INVITE) -> A
j ∈ {1, n}
A: ACK -> Bj
•
Note (1):
"Bid-2.1" is substantially equivalent to the one described in
Section A.8.1.1.2.1.1.
Note (2):
Balance resources upon the answers of Bj by releasing any excess
resource.
Note (3):
By using the command-start-reservation signalling, peer A will
be able to determine if and when network resource reservations
should be carried out based on all {"Answer-2.1.Bj"}, or only on
whatever subset thereof is currently available.
Note (4):
Based on the Bj’s answer-2.1.Bj
Pull mode
Page A.286
MIND
1.2 / 0.1
Peers A1 … Am: Offerers - Peer B: Answerer
Aj: INVITE -> B
B: Local-Admission-Control (bid-2.2):
successful
B: Local-Resource-Reservation (bid-2.2):
successful
B: 183 Session Progress (bid-2.2.Aj) -> Aj
Aj: Local-Admission-Control (bid-2.2.B):
answer-2.2.Aj ⊆ bid-2.2 (Note (5))
Aj: Local-Resource-Reservation (answer-2.2.Aj):
successful
Aj: PRACK (answer-2.2.Aj - see Note (6)) -> B
B: Eventually correlates streams coming from- or going to- the different Aj
B: Local-Resource-Reservation (answer-2.2.Aj):
successful
B: 200 OK (of PRACK) (command-start-reservation) -> Aj
Aj: Network reservation (Note (7))
B: Network reservation (based on all {answer-2.2.Aj})
Aj. UPDATE (command-ready-reservation) -> B
B: 200 OK (of UPDATE) -> Aj
B: 180 Ringing -> Aj
B: 200 OK -> Aj
j ∈ {1, m}
Aj: ACK -> B
Note (5):
the various answers “Answer-2.2.Aj” can coincide, partially
differ, or differ completely.
Note (6):
"Bid-2.2" and "Answer-2.2.Aj" are substantially equivalent to
(correspondingly) "Bid-2.1" and "Answer-2.1", except for the
<e2enp:purpose> element, which features the attribute
"mode" set to "pull" and, in the case of "Answer-2.2.Aj", the
attribute "name" set to "start-reservation".
Note (7):
Based on the Bj’s "Answer-2.2.Aj"
Page A.287
MIND
1.2 / 0.1
Note (8):
By using the command-start-reservation signalling, peer A will
be able to determine if and when network resource reservations
should be carried out based on all {"Answer-2.2.Aj"}, or only on
whatever subset thereof is currently available.
Negotiating bi-directional connections for the case one-to-many may result in an actual many-to-many
connection; therefore this case is not treated here.
A.8.1.2.3
Re-negotiation
In general the re-negotiation of multiparty connections (as the one-to-many connections are), should be
considered equivalent to the case of one-to-one connections. The requirements set forth in Section
A.4.5.1.4 lead to only two special cases, when more than one stream should be re-negotiated
simultaneously. These two cases are determined by the following circumstances:
•
If the central component (the “one”) discovers a violation, it should check if the affected stream
is a stream of a group and if it belongs to a group, is the context of the group in sense of QoS
affected. By single streams and by discovering that the context of the group is not affected the
central component performs one-to-one negotiation with the respective peer, otherwise the
central component performs one-to-many re-negotiation as described in the first case below.
•
If one of the “many” discovers a violation it signals this the central component in one-to-one
fashion, since the “many” do not know about the eventual stream grouping performed by the
central component. In order to decide how to proceed the central component checks the
dependencies of the affected stream:
o
If the stream does not belong to a group or the context of the group is not affected, the
central component continues the negotiation in one-to-one fashion.
o
If the central component discovers dependencies affecting not only the single stream, it
signals the waiting Offerer (as described below – case 2) that from now on it would be
responsible for the re-negotiation. The Offerer should cancel its call and wait for an
offer from the central component.
The following are the examples on the two one-to-many re-negotiation cases:
1.
The central party of a given one-to-many connection discovers a violation affecting a single
stream of the given group thereof and, according to the profile settings (i.e. to the pre-negotiated
high-level APs) of this group, performs the necessary adaptation of the whole stream group. In
the case one-to-many connections, it is in fact only the peer acting as the “one”, who takes care
of stream grouping.
Peer A: The peer acting as “one” discovers the violation - Peers B1.. Bm: Affected peers
A: detected QoS violation/change:
select new QoS level to enforce from pre-negotiated APs ⇒ bid-A|Bj
(bid-1j may be the same or different for every Bj)
A: Local-Admission-Control (bid-A|Bj):
successful
A: Local-Resource-Reservation (bid-A|Bj):
successful
Page A.288
MIND
1.2 / 0.1
A: INVITE (bid-A|Bj) -> Bj
Bj: Local-Admission-Control (bid-A|Bj):
answer-Bj ⊆ bid-A|Bj
every Bj)
(answer-Bj is drawn from pre-negotiated APs, and may be the same or different for
Bj: Local-Resource-Reservation (answer-Bj):
successful
Bj: 183 Session Progress (answer-Bj) ->A
A: Eventual reconfiguration of the stream-group to meet the requirements of the single Bj-s
and avoid eventual multiple-source of failure caused by one or many peers of the affected
group.
A: Local-Resource-Reservation (answer-Bj)
A: PRACK (command-start-reservation) -> Bj
Bj: 200 OK (of PRACK)->A
Bj: Network reservation (based on answer-Aj)
A: Network reservation (based on all answer-Aj)
A. UPDATE (command-ready-reservation) -> Bj
Bj: 200 OK (of UPDATE) -> A
j ∈ {1,m}
Bj: 200 OK (of INVITE) -> A
A: ACK -> Bj
2.
One of the “many“ peers discovers a violation
Peer B: one of the “many”, discovering the violation - Peers A: Responsible for the
stream grouping
B: detected QoS violation/change:
select new QoS level to enforce from pre-negotiated APs ⇒ bid-1
B: Local-Admission-Control (bid-1):
successful
B: Local-Resource-Reservation (bid-1):
successful
B: MESSAGE (bid-1) -> A
A: Check the necessity of the group reconfiguration:
Page A.289
MIND
1.2 / 0.1
Reconfiguration necessary
A: 200 OK(of MESSAGE + answer-1)->B (The answer-1 signalises that A is notified about
the violation and is ready to take care).
… The rest is like the example above
As by the re-negotiation in the one-to-one case (see Section A.8.1.1.3) an INVITE within a dialogue is
used if the coordinating party discovers the QoS violation/change. In case it is the one of the many peers,
which do not coordinate, this peer would send a message to the coordinator using the MESSAGE method.
A.8.2 Third-Party-Assisted Negotiation Scenario
This is an example of how third-party-assisted negotiation as described in Section A.3.3.1 and Section
A.4.5.7 can be performed using E2ENP.
The negotiating parties are:
A – The peer for which the mediation is being done
B – The Mediator peer
C – The Offerer peer, which addresses the Mediator
The third-party-assisted negotiation is being triggered when an Offerer calls a mediating device and this
respective peer discovers that it cannot handle the call itself but has the possibility to delegate the call to
another Answerer. The discovered Answerer is an alternative device from the perspective of the
Mediator, which the calling Offerer may use instead of the Mediator and by respective approval of the
user, which device the Mediator is.
A.8.2.1
Pre-negotiation
The purpose of pre-negotiations with a Mediator is to allow the Mediator gathering information about
those peers, which may be involved in possible future redirections. The Mediator may do this by using
some service discovery mechanism like JINI [JINI], Bluetooth SDP [BLUE], etc., or by directly calling
the affected peers for which the facilitation is being done.
In the latter case, the pre-negotiation can be performed similarly to the case of one-to-one prenegotiations, whereby the Mediator acts as the Offerer and the peer, for which the mediation is done, acts
as the Answerer,. To this extent, a special indication in the <e2enp:purpose> element is required, to
indicate that the Offerer is the Mediator (<e2enp:mediation mode=”third-partyassisted”/>).
In the case that the party for which the mediation is done starts the pre-negotiation with the Mediator the
SIP-scheme is as follows:
A: REFER ->B
B: 202 Accepted ->A
B: OPTIONS -> A
A: 200 OK (answer) ->B
B: NOTIFY (answer or reference to the answer)->A
A: 200 OK
Page A.290
MIND
1.2 / 0.1
The Mediator just picks the settings of A (answer) and uses them to perform the mediation.
The pre-negotiation between the mediating peer and the Offerer is very much the same as by the one-toone pre-negotiation with the indication in the <e2enp:purpose> element that the Answerer is the
mediator (<e2enp:mediation mode=”third-party-assisted”/>). The Offerer should use
push or push-pull mode to trigger the facilitating functionality of the Mediator. Instead of using “200 OK”
as answer for the OPTIONS the Mediator uses “300 Multiple Choices ” thus indicating that it is not the
peer which is going to communicate. The Offerer is already informed on this stage about the existence of
an alternative peer and in some cases, where the called user is informed and agrees on the usage of the
alternative peer, the Offerer may directly start a negotiation with the alternative peer by applying the oneto-one negotiation scheme.
A.8.2.2
Negotiation
The third-party-assisted negotiation should always be performed in push or push-pull mode with the
Mediator in order to trigger the facilitating functionality of the mediating peer in case it cannot support a
bid.
C: Local admission control (bid1):
successful
C: Local resource reservation (bid1):
successful
C: INVITE (bid1)->B
B: Local admission control(bid1): unsuccessful (B cannot support such settings as in
bid1)
B: 183 Session Progress(answer1) ->C (answer1 contains information that B would be a
mediator and C should expect eventually 300 Multiple Choices as a reply later)
C: PRACK ->B
B: 200 OK(PRACK) ->C
B: Check, if alternatives are available (Ask naming, registration service): successful
B: Check alternatives (These are the settings of A, which B eventually knows from a
pre-negotiation): successful
B: Ask if the user agrees on the call: successful (This information can be retrieved from
the user profile or by direct signalling the user on the spot, e.g. by popping up a GUI
window or by playing a tone. )
B: INVITE (bid2) ->A
(bid2 is a combination of bid1 and indication that B is a Mediator)
A: Local admission control(bid2):
answer2 ⊆ bid2
A: 200 OK (answer2)
B: ACK->A
Page A.291
MIND
1.2 / 0.1
B: Inform the user that the call is being redirected and on what device.
B: Reconfigure answer2 to inform C, which is the alternative service:
answer2a
B: 300 Multiple Choices (answer2a) ->C
B: BYE ->A
A: 200 OK ->B
As a result of this negotiation peer C knows who is peer A and the settings of it and can start a normal
one-to-one negotiation with it (see one-to-one negotiation example).
A.8.2.3
Re-negotiation
Performing a re-negotiation over a Mediator makes sense only in case of full re-negotiation when a new
device should be chosen to communicate with, otherwise the re-negotiation would become too complex.
This would in fact contradict the requirement of simplicity of E2ENP, and would be in any case not really
logical, since the Offerer already knows from the Negotiation phase who exactly its Answerer is. By renegotiation going over a Mediator, the Mediator acts as a proxy. In the case of full re-negotiation this
process is the same as the pre-negotiation and negotiation described above. By re-negotiation, the
Mediator should also fulfil the requirement on the completeness of the negotiated data.
A.8.3 Many-to-many communication scenario
The construction and the negotiation of the many-to-many communication are context dependant with
respect to the considered scenarios, e.g. conferencing, gaming, etc. A general solution is not possible for
this case, but taking some ready, topic-dependant scenarios like in [Rosen01] and [Rosen01a] and
developing them in terms of E2ENP should help the understanding how E2ENP functions by multiparty
connections. The following example from [Rosen01a] is connected with ad hoc networking.
The example below (Figure A.13) is called “Transitioning to ad hoc”(see chapter 5 “Ad-hoc Centralized
Conferences” of [Rosen01a] for more details):
Page A.292
MIND
1.2 / 0.1
Figure A.13: Example of Many-to-Many Scenario (partly from [Rosen01])
The places indicated with dashed rectangles (Figure A.13) should be considered as places where
respective network reservations take place. The messages on these places should be changed accordingly
to support the reservations. Considering the numbering in the above diagram the following steps should
be taken to apply the E2ENP:
Page A.293
MIND
1.2 / 0.1
•
At number 1 – A supplies B with its QoS view
•
At number 4 – B supplies the Conference Server with the QoS view of A and B
•
At number 5 – The Conf. Server delivers his view on the conference to B and B makes the
reservations for himself up to the server.
•
At number 7 – A gets to know the Conf. Server view on the conference from B
•
At number 9 – A invites the Conf. Server with the delivered from B server view on the QoS
Page A.294
MIND
1.2 / 0.1
Figure A.14a: Complete Many-to-Many Scenario
Page A.295
MIND
1.2 / 0.1
Figure A.14b: Complete Many-to-Many Scenario
Page A.296
MIND
1.2 / 0.1
Page A.297
MIND
1.2 / 0.1
Figure A.14c: Complete Many-to-Many Scenario
•
At number 10 – A makes the reservations for himself up to the server
•
At number 16 – B supplies C with the view of the server on the conference
•
At number 18 – C supplies the server with his view on the conference restricted according to the
information from B
•
At number 19 – C makes the reservations for himself up to the server
•
At number 20 – C informs B that he is ready
•
Additionally B should inform the conference server that all the partners are ready and the server
should deliver a start command to all.
From this example it is evident that some ideas from the one-to-one scenario concerning the reservations
can be also applied to the peer-to-peer communication between the users and the conference server. With
this respect it is evident that E2ENP negotiation pattern is applicable also to existing solutions (see the
dashed frames in Figure A.13). The complete scenario is shown in Figure A.14a, Figure A.14b and Figure
A.14c. The bids and the answers are common to those in Section A.8.1.1.2. This example depicts the
reservation procedure with SIP-messages in the same manner as by the one-to-one scenario, the only
difference is what kind of messages are put as E2ENP overhead. According to the example above there
are three different roles, which the end-peers can play:
o
Ad-Hoc-conference-initiator – Like B
o
Already-conference-participant - Like A
o
New-conference-participant – Like C
These three roles correspond three different communication patterns with the Conference Server with
respect to the exchanged E2ENP-messages.
The biggest communication overhead has B (the Ad-Hoc-conference-initiator), since it carries all the
E2ENP-messages of the already-conference-participants. This capability of B is a sort of mediation
capability to initialise the conference by enforcing the affected peers to negotiate with the Conferencing
Server and by ending of the negotiating to transfer the controls to the server.
The smallest communication overhead has an already-conference-participant like A, since the Conference
Server is being already informed about the profile of A via B and A needs only to remind the Server
which profile belongs to it (Figure A.14b – message 15).
The new-conference-participant C gets to know the validated from the Conference Server profiles of the
already-conference-participants, thus minimizing its decision set and enabling it to meet a quicker
agreement with the Conference Server. The communication overhead of C is thus approximately the same
as by the one-to-one communication, since it has to meet the agreement with the Server by itself.
A.8.4 Some examples on failure cases
The following examples illustrate some of the failure cases described in Section A.7.4.
A.8.4.1
•
One-to-one communication
Pre-negotiation
Page A.298
MIND
1.2 / 0.1
Peer A: Offerer - Peer B: Answerer
A: Local-Admission-Control (bid-1.1):
successful
A: OPTIONS (bid-1.1) -> B
B: Local-Admission-Control (bid-1.1):
unsuccessful
B: 600 Busy/603 Decline
Note (1):
•
The Answerer answers with 600 Busy if at the moment there is
no capacity to handle any call. Alternatively, the Answerer might
answer with 603 Decline indicating at what later time the call can
take place, should this time is known. The same can be used both
push and pull modes but in the pull mode the OPTIONS call
contains no bid.
Negotiation
Peer A: Offerer - Peer B: Answerer
A: Local-Admission-Control (bid):
successful
A: Local-Resource-Reservation (bid):
successful
A: INVITE (bid) -> B
B: Local-Admission-Control (bid):
not successful
B: 600 Busy/603 Decline/606 Not Acceptable/380 Alternative Service
Note (2):
The Answerer issues 600 Busy if some other Offerer was quicker
with in issuing the call and occupied all the available capacities
of the Answerer.
The Answerer issues 603 Decline if some other Offerer was
quicker with issuing the call and occupied all the available
capacities of the Answerer but the Answerer knows how long the
call shall continue. This is also the case that a similar transaction
with respect to priority is being processed at the moment and the
caller has to wait.
The Answerer issues 606 Not Acceptable if the Offerer asks for
QoS support that is not available at the moment.
The Answerer issues 380 Alternative Service if the conditions
of the Offerer are not acceptable for him but he knows an
Page A.299
MIND
1.2 / 0.1
alternative service, which can support these conditions. This call
should be used with automatic services like VoD.
In any of the above cases the Offerer may start a new call with
OPTIONS since the pre-negotiated conditions may no longer be
valid.
This scheme is applicable for all communication modes (push,
pull, push-pull). The only difference between them is the sending
of an initial bid with the INVITE or sending it later (pull mode).
•
Re-negotiation
The failure cases by the re-negotiation are the same as by the negotiation. The respective error
indications are returned as a reply to the re-INVITE calls of the Offerer.
A.8.4.2
One-to-many communication
The structure of the negotiation phases by the one-to-many scenario is very much like the one-to-one
scenario, to this extent the E2ENP error cases described in the one-to-one scenario (Section A.8.4.1) are
also valid in this case. Since the one-to-many scenario is connected with the possibility of multiple
failures caused by the “many” peers, the central component (the “one”) should have the ability to cope
with such failures. The following are some suggestions how these may be treated:
1. Every negotiation connection between the peer acting as the “one” and each of those acting as the
“many” should be considered as single standalone one, with respect to SIP signalling. In this way the
peers acting as “many” involved in the negotiation phase do not need to know about the failures,
which some peers of the group make. The failure treatment takes place only at the central component.
2. If some of the negotiation connections do not succeed within the time limit, they would be called at
later time for repeated negotiation. The central component would detect this either by time-out of a
SIP call, or by receiving a SIP-error message from the called party. Since, E2ENP has a requirement
for consistency but not for isolation, it would be enough to save the current data of the unsuccessful
calls to have a reference on their current state, before the failure, by the repetition of the call. This
means that no complete state saving of the E2ENP runs is necessary, since no “undo” is necessary.
3. The central party should be able to reconfigure the streams on line. If some of the streams do not
succeed to be renegotiated within the time limit, the central component reconfigures accordingly only
those which have succeeded and tries to renegotiate the unsuccessful ones at later moment. Here again
the successful negotiations do not need to know that some of them failed.
4. The central component tries to call the parties with unsuccessful negotiation several but limited
number of times, e.g. 3 times. If there are parties whose negotiation phases did not succeed after the
3rd call, they would be thrown out of the group and their streams would be eventually cancelled, if for
example the RTP-signalling over the data connection is also nonexistent. This approach should give
possibility to the unsuccessful “many” to have chance to recover and eventually start the negotiation
call by themselves52.
5. The parallel performance of the negotiation calls enables the quick execution of the negotiation. To
this extent the central component should have possibility flexibly to reconfigure its resources. It is
necessary to know how many parties in parallel the central component can serve and if this limit is
exceeded the central component issues 486 Busy Here or 380 Alternative Service (if the central
component is a service and knows an alternative one).
52
This would require additional XML-signalling to inform the unsuccessful parties, when they would be allowed to
the negotiation again, in order not to interfere within a successful negotiation and destroy it.
Page A.300
MIND
A.8.4.3
1.2 / 0.1
Third-party-assisted E2ENP
If the relocation search fails:
A: Local admission control (bid1):
successful
A: Local resource reservation (bid1):
successful
A: INVITE (bid1)->B
B: Local admission control (bid1):
unsuccessful (B cannot support such settings as in bid1)
B: 183 Session Progress (answer1) ->A
(answer1 contains information that B would be a mediator and A should
expect eventually 300 Multiple Choices as a reply later)
A: PRACK ->B
B: 200 OK (of PRACK) ->A
B: Check, if alternatives are available (Ask naming, registration service):
unsuccessful
(the failure may happen also on the next line)
B: Check alternatives (These are the settings of C, which B eventually knows
from a pre-negotiation): unsuccessful
B: 606 Not Acceptable ->A
The Mediator signals that no alternative was found and the Offerer should call again in pull mode,
adapting to the settings of the Mediator.
If the user declines the call relocation, the possible result of the negotiation is:
A: Local admission control (bid1):
successful
A: Local resource reservation (bid1):
successful
A: INVITE (bid1)->B
B: Local admission control (bid1):
unsuccessful (B cannot support such settings as in bid1)
B: 183 Session Progress (answer1) ->A
Page A.301
MIND
1.2 / 0.1
(answer1 contains information that B would be a mediator and A should
expect eventually 300 Multiple Choices as a reply later)
A: PRACK ->B
B: 200 OK (of PRACK) ->A
B: Check, if alternatives are available (Ask naming, registration service):
successful
B: Check alternatives (These are the settings of C, which B eventually knows
from a pre-negotiation): successful
B: Ask if the user agrees on the call: unsuccessful (This information can be
retrieved from the user profile or by direct signalling the user on the spot, e.g.
by popping up a GUI window or by playing a tone, etc.)
B: 480 Temporarily Unavailable / 603 Decline / 606 Not Acceptable ->A
The Mediator replies with:
•
480 Temporarily Unavailable, if the user does not react on the signal or the popped up window
for certain time, she/he should be considered unavailable.
•
603 Decline, if the user explicitly declines the call
•
606 Not Acceptable, if the user declines the delegation of the call
If the negotiation with the expected answerer (the C party) is unsuccessful or the to be delegated to party
does not accept the call.
A: Local admission control (bid1):
successful
A: Local resource reservation (bid1):
successful
A: INVITE (bid1)->B
B: Local admission control (bid1):
unsuccessful (B cannot support such settings as in bid1)
B: 183 Session Progress (answer1) ->A
(answer1 contains information that B would be a mediator and A
should expect eventually 300 Multiple Choices as a reply later)
A: PRACK ->B
B: 200 OK (of PRACK) ->A
B: Check, if alternatives are available (Ask naming, registration service):
successful
Page A.302
MIND
1.2 / 0.1
B: Check alternatives (These are the settings of C, which B eventually knows
from a pre-negotiation):
successful
B: Ask if the user agrees on the call: successful
(This information can be retrieved from the user profile or by direct signalling
the user on the spot, e.g. by popping up a GUI window or by playing a tone,
etc )
B: INVITE (bid2) ->C
(bid2 is a combination of bid1 and indication that B is a Mediator)
….(Something goes wrong with C)
B: Inform the user of B that the relocation was not successful, eventually ask
what to do by popping up a window.
B: 480 Temporarily Unavailable / 603 Decline / 606 Not Acceptable ->A
The meaning of these answers is:
•
480 Temporarily Unavailable, if the user does not react on the signal or the popped up window
for certain time, she/he should be considered unavailable.
•
603 Decline, if the user explicitly declines the call
•
606 Not Acceptable, if the user wants to communicate, but the delegation of the call is gone
wrong. This answer would enable the initiation of a new negotiation with the Mediator as an
Answerer; the Offerer should take care of performing the new negotiation in pull mode in order
to adapt himself to the profile of the Mediator by not triggering its facilitating functionality.
Page A.303
MIND
1.2 / 0.1
A.9. Security Considerations
This chapter discusses some aspects considering security with respect to SDPng and SIP.
If the contents of the SIP message body (SDPng) are private and should be treated according to security
policies they might be encrypted.
The use of Digital Certificates might be used for authenticating the negotiations bids and answers.
Provider-specific Digital Certificates might be as well used to identify the blocked/unblocked QoS
contracts in order to let intermediate components (proxies) verify the authenticity of the calls without
changing them.
Additional techniques for confidentiality and integrity support, with respect to the negotiated information,
should also be considered
Fine-grained requirement analysis should be carried out over the current list of requirements, so as to
identify potential security problems when non-mandatory requirements are not taken into account and/or
when optionally prohibited requirements are taken into account.
On the issue of firewalls, further thorough investigations, definitions and exact specifications on
intermediate components should be made.
Finally, there are many security aspects with respect to the interworking between service domains and
transport domains, when E2ENP is applied. More information can be found in the main document in
Chapter 4.
Page A.304
MIND
1.2 / 0.1
A.10. Related Work
This section indicates why and how the state of art not sufficient either to cope with the all the goals set
forth in Chapter 2, nor to meet the requirements identified in Section A.4.
We have followed and participated to the discussion in the IETF MMUSIC WG concerning QoS and
capabilities negotiation and the on-going SDPng specification. However, in our work we drafted a
specification based on an original use of SDPng, which partially diverges from the current status of the
discussion in MMUSIC. We took this decision, for the sake of explaining the E2ENP concepts in more
concrete terms, without waiting for the SDPng specification to be finalized. To this extent, we plan in any
case to harmonise our specification with the final SDPng version, or even contribute to the preparation
thereof, once the E2ENP concepts will have been properly reviewed after a necessary testing phase.
The [RFC2198] and [RTP-Prof] describe possibilities of quick re-negotiations via in-band signalling.
However this kind of signalling concerns only change of codecs and the redundant support of differently
coded media without considering the respective effects when QoS should be supported. Similar approach
with in-band signalling is also mentioned in [RFC2703].
In [SIPRES01], [SIPRES07], [Marsh00], the authors present a multi-phase call-setup mechanism that
makes network QoS and security establishment a precondition to sessions initiated by the Session
Initiation Protocol (SIP) and described by the Session Description Protocol (SDP). Network resources are
reserved before the session is started using existing network resource reservation mechanisms (like
RSVP). The resource management protocol is interleaved between two phases of call signalling and
participants are invited after resources are available in the network. A confirmation of the preconditions is
explicitly signalled. Resource management is done only for the network resources. An extension to SDP
is introduced to determine whether the preconditions are met. Ongoing work on reservation preconditions
[SIPRES07] makes use of the [100rel06] and [SIPUP01] for establishing the preconditions. Additionally
[SIPRES07] discusses re-negotiation possibilities in accordance with the Offer/Answer model
[SDPOA02]. [SIPRES07] identifies the necessity of meta-information connected with the reservation
preconditions, since the carrier protocol (e.g. SIP) might not explicitly support stream specific
preconditions. Since [SIPRES07] considers SDP as a description model, the proposed meta-information is
not a protocol due to the lack of expressiveness of SDP and this meta-information concerns only the
single media streams.
However [SIPRES01], [SIPRES07], [Marsh00] do not consider pre-negotiation of QoS; the integration of
local and peer resource management; the negotiation of alternative QoS levels and adaptation paths; the
possibility of grouping streams and managing the resources of stream groups.
In [Cama00], an additional direction attribute is introduced to indicate which party sends the
confirmation of the preconditions. Finally, [Cama00] provides a mechanism to perform third party call
control in SIP when SDP preconditions are used.
However [Cama00] does not consider pre-negotiation of QoS and the integration of local and peer
resource management.
In [RFC2533] the authors present a format to express media feature sets that represent media handling
capabilities. In addition, an algorithm is provided that matches the feature sets. It might be used to
determine if the capabilities of a sender and receiver are compatible and for matching with local and
network policies as a trading policy of a QoS Broker/QoS Agent in the process for validation of the QoS
contracts. This matching algorithm is improved in [CONNEG00]. In addition, [RFC2938] describes an
abbreviated format for composite media feature sets that use a hash of the feature representation to
describe the composite. This can be used to provide an abbreviated form for referencing an arbitrary
feature set expression, independent of any particular mechanism for de-referencing. [RFC2533] together
with [Conneg00] and ([RFC2938] or [SDPCN01]) do neither integrate existing internet protocols, nor
include the concept of pre-negotiating alternative QoS Contracts, nor integrate local-, network- and peerresource reservation mechanisms. In fact [RFC2533] and [RFC2938] can be used for QoS Broker/QoS
Page A.305
MIND
1.2 / 0.1
Agent internal descriptions and processing of the capability information by matching different negotiated
information that might have been exchanged over different protocols.
In [Andre00] the authors state the requirement that a capability set should contain a handle (similar to the
hash mentioned above) allowing for easy referencing of the capability set.
In [RFC2703] the authors present an abstract framework for protocol independent content negotiation for
the resources with which it interacts. It does however not provide the content negotiation process. It
identifies the need for expressing the capabilities of the sender and the data resource to be transmitted, the
capabilities of the receiver and the need for a protocol to exchange these capabilities. Negotiation is
carried out by a series of negotiation metadata exchanges in-band. The negotiation stops, as soon as a
specific data file to be transmitted has been found. The sender transfers the data if the sender determines
the file, otherwise the receiver informs the sender. This proposal therefore relates to content negotiation,
instead of dealing with pre-negotiation of configurations QoS contracts and capabilities. The [RFC2703]
proposal also does not integrate local-, peer-, as well as network-resource reservation.
[SDPOA00] describes a complete model for one-to-one capabilities negotiation with SDP. However this
model has problems by the definition of mutually referred information and information on grouping
streams because of the flat-hierarchy structure of the SDP. Additionally this model concerns only
capability negotiation but no QoS support. The "An Offer/Answer Model with SDP" [SDPOA00], states:
" Once the offerer has sent the offer, it MUST be prepared to receive media described by that offer.”.
This approach is not failure-tolerant with respect to the E2ENP and the adaptation mechanisms, since it
should be taken into account the possible dynamic reconfiguration of the peers both in failure and
upgrade cases, when the negotiated data becomes invalid within the time of a running negotiation or
before media streaming has started.
The most recent version of this IETF draft [SDPOA02] is a model in line with the new SIP approach
[SIPBIS09], [RFC3261] of moving the message processing capability from the stack to the user agents.
According to the new [SIPBIS09], [RFC3261] SIP is only a carrier protocol not incorporated in a
framework and additional functionality corresponding a specific system architecture can be achieved over
enhancing the user agent functionality by wrapping the SIP user agents in a framework structure. Thus
SIP can be used to carry session descriptions concerning session setup with respect to negotiation of
capabilities, QoS, etc. This new SIP approach makes E2ENP easily applicable with SIP, due to the
piggybacking possibility. The new Offer-Answer model [SDPOA02] also recognizes the benefits of the
approach. [SDPOA02] identifies the needs for pre-negotiation and applies a re-negotiation with SDP.
Since SDP is not a protocol and supports no referencing, the described negotiation and re-negotiation
signalling is ineffective. With SDP every message carries repeatable complete descriptions that should be
locally filtered every time to recognize the new set up. Such approach can lead to wasting of bandwidth
and to overloading of the peer internal processing, if it comes to complex session descriptions.
[SDPOA02] identifies also the need of supporting dynamic payload types. However, by supporting
dynamic payload types both the Offerer and the Answerer need to have a common view what is the
meaning of the payload type and how it is parameterised. This knowledge should also be negotiable, since
it cannot be expected that it is per se available as [SDPOA02] suggests. The authors of [SDPOA02] also
recognizes the possibility to combine in-band with out-band signalling in order to achieve better
adaptability. [SDPOA02] still considers only the problem of capabilities negotiation but not of QoS.
[100rel06] describes extension scenarios of the Offer/Answer model [SDPOA02] for support of different
negotiation modes (push, pull, push-pull) by using reliable provisional SIP requests and responses.
Additionally [SIPUP01] defines a new SIP method UPDATE, which is also used for different negotiation
modes support. This method can also be used for session descriptions update on the fly within a session
setup procedure and in failure treatment cases for symmetrical signalling between the SIP UAC and UAS.
Ongoing work in [SDPNG01] identifies the requirements of a framework dealing with session description
and endpoint capability negotiation in multiparty multimedia conferencing scenarios. Depending on user
preferences, system capabilities or other constraints, different configurations can be chosen for the
conference. The need of a negotiation process among the peers is identified, but not described, in order to
determine a common set of potential configurations and to select one of the common configurations to be
used for information exchange. This capability negotiation is used to get a valid session description
compatible with the end system capabilities and user preferences of the potential participants. Different
Page A.306
MIND
1.2 / 0.1
negotiation policies may be used to reflect different conference types. They also identify the need for
network resource reservation coupled with session setup. Finally a proposal is drafted for describing
capabilities and providing the negotiation language but not a protocol.
The [SDPNG01] proposal does neither consider the negotiation protocol for determining a common set of
QoS configuration nor integrate local, peer and network resource reservation. In addition, the [SDPNG01]
proposal does neither integrate the process of referencing configurations by handles, nor build upon the
QoS contract concept. Also, the [SDPNG01] proposal deals only with codec negotiation, without
considering also terminal capabilities and network resource reservation mechanisms.
The most recent versions of this IETF draft, the [SDPNG03], [SDPNG04], provide detailed XML Schema
specification and a prototype of the Audio Codec and RTP Profiles. Compared to such a latest, more
complete version of this IETF proposal, the E2ENP features (as an extension of that proposal):
•
Notion of the E2ENP phases
•
New SDPng sections and various configurations thereof, according to the format of the PDUs
associated with the various E2ENP phases.
•
Use of explicit <e2enp:session_id> element in the new <e2enp:purpose> section,
instead of the <owner> element in the <conf> section (which still remain, but for other
purposes).
•
Leasing of negotiated information
•
Concatenation of negotiated information
•
The original <def> now is not used, but two new <e2enp:qosdef> sections are
introduced, due to the specificity of the QoS definition in combination with capabilities.
•
Support of any type of network/protocol version in the <cfg> section.
•
Extensions to the Audio Codec and RTP Profiles.
•
Possibility to model QoS correlation and time synchronization constraints at any level of
abstraction, for local enforcement of the given terminal device or for delegating this to a thirdparty component (e.g. conference bridge)
•
Handling of third-party-assisted negotiation scenarios.
•
Handling video-codec information.
[SDPCO01] and [SDPNG03] identify the necessity of defining which of the communication parties are
with respect to the connection mode – sender, receiver or sender-receiver. Additionally [SDPCO01]
identifies the necessity of denoting that a single port might be used for sending or receiving of the
differently coded media with the same content. This respective definition with SDP is problematic
because of the flat structure of the protocol, on the other hand SDPng [SDPNG03] with the XML-schema
can perform cross references for the respective description. For the needs of QoS negotiations the
identification of the sender and/or the receiver parties may serve the speeding up of the negotiation by
choosing the most appropriate negotiation mode (push, pull or push-pull).
[SDPNG04] describes in addition a capability negotiation process for establishing of a common capability
vocabulary between end-peers. However the proposal [SDPNG04] still does not consider the QoS
specific issues. Additionally [SDPNG04] does not define a validation of the negotiated capabilities
usability against local and network policies but directly processes the end-results of the negotiation
(“Collapsing Algorithm”). This can be a problem for the effective and dynamic application of QoS
Broker/QoS Agent trading policies and for the mapping of the “external” protocol specific representation
Page A.307
MIND
1.2 / 0.1
to an “internal” Broker/Agent representation. On the other hand direct processing of XML descriptions
over the “Collapsing Algorithm” can be performance ineffective.
[SDPNG05] is just a refined version of the [SDPNG04] with improvements in the SDPng XML-Schema
and SDPng document referencing mechanisms.
It is worth to mention that the description of the stream configuration in SDPng [SDPNG05] (the <cfg>
section) is quite RTP/RTCP-centric. This might be a problem for defining codecs which do not fit in the
usual RTP definition. The configuration of media streams should be general enough to fit also non-RTP
specific descriptions as suggested in [MMUS_54].
The authors of [SDPCN00] propose a set of SDP extensions providing a minimal and backward
compatible capability negotiation mechanism. [SDPCN00] adds SDP extensions for capability
negotiation, only.
In [Beser00] the author extends SDP so that the end-points know the codec choices and can agree on a
common set. The communication partner can thus obtain the originators capabilities and preferences. The
[Beser00] proposal only provides SDP extensions necessary for endpoints to negotiate codecs.
In [Ott99] a notation for describing potential and specific configurations of end systems in multiparty
collaboration sessions is given. This enables mechanisms to define end system capabilities, calculate a set
of common capabilities and to express a selected media description for use in session descriptions. They
do not provide a protocol for capability exchange. The [Ott99] proposal however only provides a notation
for configuration description.
In [Bor00] the authors define services for a simple conference control protocol (SCCP) for tightly coupled
conferences. Member management, application/session management and access control rules for
distributed application resources are defined. The conference’s state, which might be established using
SIP, is managed during the lifetime using SCCP. This includes the finding of appropriate configurations,
negotiating for configurations and changing the configuration. However, no interaction with local- and
network-resource management is intended. The SCCP also does not cover the handling of QoS contracts
and how to pre-negotiate configurations thereof.
[Nahr95] presents a model for an end-point architecture based on a QoS Broker, which is a functional
entity that orchestrates resources at the end-points and co-ordinates resource management across layers.
In order to configure the system properly, the broker uses admission control and negotiation. Negotiation
among peer entities leads to a valid configuration, which involves all necessary components of the
communication system.
The model described in [Nahr95] however does neither integrate existing internet protocols nor considers
other resources like battery power or wireless sub-network availability.
Additional works on the problem of a QoS Broker description language are [Xiaohui], [Nahr00],
[Frolu98] and [QuO]. They also use some of the currently wide-spread description technologies, like
XML [Xiaohui], [Nahr00] and CORBA Objects [QuO]. However these descriptions integrate both
capabilities, QoS and Broker internal trading policies. This information is rather an internal description of
the QoS Broker policies as a protocol specific description and can be used only for negotiation between
QoS Brokers belonging to the same type with respect to their performance and their architecture. In
contrast to this E2ENP is an external description, which can be used as an interoperable protocol between
QoS Brokers and applications of different types.
[Levin00] presents a set of requirements for a call-control protocol for real-time multimedia support over
IP. Capabilities have to be expressed, capabilities have to be signalled to identify the amount of resources
that are necessary, and a call control mechanisms is needed to open/close/modify media streams within
the boundaries set forth by capabilities and reserved resources. Also the authors propose to announce new
capabilities (if available) during a session. In addition, the peers have to agree on a common set of codecs
to be used. A session control mechanism to start/stop the streams is put as a requirement. [Levin00] also
recognizes the need of separate treatment of audio and video, since video codecs can generate both static
Page A.308
MIND
1.2 / 0.1
and dynamic network streams and due to this feature the description of video capabilities should be
different and more profound compared to audio.
However [Levin00] does not consider the integration of local, remote and network resource management
into a coherent framework; rather, [Levin00] only provides requirements. Neither specific protocol
mapping nor mechanisms to enforce the requirements are proposed.
Ongoing work on the problem of multimedia and video [Levin01] recognizes the need for video
adaptability and the correlation of video with other streaming types at application level. [Levin01]
identifies some of the video capabilities important to parameterise a codec. Still [Levin01] presents only
requirements for video capabilities exchange and not a methodology about solving the problem.
In [BRAIN], [Roble01], [Kassl00], and [Kassl01], an end-system architecture has been presented that
integrates local, peer and network resource reservation into a framework for end-to-end QoS
management. Whereby User Preferences and adaptation paths are used together with QoS states to
negotiate QoS at application level. Interaction with local resource management is introduced. The layered
architecture provides support for different types of applications.
[Manda00], [Manda01] and [Cama01] discuss the possibility of grouping of media streams but do not
consider criteria for the grouping, the possibility of recursive group building (a group of many groups)
and the treatment of real, pseudo-real and non-real time information streams that also may be grouped.
Additionally, [Cama02] discusses the possibility of using the directly negotiated information for
reservation purposes. To this extent E2ENP only synchronises the reservation process but is not used for
the reservation itself. The advantage of this approach is that E2ENP can be used even in cases when no or
partial network reservation is necessary (e.g. over-provisioned networks, segmented reservations, and
Service Domain reservation processing – see also Chapter 4). The disadvantage of the [Cama02]
approach is the usage of SDP to define multiple RSVP reservation flows, since SDP has flat structure and
the definitions of grouped structures is quite cumbersome. On the other hand the usage of XML based
protocols also by reservation processing would allow the easy definition of media groups and the
performing of the reservation for all groups and single media streams in one shot. Thus the reservation
agents would be able to process multiple reservation requests coming from the same peer within a single
call. The advantage here is that the reservation agents would not need to synchronize multiple reservation
calls.
[Manda00] and [Manda01] define negotiation steps that may or may not run at one shot, but not
independent phases and have no requirement for the consistency of the negotiated QoS information
during a negotiation phase and after it. The treatment of colliding “Economy Principle”-applications is
also not considered.
[Manda00] and [Manda01] describe the possibility of setting and managing adaptation paths for the QoS
adaptation, which is controlled by a third party component (QoS Broker). The possibility that the endparties perform and control the negotiations on their own is not considered.
In [Bos01] an End-to-End User Perceived Quality of Service Negotiation is described, with the
assumption that some IMs and services may strongly be involved in the end-decision about the negotiated
QoS information of the end-peers. The decision about QoS configurations in [Bos01] may be taken over
some standard “contract types”. Although [Bos01] mentions that signalling and data packets may flow
along different paths throughout the network, the authors of [Bos01] suggest that some IMs along the
negotiation path may influence the negotiation, though in general having nothing to do with the data.
According to such a protocol model the network is not transparent.
The negotiation process presented in [Bos01] does not allow incremental negotiations, and furthermore
[Bos01] leverages static APs with fixed transitions among capability configurations/network-level QoS
contracts only. The model of [Bos01] suggests negotiations of QoS only at stream level without
considering some stream dependencies like groups and stream hierarchies.
The most recent work on the problem of User Perceived QoS [Bos02] introduces SDPng schema for
defining traffic throughput and sensitivity information. This information considers only the network
reservation process without taking in account the necessity for local (peer) QoS specific configurations
Page A.309
MIND
1.2 / 0.1
and reservations. The model in [Bos02] is not taking in account the Application Level QoS definitions,
with respect to codec configuration and a flexible adaptation process. However the E2ENP can
incorporate this proposal, by allowing senders to derive TI/SI from Application Level QoS contracts, and
to forward this information as part of a proposal/counter-proposal to the receiver(s). The model of
[Bos02] is static in terms of adaptation, insofar as it reuses the fixed prioritisation of alternative options
derived from SDP, thus losing the powerful flexibility featured by XML. The description of the payload
types in [Bos02] is not in accordance with the payload types as described in [RTP-Prof], since the codec
parametrization of the audio codecs is already pre-defined for the static payload types. One interesting
aspect in [Bos02] is the introduction of QoS Class format as a form of predefined interoperable
application level QoS definition. However such a definition would also need high level QoS specification
considering the usage of different possible QoS configurations of a single codec/payload type.
In [Berg01] a list of key questions (actually, real requirements) are proposed. More specifically, "1) the
exchange of QoS related information and 2) enforcement of QoS related decisions" are indicated as
"enhancements required in order to provide predictable end-to-end QoS". The E2ENP meets both these
requirements, insofar as it:
•
defines an application-level protocol dealing with the first requirement, and
•
enforces resource management according to the Economy Principle. More specifically, with
respect to the second requirement, the E2ENP assumes the existence of the Extended Socket
Interface (ESI), described in [BRAIN], [Roble01], whereby details of network resource
management are hidden to applications. This means that the ESI offers a level of abstraction,
upon which QoS aware middleware and applications can be built. Should however the ESI not
be available, the E2ENP assumes that applications and/or middleware will be able to derive
network-level QoS Contracts from high-level QoS Contracts, as well as use low-level monitored
information for triggering application and/or middleware QoS adaptation mechanisms.
More specifically, [Berg01] lists the following five points:
1.
"The access network: the probability of congestion is the highest in the access network, thus it is
very likely that some kind of mechanism supporting the QoS information is necessary here."
This is exactly the assumption made in [BRAIN], [Roble01] (from which the original concept of
E2ENP originates), whereby the ESI abstraction allows applications and/or middleware
(leveraging the E2ENP), not only to use in general any kind of network architecture available,
but also (more particularly) to make a similar assumption concerning the Access Network
2.
"End-to-end signalling between applications: we believe that a high level information exchange
must be the first of QoS session initiation in several cases."
This is exactly one of the requirements that the E2ENP targets. In addition, the E2ENP deals
with proactive pre-negotiations of alternative QoS Contracts, and of higher-level QoS Contracts
as well. The E2ENP furthermore offers in addition a full-blown set of procedures for handling
re-negotiations.
3.
"Inter-domain communication, particularly on peering link: an automatic service announcement
is needed, something like BGP, but with QoS enhancements. In addition, it is considerable to
have a mechanism, which actually provides inter-domain provisioning of these resources."
The E2ENP is a pure End-to-End application-level protocol, whereby only the peers (and
eventually some intermediate components, like conference bridges or transcoders) are directly
involved. Lower level functionality dealing with intra- and/or inter-domain network resource
management and routing is hidden to the E2ENP, thanks to the ESI, or equivalent abstraction.
This means that the E2ENP is a pure application-level protocol, which peers can use to
communicate over any network architecture.
Page A.310
MIND
1.2 / 0.1
4.
"Identifying, which customer to penalize in case of a network congestion: when a sever
congestion occurs and a contract has to be breached, it should be under the control of the
network."
The E2ENP is compatible with this requirement, since the E2ENP assumes that the detection of
QoS Violation is carried out by the underlying network architecture.
5.
"Providing requirement information for customers: Customers could inform the service
providers about the current and intended network utilization, specifying for example the
expected destinations and traffic volumes. The operator could then use this knowledge to
dimension its network better, and also to calculate the amount of services to buy from the
neighbouring operators."
This is exactly the assumption made in [BRAIN], [Roble01], from which the original concept of
E2ENP originates. More specifically, users can not only provide "current and intended network
utilization, specifying for example the expected destinations and traffic volumes" in terms of
application-level QoS Contracts pre-negotiated with the network provider (during the process
described in Section A.7.3.4), but also exchange with peers sets of alternative QoS Contracts
(the APs), and at different levels of abstractions, so as to take into account inter-stream
relationships (with APs as well).
Finally, [Berg01] mentions to the need of having peers agreeing with their networks provider the type of
Quality of Service, along with pricing information, a priori of any session establishment. This is similar to
the process described in Section A.7.3.4, where however the user specifies Application-level QoS
information, which eventually gets mapped to network level QoS contracts, which are then validated
against pre-arrangements with the network provider, or via direct communication with the latter. How
these low-level processes are accomplished is how of E2ENP scope, thanks to the ESI abstraction (or
similar functionality).
In [Roja00] the importance of having both application and transport level QoS specification is discussed.
The authors of [Roja00] describe the necessity of having this information negotiated, in order to be able
to manage the QoS delivery at all abstraction levels of a QoS aware application. Furthermore, [Roja00]
sets requirements forth that the QoS descriptions should be general enough to fit different systems and
technologies. These requirements are in line with the E2ENP idea.
[Khart01], [Rosen01] and [Rosen01a] introduce models for multiparty conferencing which consider
scenarios like one-to-many and many-to-many connections. The described models take advantage of a
centralized architecture using conference server. In this case there is no direct end-to-end communication
between the end-peers and the application of E2ENP could be performed in several different ways:
•
Direct signalling between the end-peers, data path over the conference server
•
Indirect signalling between the end-peers over the conference server, direct data connection
between the end-peers
•
Indirect signalling between the end-peers over the conference server and data path over it
Such application of E2ENP may require different message sequences and E2ENP-structure for every
different scenario. The models of [Khart01], [Rosen01] and [Rosen01a] are mainly concerned with the
description of the message sequences by a conferencing scenario using a centralized component. By
necessary capabilities- and/or QoS negotiations and respective reservations these sequences may undergo
changes if E2ENP should also be applied to such scenarios. The advantage of E2ENP application in a
scenario with some centralized components is that the communication model can be reduced to one-tomany scenario.
Page A.311
MIND
1.2 / 0.1
A.11. Conclusions
This Annex has introduced the concept, requirements and proposed solution of the End-to-End QoS
Negotiation Protocol (E2ENP). The E2ENP is a signalling mechanism for effectively and efficiently
performing end-to-end QoS negotiations/re-negotiations and resource management coordination, when
dealing with multiparty multimedia services under unstable network conditions. Special features are the
negotiation of common vocabulary and adaptation paths, that describe alternative QoS contracts to be
applied, when QoS violations occur.
Furthermore, the E2ENP allows developers and/or users to capture and enforce time synchronization and
QoS correlation (and even more complex) constraints among multiple streams, thus allowing adaptation
at different levels. This is envisioned to be a key benefit in terms of QoS for current and future
applications.
Additionally, both the application level and the transport level QoS parameters are considered as two
orthogonal issues of the QoS delivery. The necessity of those two dimensions for the aims of the QoS
management at all abstraction levels at which an application performs is thoroughly discussed.
By modularly extending SDPng, and by properly defining SIP usages, it is expected that the induction of
the E2ENP concept will smoothly blend with legacy solutions, along the path towards the next generation
of QoS aware multiparty, multimedia services.
The authors have followed and participated to the discussion in the IETF MMUSIC WG concerning QoS
and capabilities negotiation and the on-going SDPng specification. However, in this work a specification
based on an original use of SDPng is drafted, which partially diverges from the current status of the
discussion in MMUSIC. This decision is taken for the sake of explaining the E2ENP concepts in more
concrete terms, without waiting for the SDPng specification to be finalized. Additional SDPng inherent
problem by the convergence of the E2ENP and the SDPng descriptions is, that SDPng is too RTP-centric.
This makes it difficult to introduce general QoS definitions from the application point of view, which are
applicable for bigger variety of codecs and not only for the RTP specific profile. Furthermore, the SDPng
stream configuration definition is quite fix, when it comes to describing vertical handovers and session
mobility. To this extent, the authors plan in any case to harmonise the E2ENP specification with the final
SDPng version, or even contribute to the preparation thereof, once the E2ENP concepts will have been
properly reviewed after a necessary testing phase.
Page A.312
MIND
1.2 / 0.1
A.12. References
[100rel06]
J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses in SIP", IETF SIP
working group, Work-in-progress, <draft-ietf-sip-100rel-06.txt>.
[Andre00]
F. Andreasen, "SDP Simple Capability Negotiation Requirements", IETF MMUSIC
working group, Work-in-progress, <draft-andreasen-mmusic-sdp-simcap-reqts-00.txt>.
[Berg01]
A. Bergsten, K. Nemeth, I. Cselenyi, G. Feher, "Fundamental Questions Regarding End-toEnd QoS", Work-in-progress, <draft-bergsten-e2eqos-questions-00.txt>.
[Beser00]
B. Beser: Codec Capabilities Attribute for SDP, IETF Internet-Draft, Work-in-progress,
<draft-beser-mmusic-capabilities-00.txt>.
[Bhatt99]
S. Bhatti, G .Knight, “Enabling QoS adaptation decisions for Internet applications”,
London, UK, 1999.
[BLUE]
Specification of the Bluetooth System, version 1.1,
http://www.bluetooth.com/files/Bluetooth_11_Specifications_Book.pdf.
[Booch99]
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide,
Addison Wesley Longman, 1999.
[Bor00]
C. Bormann et al.: Simple Conference Control Protocol, IETF Internet-Draft, Work-inprogress, <draft-ietf-mmusic-sccp-01.txt>.
[Bos01]
L. Bos, et al: A Framework for End-to-End User Perceived Quality of Service Negotiation,
IETF Internet-Draft, Work-in-progress,<draft-bos-mmusic-sdpqos-framework-00.txt >.
[Bos02]
L. Bos, et al: SDPng extensions for Quality of service negotiation, IETF Internet-Draft,
Work-in-progress,<draft-bos-mmusic-sdpng-qos-00.txt >.
[BRAIN]
IST-1999-10050 BRAIN Deliverable 1.2, Concepts for Service adaptation, scalability and
QoS handling on mobility enabled networks, 31.03.2001 (http://www.ist-brain.org/)
[Cama00]
G. Camarillo: Confirmation of SDP preconditions, IETF Internet Draft, Work-in-progress,
<draft-camarillo-manyfolks-confirm-02.txt>.
[Cama01]
G. Camarillo, et al: Grouping of media lines in SDP, IETF Internet Draft, Work-inprogress, <draft-ietf-mmusic-fid-06.txt>.
[Cama02]
G. Camarillo, et al: Mapping of Media Streams to Resource Reservation Flows, IETF
Internet Draft, Work-in-progress, <draft-ietf-reservation-flows-01.txt>
[Conneg00] G. Klyne (ed.): A revised media feature set matching algorithm , IETF media feature
registration WG, Work-in-progress, <draft-klyne-conneg-feature-match-02.txt>.
[ETSIWS02] Mike Buckley: ETSI Workshop on QoS in Next Generation Networks – Workshop
Conclusions, 21.02.2002, (http://www.etsi.org/frameset/home.htm?/QOSWORKSHOP/),
[Even00]
R. Even et al: SDP attributes for Video Media Control, IETF Internet-Draft, Work-inprogress, <draft-even-mmusic-video-media-control-00.txt>.
[FIPA]
THE FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS (http://www.fipa.org/)
[Frolu98]
S. Frolund, J. Koistinien, “QML: A Language for Quality of Service Specification”, HPLab Technical Reports, HPL-98-10, 980210.
Page A.313
MIND
1.2 / 0.1
[H323]
“Recommendation H.323”,
http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.323
[Handl98]
M. Handley, V. Jacobson “SDP: Session Description Protocol “, IETF Request for
Comments: 2327, April 1998.
[ISOX641] ITU-T Recommendation X.641 (12/97) | ISO/IEC 13236:1998, Information technology Quality of Service: Framework.
[JINI]
JINI[tm] network technology, http://www.sun.com/jini/
[Kassl00]
Kassler A. et al., BRENTA - Supporting Mobility and Quality of Service for Adaptable
Multimedia Communication, in Proceedings of the IST Mobile Communications Summit
2000, Galway, Ireland, October 2000, pp. 403-408.
[Kassl01]
Kassler A. et al., An Open Endsystem Architecture for Adaptable Multimedia Services with
QoS Support, in Proceedings of the BRAIN workshop, London, 2000.
[Khart01]
H. Khartabil, Conferencing using SIP, IETF Internet-Draft, Work-in-progress, <draftkhartabil-sip-conferencing-00.txt >
[Levin00]
O. Levin, SIP Requirements for support of Multimedia and Video, IETF Internet-Draft,
Work-in-progress, <draft-levin-sip-for-video-00.txt>
[Levin01]
O. Levin, Multimedia Conferencing Requirements for SIP Based Systems, IETF InternetDraft, Work-in-progress, <draft-levin-sip-for-video-01.txt>
[Loyal]
J. P. Loyall et al., “QoS Aspect Languages and their Runtime Integration”, in Lecture Notes
in Computer Science, Vol. 1511, Springer-Verlag.
[Manda00] D. Mandato, A. Kassler, T. Robles, G. Neureiter, Concepts for Service adaptation,
Scalability and QoS concepts on mobility enabled networks, IST Global Summit 2001,
Barcelona, September 2001, pages: 285-293.
[Manda01] D. Mandato, A. Kassler, T. Robles, G. Neureiter, Handling End-to-End QoS in Mobile
Heterogeneous Networking Environments, PIMRC 2001, San Diego, 30/9 - 3/10 2001,
Pages: C-49 - C-54.
[Marsh00]
W.Marshall et al., SIP Extensions for Resource Management, IETF draft <draft-ietf-sipmanyfolks-resource-00>, November 2000.
[Mao00]
Z. M. Mao, R. Katz, “Achieving Service Portability in ICEBERG”, in Proc. Of IEEE `00
CLOBECOMM Workshop “2000 IEEE Service Portability and Virtual Customer
Environments”, IEEE, December 2000
[MEGACO] “Media Gateway
charter.html
Control
(MEGACO)”,
http://www.ietf.org/html.charters/megaco-
[MMUS_53] “Multiparty Multimedia Session Control WG (MMUSIC)” - 53-mmusic-minutes.txt, 53rd
IETF
Meeting,
Minneapolis,
20th
March
2002,
http://www.dmn.tzi.org/ietf/mmusic/53/slides/53-mmusic-slides-ppt.zip
[MMUS_54] “Multiparty Multimedia Session Control WG (MMUSIC)” - 54-mmusic-minutes.txt, 54rd
July
2002,
IETF
Meeting,
Yokohama,
14th
http://www.dmn.tzi.org/ietf/mmusic/54/slides/54-mmusic-slides-ppt.zip
[Nahr95]
K. Nahrstedt and J. M. Smith: The QoS Broker, IEEE Multimedia Magazine, Spring 1995
(2)1, pp. 53-67.
Page A.314
MIND
1.2 / 0.1
[Nahr00]
D. Wichadakul, K. Nahrstedt: Distributed QoS Compiler, Project Report - National Science
Foundation, 2001
[Olson01]
S. Olson, G. Camarillo, A. Roach, "Support for IPv6 in SDP", IETF Internet-Draft, Workin-progress, <draft-olson-sdp-ipv6-02.txt>.
[Ott99]
J. Ott et al.: Capability description for group cooperation, IETF Internet-Draft, Work-inprogress, <draft-ott-mmusic-cap-00.txt>.
[QuO]
BBN TECHNOLOGIES – Quality Objects (QuO), http://quo.bbn.com/
[Quit00]
J. Quittek et. al.: Requirements for IP Flow Information Export, <draft-ietf-ipfix-reqs00.txt>.
[RFC2119] IETF RFC 2119, "Key words for use in RFCs to Indicate Requirements Levels", S. Bradner,
Network Working Group, March 1997.
[RFC2198] IETF RFC 2198, RTP Payload for Redundant Audio Data, C. Perkins et al., Network
Working Group, September 1997.
[RFC2327] IETF RFC 2327, SDP: Session Description Protocol, M. Handley and V. Jacobson,
Network Working Group, April 1998
[RFC2533] IETF RFC 2533, A Syntax for Describing Media Feature Sets, Graham Klyne,
5GM/Content Technologies, March 1999.
[RFC2543] IETF RFC 2543, SIP: Session Initiation Protocol, M. Handley et al, ACIRI, March 1999.
[RFC2703] IETF RFC 2703, Protocol-independent Content Negotiation Framework, Graham Klyne,
5GM/Content Technologies, September 1999.
[RFC2938] IETF RFC 2938, Identifying composite media features, Graham Klyne, Content
Technologies, September 2000
[RFC3261] IETF RFC 3261, SIP: Session Initiation Protocol, J. Rosenberg, DYNAMICSOFT, June
2002
[Roble01]
Tomas Robles, Arndt Kadelka, Hector Velayos, Antti Lappetelainen, Andreas Kassler, Hui
Li, Davide Mandato, Jussi Ojala, and Bernard Wegmann, QoS Support for an All-IP System
Beyond 3G, IEEE Communication Magazine, August 2001, Vol.39, No.8.
[Roja00]
J.C. Rojas et al.: Requirements for the QoS negotiation at the Application Layer, IETF
Internet-Draft, Work-in-progress, <draft-rojas-mmusic-qosreq-00.txt>
[Rosen01]
J. Rosenberg, H. Schulzrinne, Models for Multi Party Conferencing in SIP, IETF SIPPING
working group, Work-in-progress, <draft-rosenberg-sip-conferencing-models-01.txt >
[Rosen01a] J. Rosenberg, H. Schulzrinne, Models for Multi Party Conferencing in SIP, IETF SIPPING
working group, Work-in-progress, <draft-ietf-sipping-conferencing-models-00.txt >
[RTP-Prof] H. Schulzrinne et al.: RTP Profile for Audio and Video Conferences with Minimal Control,
Columbia U., Work-in-progress, <draft-ietf-avt-profile-new-09.txt >
[SDPCN00] F. Andreasen, SDP Simple Capability Negotiation, IETF MMUSIC working group, Workin-progress, <draft-andreasen-mmusic-sdp-simcap-00.txt>.
[SDPCN01] F. Andreasen, SDP Simple Capability Negotiation Requirements, IETF MMUSIC working
group, Work-in-progress, <draft-andreasen-mmusic-sdp-simcap-reqts-00.txt>.
Page A.315
MIND
1.2 / 0.1
[SDPCO01] D. Yon, Connection-Oriented Media Transport in SDP, IETF MMUSIC working group,
Work-in-progress, <draft-ietf-mmusic-sdp-comedia-01.txt >.
[SDPNG01] D. Kutscher et al.: Requirements for Session Description and Capability Negotiation, IETF
Internet-Draft, Work-in-progress, <draft-kutscher-mmusic-sdpng-req-01.txt>.
[SDPNG03] D. Kutscher et al.: Session Description and Capability Negotiation, IETF Internet-Draft,
Work-in-progress, <draft-ietf-mmusic-sdpng-03.txt>.
[SDPNG04] D. Kutscher et al.: Session Description and Capability Negotiation, IETF Internet-Draft,
Work-in-progress, <draft-ietf-mmusic-sdpng-04.txt>.
[SDPNG05] D. Kutscher et al.: Session Description and Capability Negotiation, IETF Internet-Draft,
Work-in-progress, <draft-ietf-mmusic-sdpng-05.txt>.
[SDPngT00] J. Ott, C. Perkins.: SDPng Transition, IETF Internet-Draft, <draft-ietf-mmusic-sdpng-trans00.txt>.
[SDPOA00] J.Rosenberg, H.Schulzrinne.: An Offer/Answer Model with SDP, IETF Internet-Draft,
Work-in-progress, <draft-rosenberg-mmusic-sdp-offer-answer-00.txt >.
[SDPOA02] J.Rosenberg, H.Schulzrinne.: An Offer/Answer Model with SDP, IETF Internet-Draft,
Work-in-progress, <draft-ietf-mmusic-sdp-offer-answer-02.txt >.
[SRL98]
H. Schulzrinne, A. Rao, R. Lanphier, “Real Time Streaming Protocol (RTSP) “, IETF
Request for Comments: 2326, April 1998.
[SIPBIS04] Handley et al.: SIP: Session Initiation Protocol, IETF SIP working group, Work-inprogress, <draft-ietf-sip-rfc2543bis-04.txt>.
[SIPBIS09] Rosenberg et al.: SIP: Session Initiation Protocol, IETF SIP working group, Work-inprogress, <draft-ietf-sip-rfc2543bis-09.txt>.
[SIPPRE01] J. Rosenberg et al., SIP Extensions for Presence, SIMPLE WG, Work-in-progress, <draftrosenberg-impp-presence-01.txt>
[SIPRES01] W. Marshall et al.: Integration of Resource Management and SIP – SIP Extensions for
Resource Management, IETF SIP working group, Work-in-progress, <draft-ietf-sipmanyfolks-resource-01.txt>.
[SIPRES07] G. Camarillo et al.: Integration of Resource Management and SIP, IETF SIP working
group, Work-in-progress, <draft-ietf-sip-manyfolks-resource-07.txt>
[SIPUP01]
J. Rosenberg.: The SIP UPDATE Method, IETF SIP working group, Work-in-progress,
<draft-ietf-sip-update-01.txt>
[WAVI]
G. Fankhauser, M. Dasen, N. Weiler, B. Plattner, and B. Stiller. WaveVideo -- An
integrated approach to adaptive wireless video. in ACM Monet, Special Issue on Adaptive
Mobile Networking and Computing, 1998
[WP-Cod]
White Paper, IP/TV CODECs, File Transfer and Storage Requirement Considerations, Jul
2000, http://www.cisco.com/warp/public/cc/pd/mxsv/iptv3400/tech/ipcod_wp.htm
[Xiaohui]
Xiaohui Gu, K. Nahrstedt, et al, An XML-based Quality of Service Enabling Language for
the Web, Project Report - National Science Foundation, 2001
[XLINK]
W3C, XML Linking Language (XLink) Recommendation Version 1,
http://www.w3.org/TR/xlink/, June 2001.
Page A.316
MIND
1.2 / 0.1
[XMLSC]
W3C, "XML Schema: Primer", "XML Schema: Structures", and "XML Schema:
Datatypes", 2001.
[XPATH]
W3C, XML Path Language Recommendation Version 1, http://www.w3.org/TR/xpath,
November 1999.
[XPOINT]
W3C, XPointer Recommendation, http://www.w3.org/TR/xptr, work in progress 2000
Page A.317