1、 ETSI TS 183 067 V3.1.1 (2009-11)Technical Specification Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Mapping of multicast and unicast transport control protocolsto Re - stage 3ETSI ETSI TS 183 067 V3.1.1 (2009-11)2Reference RTS/TISPAN-03191-NGN-R3
2、 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 Individual
3、 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 For
4、mat (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
5、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 e
6、xcept 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 ETSI regi
7、stered 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 GSM logo
8、 are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 183 067 V3.1.1 (2009-11)3Contents Intellectual Property Rights 4g3Foreword . 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.
9、2 Abbreviations . 6g34 Overview 6g34.1 Overview of multicast transport control protocol to Re mapping 6g34.2 Overview of unicast transport control protocol to Re mapping 7g34.2.1 Push Mode 7g34.2.2 Pull Mode . 8g35 Behaviours of the transport functions for multicast . 9g35.1 PULL mode: case 1 9g35.2
10、 PULL mode: case 2 10g36 Multicast to Re parameters mapping 10g36.1 PULL mode: case 1 10g36.2 PULL mode: case 2 11g37 Behaviours of the transport functions for unicast . 12g37.1 Push mode (RACS initiated Procedures) 12g37.1.1 Handling Policy-Install-Request from RACS . 12g37.1.1.1 Activation of a Po
11、licy Rule . 12g37.1.1.2 Policy Modification . 12g37.1.1.3 Deactivation of a Policy Rule 12g37.1.2 Handling unicast transport control protocol events 13g37.1.2.1 RSVP Reservation establishment 13g37.1.2.2 RSVP Reservation Reject/Establishment Failure/Modification Failure 13g37.1.2.3 RSVP Reservation
12、Loss/Tear-Down . 13g37.2 Pull mode (RCEF initiated Procedures) . 14g37.2.1 Reservation pre-authorization . 14g37.2.2 Reservation establishment in pull mode . 14g37.2.3 Reservation Loss/Tear-Down . 14g37.2.4 Reservation Modification . 15g38 RSVP to Re parameters mapping . 16g38.1 Push Mode 16g38.1.1
13、Re PIR to RSVP Path Parameter Mapping . 16g38.2 Pull Mode . 17g38.2.1 RSVP Resv to Re CCR Parameter Mapping 17g3Annex A (informative): Change history . 18g3History 19g3ETSI ETSI TS 183 067 V3.1.1 (2009-11)4Intellectual Property Rights IPRs essential or potentially essential to the present document m
14、ay 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
15、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 o
16、f 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 Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services a
17、nd Protocols for Advanced Networking (TISPAN). ETSI ETSI TS 183 067 V3.1.1 (2009-11)51 Scope The present document describes the signalling behaviour of the transport functions BTF - for informative references. Referenced documents which are not found to be publicly available in the expected location
18、 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 validity. 2.1 Normative references The following referenced documents are indispensable for the application of the presen
19、t document. For dated references, only the edition cited applies. For non-specific references, the latest edition of the referenced document (including any amendments) applies. 1 IETF RFC 2205: “Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification“. 2 ETSI TS 183 060: “Telecommu
20、nications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Subsystem (RACS); Re interface based on the DIAMETER protocol“. 3 IETF RFC 3181: “Signaled Preemption Priority Policy Element“. 4 IETF RFC 3182: “Identity Representation for RSVP“
21、. 5 IETF draft-ietf-tsvwg-rsvp-proxy-proto: “RSVP Extensions for Path-Triggered RSVP Receiver Proxy“. 6 IETF RFC 3376: “Internet Group Management Protocol, Version 3“. 7 IETF RFC 2236: “Internet Group Management Protocol, Version 2“. 8 IETF RFC 3810: “Multicast Listener Discovery Version 2 (MLDv2) f
22、or IPv6“. 2.2 Informative references The following referenced documents are not essential to the use of the present document but they assist the user with regard to a particular subject area. For non-specific references, the latest version of the referenced document (including any amendments) applie
23、s. Not applicable. ETSI ETSI TS 183 067 V3.1.1 (2009-11)63 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: termination point: element acting as the neighbouring multicast router receiving and handling IGMP/MLD request
24、 from the UE 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AF Application Function A-RACF Access-Resource and Admission Control Function BTF Basic Transport Functions CAC Connection Admission Control CCA Credit-Control-Answer CCR Credit-Control-Reques
25、tCPN Customer Premises Network IGMP Internet Group Management Protocol IPTV Internet Protocol Television MLD Multicast Listener Discovery QoS Quality of Service RACS Resource and Admission Control Subsystem RCEF Resource Control Enforcement Function RSVP Resource ReSerVation Protocol UE User Equipme
26、nt 4 Overview 4.1 Overview of multicast transport control protocol to Re mapping PULL mode for multicast applies in two cases: PULL mode case 1: when it applies below the termination point in the access segment, the PULL mode is used to request resources for a channel in the access network and/or to
27、 indicate that the resources associated to a channel can be released as the channel is left. This is per user and can be combined with the PUSH mode at session initiation to allow the A-RACF to download the permitted multicast flow for that user to the RCEF. PULL mode case 2: when it applies beyond
28、the termination point, the PULL mode is used to request shared resources to transport a multicast flow corresponding to a channel that has been requested by one or more users. The following figure shows a generic scenario for both cases of PULL mode. Transport processing nodes comprises one or sever
29、al BTFs and one or several RCEFs that may be colocalised. ETSI ETSI TS 183 067 V3.1.1 (2009-11)7Figure 4.1: A generic scenario for both cases of PULL mode 1) Upon session activation, the RACS downloads the policy rules in the RCEF in charge of enforcing policies applicable to the access segment. Thi
30、s corresponds e.g. to the list of subscribed channels in case of IPTV service activation. For each policy, bandwidth is set to zero, this will force the transport processing node to trigger the PULL mode. 2) The BTF receives a multicast request. This message may contain IGMP/MLD “leave“ and/or “join
31、“ requests. 3) The BTF requests CAC towards the RCEF. The RCEF checks that the requested channel corresponds to an existing policy-rule. If not, it ignores the request and the user will not receive the channel. If a policy-rule exists, and if PULL mode applies below the termination point, the RCEF s
32、ends a CC-Request to the RACS based on parameters received in the multicast request. It has therefore to indicate to the RACS that the UE wants to leave a particular channel and/or wants to join another one. If enough resource is available to join the requested channel, the RACS answers positively t
33、o the RCEF. 4) If the step 3 is successful, the BTF forwards the request to the RCEF dealing with resource beyond the termination point. If PULL mode applies beyond the termination point, the RCEF sends a CC-Request to the RACS based on parameters received in the multicast request. It does not have
34、to check any policy-rule previously downloaded because this request is not linked to any users rights. The RACS can determine if enough resource is available in the aggregation segment. If this is the case, the RACS answers positively to the RCEF. 4.2 Overview of unicast transport control protocol t
35、o Re mapping The mapping between unicast transport control protocol and Re may be invoked in the Push Mode or the Pull Mode. An overview is provided below for both cases. The mapping is defined with RSVP (1) as the unicast transport control protocol. 4.2.1 Push Mode Figure 4.2 illustrates the RSVP t
36、o Re mapping in Push Mode with on-path QoS reservation in the case of a successful reservation establishment. ETSI ETSI TS 183 067 V3.1.1 (2009-11)8Figure 4.2: RSVP to Re mapping in Push Mode with on-path QoS reservation 1) As a result of a request from the AF for admission and resource reservation,
37、 the RACS sends a Policy-Install-Request to the RCEF in order to install a policy rule into the Transport Processing Nodes. 2) In the Push mode with on-path QoS signaling, the RCEF communicates the request to the BTF that issues an RSVP Path message to initiate path-coupled QoS signaling in order to
38、 establish the necessary reservation in the Transport Processing Nodes. 3) On receipt of an RSVP Resv message, the BTF communicates the reservation establishment to the RCEF. 4) The RCEF sends a Policy-Install-Answer to the RACS to confirm policy rule installation in the Transport Processing Nodes.
39、4.2.2 Pull Mode Figure 4.3 illustrates the RSVP to Re mapping in Pull Mode in the case of a successful reservation establishment. Figure 4.3: RSVP to Re mapping in Pull Mode ETSI ETSI TS 183 067 V3.1.1 (2009-11)91) The BTF receives an RSVP Path message corresponding to a path-coupled QoS reservation
40、 initiation request from a Transport Node (e.g. a CPN Device). The BTF communicates the request to the RCEF. 2) The RCEF sends a CCR request to the RACS to request authorization of the reservation initiation request based on parameters mapped from the RSVP Path message. 3) The RCEF responds to the R
41、CEF with a CCA to confirm that the reservation initiation request is authorized. The RCEF confirms the authorization decision to the BTF. 4) The BTF forwards the RSVP Path message towards the reservation destination. 5) The BTF receives an RSVP Resv message requesting reservation establishment. Afte
42、r successful RSVP reservation establishment, the BTF communicates the resource reservation establishment to the RCEF. 6) The RCEF sends a CCR request to the RACS to request resource reservation based on parameters mapped from the RSVP Resv message. 7) The RACS responds to the RCEF with a CCA to conf
43、irm the reservation establishment. The RCEF communicates the establishment decision to the BTF. 8) The BTF forwards the RSVP Resv message towards the reservation source. 5 Behaviours of the transport functions for multicast 5.1 PULL mode: case 1 On reception of an IGMPv3/MLDv2 request, the BTF commu
44、nicates the request to the RCEF. If the type is set to 0x22 “v3 Membership Report“ in case of IGMPv3 or to 143 “Version 2 Multicast Listener Report“ in case of MLDv2, the RCEF shall take the following actions for each Group/multicast Records present in the request: If Record Type indicates ALLOW_NEW
45、_SOURCE with INCLUDE filter mode or CHANGE_TO_EXCLUDE_MODE with no “Source address“ fields, the RCEF shall check for each multicast address/source address pair if it corresponds to an existing policy rule. If not, the RCEF shall ignore the request for that pair. If this is the case, the RCEF shall c
46、onsider that the UE wants to join the corresponding multicast flow and shall send a CC-Request applying the mapping defined in clause 6.1 for IGMPv3/MLDv2. If Record Type indicates BLOCK_OLD_SOURCE or CHANGE_TO_INCLUDE_MODE with an empty source list, the RCEF shall consider that the UE wants to leav
47、e the corresponding multicast flow and shall send a CC-Request applying the mapping defined in clause 6.1 for IGMPv3/MLDv2. On reception of an IGMPv2 request, the BTF communicates the request to the RCEF. If the type is set to 0x16 “v2 Membership Report“, the RCEF shall consider that the UE wants to
48、 join the corresponding multicast flow and shall take the following actions: If the multicast address indicated in the Group Address parameter corresponds to an existing policy rule, the RCEF shall consider that the UE wants to join the corresponding multicast flow and shall send a CC-Request applyi
49、ng the mapping defined in clause 6.1 for IGMPv2. If not, the RCEF shall ignore the request for that pair. If the type is set to 0x17 “Leave Group“, the RCEF shall consider that the UE wants to leave the corresponding multicast flow and shall send a CCR request applying the mapping defined in clause 6.1 for IGMPv2. On receipt of a CC-Answer, the RCEF shall behave as defined in TS 183 060 2. For each Policy-Rule-Install AVP that corresponds to a previously reported Policy-Update-Request in the CCR, the RCEF shall update the Max-Requested-Bandw
