Skip to main content

Multicast Control Extensions for ANCP
draft-ietf-ancp-mc-extensions-10

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7256.
Authors François Le Faucheur , Roberta Maglione , Tom Taylor
Last updated 2013-11-11 (Latest revision 2013-08-21)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Matthew Bocci
IESG IESG state Became RFC 7256 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ancp-mc-extensions-10
ANCP                                                      F. Le Faucheur
Internet-Draft                                                     Cisco
Intended status: Standards Track                             R. Maglione
Expires: February 23, 2014                                 Cisco Systems
                                                               T. Taylor
                                                                  Huawei
                                                         August 22, 2013

                 Multicast Control Extensions for ANCP
                  draft-ietf-ancp-mc-extensions-10.txt

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 and one
   additional use case described in this document.  These 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;

   o  committed bandwidth reporting.

   These capabilities may be combined according to the rules given in
   this specification.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

Le Faucheur, et al.     Expires February 23, 2014               [Page 1]
Internet-Draft          ANCP Multicast Extensions            August 2013

   This Internet-Draft will expire on February 23, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Multicast Use Cases . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  NAS Initiated Multicast Replication Control Use Case  . .   7
       3.1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  Message Flow  . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Conditional Access and Admission Control Use Case . . . .   8
       3.2.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.2.  Message Flow  . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Multicast Flow Reporting Use Case . . . . . . . . . . . .   9
       3.3.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.3.2.  Message Flow  . . . . . . . . . . . . . . . . . . . .   9
     3.4.  Committed Bandwidth Reporting Use Case  . . . . . . . . .  10
       3.4.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.4.2.  Message Flow  . . . . . . . . . . . . . . . . . . . .  10
   4.  ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Provisioning Message  . . . . . . . . . . . . . . . . . .  11

Le Faucheur, et al.     Expires February 23, 2014               [Page 2]
Internet-Draft          ANCP Multicast Extensions            August 2013

       4.1.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  12
       4.1.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  13
     4.2.  Port Management Message . . . . . . . . . . . . . . . . .  14
       4.2.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  15
       4.2.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  15
     4.3.  Multicast Replication Control Message . . . . . . . . . .  16
       4.3.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  19
       4.3.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  20
     4.4.  Multicast Admission Control Message . . . . . . . . . . .  22
       4.4.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  23
       4.4.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  24
     4.5.  Bandwidth Reallocation Request Message  . . . . . . . . .  25
       4.5.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  25
       4.5.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  26
     4.6.  Bandwidth Transfer Message  . . . . . . . . . . . . . . .  29
       4.6.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  30
       4.6.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  30
     4.7.  Delegated Bandwidth Query Request Message . . . . . . . .  31
       4.7.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  31
       4.7.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  31
     4.8.  Delegated Bandwidth Query Response Message  . . . . . . .  32
       4.8.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  32
       4.8.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  32
     4.9.  Multicast Flow Query Request and Response Messages  . . .  33
       4.9.1.  Sender Behaviour  . . . . . . . . . . . . . . . . . .  34
       4.9.2.  Receiver Behaviour  . . . . . . . . . . . . . . . . .  34
     4.10. Committed Bandwidth Report Message  . . . . . . . . . . .  36
       4.10.1.  Sender Behaviour . . . . . . . . . . . . . . . . . .  36
       4.10.2.  Receiver Behaviour . . . . . . . . . . . . . . . . .  36
   5.  ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . .  37
     5.1.  Multicast-Service-Profile TLV . . . . . . . . . . . . . .  37
     5.2.  Multicast-Service-Profile-Name TLV  . . . . . . . . . . .  38
     5.3.  List-Action TLV . . . . . . . . . . . . . . . . . . . . .  39
     5.4.  Sequence-Number TLV . . . . . . . . . . . . . . . . . . .  41
     5.5.  Bandwidth-Allocation TLV  . . . . . . . . . . . . . . . .  42
     5.6.  White-List-CAC TLV  . . . . . . . . . . . . . . . . . . .  42
     5.7.  MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . .  43
     5.8.  Bandwidth-Request TLV . . . . . . . . . . . . . . . . . .  43
     5.9.  Request-Source-IP TLV . . . . . . . . . . . . . . . . . .  44
     5.10. Request-Source-MAC TLV  . . . . . . . . . . . . . . . . .  44
     5.11. Multicast-Flow TLV  . . . . . . . . . . . . . . . . . . .  45
     5.12. Report-Buffering-Time TLV . . . . . . . . . . . . . . . .  46
     5.13. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . .  47
   6.  Multicast Capabilities  . . . . . . . . . . . . . . . . . . .  47
     6.1.  Required Protocol Support . . . . . . . . . . . . . . . .  48
       6.1.1.  Protocol Requirements For NAS-Initiated Replication .  48
       6.1.2.  Protocol Requirements For Committed Multicast
               Bandwidth Reporting . . . . . . . . . . . . . . . . .  49

Le Faucheur, et al.     Expires February 23, 2014               [Page 3]
Internet-Draft          ANCP Multicast Extensions            August 2013

       6.1.3.  Protocol Requirements For Conditional Access With
               White and Black Lists . . . . . . . . . . . . . . . .  50
       6.1.4.  Protocol Requirements For Conditional Access With
               Grey Lists  . . . . . . . . . . . . . . . . . . . . .  50
       6.1.5.  Protocol Requirements For Delegated Bandwidth . . . .  52
     6.2.  Capability-Specific Procedures for Providing Multicast
           Service . . . . . . . . . . . . . . . . . . . . . . . . .  52
       6.2.1.  Procedures For NAS-Initiated Replication  . . . . . .  52
       6.2.2.  Procedures For Committed Bandwidth Reporting  . . . .  53
       6.2.3.  Procedures For Conditional Access With Black and
               White Lists . . . . . . . . . . . . . . . . . . . . .  54
       6.2.4.  Procedures For Conditional Access With Grey Lists . .  56
       6.2.5.  Procedures For Delegated Bandwidth  . . . . . . . . .  57
     6.3.  Combinations of Multicast Capabilities  . . . . . . . . .  58
       6.3.1.  Combination of Conditional Access With White and
               Black Lists and Conditional Access With Grey Lists  .  58
       6.3.2.  Combination of Conditional Access With Delegated
               Bandwidth . . . . . . . . . . . . . . . . . . . . . .  60
       6.3.3.  Combination of NAS-Initiated Replication with Other
               Capabilities  . . . . . . . . . . . . . . . . . . . .  60
       6.3.4.  Combinations of Committed Bandwidth Reporting with
               Other Multicast Capabilities  . . . . . . . . . . . .  61
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  61
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  61
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  64
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  64
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  64
     10.2.  Informative References . . . . . . . . . . . . . . . . .  64
   Appendix A.  Example of Messages and Message Flows  . . . . . . .  65
     A.1.  Provisioning Phase  . . . . . . . . . . . . . . . . . . .  66
     A.2.  Handling a Grey-Listed Flow . . . . . . . . . . . . . . .  70
     A.3.  Handling White-Listed Flows . . . . . . . . . . . . . . .  75
     A.4.  Handling Of Black-Listed Join Requests  . . . . . . . . .  79
     A.5.  Handling Of Requests To Join and Leave the On-Line Game .  80
     A.6.  Example Flow For Multicast Flow Reporting . . . . . . . .  82
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  85

1.  Introduction

   [RFC5851] 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.  [RFC6320]
   specifies a protocol for Access Node Control in broadband networks in
   line with this framework.

Le Faucheur, et al.     Expires February 23, 2014               [Page 4]
Internet-Draft          ANCP Multicast Extensions            August 2013

   [RFC6320] supports three use cases defined in [RFC5851], specifically
   for DSL access: the DSL Topology Discovery use case, the DSL Line
   Configuration use case and the DSL Remote Connectivity Test use case.
   However, it does not support the multicast use cases defined in
   [RFC5851].  The present document specifies the extensions to the
   Access Node Control Protocol required for support of these multicast
   use cases.  In addition, it supports the Committed Bandwidth
   Reporting use case, described below.  In terms of the ANCP protocol,
   these use cases are organized into five capabilities:

   o  NAS-initiated multicast replication;

   o  conditional access with white and black lists;

   o  conditional access with grey lists;

   o  bandwidth delegation;

   o  committed bandwidth reporting.

   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 [RFC5851].

   Conditional access is described in Sections 3.4.1 and 3.4.2.3 of
   [RFC5851], 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.

   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.

   Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851].
   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

Le Faucheur, et al.     Expires February 23, 2014               [Page 5]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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.

   Committed bandwidth reporting is described below, in Section 3.4.
   The AN reports the amount of multicast bandwidth it has granted to a
   given access line each time that value changes.  These reports may be
   buffered for a NAS-provisionable interval so that reports for
   multiple access lines can be bundled into the same message.

   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 [RFC5851].  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.

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".

3.  Multicast Use Cases

   Quoting from [RFC5851]:

   "... 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

Le Faucheur, et al.     Expires February 23, 2014               [Page 6]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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."

   [RFC5851] 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 [RFC5851] 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.

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).  In the example message
   flow, 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|     +-----+                      +-----+
         |         +-------+         |                           |
         |            |              |                          (*)

Le Faucheur, et al.     Expires February 23, 2014               [Page 7]
Internet-Draft          ANCP Multicast Extensions            August 2013

         |            |              | Multicast-Replication-Crl |
         |            |              |   (Target,add, Flow 1)    |
         |            |              |<--------------------------|
         |       Mcast Flow 1        |                           |
         |<==========================+                           |
         |            |              |     Generic Response      |
         |            |              |-------------------------->|
         |            |              |                           |
         |            |              |                           |
         ~            ~              ~                           ~
         |            |              |                           |
         |            |              | Multicast-Replication-Crl |
         |            |              |   (Target,delete, Flow 1) |
         |            |              |<--------------------------|
         |            |              |                           |
         |  <Stop Replication of     X                           |
         |            Mcast Flow 1>  |     Generic Response      |
         |            |              |-------------------------->|

        (*) The NAS may optionally seek direction from an external
       Authorization/Policy Server before admitting the flow.

           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 end user
   for a multicast flow (in the grey list), the AN uses ANCP to request
   a 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.

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 a conditional access and admission
   control check.  In the case of a 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.

Le Faucheur, et al.     Expires February 23, 2014               [Page 8]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +----------+    +-------+   +-----+      ANCP           +-----+
   |Subscriber|    | Home  |   | AN  |<------------------->| NAS |
   +----------+    |Gateway|   +-----+                     +-----+
         |         +-------+      |                           |
         |            |           |                           |
         |       Join(Gr-Flow1)   |  Admission-Control        |
         |------------+---------->|   (Target,add,Gr-Flow1)   |
         |            |           |-------------------------->|
         |            |           |                          (*)
         |            |           | Multicast-Replication-Crl |
         |            |           |   (Target,add,Gr-Flow1)   |
         |            |           |<--------------------------|
         |     Mcast Gr-Flow1     |                           |
         |<=======================+                           |
         |            |           |                           |
         ~            ~           ~                           ~
         |            |           |                           |
         |      Leave(Gr-Flow1)   |  Admission-Control        |
         |------------+---------->| (Target,delete,Gr-Flow1)  |
         |            |           |-------------------------->|
         | <Stop Replication of   X                           |
         |       Mcast 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 before admitting the flow.

       Figure 2: Multicast Conditional Access and Admission Control

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.

Le Faucheur, et al.     Expires February 23, 2014               [Page 9]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |  Multicast Flow   |
         |           |           |  Query Request    |
         |           |           |<------------------|
         |           |           |                   |
         |           |           | Multicast Flow    |
         |           |           | Query Response    |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |                   |

                    Figure 3: Multicast Flow Reporting

3.4.  Committed Bandwidth Reporting Use Case

3.4.1.  Goals

   The committed bandwidth reporting use case allows the NAS to maintain
   current awareness of how much multicast bandwidth the AN has
   committed to a given access line, so that the NAS can adjust its
   forwarding scheduler to ensure the associated QoS.  Note that this
   involves a finer level of detail than provided by bandwidth
   delegation, since the amount of delegated bandwidth is an upper limit
   on the amount of bandwidth committed rather than an actual value.  To
   reduce the volume of messaging, reports from the AN may be buffered
   so that one message reports on changes for multiple access lines.

3.4.2.  Message Flow

   The message flow associated with this use case is shown in Figure 4.
   The figure assumes that a non-zero buffering interval was previously
   provisioned on the AN.

   +-----+    +-------+       +-----+    ANCP    +-----+
   |Subs |+   | Home  |+      | AN  |<---------->| NAS |
   |1,2  ||   |GW 1,2 ||      +-----+            +-----+
   +-----+|   +-------+|         |                   |
    +|----+    +|------+         |                   |
     | |        | |              |                   |
     | |Join(Subs1, Ch1)         |                   |
     |----------+--------------->|  Start buffering  |
     | |        | Multicast flow |  timer. Create    |
     |<==========================|  message with     |
     | |        | |              |  initial contents |
     | |        | |              |  reporting new    |

Le Faucheur, et al.     Expires February 23, 2014              [Page 10]
Internet-Draft          ANCP Multicast Extensions            August 2013

     | |        | |              |  Subs1 bandwidth. |
     | | Join(Subs2, Ch2)        |                   |
     | |----------+------------->|  Add report for   |
     | |        | Multicast flow |  new Subs2 b/w.   |
     | |<========================|                   |
     | |        | |              |                   |
     | |Leave(Subs1, Ch1)        |                   |
     |----------+--------------->|  Replace report   |
     | |        | |              |  for Subs1 with   |
     | |      Stop replication   X  new value (which |
     | |        | |              |  happens to be    |
     | |        | |              |  the same as the  |
     | |        | |              |  starting value.  |
     | |        | |              |                   |
     | |        | |             >|< TIMER expires    |
     | |        | |              |                   |
     | |        | |              |Committed          |
     | |        | |              |  Bandwidth Report |
     | |        | |              |------------------>|
     | |        | |              |   (for latest     |
     | |        | |              |   Subs1 and Subs2 |
     | |        | |              |   bandwidth)      |
     | |        | |              |                   |

         Figure 4: Message Flow For Committed Bandwidth Reporting

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 4.1 of [RFC6320] 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:

Le Faucheur, et al.     Expires February 23, 2014              [Page 11]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 5.6.  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 5.7.  If present, this TLV indicates that the
      AN is required to do admission control before replicating flows
      specified in Multicast Replication Control messages.

   o  an instance of the Report-Buffering-Time TLV.  The Report-
      Buffering-Time TLV is defined in Section 5.12.  If present, this
      TLV indicates Committed Bandwidth Report messages should be
      buffered for the amount of time given by the TLV before being
      transmitted to the NAS.

   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
   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

Le Faucheur, et al.     Expires February 23, 2014              [Page 12]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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.

   To require buffering of Committed Bandwidth Report messages so that
   reports for multiple access lines can be included in the same
   message, the NAS MUST include a copy of the Report-Buffering-Time TLV
   containing a non-zero time value in a Provisioning message sent to
   the AN.  The Report-Buffering-Time TLV MUST NOT be provided unless
   the negotiated set of capabilities includes committed bandwidth
   reporting.

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
   according to the contents of the associated List-Action TLVs.  The AN
   MUST process List-Action TLVs in the order in which they appear
   within the message.  The AN MUST ignore instances of the List-Action
   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.

   The receipt of a Provisioning message containing updates to an
   existing multicast service profile subsequent to startup will cause
   the AN to review the status of active flows on all ports to which
   that profile has been assigned.  For further details, see Section 6.

Le Faucheur, et al.     Expires February 23, 2014              [Page 13]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 (or continues) to do connection
   admission control on the indicated class(es) of flow.  If one or both
   of these TLVs was present in an earlier Provisioning message but is
   absent in the latest message received, the AN ceases to do connection
   admission control on the indicated class(es) of flow.

   The buffering time specified in an instance of the Report-Buffering-
   Time TLV applies to only to Committed Bandwidth Report messages
   initiated after the new buffering time is received at the AN, not to
   any message already in the process of accumulation.

   As indicated in [RFC6320], 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 [RFC6320], containing a
   Status-Info TLV with the appropriate content describing the error.
   For this purpose, the presence of a list type in 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.

4.2.  Port Management Message

   As specified in [RFC6320], the NAS may send DSL line configuration
   information to the AN ("ANCP based DSL Line Configuration" use case)
   using ANCP Port Management messages.  See Section 7.3 of [RFC6320]
   for the format of the Port Management message in that usage.

   This document specifies that the Port Management message MAY be used
   to convey either or both of the following TLVs:

   o  Multicast-Service-Profile-Name TLV (defined in Section 5.2).  This
      TLV associates a Multicast Service Profile with the Access Port
      specified by the extension block.

   o  Bandwidth-Allocation TLV (defined in Section 5.5).  This TLV
      specifies the total multicast bandwidth available to the AN for
      admission control at the Access Port.

   When the Port Management message is used for this purpose:

   o  the Function field in the Port Management message MUST be set to
      8, "Configure Connection Service Data".

   o  the message MUST include TLV(s) to identify the access line
      concerned.  If the access line is a DSL loop, the line-identifying
      TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320].  For

Le Faucheur, et al.     Expires February 23, 2014              [Page 14]
Internet-Draft          ANCP Multicast Extensions            August 2013

      non-DSL access lines, the appropriate alternative line-identifying
      TLV(s) MUST be present.  Line configuration data other than the
      two TLVs listed in the previous paragraph MAY be present.

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.  If the NAS
   includes a Multicast-Service-Profile-Name TLV in the Port Management
   message, the name MUST match a profile name provided in a Multicast-
   Service-Profile TLV in a prior Provisioning message.  The NAS MUST
   NOT include a TLV unless it is supported by the set of multicast
   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.  The replacement of one multicast service profile
   with another will cause the AN to review the status of all active
   flows on the target port.  For further details see Section 6.

   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 target 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 Result Code value returned in the response header.  In
   particular, if the name within the Multicast-Service-Profile-Name TLV
   does not match a profile name given in a prior Provisioning message,
   the AN SHOULD return a reply where the Result Code field in the
   header indicates 0x55, "Invalid TLV contents", the Error Message

Le Faucheur, et al.     Expires February 23, 2014              [Page 15]
Internet-Draft          ANCP Multicast Extensions            August 2013

   field in the Status-Info TLV contains the text "Multicast profile
   name not provisioned", and the Status-Info TLV contains a copy of the
   Multicast-Service-Profile-Name TLV.

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
   144.

   The ANCP Multicast Replication Control message payload contains the
   following TLVs:

   o  Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320].
      It MUST appear once and only once.  It is encoded as specified in
      [RFC6320] or extensions and identifies the AN port subject to the
      request for admission or release.

   o  Command TLV: The Command TLV is defined in Section 4.4 of
      [RFC6320].  It MUST be present.  It MAY appear multiple times.

   As [RFC6320] indicates, the contents of the Command Info field within
   the Command TLV are specific to the message in which the TLV occurs.
   For the Multicast Replication Control Message, these contents consist
   of:

   o  a Command Code field;

   o  an Accounting field;

   o  an instance of the Multicast-Flow TLV.

   Figure 5 illustrates the complete Command TLV with the contents
   specific to the Multicast Replication Control 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TLV Type = Command        |       Command-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Command Code |  Accounting     |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Multicast-Flow TLV                        |

Le Faucheur, et al.     Expires February 23, 2014              [Page 16]
Internet-Draft          ANCP Multicast Extensions            August 2013

   |                           ...                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Other embedded TLV Type     |   Other embedded TLV Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Other embedded TLV data                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 5: Contents of the Command TLV in the Multicast Replication
                              Control Message

   Command Code:
             Command directive:

                1 - Add;

                2 - Delete;

                3 - Delete All;

                4 - Admission Control Reject;

                5 - Conditional Access Reject;

                6 - Admission Control and Conditional Access Reject.

             Directives 4 through 6 are used as described in
             Section 4.4.2.

   Accounting:
             Meaningful only when the Command Code is "Add" (1).  In
             that case, 0x00 indicates no flow accounting, 0x01
             indicates that octet accounting for the flow is to
             commence.  The Accounting field MUST be set to 0x00 for
             other Command Code values.

   Reserved:
             Reserved for future use.  MUST be set to 0x0000 by the
             sender and ignored by the receiver.

   Multicast-Flow TLV:
             An instance of the Multicast-Flow TLV (Section 5.11)
             specifying the flow to be added or deleted.  The Multicast-
             Flow TLV MUST be omitted if the Command Code has value
             "Delete All" (3).

   Other embedded TLV:

Le Faucheur, et al.     Expires February 23, 2014              [Page 17]
Internet-Draft          ANCP Multicast Extensions            August 2013

             No other embedded TLVs are currently specified within the
             Multicast Replication Control message/Command TLV.
             However, see the description of the Multicast Admission
             Control message (Section 4.4).  Unrecognized embedded TLVs
             SHOULD be silently discarded.

   The figure below is an example of a Multicast Replication Control
   message that would result in a swap from multicast Source-Specific
   Multicast (SSM) flows 2001:DB8::1, FF34::2, to 2001:DB8::2, FF34::3
   on the Target identified by the "Access Loop Circuit ID":

                          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 (0x880C)          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |  MsgType=144  | 0x02  |     Result 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 = 0x0014  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cmd Code=2    |Acctg = 0x00   |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Multicast-Flow      |      TLV Length = 0x000C      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |AddrFam = 0x02 |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Multicast Group Address                     ~
   |                          = FF34::2                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Source Address                        ~
   |                          = 2001:DB8::1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = Command-TLV     |  Command-TLV Length = 0x0014  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 18]
Internet-Draft          ANCP Multicast Extensions            August 2013

   | Cmd Code=1    |Acctg = 0x01   |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Multicast-Flow      |      TLV Length = 0x000C      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |AddrFam = 0x02 |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Multicast Group Address = FF34::3                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address = 2001:DB8::2            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |                                                               |
   ~                   Multicast Group Address                     ~
   |                          = FF34::3                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Source Address                        ~
   |                          = 2001:DB8::2                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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
   NAS initiated Multicast Control use case presented in [RFC5851] 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 [RFC5851] 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 Result Code field with
   the value 0x000 and the ANCP Transaction Identifier field with a
   unique value, as described in Section 3.6.1.6 of [RFC6320].

   Each Multicast Replication Control Message MUST 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.

Le Faucheur, et al.     Expires February 23, 2014              [Page 19]
Internet-Draft          ANCP Multicast Extensions            August 2013

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 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 attribute.  As an example, successive Multicast
   Replication Control messages containing add commands for a given port
   and flow, but differing only in the Accounting field 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.

   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 a Command TLV adds a flow 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 Result Code value for the
   response is 0x013 "Out of 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 Result 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.

   If the AN processes the complete Multicast Replication Control
   message successfully and the Result field of the Multicast
   Replication Control message was set to Nack (0x1), the AN MUST NOT
   respond to the 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

Le Faucheur, et al.     Expires February 23, 2014              [Page 20]
Internet-Draft          ANCP Multicast Extensions            August 2013

   (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message
   providing error information to the NAS.  This specification
   identifies the following new Result Code values beyond those
   specified in [RFC6320], which MAY be used in a Generic Response sent
   in reply to a Multicast Replication Control message:

   0x64  Command error.

         Where detected: ANCP agent at the AN.

         Further description: an invalid command code has been received.

         Required additional information in the message: see below.

         Target: ANCP agent at the NAS.

         Action RECOMMENDED for the receiving ANCP agent: Correct the
         error and re-send the request, if possible.  Otherwise, report
         the error to the control application with an indication of the
         erroneous information associated with the invalid TLV(s).

   0x65  Invalid flow address.

         Where detected: ANCP agent at the AN.

         Further description: either inconsistent flow address
         information has been provided or the address family is
         unsupported.

         Required additional information in the message: see below.

         Target: ANCP agent at the NAS.

         Action RECOMMENDED for the receiving ANCP agent: correct the
         error and re-send the request, if possible.  Otherwise, report
         the error to the control application with an indication of the
         erroneous information associated with the invalid TLV(s).

   0x66  Multicast flow does not exist.

         Where detected: control application at the AN.

         Further description: the NAS has attempted to delete a flow
         that is not active on the given access line.

         Required additional information in the message: see below.

         Target: control application at the NAS.

Le Faucheur, et al.     Expires February 23, 2014              [Page 21]
Internet-Draft          ANCP Multicast Extensions            August 2013

         Action RECOMMENDED for the receiving ANCP agent: report the
         error to the control application with an indication of the
         erroneous information associated with the invalid TLV(s).

   A Generic Response message responding to the Multicast Replication
   Control message and containing one of the above Result Code values
   MUST include a Status-Info TLV which includes one or two embedded
   TLVs as follows:

   o  a Sequence-Number TLV as described in Section 5.4, 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 Result Code value
      in the message header.  For example, the Result Code value could
      be 0x65 and the Error Message field could contain the text:
      "Source address present for ASM flow".

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 145.

   The ANCP Multicast Admission Control message payload contains two
   TLVs:

   o  Target TLV: The Target TLV is defined in [RFC6320].  It MUST
      appear once and only once in the Multicast Admission Control
      message.  It is encoded as specified in [RFC6320] or extensions
      and identifies the AN port subject to the request for admission or
      release.

   o  Command TLV: The Command TLV is defined in [RFC6320].  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.

   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

Le Faucheur, et al.     Expires February 23, 2014              [Page 22]
Internet-Draft          ANCP Multicast Extensions            August 2013

      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.

   The Command TLV has the same contents as were described above for the
   Multicast Replication Control message, with the following additions:

   o  a Request-Source-IP TLV MAY be appended to the Command TLV as an
      additional embedded TLV;

   o  similarly, a Request-Source-MAC TLV MAY be appended to the Command
      TLV as an additional embedded TLV.

   Note that the Command TLV length includes the length of any embedded
   TLVs, including the embedded TLV headers.

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 3.6.1.6 of [RFC6320].

   The AN MUST encode the Command TLV as specified in Section 4.3 with
   the following additional rules:

   o  the Accounting field MUST be set to 0;

   o  the Command Code field MUST be set to "1 - Add" when the message
      conveys a Join , to "2 - Delete" when the message conveys a Leave
      and to "3 - Delete All" when the message conveys a Leave of all
      channels (on the target);

   o  The Multicast-Flow TLV within the Command TLV identifies the
      multicast flow subject to the request for admission or release.
      When the Command Code is 3, the Multicast-Flow TLV is meaningless
      and MUST be omitted.

   o  the Request-Source-IP embedded TLV 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

Le Faucheur, et al.     Expires February 23, 2014              [Page 23]
Internet-Draft          ANCP Multicast Extensions            August 2013

      appears more than once, only the first instance is considered
      meaningful and the other instances are ignored.

   o  the Request-Source-MAC embedded TLV 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 "2
      - Delete" or "3 - 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 "1
      - 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 with a unique value, as described
         in Section 3.6.1.6 of [RFC6320];

      *  MUST contain the directive as accepted by the NAS.  The NAS MAY
         modify the Accounting field if flow accounting is required.

   o  if the directive in the Multicast Admission Control message is "1
      - Add", is processed correctly but not accepted by the NAS (i.e.,
      it does not pass the admission control or conditional access
      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 rejections.

         In the future, the AN may be able to notify the subscriber that
         the request was rejected (e.g., using
         [I-D.morin-mboned-igmpmld-error-feedback]).

Le Faucheur, et al.     Expires February 23, 2014              [Page 24]
Internet-Draft          ANCP Multicast Extensions            August 2013

      When used in this situation, the Multicast Replication Control
      message:

      *  MUST contain a Result set to 0x0;

      *  MUST contain a Transaction ID with a unique value, as described
         in Section 3.6.1.6 of [RFC6320];

      *  MUST contain the directive rejected by the NAS (i.e., Target
         TLV and Command TLV) but with a Command Code set to "4 -
         Admission Control Reject", "5 - Conditional Access Reject", or
         "6 - Admission Control and Conditional Access Reject" as
         applicable.

   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 Section 4.2 of [RFC6320]) 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 4.3 of [RFC6320] or an extension),
      specifying a single access line;

   o  the Bandwidth-Request TLV (Section 5.8), specifying the required
      and preferred amounts of delegated bandwidth.

   The Message Type for the Bandwidth Reallocation Request message is
   146.

4.5.1.  Sender Behaviour

Le Faucheur, et al.     Expires February 23, 2014              [Page 25]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 current 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 current 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
   Result Code field MUST be set to 0x000, and the Bandwidth-Allocation
   TLV (Section 5.5) 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 Result Code field MUST be
   set to 0x000, and the Bandwidth Allocation TLV MUST contain the value
   of the 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 delegated bandwidth from the receiver:

Le Faucheur, et al.     Expires February 23, 2014              [Page 26]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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
       Result Code value set to 0x68 "Inconsistent views of delegated
       bandwidth amount" or 0x69 "Bandwidth request conflict" as
       applicable.  (See below for more information).

   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
   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),

Le Faucheur, et al.     Expires February 23, 2014              [Page 27]
Internet-Draft          ANCP Multicast Extensions            August 2013

   o  the Result 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 Result Code values applicable
   specifically to the contents of the Bandwidth-Request TLV.  These
   Result 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.

   0x67  Invalid preferred bandwidth amount.

         Where detected: control application at the receiver of the
         Bandwidth Reallocation Request message.

         Further description: the preferred and required amounts of
         bandwidth in the TLV do not have the numerical relationship
         described above.

         Required additional information in the message: as described
         above.

         Target: control application at the sender of the Bandwidth
         Reallocation Request message.

         Action RECOMMENDED for the receiving ANCP agent: report the
         error to the control application with the returned value of the
         Bandwidth-Allocation TLV.  See also Section 4.6.2.2.

   0x68  Inconsistent views of delegated bandwidth amount.

         Where detected: control application at the NAS.

         Further description: the NAS has an outstanding Bandwidth
         Reallocation Request, so it is rejecting a similar request from
         the AN.  In the AN request, the required amount was less than
         the NAS's view of the current amount of delegated bandwidth.

         Required additional information in the message: as described
         above.

         Target: control application at the AN.

Le Faucheur, et al.     Expires February 23, 2014              [Page 28]
Internet-Draft          ANCP Multicast Extensions            August 2013

         Action RECOMMENDED for the receiving ANCP agent: report the
         error to the AN control application with the returned value of
         the Bandwidth-Allocation TLV.  See also Section 4.6.2.2.

   0x69  Bandwidth request conflict.

         Where detected: control application at the NAS.

         Further description: the NAS has an outstanding Bandwidth
         Reallocation Request, so it is rejecting a similar, valid
         request from the AN.

         Required additional information in the message: as described
         above.

         Target: control application at the AN.

         Action RECOMMENDED for the receiving ANCP agent: report the
         error to the AN control application with the returned value of
         the Bandwidth-Allocation TLV.  See also Section 4.6.2.2.

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).

      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 147.  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.5).  The
      bandwidth value in the Bandwidth-Allocation TLV is the new amount
      of delegated bandwidth allocated to the target.

Le Faucheur, et al.     Expires February 23, 2014              [Page 29]
Internet-Draft          ANCP Multicast Extensions            August 2013

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
   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 Result Code field equal to 0x68
   "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth

Le Faucheur, et al.     Expires February 23, 2014              [Page 30]
Internet-Draft          ANCP Multicast Extensions            August 2013

   request conflict".  If Result Code value 0x68 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 Result Code value 0x69 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 Result 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 148.

   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:

   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 Result Code
   value MUST be set to 0x000.  The sender MUST populate the ANCP
   Transaction Identifier field with a unique value, as described in
   Section 3.6.1.6 of [RFC6320].

4.7.2.  Receiver Behaviour

Le Faucheur, et al.     Expires February 23, 2014              [Page 31]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 Result 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 Result Code field MUST be set to the value that indicates
   the nature of the error (e.g., 0x500 "One or more of the specified
   ports do not exist").  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 information 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 148.

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

Le Faucheur, et al.     Expires February 23, 2014              [Page 32]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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.

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 149.

   The contents of the Multicast Flow Query Request and Response depend
   on the nature of the query, as described below.

Le Faucheur, et al.     Expires February 23, 2014              [Page 33]
Internet-Draft          ANCP Multicast Extensions            August 2013

4.9.1.  Sender Behaviour

   The sender of a Multicast Flow Query Request message MUST set the
   Result field to AckAll (0x2).  The Result Code field MUST be set to
   0x000.  The sender MUST populate the ANCP Transaction Identifier
   field with a unique value, as described in section 3.6.1.6 of
   [RFC6320].

   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
      access port of the AN.

   To retrieve the AN's view of which multicast flows are currently
   active on a given port of the AN, the NAS MUST include a Target TLV
   in the Multicast Flow Query Request payload identifying that port.
   The Target TLV is encoded as specified in [RFC6320].

   To retrieve the AN's view of the ports currently receiving a given
   multicast flow, the NAS MUST include a Multicast-Flow TLV in the
   Multicast Flow Query Request payload identifying that flow.  The
   Multicast-Flow TLV is encoded as specified in Section 5.11.

   The NAS MAY include multiple Target TLVs or multiple Multicast-Flow
   TLVs in the Multicast Flow Query Request, but MUST NOT include both
   Target and Multicast-Flow TLVs in the same message.

   To retrieve the AN's view of all of the multicast flows currently
   active on each port of the AN, the NAS MUST send a Multicast Flow
   Query Request which does 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 Result Code field MUST be set to 0x000.  The
   Transaction-Id field MUST be copied from the request.

Le Faucheur, et al.     Expires February 23, 2014              [Page 34]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 Multicast-Flow
      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 currently
   receiving multicast flow(s), the following set of TLVs:

   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.

Le Faucheur, et al.     Expires February 23, 2014              [Page 35]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 Result 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.

4.10.  Committed Bandwidth Report Message

   This section describes the Committed Bandwidth Report message, which
   is sent from the AN to the NAS to report the most recent amount of
   multicast bandwidth usage committed to one or more access lines.

   The Message Type for the Committed Bandwidth Report message is 150.

   The Committed Bandwidth Report message contains one or more instances
   of the Committed-Bandwidth TLV, as described in Section 5.13.

4.10.1.  Sender Behaviour

   The sender of a Committed Bandwidth Report message MUST set the
   Result field to Ignore (0x0).  The Result Code field MUST be set to
   0x000.  The sender MUST populate the ANCP Transaction Identifier
   field with a unique value, as described in section 3.6.1.6 of
   [RFC6320].

   Each instance of the Committed-Bandwidth TLV included in the message
   MUST identify an access line for which the amount of committed
   multicast bandwidth has changed since the previous Committed
   Bandwidth Report message was sent and MUST report the latest amount
   of multicast bandwidth committed to that line.  There MUST be only
   one instance of the Committed-Bandwidth TLV present in the message
   for any given access line.  The message MUST include an instance of
   the Committed-Bandwidth TLV for every access line for which committed
   multicast bandwidth has changed since the previous Committed
   Bandwidth Report message was sent.

   Further behaviour at the AN is specified in Section 6.2.2.

4.10.2.  Receiver Behaviour

   The usage of the contents of a Committed Bandwidth Report message
   received by the NAS is implementation-dependent.  One example is that

Le Faucheur, et al.     Expires February 23, 2014              [Page 36]
Internet-Draft          ANCP Multicast Extensions            August 2013

   the NAS uses the reports of multicast bandwidth commitments to adjust
   its forwarding scheduler operation to provide the intended level of
   QoS.

   The NAS MUST NOT reply to a valid Committed Bandwidth Report message.
   The NAS MAY send a Generic Response message indicating the nature of
   any errors detected in a Committed Bandwidth Report message that it
   has received.

5.  ANCP TLVs For Multicast

   This section defines new ANCP TLVs for the control of multicast
   flows.

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 TLV is illustrated in Figure 6.  It
   consists of a TLV header encapsulating a single instance of the
   Multicast-Service-Profile-Name TLV and one or more instances of the
   List-Action 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Mcast Serv Profile  |             TLV Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Multicast-Service-Profile-Name TLV                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   List-Action TLV                                             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ...                                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   List-Action TLV                                             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: Multicast-Service-Profile TLV

   The Multicast-Service-Profile TLV has the following fields:

Le Faucheur, et al.     Expires February 23, 2014              [Page 37]
Internet-Draft          ANCP Multicast Extensions            August 2013

   o  The Multicast-Service-Profile TLV Type is 0x0013.

   o  The TLV length is determined by the contents following the TLV
      header.

   o  The Multicast-Service-Profile-Name TLV is described in
      Section 5.2.  The Multicast-Service-Profile-Name TLV MUST contain
      an identifier which is unique over all profiles provisioned to the
      same AN partition.  This identifier will be used to refer to the
      profile when activating it for a given target within a Port
      Management message (see Section 4.2).

   o  The List-Action TLV is described in Section 5.3.  The List-Action
      TLV(s) provide the content of a newly defined multicast service
      profile or modify the existing content.  If more than one List-
      Action TLV is present, the order of the TLVs may be significant,
      since List-Action TLVs are processed in the order in whch they
      appear.

5.2.  Multicast-Service-Profile-Name TLV

   The Multicast-Service-Profile-Name TLV carries the identifier of a
   multicast service profile provisioned on the AN.  It is illustrated
   in Figure 7.

                        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 = MSP Name            |             TLV Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Multicast service profile identifier                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 7: Multicast-Service-Profile-Name TLV

   The Multicast-Service-Profile-Name TLV has the following fields:

   o  The Multicast-Service-Profile-Name TLV Type is 0x0018.

   o  TLV Length: up to 255 octets.

   o  Multicast service profile identifier: an opaque sequence of octets
      identifying a specific multicast service profile.

         The identifier could have the form of human-readable text or an
         arbitrary binary value, depending on the operator's practices.

Le Faucheur, et al.     Expires February 23, 2014              [Page 38]
Internet-Draft          ANCP Multicast Extensions            August 2013

5.3.  List-Action TLV

   The List-Action TLV identifies multicast flows to be added to or
   removed from a list of white-, black-, or grey-listed flows.  It is
   meaningful only in association with a Multicast-Service-Profile-Name
   TLV identifying the profile to which the List-Action TLV applies.
   Such an association can be achieved by placing both TLVs in the same
   base message payload or as embedded TLVs of another TLV such as the
   Multicast-Service-Profile.  The List-Action TLV is shown in Figure 8.

                        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 = List-Action TLV    |          TLV Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Operation     | List Type     |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family                |     Number of flow fields     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast flow fields                      |
                             ......
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family                |     Number of flow fields     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast flow fields                      |
                                    ......
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 8: List-Action TLV

   The List-Action TLV contains the following fields:

   o  The List-Action TLV Type is 0x0021.

   o  TLV Length: length of the subsequent contents.

   o  Operation: operation to be performed upon the white, black, or
      grey list identified by the List Type field within the profile
      identified by the associated Multicast-Service-Profile-Name
      embedded TLV.  The possible values are:

      *  Add (0x01): the multicast flow fields are to be added to the
         list.

      *  Delete (0x02): the multicast flow fields are to be removed from
         the list.  Each multicast flow field in the List-Action MUST

Le Faucheur, et al.     Expires February 23, 2014              [Page 39]
Internet-Draft          ANCP Multicast Extensions            August 2013

         match exactly an existing entry in the list concerned.  Thus to
         remove part of the range provided by a wildcarded list entry,
         it is necessary to remove the entire entry and add back the
         remaining partial range(s).

      *  Replace (0x03): the multicast flow fields replace the existing
         contents of the list.

   o  List Type: the list type being modified by this List-Action.  The
      possible values are White (0x01), Black (0x02), or Grey (0x03).

   o  Reserved: a sender MUST set this field to 0x0000.  A receiver MUST
      ignore the contents of this field.

   o  Address Family: the IP version of the set of multicast flow fields
      that follow, encoded according to [PIMreg].  Possible values are
      0x0001 (IPv4) or 0x0002 (IPv6).  Either an IPv4 list or an IPv6
      list or both MAY be present in the List-Action TLV.

   o  Number of flow fields: the number of multicast flow fields of the
      given address family which follow.

   o  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 Source-Specific
   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 embedded 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)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 40]
Internet-Draft          ANCP Multicast Extensions            August 2013

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

   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.4.  Sequence-Number TLV

   The Sequence-Number TLV conveys a sequence number of some sort.  The
   specific meaning of the sequence number is message-specific.  Within
   this specification, the Sequence-Number TLV is used as a embedded TLV
   in a Status-Info TLV, in a Generic Response reporting a failed
   command in a Multicast Replication Control or Multicast Admission
   Request message.  It identifies the sequence number within the
   message of the command that failed.

   The Sequence-Number TLV has the format shown in Figure 10.

                        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 = Sequence-Number     |          TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 10: Sequence-Number TLV

   The Sequence-Number TLV has the following fields:

   o  The Sequence-Number TLV Type is 0x0022.

   o  TLV length is 0x0004.

Le Faucheur, et al.     Expires February 23, 2014              [Page 41]
Internet-Draft          ANCP Multicast Extensions            August 2013

   o  Sequence number: the sequence number of a specific entity within a
      series, where numbering starts from 1 for the first entity in the
      series.  Represented as a 32-bit binary number, most significant
      bit first.

5.5.  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.

                        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 = BW-Allocation       |          TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Delegated amount (kbits/s)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: The Bandwidth-Allocation TLV

   The Bandwidth-Allocation TLV has the following fields:

   o  The Bandwidth-Allocation TLV Type is 0x0015.

   o  TLV length is 4.

   o  Delegated amount: the bandwidth amount delegated to the AN for
      admission of multicast video on a given port, kilobits per second.
      Presented as a 32-bit binary value, most significant bit first.

5.6.  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 is illustrated in Figure 12.

                        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 = White-List-CAC      |          TLV Length = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 12: White-List-CAC TLV

   The White-List-CAC TLV contains the following fields:

Le Faucheur, et al.     Expires February 23, 2014              [Page 42]
Internet-Draft          ANCP Multicast Extensions            August 2013

   o  The White-List-CAC TLV Type is 0x0024.

   o  TLV length is 0, since the TLV contains no data other than the TLV
      header.

5.7.  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 is
   illustrated in Figure 13.

                        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 = MRepCtl-CAC         |          TLV Length = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 13: MRepCtl-CAC TLV

   The MRepCtl-CAC TLV contains the following fields:

   o  The MRepCtl-CAC TLV Type is 0x0025.

   o  TLV length is 0, since the TLV contains no data other than the TLV
      header.

5.8.  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 14.

                        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 = Bandwidth-Request   |          TLV Length = 8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Required amount  (kbits/s)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 43]
Internet-Draft          ANCP Multicast Extensions            August 2013

   |           Preferred amount (kbits/s)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 14: The Bandwidth-Request TLV

   The Bandwidth-Request TLV has the following fields:

   o  The Bandwidth-Request TLV Type is 0x0016.

   o  The TLV length is 8 octets.

   o  Required amount: the minimum or maximum amount, depending on
      whether the sender is the AN or the NAS respectively, of delegated
      video bandwidth that is being requested, in kilobits per second.
      Presented as a 32-bit binary value, most significant bit first.

   o  Preferred amount: the preferred amount of delegated video
      bandwidth that is being requested, in kilobits per second.
      Presented as a 32-bit binary value, most significant bit first.

5.9.  Request-Source-IP TLV

   The Request-Source-IP TLV provides the IP address of the entity that
   originated a specific request to join or leave a multicast channel.
   The TLV is illustrated in Figure 15.

                         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 = Request-Source-IP |   TLV length = 4 or 16        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Unicast Address                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 15: Request-Source-IP TLV

   The Request-Source-IP TLV contains the following fields:

   o  The Request-Source-IP TLV Type is 0x0092.

   o  TLV length is 4 for an IPv4 address or 16 for an IPv6 address.

   o  Unicast address: IP address of the source of a multicast flow join
      request, in network byte order.

5.10.  Request-Source-MAC TLV

Le Faucheur, et al.     Expires February 23, 2014              [Page 44]
Internet-Draft          ANCP Multicast Extensions            August 2013

   The Request-Source-MAC TLV provides the MAC address of the entity
   that originated a specific request to join or leave a multicast
   channel.  The TLV is illustrated in Figure 16.

                        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=Request-Source-MAC    |     TLV Length = 6 or 8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-                      IEEE MAC Address              +-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 16: Request-Source-MAC TLV

   The Request-Source-MAC TLV contains the following fields:

   o  The Request-Source-MAC TLV Type is 0x0093.

   o  TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets
      (EUI-64).

   o  IEEE MAC Address: MAC address of the device originating the
      request to join a multicast flow.  Within the address, bytes and
      bits respectively shall be ordered from most to least significant,
      consistently with [IEEE48] for MAC-48 and EUI-48, and with
      [IEEE64] for EUI-64.

         EUI-48 and EUI-64 are registered trademarks of the IEEE.

5.11.  Multicast-Flow TLV

   The Multicast-Flow TLV specifies a multicast flow in terms of its
   multicast group address and, if applicable, its unicast source
   address.  It is illustrated in Figure 17.

                        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 = Multicast-Flow      |      TLV Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Flow Type   |  Addr Family  |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Multicast Group Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |           Unicast Source Address (for SSM flows only)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 45]
Internet-Draft          ANCP Multicast Extensions            August 2013

                       Figure 17: Multicast-Flow TLV

   The Multicast-Flow TLV has the following fields:

   o  The Multicast-Flow TLV Type is 0x0019.

   o  TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to
      36 (for an IPv6 SSM flow).

   o  Flow Type: 0x01 for Any Source Multicast (ASM), 0x02 for Source-
      Specific Multicast (SSM).

   o  Addr Family: address family of the multicast source and group
      addresses, encoded in accordance with the IANA PIM Address Family
      registry ([PIMreg]). 0x01 indicates IPv4, 0x02 indicates IPv6.

   o  Reserved: MUST be set to 0x0000 by the sender and MUST be ignored
      by the receiver.

         One possible use for this field in the future is to indicate
         the presence of PIM Join attributes attached to the source
         address (see [RFC5384]).  The applicability of PIM attributes
         in the context of ANCP is for further study.

   o  Multicast Group Address: a multicast group address within the
      given address family.  The group address MUST always be present.

   o  Unicast Source Address: unicast address within the given address
      family.  If the Flow Type is 0x01 (ASM), a source address MUST NOT
      be present.  If the Flow Type is 0x02 (SSM), a source address MUST
      be present.

5.12.  Report-Buffering-Time TLV

   The Report-Buffering-Time TLV provides the time for which a Committed
   Bandwidth Report message must be held with the intention of
   accumulating multiple reports of changed committed multicast
   bandwidth in one report, to reduce the volume of messages sent to the
   NAS.  For further information see Section 6.2.2.  The TLV is
   illustrated in Figure 18.

                        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=Report-Buffering-Time |      TLV Length = 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Buffering Time (ms)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 46]
Internet-Draft          ANCP Multicast Extensions            August 2013

                   Figure 18: Report-Buffering-Time TLV

   The Report-Buffering-Time TLV contains the following fields:

   o  The Report-Buffering-Time TLV Type is 0x0094.

   o  TLV length is 4 octets.

   o  Buffering Time is a 32-bit unsigned integer containing a time
      value in ms.

5.13.  Committed-Bandwidth TLV

   The Committed-Bandwidth TLV identifies an access line and provides
   the current amount of multicast bandwidth that the AN has committed
   to it.  The TLV is illustrated in Figure 19.

                        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=Committed-Bandwidth   |      TLV Length (variable)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Committed Multicast Bandwidth   (kbits/s)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-                      Target TLV                    +-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 19: Committed-Bandwidth TLV

   The Committed-Bandwidth TLV contains the following fields:

   o  The Committed-Bandwidth TLV Type is 0x0095.

   o  TLV length is 4 octets plus the length of the Target TLV including
      its header and any padding.

   o  Committed Multicast Bandwidth is a 32-bit unsigned integer
      providing a bandwidth amount in kbits/s.

   o  The Target TLV identifies the access line to which this amount of
      multicast bandwidth is currently committed.

6.  Multicast Capabilities

Le Faucheur, et al.     Expires February 23, 2014              [Page 47]
Internet-Draft          ANCP Multicast Extensions            August 2013

   Section 3.5 of [RFC6320] defines a capability negotiation mechanism
   as well as a number of capabilities.  This section defines five new
   capabilities in support of different modes of multicast operation:

   o  NAS-initiated replication (capability type 3);

   o  committed multicast bandwidth reporting (capability type 5);

   o  conditional access with white and black lists (capability type 6);

   o  conditional access with grey lists (capability type 7);

   o  bandwidth delegation (capability type 8).

   The "Capability Data" field within the Capability TLV for all of
   these capabilities is empty.  All of these capabilities are
   independent of the access technology.

   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.  The body of the message MUST contain a Status-Info TLV.
   See Sections 4.2 and 4.5 in [RFC6320] 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.

   In addition to the elements listed below, implementation of the
   Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the
   capabilities specified in this document.

6.1.1.  Protocol Requirements For NAS-Initiated Replication

Le Faucheur, et al.     Expires February 23, 2014              [Page 48]
Internet-Draft          ANCP Multicast Extensions            August 2013

   Table 1 specifies the protocol elements within Section 4 and
   Section 5 that MUST be implemented to support the NAS-initiated
   replication multicast capability.  Additionally, implementation of
   the Multicast Replication Control message requires implementation of
   the Command TLV (Section 4.4 of [RFC6320] with additional details in
   Section 4.3 of this document).

   +-----------------+-------------------------------------------------+
   | 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.4     | Sequence Number TLV                             |
   |                 |                                                 |
   | Section 5.5     | Bandwidth-Allocation TLV                        |
   |                 |                                                 |
   | Section 5.7     | MRepCtl-CAC TLV                                 |
   |                 |                                                 |
   | Section 5.11    | Multicast-Flow TLV                              |
   +-----------------+-------------------------------------------------+

       Table 1: Protocol Requirements For NAS-Initiated Replication

6.1.2.  Protocol Requirements For Committed Multicast Bandwidth
        Reporting

   Table 2 specifies the protocol elements within Section 4 and
   Section 5 that MUST be implemented to support the committed multicast
   bandwidth reporting capability.

   +-----------------+-------------------------------------------------+
   | Reference       | Protocol Element                                |
   +-----------------+-------------------------------------------------+
   | Section 4.1     | Provisioning message with Report-Buffering-Time |
   |                 | TLV                                             |
   |                 |                                                 |
   | Section 4.10    | Committed Bandwidth Report message              |
   |                 |                                                 |
   | Section 4.9     | Multicast Flow Query Request and Response       |
   |                 | messages                                        |

Le Faucheur, et al.     Expires February 23, 2014              [Page 49]
Internet-Draft          ANCP Multicast Extensions            August 2013

   |                 |                                                 |
   | Section 5.12    | Report-Buffering-Timer TLV                      |
   |                 |                                                 |
   | Section 5.13    | Committed-Bandwidth TLV                         |
   |                 |                                                 |
   | Section 5.11    | Multicast-Flow TLV                              |
   +-----------------+-------------------------------------------------+

     Table 2: Protocol Requirements For Committed Multicast Bandwidth
                                 Reporting

6.1.3.  Protocol Requirements For Conditional Access With White and
        Black Lists

   Table 3 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.

   +--------------+----------------------------------------------------+
   | 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                      |
   |              |                                                    |
   | Section 5.2  | Multicast-Service-Profile-Name TLV                 |
   |              |                                                    |
   | Section 5.3  | List-Action TLV, white and black lists only        |
   |              |                                                    |
   | Section 5.5  | Bandwidth-Allocation TLV                           |
   |              |                                                    |
   | Section 5.6  | White-List-CAC TLV                                 |
   |              |                                                    |
   | Section 5.11 | Multicast-Flow TLV                                 |
   +--------------+----------------------------------------------------+

   Table 3: Protocol Requirements For Conditional Access with White and
                                Black Lists

6.1.4.  Protocol Requirements For Conditional Access With Grey Lists

Le Faucheur, et al.     Expires February 23, 2014              [Page 50]
Internet-Draft          ANCP Multicast Extensions            August 2013

   Table 4 specifies the protocol elements within Section 4 and
   Section 5 that MUST be implemented to support the conditional access
   with grey lists multicast capability.  Additionally, implementation
   of the Multicast Replication Control message requires implementation
   of the Command TLV (Section 4.4 of [RFC6320] with additional details
   in Section 4.3 of this document).

   +--------------+----------------------------------------------------+
   | 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  | Multicast-Service-Profile-Name TLV                 |
   |              |                                                    |
   | Section 5.3  | List-Action TLV, grey lists only                   |
   |              |                                                    |
   | Section 5.4  | Sequence Number TLV                                |
   |              |                                                    |
   | Section 5.5  | Bandwidth-Allocation TLV                           |
   |              |                                                    |
   | Section 5.7  | MRepCtl-CAC TLV                                    |
   |              |                                                    |
   | Section 5.9  | Request-Source-IP TLV                              |
   |              |                                                    |
   | Section 5.10 | Request-Source-MAC TLV                             |
   |              |                                                    |
   | Section 5.11 | Multicast-Flow TLV                                 |
   +--------------+----------------------------------------------------+

   Table 4: Protocol Requirements For Conditional Access with Grey Lists

Le Faucheur, et al.     Expires February 23, 2014              [Page 51]
Internet-Draft          ANCP Multicast Extensions            August 2013

6.1.5.  Protocol Requirements For Delegated Bandwidth

   Table 5 specifies the protocol elements within Section 4 and
   Section 5 that MUST be implemented to support the delegated bandwidth
   multicast capability.

   +-----------------+-------------------------------------------------+
   | 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.5     | Bandwidth-Allocation TLV                        |
   |                 |                                                 |
   | Section 5.8     | Bandwidth-Request TLV                           |
   |                 |                                                 |
   | Section 5.11    | Multicast-Flow TLV                              |
   +-----------------+-------------------------------------------------+

          Table 5: Protocol 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

Le Faucheur, et al.     Expires February 23, 2014              [Page 52]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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.

6.2.1.1.  Provisioning

   The NAS MAY perform admission control for NAS-initiated replication.
   In this case, it MUST NOT include the MRepCtl-CAC TLV in a
   Provisioning message sent to the AN.  Alternatively, the NAS MAY
   enable admission control at the AN for NAS-initiated replication.  To
   do this, it MUST include the MRepCtl-CAC TLV in a Provisioning
   message sent to the AN and it MUST also include a Bandwidth-
   Allocation TLV in a Port Management message for each access line.

6.2.1.2.  Multicast Service Procedures

   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 4.3.1.  To
   terminate replication the NAS MUST send a Multicast Replication
   Control message where the commands delete instead of adding the
   flows.  The AN acts upon these messages as specified in
   Section 4.3.2.

6.2.2.  Procedures For Committed Bandwidth Reporting

   Committed bandwidth reporting may be negotiated if the NAS requires
   current knowledge of the amount of multicast bandwidth committed to
   each access line and cannot obtain this information by other means.

6.2.2.1.  Provisioning

   The default buffering time when committed bandwidth reporting is
   enabled is zero (immediate reporting).  To change this, the NAS MAY
   send an instance of the Report-Buffering-Time TLV containing a non-
   zero time value to the AN in a Provisioning message.  If the NAS
   subsequently wishes to change the buffering time again, it MAY do so
   in another Provisioning message.

Le Faucheur, et al.     Expires February 23, 2014              [Page 53]
Internet-Draft          ANCP Multicast Extensions            August 2013

6.2.2.2.  Multicast Service Procedures

   If the buffering time for committed bandwidth reporting is zero, the
   AN MUST send a Committed Bandwidth Report message to the NAS each
   time the amount of multicast bandwidth committed to any access line
   under its control changes.

   If a non-zero value is provided in the Report-Buffering-Time TLV, the
   AN at any given moment is in one of two states: not-buffering, or
   buffering.  The AN enters buffering state if it is in not-buffering
   state and the multicast bandwidth amount committed to some access
   line changes.  It leaves buffering state when the AN sends a
   Committed Bandwidth Report.

   Upon entry to the buffering state, the AN MUST start a buffering
   timer and create a Committed Bandwidth Report message containing a
   Committed-Bandwidth TLV for the triggering access line, but MUST NOT
   send it.  If a multicast bandwidth change occurs for another access
   line, the AN MUST add a new Committed-Bandwidth TLV to the message
   for that additional line.  If a multicast bandwidth change occurs for
   a line for which a Committed-Bandwidth TLV is already present in the
   buffered report, the AN MUST update the corresponding Committed-
   Bandwidth TLV to contain the new bandwidth value, rather than adding
   another Committed-Bandwidth TLV for the same access line.

   The buffering timer expires after the period provided by the Report-
   Buffering-Time TLV.  When it expires, the AN MUST send the Committed
   Bandwidth Report message that it has been accumulating to the NAS.
   Exceptionally, the AN MAY choose to send the message before the timer
   expires, in which case it MUST clear the buffering timer when the
   message is sent.  In either case, the AN enters the not-buffering
   state as a result.

      Report buffering implies that NAS reaction to changes in multicast
      bandwidth usage is delayed by the amount of the buffering period.
      The choice of buffering period must take this into consideration.

6.2.3.  Procedures For Conditional Access With Black and White Lists

6.2.3.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.

Le Faucheur, et al.     Expires February 23, 2014              [Page 54]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 change the multicast service
   profile for a given access line at any time by sending a Port
   Management message identifying a new multicast service profile.

   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 4.1, which includes the White-List-CAC TLV and
   it MUST provide a multicast bandwidth allocation for each access line
   by including a Bandwidth-Allocation TLV in a Port Management message.

6.2.3.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 AN as described in the previous section, but
   a white-listed flow would cause the amount of committed multicast
   bandwidth to exceed the provisioned limit, the request MUST be
   discarded.  The AN replicates flows passing these checks 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 group address (i.e., on G of <S,G>)

   o  then, most specific match (longest prefix length) on the unicast
      source address (i.e. on S of <S,G>)

   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 (<S=*,G=*>) 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.

Le Faucheur, et al.     Expires February 23, 2014              [Page 55]
Internet-Draft          ANCP Multicast Extensions            August 2013

   When the AN receives a "leave" request, it terminates replication of
   the multicast flow.

   If the AN receives a Provisioning message which updates an existing
   multicast service profile, the AN MUST review the status of active
   flows on all ports to which the updated profile is currently
   assigned.  Similarly, if a Port Management message assigns a new
   multicast service profile to a given port, the AN MUST review all
   active flows on that port.  If the most specific match for any flow
   is a black list entry, the flow MUST be terminated immediately.  If
   any of the remaining flows do not match an entry in the white list,
   they also MUST be terminated immediately.  White listed flows MUST be
   allowed to continue.

6.2.4.  Procedures For Conditional Access With Grey Lists

6.2.4.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 MAY change profiles on the line by
   sending a subsequent Port Management message identifying a new
   profile.

   The NAS MAY perform admission control for grey-listed flows.  In that
   case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning
   message sent to the AN.  Alternatively, the NAS MAY enable admission
   control at the AN for grey-listed flows.  To do this, it MUST include
   the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST
   also provide a Bandwidth-Allocation TLV in a Port Management message
   for each access line.

6.2.4.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

Le Faucheur, et al.     Expires February 23, 2014              [Page 56]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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 4.3.1.

   When the AN receives the Multicast Replication Control request, it
   performs admission control if admission control has been enabled as
   described in the previous section.  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 4.3.2.  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.

   If the AN receives a Provisioning message which updates an existing
   multicast service profile, the AN MUST review the status of active
   flows on all ports to which the updated profile has been assigned.
   Similarly, if a Port Management message that assigns a new profile to
   a given port, the AN MUST review all active flows on that port.  In
   either case, if any flow does not match an entry in the grey list, it
   MUST be terminated immediately.

6.2.5.  Procedures For Delegated Bandwidth

6.2.5.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.

Le Faucheur, et al.     Expires February 23, 2014              [Page 57]
Internet-Draft          ANCP Multicast Extensions            August 2013

   The NAS MAY at any time force an update of the amount of delegated
   bandwidth by the same means.

6.2.5.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 Conditional Access With White and Black Lists and
        Conditional Access With Grey Lists

Le Faucheur, et al.     Expires February 23, 2014              [Page 58]
Internet-Draft          ANCP Multicast Extensions            August 2013

   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.3.1 except that
   multicast service profiles will also include grey lists.  Admission
   control is enabled independently on the AN 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.3.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.3.2 for white or black listed
   flows or Section 6.2.4.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.

   If the AN receives a Provisioning message which updates an existing
   multicast service profile, the AN MUST review the status of active
   flows on all ports to which the updated profile is currently
   assigned.  Similarly, if a Port Management message assigns a new
   multicast service profile to a given port, the AN MUST review all
   active flows on that port.  If any flow has its most specific match
   in a black list entry, it MUST be terminated immediately.  If any of
   the remaining flows do not match an entry in the white or grey list,
   they MUST also be terminated immediately.  Finally, if any remaining
   flows were originally admitted because they were white-listed, but
   after the change they are grey-listed, the AN MUST generate a
   Multicast Flow Query response message autonomously as if it were
   responding to a Multicast Flow Query request, listing all such flows.
   These flows MUST be allowed to continue until the NAS or the
   subscriber terminates them.  Flows with their most specific match in
   the white list MUST be allowed to continue.

Le Faucheur, et al.     Expires February 23, 2014              [Page 59]
Internet-Draft          ANCP Multicast Extensions            August 2013

   The autonomously-generated Multicast Flow Query response message MUST
   be formatted as if it were a successful response to a request
   containing no Target and no Multicast-Flow TLV, as described in
   Section 4.9.2, with the exception that the Transaction-Id MUST be set
   to all zeroes.

6.3.2.  Combination of Conditional Access With Delegated Bandwidth

   The provisioning and bandwidth management procedures of Section 6.2.5
   apply in addition to the procedures in Section 6.2.3, Section 6.2.4,
   or Section 6.3.1 as applicable.  Admission control follows the rules
   for conditional access in terms of matching flows against white and
   black and/or grey lists and performing or not performing bandwidth
   checks at the AN, but the amount of bandwidth used by the AN to
   perform admission control is negotiable as described in
   Section 6.2.5.2.

6.3.3.  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 only by
   signalling 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, if the AN is to do 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 includes the MRepCtl-CAC TLV in a Provisioning
   message and the Bandwidth-Allocation TLV in a Port Management
   message.  If instead the NAS will do 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, it does not send the MRepCtl-CAC TLV in
   a Provisioning messages to the AN.  The NAS can independently enable
   Admission Control for white flows on the AN by including the White-
   List-CAC TLV in the Provisioning message.

Le Faucheur, et al.     Expires February 23, 2014              [Page 60]
Internet-Draft          ANCP Multicast Extensions            August 2013

6.3.4.  Combinations of Committed Bandwidth Reporting with Other
        Multicast Capabilities

   Committed bandwidth reporting can take place independently of which
   other multicast capabilities have been negotiated.  However, some
   combinations do not make sense because of redundancy.  In particular,
   the NAS obtains the same information that committed bandwidth
   reporting gives if the only other capabilities operating are NAS-
   initiated replication and/or conditional access with grey lists.

7.  Security Considerations

   The security considerations of ANCP are discussed in [RFC6320] and in
   [RFC5713].  Multicast does not in principle introduce any new
   security considerations, although it does increase the attractiveness
   of the ANCP protocol as a means of denial of service (e.g., through
   direction of multicast streams onto the target) or theft of service.

8.  IANA Considerations

   IANA NOTE: Please replace XXXX with the RFC number of this document.

   This document defines the following additional values within the ANCP
   Message Type Name Space registry:

       +--------------+--------------------------------+-----------+
       | Message Type | Message Name                   | Reference |
       +--------------+--------------------------------+-----------+
       | 144          | Multicast Replication Control  | RFC XXXX  |
       |              |                                |           |
       | 145          | Multicast Admission Control    | RFC XXXX  |
       |              |                                |           |
       | 146          | Bandwidth Reallocation Request | RFC XXXX  |
       |              |                                |           |
       | 147          | Bandwidth Transfer             | RFC XXXX  |
       |              |                                |           |
       | 148          | Delegated Bandwidth Query      | RFC XXXX  |
       |              |                                |           |
       | 149          | Multicast Flow Query           | RFC XXXX  |
       |              |                                |           |
       | 150          | Committed Bandwidth Report     | RFC XXXX  |
       +--------------+--------------------------------+-----------+

   This document defines the following additional values for the ANCP
   Result Code registry:

Le Faucheur, et al.     Expires February 23, 2014              [Page 61]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +--------------+------------------------------------+---------------+
   | Result Code  | One-Line Description               | Reference     |
   +--------------+------------------------------------+---------------+
   | 0x64         | Command error.                     | RFC XXXX      |
   |              |                                    |               |
   | 0x65         | Invalid flow address.              | RFC XXXX      |
   |              |                                    |               |
   | 0x66         | Multicast flow does not exist.     | RFC XXXX      |
   |              |                                    |               |
   | 0x67         | Invalid preferred bandwidth        | RFC XXXX      |
   |              | amount.                            |               |
   |              |                                    |               |
   | 0x68         | Inconsistent views of delegated    | RFC XXXX      |
   |              | bandwidth amount.                  |               |
   |              |                                    |               |
   | 0x69         | Bandwidth request conflict.        | RFC XXXX      |
   +--------------+------------------------------------+---------------+

   This document defines the following additional values for the ANCP
   Command Code registry:

   +-----------------+---------------------------------+---------------+
   | Command Code    | Command Code Directive Name     | Reference     |
   | Value           |                                 |               |
   +-----------------+---------------------------------+---------------+
   | 1               | Add                             | RFC XXXX      |
   |                 |                                 |               |
   | 2               | Delete                          | RFC XXXX      |
   |                 |                                 |               |
   | 3               | Delete All                      | RFC XXXX      |
   |                 |                                 |               |
   | 4               | Admission Control Reject        | RFC XXXX      |
   |                 |                                 |               |
   | 5               | Conditional Access Reject       | RFC XXXX      |
   |                 |                                 |               |
   | 6               | Admission Control and           | RFC XXXX      |
   |                 | Conditional Access Reject       |               |
   +-----------------+---------------------------------+---------------+

   This document defines the following additional values within the ANCP
   TLV Type Registry:

        +-----------+--------------------------------+-----------+
        | Type Code | TLV Name                       | Reference |
        +-----------+--------------------------------+-----------+
        | 0x0013    | Multicast-Service-Profile      | RFC XXXX  |

Le Faucheur, et al.     Expires February 23, 2014              [Page 62]
Internet-Draft          ANCP Multicast Extensions            August 2013

        |           |                                |           |
        | 0x0015    | Bandwidth-Allocation           | RFC XXXX  |
        |           |                                |           |
        | 0x0016    | Bandwidth-Request              | RFC XXXX  |
        |           |                                |           |
        | 0x0018    | Multicast-Service-Profile-Name | RFC XXXX  |
        |           |                                |           |
        | 0x0019    | Multicast-Flow                 | RFC XXXX  |
        |           |                                |           |
        | 0x0021    | List-Action                    | RFC XXXX  |
        |           |                                |           |
        | 0x0022    | Sequence-Number                | RFC XXXX  |
        |           |                                |           |
        | 0x0024    | White-List-CAC                 | RFC XXXX  |
        |           |                                |           |
        | 0x0025    | MRepCtl-CAC                    | RFC XXXX  |
        |           |                                |           |
        | 0x0092    | Request-Source-IP              | RFC XXXX  |
        |           |                                |           |
        | 0x0093    | Request-Source-MAC             | RFC XXXX  |
        |           |                                |           |
        | 0x0094    | Report-Buffering-Time          | RFC XXXX  |
        |           |                                |           |
        | 0x0095    | Committed-Bandwidth            | RFC XXXX  |
        +-----------+--------------------------------+-----------+

   This document defines the following additional values for the ANCP
   Capability Type registry:

   +-------+---------------------+--------+--------------+-------------+
   | Value | Capability Type     | Tech   | Capability   | Reference   |
   |       | Name                | Type   | Data?        |             |
   +-------+---------------------+--------+--------------+-------------+
   | 3     | NAS-Initiated       | 0      | No           | RFC XXXX    |
   |       | Replication         |        |              |             |
   |       |                     |        |              |             |
   | 5     | Committed Bandwidth | 0      | No           | RFC XXXX    |
   |       | Reporting           |        |              |             |
   |       |                     |        |              |             |
   | 6     | Conditional Access  | 0      | No           | RFC XXXX    |
   |       | With White and      |        |              |             |
   |       | Black Lists         |        |              |             |
   |       |                     |        |              |             |
   | 7     | Conditional Access  | 0      | No           | RFC XXXX    |
   |       | With Grey Lists     |        |              |             |
   |       |                     |        |              |             |
   | 8     | Bandwidth           | 0      | No           | RFC XXXX    |

Le Faucheur, et al.     Expires February 23, 2014              [Page 63]
Internet-Draft          ANCP Multicast Extensions            August 2013

   |       | Delegation          |        |              |             |
   +-------+---------------------+--------+--------------+-------------+

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.  Kristian Poscic provided the committed
   bandwidth reporting use case.

10.  References

10.1.  Normative References

   [IEEE48]   IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
              EUI48.html", 2010.

   [IEEE64]   IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
              EUI64.html", 2010.

   [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.

   [RFC6320]  Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
              Taylor, "Protocol for Access Node Control Mechanism in
              Broadband Networks", RFC 6320, October 2011.

10.2.  Informative References

   [I-D.morin-mboned-igmpmld-error-feedback]

Le Faucheur, et al.     Expires February 23, 2014              [Page 64]
Internet-Draft          ANCP Multicast Extensions            August 2013

              Morin, T. and B. Haberman, "IGMP/MLD Error Feedback",
              draft-morin-mboned-igmpmld-error-feedback-02 (work in
              progress), November 2008.

   [PIMreg]   IANA, "http://www.iana.org/assignments/pim-parameters/pim-
              parameters.xhtml", 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC5384]  Boers, A., Wijnands, I., and E. Rosen, "The Protocol
              Independent Multicast (PIM) Join Attribute Format", RFC
              5384, November 2008.

   [RFC5713]  Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
              Threats and Security Requirements for the Access Node
              Control Protocol (ANCP)", RFC 5713, January 2010.

   [RFC5851]  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",
              RFC 5851, May 2010.

Appendix A.  Example of Messages and Message Flows

   This appendix provides an example in which most of the possible
   message flows for multicast control are illustrated.  This appendix
   is for informational purposes only.  In case of discrepancy with text
   of the body of this document, the text in the body of the document is
   to be considered as the normative text.

   Assume the following, for a given access port:

   o  The basic subscribed service is white-listed.  The AN will be
      responsible for admission control for this service.

   o  Some premium services are available, but requests for these
      services must be referred to the policy server for proper credit
      processing.  For this reason they are grey-listed.  The NAS will
      be responsible for admission control for these services.

   o  The subscriber has asked that certain services be blocked so that
      his children cannot view them.  These services are black-listed.

   o  All of the above services are Source-Specific Multicast (SSM).  In
      addition, by means which bypass the AN, the subscriber can signal
      intent to join an on-line game service which is Any Source

Le Faucheur, et al.     Expires February 23, 2014              [Page 65]
Internet-Draft          ANCP Multicast Extensions            August 2013

      Multicast (ASM).  The NAS is responsible for admission control for
      this service.

   o  Bandwidth delegation is in effect to share video bandwidth between
      the AN and the NAS.

   The stated conditions require the use of four of the five
   capabilities specified in this memo.

A.1.  Provisioning Phase

   Assume that capability negotiation has been completed between the AN
   and NAS and that the set of negotiated capabilities includes the
   following four multicast capabilities: NAS-initiated replication,
   conditional access with white and black list, conditional access with
   grey list, and bandwidth delegation.  At this point, the NAS can
   provision the service profiles on the AN and enable admission control
   at the AN for white-listed flows.  To do this, the NAS sends the AN a
   Provisioning message containing this information.  An example message
   providing the profile for our assumed subscriber is shown in Figure
   20.  The message has the following contents:

   o  Message type is 93.

   o  The Result and Result Code fields in the header are set to zeroes,
      as specified [RFC6320].

   o  A Transaction identifier is assigned by the NAS.

   o  The Multicast-Service-Profile TLV (of which typically there would
      be multiple instances) contains a Multicast-Service-Profile-Name
      TLV (with a length of 20 octets assumed for the example) and three
      List-Action TLVs, one each for the white, grey, and black lists
      within the profile.  The white list flows come in two sets of
      group addresses: 233.252.0.0/29, coming from a server at
      192.0.2.15, and 233.252.0.32/29, coming from a server at
      192.0.2.16.  The grey-listed flows are in the band 233.252.0.64/
      29, coming from a server at 192.0.2.21.  Finally, the black list
      flows are two individual flows that happen to overlap with the
      grey list band: 233.252.0.65, and 233.252.0.69, also with source
      192.0.2.21.

   o  The White-List-CAC TLV indicates that the AN does admission
      control on white-listed flows.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 66]
Internet-Draft          ANCP Multicast Extensions            August 2013

   |        Type (0x880C)          |           Length = 132        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type = 93 | 0x00  | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |       Length = 132            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | M-Serv-Prof TLV Type = 0x13   |       TLV Length = 112        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | M-S-Prof-Name TLV Type = 0x18 |  Embedded TLV Length = 20     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Multicast service profile name               |
   ~                  = "Cust 0127-53681-0003"                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | List-Action TLV Type = 0x21   |   Embedded TLV Length = 28    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Oper = 0x01   |Lst Typ = 0x01 |        Reserved = 0x0000      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family = 0x01         |       List Length = 20        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | G Preflen = 29| S Preflen = 32| Group prefix =                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      233.252.0.0              | Source prefix =               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      192.0.2.15               | G Preflen = 29| S Preflen = 32|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Group prefix = 233.252.0.32                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source prefix = 192.0.2.15                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | List-Action TLV Type = 0x21   |   Embedded TLV Length = 18    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Oper = 0x01   |Lst Typ = 0x03 |        Reserved = 0x0000      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family = 0x01         |       List Length = 10        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | G Preflen = 29| S Preflen = 32| Group prefix =                /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /      233.252.0.64             | Source prefix =               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /      192.0.2.21               |   Padding = 0x0000            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | List-Action TLV Type = 0x21   |   Embedded TLV Length = 28    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Oper = 0x01   |Lst Typ = 0x02 |        Reserved = 0x0000      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 67]
Internet-Draft          ANCP Multicast Extensions            August 2013

   | Address Family = 0x01         |       List Length = 20        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | G Preflen = 32| S Preflen = 32| Group prefix =                /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /      233.252.0.65             | Source prefix =               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /      192.0.2.21               | G Preflen = 32| S Preflen = 32|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Group prefix = 233.252.0.69                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source prefix = 192.0.2.21                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |White-List-CAC TLV Type = 0x24 |          TLV Length = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 20: Example Provisioning Message

   TLV lengths in the figure are given in decimal for easier
   understanding.  Note that the padding after the middle List-Action
   TLV is counted as part of length of the Multicast-Service-Profile
   TLV, but is not included in the length of that List-Action TLV.  Note
   also that the Length field in the message header, unlike those in the
   TLVs, includes the message header itself, as required by [RFC6320].
   Finally, note that the Provisioning message does not include a
   MRepCtl-CAC TLV since in our example admission control for grey
   listed flows and for NAS-initiated replication is performed by the
   NAS.

   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 Management message that, together with the other
   parameters, includes the multicast service profile name to be
   associated to that port along with the initial amount of delegated
   bandwidth.  The corresponding message flow is illustrated in Figure
   21.

    +----------+      +---------+               +-----+             +-----+
    |Subscriber|      |  Home   |               | AN  |             | NAS |
    +----------+      | Gateway |               +-----+             +-----+
         |            +---------+                 |                     |
         |                 |                      |                     |
         |                 |                      |                     |
         |                 |      DSL Synch.      |                     |
         |                 |--------------------->|                     |
         |                 |                      |(M1)PORT_UP(Port ID) |
         |                 |                      |-------------------->|
         |                 |                      |                    (*)

Le Faucheur, et al.     Expires February 23, 2014              [Page 68]
Internet-Draft          ANCP Multicast Extensions            August 2013

         |                 |                      |(M2) PORT_MNGT       |
         |                 |                      |    (Port ID,        |
         |                 |                      |Mcast S Profile Name,|
         |                 |                      |Bandwidth Allocation)|
         |                 |                      |<--------------------|

   (*) The NAS may optionally seek direction from an external
       Autorization/Policy Server

    Figure 21: Configuring an AN Port With Multicast Service Profile ID
                      and Delegated Bandwidth Amount

   The Port Management message will typically contain other TLVs but our
   example (Figure 22) just shows the Target, Multicast-Service-Profile-
   Name, and Bandwidth-Allocation TLVs.  The Target TLV identifies the
   subscriber line, the Multicast-Service-Profile-Name TLV is identical
   to the one contained in the Provisioning message, and the Bandwidth-
   Allocation TLV provides just enough bandwidth (2000 kbits/s) for one
   channel to start with.

   The following fields in the Port Management message header are shown
   with specific values either as directed by the base protocol document
   or for the sake of our example:

   o  Message Type is 32.

   o  Result is set to Nack (0x01) for this example.

   o  Result Code is 0x000.

   o  Port is set to 0.

   o  Event Sequence Number, the R flag and the other bits marked x,
      Duration, the Event Flags, and the Flow Control Flags are all
      irrelevant for this function and are set to 0.

   o  Function is set to 0x8, "Configure Connection Service Data".

   o  X-Function is set to 0.

   o  Tech Type is 0x05 (DSL).

   o  Block lengths are calculated assuming a Circuit-Id length of 4 in
      our example.  Recall that the example Multicast-Service-Profile-
      Name TLV length is 20.

Le Faucheur, et al.     Expires February 23, 2014              [Page 69]
Internet-Draft          ANCP Multicast Extensions            August 2013

                        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 (0x880C)          |           Length = 84         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type = 32 | 0x01  |  Result Code = 0x000  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 84         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port = 0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number = 0                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x| Duration = 0  | Function = 0x8| X-Function = 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Event Flags         |        Flow Control Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Msg Type = 32 |Tech Type=0x05 | Blk Len = 56  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs = 3             | Extension Block length = 44   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Target TLV Type = 0x1000      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | M-S-Prof-Name TLV Type = 0x18 |       TLV Length = 20         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Multicast service profile name               |
   ~                  = "Cust 0127-53681-0003"                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BW Alloc TLV Type = 0x15   |       TLV Length = 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Bandwidth value = 0x000007D0 (2000 kbits/s)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 22: Example Port Management Message

A.2.  Handling a Grey-Listed Flow

   Suppose now that the subscriber chooses to watch the premium channel
   characterized by source 192.0.2.21, group 233.252.0.67.  Upon

Le Faucheur, et al.     Expires February 23, 2014              [Page 70]
Internet-Draft          ANCP Multicast Extensions            August 2013

   receiving the Join request, the AN matches it against the multicast
   service profile for the port and determines that it is a grey-listed
   flow.  Figure 23 illustrates the resulting ANCP message flow for the
   case of a simple join and leave, when admission control for grey-
   listed flows is not activated on the AN.

   To start the flow, the AN sends a Multicast Admission Control request
   (M1) to the NAS.  The NAS decides whether flow can be admitted,
   applying both policy and bandwidth criteria.  It returns its decision
   (positive in this example) in a Multicast Replication Control message
   (M2).  Later, when the subscriber leaves the flow, the AN informs the
   NAS by sending another Multicast Admission Control message.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |     Multicast     |
         |      Join(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M1) |
         |           |           |------------------>|
         |           |           |                   |  (NAS performs
         |           |           |     Multicast     |   admission
         |           |           |     Replication  (*)  control)
         |           |           |     Control (M2)  |
         |     Mcast Grey Flow   |<------------------|
         |<======================+                   |
         |           |           |                   |
         ~           ~           ~                   ~
         |           |           |     Multicast     |
         |     Leave(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M3) |
         |           |           |------------------>|
         |           |           |                   |

   Grey-Fl   : Multicast Flow matching an entry in grey List

   (*) The NAS may optionally seek direction from an external
   Authorization/Policy Server

       Figure 23: Successful Join/Leave Operations, Grey-Listed Flow

   The Multicast Admission Control message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 145 - Multicast Admission Control;

Le Faucheur, et al.     Expires February 23, 2014              [Page 71]
Internet-Draft          ANCP Multicast Extensions            August 2013

      *  Result= 0x0 (Ignore);

      *  Transaction-ID = Transaction-ID maintained by AN;

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  Command Code = Add (1);

      *  Accounting = 0;

      *  a Multicast-Flow embedded TLV indicating the SSM multicast flow
         (Flow Type = 0x02) for which the AN received the IGMP Join:
         IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source
         Address = 192.0.2.21;

      *  a Request-Source-IP embedded TLV containing the IGMP join
         source IP (192.0.2.100).

   The Multicast Admission Control message M1 is illustrated in Figure
   24:

                        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 (0x880C)          |           Length = 98         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=145  | 0x0   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 98         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Command TLV Type  = 0x11     |       TLV Length = 28         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cmd Code=0x01 |Acctg = 0x00   |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Multicast-Flow TLV Type = 0x19 |   Embedded TLV Length = 12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |Addr Fam =0x01 |     Reserved = 0x0000         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 72]
Internet-Draft          ANCP Multicast Extensions            August 2013

   |             Multicast Group Address = 233.252.0.67            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unicast Source Address =  192.0.2.21            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   | Req-Src-IP TLV Type = 0x92    |   Embedded TLV length = 4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Unicast Address = 192.0.2.100                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 24: Multicast Admission Control Message Seeking To Add A Flow

   The Multicast Replication Control message M2 contains:

   o  an ANCP Header with:

      *  Message Type = 144 - Multicast Replication Control;

      *  Result= 0x1 (NAck);

      *  Transaction-ID = Transaction-ID maintained by NAS;

   o  a Target TLV identifying the AN Port;

   o  a Command TLV containing:

      *  Command Code = Add (1);

      *  Accounting = 1 (begin flow accounting), since in our example
         the operator wants accounting on this flow.

      *  a Multicast-Flow embedded TLV indicating the SSM multicast flow
         (Flow Type = 0x02) that the NAS is admitting for this access
         port: IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01)
         Source Address = 192.0.2.21.

   The Multicast Admission Control message M2 is illustrated in Figure
   25.

                        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 (0x880C)          |           Length = 48         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=144  | 0x1   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 48         |

Le Faucheur, et al.     Expires February 23, 2014              [Page 73]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Command TLV Type  = 0x11     |       TLV Length = 20         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cmd Code=0x01 | Acctg = 0x01  |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Multicast-Flow TLV Type = 0x19 |   Embedded TLV Length = 12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |Addr Fam =0x01 |     Reserved = 0x0000         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Multicast Group Address = 233.252.0.67            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unicast Source Address =  192.0.2.21            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 25: Multicast Replication Control Message Admitting A Flow

   The Multicast Admission Control message M3 advising the NAS that the
   flow has been terminated contains:

   o  an ANCP Header with:

      *  Message-Type = 145 - Multicast Admission Control

      *  Result= 0x0 (Ignore)

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Delete (2);

      *  Accounting = 0;

      *  a Multicast-Flow embedded TLV indicating the SSM multicast flow
         (Flow Type = 0x02) for which the AN received the IGMP leave:
         IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source
         Address = 192.0.2.21.

      *  a Request-Source-IP embedded TLV containing the IGMP leave
         request source, IPv4 (0x01) address 192.0.2.100.

Le Faucheur, et al.     Expires February 23, 2014              [Page 74]
Internet-Draft          ANCP Multicast Extensions            August 2013

   The Multicast Admission Control message M3 is illustrated in Figure
   26.

                        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 (0x880C)          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=145  | 0x0   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Command TLV Type  = 0x11     |       TLV Length = 28         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cmd Code=0x02 |Acctg = 0x00   |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Multicast-Flow TLV Type = 0x19 |   Embedded TLV Length = 12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |Addr Fam =0x01 |     Reserved = 0x0000         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Multicast Group Address = 233.252.0.67            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unicast Source Address =  192.0.2.21            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Req-Src-IP TLV Type = 0x92    |   Embedded TLV length = 4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Unicast Address = 192.0.2.100                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 26: Multicast Admission Control Message Signalling Flow
                                Termination

A.3.  Handling White-Listed Flows

   The NAS has enabled white list admission control on the AN, and the
   bandwidth delegation capability has been negotiated.  White listed
   flows in themselves require no messages to the NAS, either upon
   admission or upon termination, but the AN may request an increase in
   the amount of delegated bandwidth if it needs the increase to admit a
   flow.

Le Faucheur, et al.     Expires February 23, 2014              [Page 75]
Internet-Draft          ANCP Multicast Extensions            August 2013

   Consider an example where the AN has already admitted one white-
   listed flow, thereby using up the initially provisioned amount of
   delegated bandwidth (2000 kbits/s).  A request is received to join a
   new flow in the white list range.  The AN chooses to send a Bandwidth
   Reallocation Request message to the NAS, requesting that the
   delegated bandwidth allocation be increased to 4000 kbits/s at a
   minimum, and preferably to 6000 kbits/s.

   In our example, the NAS is managing bandwidth tightly, as witnessed
   by its minimal initial allocation of just enough for one flow.  It is
   willing to provide the minimum additional amount only, and therefore
   returns a Bandwidth Transfer message where the delegated bandwidth
   value is given as 4000 kbits/s. With this amount, the AN is able to
   admit the second white-listed flow.  The AN could send a similar
   Bandwidth Transfer message back to the NAS bringing the delegated
   bandwidth amount back down to 2000 kbits/s when one of the flows is
   terminated, but this shows nothing new and is omitted.

   As one more point of illustration, suppose that the NAS chooses to
   audit the current amount of delegated bandwidth to ensure it is
   synchronized with the AN.  It sends a Delegated Bandwidth Query
   request message to the AN, and receives a Delegated Bandwidth Query
   response message with the current allocation as the AN sees it.

   The complete message flow is shown in Figure 27.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |      Join(White-F1)   |                   |
         |-----------+---------->|                   |
         |           |           |AN performs        |
         |  Mcast White Flow 1   | admission control |
         |<======================+                   |
         |           |           |                   |
         |      Join(White-F2)   |                   |
         |-----------+---------->|No bandwidth left  |
         |           |           |                   |
         |           |           |Bandwidth          |
         |           |           | Reallocation Req  |
         |           |           |------------------>|(M1)
         |           |           |                   |
         |           |           |                  (*)
         |           |           |Bandwidth Transfer |
         |           AN can now  |<------------------|(M2)
         |           admit flow  |                   |

Le Faucheur, et al.     Expires February 23, 2014              [Page 76]
Internet-Draft          ANCP Multicast Extensions            August 2013

         |   Mcast White Flow 2  |                   |
         |<======================+                   |
         |           |           |                   |
         ~           ~           ~                   ~
         |           |           |Delegated Bandwidth|
         |           |           | Query request     |
         |           |           |<------------------|(M3)
         |           |           |                   |
         |           |           |Delegated Bandwidth|
         |           |           | Query response    |
         |           |           |------------------>|(M4)
         |           |           |                   |

   (*) The NAS may optionally seek direction from an external
   Authorization/Policy Server

      Figure 27: Successful Join/Leave Operations, White-Listed Flow

   The Bandwidth Reallocation Request message (M1) is shown in Figure
   28.  The contents require little explanation.  The Message Type for
   the Bandwidth Reallocation Request is 146.  The Result field is set
   to 0x0 (Ignore).  Besides the Target, the message has one other TLV,
   the Bandwidth-Request, with a TLV Type of 0x16.  The TLV contains
   Required Amount and Preferred Amount fields, set to 4000 and 6000
   kbits/s respectively.

                        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 (0x880C)          |           Length = 36         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=146  | 0x0   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 36         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Bandwidth-Req TLV Type = 0x16  |          TLV Length = 8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Required Amount = 0x00000FA0 (4000 kbits/s)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Preferred Amount = 0x00001770 (6000 kbits/s)         |

Le Faucheur, et al.     Expires February 23, 2014              [Page 77]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 28: Bandwidth Reallocation Request Message

   The Bandwidth Transfer message (M2) is shown in Figure 29.  Again,
   the contents are easily understood.  The Message Type for the
   Bandwidth Transfer message is 147.  The Result field is set to
   Success (0x3).  The message contains the Target TLV and the
   Bandwidth-Allocation TLV.  The latter has a TLV Type of 0x15 and
   contains a Delegated Amount field, set to 4000 kbits/s.

                        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 (0x880C)          |           Length = 32         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=147  | 0x3   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 32         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |BW-Allocation TLV Type = 0x15  |          TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Delegated Amount = 0x00000FA0 (4000 kbits/s)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 29: NAS Response, Bandwidth Transfer Message

   The Delegated Bandwidth Query request message (M3) is shown in Figure
   30.  The Message Type for the Delegated Bandwidth Query request
   message is 148.  The Result field is set to AckAll (0x2).  The
   message contains the Target TLV only.

                        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 (0x880C)          |           Length = 24         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=148  | 0x2   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |

Le Faucheur, et al.     Expires February 23, 2014              [Page 78]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 24         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 30: Delegated Bandwidth Query Request Message

   Finally, the Delegated Bandwidth Query response message (M4) is shown
   in Figure 31.  The Message Type for the Delegated Bandwidth Query
   response message is 148.  The Result field is set to Success (0x3).
   The message contains the Target TLV and the Bandwidth-Allocation TLV
   with the Delegated Amount field set to 4000 kbits/s.

                        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 (0x880C)          |           Length = 32         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=148  | 0x3   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  | Transaction Identifier (copied from request)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 32         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |BW-Allocation TLV Type = 0x15  |          TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Delegated Amount = 0x00000FA0 (4000 kbits/s)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 31: Delegated Bandwidth Query Response Message

A.4.  Handling Of Black-Listed Join Requests

   This section introduces no new messages, since requests for flows in
   the black list are simply ignored.  The one thing to point out is the
   overlap in our example between the set of flows in the grey list and
   the flows in the black list.  This does not create any ambiguity,

Le Faucheur, et al.     Expires February 23, 2014              [Page 79]
Internet-Draft          ANCP Multicast Extensions            August 2013

   since not only does the black list have priority for equally good
   matches, but also the black list entries are more specific (group
   prefix lengths of 32 versus 29 in the grey list) than the grey list
   flow prefixes.

A.5.  Handling Of Requests To Join and Leave the On-Line Game

   The final class of multicast control actions in our example allows
   the subscriber to enter and leave the on-line game.  As described at
   the beginning of this example, the game uses Any Source Multicast
   (ASM).  Subscriber signalling bypasses the AN, going directly to the
   NAS (e.g., through a web interface).

   When the subscriber requests to join the game, the NAS (after
   applying policy and bandwidth checks) sends a Multicast Replication
   Control message to the AN to enable the flow on the port concerned.
   The AN knows not to apply admission control, since it has not
   received an MRepCtl-CAC TLV in the Provisioning message.  When the
   subscriber leaves, the NAS sends another Multicast Replication
   Control message to delete the flow.  This message sequence is shown
   in Figure 32.

   It is possible that the NAS finds that there is not enough bandwidth
   available to accommodate the subscriber's request.  In this case, the
   NAS could send a Bandwidth Reallocation Request message to the AN,
   asking it to release some of the bandwidth delegated to it.  This is
   not shown in the present example, since the messages are the same as
   those already presented with the exception that the Preferred Amount
   in the request will be *less than* or equal to the Required amount,
   rather than *greater than* or equal to it.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |      Join game        |                   |
         |-----------+------------------------------>|
         |           |           |     Multicast     |   NAS performs
         |           |           |     Replication  (*)  admission
         |           |           |     Control (M1)  |   control
         |     Mcast Game Flow   |<------------------|
         |<=====================>+                   |
         |           |           |                   |
         ~           ~           ~                   ~
         |           |           |                   |
         |     Leave game        |                   |
         |-----------+------------------------------>|

Le Faucheur, et al.     Expires February 23, 2014              [Page 80]
Internet-Draft          ANCP Multicast Extensions            August 2013

         |           |           |     Multicast     |
         |           |           |     Replication   |
         |           |           |     Control (M2)  |
         |     Mcast Game Flow   |<------------------|
         |       discontinued    |                   |
         |           |           |                   |

   (*) The NAS may optionally seek direction from an external
   Authorization/Policy Server

             Figure 32: NAS-Initiated Flows For On-Line Gaming

   Multicast Replication Control message (M1) in Figure 33 looks like
   the message in Figure 25 with two exceptions.  The first is that the
   NAS has the option to set the Result field to AckAll (0x02) if it
   needs positive reassurance that the flow has been enabled.  This was
   not done here to save having to depict a response differing only in
   the Result field.  The larger difference in this example is that the
   flow description in the Multicast-Flow embedded TLV is that of an ASM
   multicast group (Flow Type = 0x01) with IPv4 (0x01) group address
   233.252.1.100.

                        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 (0x880C)          |           Length = 44         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type=144  | 0x1   | Result Code = 0x000   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length = 44         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length = 8  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Access Loop Circuit ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Command TLV Type  = 0x11     |       TLV Length = 16         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cmd Code=0x01 | Acctg = 0x01  |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Multicast-Flow TLV Type = 0x19 |    Embedded TLV Length = 8    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x01 |Addr Fam =0x01 |     Reserved = 0x0000         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Multicast Group Address =  233.252.1.100           |

Le Faucheur, et al.     Expires February 23, 2014              [Page 81]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

        Figure 33: Enabling The Subscriber To Join An On-Line Game

   Message M2 terminating the flow when the subscriber leaves the game
   looks the same as the message in Figure 33 with two exceptions: the
   Command Code becomes Delete (2), and Accounting is set to 0 to turn
   off flow accounting.  Of course, the Transaction Identifier values
   will differ between the two messages.

A.6.  Example Flow For Multicast Flow Reporting

   The example in this section is independent of the example in the
   preceding sections.

   Figure 34 illustrates a message flow in a case where the NAS queries
   the AN about which multicast flows are active on port 10, on port 11
   and on port 20 of the AN.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |             |         |  Multicast Flow   |
         |             |         |  Query Request    |
         |             |         |      (M1)         |
         |             |         |<------------------|
         |             |         |                   |
         |             |         | Multicast Flow    |
         |             |         | Query Response    |
         |             |         |      (M2)         |
         |             |         |------------------>|
         |             |         |                   |
         |             |         |                   |

               Figure 34: Per-Port Multicast Flow Reporting

   The Multicast Flow Query Request message (M1) is illustrated in
   Figure 35.  The Message Type is 149.  The Result field is set to
   AckAll (0x2).  Three Target TLVs are present, identifying port 10,
   port 20, and port 11 respectively.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type (0x880C)          |           Length              |

Le Faucheur, et al.     Expires February 23, 2014              [Page 82]
Internet-Draft          ANCP Multicast Extensions            August 2013

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type = 149|Rslt=2 |    Result 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 35: Multicast Flow Query Request Message For Per-Port
                         Multicast Flow Reporting

   The Multicast Flow Query Response message (M2) is illustrated in
   Figure 36.  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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type (0x880C)          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     | Msg Type = 149|Rslt=3 |    Result Code = 0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 83]
Internet-Draft          ANCP Multicast Extensions            August 2013

   | 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)             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Multicast-Flow TLV Type = 0x19 |    Embedded TLV Length = 12   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |Addr Fam =0x01 |       Reserved = 0x0000       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Multicast Group Address = 233.252.2.4             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Unicast Source Address = 192.0.2.1             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |   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)            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Multicast-Flow TLV Type = 0x19 |    Embedded TLV Length = 12   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |Addr Fam =0x01 |       Reserved = 0x0000       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Multicast Group Address = 233.252.2.4             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Unicast Source Address = 192.0.2.1             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |Multicast-Flow TLV Type = 0x19 |   Embedded TLV Length = 12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Type=0x02 |Addr Fam =0x01 |       Reserved = 0x0000       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al.     Expires February 23, 2014              [Page 84]
Internet-Draft          ANCP Multicast Extensions            August 2013

   |             Multicast Group Address: 233.252.2.10             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Unicast Source Address = 192.0.2.2             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

       Figure 36: Multicast Flow Query Response message For Per-Port
                         Multicast Flow Reporting

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
   Cisco Systems
   181 Bay Street
   Toronto, ON  M5J 2T3
   Canada

   Email: robmgl@cisco.com

   Tom Taylor
   Huawei Technologies
   Ottawa
   Canada

   Email: tom.taylor.stds@gmail.com

Le Faucheur, et al.     Expires February 23, 2014              [Page 85]