ETSI TR 183 070-2009 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Resource and Admission Control Sub-System (RACS) Rr interface_1.pdf

《ETSI TR 183 070-2009 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Resource and Admission Control Sub-System (RACS) Rr interface_1.pdf》由会员分享，可在线阅读，更多相关《ETSI TR 183 070-2009 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Resource and Admission Control Sub-System (RACS) Rr interface_1.pdf（13页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TR 183 070 V3.1.1 (2009-08)Technical Report Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Resource and Admission Control Sub-System (RACS);Rr interface based on the ANCP protocolETSI ETSI TR 183 070 V3.1.1 (2009-08) 2 Reference DTR/TISPAN-0319

2、8-NGN-R3 Keywords interface, network, system 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 In

3、dividual 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 Docu

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

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

6、oduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2009. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of E

7、TSI registered 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. LTE is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the

8、GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TR 183 070 V3.1.1 (2009-08) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 2.1 Normative references .5 2.2 Informative references5 3 Abbreviations .5 4 Overview 6 5 Scenarios of ANCP for the

9、 Rr Interface.7 5.1 Compound Protocol Scenario of ANCP for the Rr Interface .7 6 Procedure descriptions .8 6.1 General .8 6.2 Procedures on the Rr interface .8 6.2.1 Provisioning of delegated bandwidth8 6.2.2 Increase of delegated bandwidth.9 6.2.3 Decrease of delegated bandwidth .10 6.2.4 Query of

10、delegated bandwidth11 7 ANCP application 12 8 General Conclusion12 History 13 ETSI ETSI TR 183 070 V3.1.1 (2009-08) 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 an

11、y, 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 o

12、n 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) w

13、hich 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 ETSI TR 183 070 V3.1.1 (2009-08) 5 1 Scope

14、The present document provides a report on the study of the applicability of the ANCP protocol to the Rr interface between Generic Resource Admission Control Function (x-RACF) instances. Whenever it is possible the present document specifies the requirements for this protocol by reference to specific

15、ations produced by the IETF within the scope of ANCP. Where this is not possible, extensions to ANCP are defined within the present document. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific refere

16、nce, 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; - fo

17、r 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. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term valid

18、ity. 2.1 Normative references The following referenced documents are indispensable for the application of the present document. For dated references, only the edition cited applies. For non-specific references, the latest edition of the referenced document (including any amendments) applies. Not app

19、licable. 2.2 Informative references i.1 ETSI ES 282 001: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture“. i.2 ETSI ES 282 003: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (T

20、ISPAN); Resource and Admission Control Sub-System (RACS): Functional Architecture“. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: AN Access Node ANCP Access Node Control Protocol IETF Internet Engineering Task Force NAS Network Access Server RACS Resour

21、ce and Admission Control Sub-System ETSI ETSI TR 183 070 V3.1.1 (2009-08) 6 x-RACF Generic Resource Admission Control Function 4 Overview The present document describes the ANCP protocol for the RACS Rr interface. The Rr interface is used for QoS resource reservation between x-RACF instances of RACS

22、 within a single administrative domain. The functional requirements and the stage 2 specifications of the Rr interface are contained in ES 282 001 i.1 and ES 282 003 i.2. Rrx - RACFAFSPDF BGFRCEFNASSRe IaGq Rd, Ri Rqe4Transport Processing FunctionsRACSBTF RfFigure 4.1: Rr interface ETSI ETSI TR 183

23、070 V3.1.1 (2009-08) 7 5 Scenarios of ANCP for the Rr Interface 5.1 Compound Protocol Scenario of ANCP for the Rr Interface Figure 5.1 illustrates a scenario where the ANCP could be applicable for the Rr interface. In this scenario, there are three types of network entities, the standalone RACS, the

24、 IP edge (i.e. NAS in IETF) and the access node. The top-tier x-RACF is deployed on a standalone RACS device, while the lower-tier x-RACF is deployed on the access node. The RACS supports the Diameter protocol but not the ANCP protocol with the IP Edge. The access node supports the ANCP protocol but

25、 not the Diameter protocol with the IP Edge. Therefore, the top-tier x-RACF and the lower-tier x-RACF do not interact directly with each other using a common protocol. They always interact with each other indirectly via an intermediate network entity, i.e. the IP Edge, using both Diameter and ANCP p

26、rotocols. Figure 5.1: A Scenario of ANCP Applicable for the Rr Interface In this scenario, the top-tier x-RACF manages one part of the bandwidth of the access segment and performs admission control for unicast flows, while the lower-tier x-RACF manages the other part of the bandwidth of the access s

27、egment and performs admission control for multicast flows. When the bandwidth managed by the top-tier x-RACF of the access segment is sufficient for a new unicast request, the top-tier x-RACF performs the admission control without interaction with the low-tier x-RACF. When the bandwidth managed by t

28、he top-tier x-RACF of the access segment is insufficient for a new unicast request, the top-tier x-RACF will send a request to the low-tier x-RACF to ask for more bandwidth for unicast flows: If the low-tier x-RACF has sufficient free bandwidth, it will grant the requested amount of bandwidth to be

29、managed by the top-tier x-RACF. After this interaction, the part of the bandwidth managed by the lower-tier x-RACF has been decreased and meanwhile the other part of he bandwidth managed by the top-tier x-RACF has been increased. Then the top-tier x-RACF can have sufficient bandwidth to meet the uni

30、cast request. If the low-tier x-RACF has insufficient free bandwidth, it will refuse to grant the amount of bandwidth to be managed by the top-tier x-RACF. Then the top-tier x-RACF will refuse the unicast request because of insufficient bandwidth. RACS SPDF top-tier x-RACF IP Edge Access Node lower-

31、tier x-RACF Rr Diameter Rr ANCP ETSI ETSI TR 183 070 V3.1.1 (2009-08) 8 When the bandwidth managed by the lower-tier x-RACF of the access segment is sufficient for a new multicast request, the lower-tier x-RACF performs the admission control without interaction with the top-tier x-RACF. When the ban

32、dwidth managed by the lower-tier x-RACF of the access segment is insufficient for a new multicast request, the lower-tier x-RACF will send a request to the top-tier x-RACF to ask for more bandwidth for multicast flows: If the top-tier x-RACF has sufficient free bandwidth, it will grant the requested

33、 amount of bandwidth to be managed by the lower-tier x-RACF. After this interaction, the part of the bandwidth managed by the top-tier x-RACF has been decreased and meanwhile the other part of the bandwidth managed by the lower-tier x-RACF has been increased. Then the lower-tier x-RACF can have suff

34、icient bandwidth to meet the multicast request. If the top-tier x-RACF has insufficient free bandwidth, it will refuse to grant the amount of bandwidth to be managed by the lower-tier x-RACF. Then the lower-tier x-RACF will refuse the multicast request because of insufficient bandwidth. 6 Procedure

35、descriptions 6.1 General In the present document, the RACS acts as the delegating x-RACF as well as the SPDF and is responsible for the admission control for unicast services, while the AN acts as the delegated x-RACF and is responsible for the admission control for multicast services. IP Edge acts

36、as an intermediate entity between the delegating x-RACF and the delegated x-RACF. The ANCP protocol operates between the IP Edge and AN, and supports the delegated model of the Rr reference point. 6.2 Procedures on the Rr interface 6.2.1 Provisioning of delegated bandwidth The procedure of provision

37、ing of delegated bandwidth is illustrated in figure 6.1. This procedure is triggered during the users network attachment phase. The RACS also reuse this procedure to synchronize the delegated bandwidth with the AN. ETSI ETSI TR 183 070 V3.1.1 (2009-08) 9 Figure 6.1: Provisioning of delegated bandwid

38、th 1) During the network attachment phase, the CLF notifies the RACS of the event that the user is online. The RACS obtains or decides the initial delegated bandwidth for the users multicast services based on for example the local configuration on the RACS. 2) The RACS sends to IP Edge a message con

39、taining the provisioning data of the delegated bandwidth for the users multicast services. 3) The IP Edge sends to AN an ANCP message containing the provisioning data of the delegated bandwidth for the users multicast services. 4) The AN saves the delegated bandwidth for the users multicast services

40、 for future use and sends an ANCP response to the IP Edge. 5) The IP Edge sends a response to the RACS. 6.2.2 Increase of delegated bandwidth The procedure of increase of delegated bandwidth is illustrated in figure 6.2. This procedure is triggered by the AN when there is not sufficient delegated ba

41、ndwidth for multicast services. RACS IP Edge AN 1. Trigger 2. Provisioning of Delegated Bw 3. Provisioning of Delegated Bw 4. Response 5. Response ETSI ETSI TR 183 070 V3.1.1 (2009-08) 10Figure 6.2: Increase of delegated bandwidth 1) The procedure of increase of delegated bandwidth is triggered by t

42、he AN when there is not sufficient delegated bandwidth for a new multicast request. The AN decides to ask for more delegated bandwidth to meet the requirement of the new multicast request. 2) The AN sends to the IP Edge an ANCP message to increase the delegated bandwidth. 3) The IP Edge sends to the

43、 RACS a message to increase the delegated bandwidth. 4) The RACS checks whether it can increase the delegated bandwidth or not without affecting the admitted unicast services, and sends to the IP Edge a response accordingly. 5) The IP Edge sends an ANCP response to the AN. If an amount of sufficient

44、 delegated bandwidth is increased, the AN admits the multicast request. Otherwise, the AN rejects the multicast request. 6.2.3 Decrease of delegated bandwidth The procedure of decrease of delegated bandwidth is illustrated in figure 6.3. This procedure is triggered by the RACS when there is not suff

45、icient bandwidth for unicast services. RACS IP Edge AN 1. Trigger 2. Increase Delegated Bw Request 4. Response 5. Response 3. Increase Delegated Bw Request ETSI ETSI TR 183 070 V3.1.1 (2009-08) 11Figure 6.3: Decrease of delegated bandwidth 1) The procedure of decrease of delegated bandwidth is trigg

46、ered by the RACS when there is not sufficient bandwidth for a new unicast request. The RACS decides to get sufficient amount of delegated bandwidth back to its own control to meet the requirement of the new unicast request, which leads to the procedure of decrease of delegated bandwidth. 2) The RACS

47、 sends to the IP Edge a message to decrease the delegated bandwidth. 3) The IP Edge sends to the AN an ANCP message to decrease the delegated bandwidth. 4) The AN checks whether it can decrease the delegated bandwidth or not without affecting the admitted multicast services, and sends to the IP Edge

48、 a ANCP response accordingly. 5) The IP Edge sends an response to the RACS. If an amount of sufficient delegated bandwidth is decreased, the RACS gets sufficient bandwidth for unicast services and then admits the unicast request. Otherwise, the RACS rejects the unicast request. 6.2.4 Query of delega

49、ted bandwidth The procedure of query of delegated bandwidth is illustrated in figure 6.4. This procedure is triggered by the AN. RACS IP Edge AN 1. Trigger 3. Decrease Delegated Bw Request 5. Response 4. Response 2. Decrease Delegated Bw Request ETSI ETSI TR 183 070 V3.1.1 (2009-08) 12Figure 6.4: Query of delegated bandwidth triggered by the AN 1) When the AN detects that there is possibility that the AN and the RACS holds different data of delegated bandwidth (e.g. when it fails to receive a response to the increase of delegated bandwidth request