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. ) 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. o a mask-based range match for a (*,G) ASM group (e.g. ) o a mask-based range match for a (S,G) SSM channel (e.g. 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]