ETSI TR 182 022-2007 Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN) Architectures for QoS handling《电信和互联网融合业务及高级网络协议(TISPAN) QoS的.pdf

《ETSI TR 182 022-2007 Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN) Architectures for QoS handling《电信和互联网融合业务及高级网络协议(TISPAN) QoS的.pdf》由会员分享，可在线阅读，更多相关《ETSI TR 182 022-2007 Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN) Architectures for QoS handling《电信和互联网融合业务及高级网络协议(TISPAN) QoS的.pdf（17页珍藏版）》请在麦多课文档分享上搜索。

1、 . 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 handlingETSI ETSI TR 182 022 V2.0.0 (2007-12) 2 Reference DTR/TISPAN-02039-NGN-R2 Keywords architecture, QoS ETSI 650 Route des

2、 Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from:

3、 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 t

4、he 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

5、 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 copyrigh

6、t and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2007. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently bein

7、g registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 182 022 V2.0.0 (2007-12) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 2.1 Informative re

8、ferences5 3 Definitions and abbreviations.6 3.1 Definitions6 3.2 Abbreviations .6 4 Resource Monitoring6 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 Deman

9、d8 4.1.3 Preferred functional properties .9 4.2 Mechanisms for Resource Monitoring .10 4.2.1 Type of information to be monitored10 4.2.2 Principles of the information specification .10 4.2.3 Sources of information11 5 QoS Reporting11 5.1 General principles of QoS Reporting .12 5.1.1 Overview 12 5.1.

10、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 architecture15 7 Relationship between Resource Monitoring and QoS Reporting.15 His

11、tory 17 ETSI ETSI TR 182 022 V2.0.0 (2007-12) 4 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

12、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 t

13、o 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.

14、 Foreword This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). ETSI ETSI TR 182 022 V2.0.0 (2007-12) 5 1 Scope The present document presents an overall analysis of architectural req

15、uirements 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 cov

16、ers 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 a

17、n 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 i

18、t 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

19、 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 (identifi

20、ed 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 possi

21、ble 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 docum

22、ents, 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

23、 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 ter

24、m 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 Serv

25、ices and Protocols for Advanced Networking (TISPAN); Requirements for QoS in a NGN“. ETSI ETSI TR 182 022 V2.0.0 (2007-12) 6 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 t

26、he 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 cont

27、rolled 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 Serve

28、rATM Asynchronous Transfer Mode BGF Border Gateway Function BoD Bandwidth on Demand CAC Call Admission Control CDR Call Detail RecordCPE Customer Premises Equipment IP Internet Protocol OSS Operation Support System PCR Peak Cell Rate QoS Quality of Service QRC QoS Reporting Collector QRS QoS Reporti

29、ng 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

30、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, re

31、source 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

32、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

33、 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 ETSI TR 182 022 V2.0.0 (2007-12) 7 Clause 4.1 discusses the general principles in retrieving, storing and keeping TRIS up-to-date to fac

34、ilitate 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 cu

35、rrent 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 RAC

36、S 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 for

37、warding 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

38、 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 inform

39、ation 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 pr

40、otect 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

41、 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 pro

42、vide 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 c

43、ase 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 par

44、ameter 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 th

45、e 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 ap

46、proach 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 co

47、ntrol 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

48、, 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 resourc

49、e information (TRIS) maintained by the RACS is independent of the network technology and particular deployments. ETSI ETSI TR 182 022 V2.0.0 (2007-12) 8 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 usuall