ETSI TS 183 067 V3.1.1 (2009-11)

Telecommunications and Internet converged Services and Protocols for Advanced Networks (TISPAN); Mapping of multicast and unicast transport control protocols to Re - stage 3

RTS/TISPAN-03191-NGN-R3

General Information

• Status: Published
• Publication Date: 09-Nov-2009
• Technical Committee: TISPAN 3 - TISPAN Protocols
• Current Stage: 12 - Completion
• Due Date: 18-Nov-2009
• Completion Date: 10-Nov-2009

Standards Content (Sample)

ETSI TS 183 067 V3.1.1 (2009-11)
Technical Specification


Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Mapping of multicast and unicast transport control protocols
to Re - stage 3

---------------------- Page: 1 ----------------------
2 ETSI TS 183 067 V3.1.1 (2009-11)



Reference
RTS/TISPAN-03191-NGN-R3
Keywords
interface, network, system
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual 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 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 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 reproduced 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.

TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP 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 are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TS 183 067 V3.1.1 (2009-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Overview . . 6
4.1 Overview of multicast transport control protocol to Re mapping . . 6
4.2 Overview of unicast transport control protocol to Re mapping . 7
4.2.1 Push Mode . 7
4.2.2 Pull Mode . 8
5 Behaviours of the transport functions for multicast . 9
5.1 PULL mode: case 1 . 9
5.2 PULL mode: case 2 . 10
6 Multicast to Re parameters mapping . 10
6.1 PULL mode: case 1 . 10
6.2 PULL mode: case 2 . 11
7 Behaviours of the transport functions for unicast . 12
7.1 Push mode (RACS initiated Procedures) . 12
7.1.1 Handling Policy-Install-Request from RACS . 12
7.1.1.1 Activation of a Policy Rule . 12
7.1.1.2 Policy Modification . 12
7.1.1.3 Deactivation of a Policy Rule. 12
7.1.2 Handling unicast transport control protocol events . 13
7.1.2.1 RSVP Reservation establishment . 13
7.1.2.2 RSVP Reservation Reject/Establishment Failure/Modification Failure . 13
7.1.2.3 RSVP Reservation Loss/Tear-Down . 13
7.2 Pull mode (RCEF initiated Procedures) . 14
7.2.1 Reservation pre-authorization . 14
7.2.2 Reservation establishment in pull mode . 14
7.2.3 Reservation Loss/Tear-Down . 14
7.2.4 Reservation Modification . 15
8 RSVP to Re parameters mapping . 16
8.1 Push Mode . 16
8.1.1 Re PIR to RSVP Path Parameter Mapping . 16
8.2 Pull Mode . 17
8.2.1 RSVP Resv to Re CCR Parameter Mapping . 17
Annex A (informative): Change history . 18
History . 19

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 183 067 V3.1.1 (2009-11)
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 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, 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 Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 183 067 V3.1.1 (2009-11)
1 Scope
The present document describes the signalling behaviour of the transport functions BTF & RCEF for the listed multicast
and unicast transport control protocols (IGMP, MLD, RSVP) and Diameter Re and provides a mapping between these
multicast and unicast transport control protocols and the TISPAN RACS Re interface.
2 References
References are either specific (identified 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 possible 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.
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 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.
[1] IETF RFC 2205: "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification".
[2] ETSI TS 183 060: "Telecommunications 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".
[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) for 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) applies.
Not applicable.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TS 183 067 V3.1.1 (2009-11)
3 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
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-Request
CPN 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 Equipment
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 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 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 several BTFs and one or several RCEFs that may be colocalised.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 183 067 V3.1.1 (2009-11)

Figure 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. This 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" 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 sends 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 to 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 to check any policy-rule
previously downloaded because this request is not linked to any user's 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 to 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 to Re mapping in Push Mode with on-path QoS reservation in the case of a successful
reservation establishment.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 183 067 V3.1.1 (2009-11)

Figure 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, 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 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.
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

---------------------- Page: 8 ----------------------
9 ETSI TS 183 067 V3.1.1 (2009-11)
1) The BTF receives an RSVP Path message corresponding to a path-coupled QoS reservation 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 RCEF 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. After 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 confirm 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 communicates 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_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 consider 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 leave 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 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
applying 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-Bandwidth-DL for the corresponding policy based on the value received from
the A-RACF. If the value is set to zero, the BTF shall not forward the corresponding multicast flow.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 183 067 V3.1.1 (2009-11)
5.2 PULL mode: case 2
On reception of an IGMPv3/MLDv2 request, the BTF communicates 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_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 the corresponding multicast flow is already received. If it is the case, the RCEF
shall ignore the request for that pair. If not, the RCEF shall send a CC-Request applying the mapping defined
in clause 6.2 for IGMPv3/MLDv2.
• If Record Type indicates BLOCK_OLD_SOURCE or CHANGE_TO_INCLUDE_MODE with an empty
source list, the RCEF shall check if other UE are still requesting the corresponding multicast flow. If not, the
RCEF may send a CC-Request applying the mapping defined in clause 6.2 for IGMPv3/MLDv2.
NOTE: The way the transport functions know that a channel is not required by any other UEs is based on
Membership Query mechanisms as defined in RFC 3376 [6] (IGMPv3) and RFC 2236 [7] (IGMPv2) and
based on Membership Listener query mechanisms as defined in RFC 3810 [8] (MLDv2).
On reception of an IGMPv2 request, BTF communicates the request to the RCEF.
If the type is set to 0x16 "v2 Membership Report", the RCEF shall check if the requested multicast address indicated in
the Group Address parameter is already received. If it is the case, the RCEF shall ignore the request. If not, the RCEF
shall send a CC-Request applying the mapping defined in clause 6.2 for IGMPv2.
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 check if other UEs are still requesting the corresponding multicast flow. If not, the RCEF may
send a CC-Request applying the mapping defined in clause 6.2 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 Flow-Description, the RCEF shall create
the corresponding policy. The transport function shall forward the corresponding multicast flow applying QoS
parameters defined in the Policy-Rule-Install AVP. For any previously reported Flow-Description that does not receive
any corresponding Policy-Rule-Install AVP, the BTF shall not forward the corresponding multicast flow.
6 Multicast to Re parameters mapping
6.1 PULL mode: case 1
When the RCEF sends a CCR for PULL mode case 1, it shall use the mapping defined in table 6.1 for IGMPv3/MLDv2
request.
Table 6.1: Rules for derivation of CCR AVPs from IGMPv3/MLDv2 requests for PULL mode case 1
CCR AVPs Derivation from IGMPv3/MLDv2 Parameters
CC-Request-Type It shall be set to UPDATE_REQUEST.
Event-Trigger It shall be set to RESOURCES_MODIFICATION.
Policy-Update-Request
For each multicast/source address:
• Policy-rule-Name shall be set to the corresponding policy rule name for that pair.
• Policy_rule_status shall be set to ACTIVE.
• if Record Type indicates ALLOW_NEW_SOURCE with INCLUDE filter mode or
CHANGE_TO_EXCLUDE_MODE with no "Source address" fields:
o Max-Requested-Bandwidth-UL shall be set to zero.
o Max-Requested-Bandwidth-DL shall be set to FFFFFFFF.
• if Record Type indicates BLOCK_OLD_SOURCE or
CHANGE_TO_INCLUDE_MODE with an empty source list:
o Max-Requested-Bandwidth-UL shall be set to zero.
o Max-Requested-Bandwidth-DL shall be set to zero.

ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 183 067 V3.1.1 (2009-11)
When the RCEF sends a CCR for PULL mode case 1, it shall use the mapping defined in table 6.2 for IGMPv2 request.
Table 6.2: Rules for derivation of CCR AVPs from IGMPv2 requests for PULL mode case 1
CCR AVPs Derivation from IGMPv2 Parameters
CC-Request-Type It shall be set to UPDATE_REQUEST.
Event-Trigger It shall be set to RESOURCES_MODIFICATION.
Policy-Update-Request • Policy-rule-Name shall be set to the corresponding policy rule name for that group
address indicated in the request.
• Policy_rule_status shall be set to ACTIVE.
• If the type is set to 0x16 "v2 Membership Report":
o Max-Requested-Bandwidth-UL shall be set to zero.
o Max-Requested-Bandwidth-DL shall be set to FFFFFFFF.
• If the type is set to 0x17 "Leave Group":
o Max-Requested-Bandwidth-UL shall be set to zero.
o Max-Requested-Bandwidth-DL shall be set to zero.

6.2 PULL mode: case 2
When the RCEF sends a CCR for PULL mode case 2, it shall use the mapping defined in table 6.3 for IGMPv3/MLDv2
request.
Table 6.3: Rules for derivation of CCR AVPs from IGMPv3/MLDv2 requests for PULL mode case 2
CCR AVPs Derivation from IGMPv3/MLDv2 Parameters
CC-Request-Type
It shall be set to UPDATE_REQUEST.
Framed-IP address
It shall set to termination point IP address.
Physical-Access-Id It shall not be present.
Logical-Access-Id It shall not be present.
User-Name It shall not be present.
Called-station-ID It shall not be present.
Event-Trigger It shall be set to RESOURCES_MODIFICATION.
Policy-rule-Report
If the flow is already received, for each multicast/source address:
• Policy-rule-Name shall be set to the corresponding policy rule name for that pair.
• If Record Type indicates BLOCK_OLD_SOURCE or
CHANGE_TO_INCLUDE_MODE with an empty source list, Policy-Rule-status shall
be se to INACTIVE.
Flow-Description If the flow is not already received, for each multicast/source address:
• Direction shall be set to "in".
• Destination address shall be set to the "multicast address".
• Source address shall be set to the Source address if present.
• Source and Destination port shall be not be supplied.

When the RCEF sends a CCR for PULL mode case 2, it shall use the mapping defined in table 6.4 for IGMPv2 request.
Table 6.4: Rules for derivation of CCR AVPs from IGMPv2 requests for PULL mode case 2
CCR AVPs Derivation from IGMPv2 Parameters
CC-Request-Type
It shall be set to UPDATE_REQUEST.
Event-Trigger It shall be set to RESOURCES_MODIFICATION.
Policy-rule-Report If the flow is already received:
• Policy-rule-Name shall be set to the corresponding policy rule name for the Group
Address indicated in the request.
• If the type is set to 0x17 "Leave Group" Policy-Rule-status shall be se to INACTIVE.
Flow-Description If the flow is not already received:
• Direction shall be set to "in".
• Destination address shall be set to the Group Address parameter.
• Source address shall not be supplied.
• Source and Destination port shall be not be supplied.

ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 183 067 V3.1.1 (2009-11)
7 Behaviours of the transport functions for unicast
7.1 Push mode (RACS initiated Procedures)
This clause specifies the behavior of the RSVP transport functions for unicast in the case of Push mode with on-path
QoS reservation.
7.1.1 Handling Policy-Install-Request from RACS
On receipt of a Policy-Install-Request from RACS, the RCEF shall process the message as specified in TS 183 060 [2].
In addition, when operating in the Push mode with on-path QoS reservation, the RCEF shall extend this behavior as
defined in clause 7.1.1.1 (respectively clauses 7.1.1.2 and 7.1.1.3) in case of policy activation (respectively policy
modification and policy deactivation).
7.1.1.1 Activation of a Policy Rule
On receipt of a Policy-Install-Request with PI-Request-Type AVP containing the value INITIAL_REQUEST that
activates a new Policy Rule with Flow-Status ENABLED-DOWNLINK, the RCEF shall consider that a new on-path
QoS reservation is to be initiated for each IP Flow defined in a Flow-Description AVP. The RCEF shall communicate
with the BTF to ensure that an RSVP Path message is transmitted. The parameters in the RSVP Path message shall be
mapped from those of the PIR command in accordance with table 8.1.
The BTF is responsible for refreshing the RSVP path state in accordance with RSVP procedures during all the time that
the corresponding Policy Rule is maintained active by the RACS.
7.1.1.2 Policy Modification
On receipt of a Policy-Install-Req
...