ETSI TR 182 013-2006 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Bearer Control Stage 2 Requirements《电信和互联网融合业务及高级网络协议(TISPAN)_1.pdf

《ETSI TR 182 013-2006 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Bearer Control Stage 2 Requirements《电信和互联网融合业务及高级网络协议(TISPAN)_1.pdf》由会员分享，可在线阅读，更多相关《ETSI TR 182 013-2006 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) Bearer Control Stage 2 Requirements《电信和互联网融合业务及高级网络协议(TISPAN)_1.pdf（21页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TR 182 013 V1.1.1 (2006-06)Technical Report Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Bearer Control;Stage 2 RequirementsETSI ETSI TR 182 013 V1.1.1 (2006-06) 2 Reference DTR/TISPAN-02024-NGN Keywords bearer, control ETSI 650 Route des Luc

2、ioles 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: htt

3、p:/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 p

4、rinting 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 htt

5、p:/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 an

6、d 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 TIPHON logo are Trade Marks currently being re

7、gistered 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 013 V1.1.1 (2006-06) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 3 Definitions and abbr

8、eviations.6 3.1 Definitions6 3.2 Abbreviations .6 4 Introduction 7 5 Functional Model .7 6 Requirements8 7 Information flows.10 7.1 BCF source addressing information flows .10 7.2 Uni-directional QoS path establishment information flows .11 7.3 Bidirectional QoS path establishment information flows.

9、13 7.3.1 Unified-allocated forward-and-backward-resource information flows.13 7.3.2 Separately-allocated forward-and-backward-resource information flows 16 8 The relationship with TISPAN NGN .18 Annex A (informative): Mapping ITU-T Q.Sup51 into TR-RACF .20 History 21 ETSI ETSI TR 182 013 V1.1.1 (200

10、6-06) 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 found in ETSI SR 000 314: “Intellectual

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

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

13、 been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). ETSI ETSI TR 182 013 V1.1.1 (2006-06) 5 1 Scope The present document identifies a range of issues which occur if Bearer Control Function communicates with eac

14、h other. The present document is based on concepts developed in ITU-T Q.Sup51: “Signalling Requirements For IP-QoS“. The present document covers the part of NCI (Network Control Interface) interface which provides multiple bearer routes between source and destination. 2 References For the purposes o

15、f this Technical Report (TR) the following references apply: 1 ITU-T Recommendation H.360: “An architecture for end-to-end QoS control and signalling“. 2 ITU-T Recommendation Y.1291: “An architectural framework for support of Quality of Service in packet networks“. 3 ITU-T Q.Sup51: “Signalling Requi

16、rements For IP-QoS “. 4 ITU-T Recommendation E.360.1: “Framework for QoS routing Resource and Admission Control Sub-system (RACS); Functional Architecture“. 14 MSF MSF-TR-QoS-001-FINAL: “Quality of Service for Next Generation Voice Over IP Networks“. 15 3GPP TR 23.802: “Architectural Enhancements fo

17、r End-to-End Quality of Service (QoS)“. NOTE: Also some of the above referenced URI Schemes are currently updated. ETSI ETSI TR 182 013 V1.1.1 (2006-06) 6 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: bearer: conn

18、ection for the transport of user plane information between users involved in a communication NOTE: Derived from 12. Bearer Control Function (BCF): functional entity that performs the Resource and Admission Control functions related to QoS requests as well as routing functions NOTE: Derived from 12.

19、connection: “transport entity“ which consists of an associated pair of “unidirectional connections“ capable of simultaneously transferring information in opposite directions between their respective inputs and outputs 11 IP data Stream: sequence of packets sent to convey communication between the tw

20、o endpoints identified by the Stream Information Session Control Function (SCF): functional entity that provides the call/session control functionality NOTE: Derived from 3. Service Control Function (SvCF): functional entity that provides value-added service functionality NOTE: Derived from 3. strea

21、m information: information necessary to identify an IP data stream Switching Function (SF): functional entity that performs stream classification, switching and forwarding NOTE 1: I.e. QoS guarantee. NOTE 2: Derived from 3. 3.2 Abbreviations For the purposes of the present document, the following ab

22、breviations apply: AF Application Function BCF Bearer Control Function MPLS Multi-Protocol Label Switch NASS Network Access Subsystem NCI Network Control Interface PDF Policy Decision Function QoS Quality of Service RACS Resource And Control Subsystem RCEF Remote Control Emulation Function SCF Sessi

23、on Control Function SCI Switching Control Interface SF Switching Function SPDF Service Protocol Data Function SvCF Service Control Function UE User Equipment ETSI ETSI TR 182 013 V1.1.1 (2006-06) 7 4 Introduction In order to tone up the satisfaction of the end user, we often provide multiple bearer

24、routes in the bearer network. For example, when an end user make an IP call from source to destination, network provides route A for him; however, the QoS quality of route A is not good enough. When the end user ring off the call, and make the same call again, the network can change another route B

25、for him. If the bearer network is a network that there are multiple bearer routes between source and destination, the SCF can not make the routing judgement, and it should be done by BCFs. Thus need routing selection Information being commuted between BCF(s). 5 Functional Model Figure 1: The functio

26、nal model of bearer control requirements Figure 1 depicts the functional model consisting of SCF, BCF, SF, and NCIs. The functions are structured into 2 layers, namely the call and session layer and the transport layer. The transport layer is further subdivided into the bearer control plane and the

27、transport plane. The bearer control plane is composed of the BCFs. In particular it does the resource calculation related to service request. (For the MPLS case, it is also responsible for path selection and resource allocation, which characterize the logical bearer network of this service type). Th

28、e transport plane is composed of the SFs and the media source and sinks. The proposed modular bearer control components and the interfaces that interconnect them relate to the functional model as follows: a) BCF: BCFs (Bearer Control Functions) are responsible for establishing, modifying and releasi

29、ng the network resources necessary to provide the negotiated arrangement. One BCF interacts with a peer BCF to establish and disconnect network facilities on a link-by-link basis. BCF components provide a generic and flexible connection model that encompasses multimedia call requirements. The BCF re

30、ceives a QoS request from the SCF, based on a service stream. (For the MPLS case, the BCF performs service routing. For the non-MPLS case, it performs the identification of the logical path). After path-analysis, like service routing or the logical-path identification, it delivers the path-analysis

31、results to the SF. The BCF needs certain network topology information and resource status information in order to be able to evaluate QoS requests and generate QoS configuration data. b) SCF: An end user interacts with the SCF in order to request some service. The SCF initiate a QoS request, usually

32、 the SCF decides the parameters of a communications arrangement (such as bandwidth, quality of service, etc.). If an acceptable set of parameters can be negotiated, the SCF uses the services provided by the BCF to establish, maintain and disconnect the network resources necessary to provide the nego

33、tiated arrangement. ETSI ETSI TR 182 013 V1.1.1 (2006-06) 8 c) SF: SFs cross-connect a virtual connection at one port with a virtual connection at another port. Via one or more cross-connects at various SFs located between users, a virtual connection is created between the users. The characteristics

34、 of this virtual connection are based on the call parameters negotiated at the SCF level and the route is determined by BCF level. Based on instructions received over the SCI (Switching Control Interface), the SF controlled by the BCF creates and destroys cross-connects. NOTE: For the MPLS case, it

35、also performs MPLS transfer. d) NCI: The NCI (Network Control Interface) is the interface between the functions of bearer control plane of transport layer. 6 Requirements The QoS signalling (running on the Network control interface) in the bearer control plane should accomplish the following functio

36、ns: 1) Request for resources to support service: The current BCF initiates a QoS request to the next hop BCF for an interface, with the following main parameters are: - Connection ID: the unique ID for each request. Each connection may contain multiple streams. - It is a requirement to have a “conne

37、ction ID“ to allow the sender and receiver to match a request with following responses, related modifications and cancellations. It is left for protocol design to determine which side generates that connection ID. - Stream information: Information to identify an IP data stream. - QoS parameters: A d

38、escription of the service quality requirements of a stream. Many international standards are available for reference in this respect, hence no further description here. - Path information selected in the local domain and the previous domains (for the MPLS case: By means of consultation, data stream

39、bearer path LSP sets are distributed between the BCFs, so conditions of LSP paths selected in the local domain and the previous domains should be provided for each other among BCFs, so that a peer BCF can correctly select a transit path LSP. For a bidirectional path, both forward path and backward p

40、ath are available, such as MPLS label stack). Address information of the inter-domain interface: The address of the egress interface in the local domain (for the non-MPLS case). 2) Modification of resources to support service: In respect with some services, it may be necessary to modify the QoS requ

41、irements at any time during the service running. According to the request by the upstream BCF, a BCF modifies the bandwidth that was applied for use at the previous time. Multi-time modification is supported. Main parameters are: - Connection ID: The unique ID for each request. Each connection may c

42、ontain multiple streams. - Stream information: Information to identify an IP data stream. - QoS parameters: A description of the service quality requirements of a stream. Many international standards are available for reference in this respect, hence no further description here. 3) Acceptance of req

43、uest for resources to support service: Upon allocating the local domain resources, the BCF responds a piece of success information to the upstream BCF. Main parameters are: - Connection ID. Accepted QoS parameters: Among multi-optional QoS capabilities, the accepted QoS capability is selected. - Who

44、le path information for the connection (for the MPLS case). ETSI ETSI TR 182 013 V1.1.1 (2006-06) 9 Address information of the inter-domain interface: The address of the egress interface in the local domain (for the non-MPLS case). 4) Rejection of request for resources to support service: When the B

45、CF finds out that the QoS request of the upstream BCF cannot be satisfied, it will send a rejection response to the upstream BCF. Main parameters are: - Connection ID. - Rejection cause. 5) Report about resources to support service: In case of any change with the allocated bandwidth information (the

46、 resource seized by the connection is no longer available, etc.; for example), BCF should report it to the upstream BCF. Main parameters: - Connection ID. - Current status. 6) Release of resources to support service: The upstream BCF requests the downstream BCF for releasing the resource that has be

47、en requested for allocation. Main parameters are: - Connection ID. - Release cause. 7) Response for release for resources: The cancellation of resources should be confirmed to the upstream BCF. Main parameters are: - Connection ID. - Execution results. ETSI ETSI TR 182 013 V1.1.1 (2006-06) 107 Infor

48、mation flows Within the signalling flows, the following functional entities have certain roles. They are described below. Table 1: Roles of Functional Entities Destination BCF The destination BCF receives a QoS request based on a service stream, sent by the previous hop BCF. When it finds out that t

49、he destination IP of the service stream belongs to the BCF domain that is under its administration, if the request is a bidirectional one, the destination BCF will deliver the routing result of the QoS path from the destination to the source directly to the edge router, and return the response message of the QoS path from the source to the destination to the previous hop BCF. Destination SF The destination SF is an SF to which a certain service stream destination belongs. The destination SF transmits a data packet directly to a user or transfers it to ano