ANCP R. Maglione, A. Garofalo
Internet Draft Telecom Italia
F. Le Faucheur, T. Eckert
Cisco Systems
Intended status: June 29, 2007
Expires: December 2007
ANCP Multicast Handling
draft-maglione-ancp-mcast-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Maglione Expires December 29, 2007 [Page 1]
Internet-Draft ANCP Multicast Handling June 2007
Abstract
This draft is aimed at presenting ANCP Multicast Handling in order to
extend the high level multicast description currently present in [1]
and [2]. The document describes the ANCP Multicast use cases as well
as the protocol requirements and message flows derived from the use
cases. The proposal is mainly driven by the following two objectives.
First, enabling NAS and AN to functionally behave as one single black
box, while replication is performed on the AN, but without any loss
of functionality compared to if replication was performed on NAS.
Second, allowing the necessary information to be provided by NAS to
the AN to perform multicast admission decision locally when possible
and/or desirable, and allowing the AN to query the NAS when further
decisions are needed.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3].
Table of Contents
1. Introduction...................................................3
2. Multicast Terminology..........................................4
3. Multicast Use Cases............................................5
3.1. Multicast Conditional Access..............................5
3.2. Multicast Admission Control...............................6
3.3. Multicast Accounting......................................7
3.4. Multicast Termination.....................................8
4. Protocol Requirements..........................................8
4.1. Conditional Access Use case with local AN decision........8
4.2. Conditional Access and Admission Control with NAS decision9
4.3. Multicast Accounting.....................................10
4.4. Conditional Access and Admission Control with local-AN
decisions within a given Flow-Group...........................10
4.5. Multicast Termination....................................11
5. Message Flow..................................................11
5.1. Provision AN with initial configurations.................12
5.1.1. Provisioning AN with White/Black-List and Conditional
Access with AN Decision....................................12
5.1.2. Provisioning AN with Multicast Flow-Groups..........13
Maglione Expires December 29, 2007 [Page 2]
Internet-Draft ANCP Multicast Handling June 2007
5.2. Multicast Flow Admission Control.........................14
5.2.1. Multicast Flow with NAS decision, without accounting,
without Policy Server Synchronization......................14
5.2.2. Multicast Flow with NAS Decision, with accounting,
Without Policy Server Synchronization......................16
5.2.3. Multicast Flow with NAS decision, without accounting,
with Policy Server Synchronization.........................18
5.2.4. Multicast Flow with NAS decision, without accounting,
without Policy Server Synchronization, with AAA Server
Multicast Authorization....................................20
5.2.5. Multicast Flow Replication Stop with accounting,
without Policy Server Synchronization......................21
5.3. Multicast Flow-Group Admission Control...................22
5.3.1. Multicast Flow-Group with NAS decision, without
accounting, without Policy Server Synchronization..........22
5.3.2. Multicast Flow-Group with NAS decision, with
accounting, with Policy Server Synchronization.............25
6. Security Considerations.......................................27
7. IANA Considerations...........................................27
8. Acknowledgments...............................................27
9. References....................................................29
9.1. Normative References.....................................29
Author's Addresses...............................................29
Intellectual Property Statement..................................30
Disclaimer of Validity...........................................31
1. Introduction
[1] defines a framework and requirements for an Access Node Control
Mechanism between a Network Access Server (NAS) and an Access Node
(e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a
multi-service reference architecture in order to perform QoS-related,
service-related and Subscriber-related operations. [2] specifies a
Protocol for Access Node Control Mechanism in Broadband Networks in
line with this framework.
[1] and [2] already cover different use cases related to unicast
traffic, but they do not yet appropriately cover multicast use cases.
This document describes key ANCP Multicast use cases as well as the
protocol requirements and message flows derived from such use cases;
Maglione Expires December 29, 2007 [Page 3]
Internet-Draft ANCP Multicast Handling June 2007
This proposal aims at collecting feedback from this community in
order to work towards consensus. Eventually, text derived from the
material in section 3. and 4. would be intended to be incorporated in
"ANCP Framework I-D" [1]. Similarly, text derived from the material
of section 5. would be intended to be incorporated in "ANCP Protocol
I-D" [2] and to be extended with actual protocol extensions.
The proposal is guided by the following objectives:
* when replication is performed by the AN, enable the combination
of NAS and AN to functionally behave as one single black box, without
any loss of functionality compared to if replication was performed on
NAS.
* enable the necessary information to be provided by NAS to the
AN, so that the AN can perform locally the conditional access and
admission control decisions when possible and/or desirable, and allow
the AN to query the NAS for further decisions in other cases.
2. Multicast Terminology
o Multicast Flow: multicast Any Source Multicast (ASM) group or
multicast Source Specific Multicast (SSM) (S,G) channel. An
application channel (such as a TV channel) is mapped onto a
Multicast Flow.
o Multicast Flow-Group: A set of same bandwidth multicast flows
sharing the same conditional access policy. For the purpose of CAC
on the access line, channel changing between flows of the same
Flow-Group can happen without the need for bandwidth or policy
reconsideration.
o Join: signaling from the user equipment that it wishes to start
receiving a new multicast flow. In ASM, it is referred to as a
"Join". In SSM [6], it is referred to as a "subscribe". In IGMPv2,
"joins" are indicated through an "IGMPv2 membership report". In
IGMPv3 [4], "join" are indicated through "IGMPv3 membership
report" using different Filter-Mode-Change (ASM) and Source-List-
Change Records.
Maglione Expires December 29, 2007 [Page 4]
Internet-Draft ANCP Multicast Handling June 2007
o Leave: signaling from the user equipment that it wishes to stop
receiving a multicast flow. With IGMPv2 this is conveyed inside
the "Leave Group" message while in IGMPv3, "leave" is indicated
through "IGMPv3 membership report" message using different Filter-
Mode-Change (ASM) and Source-List-Change Records.
Note that with respect to the join and leave defined above, this
document does not concern itself with all the possible combinations
allowed in [4] for EXCLUDE/INCLUDE in "IGMPv3 membership report"
messages. It only concerns itself with the use of EXCLUDE/INCLUDE to
achieve the equivalent of an ASM join/leave and the equivalent of an
SSM join/leave (see [5]).
3. Multicast Use Cases
3.1. Multicast Conditional Access
In a DSL Broadband access scenario Service Providers may want to
dynamically control, at the network level, access to some Multicast
Flows on a per user basis. This may be used in order to differentiate
among multiple Service Offers or to realize/reinforced conditional
access for sensitive content (in addition to content protection
mechanisms which may also exist at the application level).
In some cases, it is possible to provision the necessary conditional
access information into the AN so the AN can then perform the
conditional access decisions autonomously. For these cases, the NAS
will use ANCP to provision the necessary information in the AN so
that the AN can then perform conditional access enforcement locally
(i.e. decide locally to honor a join or do not honor a join).
In some cases, it is desirable to have the conditional access
decision taken by the NAS. For example, this may be because the
conditional access control needs to be tied to a more complex
policy/authorization mechanism, e.g. time of day access, or location
based access or to invoke a remote authorisation server. For these
cases, the AN will use ANCP to query the NAS, that in turn will
respond to the AN indicating whether the join is to be honored (and
hence replication performed by the AN) or denied.
Maglione Expires December 29, 2007 [Page 5]
Internet-Draft ANCP Multicast Handling June 2007
Querying the NAS before performing a join on the AN may increase
channel join and channel change times. However, pre-provisioning per
subscriber profiles potentially different for each subscriber may
cause high memory requirements on the AN or large delays when
restarting NAS or AN, or when having to change conditional access
policies. The notion of Flow-Groups (introduced in section 2.) is a
means to compromise between these operational factors.
Thus, in some cases, it is desirable to have the decision for
multicast Flow change within aFlow-Group handled by the AN, and have
the NAS only take a conditional access decision upfront for the whole
Multicast Flow-Group. For these cases, the AN will use ANCP to query
the NAS on receipt of the join for the first Multicast Flow from a
given Multicast Flow-Group. Then, when responding to the AN, the NAS
will indicate that the decision applies to the whole Multicast Flow-
Group. The AN can then autonomously honor changes for a given
user/port from one Multicast flow from that Multicast Flow-group to
another Multicast Flow of the same Multicast Flow-Group.
3.2. Multicast Admission Control
The successful delivery of Triple Play Broadband services is quickly
becoming a big challenge for most of the Service Providers nowadays.
Solely increasing available bandwidth is not always practical, cost-
economical and/or sufficient to satisfy end user experience given not
only the strict requirements of unicast delay sensitive applications
like VoIP and Video on Demand, but also the fast growth of multicast
interactive applications such as videoconferencing, digital TV,
digital audio, online movies and networked gaming. These applications
are typically characterized by a delay sensitive nature, an extremely
loss sensitive nature and intensive bandwidth requirements. They are
also typically "non-elastic", which means that they operate at a
fixed bandwidth, that cannot be dynamically adjusted to the currently
available bandwidth.
Therefore an admission control mechanism covering admission of
multicast traffic over the DSL Broadband access is required, in order
to avoid oversubscribing the available bandwidth and negatively
impacting the end user experience.
Maglione Expires December 29, 2007 [Page 6]
Internet-Draft ANCP Multicast Handling June 2007
Considering specifically admission control over the access line,
before honoring a user request to join a new multicast flow, the
combination of AN and NAS MUST ensure admission control is performed
to validate that there is enough "video" bandwidth remaining on the
access line to carry the new flow (in addition to all other multicast
and unicast video traffic). The solution needs to cope with multiple
Flows per access line and needs to allow access line bandwidth to be
dynamically shared across multicast and unicast traffic (both when
unicast CAC is performed by NAS or by some off-path Policy Server).
In some cases, it is desirable to have the multicast admission
control decision taken by the NAS. For example, this may be because
the multicast admission control decision needs to be synchronized
with unicast admission control that may be performed by the NAS, or
that may be performed by a remote entity (e.g. by a remote policy
server) that requires synchronization information about multicast
bandwidth usage. For these cases, the AN will use ANCP to query the
NAS, that in turn will respond to the AN indicating whether the join
is to be honored (and hence replication performed by the AN) or
denied.
In some cases, it is desirable to have the decision for multicast
admission control handled by the AN. With the notion of Flow-Groups
(defined in section 2.), the AN locally performs all the decisions
for multicast flow change within a Flow-Group while the NAS only
takes an admission control decision upfront for the whole Multicast
Flow-Group. For these cases, the AN will use ANCP to query the NAS on
receipt of the join for the first Multicast Flow from a given
Multicast Flow-Group. Then, when responding to the AN, the NAS will
indicate that the admission control decision applies to the whole
Multicast Flow-Group. The AN can then autonomously honor changes for
a given user/port from one Multicast Flow from that Multicast Flow-
Group to another Multicast Flow of the same Multicast Flow-Group.
3.3. Multicast Accounting
Whenever accurate per-subscriber or per access-line, time or volume
based accounting records are required, the AN performing multicast
replication needs to provide the NAS with accurate information in
order to generate accounting information on a per-user/per-Multicast
Flow basis (e.g. when a particular user starts/stops receiving a
Multicast Flow, received volume, replication start and stop
timestamp...).
Maglione Expires December 29, 2007 [Page 7]
Internet-Draft ANCP Multicast Handling June 2007
3.4. Multicast Termination
The capability to dynamically stop the replication of a multicast
flow can be useful in different scenarios: for example in case of
prepaid service when available credit expires Service Provider may
want to be able to stop multicast replication on a specified AN port
for a particular user. Another example of applicability for this
functionality is a scenario where a Service Provider would like to
show a "Content Preview": in this case a multicast content will be
delivered just for a fixed amount of time. In both cases an external
entity (for example a policy server or an external application
entity), instructs the NAS to interrupt the Multicast replication of
a specified multicast flow to a specified user.
When Multicast replication occurs on AN, NAS MUST be able to revoke
the authorization previously granted to the AN to replicate the
multicast flow, for a specific user/group on a specified port. When
Access Node stops replicating a multicast flow for the specified
user/port it should also be able to block successive IGMP requests
for the same group from the same user.
4. Protocol Requirements
This section contains the protocol requirements for the ACNP control
mechanism that can be derived from the previously described use
cases.
4.1. Conditional Access Use case with local AN decision
We define the following notions:
o White list: List that identifies the Multicast Flows for which the
AN, on receiving a join message, is to autonomously start
replicating multicast traffic without requesting further
authorization to the NAS;
o Black list: List that identifies the Multicast Flows for which the
AN, on receiving a join message, autonomously knows that is not
authorized to start replicating multicast traffic.
The White List and Black List can contain entries allowing:
o an exact match for a (*,G) ASM group (e.g. <G=g.h.i.l>)
Maglione Expires December 29, 2007 [Page 8]
Internet-Draft ANCP Multicast Handling June 2007
o an exact match for a (S,G) SSM channel (e.g. <S=s.t.u.v,G=g.h.i.l>
o a mask-based range match for a (*,G) ASM group (e.g.
<G=g.h.i.l/Mask>)
o a mask-based range match for a (S,G) SSM channel (e.g.
<S=s.t.u.v/Mask,G=g.h.i.l/Mask>
The following requirements allow support of the Conditional Access
Use case with local AN decision:
1. ANCP MUST allow AN to be provisioned with Black and White Lists;
2. ANCP MUST allow to bind a particular Black and White Lists to a
given AN port;
3. An AN MUST unconditionally deny join to a Multicast Flow matching
the Black-List for relevant AN Port;
4. An AN MUST unconditionally accept join to a Multicast Flow
matching the White-List for relevant AN Port;
5. When a Multicast Flow matches both in the Black List and the White
List, the AN MUST use the most specific match.
6. Upon receiving a join to a Multicast Flow which does not match
any entry in the Black List nor in the White List for a specific
port, MUST query the NAS, that in turn MUST respond to the AN
indicating whether that join is to be honored or denied.
4.2. Conditional Access and Admission Control with NAS decision
The requirements below allow support of Conditional Access with NAS
decisions as well as query by NAS of a remote AAA authorization
server. This also supports Admission Control with NAS decision (in
turn allowing integrated unicast CAC to be performed either on NAS or
on remote off-path server) while replication is still done on AN:
Maglione Expires December 29, 2007 [Page 9]
Internet-Draft ANCP Multicast Handling June 2007
7. ANCP MUST support Admission Request messages (from AN to NAS) and
Admission Response messages (from NAS to AN). Admission Request
messages allow AN to query NAS for additional decision/information
(e.g. query NAS for additional validation before honoring a join)
8. AN MUST issue Admission Request when further decision by NAS is
needed;
9. NAS MUST issue Admission Response conveying decision to AN.
4.3. Multicast Accounting
The following requirements allow support of the Multicast Accounting
use case with replication done on AN:
10. ANCP Admission Response MUST allow optional indication by NAS
that "accounting is needed" for this port/multicast flow;
11. When Admission Response includes "accounting needed", AN
supporting accounting MUST issue an Information Report whenever
replication starts/stops for the port/Multicast Flow.
4.4. Conditional Access and Admission Control with local-AN decisions
within a given Flow-Group
The following requirements allow support of Conditional Access and
Admission Control with local-AN decisions for all Multicast Flow
changes within a given Flow-Group:
12. ANCP MUST allow the AN to indicate whether the notion of Flow-
Group is supported by the AN or not;
13. ANCP MUST allow AN to be provisioned with Multicast Flow-Groups;
14. When receiving a join request for the first multicast flow of a
given Flow-Group, the AN MUST issue an Admission Request to NAS;
15. ANCP Admission Response, MUST optionally allow NAS to indicate
that a decision is valid for the whole Flow-Group instead of just
for that single Flow;
Maglione Expires December 29, 2007 [Page 10]
Internet-Draft ANCP Multicast Handling June 2007
16. When Admission Response indicates that a NAS decision is valid
for a Flow-group, an AN supporting Multicast Flow-Groups MUST
locally honor all Multicast Flow changes within that Flow-Group
(i.e. without any further Admission Request to NAS);
17. When there is no longer any active Multicast Flow of a given
Flow-Group, an AN supporting Multicast Flow-Groups MUST issue a
Admission Request indicating that the line bandwidth is no longer
used by the Flow-Group.
4.5. Multicast Termination
This requirement allows support of the Multicast Termination use case
with replication done on AN:
18. ANCP MUST allow NAS to revoke a decision that had been conveyed
earlier to AN in an Admission Response;
19. When receiving such a revocation, the AN MUST stop replication of
the corresponding Multicast-Flow to the corresponding user/port.
5. Message Flow
This section presents the Message Flows supporting the uses cases
previously described. Three different categories of Message Flow have
been identified:
o Provision AN with initial configurations (including both
White/Black Lists and Multicast-Flow Groups;) and Conditional
Access with AN Decision
o Multicast Flow Admission control;
o Multicast Flow-Group Admission Control.
Message Flow related to Admission Control are presented combining, in
incremental way, the three basic functions involved in the use cases:
o Admission Control;
o Accounting Capability;
o Policy Server Synchronization.
Maglione Expires December 29, 2007 [Page 11]
Internet-Draft ANCP Multicast Handling June 2007
5.1. Provision AN with initial configurations
5.1.1. Provisioning AN with White/Black-List and Conditional Access
with AN Decision
The following Message Flow describes the AN provisioning with White
and Black lists. Initial configuration for White/Black lists is
called Standard Multicast Profile and is identified by a "Multicast
Profile ID".
The AN provisioning is performed by NAS using a Push Profile message
that contains both the "Multicast Profile ID" and the White/Black
Lists parameters. Each subscriber has its own Multicast Profile ID
associated to the user profile inside the Radius Server. As soon as
DSL line comes up, AN sends a PORT UP message to the NAS specifying
the Port ID, the NAS replies with a PORT_MNGT message that, together
with the other parameters, includes the Multicast Profile ID for that
specific subscriber.
The Messages involved in the following flow are:
o Push_profile (Multicast Profile ID, White/Black Lists)
o PORT_MNGT(Port_ID, Multicast Profile ID)
Maglione Expires December 29, 2007 [Page 12]
Internet-Draft ANCP Multicast Handling June 2007
+-----+ +-----+ +-----+ +-----+
| CPE | | RG | | AN | | NAS |
+-----+ +-----+ +-----+ +-----+
| | | Push_profile( |
| | | Profile_ID) |
| | DSL Synch. |<--------------------|
| |--------------------->| |
| | | PORT_UP(Port_ID) |
| | |-------------------->|
| | | |
| | | PORT_MNGT(Port_ID, |
| | | Profile_ID) |
| | |<--------------------|
| JOIN(White-Fl) | |
|---------------+--------------------->| |
| Mcast-Flow White-Fl1 | |
|<--------------+----------------------| |
| | | |
| LEAVE(White-Fl) | |
|---------------+--------------------->| |
| | | |
| JOIN(Black-Fl) | |
|---------------+--------------------->| |
| | | |
Figure 1 Provisioning AN with White/Black-List and Conditional Access
with AN decision
5.1.2. Provisioning AN with Multicast Flow-Groups
The following Message Flow describes the AN provisioning with
Multicast Flow Group membership.
A Push Membership message is used to push the Flow-Group membership
to AN. The following mapping between single flows and Flow Groups
will be created on the AN:
Flow-Group i= {Flow n, Flow m, ...}, Flow-Group j= {Flow k, Flow l,
...}.
The Message involved in the following flow is:
Maglione Expires December 29, 2007 [Page 13]
Internet-Draft ANCP Multicast Handling June 2007
o Push Membership (Flow Group id, Flow i, Flow j ...)
+-----+ +-----+ +-----+ +-----+
| CPE | | RG | | AN | | NAS |
+-----+ +-----+ +-----+ +-----+
| | | Push_Membership( |
| | | FGid, Fl i, Fl j) |
| | |<-----------------------|
Figure 2 Provisioning AN with Multicast Flow-Groups
5.2. Multicast Flow Admission Control
5.2.1. Multicast Flow with NAS decision, without accounting, without
Policy Server Synchronization
The following Message Flow describes a scenario where Multicast
Admission control is required, while Accounting information and
Policy Server Synchronization are not needed. Admission control is
performed on per single multicast flow.
When AN receives a user request to join a new multicast flow which
has not been explicitly configured in Black or White List for that
port, AN sends an Admission Request message, correlated with Flow id
and Port ID parameters, to the NAS to verify if there is enough
"video" bandwidth remaining on the access line to carry the new flow.
The NAS answers with Admission Response also containing an Accounting
Flag (Acct_F) that specifies if Accounting is needed. In this
scenario Accounting Flag is set to zero, meaning no need for
Accounting Information.
When AN receives a user Leave Message, for the previously joined
multicast flow, AN sends an Admission Release message, correlated
with Flow id and Port ID parameters, to the NAS to release the
previously allocated bandwidth resources.
The Messages involved in the following flow are:
o Admission Request (Flow id, Port Id)
o Admission Response (Acct_F)
Maglione Expires December 29, 2007 [Page 14]
Internet-Draft ANCP Multicast Handling June 2007
o Admission Release (Flow id, Port Id)
+-----+ +-----+ +-----+ANCP +-----+ +------+ +------+
| CPE | | RG | | AN |<--->| NAS | |Policy| |Radius|
+-----+ +-----+ +-----+ +-----+ +------+ +------+
| | | | | |
| Join(Fl1) |Admission | | |
|-----------+---------->|Request(Fl1,| | |
| | | Port_Id)| | |
| | |----------->| | |
| | | | | |
| | | Admission | | |
| | | Response | | |
| Mcast-Flow Fl1 |<-----------| | |
|<----------+-----------| | | |
| | | | | |
| Leave(Fl1) |Admission | | |
|-----------+------ --->|Release(Fl1,| | |
| | | Port_Id) | | |
| | |----------->| | |
| | | | | |
| | | | | |
| | | | | |
| Join(Fl2) |Admission | | |
|-----------+---------->|Request(Fl2,| | |
| | | Port_Id)| | |
| | |----------->| | |
| | | | | |
| | |Admission | | |
| | | Response | | |
| Mcast-Flow Fl2 |<-----------| | |
|<----------+-----------| | | |
| | | | | |
| | | | | |
| Leave(Fl2) |Admission | | |
|-----------+---------->|Release(Fl2,| | |
| | | Port_Id) | | |
| | |----------->| | |
Figure 3 Multicast Flow with NAS decision, without accounting,
without Policy Server Synch Message Flow
Maglione Expires December 29, 2007 [Page 15]
Internet-Draft ANCP Multicast Handling June 2007
5.2.2. Multicast Flow with NAS Decision, with accounting, Without
Policy Server Synchronization
The following Message Flow adds to the functionalities described by
flow in 5.2.1. the accounting capability. The Accounting_Required
Flag sent by NAS in the Admission Response message is set to 1
(meaning Accounting needed) and two new messages are used by AN to
signal Replication Start and Replication Stop.
When NAS receives the Replication Start message from the AN, it sends
an Accounting Start Message to the Radius Server, while when NAS
receives the Replication Stop message from the AN, it sends an
Accounting Stop Message to the Radius Server.
The Messages involved in this flow, in addition to those listed in
5.2.1. are:
o Replication Start (Flow id, Port Id)
o Replication Stop (Flow id, Port Id)
Maglione Expires December 29, 2007 [Page 16]
Internet-Draft ANCP Multicast Handling June 2007
+-----+ +-----+ +-----+ANCP +-----+ +------+ +------+
| CPE | | RG | | AN |<--->| NAS | |Policy| |Radius|
+-----+ +-----+ +-----+ +-----+ +------+ +------+
| | | | | |
| Join(Fl1) | Admission | | |
|-----------+---------->|Request(Fl1,| | |
| | | Port_Id)| | |
| | |----------->| | |
| | | | | |
| | | Admission | | |
| | | Response(A)| | |
| Mcast-Flow Fl1 |<-----------| | |
|<----------+-----------|Replication | | |
| | |Start(PortId| | |
| | | ,Fl1)| | |
| | |----------->| Start Accounting |
| | | | (Port_Id,Fl 1) |
| Leave(Fl1) | Admission |-----------+----------->|
|-----------+---------->|Release(Fl1,| | |
| | | Port_Id) | | |
| | |----------->| Stop Accounting |
| | | | (Port_Id,Fl 1) |
| | | |-----------+----------->|
| | | | | |
| Join(Fl2) | Admission | | |
|-----------+---------->|Request(Fl2,| | |
| | | Port_Id) | | |
| | |----------->| | |
| | | | | |
| | | Admission | | |
| | | Response(A)| | |
| Mcast-Flow Fl2 |<-----------| | |
|<----------+-----------|Replication | | |
| | |Start(PortId| | |
| | | ,Fl2)| | |
| | |----------->| Start Accounting |
| | | | Port_Id,Fl 2 |
| Leave(Fl2) | Admission |-----------+----------->|
|-----------+---------->|Release(Fl2,| | |
| | | Port_Id) | | |
| | |----------->| Stop Accounting |
| | | | (Port_Id,Fl 2) |
| | | |-----------+----------->|
Maglione Expires December 29, 2007 [Page 17]
Internet-Draft ANCP Multicast Handling June 2007
(A) = Accounting_Required flag set
Figure 4 Multicast Flow with NAS Decision, with accounting, without
Policy Server Synch Message Flow
5.2.3. Multicast Flow with NAS decision, without accounting, with
Policy Server Synchronization
The following Message Flow adds to the functionalities described by
flow in 5.2.1. the Policy Server Synchronization. The only difference
between this scenario and the one described in 5.2.1. is the
interaction between NAS and Policy Server. When NAS receives an
Admission Request message from the AN, instead of deciding
autonomously, it sends a QoS Request message to the Policy Server to
verify bandwidth availability. The Policy Server replies with a Qos
Reply message specifying if the NAS should honor the request. When
AN receives a user Leave Message, for the previously joined multicast
flow, AN sends an Admission Release message, correlated with Flow id
and Port ID parameters, to the NAS to release the previously
allocated bandwidth resources. NAS on receiving Admission Release
Message from AN sends a Qos Release Message to the Policy Server.
The Messages involved in this flow, in addition to those listed in
5.2.1. are:
o Qos Request
o Qos Reply
o Qos Release
Maglione Expires December 29, 2007 [Page 18]
Internet-Draft ANCP Multicast Handling June 2007
+-----+ +-----+ +-----+ANCP +-----+ +------+ +------+
| CPE | | RG | | AN |<--->| NAS | |Policy| |Radius|
+-----+ +-----+ +-----+ +-----+ +------+ +------+
| | | | | |
| Join(Fl1) |Admission | | |
|-----------+---------->|Request(Fl1,| | |
| | | Port_Id) | | |
| | |----------->|Qos Request| |
| | | |---------->| |
| | |Admission |Qos Reply | |
| | | Response |<----------| |
| Mcast-Flow Fl1 |<-----------| | |
|<----------+-----------|Replication | | |
| | |Start(PortId| | |
| | | ,Fl1)| | |
| | |----------->| | |
| Leave(Fl1) |Admission | | |
|-----------+---------->|Release(Fl1,| | |
| | | Port_Id) | | |
| | |----------->|Qos Release| |
| | | |---------->| |
| | | | | |
| | | | | |
| Join(Fl2) | Admission | | |
|-----------+---------->|Request(Fl2,| | |
| | | Port_Id) | | |
| | |----------->|Qos Request| |
| | | |---------->| |
| | | Admission | Qos Reply | |
| | | Response |<----------| |
| Mcast-Flow Fl2 |<-----------| | |
|<----------+-----------|Replication | | |
| | |Start(PortId| | |
| | | ,Fl2)| | |
| | |----------->| | |
| Leave(Fl2) | Admission | | |
|-----------+---------->|Release(Fl2,| | |
| | | Port_Id) | | |
| | |----------->|Qos Release| |
| | | |---------->| |
Figure 5 Multicast Flow with NAS Decision, without accounting, with
Policy Server Synchronization
Maglione Expires December 29, 2007 [Page 19]
Internet-Draft ANCP Multicast Handling June 2007
5.2.4. Multicast Flow with NAS decision, without accounting, without
Policy Server Synchronization, with AAA Server Multicast
Authorization
This scenario differs from the one described in 5.2.1. for the
interaction between NAS and Radius Server. In particular when NAS
receives an Admission Request message from the AN, instead of
deciding autonomously, it sends an Authorization Message to the
Radius Server to verify it that user is currently authorized to
received that specific Multicast Flow.
As far as ANCP, Messages involved in this flow are the same as the
ones listed in 5.2.1. , authorization check performed by NAS with
Radius Server, is based on Standard AAA messages.
+-----+ +-----+ +-----+ANCP +-----+ +------+ +------+
| CPE | | RG | | AN |<--->| NAS | |Policy| |Radius|
+-----+ +-----+ +-----+ +-----+ +------+ +------+
| | | | | |
| Join(Fl1) | Admission | | |
|-----------+---------->|Request(Fl1,| | |
| | | Port_Id) | | |
| | |----------->| AAA Authorization |
| | | | (Port_Id,Fl 1) |
| | | |------------+---------->|
| | | Admission | AAA Response |
| | | Response |<-----------+-----------|
| Mcast-Flow Fl1 |<-----------| | |
|<----------+-----------|Replication | | |
| | |Start(PortId| | |
| | | ,Fl1)| | |
| | |----------->| | |
| Leave(Fl1) | Admission | | |
|-----------+---------->|Release(Fl1,| | |
| | | Port_Id) | | |
| | |----------->| | |
| | | | | |
| | | | | |
| | | | | |
Figure 6 Multicast Flow with NAS decision, without accounting,
without Policy Server Synchronization, with AAA Server Multicast
Authorization
Maglione Expires December 29, 2007 [Page 20]
Internet-Draft ANCP Multicast Handling June 2007
5.2.5. Multicast Flow Replication Stop with accounting, without
Policy Server Synchronization
The following Message Flow describes the possibility to
asynchronously stop the Multicast Flow Replication.
When AN receives a user request to join a new multicast flow which
has not been explicitly configured in Black or White List for that
port, AN sends an Admission Request message, correlated with Flow id
and Port ID parameters, to the NAS to verify if there is enough
"video" bandwidth remaining on the access line to carry the new flow.
The NAS answers with Admission Response also containing an Accounting
Flag (Acct_F) that specifies that Accounting is needed (Accounting
Flag is set to one.) When AN receives the Admission Response message
it starts replicating the Multicast Flow and it sends a Replication
Start Message to the NAS. When NAS receives a notification from
Radius server telling that Prepaid Quota for that User/Flow expired,
NAS sends an Admission Teardown message to the AN to stop the
multicast Replication. NAS may include a timer for AN to block
further join to that Flow/Port-ID.
The Messages involved in this flow, in addition to those listed in
5.2.1. are:
o Admission Teardown (Flow id, Port Id)
Maglione Expires December 29, 2007 [Page 21]
Internet-Draft ANCP Multicast Handling June 2007
+-----+ +-----+ +-----+ANCP +-----+ +------+ +------+
| CPE | | RG | | AN |<--->| NAS | |Policy| |Radius|
+-----+ +-----+ +-----+ +-----+ +------+ +------+
| | | | | |
| Join(Fl 1) | Admission | | |
|-----------+---------->|Request(Fl1,| | |
| | | Port_Id) | | |
| | |----------->| | |
| | | | | |
| | | Admission | | |
| | |Response(A) | | |
| Mcast-Flow Fl1 |<-----------| | |
|<----------+-----------|Replication | | |
| | |Start(PortId| | |
| | | ,Fl1)| | |
| | |----------->| Start Accounting |
| | | | (Port_Id,Fl 1) |
| | | |-----------+----------->|
| | | | | |
| | | | | |
| | | | | |
| | | |Quota Expired(PortId,Fl1|
| | | |<----------+------------|
| | | Admission | | |
| | | Teardown() | | |
| | |<-----------| | |
| | |Replication | | |
| | |Stop(Port_Id| | |
| | | ,Fl1)| | |
| | |----------->| | |
Figure 7 Multicast Flow Replication Stop with accounting, Without
Policy Server Synch Message Flow
5.3. Multicast Flow-Group Admission Control
5.3.1. Multicast Flow-Group with NAS decision, without accounting,
without Policy Server Synchronization
The following Message Flow is an optimization of scenario described
in 5.2.1. and it allows support of Conditional Access and Admission
Control for all Multicast Flow changes within a given Flow-Group. On
Maglione Expires December 29, 2007 [Page 22]
Internet-Draft ANCP Multicast Handling June 2007
receiving a Join Request for a new Multicast Flow which has not been
explicitly configured in Black or White List for that port, AN sends
and Admission Request message to the NAS only if that flow is the
first multicast flow of a given Flow Group. The Admission Request
also contains a Flow-Group Id. NAS replies with an Admission Response
indicating that the decision is valid for the whole Flow-Group
instead of just for a single Flow. Successive Join messages for Flows
belonging to the same Flow Group do not require Admission Control
check from AN to NAS, thus AN can autonomously decide to start
replicating the requested multicast Flow.
After receiving a Leave message AN waits for a predefined time-out
before sending the Admission Release Message to the NAS, in order to
see if the end user sends a Join Message for another Flow belonging
to the same Multicast Flow Group.
The Messages involved in the following flow are:
o Admission Request (Flow id, Flow Group Id, Port Id)
o Admission Response (Flow Group Id)
o Admission Release (Flow Group Id, Port Id)
Maglione Expires December 29, 2007 [Page 23]
Internet-Draft ANCP Multicast Handling June 2007
+-----+ +-----+ +-----+ANCP +-----+ +------+ +------+
| CPE | | RG | | AN |<--->| NAS | |Policy| |Radius|
+-----+ +-----+ +-----+ +-----+ +------+ +------+
| | | | | |
| Join(Fl 1) | Admission | | |
|-----------+---------->|Request(Fl1,| | |
| | |FG1,Port_Id)| | |
| | |----------->| | |
| | | | | |
| | | Admission | | |
| | |Response(FG1| | |
| | | | | |
| Mcast-Flow Fl1 |<-----------| | |
|<----------+-----------| | | |
| | | | | |
| | | | | |
| Leave(Fl 1) | | | |
|-----------+---------->| | | |
| | | | | |
| Join(Fl 2) | | | |
|-----------+---------->| | | |
| Mcast-Flow 2 | | | |
| | | | | |
|<----------+-----------| | | |
| Leave(Fl 2) | | | |
|-----------+---------->| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | |Reservation | | |
| | |Release(FG1)| | |
| | |----------->| | |
| | | | | |
| | | | | |
| | | | | |
Figure 8 Multicast Flow-Group with NAS decision, without accounting,
without Policy Server Synchronization
Maglione Expires December 29, 2007 [Page 24]
Internet-Draft ANCP Multicast Handling June 2007
5.3.2. Multicast Flow-Group with NAS decision, with accounting,
with Policy Server Synchronization
This scenario adds to the one described in 5.3.1. the accounting
capability and the Policy Server interaction. The logic in same as
the one described for Multicast Flow scenario with NAS decision,
accounting and Policy Server Synchronization, but the Admission
Response is valid for all Flows belonging to the authorized Multicast
Flow-Group.
Maglione Expires December 29, 2007 [Page 25]
Internet-Draft ANCP Multicast Handling June 2007
+-----+ +-----+ +-----+ANCP +-----+ +------+ +------+
| CPE | | RG | | AN |<--->| NAS | |Policy| |Radius|
+-----+ +-----+ +-----+ +-----+ +------+ +------+
| | | | | |
| Join(Fl 1) | Admission | | |
|-----------+-- ------->|Request(Fl1,| | |
| | |FG1,Port_Id)| | |
| | |----------->|Qos Request| |
| | | |---------->| |
| | | Admission | Qos Reply | |
| | |Response(FG1|<----------| |
| Mcast-Flow Fl1 |<-----------| | |
|<----------+-----------|Replication | | |
| | |Start(PortId| | |
| | | ,Fl1)| | |
| | |----------->| Start Accounting |
| | | | (Port_Id,Fl 1) |
| Leave(Fl 1) |Replication |-----------+----------->|
|-----------+---------->|Stop(PortId,| | |
| | | ,Fl 1)| | |
| Join(Fl 2) |----------->| Stop Accounting |
| | | | (Port_Id,Fl 1) |
|-----------+---------->|Replication |-----------+----------->|
| Mcast-Flow Fl2 |Start(PortId| | |
| | | ,Fl 2)| | |
|<----------+-----------|----------->| Start Accounting |
| | | | (Port_Id,Fl 2) |
| Leave(Fl 2) |Replication |-----------+----------->|
|-----------+---------->|Stop(Portid,| | |
| | | Fl 2)| | |
| | |----------->| Stop Accounting |
| | | | (Port_Id,Fl 2) |
| | | |-----------+----------->|
| | | | | |
| | | Admission | | |
| | |Release(FG1)| | |
| | |----------->|Qos Release| |
| | | |---------->| |
| | | | | |
| | | | | |
Maglione Expires December 29, 2007 [Page 26]
Internet-Draft ANCP Multicast Handling June 2007
Figure 9 Multicast Flow-Group with NAS decision, with accounting,
with Policy Server Synchronization
6. Security Considerations
Security of the ANCP protocol is discussed in [7].
With Multicast handling as described in this document, ANCP protocol
activity between the AN and the NAS is triggered by join/leave
requests coming from the end-user equipment. This could potentially
be used for denial of service attack against the AN and/or the NAS.
This is not a new class of risk over already possible IGMP messages
send from subscribers to the NAS when the AN uses no IGMP snooping
transparent as long as processing of ANCP messages on the NAS/AN is
comparable efficient and protected against congestion.
To mitigate this risk, the AN MAY implement control plane protection
mechanisms such as limiting the number of multicast flows a given
user can simultaneously join, or limiting the maximum rate of
join/leave from a given user.
We also observe that an operator can easily deploy some protection
against attacks using invalid multicast flows by taking advantage of
the mask-based match in the Black List. This way, join for invalid
multicast flows can be denied at the AN level without any ANCP
protocol interactions and without NAS involvement.
7. IANA Considerations
The ANCP protocol extensions necessary to address the ANCP
requirements identified in this document are likely to result in
requests to IANA. Those will be identified in [2] if, and when, the
corresponding protocol extensions are incorporated in [2].
8. Acknowledgments
The authors would like to thank Wojciech Dec for his valuable
comments.
Maglione Expires December 29, 2007 [Page 27]
Internet-Draft ANCP Multicast Handling June 2007
This document was prepared using 2-Word-v2.0.template.dot.
Maglione Expires December 29, 2007 [Page 28]
Internet-Draft ANCP Multicast Handling June 2007
9. References
9.1. Normative References
[1] S. Ooghe, S. Wadhwa .. "Framework and Requirements for an
Access Node Control Mechanism in Broadband Multi-Service
Networks", draft-ietf-ancp-framework-01.txt
[2] S. Wadhwa, J. Moisand, .. " Protocol for Access Node Control
Mechanism in Broadband Networks", draft-ietf-ancp-protocol-
00.txt
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, "
Internet Group Management Protocol, Version 3", RFC 3376,
October 2002.
[5] H. Holbrook, B. Cain, B. Haberman, "Using Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast Listener
Discovery Protocol Version 2 (MLDv2) for Source-Specific
Multicast", RFC 4604, August 2006
[6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006
[7] H. Moustafa, H. Tschofenig, S. De Cnodder, "Security Threats
and Security Requirements for the Acces Node Control Protocol
(ANCP)", draft-ietf-ancp-security-threats-01.txt
Author's Addresses
Roberta Maglione
Telecom Italia
Via Reiss Romoli 274
10148 Torino - Italy
Phone: +39 011 2285007
Email: roberta.maglione@telecomitalia.it
Maglione Expires December 29, 2007 [Page 29]
Internet-Draft ANCP Multicast Handling June 2007
Angelo Garofalo
Telecom Italia
Via Reiss Romoli 274
10148 Torino - Italy
Phone: +39 011 2287211
Email: angelo.garofalo@telecomitalia.it
Francois Le Faucheur
cisco Systems
Domaine Green Side, 400 Avenue de Roumanille
Biot, Sophia Antipolis 06410
France
Phone:
EMail: flefauch@cisco.com
Toerless Eckert
cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Phone:
EMail: eckert@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
Maglione Expires December 29, 2007 [Page 30]
Internet-Draft ANCP Multicast Handling June 2007
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Maglione Expires December 29, 2007 [Page 31]