ETSI TR 182 022 V2.0.0 (2007-12)

Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); Architectures for QoS handling

DTR/TISPAN-02039-NGN-R2

General Information

• Status: Published
• Publication Date: 03-Dec-2007
• Technical Committee: TISPAN 2 - TISPAN Architecture
• Current Stage: 12 - Completion
• Due Date: 05-Dec-2007
• Completion Date: 04-Dec-2007

Standards Content (Sample)

ETSI TR 182 022 V2.0.0 (2007-12)
Technical Report
.

Telecommunications and Internet Converged Services and
Protocols for Advanced Networking (TISPAN);
Architectures for QoS handling

---------------------- Page: 1 ----------------------
2 ETSI TR 182 022 V2.0.0 (2007-12)



Reference
DTR/TISPAN-02039-NGN-R2
Keywords
architecture, QoS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2007.
All rights reserved.

TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TR 182 022 V2.0.0 (2007-12)
Contents
Intellectual Property Rights.4
Foreword.4
1 Scope.5
2 References.5
2.1 Informative references.5
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations.6
4 Resource Monitoring.6
4.1 General principles of Resource Monitoring .7
4.1.1 Overview.7
4.1.2 Brief description of scenarios .7
4.1.2.1 L2 Topology awareness and traffic management options.7
4.1.2.2 Bandwidth on Demand.8
4.1.3 Preferred functional properties .9
4.2 Mechanisms for Resource Monitoring .10
4.2.1 Type of information to be monitored.10
4.2.2 Principles of the information specification .10
4.2.3 Sources of information.11
5 QoS Reporting.11
5.1 General principles of QoS Reporting .12
5.1.1 Overview.12
5.1.2 Brief description of scenarios .12
5.1.3 Preferred functional properties .13
5.2 QoS Reporting framework.13
5.2.1 QoS Reporting Sources.13
5.2.2 QoS Reporting Users .14
5.2.3 QoS Reporting Collector.14
6 Overall QoS architecture.15
7 Relationship between Resource Monitoring and QoS Reporting.15
History .17

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 182 022 V2.0.0 (2007-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 182 022 V2.0.0 (2007-12)
1 Scope
The present document presents an overall analysis of architectural requirements for QoS reporting and resource
monitoring (i.e. QoS handling). This includes analysing management aspects from an architectural perspective (stage 2)
as well as taking into account the work on performance and QoS for Next Generation Networks undertaken by STQ.
The area of QoS reporting covers detecting the end-to-end QoS experienced by bearer flows, while the area of resource
monitoring covers monitoring the topologies and resources of the transport segments controlled by RACS. Resource
monitoring includes detecting the actual usage of these resources.
The present document provides an informative description of the QoS handling tasks that are to be performed. It further
describes how different subsystems, common functions or capabilities, and management systems interact in performing
these tasks.
Being an informative document providing an overall analysis of QoS handling area it is foreseen to be referenced by the
RACS release 2 specification [1] and potentially other specifications impacted by QoS handling, but it only performs a
preliminary architectural analysis. New functions or interfaces for QoS Handling will not be part of the normative
document of the RACS release 2 specification [1]. The present document does not define or re-define functions or
interfaces needed for QoS handling. Instead, such enhancements are expected to be made in normative documents such
as the RACS specification, beyond current release.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Informative references
[1] ETSI ES 282 003: "Telecommunications and Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Resource and Admission Control Sub-system (RACS);
Functional Architecture".
[2] ETSI TS 181 018: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Requirements for QoS in a NGN".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 182 022 V2.0.0 (2007-12)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
QoS reporting: this mechanism identifies the ability for some network elements to collect the values of some QoS
metrics of a single service instance
NOTE: Example of QoS metrics could be delay, packet loss, etc.
resource monitoring: this mechanism identifies the ability to monitor the topologies and resources of the transport
segments controlled by RACS. Resource monitoring includes detecting the actual usage of these resources.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AF Application Function
AN Access Node
A-RACF Access-Resource and Admission Control Function
AS Application Server
ATM Asynchronous Transfer Mode
BGF Border Gateway Function
BoD Bandwidth on Demand
CAC Call Admission Control
CDR Call Detail Record
CPE Customer Premises Equipment
IP Internet Protocol
OSS Operation Support System
PCR Peak Cell Rate
QoS Quality of Service
QRC QoS Reporting Collector
QRS QoS Reporting Source
QRU QoS Reporting User
RACS Resource Admission Control Subsystem
RCEF Resource Control Enforcement Function
SNMP Simple Network Management Protocol
SPDF Service-based Policy Decision Function
TRIM Topology and Resource Information Model
TRIS Topology and Resource Information Specification
TRSF Topology and Resource Storage Function
VC Virtual Circuit
VP Virtual Path
x-RACF Generic-Resource and Admission Control Function
4 Resource Monitoring
RACS provides policy based transport control services to application functions (i.e. QoS control). These services may
include policy control, resource reservation, policing, gate control and IP address mediation. Implementing such
services RACS needs to hold a logical view of the different transport segments within its control. This view is kept
up-to-date and potentially also reflect the actual usage of the network in case traffic sources send at variable rates or in
case not all flows are under the control of RACS.
Hence, for RACS to perform resource monitoring it needs functions and reference points to retrieve and store a logical
view of the different transport segments within its control. This view is herein described in the form of a logical
topology and resource information model (TRIM), which is stored by RACS in the form of a topology and resource
information specification (TRIS).
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 182 022 V2.0.0 (2007-12)
Clause 4.1 discusses the general principles in retrieving, storing and keeping TRIS up-to-date to facilitate efficient
resource control by RACS. Clause 4.2 describes the concrete information of TRIS and the mechanisms involved in
retrieving, storing and keeping TRIS up-to-date with the transport segments it models.
4.1 General principles of Resource Monitoring
RACS needs to maintain accurate and current knowledge of resources available in the transport segments within its
control and knowledge of which resources will be involved in forwarding individual media flows through these
transport segments (i.e. the topology and resource information captured by TRIS). This information is needed by RACS
for it to locate all the necessary functional entities and Transport Processing Entities (e.g. SPDF, A-RACF, BGF, RCSF
and AN instances), that need to be involved in serving reservation requests issued over Gq'. The A-RACF uses TRIS to
perform effective resource admission control for guaranteed forwarding quality of service (QoS).
4.1.1 Overview
The topology and resource information is expected to be stored locally by functional entities within RACS. That is,
interrogating other functions on a per-request basis may delay the replies to reservation requests made over Gq' and Rq.
The information stored locally by each functional entity may not be the complete TRIS for all transport segments
controlled by a specific RACS instantiation. An SPDF instance needs only to have access to the information required to
serve requests arriving over Gq', while an A-RACF instance only needs to have information to serve requests made over
Rq available (i.e. information to interrogate the correct AN and/or RCEF and to perform admission control if
guaranteed forwarding QoS is to be offered).
The status of the monitored resources allows the A-RACF to perform resource admission control for the path to protect
the involved forwarding resources from overload.
The topology information may be learned by means of a provisioning integration for run-time interaction with OSS
system(s) and/or by interacting with network devices.
4.1.2 Brief description of scenarios
In annex A of TS 181 018 [2] four scenarios are described that are related to the use of a Resource Monitoring
mechanism which will enable a TISPAN NGN to provide an adequate Quality of Service to the media flows.
The following scenarios are derived from the above and illustrate examples where resource monitoring mechanisms are
needed to provide accurate and up-to-date network resource and topology information to enable RACS to perform
correctly in response to requests for admission control.
4.1.2.1 L2 Topology awareness and traffic management options
Scenario A.2 "L2 Topology awareness and traffic management options" [2] describes the case where the RACS has to
control an ATM-based access network. Focusing on Connection Admission Control mechanism within an ATM
network different approaches can be used. The simplest form among all CAC algorithms, is the so-called Peak
Bandwidth Allocation that uses only the knowledge of the PCR parameter to compare against the network available
bandwidth and decide whether to accept the configuration of new connection or not. This algorithm ensures that the
sum of requested resources and existing connections is bounded by the physical link capacity, but prevents any
multiplexing gain among the VC and VP configured into the network. Another approach is to admit new connection
allocating a bandwidth between the peak cell rate and the sustained cell rate. As a result, the sum of all the admitted
connections' peak cell rates may be greater than the outgoing link capacity.
If a statistical approach is used in the ATM network, RACS is aware of the exact network topology and knows for
example the different overbooking factors used in all the interfaces of the various ATM switches. Then, the resource
monitoring mechanism allows the RACS to be aware of L2 topology information in order to control an
ATM-based access network. In this case the RACS needs to have a map of the network topology, able to model the link
that will be affected by the traffic flow and other parameter as VPs and VCs.
Since the RACS is able to control network based on different technology and different deployments, a mechanism is
needed in order to retrieve the topology and resource information for different networks and to allow the RACS to know
all the information necessary to perform a correct admission control. Moreover, also the topology and resource
information model (TRIM) and the topology and resource information (TRIS) maintained by the RACS is independent
of the network technology and particular deployments.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 182 022 V2.0.0 (2007-12)
NOTE: Further scenarios are possible and contributions are invited.
4.1.2.2 Bandwidth on Demand
Scenario A.4 "Bandwidth on Demand" [2] describes a service offered to a user which allows the user to boost his access
bandwidth to a higher level for a limited period of time.
The objective is to study the requirements on the RACS functionalities to deliver such a service. The service would
allow users who usually have e.g. 512 Kbps of access bandwidth available to increase this to a higher bandwidth,
e.g. 2 Mbps, for a limited period of time.
The service could offer a number of options:
1) Request for increased downstream bandwidth for a specified time. This would allow the user to e.g. download
content at a higher rate than normal. In this case only downstream traffic would need to be boosted.
2) Request for increased bi-directional bandwidth for a specified time. This would allow the user to e.g. share
content or take part in a video conference and enjoy an improved image and sound quality.
3) Request for increased bandwidth for a specific service which would only affect the traffic associated with that
service, e.g. a "Video Boost" service.
4) Request for increased bandwidth for some specific content.
Note that any of the options above (time based, service based and content based) could be combined.
The traffic affected by a bandwidth change may be all of the traffic to/from a particular subscriber or only a specific
subset related to the given service requested. For example, in option 3) above only the video traffic would benefit from
the newly available bandwidth. Also, depending on the service requested, bandwidth changes may have an impact on
upstream and/or downstream traffic.
Bandwidth rates and the services to which they apply may be explicitly requested by the user or the user may request
pre-defined policies. The request could be performed through a web portal. When explicitly requesting a bandwidth
rate, the user includes sufficient information to identify the traffic that should be boosted. When requesting a
pre-defined policy, the user minimally indicates the policy s/he wants to activate. In this last scenario the user/web
portal may be unaware of the specific bandwidth change that RACS will apply in the network since RACS will hide this
information.
Figure 1 represents an example of a possible realization of this service.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 182 022 V2.0.0 (2007-12)
11. W Wee a assssuumeme the the UseUserr C CPPE NeE Networktwork Ses Sesssioion isn is
3333
SPDSPDSPDFFF aallreadreadyy es establistablishehed and thd and that that the use user per poolicylicy ca can ben be
aappliepplied. Thed. Therre me maayy or may or may not bnot bee a a defadefault policult policy y
8888 aapplieppliedd
22. A  A UsUser loger logss in into theto the Porta Portall an and sd seeleclectts tos to ac activattivate e
4444
tthhe Boe BoDD SSeerrvviicece
33. The The porta portal forwl forwardsards the the requ requestest onto onto the the SPDF SPDF
(inc(includeludes Us Usseerr Iden Identifier atifier and Bnd BooDD PProfilerofile to to
aapplypply))
A-RA-RA-RAAACCCFFF
TRTRTRISISIS
5555
44. SPD SPDF usF useses the the Us User IP aer IP addreddressss or nu or numericmeric
6666
ideidenntifietifier to mr to maap thp the ree requequest tost to an A an A--RARACCFF
2222
55. Ad Admismisssionion Co Control Pntrol Poolicylicy i inn the the A-R A-RAACF uCF usseess
TRTRIS infoIS informatiormation to n to detedeterminermine wh whetheether therer there are are
ssuufficiefficiennt ret resousourrcesces to a to addmitmit the the rreequequest (ast (assssumeume
7777
yeyes)s)
66. A  A newnew net netwwork ork policpolicyy se set is t is consconstructructed for thited for thiss
reqrequuesest. t.
77. B BooDD PPolicyolicy R Ruulele is ap is appliedplied to th to the Re RCCEF EF and/and/or or
ANAN
88. A-R A-RAACCFF g giivesves pos positiveitive req requuesest rest responponse se to SPDto SPDF F
wwhhichich forwa forwarrds ds conconffiirrmatiomation to n to useuserr throu through thgh the e
1111
PoPortalrtal

Figure 1: Bandwidth-on-Demand Scenario
The sequence of operations is as follows:
• The user logs on to a web portal and selects the BoD service.
• The Web Portal forwards the request to the SPDF including a user identifier (e.g. IP address or numeric
identifier) plus an indication of quantity for bandwidth boost (this may be explicitly indicated in the request, or
it is possible to reference pre-defined BoD classes).
• The SPDF uses the user identifier to map the request to an appropriate A-RACF.
• The A-RACF accesses information from the TRIS, if needed via TRSF, to determine whether there are
sufficient network bandwidth resources to admit the request (we assume there are).
• A new policy set is constructed and applied in the network for the user according to the quantity of bandwidth
requested.
• A positive response is forwarded to the user.
• If the Admission Control fails, the user is notified, and no upgrade is configured.
This scenario illustrates the need for current topology and resource information to be available to RACS to allow
accurate allocation of resources for new requests. The topology and resource information is maintained in the form of
the TRIS as discussed in clause 4.2.2. Implementation of the storage medium for TRIS and its location are for further
study but are discussed in annex F to [1].
4.1.3 Preferred functional properties
The topology and resource information maintained by RACS (i.e. TRIS) should be independent of the network
technology and particular deployments. That is, the actual information stored by RACS may differ between different
network technologies and deployments, but the information model used to maintain the required knowledge should be
the same for all network technologies and deployments.
Although TRIS is network technology and deployment independent the protocols used to retrieve resource topology and
state information can be network technology specific. For example, a protocol used to retrieve the information may
have different profiles or parameters to support specific network technologies.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 182 022 V2.0.0 (2007-12)
Interfaces for retrieving topology and resource information should support both push and pull. That is, entities
communicating topology and resource information to RACS should be able to push information at any time and without
delay. RACS should also be able of explicitly pull information from such entities at any time and without delay. For
example, a change in topology of the transport network may result in a notification that there are no resources available.
4.2 Mechanisms for Resource Monitoring
RACS needs mechanisms to retrieve and store TRIS. This includes mechanism to keep TRIS up-to-date. Moreover,
RACS needs mechanisms to distribute subsets of it for usage in different RACS functional entities. Before discussing
these mechanisms the type of information to maintain in TRIS and the principles of the information model of TRIS
need to be however defined. Clauses 4.2.1 and 4.2.2 provide this definition and these principles. Thereafter, the
mechanisms involved in retrieving, storing and distributing TRIS are described in clause 4.2.3.
4.2.1 Type of information to be monitored
The resource monitoring mechanisms of RACS are to maintain a topology and resource information
specification (TRIS) following the topology and resource information model (TRIM).
TRIM can conceptually be separated into five levels:
1) Physical Topology: Device and interface entities of the physical network topology (i.e. the transport segments
controlled by RACS) are represented at the first level of TRIM (i.e. network topology information). This
includes the connections between entities (i.e. connections between interfaces and between interfaces and
devices). Entities represented are routers, switches or any other network nodes and network interfaces
(physical or logical). At minimum, all contention points should be represented to support meaningful resource
admission control. Whether a represented entity is in operation or not is modelled.
2) Logical Topology: that describes logical pipes and entry points. The map between physical and logical
topology can be maintained by RACS or outside RACS (e.g. in the OSS system) depending on the deployment
scenario
3) At the third level of TRIM, routing information that describes the connectivity through the topology modelled
at the first and the second levels is represented. This information allows identification of the set of device and
interface entities traversed by media flows between each transport segment edge-points.
4) Resource information is represented at the fourth level. This information may model a hierarchy of resources
to accurately describe how capacity is shared at network devices or interfaces between traffic classes. It may
further include measurement results for the actual usage of the resources. Each resource is mapped to a device
or interface entity represented at the first level of TRIM and/or a logical pipes represented at the second level
of TRIM.
5) Selection Information: constitutes the fifth level of TRIM. This information allow requests issued over Gq' to
be routed to the correct functional entities within RACS.
4.2.2 Principles of the information specification
As mentioned above, TRIS needs to be both accurate and up-to-date with the transport segments it models. This clause
discusses what parts of TRIS that can be expected to be dynamic and what parts that are likely to be more static over
time. The time-scales at which dynamic information may change depends on network technology and configuration.
Time-scales are therefore not specifically discussed herein.
The topology information at the first level of TRIS constitutes bootstrap information needed by RACS to interact with
individual network devices (i.e. the addresses to network devices are needed). Although the physical topology may not
change individual network devices and/or interfaces may be taken out of service for failure, maintenance or other
reasons. Hence, the first level information of TRIS can be considered partly static and potentially partly dynamic.
The logical topology information at the second level of TRIS can be considered static and retrieved by OSS systems or
interacting with network devices.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 182 022 V2.0.0 (2007-12)
The source of the routing information at the third level of TRIS may be implicit in the sense that the routing algorithm
is known (e.g. shortest path first) or explicit in
...