ETSI TR 182 015-2006 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Next Generation Networks Architecture for Control of Processi_1.pdf

《ETSI TR 182 015-2006 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Next Generation Networks Architecture for Control of Processi_1.pdf》由会员分享，可在线阅读，更多相关《ETSI TR 182 015-2006 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Next Generation Networks Architecture for Control of Processi_1.pdf（54页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TR 182 015 V1.1.1 (2006-10)Technical Report Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Next Generation Networks;Architecture for Control of Processing OverloadETSI ETSI TR 182 015 V1.1.1 (2006-10) 2 Reference DTR/TISPAN-02026-NGN Keywords c

2、ontrol, architecture ETSI 650 Route des 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 p

3、resent 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 ca

4、se 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 a

5、nd 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 authori

6、zed by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2006. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIP

7、HON logo are Trade Marks currently being 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 015 V1.1.1 (2006-10) 3 Contents Intellectual Property Rights5 Foreword.5 Intr

8、oduction 5 1 Scope 7 2 References 7 3 Definitions and abbreviations.8 3.1 Definitions8 3.2 Abbreviations .8 4 Requirements for NGN overload controls9 4.1 NGN overload scenarios 9 4.1.1 Processing overload sizes .9 4.1.2 Media stimulated events .9 4.1.3 Disasters10 4.1.4 Network Failures 10 4.1.5 Con

9、clusion 10 4.2 Impact of overload on resources and customer behaviour .10 4.3 NGN Interfaces requiring overload controls 11 4.4 NGN architectural factors.12 4.5 GOCAP requirements.13 5 Overload control design rules.14 6 Detailed NGN overload control architecture16 6.1 Control architecture: General a

10、pproach16 6.2 Options for locating components (M, D and R) .17 6.2.1 Case 1: protocol supports reject of service requests by the target with an indication of overload17 6.2.2 Case 2: protocol supports an indication of overload, but not rejection of service requests 18 6.2.3 Case 3: protocol supports

11、 neither rejection of service requests nor indication of overload19 6.2.4 Preferred locations of components20 6.3 Destination load control .20 6.3.1 Control loops in series 21 6.3.2 Called address translation .21 6.4 Control of server overload22 6.4.1 Control loops in series 23 6.5 Joint control of

12、destination- and server-overload .23 6.6 AMG to MGC fan-in issue.24 6.7 Discriminating between importance levels.25 6.8 Interworking with load balancing and forking .25 6.9 Interworking with information hiding proxies .25 6.10 Multiple controls at an overloaded resource.27 6.11 Specification of stan

13、dardized control components .28 6.11.1 Mapping of the M, D 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

14、 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. Fore

15、word This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). Introduction Next Generation Networks (NGN) are required to provide real-time services such as authentication, location, pr

16、esence information, user registration, accounting, and separation of bandwidth control from call/session control (as with the gateway control protocol H.248); and these functions will generally be distributed over a number of servers. The protocols used between the servers could comprise any, or all

17、, of the following: SIP, HTTP(S), Radius, Diameter, DNS, COPS, SNMP, SMPP, SAML, LDAP, Parlay, Java, SOAP, Midcom, H.248, SIP-I, INAP, etc. An analysis of IETF Working Groups suggests that much thought has been, and is being, given to the management of bandwidth and router congestion (see, for examp

18、le, RFC 3124 5 “The Congestion Manager“), but almost none to control of host and server processing overload. Indeed, although some of the above listed protocols (e.g. SIP and HTTP) do provide response or status codes that might be used to indicate processing overload, none explicitly specifies an ov

19、erload control mechanism. The same conclusion also seems to apply to the following non-IETF protocols: H.323 8, SOAP, SAML, SMPP, and Parlay. This contrasts with the telephony/ATM world where there are examples of protocols that have built-in overload control features: INAP, ISUP, BICC, PNNI and mor

20、e recently overload control package H.248.11 7. Such controls are crucial during extremes of network operation where surges of service requests (or Denial of Service attacks) can be an order of magnitude greater than normal demand levels. As a general rule, an NGNs servers can experience prolonged p

21、rocessing overload under the appropriate circumstances (e.g. partial, or full, server failure, high rates of incoming service requests). Consequently, it needs to be equipped with some form of overload detection and control (including expansive controls such as load balancing and resource replicatio

22、n), in order to keep response times just low enough under such processing overload to preclude customers abandoning their service requests prematurely. The usual way to provide load control is to build a mechanism into each protocol that needs it (for example ISUP ACC, and the H.248.11 7 Congestion

23、Control Package). However, rather than building a variety of mechanisms into a range of protocols, established through a number of standards fora, it ought to be quicker and cheaper to solve the problem once, in a way that is independent of the main protocols. This could be done by designing a separ

24、ate overload control protocol with associated load control functions which together detect processing overload, adapt and distribute restriction levels and apply restriction. This protocol is called GOCAP (Generic Overload Control Application Protocol). ETSI ETSI TR 182 015 V1.1.1 (2006-10) 6 The pe

25、rceived benefits are: 1) IT- and internet-based protocols will more easily transfer into the service-level assured world of the telecommunications operators. 2) Manufacturers have only one overload control mechanism to implement and maintain. 3) It would simplify the route through standards bodies.

26、4) It would provide flexibility of implementation (no need to implement if not required). The present document explores the some of the options for GOCAP and the functional entities required to support its use as an overload control. The specific NGN requirements and actual protocol specification of

27、 such an overload control will be described separately. ETSI ETSI TR 182 015 V1.1.1 (2006-10) 7 1 Scope The present document describes the architectural principles that are required to provide effective control of processing overload in networks compliant to the TISPAN NGN Architecture. As such it c

28、onstitutes a discussion of the requirements for the protocols required to support the NGN overload control architecture. The scope is limited to the control of processing overload at NGN processing resources caused by service requests coming from session-based or command-response applications by con

29、trolling the rate at which those applications send service requests to an overloaded resource. It does not extend to the overload of transmission bandwidth whether used for the user plane or for the control plane. 2 References For the purposes of this Technical Report (TR), the following references

30、apply: NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity. 1 ETSI ES 283 039-3: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Specification of protocols required

31、 to support the NGN Overload Control Architecture; Part 3: Overload and Congestion Control for H.248 MG/MGC“. 2 Whitehead M J and Williams P M, “Adaptive Network Overload Controls“, BT Technology Journal, Vol. 20, No. 3, July 2002. 3 ITU-T Recommendation E.412 (01/2003): “Network management controls

32、“. 4 ETSI TR 180 001: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Release 1; Release definition“. 5 IETF RFC 3124: “The Congestion Manager“. 6 ITU-T Recommendation H.248.10: “Gateway control protocol: Media gateway resource congestion handl

33、ing package“. 7 ITU-T Recommendation H.248.11: “Gateway control protocol: Media gateway overload control package“. 8 ITU-T Recommendation H.323: “Packet-based multimedia communications systems“. 9 ITU-T Recommendation H.248.1: “Gateway control protocol: Version 3“. 10 ITU-T Recommendation E.164: “Th

34、e international public telecommunication numbering plan“. 11 ETSI EN 383 001: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control (BICC) Protocol or ISDN User Pa

35、rt (ISUP) ITU-T Recommendation Q.1912.5, modified“. ETSI ETSI TR 182 015 V1.1.1 (2006-10) 8 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: admission control: control that accepts or rejects request on the basis of

36、system load state NOTE: This “admission control“ relates only to requests accepted and rejected on the basis load state of processing resource. This is a separate control to that used to manage access to transport resource. 3.2 Abbreviations For the purposes of the present document, the following ab

37、breviations apply: A Admission (control, function) ACC Automatic Congestion Control ACL Access Control List ADC Automatic Destination Control AF Application Function AMG Access Media Gateway API Application Programming Interface A-RACF Access Resource Admission Contol Function ATM Asynchronous Trans

38、fer Mode BGF Border Gateway Function BICC Bearer Independent Call Control C Communication (applications) C Control (variable) CA Call Agent COPS Common Open Policy Service D Distribution (function)DNS Domain Name System DoS Denial of Service GOCAP Generic Overload Control Application Protocol HTTP H

39、yperText Transfer Protocol IETF Internet Engineering Task Force IMS Internet protocol based Multimedia core network Subsystem INAP Intelligent Network Application Protocol IP Internet ProtocolISUP ISDN User Part IT Information Technology LDAP Lightweight Directory Access Protocol M Monitor (reject M

40、onitor and restriction Mastering function) MGC Media Gateway Controller NGN Next Generation Network NOCA NGN Overload Control Architecture OSA Open Service Access pA pseudo-AdmissionPDU Packet Data Unit PNNI Private Network to Network Interface PSTN Public Switched Telephone Network R Restrictor, Re

41、striction (method) RACS Resource and Admission Control Subsystem RADIUS Remote Authentication Dial-in User Service SAML Security Access Markup Language SCP Service Control Point SCTP Stream Contol Transmission Protocol SIP Session Initiation Protocol ETSI ETSI TR 182 015 V1.1.1 (2006-10) 9 SIP-I SIP

42、 profile C of EN 383 001 11 SLA Service Level Agreement SMPP Short Message Peer to Peer Protocol SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SPDF Service Policy Decision Function TCP Transmission Contol ProtocolTISPAN Telecommunications and Internet converged Services

43、and Protocols for Advanced Networking TLS Transaction Layer Security UDP User Datagram Protocol URI Uniform Resource Identifier VoIP Voice-over-IP 4 Requirements for NGN overload controls 4.1 NGN overload scenarios 4.1.1 Processing overload sizes Overloads peak at calling rates much greater than the

44、 predictable daily profile peak to which the network can be economically dimensioned. Table 1 taken from 2 shows the range of calling rate measurements taken from BTs network (based on 15 minute samples). We can see that overload can exceed 64 times the systematic peak calling rate for six 15 minute

45、s periods a year. While, during such an overload we might expect a large proportion of call attempts to fail, however, it would be unacceptable for the network to fail completely due to processing overload. In particular, the network would prioritize service of emergency traffic and other important

46、streams. The reality of massive overloads has been demonstrated by data from PSTN networks, how do these overloads occur? Table 1: Extremes of the calling rate distribution Calling rate expressed as a multiple of systematic quarter hour peak Number of quarter hours per year calling rate is exceeded

47、(% of quarter hours) 2 344 (1 %) 4 139 (0,4 %) 8 51 (0,1 %) 16 22 (0,06 %) 32 17 (0,05 %) 64 6 (0,02 %) 4.1.2 Media stimulated events This is a family of events such as televotes for TV programmes, ticket sales and phone-ins which can all generate high calling rates to particular small ranges of num

48、bers. In 2, it is reported that these events occur with a frequency of several thousand a month. Some of the largest events are televotes stimulated by TV programmes, and such events can have a very rapid onset, with the calling rate increasing at a rate of 4 k calls per second per second over 6 sec

49、onds observed in parts of BTs network. Often these events are known about in advance, so steps can be taken to prepare the overload controls. Also they are usually focussed on a small range of destinations, so controls like ADC 3 may help to reject sessions unlikely to succeed early in the call setup process. ETSI ETSI TR 182 015 V1.1.1 (2006-10) 104.1.3 Disasters Disasters, such as major accidents, terrorist attacks or extreme weather, may stimulate overloads, some times focussed on a few destinations (emergency services, information line