ANCP F. Le Faucheur Internet-Draft Cisco Intended status: Standards Track R. Maglione Expires: April 29, 2010 Telecom Italia T. Taylor Huawei October 26, 2009 Additional Multicast Control Extensions for ANCP draft-ietf-ancp-mc-extensions-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the Le Faucheur, et al. Expires April 29, 2010 [Page 1] Internet-Draft ANCP Multicast Extensions October 2009 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Le Faucheur, et al. Expires April 29, 2010 [Page 2] Internet-Draft ANCP Multicast Extensions October 2009 Abstract This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document. Those use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation. These capabilities may be combined according to the rules given in this specification. Le Faucheur, et al. Expires April 29, 2010 [Page 3] Internet-Draft ANCP Multicast Extensions October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 10 3.1. NAS Initiated Multicast Replication Control Use Case . . . 10 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 3.2. Conditional Access and Admission Control Use Case . . . . 11 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 12 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 13 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 13 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 14 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 14 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 15 4.2. Port Management Message . . . . . . . . . . . . . . . . . 16 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 16 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 17 4.3. Multicast Replication Control Message . . . . . . . . . . 17 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 21 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 22 4.4. Multicast Admission Control Message . . . . . . . . . . . 24 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 25 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 26 4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 27 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 28 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 28 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 30 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 31 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 31 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 32 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 33 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 33 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 33 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34 4.9. Multicast Flow Query Request and Response Messages . . . . 35 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 35 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 36 5. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 38 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 38 5.2. Command Number TLV . . . . . . . . . . . . . . . . . . . . 41 5.3. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 41 5.4. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 42 5.5. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 42 Le Faucheur, et al. Expires April 29, 2010 [Page 4] Internet-Draft ANCP Multicast Extensions October 2009 5.6. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 42 5.7. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 43 5.8. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 43 5.9. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 44 5.10. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 45 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 46 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 46 6.1.1. Protocol Requirements For NAS-initiated Replication . 46 6.1.2. Protocol requirements For Conditional Access With White and Black Lists . . . . . . . . . . . . . . . . 47 6.1.3. Protocol requirements For Conditional Access With Grey Lists . . . . . . . . . . . . . . . . . . . . . . 48 6.1.4. Protocol requirements For Delegated Bandwidth . . . . 49 6.2. Capability-Specific Procedures for Providing Multicast Service . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2.1. Procedures For NAS-initiated Replication . . . . . . . 50 6.2.2. Procedures For Conditional Access With Black and White Lists . . . . . . . . . . . . . . . . . . . . . 51 6.2.3. Procedures For Conditional Access With Grey Lists . . 52 6.2.4. Procedures For Delegated Bandwidth . . . . . . . . . . 53 6.3. Combinations of Multicast Capabilities . . . . . . . . . . 54 6.3.1. Combination of NAS-Initiated Replication with Other Capabilities . . . . . . . . . . . . . . . . . . 54 6.3.2. Conditional Access With White, Black, and Grey Lists . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3.3. Conditional Access Combined With Delegated Bandwidth . . . . . . . . . . . . . . . . . . . . . . 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 63 Appendix A. Example of Messages and Message Flows . . . . . . . . 65 A.1. Multicast Conditional Access and CAC without AN bandwidth delegation . . . . . . . . . . . . . . . . . . . 65 A.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 65 A.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 67 A.1.3. Successful Join/Leave Operations . . . . . . . . . . . 67 A.1.4. Admission Control Reject without NAS Response . . . . 73 A.1.5. Admission Control Reject with NAS Response . . . . . . 75 A.2. Example Flows For bandwidth delegation . . . . . . . . . . 79 A.2.1. Activation and Provisioning of total multicast Bandwidth . . . . . . . . . . . . . . . . . . . . . . 80 A.2.2. Successful Request For More Multicast Bandwidth . . . 81 A.2.3. Failed Autonomous Transfer With Reset . . . . . . . . 83 A.3. Example Flows For Multicast Flow Reporting . . . . . . . . 86 A.3.1. Per Port Multicast Flow Reporting . . . . . . . . . . 86 Le Faucheur, et al. Expires April 29, 2010 [Page 5] Internet-Draft ANCP Multicast Extensions October 2009 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 Le Faucheur, et al. Expires April 29, 2010 [Page 6] Internet-Draft ANCP Multicast Extensions October 2009 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 in broadband networks in line with this framework. The Access Node Control Protocol (ANCP) specified in [I-D.ietf-ancp-protocol] supports a number of use cases defined in [I-D.ietf-ancp-framework] such as the Access Topology Discovery use case, the Access Loop Configuration use case and the Remote Connectivity Test use case. However, it does not support the multicast use cases defined in [I-D.ietf-ancp-framework]. The present document specifies the extensions to the Access Node Control Protocol required for support of these multicast use cases. In terms of the ANCP protocol, these use cases are organized into four capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation. NAS-initiated multicast replication assumes that multicast "join" and "leave" requests are terminated on the NAS, or that the NAS receives requests to establish multicast sessions through other means (e.g., application-level signalling). The NAS sends commands to the AN to start or stop replication of specific multicast flows on specific subscriber ports. This use case is described briefly in the next-to- last paragraph of section 3.4 of [I-D.ietf-ancp-framework]. Conditional access is described in sections 3.4.1 and 3.4.2.3 of [I-D.ietf-ancp-framework], with the latter section particularly applicable to operation with white and black lists only. In case of "conditional access with white and black lists", multicast join and leave requests are terminated at the AN and accepted or ignored in accordance with the direction provided by white and black lists respectively. The white and black lists are provisioned per port at startup time and may be modified thereafter. The NAS may enable admission control of White-listed flows by appropriate provisioning. If the bandwidth delegation capability has also been negotiated, that capability provides a means to adjust the multicast bandwidth limits Le Faucheur, et al. Expires April 29, 2010 [Page 7] Internet-Draft ANCP Multicast Extensions October 2009 at the AN. Conditional access with grey lists is similar to conditional access with white lists, except that before accepting any request matching a grey list entry, the AN sends a request to the NAS for permission to replicate the flow. Again, the NAS can enable admission control of Grey-listed flows at the AN. It can control the application of admission control on a per-flow basis. Bandwidth delegation is described in section 3.4.2.1 of [I-D.ietf-ancp-framework]. It allows flexible sharing of total video bandwidth on an access line between the AN and the NAS. One application of such bandwidth sharing is where the AN does multicast admission control, while the NAS or Policy Server does unicast admission control. In that case, bandwidth delegation allows dynamic sharing of bandwidth between unicast and multicast video traffic on each access line. The formal specification of the behaviours associated with each of these capabilities, singly and in combination, is given in Section 6. In addition to the multicast service processing behaviour just sketched, the definition of each capability includes support for the multicast accounting and reporting services described in section 3.4.3 of [I-D.ietf-ancp-framework]. Because of this common content and because of other protocol overlaps between the different capabilities, the protocol descriptions for the multicast extensions specified in this document are merged into a single non-redundant narrative. Tables in Section 6 then indicate the specific sub- sections of the protocol description that have to be implemented to support each capability. Le Faucheur, et al. Expires April 29, 2010 [Page 8] Internet-Draft ANCP Multicast Extensions October 2009 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 [RFC2119]. The expression "delegated bandwidth" is used as a shorter way of saying: "the total amount of video bandwidth delegated to the AN for multicast admission control". Le Faucheur, et al. Expires April 29, 2010 [Page 9] Internet-Draft ANCP Multicast Extensions October 2009 3. Multicast Use Cases Quoting from [I-D.ietf-ancp-framework]: "... the Access Node, aggregation node(s) and the NAS must all be involved in the multicast replication process. This avoids that several copies of the same stream are sent within the access/ aggregation network. In case of an Ethernet-based access/aggregation network, this may, for example, be achieved by means of IGMP snooping or IGMP proxy in the Access Node and aggregation node(s). By introducing IGMP processing in the access/aggregation nodes, the multicast replication process is now divided between the NAS, the aggregation node(s) and Access Nodes. In order to ensure backward compatibility with the ATM-based model, the NAS, aggregation node and Access Node need to behave as a single logical device. This logical device must have exactly the same functionality as the NAS in the ATM access/aggregation network. The Access Node Control Mechanism can be used to make sure that this logical/functional equivalence is achieved by exchanging the necessary information between the Access Node and the NAS. " [I-D.ietf-ancp-framework] describes the use cases for ANCP associated with such multicast operations, and identifies the associated ANCP requirements. The present section describes a subset of these use cases as background to facilitate reading of this document, but the reader is refered to [I-D.ietf-ancp-framework] for a more exhaustive description of the ANCP multicast use cases. Detailed example message flows can also be found in Appendix A. 3.1. NAS Initiated Multicast Replication Control Use Case 3.1.1. Goals One option for multicast handling is for the subscriber to communicate the "join/leave" information to the NAS. This can be done for instance by terminating all subscriber IGMP ([RFC3376]) or MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example could be a subscriber using some form of application level signaling, which is redirected to the NAS. In any case, this option is transparent to the access and aggregation network. In this scenario, the NAS uses ANCP to create and remove replication state in the AN for efficient multicast replication. Thus, the NAS only sends a single copy of the multicast stream towards the AN, which in turn performs replication to multiple subscribers as instructed by the NAS via ANCP. The NAS first performs conditional access and multicast admission control when processing multicast join requests, and only creates replication state in the AN if admission succeeds. Le Faucheur, et al. Expires April 29, 2010 [Page 10] Internet-Draft ANCP Multicast Extensions October 2009 3.1.2. Message Flow With the NAS-initiated use case, a Multicast Replication Control Message is sent by the NAS to the AN with a directive to either join or leave one (or more) multicast flow(s). The AN uses a Generic Response message to convey the outcome of the directive. Figure 1 illustrates such an ANCP message exchange as well as the associated AN behavior. +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<-------------------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | Multicast-Replication-Crl | | | | (Target,add, Flow 1) | | | |<--------------------------| | Mcast Flow 1 | | |<==========================+ | | | | Generic Response | | | |-------------------------->| | | | | | | | | ~ ~ ~ ~ | | | | | | | Multicast-Replication-Crl | | | | (Target,delete, Flow 1) | | | |<--------------------------| | | | | | | Generic Response | | | |-------------------------->| Figure 1: NAS Initiated Multicast Replication Control 3.2. Conditional Access and Admission Control Use Case 3.2.1. Goals One option for multicast handling is for the access/aggregation nodes to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). In this scenario, on detecting a join/leave request from an enduser for a multicast flow (in the grey list), the AN uses ANCP to request conditional access and admission control decision from the NAS. In turn, after conditional access and admission control checks, the NAS uses ANCP to instruct the AN to change the replication states accordingly. Le Faucheur, et al. Expires April 29, 2010 [Page 11] Internet-Draft ANCP Multicast Extensions October 2009 3.2.2. Message Flow For support of the conditional access and admission control use case, on detection of an IGMP/MLD Join, the AN sends an Admission Control message to the NAS to request conditional access and admission control check. In case of positive outcome, the NAS sends a Multicast Replication Control Message to the AN with a directive to replicate the multicast flow to the corresponding user. Similarly on detection of an IGMP/MLD leave, an Admission Control message is sent by the AN to the NAS to keep the NAS aware of user departure for the flow. This message flow is illustrated in Figure 2. +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<------------------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | Join(Gr-Flow1) | Admission-Control | |------------+---------->| (Target,add,Gr-Flow1) | | | |-------------------------->| | | | (*) | | | Multicast-Replication-Crl | | | | (Target,add,Gr-Flow 1) | | | |<--------------------------| | Mcast Gr-Flow1 | | |<=======================+ | | | | | ~ ~ ~ ~ | | | | | Leave(Gr-Flow1) | Admission-Control | |------------+---------->| (Target,delete,Gr-Flow1) | | | |-------------------------->| | | | | | | | Gr-Flow1: a multicast flow matching the grey list for that port (*) The NAS may optionally seek direction from an external Authorization/Policy Server Figure 2: Multicast Conditional Access and Admission Control Le Faucheur, et al. Expires April 29, 2010 [Page 12] Internet-Draft ANCP Multicast Extensions October 2009 3.3. Multicast Flow Reporting Use Case 3.3.1. Goals The Multicast flow reporting use case allows the NAS to asynchronously query the AN to obtain an instantaneous status report related to multicast flows currently replicated by the AN. 3.3.2. Message Flow The NAS sends a Multicast Flow Query Request message to the AN in order to query the AN about information such as which multicast flows are currently active on a given AN port or which ports are currently replicating a given multicast flow. The AN conveys the requested information to the NAS in a Multicast Flow Query Response message. This message flow is illustrated in Figure 3. +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | Multicast Flow | | | | Query Request | | | |<------------------| | | | | | | | Multicast Flow | | | | Query Response | | | |------------------>| | | | | | | | | Figure 3: Multicast Flow Reporting Le Faucheur, et al. Expires April 29, 2010 [Page 13] Internet-Draft ANCP Multicast Extensions October 2009 4. ANCP Messages This section defines new ANCP messages and new usage of existing ANCP messages as well as procedures associated with the use of these messages. 4.1. Provisioning Message Section 5.4.3.1 of [I-D.ietf-ancp-protocol] defines the Provisioning message that is sent by the NAS to the AN to provision information in the AN. The present document specifies that the Provisioning message MAY be used by the NAS to provision multicast-related information (e.g. multicast service profiles). The ANCP Provisioning message payload MAY contain: o one or more instances of the Multicast-Service-Profile TLV. The Multicast-Service-Profile TLV is defined in the present document in Section 5.1. Each instance of the Multicast-Service-Profile TLV contains a Multicast Service Profile name and one or more list actions. A list action consists of an action (add, delete, replace), a list type (White, Black, or Grey), and list content (multicast source and group addresses). o an instance of the White-List-CAC TLV. The White-List-CAC TLV is defined in section TLV_White_AC. If present, this TLV indicates that the AN is required to do admission control before replicating White-listed flows. o an instance of the MRepCtl_CAC TLV. The MRepCtl-CAC TLV is defined in section TLV_MRepCtl_AC. If present, this TLV indicates that the AN may be required to do admission control before replicating flows specified in Multicast Replication Control messages. See Section 6 for information on which multicast capabilities require support of these TLVs in the Provisioning message. 4.1.1. Sender Behaviour When directed by the Policy Server or by management action, the NAS sends the Provisioning message to initially provision or to update the White, Black, and/or Grey multicast channel lists associated with a set of named multicast service profiles, or to enable the AN to perform admission control for specific classes of flows. To provision or update a multicast service profile, the NAS MUST Le Faucheur, et al. Expires April 29, 2010 [Page 14] Internet-Draft ANCP Multicast Extensions October 2009 include within the message one or more instances of the Multicast- Service-Profile TLV specifying the content to be provisioned or updated. The NAS SHOULD NOT include any list type (White, Black, or Grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN. The NAS MUST NOT use the Provisioning message to send instances of the Multicast-Service- Profile TLV to the AN unless the Multicast-Service-Profile TLV is supported by the set of multicast capabilities negotiated between the NAS and the AN. To require admission control to be performed at the AN on White- listed flows, the NAS MUST include a copy of the White-List-CAC TLV in the Provisioning message. The White-List-CAC TLV MUST NOT be provided unless the negotiated set of capabilities includes conditional access with White and Black lists. To require admission control to be performed at the AN on Grey-listed flows or on NAS-initiated flows, the NAS MUST include a copy of the MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV MUST NOT be provided unless the negotiated set of capabilities includes NAS-initiated replication control or conditional access with Grey lists. 4.1.2. Receiver Behaviour The receiving AN provisions/updates the White, Black, and/or Grey lists associated with the Multicast Service Profile names contained in the Multicast-Service-Profile TLV instances within the message. The AN MUST ignore instances of the Multicast-Service-Profile TLV referring to any list type (White, Black, or Grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN. When a new Multicast Service Profile is identified by a Multicast- Service-Profile TLV, the initial state of all lists associated with that profile according to the negotiated set of multicast capabilities is empty until changed by the contents of Multicast- Service-Profile TLVs. If the White-List-CAC and/or MRepCtl-CAC TLV is present in the Provisioning message and the respective associated capabilities have been negotiated, the AN prepares to do connection admission control on the indicated class(es) of flow. As indicated in [I-D.ietf-ancp-protocol], the AN MUST NOT reply to the Provisioning message if it processed it successfully. If an error prevents successful processing of the message content, the AN MUST return a Generic Response message as defined in Le Faucheur, et al. Expires April 29, 2010 [Page 15] Internet-Draft ANCP Multicast Extensions October 2009 [I-D.ietf-ancp-protocol], containing a Status-Info TLV with the appropriate content describing the error. For this purpose, the presence of a list typein a Multicast-Service-Profile TLV which was ignored because it was not supported by the negotiated set of capabilities is not considered to be an error. Editor's note: that means that if a NAS mistakenly adds the wrong list types there will be no debugging feedback. On the other hand, this adds flexibility for handling pre-assembled sets of list updates being sent out to multiple ANs. If there are no comments on this feature/bug, this Editor's note will be removed in the next version of the draft. When a new Multicast Service Profile is identified by a Multicast- Service-Profile TLV, the initial state of all lists associated with that profile according to the negotiated set of multicast capabilities is empty until changed by the contents of Multicast- Service-Profile TLVs. 4.2. Port Management Message As specified in [I-D.ietf-ancp-protocol], the NAS may send line configuration information to the AN ("ANCP based Line Configuration" use case) using GSMP Port Management messages modified to contain an extension block. Section 5.4.3 of [I-D.ietf-ancp-protocol] defines a number of TLVs that can be included in the Extension Value field inside a Port Management message to support line configuration. This document specifies that the Port Management message MAY also include the following TLVs: o "Multicast-Service-Profile-Name" TLV (defined in Section 5.7). This TLV associates a Multicast Service Profile with the Access Port specified by the extension block. o "Bandwidth-Allocation" TLV (defined in Section 5.3). This TLV specifies the total multicast bandwidth available to the AN for admission control at the Access Port. 4.2.1. Sender Behaviour The NAS sends the Port Management message at startup time to initialize parameters associated with the Access Port specified in the message and with the multicast capabilities negotiated between the NAS and the AN. The NAS MAY send additional Port Management messages subsequent to startup, to update or, in the case of the Bandwidth-Allocation TLV, reset these parameters. The NAS MUST NOT include a TLV unless it is supported by the set of multicast Le Faucheur, et al. Expires April 29, 2010 [Page 16] Internet-Draft ANCP Multicast Extensions October 2009 capabilities negotiated between the NAS and the AN. See Section 6 for further information. 4.2.2. Receiver Behaviour If the Port Management message contains a Multicast-Service-Profile- Name TLV, the AN associates the named profile with the specified Access Port. This association replaces any previous association. That is, a given Access Port is associated with at most one Multicast Service Profile. As specified in [I-D.ietf-ancp-framework], if a join request is later received by the AN for a multicast flow that is part of multiple lists in the Multicast Service Profile associated with the Access Port, then the most specific match MUST be used by the AN. If the most specific match occurs in multiple lists, the Black list entry MUST take precedence over the Grey list, which MUST take precedence over the White list. If the requested multicast flow is not part of any list, the AN SHOULD ignore the join request. If the Port Management message contains a Bandwidth-Allocation TLV, the AN adopts this as the current value of its total multicast bandwidth limit for the Access Port. If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth- Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. If the Port Management request cannot be processed due to error and the Result field of the request is Nack (0x1) or AckAll (0x2), the AN SHOULD add a Status-Info TLV to the Extension Value field in its reply if this will provide useful information beyond what is provided by the Code value returned in the response header. 4.3. Multicast Replication Control Message This section defines a new message called the Multicast Replication Control message. The Multicast Replication Control message is sent by the NAS to the AN with one or more directives to add (join) or delete (leave) a multicast flow on a target object identified in the content of the message. The Message Type for the Multicast Replication Control message is 0x90. The ANCP Multicast Replication Control message payload contains the Le Faucheur, et al. Expires April 29, 2010 [Page 17] Internet-Draft ANCP Multicast Extensions October 2009 following TLVs: o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. It MUST appear once and only once. It is encoded as specified in [I-D.ietf-ancp-protocol] and identifies the AN port subject to the request for admission or release. o Command TLV: The Command TLV is defined in [I-D.ietf-ancp-protocol]. It MUST be present. It MAY appear multiple times. Each Command TLV contains a multicast flow directive for the target. The contents of the Command TLV for the Multicast Replication Control Message are defined in Figure 4 and subsequent text. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code |R O M Flags | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Flow Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Cont'd) ... / \ | Multicast Flow Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Cont'd) ... / \ | Sub-TLVs ... | +-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Cont'd) ... / \ | Padding to 32-bit boundary | +-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Contents of the Command TLV in the Multicast Replication Control Message Command Code: Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete All. Command Length: Length in bytes of the Command including multicast flow address, but excluding the Command Code header and flags. Flags: 8 bit General purpose Flag field. Currently the following flags are defined: R - Resource Admitted Flag. Set to 1 in an add command to indicate that the flow resources have been reserved by admission control. Cleared to 0 otherwise. Le Faucheur, et al. Expires April 29, 2010 [Page 18] Internet-Draft ANCP Multicast Extensions October 2009 O - Flow Accounting. When set in add command indicates that byte accounting for the flow is to commence. M - When set, indicates that the multicast flow is SSM; the Command MUST then specify both the source and the group address. When not set, indicates that the multicast flow is ASM; the Command MUST then specify the group address only, omitting the Source Address field. Multicast Flow Source Address: a field containing three sub-fields as illustrated in Figure 5, giving the source address for an SSM flow. This field MUST be present if the M flag is set, and MUST NOT be present if the M flag is cleared. Multicast Flow Group Address: a field containing three sub-fields as illustrated in Figure 5, giving the group address for the multicast flow. This field MUST be present. The address family of the group address MAY differ from the address family of the source address, if present. For future extensibility, each Command TLV MAY also have additional sub-TLVs appended following the command and multicast flow information (shown as "Sub-TLVs" in Figure 4). Unrecognized sub-TLVs SHOULD be silently discarded. If needed, padding is done at the end of the command data so that the TLV is 32-bit aligned. As shown in Figure 5, each address entry in the Command TLV consists of the following three sub-fields with no intervening padding: Address Family: The address family of the address with values as defined in [IANAAEA]. Encoding Type: The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. This is consistent with the address encoding specified in [RFC4601]. Le Faucheur, et al. Expires April 29, 2010 [Page 19] Internet-Draft ANCP Multicast Extensions October 2009 Address: The address as represented by the given Address Family and Encoding Type. This is consistent with the address encoding specified in [RFC4601]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+ | IP Address (Cont'd) ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+ Figure 5: Structure of the Address Fields in the Command TLV The figure below is an example of a Multicast Replication Control message that would result in a swap from multicast SSM flows 192.0.2.1, 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target identified by the "Access Loop Circuit ID": Le Faucheur, et al. Expires April 29, 2010 [Page 20] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=90 | 0x02 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Target 0x1000 | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Command TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x02 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Mcast Source (Ctnd) 192.0.2.1 | AddrFamily 01 | EncType 0x0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow : 233.252.0.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ | Type = Command-TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x01 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Mcast Source (Ctnd) 192.0.2.2 | AddrFamily 01 | EncType 0x0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow: 233.252.0.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.1. Sender Behaviour The NAS MAY issue a Multicast Replication Control message to the AN to convey one or more directives to add (join) or delete (leave) one or more multicast flows. The NAS MAY send this message on its own initiative to support the Le Faucheur, et al. Expires April 29, 2010 [Page 21] Internet-Draft ANCP Multicast Extensions October 2009 NAS initiated Multicast Control use case presented in [I-D.ietf-ancp-framework] and summarized in Section 3.1. In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1) according to its requirements. The NAS MAY also send this message in response to a Multicast Admission Control message (defined in Section 4.4) received from the AN to support the conditional access and admission control use case presented in [I-D.ietf-ancp-framework] and summarized in Section 3.2. In that case, the NAS MUST set the Result field to NAck (0x1). In either case, the sender MUST populate the Code field with the value 0x000 and the ANCP Transaction Identifier field with a unique value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol]. Each Multicast Replication Control Message MAY contain one or more commands, each encapsulated in its own Command TLV. The sender MUST use a separate Command TLV for each distinct multicast flow. When the order of processing of two commands does not matter, the commands MUST be transmitted in separate Multicast Replication Control messages. The NAS MAY choose to perform admission control before adding a particular flow even if admission control has been enabled on the AN. If it does so, it MUST set the R flag in the Command TLV concerned. Conversely, if admission control has been enabled on the AN, the NAS MAY choose to have the AN do admission control by clearing the R flag. Note that clearing the R flag causes the AN to allocate resources for the flow out of its bandwidth budget as opposed to any bandwidth budget managed for the same access line at the NAS. 4.3.2. Receiver Behaviour When successive commands (in the same or different messages) relate to the same Target and multicast flow, the state of each feature controlled or affected by flags or by optional attributes received in the Multicast Replication Control message, SHALL be as set by the last command or message referring to that target and flow and containing the controlling flag or optional attribute. As an example, successive Multicast Replication Control messages containing add commands for a given port and flow, but differing only in the accounting flag setting SHALL be interpreted to mean that the state of the accounting feature is as set in the final command received, but all other features are as set in the initial message. Le Faucheur, et al. Expires April 29, 2010 [Page 22] Internet-Draft ANCP Multicast Extensions October 2009 If more than one Command TLV is present in a Multicast Replication Control message, the AN MUST act on the commands in the order in which they are presented in the message. The AN SHALL assign a sequence number to each command in a given Multicast Replication Control message, starting from 0x01 for the first command. If admission control for Multicast Replication Control messages has not been enabled (through provisioning of the MRepCtl_CAC TLV, the AN MUST ignore the R flag in Command TLVs. Otherwise, if a Command TLV adds a flow, the R flag within the TLV is not set, and the AN is performing admission control for Multicast Replication Control messages, then the AN MUST perform admission control before replicating the flow. If the admission control check fails, the AN MUST treat the failure as an error as described below. The appropriate Code value for the response is 18 (0x012) "Insufficient resources". If the AN processes the complete Multicast Replication Control message successfully and the Result field of the Multicast Replication Control message was set to AckAll (0x2), the AN MUST respond with a Generic Response message where the Result field is set to Success (0x3), the Code field is set to 0x000, and the Transaction Identifier field is copied from the Multicast Replication Control message. The body of the response MAY be empty or MAY be copied from the Multicast Replication Control message. The processing/execution of multiple commands contained in a single Multicast Control message MUST be interrupted at the first error encountered, and the remaining commands in the Multicast Replication Control message discarded. If the AN detects an error in a received Multicast Replication Control message and the Result field in that message was set to Nack (0x1) or AckAll (0x2), the AN MUST generate a Generic Response message providing error information to the NAS. This specification identifies the following new Code values beyond those specified in [I-D.ietf-ancp-protocol], which MAY be used in a Generic Response sent in reply to a Multicast Replication Control message: 0x100 Command error. This SHOULD be reported for the following cases: * invalid command code; * undefined flag set. Le Faucheur, et al. Expires April 29, 2010 [Page 23] Internet-Draft ANCP Multicast Extensions October 2009 0x101 Bad flow address. This SHOULD be reported for the following cases: * unsupported address family; * unsupported address encoding; * source address present when M flag cleared, or absent when M flag set. 0x102 Multicast flow does not exist. This SHOULD be reported if the NAS attempts to delete a flow that is not enabled. A Generic Response message responding to the Multicast Replication Control message and containing one of the above Code values MUST include a Status-Info TLV which includes one or two sub-TLVs as follows: o a Command Number TLV as described in Section 5.2, giving the sequence number of the failed command, MUST be included; o the failed Command TLV itself SHOULD be included. Note that the Error Message field of the Status-Info TLV MAY be used to report more details than implied by the Code value in the message header. For example, the Code value could be 0x101 and the Error Message field could contain the text: "Source address present when M flag cleared". 4.4. Multicast Admission Control Message This section defines a new message called the Multicast Admission Control message. The Multicast Admission Control message is sent by the AN to the NAS to request admission of a multicast flow, or to notify of the removal of a multicast flow, for a given target. The Message Type for the Multicast Admission Control message is 0x92. The ANCP Multicast Admission Control message payload contains two TLVs: o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. It MUST appear once and only once in the Multicast Admission Control message. It is encoded as specified in [I-D.ietf-ancp-protocol] and identifies the AN port subject to the request for admission or release. Le Faucheur, et al. Expires April 29, 2010 [Page 24] Internet-Draft ANCP Multicast Extensions October 2009 o Command TLV: The Command TLV is defined in [I-D.ietf-ancp-protocol]. It MUST be present. If it appears more than once, only the first instance is considered meaningful in the present version of this specification and the other instances are ignored. Informative note: In the future, the specification of the Admission Control message may be extended to allow transport of more than a single directive (e.g. to carry both a leave from one group and a join to another group for the same Target). It is expected that this would support a similar notion of strict sequenced processing as currently defined for handling multiple directives in the Multicast Replication Control message whereby all directives following the first directive that can not be executed are not executed either. When the strict sequenced processing of the directives is not required the directives are distributed across separate messages. 4.4.1. Sender Behaviour The AN sending the Multicast Admission Control message MUST set the Result field to Ignore (0x0). The AN MUST populate the ANCP Transaction Identifier field with a unique value, as described in section 5.4.5 of[I-D.ietf-ancp-protocol] . The AN MUST encode the Command TLV as specified in Section 4.3 with the following additional rules: o the R flag MUST be set to 0; o the O flag MUST be set to 0; o the Command Code field MUST be set to "0x01 - Add" when the message conveys a Join , to "0x02 - Delete" when the message conveys a Leave and to "0x03 - Delete All" when the message conveys a Leave of all channels (on the target); o The M Flag, Multicast Source Address and Multicast Flow Address of the Command TLV identify the multicast flow subject to the request for admission or release. When the Command Code is 0x03, the M Flag, Multicast Source address, and Multicast Flow Address are meaningless and MUST be set to all zeroes. Le Faucheur, et al. Expires April 29, 2010 [Page 25] Internet-Draft ANCP Multicast Extensions October 2009 o a Request-Source-IP sub-TLV (as defined in Section 5.8) MAY be included by the AN to convey the IP address of the sender of the join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the corresponding Command TLV in the Admission Control message. If it appears more than once, only the first instance is considered meaningful and the other instances are ignored. o a Request-Source-MAC sub-TLV (as defined in Section 5.9) MAY be included by the AN to convey the MAC address of the sender of the join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the corresponding Command TLV in the Admission Control message. If it appears more than once, only the first instance is considered meaningful and the other instances are ignored. 4.4.2. Receiver Behaviour On receipt of an Multicast Admission Control message, the NAS: o MUST ignore the Result field; o if the directive in the Multicast Admission Control message is "0x02 - Delete" or "0x03 - Delete All" and is processed correctly by the NAS, the NAS MUST NOT generate any ANCP message in response to the Multicast Admission Control message; o if the directive in the Multicast Admission Control message is "0x01 - Add" and is accepted by the NAS, the NAS MUST generate a Multicast Replication Control in response to the Multicast Admission Control message. The Multicast Replication Control message: * MUST contain a Result set to Nack (0x1); * MUST contain a Transaction ID generated by the NAS (distinct non-zero, and linearly incremented by NAS for each request per adjacency); * MUST contain the directive as accepted by the NAS. The R flag in the returned Command TLV MUST have value 0 if the NAS intends the AN to perform admission control before installing the flow, 1 otherwise. Note that the AN will ignore the R flag unless the MRepCtl_CAC TLV has been provisioned on the AN. o if the directive in the Multicast Admission Control message is "0x01 - Add", is processed correctly but not accepted by the NAS (i.e. it does not pass the admission control or conditional access Le Faucheur, et al. Expires April 29, 2010 [Page 26] Internet-Draft ANCP Multicast Extensions October 2009 check), the NAS MAY generate a Multicast Replication Control message in response to the Multicast Admission Control message. This optional message can be used by the AN to maintain statistics about admission control reject and, in the future, when the protocol between the subscriber and the AN allows explicit notification of join reject (e.g. [I-D.morin-mboned-igmpmld-error-feedback]). When used in this situation, the Multicast Replication Control message: * MUST contain a Result set to 0x00; * MUST contain a Transaction ID generated by the NAS (distinct non-zero, and linearly incremented by NAS for each request per adjacency); * MUST contain the directive rejected by the NAS (i.e. Target TLV and Command TLV) but with a Command Code set to "0x04 - Admission Control Reject", "0x05 - Conditional Access Reject" or "0x06 - Admission Control and Conditional Access Reject". o if the Multicast Admission Control message cannot be processed correctly by the NAS (e.g. the message is malformed, the multicast flow does not exist etc.), the NAS MUST generate a Generic Response message (defined in [I-D.ietf-ancp-protocol]) with appropriate content indicating the reason for the failure. 4.5. Bandwidth Reallocation Request Message The Bandwidth Reallocation Request message is used when the bandwidth delegation capability is included in the negotiated set. It MAY be sent either by the NAS or by the AN to request an adjustment in the amount of delegated bandwidth. It will be sent by the NAS typically to reduce the multicast bandwidth allocated to the AN in order for the NAS to satisfy a request to add one or more flows. Conversely, the AN will send a Bandwidth Reallocation Request to obtain additional bandwidth to satisfy a request to add a multicast channel. In each case, the requestor has a minimum requirement for additional bandwidth, and MAY ask for additional bandwidth beyond this amount (e.g., to handle anticipated future requests). The Bandwidth Reallocation Request message contains two TLVs: o the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]), specifying a single access line; o the Bandwidth-Request TLV (Section 5.6), specifying the required and preferred amounts of delegated bandwidth. Le Faucheur, et al. Expires April 29, 2010 [Page 27] Internet-Draft ANCP Multicast Extensions October 2009 The Message Type for the Bandwidth Reallocation Request message is 0x94. 4.5.1. Sender Behaviour The Result field in the header of the Bandwidth Reallocation Request message is not used and the sender MUST set it to Ignore (0x0). The bandwidth values in the Bandwidth-Request TLV are expressed in terms of total multicast bandwidth allocated to the AN. The choice of "total bandwidth" rather than "incremental bandwidth" was made so that it would be easier for the AN and NAS to keep their respective views of the current amount of delegated bandwidth synchronized. Because the values are totals rather than desired increments/ decrements, the relationship between the required amount and the preferred amount will differ depending on whether the Bandwidth Reallocation Request message is issued by the NAS or the AN. o If the NAS is making the request, the preferred amount MUST be less than or equal to the required amount. The required amount MUST be less than the currently amount of delegated bandwidth. o If the AN is making the request, the preferred amount MUST be greater than or equal to the required amount. The required amount MUST be greater than the currently amount of delegated bandwidth. 4.5.2. Receiver Behaviour When the peer receives a valid Bandwidth Reallocation Request message, it SHOULD determine whether it can satisfy the request from its existing allocation of unused video bandwidth. If it decides that it can reallocate bandwidth to the peer, it MAY choose to return any amount between the required and the preferred amounts indicated in the Bandwidth Reallocation Request message. The peer MUST return a Bandwidth Transfer message Section 4.6 indicating its decision. If the request is met, the Result field of the Bandwidth Transfer message MUST be set to Success (0x3), the Code field MUST be set to 0x000, and the Bandwidth-Allocation TLV (Section 5.3) MUST contain the new value of total multicast bandwidth. This new value MUST lie between the required and preferred values, inclusive, from the request message. If the request is not met, the Result field of the Bandwidth Transfer message MUST be set to Failure (0x4), the Code field MUST be set to 0x000, and the Bandwidth Allocation TLV MUST contain the value of the Le Faucheur, et al. Expires April 29, 2010 [Page 28] Internet-Draft ANCP Multicast Extensions October 2009 currently allocated amount of delegated bandwidth as the responder views it. The following cases indicate that the sender holds a different view of the amount of bandwidth from the receiver: o the NAS receives a request where the required amount is less than its view of the current amount of delegated bandwidth; o the AN receives a request where the required amount is greater than its view of the current amount of delegated bandwidth. If one of these cases occurs, the receiver with one exception MUST send a Bandwidth Transfer message indicating Success. o If the NAS received the request, the allocated amount in the NAS's response MUST be at least equal to NAS's view of the current amount of delegated bandwidth. o If the AN received the request, the allocated amount in the AN's response MUST be no greater than the AN's view of the current amount of delegated bandwidth. The exception is when the NAS receives a request while it has a request of its own outstanding. Handling of that case is described below. While the cases just described are an error condition, the success response achieves a graceful recovery. To avoid deadlock due to race conditions, the following rules MUST be applied: a. If the NAS receives a Bandwidth Reallocation Request message while it has a Bandwidth Reallocation Request message of its own outstanding for the same access line, the NAS MUST provide an immediate failure response to the request from the AN, with a Code value set to 0x105 "Bandwidth request conflict". b. If the AN receives a Bandwidth Reallocation Request message while it has a Bandwidth Reallocation Request message of its own outstanding for the same access line, the AN MUST release any bandwidth it has already committed to an outstanding Join request while it is awaiting a response from the NAS. It MUST decide upon and send its response to the NAS taking the released bandwidth into account. If the receiver is unable to process the Bandwidth Reallocation Le Faucheur, et al. Expires April 29, 2010 [Page 29] Internet-Draft ANCP Multicast Extensions October 2009 Request message due to an error, then the receiver MUST return a Bandwidth Transfer message where: o the Result field is set to Failure (0x4), o the Code field is set appropriately to indicate the type of error that was detected, o the Bandwidth Allocation TLV contains the value of the current amount of delegated bandwidth as the responder views it, and o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving further information about the error. This specification provides three new Code values applicable specifically to the contents of the Bandwidth-Request TLV. These Code values by their nature MUST only be used when the error is being reported in a Bandwidth Transfer message rather than a Generic Response message. 0x103 invalid preferred bandwidth amount. This indicates that the preferred and required amounts of bandwidth in the TLV do not have the numerical relationship described in the previous section. 0x104 inconsistent views of delegated bandwidth amount. This will appear only in a Bandwidth Transfer message from the NAS to the AN in the case where the NAS has an outstanding Bandwidth Reallocation Request. The recommended procedure for recovery is described in Section 4.6.2. 0x105 bandwidth request conflict. The NAS has rejected the AN's request for more bandwidth because the NAS has an outstanding bandwidth request. 4.6. Bandwidth Transfer Message The Bandwidth Transfer message is used to transfer video bandwidth from the sender to the peer for a specific access line. This message MAY be sent either from the AN or from the NAS. As described in the previous section, it is the required response to a valid Bandwidth Reallocation Request message. The Bandwidth Transfer message MAY also be used to transfer bandwidth autonomously from one peer to another. One example of this usage is to release bandwidth borrowed earlier by means of the Bandwidth Reallocation Request message. When the message is used in this way, the Result field in the Bandwidth Transfer message MUST be set to Ignore (0x0). Le Faucheur, et al. Expires April 29, 2010 [Page 30] Internet-Draft ANCP Multicast Extensions October 2009 This allows the receiver to distinguish between an autonomous transfer and a response to a previous Bandwidth Reallocation Request, for purposes of validation. The Message Type for the Bandwidth Transfer message is 0x95. The Bandwidth Transfer message contains the following TLVs: o the Target TLV, designating the access line concerned; o an instance of the Bandwidth-Allocation TLV (Section 5.3). The bandwidth value in the Bandwidth-Allocation TLV is the new amount of delegated bandwidth allocated to the target. 4.6.1. Sender Behaviour When sending a Bandwidth Transfer message where the Result value is Ignore (0x0) or Success (0x3), the following relationships MUST hold: o if the message is sent by the NAS, the bandwidth value in the Bandwidth-Allocation TLV MUST be greater than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned; o if the message is sent by the AN, the bandwidth value in the Bandwidth-Allocation TLV MUST be less than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned. Further sender behaviour is specified above, in Section 4.5.2. 4.6.2. Receiver Behaviour 4.6.2.1. Behaviour of the NAS If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is not greater than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Bandwidth Transfer message. This is required regardless of whether the Result field of that message indicates Success or Failure. If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new value of delegated bandwidth. Alternatively, the NAS MAY force the AN to modify its view of the amount of delegated bandwidth to that held by the NAS, by sending a Port Management message for the target access line concerned, containing a Bandwidth-Allocation TLV with a Le Faucheur, et al. Expires April 29, 2010 [Page 31] Internet-Draft ANCP Multicast Extensions October 2009 value equal to the amount of delegated bandwidth the NAS wishes to enforce. 4.6.2.2. Behaviour of the AN If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV of the Bandwidth Transfer message differs from the AN's view of the current amount of delegated bandwidth, the AN MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Bandwidth Transfer message. This is required with the exception of a Bandwidth Transfer message with a Result field equal to Failure (0x4) and a Code field equal to 0x104 "Inconsistent views of delegated bandwidth amount" or 0x105 "Bandwidth request conflict". If Code value 0x104 is received, the AN MUST issue a Delegated Bandwidth Query Request message to determine the NAS's current view of the amount of delegated bandwidth. The AN MUST update its own view based on the value returned in the Delegated Bandwidth Query Response. If Code value 0x105 is received, the AN SHOULD carry out this procedure unless it can account for the discrepancy as a result of a transfer of bandwidth to the NAS that was carried out just before the incoming Bandwidth Transfer message was processed. The two Code values indicate a race condition where the AN may have just completed a transfer of bandwidth to the NAS. As a result, the value given in the Bandwidth Transfer message may be outdated, and the AN needs to query the NAS to find its latest view. The procedure assumes that ordering is preserved between the Bandwidth Transfer message sent by the AN in response to the NAS's request and the subsequent Delegated Bandwidth Query Request message. If as the result of the procedures just described the AN determines that it has over-committed multicast bandwidth, it MUST NOT terminate any currently-active programs, but MUST NOT honour any more "join" requests until it is possible to do so within the limit set by its current value of delegated bandwidth. 4.7. Delegated Bandwidth Query Request Message The Message Type for the Delegated Bandwidth Query Request (and Response) messages is 0x96. The Delegated Bandwidth Query Request message MAY be sent either by the NAS or by the AN to retrieve the peer's view of the amount of delegated bandwidth. The request contains one TLV: Le Faucheur, et al. Expires April 29, 2010 [Page 32] Internet-Draft ANCP Multicast Extensions October 2009 o a Target TLV designating the access line for which the information is requested. 4.7.1. Sender Behaviour The sender MUST set the Result field in the header of the Delegated Bandwidth Query Request message to AckAll (0x2). The Code value MUST be set to 0x000. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol]. 4.7.2. Receiver Behaviour If the AN or NAS receives a valid Delegated Bandwidth Query Request message, it MUST respond with a Delegated Bandwidth Query Response message. The Result field in the header of the response MUST be set to Success (0x3). The Code field MUST be set to 0x000. The Transaction-Id field MUST be copied from the request message. The body of the response MUST contain the Target TLV, copied from the request message. Finally, the body of the response MUST contain a Bandwidth-Allocation TLV, containing the current amount of delegated bandwidth from the point of view of the receiver of the request. If the contents of the Delegated Bandwidth Query Request message are in error, the receiver MUST return a Delegated Bandwidth Query Response message with the Result field in the header set to Failure (0x3). The Code field MUST be set to the value that indicates the nature of the error (e.g., 0x004 "Unrecognized target"). The Transaction-Id field MUST be copied from the request. The body of the response MUST contain the Target TLV copied from the request. This MAY be followed by a Status-Info TLV giving further infromation about the error. 4.8. Delegated Bandwidth Query Response Message The Delegated Bandwidth Query Response message is sent in reply to a Delegated Bandwidth Query Request. The response to a valid request contains two TLVs: o the Target TLV, copied from the request; o a Bandwidth-Allocation TLV, giving the responder's view of the current amount of multicast bandwidth delegated to the AN. The Message Type for the Delegated Bandwidth Query Response message is 0x96. Le Faucheur, et al. Expires April 29, 2010 [Page 33] Internet-Draft ANCP Multicast Extensions October 2009 4.8.1. Sender Behaviour Sender behaviour for the Delegated Bandwidth Query Response message is specified in Section 4.7.2. 4.8.2. Receiver Behaviour If the Delegated Bandwidth Query Response message indicates Success (0x3), the following actions apply. 4.8.2.1. Behaviour at the NAS If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is less than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Delegated Bandwidth Query Response message. If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new value of delegated bandwidth. Alternatively, the NAS MAY force the AN to modify its view of the amount of delegated bandwidth to that held by the NAS, by sending a Port Management message for the target access line concerned, containing a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wishes to enforce. 4.8.2.2. Behaviour at the AN The AN SHOULD accept the value returned in the Bandwidth- Allocation TLV of the Delegated Bandwidth Query Response message as the correct value of the current amount of delegated bandwidth. If the AN has currently committed more than this amount to active programs, it MUST NOT cease replicating the flows concerned, but MUST NOT honour any more Join requests until possible to do so within the new limit. A race condition is possible, where the AN sends a query, the NAS requests more bandwidth, then receives and responds to the query, then receives the Bandwidth Transfer message responding to its request. It is up to the AN to take appropriate action in this case. The best action appears to be not to act on the result of the first query, but to repeat the query after sending the Bandwidth Transfer message. Similar considerations apply to a race between queries from both sides. Le Faucheur, et al. Expires April 29, 2010 [Page 34] Internet-Draft ANCP Multicast Extensions October 2009 4.9. Multicast Flow Query Request and Response Messages This section defines two new messages called the Multicast Flow Query Request and Multicast Flow Query Response. The Multicast Flow Query Request is sent by the NAS to request information about the multicast flows that are active on the AN. The Multicast Flow Query Response is sent in response by the AN to provide the requested information to the NAS. The Message Type for the Multicast Flow Query Request and Multicast Flow Query Response messages is 0x97. The contents of the Multicast Flow Query Request and Response depend on the nature of the query, as described below. 4.9.1. Sender Behaviour The sender of a Multicast Flow Query Request message MUST set the Result field to AckAll (0x2). The Code field MUST be set to 0x000. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in section 5.4.5 of [I-D.ietf-ancp- protocol]. The Multicast Flow Query Request MAY be used by the NAS to retrieve: o the AN's view of which multicast flows are currently active on a specified set of access ports; or o the AN's view of the access ports on which a specified set of multicast flows are currently active; or o the AN's view of all the multicast flows currently active on each and every port of the AN. To retrieve the AN's view of which multicast flows are currently active on one (or multiple) given port(s) of the AN, the Multicast Flow Query Request payload MUST contain the following TLVs: o Target TLV. It MUST appear at least once. Each occurence identifies one AN port for which information on active multicast flows is queried. It is encoded as specified in [I-D.ietf-ancp-protocol]. To retrieve the AN's view of which ports one (or multiple) given multicast flow(s) is (are) currently active on, the Multicast Flow Query Request payload MUST contain the following TLVs: Le Faucheur, et al. Expires April 29, 2010 [Page 35] Internet-Draft ANCP Multicast Extensions October 2009 o Multicast-Flow TLV. It MUST appear at least once. Each occurence identifies one multicast flow for which information is queried. It is encoded as specified in Section 5.10. To retrieve the AN's view of all the multicast flows currently active on each port of the AN, the Multicast Flow Query Request payload MUST NOT contain any instance of the Target TLV or the Multicast-Flow TLV. 4.9.2. Receiver Behaviour The AN MUST respond to a Multicast Flow Query Request message that has a valid format and a valid content with a Multicast Flow Query Response message. The Result field in the response MUST be set to Success (0x3). The Code field MUST be set to 0x000. The Transaction-Id field MUST be copied from the request. If the Multicast Flow Query Request contained one (or more) Target TLVs, the AN MUST include, for each of these Target TLVs, the following set of TLVs: o Target TLV. This MUST be identical to the Target TLV in the received Multicast Flow Query Request message. o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per multicast flow that is currently active on the AN port identified in the preceding Target TLV. The Target TLVs MUST appear in the response from the AN in the same order as in the query from the NAS. If the Multicast Flow Query Request contained one (or more) Multicast-Flow TLVs, the AN MUST include, for each of these Multicast-Flow TLVs, the following set of TLVs: o Multicast-Flow TLV.This MUST be identical to the Target TLV in the received Multicast Flow Query Request message. o Target TLV(s). The Target TLV MUST appear once per AN port on which the multicast flow identified in the preceding Multicast Flow TLV is active. The Multicast-Flow TLVs MUST appear in the response from the AN in the same order as in the query from the NAS. If the Multicast Flow Query Request contained no Target TLV and no Multicast Flow TLV, the AN MUST include, for each AN port, the following set of TLVs: Le Faucheur, et al. Expires April 29, 2010 [Page 36] Internet-Draft ANCP Multicast Extensions October 2009 o Target TLV. This MUST identify one AN port. o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per Multicast Flow that is currently active on the AN port identified in the preceding Target TLV. If the contents of the Multicast Flow Query Request are in error, the AN MUST reply with a Multicast Flow Query Response message with the Result field set to Failure (0x4) and the Code field set to indicate the nature of the error. If the request contained multiple instances of the Target TLV or the Multicast-Flow TLV and one of these is in error, the response message MUST contain the results for the preceding instances of the TLV as if there had been no error. These successful results MUST be followed by the TLV in error, copied from the request. The AN MUST NOT do further processing of the request. The AN MAY add a Status-Info TLV to provide further information on the nature of the error. Le Faucheur, et al. Expires April 29, 2010 [Page 37] Internet-Draft ANCP Multicast Extensions October 2009 5. ANCP TLVs and Sub-TLVs This section defines new ANCP TLVs and sub-TLVs or extends existing ones. 5.1. Multicast-Service-Profile TLV This document defines the new Multicast-Service-Profile TLV. The Multicast-Service-Profile TLV MAY be included in a Provisioning message as specified in Section 4.1. The Multicast-Service-Profile is illustrated in Figure 6. It consists of a TLV header, a Multicast-Service-Profile-Name sub-TLV, and one or more List-Action sub-TLVs. The sub-TLVs are packed consecutively with no intervening padding. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Mcast Service Profile | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast-Service-Profile-Name Sub-TLV | | Sub-TLV type = 0x01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List-Action Sub-TLV | | Sub-TLV type = 0x02 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List-Action Sub-TLV | | Sub-TLV type = 0x02 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Multicast-Servive-Profile TLV Multicast Service Profile TLV Type: TLV (0x13) : indicating that this is a Multicast Service Profile TLV The Multicast-Service-Profile-Name sub-TLV is shown in Figure 7. It consists of an eight-bit sub-TLV identifier with value 0x01, an eight-bit length field, and an identifier. The length field gives the length of the identifier in octets. The identifier consists of an opaque sequence of octets used to refer to the profile when Le Faucheur, et al. Expires April 29, 2010 [Page 38] Internet-Draft ANCP Multicast Extensions October 2009 activating it for a given target within a Port Management message (see Section 4.2). The identifier MUST be unique over all profiles provisioned to the same AN partition. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x01 | Length | Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Multicast-Service-Profile-Name sub-TLV The List-Action sub-TLV is shown in Figure 8. It consists of an eight-bit sub-TLV identifier with value 0x02, a four-bit action field, a four-bit list type field, a sixteen-bit length, and a sequence of multicast flow fields organized by address family. Either an IPv4 list or an IPv6 list or both MAY be present in the sub-TLV. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x02 | Oper | LType | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Version | List Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast flow fields | ...... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Version | List Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast flow fields | ...... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: List-Action Sub-TLV The fields within the List-Action TLV are defined as follows: Type: always 0x02. Oper: operation to be performed. The possible values are Add (0x1), Delete (0x2), or Replace (0x3). The operation indicates whether the listed multicast flows are to be added to the list identified by the list type field within the profile identified by the Multicast-Service-Profile-Name sub-TLV, deleted from that list, or whether the listed flows should replace the current contents of Le Faucheur, et al. Expires April 29, 2010 [Page 39] Internet-Draft ANCP Multicast Extensions October 2009 the identified list. Ltype: the list type being modified by this list action. The possible values are White (0x1), Black (0x2), or Grey (0x3). Length: the length (in octets) of the contents of the List-Action sub-TLV following the Length field itself. IP Version: the IP version of the set of multicast flow fields that follow. Possible values are 0x0000 (IPv4) or 0x0001 (IPv6). As indicated above, either an IPv4 list or an IPv6 list or both MAY be present in the sub-TLV. List length: the length (in octets) of the list of multicast flow fields following the list length field. Multicast flow field: a field identifying one or more multicast flows. It consists of an 8-bit group address prefix length, an 8-bit source address prefix length, a 0-16 octet group prefix, and a 0-16 octet source prefix, as shown in Figure 9. Each multicast flow field refers either to a Single Source Multicast (SSM) channel or to an Any Source Multicast (ASM) group. The scope of the designation may be broadened to multiple channels or groups through use of prefix length values smaller than the total address length for the given address family. Multicast flow fields MUST be placed consecutively within the sub-TLV without intervening padding except to round out individual addresses to the nearest octet boundary. A multicast flow field consists of two single-octet prefix lengths followed by zero to two prefix values as shown in Figure 9: +-+-+-+-+-+-+-+-+ | Group PrefLen | +-+-+-+-+-+-+-+-+ | Source PrefLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Prefix (multicast) (0 to 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Prefix (unicast, SSM only) (0 to 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Organization of a Single Multicast Flow Field The prefix length has its usual meaning. It is the number of most- significant bits specified within the corresponding prefix. The Le Faucheur, et al. Expires April 29, 2010 [Page 40] Internet-Draft ANCP Multicast Extensions October 2009 prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 to 128 in the IPv6 sub-list. A value of 0x00 for either the Group PrefLen (prefix length) or the Source PrefLen indicates that any value of the corresponding address will match (wild card). If the value 0x00 is provided for a particular prefix length, the corresponding prefix MUST be omitted from the field contents. In particular, a value of 0x00 for the Source PrefLen indicates an ASM multicast entry, and the Source Prefix will be absent. The length of a Source or Group Prefix field is equal to (PrefLen + 7)/8 octets, truncated to the nearest integer. Unused bits at the end of the prefix MUST be set to zeroes. 5.2. Command Number TLV The Command Number TLV conveys the sequence number of a specific command within a Multicast Replication Control or Multicast Admission Request message. Within this specification, the Command Number TLV itself is used as a sub-TLV within a Status-Info TLV, in a Generic Response reporting a failed command. The Command TLV has the format shown in Figure 10. The sequnce number field is the sequence number of a specific command within a request, where numbering starts from 1 for the first command. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Command Number | TLV Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Structure of the Command Number TLV 5.3. Bandwidth-Allocation TLV The Bandwidth-Allocation TLV is used to indicate the total amount of video bandwidth delegated to the AN for multicast admission control for a given access line, in kilobits per second. The TLV has the format shown in Figure 11. The TLV Type for the Bandwidth-Allocation TLV is 0x15. Le Faucheur, et al. Expires April 29, 2010 [Page 41] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = BW-Allocation | TLV Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delegated amount (kbits/s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: The Bandwidth-Allocation TLV 5.4. White-List-CAC TLV The White-List-CAC TLV is used to indicate that the NAS wishes the AN to do admission control for White-listed flows. Details on when the White-List-CAC TLV may be provisioned are specified in Section 6. The White-List-CAC TLV contains no data, thus its TLV Length field MUST have value 0. 5.5. MRepCtl-CAC TLV The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to do admission control for flows added by the Multicast Replication Control message. Details on when the MRepCtl-CAC TLV may be provisioned are specified in Section 6. The MRepCtl-CAC TLV contains no data, thus its TLV Length field MUST have value 0. 5.6. Bandwidth-Request TLV The Bandwidth-Request TLV is used to request an adjustment of the total amount of video bandwidth allocated to the AN for multicast admission control for a given line. The "Required amount" field indicates the minimum adjustment required to meet the request. The "Preferred amount" field indicates the adjustment the requestor would prefer to have, if possible. Section 4.5 discusses the required relationships between the "Required amount", "Preferred amount", and current values of total bandwidth allocated to the AN. The Bandwidth-Request TLV has the format shown in Figure 12. The TLV Type for the Bandwidth-Request TLV is 0x16. Le Faucheur, et al. Expires April 29, 2010 [Page 42] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = 0x16 | TLV Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required amount (kbits/s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred amount (kbits/s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: The Bandwidth-Request TLV 5.7. Multicast-Service-Profile-Name TLV The Multicast-Service-Profile-Name TLV carries the identifier of a multicast service profile provisioned on the AN. o Type (Multicast-Service-Profile-Name = 0x18): Reference to a multicast service profile on the AN, that defines a White, Black, and/or Grey List depending on the set of negotiated capabilities. o Length : (up to 255 octets) o Value : opaque sequence of octets identifying a specific profile. This MUST match one of the multicast service profile names provisioned on the AN in a Provisioning message or by other means. 5.8. Request-Source-IP sub-TLV [I-D.ietf-ancp-protocol] defines the Command TLV that can be used in a Multicast Replication Control message and (as defined in this document) in the Admission Control message. The Command TLV MAY include sub-TLVs immediately following the Command Info field. This document defines the new Request-Source-IP sub-TLV. The Request-Source-IP sub-TLV MAY be included in a Command TLV inside an Admission Control message. The Request-Source-IP sub-TLV is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Faucheur, et al. Expires April 29, 2010 [Page 43] Internet-Draft ANCP Multicast Extensions October 2009 Request-Source-IP sub-TLV Type: sub-TLV (0x92) indicating the contents to be a Request- Source-IP sub-TLV. Request-Source-IP sub-TLV Length: Combined length in bytes of the data inside sub-TLV. Excludes the sub-TLV Header. Address Family, Encoding type and Unicast Address: Contains the IP address of the sender of the join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the corresponding Command TLV in an Admission Control message. The IP address is encoded as per [IANAAEA]. 5.9. Request-Source-MAC sub-TLV This document defines the new Request-Source-MAC sub-TLV. The Request-Source-MAC sub-TLV MAY be included in a Command TLV inside an Admission Control message. The Request-Source-MAC sub-TLV is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-TLV Type=Request-Source-MAC |Request-S-MAC sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request-Source-MAC sub-TLV Type: sub-TLV (0x93) indicating the contents to be a Request- Source-MAC sub-TLV. Request-Source-MAC sub- TLV Length: Combined length in bytes of the data inside sub-TLV. Excludes the sub-TLV Header. TBD: Le Faucheur, et al. Expires April 29, 2010 [Page 44] Internet-Draft ANCP Multicast Extensions October 2009 Contains the IEEE MAC address of the sender of the join/ leave message (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the corresponding Command TLV in an Admission Control message. The IP address is encoded as per TBD. 5.10. Multicast-Flow TLV This document defines the new Multicast-Flow TLV. The Multicast-Flow TLV MAY be included in a Multicast Flow Query Request or Response message as specified in Section 4.9. The Multicast-Flow TLV is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Multicast-Flow | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Flow Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Flow Source Address (Cont'd) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Flow Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Flow Group Address (Cont'd) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Padding to 32-bit boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multicast-Flow TLV Multicast-Flow TLV Type: TLV (0x19) : indicating that this is a Multicast-Flow TLV Multicast-Flow TLV Length: Length in bytes of the Value field of the TLV. Excludes the TLV Header (Type and Length). Addr Family, Encoding Type, Multicast Flow Source Address, Multicast Flow Group Address and Padding are encoded as specified for the corresponding field of the Command TLV in Section 4.3. Le Faucheur, et al. Expires April 29, 2010 [Page 45] Internet-Draft ANCP Multicast Extensions October 2009 6. Multicast Capabilities Section 5.3 of [I-D.ietf-ancp-protocol] defines a capability negotiation mechanism as well as a number of capabilities. This section defines four new capabilities in support of different modes of multicast operation: o NAS-initiated replication (capability type 0x05); o conditional access with white and black lists (capability type 0x06); o conditional access with grey lists (capability type 0x07); o bandwidth delegation (capability type 0x08). The "Capability Data" field within the Capability TLV for all of these capabilities is empty. The remainder of this section consists of three sub-sections. Section 6.1 specifies the protocol elements that must be implemented in order to support each capability. Section 6.2 specifies the procedures that apply to each capability on its own. Section 6.3 specifies how the capabilities interact if more than one multicast capability is included in the set of capabilities negotiated between the AN and the NAS. Note that if a request contains content that is not supported (according to the tables in Section 6.1) by the negotiated set of multicast capabilities, the appropriate response is to return a Generic Response message indicating Failure (0x4) with an appropriate code value (e.g., 0x84 "TLV or value not supported by negotiated capability set"). The body of the message MUST contain a Status-Info TLV. See Sections 5.4.5.1 and 5.4.5.2 in [I-D.ietf-ancp-protocol] for more details. 6.1. Required Protocol Support This section specifies the protocol elements that must be implemented to support each of the four multicast capabilities. Support of multiple multicast capabilities requires implementation of the union of the sets of protocol elements applying to each of the individual capabilities in the supported set. 6.1.1. Protocol Requirements For NAS-initiated Replication Table 1 specifies the protocol elements within Section 4 and Section 5 that must be implemented to support the NAS-initiated Le Faucheur, et al. Expires April 29, 2010 [Page 46] Internet-Draft ANCP Multicast Extensions October 2009 replication multicast capability. +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.1 | Provisioning message with MRepCtl_CAC TLV | | | | | Section 4.2 | Port Management message with Bandwidth-Allocation | | | TLV. | | | | | Section 4.3 | Multicast Replication Control message | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.2 | Command Number TLV | | | | | Section 5.5 | MRepCtl-CAC TLV | | | | | Section 5.10 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 1: Protocol Support Requirements For NAS-initiated Replication 6.1.2. Protocol requirements For Conditional Access With White and Black Lists Table 2 specifies the protocol elements within Section 4 and Section 5 that must be implemented to support the conditional access with white and black lists multicast capability. Le Faucheur, et al. Expires April 29, 2010 [Page 47] Internet-Draft ANCP Multicast Extensions October 2009 +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.1 | Provisioning message with | | | Multicast-Service-Profile TLV, White and Black | | | lists only, and White-List-CAC TLV | | | | | Section 4.2 | Port Management message with | | | Multicast-Service-Profile-Name and | | | Bandwidth-Allocation TLVs. | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.1 | Multicast-Service-Profile TLV, White and Black | | | lists only | | | | | Section 5.3 | Bandwidth-Allocation TLV | | | | | Section 5.4 | White-List-CAC TLV | | | | | Section 5.7 | Multicast-Service-Profile-Name TLV | | | | | Section 5.10 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 2: Protocol Support Requirements For Conditional Access with White and Black Lists 6.1.3. Protocol requirements For Conditional Access With Grey Lists Table 3 specifies the protocol elements within Section 4 and Section 5 that must be implemented to support the conditional access with grey lists multicast capability. Le Faucheur, et al. Expires April 29, 2010 [Page 48] Internet-Draft ANCP Multicast Extensions October 2009 +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.1 | Provisioning message with | | | Multicast-Service-Profile TLV, Grey lists only, | | | and MRepCtl_CAC TLV | | | | | Section 4.2 | Port Management message with | | | Multicast-Service-Profile-Name and | | | Bandwidth-Allocation TLVs. | | | | | Section 4.3 | Multicast Replication Control message | | | | | Section 4.4 | Multicast Admission Control Message | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.1 | Multicast-Service-Profile TLV, Grey lists only | | | | | Section 5.2 | Command Number TLV | | | | | Section 5.3 | Bandwidth-Allocation TLV | | | | | Section 5.5 | MRepCtl-CAC TLV | | | | | Section 5.7 | Multicast-Service-Profile-Name TLV | | | | | Section 5.8 | Request-Source-IP sub-TLV | | | | | Section 5.9 | Request-Source-MAC sub-TLV | | | | | Section 5.10 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 3: Protocol Support Requirements For Conditional Access with Grey Lists 6.1.4. Protocol requirements For Delegated Bandwidth Table 4 specifies the protocol elements within Section 4 and Section 5 that must be implemented to support the delegated bandwidth multicast capability. Le Faucheur, et al. Expires April 29, 2010 [Page 49] Internet-Draft ANCP Multicast Extensions October 2009 +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.2 | Port Management message with Bandwidth-Allocation | | | TLV. | | | | | Section 4.5 | Bandwidth Reallocation Request Message | | | | | Section 4.6 | Bandwidth Transfer Message | | | | | Section 4.7 | Delegated Bandwidth Query Request Message | | | | | Section 4.8 | Delegated Bandwidth Query Response Message | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.3 | Bandwidth-Allocation TLV | | | | | Section 5.6 | Bandwidth-Request TLV | | | | | Section 5.10 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 4: Protocol Support Requirements For Delegated Bandwidth 6.2. Capability-Specific Procedures for Providing Multicast Service This section describes multicast service procedures for each capability as if it were the only multicast capability within the negotiated set. Procedures involving combinations of multicast capabilities are described in Section 6.3. The use of the Multicast Flow Query Request and Response messages to determine the association between multicast flows and ports is common to all multicast capabilities. No additional text is required here, beyond that already given in Section 4.9 to describe the use of those messages. 6.2.1. Procedures For NAS-initiated Replication NAS-initiated replication MAY be negotiated to support a mode of operation where IGMP/MLD requests are terminated on the NAS. Alternatively, it MAY be negotiated to allow the NAS to respond to requests sent by other means (e.g., through application signalling) that require the replication of multicast channels to a given access line. The NAS MAY enable admission control at the AN for Nas-initiated Le Faucheur, et al. Expires April 29, 2010 [Page 50] Internet-Draft ANCP Multicast Extensions October 2009 replication. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. It MUST also include a Bandwidth-Allocation TLV in a Port Management message for each access line. The procedures associated with NAS-initiated replication are straightforward. To initiate replication, the NAS MUST send a Multicast Replication Control message to the AN, containing one or more commands adding flows, as described in section ReplicSend. If it does admission control itself, it MUST set the R flag in the Add commands. If it has enabled admission control in the AN and wishes the AN to perform admission control for the flows, it MUST clear the R flag in the Command TLV requesting the flow addition. To terminate replication the NAS MUST send a a Multicast Replication Control message where the commands delete instead of adding them flows. 6.2.2. Procedures For Conditional Access With Black and White Lists 6.2.2.1. Provisioning The NAS provisions named multicast service profiles containing White and Black lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required, by sending additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing White and Black lists or replacements for them. The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast- Service-Profile-Name TLV. The NAS MAY choose to enable admission control at the AN for White- listed flows. To do this, it MUST send a Provisioning message as described in section provisioning, which includes the White-List-CAC TLV. It MUST also provide a multicast bandwidth allocation for each access line by including a Bandwidth-Allocation TLV in a Port Management message. 6.2.2.2. Multicast Service Procedures The conditional access with White and Black lists capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a "join" request, it MUST check to see whether the requested flow is White-listed or Black-listed as described below. Requests for Black-listed flows MUST be discarded. If the NAS has enabled admission control on the given access line as described in the previous section, but the flow would cause the amount of committed Le Faucheur, et al. Expires April 29, 2010 [Page 51] Internet-Draft ANCP Multicast Extensions October 2009 multicast bandwidth to exceed the provisioned limit, the request MUST be discarded. Flows passing these checks are replicated to the access line. To determine if a requested flow is White-listed, the AN searches for a best match to the flow in the applicable multicast service profile. Matching is done on the prefixes specified in the profile, ignoring the address bits of lower order than those in the prefix. If the requested multicast flow matches multiple lists associated with the access line, then the most specific match will be considered by the AN. If the most specific match occurs in multiple lists, the Black list entry takes precedence over the White list. In this context, the most specific match is defined as: o first, most specific match (longest prefix length) on the multicast flow address (i.e., on G of ) o then, most specific match (longest prefix length) on the multicast source address (i.e. on S of ) If the requested multicast flow is not part of any list, the join message SHOULD be discarded by the AN. This default behavior can easily be changed by means of a "catch-all" statement in the White list. For instance, adding () in the White List would make the default behavior to accept join messages for a multicast flow that has no other match on any list. When the AN receives a "leave" request, it terminates replication of the multicast flow. 6.2.3. Procedures For Conditional Access With Grey Lists 6.2.3.1. Provisioning The NAS provisions named multicast service profiles containing Grey lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required, by sending additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing Grey lists or replacements for them. The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast- Service-Profile-Name TLV. The NAS can enable admission control at the AN for Grey-listed flows. Le Faucheur, et al. Expires April 29, 2010 [Page 52] Internet-Draft ANCP Multicast Extensions October 2009 To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. It MUST also provide a Bandwidth-Allocation TLV in a Port Management message for each access line. 6.2.3.2. Multicast Service Procedures The conditional access with Grey lists capability assumes that IGMP/ MLD requests are terminated on the AN. When the AN receives a "join" request, it MUST determine whether there is a match to the requested flow in the Grey list of the multicast service profile provisioned against the given access line. If there is no match, the request is discarded. Otherwise, the AN MUST send a Multicast Admission Control message to the NAS with content identifying the access line and the multicast flow to be added. As indicated in Section 4.4, the AN MAY add information identifying the requestor by IP address and/or MAC address. If the NAS decides to enable the flow, it MUST send a Multicast Replication Control request to the AN to replicate the flow to the access line with the Result field set to Nack (0x1), as described in section ReplicSend. If admission control has been enabled at the AN for flows added by Multicast Replication Control messages, the NAS MAY invoke admission control for a specific flow at the AN by clearing the R flag in the Command TLV that adds the flow. When the AN receives the Multicast Replication Control request, it performs admission control if admission control has been enabled and invoked by the clearing of the R flag. If admitting the flow would cause the committed multicast bandwidth at the access line to exceed the provisioned limit, the AN reports an error to the NAS as described in section ReplicRecv. Otherwise it replicates the multicast flow as requested. If the NAS decides not to permit the flow, it MAY send a Multicast Replication Control message in response to the Multicast Admission Control message to allow the AN to update its internal records. The content of this message is described in Section 4.4.2. When the AN receives a "leave" request, it MUST terminate replication of the flow to the access line. It MUST then send a Multicast Admission Control message to the NAS indicating the deletion. The NAS updates its internal records but MUST NOT respond to the message. 6.2.4. Procedures For Delegated Bandwidth Le Faucheur, et al. Expires April 29, 2010 [Page 53] Internet-Draft ANCP Multicast Extensions October 2009 6.2.4.1. Provisioning The NAS SHOULD provision an initial amount of delegated multicast bandwidth for each access line using the Port Management message containing the Bandwidth-Allocation TLV. (If it fails to do so and a value has not been provisioned on the AN by other means, the AN will be forced to request a bandwidth allocation as soon as it receives a "join" request.) 6.2.4.2. Multicast Service Procedures The delegated bandwidth capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a "join" request, it checks whether it has sufficient remaining uncommitted multicast bandwidth on the access line to accommodate the new multicast flow. If not, it MAY send a request to the NAS for an increased allocation of delegated bandwidth, using the Bandwidth Reallocation Request message. The NAS MUST return a Bandwidth Transfer message indicating whether it has granted the request, and if so, what is the new amount of delegated bandwidth. If the AN has sufficient uncommitted multicast capacity to admit the request, either originally or as the result of a successful request to the NAS, it replicates the requested flow to the access line. Otherwise it discards the request. When the AN receives a "leave" request for an active flow, it ceases replication. The NAS or AN MAY at some point detect that their respective views of the amount of delegated bandwidth are inconsistent. If so, they can recover using procedures described in Section 4.5 and Section 4.6. As a further aid to synchronization, either the NAS or the AN MAY from time to time check the peer's view of the amount of delegated bandwidth using the Delegated Bandwidth Query message. The NAS or AN MAY at any time release bandwidth to the peer using an autonomous Bandwidth Transfer message. The contents of this message are described in Section 4.6. 6.3. Combinations of Multicast Capabilities 6.3.1. Combination of NAS-Initiated Replication with Other Capabilities NAS-initiated replication can coexist with the other capabilities, but some means must exist to prevent double replication of flows. The simplest way to do this is to terminate all IGMP/MLD requests on the AN, so that NAS-initiated replication is stimulated by signalling Le Faucheur, et al. Expires April 29, 2010 [Page 54] Internet-Draft ANCP Multicast Extensions October 2009 through other channels. Other arrangements are possible, but need not be discussed here. Assuming the necessary separation of responsibilities, the only point of interaction between NAS-initiated replication and the other multicast capabilities is in the area of admission control. Specifically, inclusion of the MRepCtl-CAC TLV in a Provisiong message enables admission control for flows added by Multicast Replication Control messages, regardless of whether they are part of NAS-initiated replication or Grey list multicast service processing. The NAS can control whether the AN does admission control for individual flows by its setting or clearing of the R flag in the Command TLV. It is up to the NAS to choose how video bandwidth will be allocated between itself and the AN, and to choose which allocation must support specific requests. 6.3.2. Conditional Access With White, Black, and Grey Lists If conditional access with White and Black lists is combined with conditional access with Grey lists, provisioning of the multicast service profiles is as described in Section 6.2.2.1 except that multicast service profiles will also include Grey lists. Admission control is enabled independently for White lists by including the White-list-CAC TLV in the Provisioning message and for Grey lists by including the MRepCtl-CAC TLV in the Provisioning message. The Bandwidth-Allocation TLV provisions an amount that applies to both White- and Grey- listed flows if admission control is enabled for both. With regard to multicast service procedures, one point of difference from the individual capabilities must be noted. This is an interaction during the profile matching procedure. The AN MUST seek the best match amongst multiple lists as described in Section 6.2.2.2. However, if there are multiple matches of equal precision, the order of priority is Black list first, Grey list second, and White list last. Once profile matching has been completed, processing of a "join" request is as described in Section 6.2.2.2 for White or Black listed flows or Section 6.2.3.2 for Grey listed flows. Requests that do not match any list SHOULD be discarded. When the AN receives a "leave" request, it MUST terminate replication of the flow to the access line. If the flow was Grey-listed, the AN MUST then send a Multicast Admission Control message to the NAS indicating the deletion. Thus the AN needs to retain the fact that the flow was Grey-listed for the life of the flow. Le Faucheur, et al. Expires April 29, 2010 [Page 55] Internet-Draft ANCP Multicast Extensions October 2009 6.3.3. Conditional Access Combined With Delegated Bandwidth If either or both conditional access capabilities are combined with the delegated bandwidth capability, the AN always does admission control. Delegated bandwith simply provides a means for flexible sharing of video bandwidth between the AN and the NAS or Policy Server. The provisioning, admission, and bandwidth management procedures of Section 6.2.4 apply in addition to the procedures in Section 6.2.2, Section 6.2.3, or Section 6.3.2 as applicable. Le Faucheur, et al. Expires April 29, 2010 [Page 56] Internet-Draft ANCP Multicast Extensions October 2009 7. Security Considerations The security considerations of ANCP are discussed in [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats]. Le Faucheur, et al. Expires April 29, 2010 [Page 57] Internet-Draft ANCP Multicast Extensions October 2009 8. IANA Considerations This document defines the following additional values within the GSMPv3 Message Type Name Space registry: +--------------------------------+--------+---------------+ | Message | Number | Source | +--------------------------------+--------+---------------+ | Multicast Replication Control | 90 | This document | | | | | | Multicast Status | 91 | This document | | | | | | Multicast Admission Control | 92 | This document | | | | | | Bandwidth Reallocation Request | 94 | This document | | | | | | Bandwidth Transfer | 95 | This document | | | | | | Delegated Bandwidth Query | 96 | This document | | | | | | Multicast Flow Query | 97 | This document | +--------------------------------+--------+---------------+ This document defines the following values for the ANCP Status-Info Result Code Registry : Le Faucheur, et al. Expires April 29, 2010 [Page 58] Internet-Draft ANCP Multicast Extensions October 2009 +----------------------------------------------+--------+-----------+ | Status | Number | Reference | +----------------------------------------------+--------+-----------+ | Command not supported | 0x02 | This | | | | document | | | | | | Flag set but not supported | 0x03 | This | | | | document | | | | | | Unsupported Address Family | 0x05 | This | | | | document | | | | | | Malformed flow address | 0x06 | This | | | | document | | | | | | Configuration error (such as Port not | 0x0a | This | | enabled for multicast) | | document | | | | | | Multicast flow does not exist | 0x0b | This | | | | document | | | | | | Unsupported address encoding | 0x0c | This | | | | document | | | | | | Additional info needed to execute command | 0x0d | This | | (payload MAY contain an indication of the | | document | | expected info) | | | | | | | | Multicast flow count exceeded | 0x0e | This | | | | document | | | | | | M Flag set, but no IP Source address | 0x0f | This | | provided | | document | | | | | | Invalid preferred bandwidth amount | 0x11 | This | | | | document | | | | | | bandwidth delegation not activated | 0x12 | This | | | | document | | | | | | Delegated bandwidth reset required | 0x13 | This | | | | document | +----------------------------------------------+--------+-----------+ This document defines the following additional values within the ANCP TLV Type Registry: Le Faucheur, et al. Expires April 29, 2010 [Page 59] Internet-Draft ANCP Multicast Extensions October 2009 +--------------------------------+-----------+---------------+ | TLV Name | Type Code | Reference | +--------------------------------+-----------+---------------+ | Multicast-Service-Profile | 0x13 | This document | | | | | | Bandwidth-Delegation-Control | 0x14 | This document | | | | | | Bandwidth-Allocation | 0x15 | This document | | | | | | Bandwidth-Request | 0x16 | This document | | | | | | Bandwidth-Status | 0x17 | This document | | | | | | Multicast-Service-Profile-Name | 0x18 | This document | | | | | | Multicast-Flow | 0x19 | This document | +--------------------------------+-----------+---------------+ This document defines the following values for the ANCP Command Code registry: +-------------------------------------+----------------+------------+ | Command Code Directive Name | Command Code | Reference | | | Value | | +-------------------------------------+----------------+------------+ | Add | 0x01 | This | | | | document | | | | | | Delete | 0x02 | This | | | | document | | | | | | Delete All | 0x03 | This | | | | document | | | | | | Admission Control Reject | 0x04 | This | | | | document | | | | | | Conditional Access Reject | 0x05 | This | | | | document | | | | | | Admission Control and Conditional | 0x06 | This | | Access Reject | | document | +-------------------------------------+----------------+------------+ This document defines the following additional values to the ANCP sub-TLV Type registry: Le Faucheur, et al. Expires April 29, 2010 [Page 60] Internet-Draft ANCP Multicast Extensions October 2009 +--------------------+-----------+---------------+ | sub-TLV Name | Type Code | Reference | +--------------------+-----------+---------------+ | Request-Source-IP | 0x92 | This document | | | | | | Request-Source-MAC | 0x93 | This document | +--------------------+-----------+---------------+ Le Faucheur, et al. Expires April 29, 2010 [Page 61] Internet-Draft ANCP Multicast Extensions October 2009 9. Acknowledgements The authors would like to acknowledge Wojciech Dec for providing useful input to this document, Robert Rennison for his help in shaping the definition of the Multicast-Service-Profile TLV, Shridhar Rao for his comments and suggestions and Aniruddha A for his proposal that formed the base of the Multicast Flow Reporting solution. Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided substantial contributions on the solution for the NAS initiated multicast control use case. Le Faucheur, et al. Expires April 29, 2010 [Page 62] Internet-Draft ANCP Multicast Extensions October 2009 10. References 10.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-12 (work in progress), October 2009. [I-D.ietf-ancp-protocol] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, N., and R. Maglione, "Protocol for Access Node Control Mechanism in Broadband Networks", draft-ietf-ancp-protocol-07 (work in progress), October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 10.2. Informative References [I-D.ietf-ancp-security-threats] Moustafa, H., Tschofenig, H., and S. Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", draft-ietf-ancp-security-threats-08 (work in progress), July 2009. [I-D.morin-mboned-igmpmld-error-feedback] Morin, T. and B. Haberman, "IGMP/MLD Error Feedback", draft-morin-mboned-igmpmld-error-feedback-02 (work in progress), November 2008. [IANAAEA] "http://www.iana.org/assignments/address-family-numbers", 2005. Le Faucheur, et al. Expires April 29, 2010 [Page 63] Internet-Draft ANCP Multicast Extensions October 2009 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. Le Faucheur, et al. Expires April 29, 2010 [Page 64] Internet-Draft ANCP Multicast Extensions October 2009 Appendix A. Example of Messages and Message Flows This section provides example message flows. A.1. Multicast Conditional Access and CAC without AN bandwidth delegation This section describes ANCP operations when multicast flows are subject to multicast Conditional Access and Admission Control without bandwidth delegation. A.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 Service Profile Name". To indicate to the AN that it need not perform any CAC operation on those flows, the Provisioning message also conveys an indication that bandwidth delegation is to be deactivated. The corresponding message flow is illustrated in Figure 13. +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | |(M1) Provisioning | | | | (Mcast S Prof name, | | | | White List, | | | | Grey List, | | | | Black List, | | | | Bw Del Deactivated) | | | |<--------------------| Figure 13: Provisioning AN with White/Grey/Black Lists for Conditional Access The Provisioning message M1 contains: o an ANCP Header with: * Message-Type = 93 - Provisioning * Result= 0x00 * Transaction-ID = Transaction-ID maintained by NAS Le Faucheur, et al. Expires April 29, 2010 [Page 65] Internet-Draft ANCP Multicast Extensions October 2009 o a Multicast-Service-Profile TLV containing: * a Multicast-Service-Profile-Name sub-TLV * an Empty White-List in our example (and hence no White-List sub-TLV) * a Grey-List sub-TLV containing a catch-all entry for IPv4 (in our example) * an Empty Black-List in our example (and hence no Black-List sub-TLV) The Provisioning message M1 is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=93 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0008 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Type = 0x0001 | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Multicast service profile name ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP ver = 0x00 | List length = 0x02 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grp PLen=0x00 | Src PLen=0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 Le Faucheur, et al. Expires April 29, 2010 [Page 66] Internet-Draft ANCP Multicast Extensions October 2009 A.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 Service Profile Name to be associated to that Port. The corresponding message flow is illustrated in Figure 15. +----------+ +---------+ +-----+ +-----+ |Subscriber| | Home | | AN | | NAS | +----------+ | Gateway | +-----+ +-----+ | +---------+ | | | | | | | | | | | | DSL Synch. | | | |--------------------->| | | | |(M1)PORT_UP(Port ID) | | | |-------------------->| | | | (*) | | |(M2) PORT_MNGT | | | | (Port ID, | | | |Mcast S Profile Name)| | | |<--------------------| (*) The NAS may optionally seek direction from an external Autorization/Policy Server Figure 15: Associating Profile ID to AN Port A.1.3. Successful Join/Leave Operations The message flows in Figure 16 illustrates the ANCP message flow in case of a simple join and leave for a multicast flow that matches the grey list and when the "bandwidth delegation" mechanism is not activated in the AN. In that case the AN queries the NAS that performs Conditional Access and Admission Control. Le Faucheur, et al. Expires April 29, 2010 [Page 67] Internet-Draft ANCP Multicast Extensions October 2009 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | Join(Grey-Fl) | Admission | |-----------+---------->| Control (M1) | | | |------------------>| | | | | | | | Multicast | | | | Replication (*) | | | Control (M2) | | Mcast Grey Flow |<------------------| |<======================+ | | | | | ~ ~ ~ ~ | | | | | Leave(Grey-Fl) | Admission | |-----------+---------->| Control (M3) | | | |------------------>| | | | | Grey-Fl : Multicast Flow matching an entry in Grey List (bandwidth delegation not activated on AN) (*) The NAS may optionally seek direction from an external Autorization/Policy Server Figure 16: Successful Join/Leave Operations The Multicast Admission Control message M1 contains: o an ANCP Header with: * Message-Type = 92 - Multicast Admission Control * Result= 0x00 * Transaction-ID = Transaction-ID maintained by AN o a Target TLV identifying the AN Port o a Command TLV containing: * a Command Code = Add Le Faucheur, et al. Expires April 29, 2010 [Page 68] Internet-Draft ANCP Multicast Extensions October 2009 * R = 0 * O = 0 * the multicast flow for which the IGMP Join was received by AN= (192.0.2.1, 233.252.2.2) * a Request-Source-IP sub-TLV containing the IGMP join source IP (192.0.2.100). The Multicast Admission Control message M1 is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=92 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xTBD (Command) TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x01 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ The Multicast Replication Control message M2 contains: Le Faucheur, et al. Expires April 29, 2010 [Page 69] Internet-Draft ANCP Multicast Extensions October 2009 o an ANCP Header with: * Message-Type = 90 - Multicast Replication Control * Result= 0x00 * Transaction-ID = Transaction-ID maintained by NAS o a Target TLV identifying the AN Port o a Command TLV containing: * a Command Code = Add * R= 1 (since in our example the flow resources have been admitted by NAS) * O = 0 (since in our example flow accounting is not required) * the multicast flow for which the IGMP Join was received by AN= (192.0.2.1, 233.252.2.2) * a Request-Source-IP sub-TLV containing the IGMP join source IP (192.0.2.100). The Multicast Admission Control message M2 is illustrated below: Le Faucheur, et al. Expires April 29, 2010 [Page 70] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=90 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0009 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xTBD (Command) TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x01 |1 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ The Multicast Admission Control message M3 contains: o an ANCP Header with: * Message-Type = 92 - Multicast Admission Control * Result= 0x00 * Transaction-ID = Transaction-ID maintained by AN o a Target TLV identifying the AN Port o a Command TLV containing: Le Faucheur, et al. Expires April 29, 2010 [Page 71] Internet-Draft ANCP Multicast Extensions October 2009 * a Command Code = Delete * R = 0 * O = 0 * the multicast flow for which the IGMP leave was received by AN= (192.0.2.1, 233.252.2.2) * a Request-Source-IP sub-TLV containing the IGMP join source IP (192.0.2.100). The Multicast Admission Control message M3 is illustrated below: Le Faucheur, et al. Expires April 29, 2010 [Page 72] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=92 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0002 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xTBD (Command) TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x02 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ |Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ A.1.4. Admission Control Reject without NAS Response The message flow in Figure 17 illustrates the ANCP message flow in case of a join that is rejected by the NAS because of admission control and without explicit response from the NAS. In that case, the multicast flow is never replicated simply by virtue of the NAS not requesting replication. Le Faucheur, et al. Expires April 29, 2010 [Page 73] Internet-Draft ANCP Multicast Extensions October 2009 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | Join(Grey-Fl) | Admission | |-----------+---------->| Control (M1) | | | |------------------>| | | | | | | | (*) | | | | | Mcast Grey Flow | | | not replicated x | | | | | Grey-Fl : Multicast Flow matching an entry in Grey List (bandwidth delegation not activated on AN) (*) The NAS may optionally seek direction from an external Autorization/Policy Server Figure 17: Admission Control Reject without NAS Response The Multicast Admission Control message M1 contains: o an ANCP Header with: * Message-Type = 92 - Multicast Admission Control * Result= 0x00 * Transaction-ID = Transaction-ID maintained by AN o a Target TLV identifying the AN Port o a Command TLV containing: * a Command Code = Add * R = 0 * O = 0 * the multicast flow for which the IGMP join was received by AN= (192.0.2.1, 233.252.2.3). Le Faucheur, et al. Expires April 29, 2010 [Page 74] Internet-Draft ANCP Multicast Extensions October 2009 * a Request-Source-IP sub-TLV containing the IGMP join source IP (192.0.2.100). The Multicast Admission Control message M1 is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=92 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xTBD (Command) TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x01 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ A.1.5. Admission Control Reject with NAS Response The message flow in Figure 18 illustrates the ANCP message flow in case of a join that is rejected by the NAS because of admission control and with explicit response from the NAS. In that case, the multicast flow is not replicated by virtue of the NAS explicitely signaling to the AN that the multicast flow is not to be replicated. Le Faucheur, et al. Expires April 29, 2010 [Page 75] Internet-Draft ANCP Multicast Extensions October 2009 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | Join(Grey-Fl) | Admission | |-----------+---------->| Control (M1) | | | |------------------>| | | | | | | | Multicast (*) | | | Replication | | | | Control (M2) | | Mcast Grey Flow |<------------------| | not replicated x | | | | | Grey-Fl : Multicast Flow matching an entry in Grey List (bandwidth delegation not activated on AN) (*) The NAS may optionally seek direction from an external Autorization/Policy Server Figure 18: Admission Control Reject with NAS Response The Multicast Admission Control message M1 contains: o an ANCP Header with: * Message-Type = 92 - Multicast Admission Control * Result= 0x00 * Transaction-ID = Transaction-ID maintained by AN o a Target TLV identifying the AN Port o a Command TLV containing: * a Command Code = Add * R = 0 * O = 0 * the multicast flow for which the IGMP join was received by AN= (192.0.2.1, 233.252.2.4). Le Faucheur, et al. Expires April 29, 2010 [Page 76] Internet-Draft ANCP Multicast Extensions October 2009 * a Request-Source-IP sub-TLV containing the IGMP join source IP (192.0.2.100). The Multicast Admission Control message M1 is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=92 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0004 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xTBD (Command) TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x01 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ The Multicast Replication Control message M2 contains: o an ANCP Header with: * Message-Type = 90 - Multicast Replication Control * Result= 0x00 * Transaction-ID = Transaction-ID maintained by NAS Le Faucheur, et al. Expires April 29, 2010 [Page 77] Internet-Draft ANCP Multicast Extensions October 2009 o a Target TLV identifying the AN Port o a Command TLV containing: * a Command Code = Admission Control Reject (since in our example the flow is rejected by NAS because of bandwidth admission control and not because of conditional access) * R= 0 (since in our example the flow resources have not been admitted by NAS) * O = 0 (since in our example flow accounting is not required) * the multicast flow (192.0.2.1, 233.252.2.4) * a Request-Source-IP sub-TLV containing the IGMP join source IP (192.0.2.100). The Multicast Admission Control message M2 is illustrated below: Le Faucheur, et al. Expires April 29, 2010 [Page 78] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=90 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0010 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xTBD (Command) TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0xTBD|0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ A.2. Example Flows For bandwidth delegation As noted in TBD, the operation of bandwidth delegation is supplemental to the operation of request processing in the absence of bandwidth delegation. Thus the same flows shown in the previous section continue to hold, except that the AN does multicast call admission before doing grey and white list processing. The example flows of this section are therefore limited to the incremental operations of bandwidth delegation. They include initial provisioning, a successful request from the AN for an increase in total multicast bandwidth, an autonomous transfer of the borrowed bandwidth back to the NAS, and the initiation of the bandwidth reset procedure [text to be modified] by the NAS when it finds that the amount of total multicast bandwidth passed by the AN is larger than its current view of that amount. Le Faucheur, et al. Expires April 29, 2010 [Page 79] Internet-Draft ANCP Multicast Extensions October 2009 A.2.1. Activation and Provisioning of total multicast Bandwidth Activation of bandwidth delegation occurs at the level of the AN as a whole and is done by including a Bandwidth-Delegation-Control TLV in the Provisioning message with the E-flag set to 1. The message flow is as shown in Figure 13. In place of Figure 14 we have the following content within the Provisioning message: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=93 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0008 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Type = 0x0001 | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Multicast service profile name ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP ver = 0x00 | List length = 0x02 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Grp PLen=0x00 | Src PLen=0x00 | Padding = 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Band-Del-Control | TLV Length = 0x04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Reserved = 0x00 | Reserved = 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19 Once bandwidth delegation has been activated, the NAS must provision the amount of total multicast bandwidth for each access line (unless it is pre-configured on the AN). This requires a Port Management message with a Bandwidth-Allocation TLV. The same Port Management message may be used to provision other information, such as the multicast service profile name applicable to the access line. The information flow is therefore similar to that in Figure 15. In the following figure, an initial allocation of 8000 kbits/s is provided. Le Faucheur, et al. Expires April 29, 2010 [Page 80] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Msg Type = 32 |Rslt =1| Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|x|x|x|x|x|x|x| Duration | Func = 8 | X-Func = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Flags | Flow Control Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type = 5 | Block Len = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of TLVs = 2 | Ext Block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = 0x01 | Access-Loop-Cct-ID length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access-Loop-Circuit-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Bandwidth-Alloc | TLV length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delegated amount = 8000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: Port Management Message Allocating total multicast Bandwidth A.2.2. Successful Request For More Multicast Bandwidth Suppose that the AN allocates all 8000 kbits/s of its total multicast amount and receives a Join request requiring another 2000 kbits/s. The AN issues a Bandwidth Reallocation Request message where the required amount field is set to acquire this amount of additional bandwidth. Since the request is framed in terms of total total multicast bandwidth, required amount is 10000 kbits/s. Suppose that the AN is configured with a policy that causes it to request enough for one additional channel as a preferred amount. Hence the preferred amount is set to 12000 kbits/s. The Bandwidth Reallocation Le Faucheur, et al. Expires April 29, 2010 [Page 81] Internet-Draft ANCP Multicast Extensions October 2009 Request message has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | MsgTyp = 94 |Rslt=0 | Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Target | Target-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Bandwidth-Request | TLV Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required amount = 10000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred amount = 12000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: Example Bandwidth Reallocation Request Message In response to this request, the NAS is willing to grant the full preferred amount. (It could have granted any value between 10000 and 12000, or it could have rejected the request.) The Bandwidth Transfer message sent as a response indicates that the new total multicast bandwidth amount is 12000 kbits/s, as shown in the next figure. Le Faucheur, et al. Expires April 29, 2010 [Page 82] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | MsgTyp = 95 |Rslt=3 | Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Target | Target-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Bandwidth-Alloc | TLV Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delegated amount = 12000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: Example Bandwidth Transfer Message (Success Response) A.2.3. Failed Autonomous Transfer With Reset Suppose the AN decides after an interval that it should return 2000 kbits/s of the 4000 kbits/s that it acquired from the NAS in the previous transaction. It therefore issues a Bandwidth Transfer message of its own. This message differs from the message in Figure 22 in two ways. First, because this is an autonomous transfer rather than a response, the Result field in the header is set to Ignore (0x0). Secondly, the Delegated amount is reduced to 10000 kbits/s. Now suppose that somehow the NAS forgot that it passed an additional 4000 kbits/s to the AN. Thus its current view of the amount of total multicast bandwidth is 8000 kbits/s. The 10000 kbits/s appearing in the Bandwidth Transfer message is higher than this, so there is clearly a disgareement between the NAS and the AN. The NAS chooses to initiate the reset procedure, perhaps because it is close to committing all of its available video bandwidth for unicast service. As the initial step in this procedure, it issues a Multicast Status message indicating that a reset of the total multicast amount is required. This is shown in the following figure. Le Faucheur, et al. Expires April 29, 2010 [Page 83] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=91 | 0x4 | Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status-info-TLV=TBD | Status-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Rslt Code = xx | Cmd No = 1 | Error Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (padded to 4) if Length > 0 | +---------------------------------------------------------------+ | TLV Type = Target | Target-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Bandwidth-Alloc | TLV Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delegated amount = 8000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code field within the Status-Info TLV contains the value: total multicast bandwidth reset required (0xTBD). Figure 23: Example Initiation of Multicast Bandwidth Reset The NAS stops processing video service requests for the given access line when it sends this message. Similarly, the AN stops processing multicast video service requests when it receives the message. [To think about: can service requests that release bandwidth be safely processed? Probably.] The next step is up to the NAS: it sends a bandwidth delegation Query Request message to the AN. The Result field in the header is set to Ignore (0x0) as usual for multicast- related messages. The Target TLV is a copy of the one received in the original Bandwidth Transfer message. The message is shown in the following figure: Le Faucheur, et al. Expires April 29, 2010 [Page 84] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | MsgTyp = 96 |Rslt=0 | Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Target | Target-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 24: Example Delegated Bandwidth Query Request Message The AN returns a Delegated Bandwidth Query Response message showing that it believes that the amount of total multicast bandwidth is 10000 kbits/s and it has committed 8000 kbits/s of it. The Result field in the header shows Success (0x3) to distinguish the response. [... in case we decide to make the query bidirectional ...] Le Faucheur, et al. Expires April 29, 2010 [Page 85] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | MsgTyp = 96 |Rslt=3 | Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Target | Target-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Bandwidth-Request | TLV Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delegated amount = 10000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed amount = 8000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: Example Delegated Bandwidth Query Response Message The NAS decides to reset the total multicast bandwidth amount to 8000 kbits/s. It issues a Port Management message looking exactly like the one in Figure 20. Once it sends this message, it resumes processing service requests for the access line concerned. Similarly, the AN resumes request processing after it receives the Port Management message and resets its view of the current total multicast bandwidth. In the short run, this means that it will have to ask for more bandwidth if it receives another Join request. [It seems reasonable that the AN would not do so for a period of time after a reset or a response to a Bandwidth Reallocation Request that grants less than the preferred amount. Should we establish a timer?] A.3. Example Flows For Multicast Flow Reporting A.3.1. Per Port Multicast Flow Reporting Figure 26 illustrate a message flow in the case where the NAS queries the AN about which multicast flow is active on port 10, on port 20 and on port 11 of the AN. Le Faucheur, et al. Expires April 29, 2010 [Page 86] Internet-Draft ANCP Multicast Extensions October 2009 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<---------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | Multicast Flow | | | | Query Request | | | | (M1) | | | |<------------------| | | | | | | | Multicast Flow | | | | Query Response | | | | (M2) | | | |------------------>| | | | | | | | | Figure 26: Per Port Multicast Flow Reporting The Multicast Flow Query Request message (M1) is illustrated in Figure 27. Le Faucheur, et al. Expires April 29, 2010 [Page 87] Internet-Draft ANCP Multicast Extensions October 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID (port10) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID (port20) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID (port11) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: Multicast Flow Query Request message for per-port Mulicast Flow Reporting The Multicast Flow Query Response message (M2) is illustrated in Figure 28. It indicates that there is one active multicast flow [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and (192.0.2.2, 233.252.2.10)] on port 11. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | Le Faucheur, et al. Expires April 29, 2010 [Page 88] Internet-Draft ANCP Multicast Extensions October 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID (port10) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID (port20) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID (port11) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ Le Faucheur, et al. Expires April 29, 2010 [Page 89] Internet-Draft ANCP Multicast Extensions October 2009 Figure 28: Multicast Flow Query Response message for per-port Mulicast Flow Reporting Le Faucheur, et al. Expires April 29, 2010 [Page 90] Internet-Draft ANCP Multicast Extensions October 2009 Authors' Addresses 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 Roberta Maglione Telecom Italia Via Reiss Romoli 274 Torino 10148 Italy Phone: Email: roberta.maglione@telecomitalia.it Tom Taylor Huawei Technologies 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Phone: +1 613 680 2675 Email: tom111.taylor@bell.net Le Faucheur, et al. Expires April 29, 2010 [Page 91]