ANCP R. Maglione Internet-Draft A. Garofalo Intended status: Standards Track Telecom Italia Expires: January 12, 2009 F. Le Faucheur T. Eckert Cisco T. Taylor Huawei July 11, 2008 ANCP Multicast Handling Sessions draft-maglione-ancp-mcast-01.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 January 12, 2009. Maglione, et al. Expires January 12, 2009 [Page 1] Internet-Draft ANCP Multicast Handling July 2008 Abstract This memorandum aims at presenting ANCP Multicast handling. It proposes updated description of the Multicast Use cases and corresponding updated ANCP requirements. It also presents the corresponding Message Flows. Maglione, et al. Expires January 12, 2009 [Page 2] Internet-Draft ANCP Multicast Handling July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 8 3.1. Conditional Access . . . . . . . . . . . . . . . . . . . . 8 3.2. Multicast Admission Control . . . . . . . . . . . . . . . 9 3.2.1. When not to perform Admission Control for a subset of flows . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. Multicast Admission Control and White Lists . . . . . 12 3.3. Multicast Accounting and Reporting . . . . . . . . . . . . 12 3.4. Spontaneous Admission Response . . . . . . . . . . . . . . 12 4. Multicast Protocol Requirements . . . . . . . . . . . . . . . 13 4.1. ANCP Multicast Requirements . . . . . . . . . . . . . . . 13 4.2. ANCP Access Node Multicast Requirements . . . . . . . . . 13 4.3. ANCP NAS Multicast Requirements . . . . . . . . . . . . . 15 5. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Multicast Conditional Access without CAC . . . . . . . . . 17 5.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 17 5.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 18 5.1.3. Join & Leave Operations . . . . . . . . . . . . . . . 18 5.2. Multicast Conditional Access and CAC without AN Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 20 5.2.1. List/Profile Provisioning . . . . . . . . . . . . . . 20 5.2.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 20 5.2.3. Join & Leave Operations . . . . . . . . . . . . . . . 20 5.3. Multicast Admission Control with AN Bandwidth Delegation . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.1. List/Profile Provisioning . . . . . . . . . . . . . . 21 5.3.2. Profile Mapping and Initial Bandwidth Delegation . . . 22 5.3.3. Join & Leave Operations . . . . . . . . . . . . . . . 23 5.3.4. AN-Triggered Increase of Delegated Multicast Bandwidth . . . . . . . . . . . . . . . . . . . . . . 25 5.3.5. NAS-Triggered Decrease of Delegated Multicast Bandwidth . . . . . . . . . . . . . . . . . . . . . . 26 5.3.6. AN Release of Redundant Multicast Bandwidth . . . . . 26 5.4. Multicast Accounting . . . . . . . . . . . . . . . . . . . 27 5.4.1. List/Profile Provisioning . . . . . . . . . . . . . . 27 5.4.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 28 5.4.3. Join & Leave Operations . . . . . . . . . . . . . . . 28 5.5. Multicast Reporting . . . . . . . . . . . . . . . . . . . 30 5.6. NAS-Controlled Multicast Replication . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . . 35 Maglione, et al. Expires January 12, 2009 [Page 3] Internet-Draft ANCP Multicast Handling July 2008 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 38 Maglione, et al. Expires January 12, 2009 [Page 4] Internet-Draft ANCP Multicast Handling July 2008 1. Introduction [I-D.ietf-ancp-framework] 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. [I-D.ietf-ancp-protocol] specifies a Protocol for Access Node Control Mechanism in Broadband Networks in line with this framework. [I-D.ietf-ancp-framework] defines multicast use cases (in section 3.4) as well as the corresponding ANCP Multicast requirements, ANCP Access Node Multicast Requirements and ANCP NAS Multicast Requirements (respectively in sections 4.2, 4.7.7 and 4.8.6). The multicast use cases addressed are "Conditional Access", "Admission Control", "Accounting and Reporting", and finally "Spontaneous Admission Response". The ANCP requirements associated with the Admission Control use case support a number of models. One such model is where ANCP allows Admission Control to be performed without involvement of the Access Node i.e performed by the NAS (possibly with interactions with a Policy Server). Another model is where Admission Control is to be performed with some involvement of the Access Node i.e. performed by NAS (possibly with interactions with a Policy Server) but this time with some delegation of decision to the Access Node. This memorandum proposes some enhancements to the ANCP operations for the model where some admission control decision is delegated to the Access Node. The key enhancement is to explicitely delegate multicast bandwidth to the Access Node for the purpose of multicast admission control (instead of simply identifying multicast flows that share the same admission control rules and access control rules, as per current version of[I-D.ietf-ancp-framework]). This allows the Access Node to perform admission control without ANCP signaling with the NAS in more situations than the current proposal. With this bandwidth delegation approach the AN manages a delegated multicast bandwidth that is a subset of the total video bandwidth for an AN port. The AN can autonomously perform admission control of multicast flows within this delegated bandwidth. An initial value for the delegated multicast bandwidth can be provisioned on the AN by the NAS through ANCP. The AN and NAS then communicate via ANCP to increase or decrease the delegated multicast bandwidth depending on the relative demand of muticast flows versus unicast flows. The proposed approach for admission control with bandwidth delegation is compatible with all the conditional access methods supported by [I-D.ietf-ancp-framework]. In particular, it allows multicast Maglione, et al. Expires January 12, 2009 [Page 5] Internet-Draft ANCP Multicast Handling July 2008 admission control check to be performed by the AN even when the AN needs to query the NAS for conditional access check. This memorandum identifies all the corresponding changes that would be required to [I-D.ietf-ancp-framework] in order to reflect the proposed multicast admission control enhancement. The corresponding message flows are also documented, in view of clarifying all the proposed multicast ANCP operations and facilitating future specification of the corresponding ANCP protocol extensions. This memorandum does not propose any change to the other model of operations for multicast Admission Control Control, nor to ANCP operations for the other multicast use cases. Maglione, et al. Expires January 12, 2009 [Page 6] Internet-Draft ANCP Multicast Handling July 2008 2. Terminology 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. Maglione, et al. Expires January 12, 2009 [Page 7] Internet-Draft ANCP Multicast Handling July 2008 3. Multicast Use Cases This section describes the ANCP use cases related to Multicast. 3.1. Conditional Access This section discusses the changes proposed to section 3.4.1 of [I-D.ietf-ancp-framework]. [I-D.ietf-ancp-framework] defines the concept of multicast flows that share the same control rules (ie same Conditional Access rules and same Admission Control rules). The objective of this concept was to achieve a tradeoff between pre-provisioning the AN with all Conditional Access and Admission Control information and querying the NAS on a per join basis. The former may be a configuration burden and may lead in large delays when the NAS or AN restarts, while the latter may increase channel join and channel change times because of the additional message processing involved in the AN, the NAS and potentially the Policy Server. Now considering that o this memorandum proposes (in Section 3.2) the extension of the concept of multicast flows that share the same Admission Control rules into an approach of bandwidth delegation from NAS to the AN whereby channels of equivalent bandwidth no longer need to be provisioned into the AN by the NAS o grey lists in case of the Conditional Access scenario are mainly used in order to be able to have the conditional access decision taken by the NAS or a Policy Server (especially in order to address the case when conditional access information changes frequently, or when the multicast groups are not known to a client application in advance, thus where it may not be possible or convenient to pre-provisioning AN with conditional access information) we propose to simplify operations of Conditional Access and remove the notion of multicast flows sharing the same conditional access rules. Specifically, we propose to remove the following two paragraphs of section 3.4.1 [I-D.ietf-ancp-framework]: "Querying the NAS before performing a join on the AN may increase channel join and channel change times because of the additional message processing involved in the AN, the NAS and potentially the Policy Server. On the other hand, pre-provisioning per subscriber profiles potentially different for each subscriber may be a configuration burden, may result in large delays when the NAS or AN Maglione, et al. Expires January 12, 2009 [Page 8] Internet-Draft ANCP Multicast Handling July 2008 restarts, or may not be viable when conditional access changes frequently or are to remain under the control of an external administrative entity. In order to account for these operational factors and associated trade-offs, in some cases, the provisioning and querying techniques can be combined. In such a model, the AN sends an Admission Request message to the NAS as a trigger for a particular multicast flow. The NAS would then send back an Admission Response message to the AN, including conditional access information for that multicast flow, as well as for a set of multicast flows sharing the same conditional access rules. The AN can then autonomously honor or deny requests for a given user/port for the set of Multicast flows as indicated in the Admission Response message." 3.2. Multicast Admission Control Section 3.4.2 of [I-D.ietf-ancp-framework] presents the requirement for synchronization between the entity performing multicast CAC, the entity performing unicast CAC and the entity actually enforcing multicast replication. It describes three approaches to perform this synchronization. This memorandum proposes the following changes to the methods described in the first and in the third bullet. Replace the following text: " One approach is for the AN to query the NAS so that both unicast and multicast CAC for the access line are performed by the NAS. In this case, the AN can use ANCP to query the NAS, that in turn performs multicast CAC and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. The NAS may locally maintain available "video" bandwidth on the Access Loop, and perform video bandwidth accounting for the Access Loop. Upon receiving an Admission Request from the AN, the NAS can check available "video" bandwidth before admitting or denying the multicast flow. In the process, the NAS may communicate with the Policy Server. For unicast video services such as Video on Demand (VoD), the NAS may also be queried (by a Policy Server or via on-path CAC signaling), so that it can perform admission control for the unicast flow, and update the available video bandwidth maintained by the NAS. Similarly to what has been discussed in the Conditional Access use case, in response to a Admission Request from the AN for admission control of a multicast flow, the NAS may send back an Admission Response message to the AN, including admission control information for that multicast flow, as well as for a set of multicast flows sharing the same admission control rules. The AN can then autonomously honor or deny requests for a given user/port for the set of Multicast flows as indicated in the Admission Response Maglione, et al. Expires January 12, 2009 [Page 9] Internet-Draft ANCP Multicast Handling July 2008 message. The ANCP requirements to support this approach (where the AN queries the NAS) are specified in this document;" by the following text: "One approach is where ANCP allows Admission Control to be performed by the NAS (possibly with interactions with a Policy Server) either without any involvement of the Access Node or with some involvement of the Access Node in particular with the delegation of some decisions to the Access Node. The NAS uses ANCP to indicate to the AN whether or not Admission Control is needed for each multicast flow on a given Access Port, and where Admission Control is needed whether or not it is to be performed with AN Bandwidth Delegation. In particular: o multicast flows that require Admission Control without AN Bandwidth Delegation are inserted in the Grey List and these entries are flagged as "no Bandwidth Delegation"; o multicast flows that require Admission Control with AN Bandwidth Delegation are: o * inserted in the White list and flagged as "Bandwidth Delegation", in case they do not require any Conditional Access operation to be performed by the NAS * inserted in the Grey List and flagged as "Bandwidth Delegation", in case they require some Conditional Access checks to be performed by the NAS. In case of Admission Control without AN Bandwidth Delegation, the AN can use ANCP to query the NAS, that in turn performs multicast Admission Control check for the new multicast flow and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. The NAS may locally maintain available "video" bandwidth on the Access Loop, and perform video bandwidth accounting for the Access Loop. Upon receiving an Admission Request from the AN, the NAS can check available "video" bandwidth before admitting or denying the multicast flow. In the process, the NAS may communicate with the Policy Server. For unicast video services such as Video on Demand (VoD), the NAS may also be queried (by a Policy Server or via on-path CAC signaling), so that it can perform admission control for the unicast flow, and update the available video bandwidth maintained by the NAS. Maglione, et al. Expires January 12, 2009 [Page 10] Internet-Draft ANCP Multicast Handling July 2008 In case of Admission Control with AN Bandwidth Delegation, the NAS (possibly with interactions with a Policy Server) manages total bandwidth for video admission, performs unicast admission control and uses ANCP to delegate a certain amount of bandwidth for some multicast flows to the Access Node. In this scenario upon receiving a join to a multicast flow which matches the White or Grey Lists whose entry is flagged as "Bandwidth Delegation" for a specific Access Port, before starting the multicast flow replication the AN must perform the necessary bandwidth admission control check for the new multicast flow. In some cases, the bandwidth that the NAS initially delegated to the AN may not be enough to satisfy a multicast request for a new flow. In this scenario the AN can use ANCP to query the NAS in order to request additional multicast bandwidth; the NAS (possibly with interactions with a Policy Server) decides if the request for more bandwidth can be satisfied and uses ANCP to send a response to the AN indicating the updated delegated multicast bandwidth. It is worth noticing that in this case, the time taken to complete the procedure is an increment to the zapping delay: in order to minimize the zapping delay for future join requests the AN can insert in the request message two values: the minimum amount of additional multicast bandwidth requested, and the preferred additional amount. The first value is the amount that allows the present join request to be satisfied, the second value an amount that anticipates further join requests. In some cases, the NAS (or the Policy Server) may not have enough unicast bandwidth to satisfy a new incoming video request: in these scenarios the NAS can use ANCP to query (or instruct) the AN in order to decrease the amount of multicast bandwidth previously delegated on a given Access Port. The AN upon receiving this query from the NAS can use ANCP to send a response to AN indicating the updated delegated multicast bandwidth. Actually, based on considerations similar to those of the previous paragraph, it indicates the minimum amount of multicast bandwidth that it needs released and a preferred amount, which may be larger. In addition in some cases upon receiving a leave for a specific multicast flow the AN can decides that it has an excess of delegated but uncommitted bandwidth, thus the AN can use ANCP to send a message to the NAS to release unused multicast bandwdth previously delegated. The ANCP requirements to support this approach (where the AN queries the NAS) are specified in this document; " Replace this text: Maglione, et al. Expires January 12, 2009 [Page 11] Internet-Draft ANCP Multicast Handling July 2008 " In a third approach, the Policy Server queries the AN (either directly, or indirectly via the NAS) so that both unicast and multicast CAC for the access line are performed by the AN. In this case, a subscriber request for a unicast flow (e.g. a Video on Demand session) will trigger a resource request message towards a Policy Server; the latter will then query the AN, that in turn will perform unicast CAC for the access line and respond, indicating whether the unicast request is to be honored or denied. This method will not be addressed in this document; it may be covered by means of ANCP extensions at a later stage. " by the following text: "In a third approach, the Policy Server queries the AN directly so that both unicast and multicast CAC for the access line are performed by the AN. In this case, a subscriber request for a unicast flow (e.g. a Video on Demand session) will trigger a resource request message towards a Policy Server; the latter will then query the AN, that in turn will perform unicast CAC for the access line and respond, indicating whether the unicast request is to be honored or denied. In this scenario the Policy Server queries the AN directly, the approach doesn't require the use of ANCP. It is therefore beyond the scope of this document." 3.2.1. When not to perform Admission Control for a subset of flows This memorandum does not propose any update over the description of this use case provided in section 3.4.2.1 of [I-D.ietf-ancp-framework]. 3.2.2. Multicast Admission Control and White Lists This memorandum does not propose any update over the description of this use case provided in section 3.4.2.2 of [I-D.ietf-ancp-framework]. 3.3. Multicast Accounting and Reporting This memorandum does not propose any update over the description of this use case provided in section 3.4.3 of [I-D.ietf-ancp-framework]. 3.4. Spontaneous Admission Response This memorandum does not propose any update over the description of this use case provided in section 3.4.4 of [I-D.ietf-ancp-framework]. Maglione, et al. Expires January 12, 2009 [Page 12] Internet-Draft ANCP Multicast Handling July 2008 4. Multicast Protocol Requirements 4.1. ANCP Multicast Requirements This memorandum proposes the following changes to section 4.2 of [I-D.ietf-ancp-framework]. Replace the following requirement: o The ANCP must allow the NAS, when replying to an AN request, to convey information on multiple multicast flows sharing the same conditional access and/or admission control rules. This allows the AN to take autonomous decisions for these flows later on. by the following requirements: o The ANCP must allow the NAS to indicate to the AN whether or not Admission Control is needed for some multicast flows on a given Access Port and where needed whether or not it is to be performed with AN Bandwidth Delegation. o In case of Admission Control without AN Bandwidth Delegation the ANCP must allow the NAS to reply to a query from the AN indicating whether or not a multicast flow may be replicated to a particular Access Port. o In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the NAS to delegate a certain amount of bandwidth to the AN for a given Access Port. o In case of Admission Control with AN Bandwidth Delegation the ANCP must allow the AN to query the NAS to request additional multicast bandwidth on a given Access Port. o In case of Admission Control with AN Bandwidth Delegation the ANCP must allow the NAS to query (or to instruct) the AN to reduce the amount of bandwidth previously delegated on a given Access Port. o In case of Admission Control with AN Bandwidth Delegation the ANCP must allow the AN to autonomous release redundant multicast bandwidth on a given Access Port. 4.2. ANCP Access Node Multicast Requirements This memorandum proposes the following changes to section 4.7.6 of [I-D.ietf-ancp-framework]. Replace the following requirements: Maglione, et al. Expires January 12, 2009 [Page 13] Internet-Draft ANCP Multicast Handling July 2008 o The AN must accept any join to a multicast flow matching the White List for the relevant Access Port. o Upon receiving a join to a multicast flow which matches the Grey List for a specific Access Port, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied. o Upon querying the NAS, the AN should support receiving ANCP messages from the NAS containing conditional access and/or admission control information of multiple multicast flows. This allows the AN to take autonomous decisions for these flows later on. o The AN should support using ANCP to notify the NAS when resources for a multicast flow are no longer in use (e.g. the AN is no longer replicating any multicast flows from a set of multicast flows sharing the same admission control rules). This allows corresponding bandwidth to be released on NAS. by the following requirements: o The AN must accept any join to a multicast flow matching the White List and flagged as "no CAC" for the relevant Access Port. o Upon receiving a join to a multicast flow which matches the White List whose entry is flagged as "Bandwidth Delegation" for a specific Access Port, before starting the multicast flow replication the AN must perform the necessary bandwidth admission control check for the new flow. o Upon receiving a join to a multicast flow which matches the Grey List whose entry is flagged as "no Bandwidth Delegation" for a specific Access Port, the AN must support using ANCP to query the NAS that in turn will perform both the necessary conditional access and the admission control checks for the new flow and sends a response indicating whether that join is to be honored or denied. The AN must support using ANCP to notify the NAS when the the user leaves the multicast flow. o Upon receiving a join to a multicast flow which matches the Grey List whose entry is flagged as "Bandwidth Delegation" for a specific Access Port, the AN must perform the necessary bandwidth admission control check for the new flow and if it is successful the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied. Maglione, et al. Expires January 12, 2009 [Page 14] Internet-Draft ANCP Multicast Handling July 2008 o In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to query the NAS to request additional delegated multicast bandwidth on a given Access Port; the AN should be able to specify both the minimum and the preferred amount of additional multicast bandwidth requested. o In case of Admission Control with AN Bandwidth Delegation, upon receiving a Bandwidth Delegation Request from the NAS querying or instructing to decrease the delegated multicast bandwidth on a given Access Port, the AN must support using ANCP to send a Bandwidth Delegation Response indicating the new delegating multicast bandwidth o In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to send a Bandwidth Release message to the NAS in order to release unused delegated multicast bandwidth on a given Access Port. 4.3. ANCP NAS Multicast Requirements This memorandum proposes the following changes to section 4.8.6 of [I-D.ietf-ancp-framework]. Replace the following requirements: o The NAS must support using ANCP to configure multicast conditional access information to Access Ports on an Access Node, using Black Lists and White Lists o Upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port, the NAS must support using ANCP to reply to the AN indicating whether the request is to be honored or denied. o Upon receiving a query from the AN for a request to replicate multicast flow to a particular Access Port, the NAS should support sending an Admission Response message containing conditional access and/or admission control information of multiple multicast flows. This allows the AN to take autonomous decisions for these flows later on by the following requirements: o The NAS must support using ANCP to configure multicast conditional access information to Access Ports on an Access Node, using Black Lists, Grey Lists and White Lists. Maglione, et al. Expires January 12, 2009 [Page 15] Internet-Draft ANCP Multicast Handling July 2008 o The NAS must support using ANCP to indicate to the AN whether or not Admission Control is needed for some multicast flows on a given Access Port and where needed whether or not it is to be performed with AN Bandwidth Delegation. o Upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port and where Admission Control is not needed for that multicast flow on that Access Port, the NAS must be able to perform the necessary conditional access check for the new flow and the NAS must support using ANCP to reply to the AN indicating whether the request is to be honored or denied. o Upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port and where Admission Control without AN Bandwidth Delegation is needed for that multicast flow on that Access Port, the NAS must be able to perform both the necessary conditional access (if needed) and the bandwidth admission control check for the new flow and the NAS must support using ANCP to reply to the AN indicating whether the request is to be honored or denied. o In case of Admission Control with AN Bandwidth Delegation the NAS must support using ANCP to delegate a certain amount of bandwidth to the AN for a given Access Port. o In case of Admission Control with AN Bandwidth Delegation, upon receiving a Bandwidth Delegation Request from the AN requesting to increase the delegated multicast bandwidth on a given Access Port, the NAS must support using ANCP to send a Bandwidth Delegation Response indicating the new delegating multicast bandwidth. o In case of Admission Control with AN Bandwidth Delegation, the NAS must support using ANCP to send a request the AN to decrease the amount of multicast bandwidth previously delegated on a given Access Port; the NAS should be able to specify both the minimum and the preferred amount decrement of multicast bandwidth requested. o In case of Admission Control with AN Bandwidth Delegation, upon receiving an ANCP Bandwidth Release message, the NAS must be able to update accordingly its view of the multicast bandwidth delegated to the AN. Maglione, et al. Expires January 12, 2009 [Page 16] Internet-Draft ANCP Multicast Handling July 2008 5. Message Flows This section documents the message flows associated with multicast handling by ANCP. It is not proposed that these message flows be incorporated in [I-D.ietf-ancp-framework] since message flows are outside its scope. These messages flows are intended to clarify operation of the ANCP Multicast and provide guidance for the specification of ANCP Protocol extensions for support of multicast. 5.1. Multicast Conditional Access without CAC This section describes ANCP operations when multicast flows are subject to multicast Conditional Access but not subject to CAC. 5.1.1. List/Profile Provisioning The AN provisioning is performed by NAS using a Provisioning message that contains White/Black/Grey lists and their corresponding "Multicast Profile ID". To indicate to the AN that it need not perform any CAC operation on those flows, the White List entries are flagged as "no CAC" and the Grey List entries are flagged as "no Bandwidth Delegation". The corresponding message flow is illustrated in Figure 1. Although Figure 1 shows the three lists in the ANCP provisioning message, the message may instead contain any subset of 2 or 1 list. +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | | Provisioning( | | | | (White List(noCAC), | | | | Grey List(noBD), | | | | Black List, | | | | Profile_ID) | | | |<--------------------| (noCAC): entries in the White List flagged as "no CAC" (noBD) : entries in the Grey List flagged as "no Bandwidth Delegation" Figure 1: Provisioning AN with White/Grey/Black Lists for Conditional Access Maglione, et al. Expires January 12, 2009 [Page 17] Internet-Draft ANCP Multicast Handling July 2008 5.1.2. Profile Mapping As soon as the AN port comes up, the AN sends an ANCP PORT_UP message to the NAS specifying the Access Loop Circuit ID. The NAS replies with an ANCP PORT_MNGT message that, together with the other parameters, includes the Multicast Profile ID to be associated to that Port. The corresponding message flow is illustrated in Figure 2. +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | | | | | DSL Synch. | | | |--------------------->| | | | | PORT_UP(Port ID) | | | |-------------------->| | | | (*) | | | PORT_MNGT(Port ID, | | | | Profile_ID) | | | |<--------------------| (*) The NAS may optionnaly communicate with an external Autorization/Policy Server Figure 2: Associating Profile ID to AN Port 5.1.3. Join & Leave Operations The message flows in Figure 3 illustrates the behavior of the AN in case of receiving a join and leave messages on the Access Port for multicast flows respectively part of: o white list (with matching entry flagged as "no CAC") o black list o grey list (with matching entry flagged as "no Bandwidth Delegation") Maglione, et al. Expires January 12, 2009 [Page 18] Internet-Draft ANCP Multicast Handling July 2008 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | | | | | Join(WhiteNoCAC-Fl) | | |------------+--------->| | | | | | | Mcast White Flow | | |<======================+ | | | | | | | | | | Leave(WhiteNoCAC-Fl) | | |------------+--------->| | | | | | | Join(Black-Fl) | | |-----------+---------->x | | | | | | | | | | | | | | | | Join(GreyNoBD-Fl) | Admission | |-----------+---------->| Request | | | |------------------>| | | | Admission (*) | | | Response | | Mcast Grey Flow |<------------------| |<======================+ | | | | | | | | | Leave(GreyNoBD-Fl) | Admission | |-----------+---------->| Release | | | |------------------>| | | | | WhiteNoCAC-Fl : Multicast Flow matching an entry in White List flagged as "No CAC" GreyNoBD-Fl : Multicast Flow matching an entry in Grey List flagged as "No Bandwidth Delegation" (*) The NAS may optionnaly communicate with an external Autorization/Policy Server Figure 3: Multicast Conditional Access Maglione, et al. Expires January 12, 2009 [Page 19] Internet-Draft ANCP Multicast Handling July 2008 5.2. Multicast Conditional Access and CAC without AN Bandwidth Delegation This section describes ANCP operations when multicast flows are subject to multicast Conditional Access and subject to CAC on NAS without bandwidth delegation on the Access Node. 5.2.1. List/Profile Provisioning The AN provisioning is performed by NAS using a Provisioning message that contains Black/Grey lists and their corresponding "Multicast Profile ID". To indicate to the AN that it need not perform any CAC operation on those flows, the Grey List entries are flagged as "no Bandwidth Delegation". The corresponding message flow is illustrated in Figure 4. +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | | Provisioning( | | | | (Grey List(noBD), | | | | Black List, | | | | Profile_ID) | | | |<--------------------| (noBD) : entries in the Grey List flagged as "no Bandwidth Delegation" Figure 4: Provisioning AN with Grey/Black Lists for Conditional Access and CAC without Bandwidth Delegation 5.2.2. Profile Mapping The "Profile ID" is associated to the port when the DSL line comes up in the exact same way as illustrated in Figure 2. 5.2.3. Join & Leave Operations Upon receiving a join request for a multicast flow in a Grey List whose entry is flagged as "No Bandwidth Delegation", the AN uses ANCP to query the NAS, that in turn will perform the necessary conditional access check and bandwidth admission control check for the new flow and then it will respond to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied (and hence replication not performed by the AN). This is illustrated in Figure 5. Maglione, et al. Expires January 12, 2009 [Page 20] Internet-Draft ANCP Multicast Handling July 2008 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | | | | | Join(Black-Fl) | | |-----------+---------->x | | | | | | | | | | | | Join(GreyNoBD-Fl) | Admission | |-----------+---------->| Request | | | |------------------>| | | | (*) | | | Admission | | | | Response | | Mcast-Flow |<------------------| |<======================+ | | | | | | | | | | Leave(GreyNoBD-Fl) | Admission | |-----------+---------->| Release | | | |------------------>| (*) The NAS may optionnaly communicate with an external Autorization/Policy Server Figure 5: Multicast Admission Control without AN Bandwidth Delegation 5.3. Multicast Admission Control with AN Bandwidth Delegation This section describes ANCP operations when multicast flows are subject to multicast Conditional Access and subject to CAC on NAS with bandwidth delegation on the Access Node. 5.3.1. List/Profile Provisioning The AN provisioning is performed by NAS using a Provisioning message that contains White/Black/Grey lists and their corresponding "Multicast Profile ID". To indicate to the AN that it need perform CAC in compliance with Bandwidth Delegation on those flows, the White List entries and Grey List Entries are flagged as "Bandwidth Delegation". The corresponding message flow is illustrated in Figure 1. Although Figure 6 shows the three lists in the ANCP provisioning message, the message may instead contain any subset of 2 or 1 list. Maglione, et al. Expires January 12, 2009 [Page 21] Internet-Draft ANCP Multicast Handling July 2008 The AN is configured by other means with the multicast bandwidth required for each multicast flow. +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | | Provisioning( | | | | (White List(BD), | | | | Grey List(BD), | | | | Black List, | | | | Profile_ID) | | | |<--------------------| (BD): entries in the White/Grey List flagged as "Bandwidth Delegation" Figure 6: Provisioning AN with White/Grey/Black Lists for Conditional Access 5.3.2. Profile Mapping and Initial Bandwidth Delegation The "Profile ID" is associated to the port when the DSL line comes up in the same way as illustrated in Figure 2. In addition, the NAS passes to the AN the total video bandwidth (unicast plus multicast) associated to the AN port and the initial AN allocation of multicast bandwidth for the port. The message flow combining these two steps is illustrated in Figure 7. Maglione, et al. Expires January 12, 2009 [Page 22] Internet-Draft ANCP Multicast Handling July 2008 +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | | | | | DSL Synch. | | | |--------------------->| | | | | PORT_UP(Port ID) | | | |-------------------->| | | | (*) | | | PORT_MNGT(Port ID, | | | | Profile_ID, | | | | Total Video bw, | | | | Delegated multicast | | | | Bandwidth) | | | |<--------------------| | | | | | | | Response | | | |-------------------->| | | | | | | | (*) | | | | (*) The NAS may optionnaly communicate with an external Policy Server Figure 7: Multicast Admission Control with AN Bandwidth Delegation 5.3.3. Join & Leave Operations Upon receiving a join request for a multicast flow in a Grey List whose entry is flagged as "Bandwidth Delegation", the AN performs admission control of the flow in accordance with Bandwidth Delegation and uses ANCP to query the NAS that in turn will perform the necessary conditional access check for the new flow. The NAS will respond to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied (and hence replication not performed by the AN). This is illustrated in Figure 8. In the case where the NAS reponses indicates that the replication is not to be honored, the AN will reflect this in his Bandwidth Delegation operation (ie release corresponding bandwidth within the delegated bandwidth). Maglione, et al. Expires January 12, 2009 [Page 23] Internet-Draft ANCP Multicast Handling July 2008 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | Join(WhiteBD-Fl) | | |-----------+---------->| | | | | | | Mcast-Flow | | |<======================| | | | | | | Leave(WhiteBD-Fl) | | |-----------+---------->| | | | | | | | | | | | | | | JOIN(Black-Fl) | | |-----------+---------->| | | | | | | | | | | | | Join(GreyBD-Fl) | Admission | |-----------+---------->| Request | | | |------------------>| | | | (*) | | | Admission | | | | Response | | Mcast-Flow |<------------------| |<======================| | | | | | | Leave(GreyBD-FL) | Admission | |-----------+---------->| Release | | | |------------------>| WhiteBD-Fl : Multicast Flow matching an entry in White List flagged as "Bandwidth Delegation" GreyBD-Fl : Multicast Flow matching an entry in Grey List flagged as "Bandwidth Delegation" (*) The NAS may optionnaly communicate with an external Autorization/Policy Server Figure 8: Multicast Admission Control with AN Bandwidth Delegation Maglione, et al. Expires January 12, 2009 [Page 24] Internet-Draft ANCP Multicast Handling July 2008 5.3.4. AN-Triggered Increase of Delegated Multicast Bandwidth +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | Join(WhiteBD-Fl1) | | |-----------+---------->| | | | | | | Mcast-Flow | | |<======================| | | | | | | Leave(Flow) | | |-----------+---------->| | | | | | | | | | | Join(WhiteBD-Fl2) | Band Delegation | |-----------+---------->| Request | | | | (min increment, | | | |(pref increment) | | | |------------------>| | | | (*) | | | Band Delegation | | | | Response | | | | (delegated | | | | multicast bw) | | Mcast-Flow |<------------------| |<======================| | | | | | | Leave(Flow) | | |-----------+---------->| | | | | | WhiteBD-Fl1 : Multicast Flow matching an entry in White List flagged as "Bandwidth Delegation" WhiteBD-Fl2 : Multicast Flow matching an entry in White List flagged as "Bandwidth Delegation" WhiteBD-Fl2 requires more bandwidth than currently remaining available from the multicast delegated bandwidth (*) The NAS may optionnaly communicate with an external Autorization/Policy Server Figure 9: Requesting More Multicast Bandwidth Maglione, et al. Expires January 12, 2009 [Page 25] Internet-Draft ANCP Multicast Handling July 2008 5.3.5. NAS-Triggered Decrease of Delegated Multicast Bandwidth +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | | | (*) | | | | | | | Band Delegation | | | | Request | | | | (min increment, | | | |(pref increment) | | | |<------------------| | | | | | | | Band Delegation | | | | Response | | | | (delegated | | | | multicast bw) | | | |------------------>| | | | | | | | (*) | | | | (*) The NAS may optionnaly communicate with an external Autorization/Policy Server Figure 10: Requesting More Unicast Bandwidth 5.3.6. AN Release of Redundant Multicast Bandwidth Maglione, et al. Expires January 12, 2009 [Page 26] Internet-Draft ANCP Multicast Handling July 2008 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<-------------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | Leave(WhiteBD-Fl) | | |----------------------->| Band Release | | | | (allocated multicast| | | | bandwidth) | | | |--------------------->| (*) WhiteBD-Fl : Multicast Flow matching an entry in White List flagged as "Bandwidth Delegation" (*) The NAS may optionnaly communicate with an external Autorization/Policy Server Figure 11: AN Autonomous Release of Multicast Bandwidth 5.4. Multicast Accounting The NAS specifies if accounting is needed for a particular multicast flow: for Multicast flows belonging to the Grey list this can be conveyed in the ANCP Admission Response message sent from NAS to AN. For Multicast flows whose replication is controlled by the AN via the White list, the AN starts the multicast replication without querying the NAS and thus the NAS does not send Admission Response message; in this case the need for accounting is conveyed by the NAS in the White list during the White list provisioning phase. 5.4.1. List/Profile Provisioning The AN provisioning is performed by NAS using a Provisioning message that contains White/Black/Grey lists and their corresponding "Multicast Profile ID". To indicate to the AN that it need perform Accounting on those flows, the White List entries are flagged as either "Basic Accounting" or "Detailed Accounting". The corresponding message flow is illustrated in Figure 12. Although Figure 6 shows the three lists in the ANCP provisioning message, the message may instead contain any subset of 2 or 1 list. Maglione, et al. Expires January 12, 2009 [Page 27] Internet-Draft ANCP Multicast Handling July 2008 +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | | Provisioning( | | | |(White List (Accounting), | | | | Grey List, | | | | Black List, | | | | Profile_ID) | | | |<-------------------------| | | | | (Accounting): entries in the White List flagged as "Basic Accounting" or "Detailed Accounting" Figure 12: Provisioning AN with White/Grey/Black Lists for Accounting 5.4.2. Profile Mapping The "Profile ID" is associated to the port when the DSL line comes up in the exact same way as illustrated in Figure 2. 5.4.3. Join & Leave Operations The message flows in Figure 13 illustrates the behavior of the AN in case of receiving a join and leave messages on the Access Port for multicast flows respectively part of: o white list (with matching entry flagged as "Basic Accounting" or "Detailed Accouting") o black list o grey list Maglione, et al. Expires January 12, 2009 [Page 28] Internet-Draft ANCP Multicast Handling July 2008 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | | | | | Join(WhiteAcct-Fl) | | |------------+----------->| | | | | | | Mcast White Flow | | |<========================+ Replication Start | | | |------------------->| | | | | | | | | | | | | | Leave(WhiteAcct-Fl) | | |------------+----------->| Information Report | | | |------------------->| | | | | | Join(Black-Fl) | | |------------+----------->x | | | | | | | | | | | | | | | | Join(Grey-Fl) | Admission | |------------+----------->| Request | | | |------------------->| | | | Admission (*) | | |Response(Accounting)| | Mcast Grey Flow |<-------------------| |<========================+ | | | | | | | Replication Start | | | |------------------->| | Leave(Grey-Fl) | | |------------+----------->| Information Report | | | |------------------->| | | | | WhiteAcct-Fl : Multicast Flow matching an entry in White List flagged as "Basic Accouting" Grey-Fl : Multicast Flow matching an entry in Grey List (*) The NAS may optionnaly communicate with an external AAA Server Maglione, et al. Expires January 12, 2009 [Page 29] Internet-Draft ANCP Multicast Handling July 2008 Figure 13: Multicast Accounting 5.5. Multicast Reporting NAS uses "Port Report-Query" to query the AN to know which flows are currently active on a specific port; NAS uses "Multicast Flow Report-Query" to query the AN to know on which ports the specified multicast flow is currently active; NAS uses "AN global Report-Query" to query the AN to know all multicast flows currently active on all AN ports. The message flows in Figure 14 illustrates the behavior of the AN in case of receiving one of three Report Query messages from the NAS. +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | | | Port Report-Query | | | | (Port ID) | | Report (Mcast flows) |<------------------| |------------+----------->| | | | | | | | | | | | | Flow Report-Query | | | | (Mcast Flow) | | Report (Port IDi, |<------------------| | Port IDj,..) | | |------------+----------->| | | | | | | | | | | | |Global-Report-Query| | | | (Port ID) | | | | | |Report (All Mast Flows) |<------------------| |------------+----------->| | Figure 14: Multicast Reporting 5.6. NAS-Controlled Multicast Replication The Replication Control Request Message is sent by the NAS to the AN with a directive to either join or leave one or more multicast flows. The AN will use a Replication Control Response message when conveying Maglione, et al. Expires January 12, 2009 [Page 30] Internet-Draft ANCP Multicast Handling July 2008 the outcome of the directive. The message flows in Figure 15 illustrates the behavior of the AN in case of receiving a Replication Control Request Message. +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<------------>| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | | | Replication-Crl( | | | | Port ID,add Flow1)| | | |<--------------------| | Mcast Flow 1 | | |<==========================+ | | | |Replication-Response | | | | (status) | | | |-------------------->| | | | | | | | | | | | Replication-Crl( | | | |Port ID,delete Flow1)| | | |<--------------------| | | | | | |Replication-Response | | | | (status) | | | |-------------------->| Figure 15: NAS-Controlled Multicast Replication Maglione, et al. Expires January 12, 2009 [Page 31] Internet-Draft ANCP Multicast Handling July 2008 6. Security Considerations Those are addressed in [I-D.ietf-ancp-framework]. Maglione, et al. Expires January 12, 2009 [Page 32] Internet-Draft ANCP Multicast Handling July 2008 7. IANA Considerations Not applicable. Maglione, et al. Expires January 12, 2009 [Page 33] Internet-Draft ANCP Multicast Handling July 2008 8. Acknowledgements The authors would like to thank Wojciech Dec for his valuable comments. Maglione, et al. Expires January 12, 2009 [Page 34] Internet-Draft ANCP Multicast Handling July 2008 9. References 9.1. Normative References [I-D.ietf-ancp-framework] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", draft-ietf-ancp-framework-06 (work in progress), May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002. 9.2. Informative References [I-D.ietf-ancp-protocol] Wadhwa, S., "Protocol for Access Node Control Mechanism in Broadband Networks", draft-ietf-ancp-protocol-02 (work in progress), November 2007. Maglione, et al. Expires January 12, 2009 [Page 35] Internet-Draft ANCP Multicast Handling July 2008 Authors' Addresses Roberta Maglione Telecom Italia Via Reiss Romoli 274 Torino 10148 Italy Phone: Email: roberta.maglione@telecomitalia.it Angelo Garofalo Telecom Italia Via Reiss Romoli 274 Torino 10148 Italy Phone: Email: angelo.garofalo@telecomitalia.it Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France Phone: +33 4 97 23 26 19 Email: flefauch@cisco.com Toerless Eckert Cisco Systems Tasman Drive San Jose, CA 95134 USA Phone: Email: ackert@cisco.com Maglione, et al. Expires January 12, 2009 [Page 36] Internet-Draft ANCP Multicast Handling July 2008 Tom Taylor Huawei Technologies 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Phone: +1 613 680 2675 Email: tom.taylor@rogers.com Maglione, et al. Expires January 12, 2009 [Page 37] Internet-Draft ANCP Multicast Handling July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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. Intellectual Property 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 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. Maglione, et al. Expires January 12, 2009 [Page 38]