ANCP                                                      F. Le Faucheur
Internet-Draft                                                     Cisco
Intended status: Standards Track                             R. Maglione
Expires: January 4, April 29, 2010                                   Telecom Italia
                                                               T. Taylor
                                                                  Huawei
                                                            July 3,
                                                        October 26, 2009

            Additional Multicast Control Extensions for ANCP
                  draft-ietf-ancp-mc-extensions-00.txt
                  draft-ietf-ancp-mc-extensions-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 4, April 29, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies the extensions to the Access Node Control
   Protocol required for support of the multicast use cases defined in
   the Access Node Control Protocol framework document.  Those use cases
   are organized into the following ANCP capabilities:

   o  NAS-initiated multicast replication;

   o  conditional access with white and black lists;

   o  conditional access with grey lists;

   o  bandwidth delegation.

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5  7
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6  9
   3.  Multicast Use Cases  . . . . . . . . . . . . . . . . . . . . .  7 10
     3.1.  NAS Initiated Multicast Replication Control Use Case . . .  7 10
       3.1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . .  7 10
       3.1.2.  Message Flow . . . . . . . . . . . . . . . . . . . . .  8 11
     3.2.  Conditional Access and Admission Control Use Case  . . . .  8 11
       3.2.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . .  8 11
       3.2.2.  Message Flow . . . . . . . . . . . . . . . . . . . . .  9 12
     3.3.  Multicast Flow Reporting Use Case  . . . . . . . . . . . .  9 13
       3.3.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . .  9 13
       3.3.2.  Message Flow . . . . . . . . . . . . . . . . . . . . . 10 13
   4.  ANCP Messages  . . . . . . . . . . . . . . . . . . . . . . . . 11 14
     4.1.  Provisioning Message . . . . . . . . . . . . . . . . . . . 11
     4.2.  Port Management Message  . . 14
       4.1.1.  Sender Behaviour . . . . . . . . . . . . . . . 11
     4.3.  Multicast Replication Control Message . . . . 14
       4.1.2.  Receiver Behaviour . . . . . . 12
     4.4.  Multicast Status Message . . . . . . . . . . . . 15
     4.2.  Port Management Message  . . . . . 17
     4.5.  Multicast Admission Control Message . . . . . . . . . . . 20
     4.6.  Bandwidth Reallocation Request Message . 16
       4.2.1.  Sender Behaviour . . . . . . . . . 23
     4.7.  Bandwidth Transfer Message . . . . . . . . . . 16
       4.2.2.  Receiver Behaviour . . . . . . 25
     4.8.  Delegated Bandwidth Query Request and Response Messages . 26
     4.9.  Multicast Flow Query Request and Response Messages . . . . 28
     4.10. Delegated Bandwidth Reset Procedure . . . . . . . 17
     4.3.  Multicast Replication Control Message  . . . . 30
   5.  ANCP TLVs and Sub-TLVs . . . . . . 17
       4.3.1.  Sender Behaviour . . . . . . . . . . . . . . 32
     5.1.  Multicast-Service-Profile TLV . . . . . 21
       4.3.2.  Receiver Behaviour . . . . . . . . . 32
       5.1.1.  Profile Processing At the Access Node . . . . . . . . 34
     5.2.  Bandwidth-Delegation-Control TLV . 22
     4.4.  Multicast Admission Control Message  . . . . . . . . . . . 24
       4.4.1.  Sender Behaviour . 36
     5.3.  Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 37
     5.4.  Bandwidth-Request TLV . 25
       4.4.2.  Receiver Behaviour . . . . . . . . . . . . . . . . . 38
     5.5.  Bandwidth-Status TLV . 26
     4.5.  Bandwidth Reallocation Request Message . . . . . . . . . . 27
       4.5.1.  Sender Behaviour . . . . . . . . 38
     5.6.  Multicast-Service-Profile-Name TLV . . . . . . . . . . . 28
       4.5.2.  Receiver Behaviour . 39
     5.7.  Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 39
     5.8.  Request-Source-MAC sub-TLV . 28
     4.6.  Bandwidth Transfer Message . . . . . . . . . . . . . . . 40
     5.9.  Multicast-Flow TLV . 30
       4.6.1.  Sender Behaviour . . . . . . . . . . . . . . . . . . . 41
   6.  New Capabilities 31
       4.6.2.  Receiver Behaviour . . . . . . . . . . . . . . . . . . 31
     4.7.  Delegated Bandwidth Query Request Message  . . . . . 43
   7.  Example of Messages and Message Flows . . . 32
       4.7.1.  Sender Behaviour . . . . . . . . . 45
     7.1.  Multicast Conditional Access and CAC without AN
           Bandwidth Delegation . . . . . . . . . . 33
       4.7.2.  Receiver Behaviour . . . . . . . . . 45
       7.1.1.  List/Profile Provisioning . . . . . . . . . 33
     4.8.  Delegated Bandwidth Query Response Message . . . . . 45
       7.1.2.  Profile Mapping . . . 33
       4.8.1.  Sender Behaviour . . . . . . . . . . . . . . . . 47
       7.1.3.  Successful Join/Leave Operations . . . 34
       4.8.2.  Receiver Behaviour . . . . . . . . 47
       7.1.4.  Admission Control Reject without NAS Response . . . . 53
       7.1.5.  Admission Control Reject with NAS Response . . . . . . 55
     7.2.  Example Flows For Bandwidth Delegation 34
     4.9.  Multicast Flow Query Request and Response Messages . . . . 35
       4.9.1.  Sender Behaviour . . . . . . 59
       7.2.1.  Activation . . . . . . . . . . . . . 35
       4.9.2.  Receiver Behaviour . . . . . . . . . . . . . . . . . . 36
   5.  ANCP TLVs and Provisioning of Delegated Bandwidth Sub-TLVs . . 60
       7.2.2.  Successful Request For More Delegated Bandwidth . . . 61
       7.2.3.  Failed Autonomous Transfer With Reset . . . . . . . . 63
     7.3.  Example Flows For Multicast Flow Reporting . . . . . . . 38
     5.1.  Multicast-Service-Profile TLV  . 66
       7.3.1.  Per Port Multicast Flow Reporting . . . . . . . . . . 66
   8.  Security Considerations . . . 38
     5.2.  Command Number TLV . . . . . . . . . . . . . . . . 71
   9.  IANA Considerations . . . . 41
     5.3.  Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 72
   10. Acknowledgements 41
     5.4.  White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 42
     5.5.  MRepCtl-CAC TLV  . . . 76
   11. References . . . . . . . . . . . . . . . . . . 42
     5.6.  Bandwidth-Request TLV  . . . . . . . . 77
     11.1. Normative References . . . . . . . . . . 42
     5.7.  Multicast-Service-Profile-Name TLV . . . . . . . . . 77
     11.2. Informative References . . . 43
     5.8.  Request-Source-IP sub-TLV  . . . . . . . . . . . . . . . 77
   Authors' Addresses . 43
     5.9.  Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 44
     5.10. Multicast-Flow TLV . . . . . . . 79

1.  Introduction

   [I-D.ietf-ancp-framework] defines a framework and . . . . . . . . . . . . . 45
   6.  Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 46
     6.1.  Required Protocol Support  . . . . . . . . . . . . . . . . 46
       6.1.1.  Protocol Requirements For NAS-initiated Replication  . 46
       6.1.2.  Protocol requirements for an
   Access Node control mechanism between a Network For Conditional Access Server (NAS) With
               White and an Access Node (e.g. a Digital Subscriber Line Black Lists  . . . . . . . . . . . . . . . . 47
       6.1.3.  Protocol requirements For Conditional Access Multiplexer
   (DSLAM)) in a multi-service reference architecture in order to
   perform QoS-related, service-related and subscriber-related
   operations.  [I-D.ietf-ancp-protocol] specifies a protocol for Access
   Node Control in broadband networks in line with this framework.

   The Access Node Control With
               Grey Lists . . . . . . . . . . . . . . . . . . . . . . 48
       6.1.4.  Protocol (ANCP) specified in
   [I-D.ietf-ancp-protocol] supports a number of use cases defined in
   [I-D.ietf-ancp-framework] such as the Access Topology Discovery use
   case, the requirements For Delegated Bandwidth  . . . . 49
     6.2.  Capability-Specific Procedures for Providing Multicast
           Service  . . . . . . . . . . . . . . . . . . . . . . . . . 50
       6.2.1.  Procedures For NAS-initiated Replication . . . . . . . 50
       6.2.2.  Procedures For Conditional Access Loop Configuration use case With Black and the Remote
   Connectivity Test use case.  However, it does not support the
   multicast use cases defined in [I-D.ietf-ancp-framework].  The
   present document specifies the extensions to the
               White Lists  . . . . . . . . . . . . . . . . . . . . . 51
       6.2.3.  Procedures For Conditional Access Node Control
   Protocol required for support With Grey Lists  . . 52
       6.2.4.  Procedures For Delegated Bandwidth . . . . . . . . . . 53
     6.3.  Combinations of these multicast use cases.

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 Multicast Capabilities . . . . . . . . . . 54
       6.3.1.  Combination of NAS-Initiated Replication with
               Other Capabilities . . . . . . . . . . . . . . . . . . 54
       6.3.2.  Conditional Access With White, Black, and Grey
               Lists  . . . . . . . . . . . . . . . . . . . . . . . . 55
       6.3.3.  Conditional Access Combined With Delegated
               Bandwidth  . . . . . . . . . . . . . . . . . . . . . . 56
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 57
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 58
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 63
     10.2. Informative References . . . . . . . . . . . . . . . . . . 63
   Appendix A.  Example of Messages and Message Flows . . . . . . . . 65
     A.1.  Multicast Conditional Access and CAC without AN
           bandwidth delegation . . . . . . . . . . . . . . . . . . . 65
       A.1.1.  List/Profile Provisioning  . . . . . . . . . . . . . . 65
       A.1.2.  Profile Mapping  . . . . . . . . . . . . . . . . . . . 67
       A.1.3.  Successful Join/Leave Operations . . . . . . . . . . . 67
       A.1.4.  Admission Control Reject without NAS Response  . . . . 73
       A.1.5.  Admission Control Reject with NAS Response . . . . . . 75
     A.2.  Example Flows For bandwidth delegation . . . . . . . . . . 79
       A.2.1.  Activation and Provisioning of total multicast
               Bandwidth  . . . . . . . . . . . . . . . . . . . . . . 80
       A.2.2.  Successful Request For More Multicast Bandwidth  . . . 81
       A.2.3.  Failed Autonomous Transfer With Reset  . . . . . . . . 83
     A.3.  Example Flows For Multicast Flow Reporting . . . . . . . . 86
       A.3.1.  Per Port Multicast Flow Reporting  . . . . . . . . . . 86

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91

1.  Introduction

   [I-D.ietf-ancp-framework] defines a framework and requirements for an
   Access Node control mechanism between a Network Access Server (NAS)
   and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer
   (DSLAM)) in a multi-service reference architecture in order to
   perform QoS-related, service-related and subscriber-related
   operations.  [I-D.ietf-ancp-protocol] specifies a protocol for Access
   Node Control in broadband networks in line with this framework.

   The Access Node Control Protocol (ANCP) specified in
   [I-D.ietf-ancp-protocol] supports a number of use cases defined in
   [I-D.ietf-ancp-framework] such as the Access Topology Discovery use
   case, the Access Loop Configuration use case and the Remote
   Connectivity Test use case.  However, it does not support the
   multicast use cases defined in [I-D.ietf-ancp-framework].  The
   present document specifies the extensions to the Access Node Control
   Protocol required for support of these multicast use cases.  In terms
   of the ANCP protocol, these use cases are organized into four
   capabilities:

   o  NAS-initiated multicast replication;

   o  conditional access with white and black lists;

   o  conditional access with grey lists;

   o  bandwidth delegation.

   NAS-initiated multicast replication assumes that multicast "join" and
   "leave" requests are terminated on the NAS, or that the NAS receives
   requests to establish multicast sessions through other means (e.g.,
   application-level signalling).  The NAS sends commands to the AN to
   start or stop replication of specific multicast flows on specific
   subscriber ports.  This use case is described briefly in the next-to-
   last paragraph of section 3.4 of [I-D.ietf-ancp-framework].

   Conditional access is described in sections 3.4.1 and 3.4.2.3 of
   [I-D.ietf-ancp-framework], with the latter section particularly
   applicable to operation with white and black lists only.  In case of
   "conditional access with white and black lists", multicast join and
   leave requests are terminated at the AN and accepted or ignored in
   accordance with the direction provided by white and black lists
   respectively.  The white and black lists are provisioned per port at
   startup time and may be modified thereafter.  The NAS may enable
   admission control of White-listed flows by appropriate provisioning.
   If the bandwidth delegation capability has also been negotiated, that
   capability provides a means to adjust the multicast bandwidth limits
   at the AN.

   Conditional access with grey lists is similar to conditional access
   with white lists, except that before accepting any request matching a
   grey list entry, the AN sends a request to the NAS for permission to
   replicate the flow.  Again, the NAS can enable admission control of
   Grey-listed flows at the AN.  It can control the application of
   admission control on a per-flow basis.

   Bandwidth delegation is described in section 3.4.2.1 of
   [I-D.ietf-ancp-framework].  It allows flexible sharing of total video
   bandwidth on an access line between the AN and the NAS.  One
   application of such bandwidth sharing is where the AN does multicast
   admission control, while the NAS or Policy Server does unicast
   admission control.  In that case, bandwidth delegation allows dynamic
   sharing of bandwidth between unicast and multicast video traffic on
   each access line.

   The formal specification of the behaviours associated with each of
   these capabilities, singly and in combination, is given in Section 6.

   In addition to the multicast service processing behaviour just
   sketched, the definition of each capability includes support for the
   multicast accounting and reporting services described in section
   3.4.3 of [I-D.ietf-ancp-framework].  Because of this common content
   and because of other protocol overlaps between the different
   capabilities, the protocol descriptions for the multicast extensions
   specified in this document are merged into a single non-redundant
   narrative.  Tables in Section 6 then indicate the specific sub-
   sections of the protocol description that have to be implemented to
   support each capability.

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 video bandwidth delegated to the AN for
   multicast admission control".

3.  Multicast Use Cases

   Quoting from [I-D.ietf-ancp-framework]:

   "... the Access Node, aggregation node(s) and the NAS must all be
   involved in the multicast replication process.  This avoids that
   several copies of the same stream are sent within the access/
   aggregation network.  In case of an Ethernet-based access/aggregation
   network, this may, for example, be achieved by means of IGMP snooping
   or IGMP proxy in the Access Node and aggregation node(s).  By
   introducing IGMP processing in the access/aggregation nodes, the
   multicast replication process is now divided between the NAS, the
   aggregation node(s) and Access Nodes.  In order to ensure backward
   compatibility with the ATM-based model, the NAS, aggregation node and
   Access Node need to behave as a single logical device.  This logical
   device must have exactly the same functionality as the NAS in the ATM
   access/aggregation network.  The Access Node Control Mechanism can be
   used to make sure that this logical/functional equivalence is
   achieved by exchanging the necessary information between the Access
   Node and the NAS.  "

   [I-D.ietf-ancp-framework] describes the use cases for ANCP associated
   with such multicast operations, and identifies the associated ANCP
   requirements.  The present section describes a subset of these use
   cases as background to facilitate reading of this document, but the
   reader is refered to [I-D.ietf-ancp-framework] for a more exhaustive
   description of the ANCP multicast use cases.  Detailed example
   message flows can also be found in Appendix A.

3.1.  NAS Initiated Multicast Replication Control Use Case

3.1.1.  Goals

   One option for multicast handling is for the subscriber to
   communicate the "join/leave" information to the NAS.  This can be
   done for instance by terminating all subscriber IGMP ([RFC3376]) or
   MLD ([RFC2710], [RFC3810]) signaling on the NAS.  Another example
   could be a subscriber using some form of application level signaling,
   which is redirected to the NAS.  In any case, this option is
   transparent to the access and aggregation network.  In this scenario,
   the NAS uses ANCP to create and remove replication state in the AN
   for efficient multicast replication.  Thus, the NAS only sends a
   single copy of the multicast stream towards the AN, which in turn
   performs replication to multiple subscribers as instructed by the NAS
   via ANCP.  The NAS first performs conditional access and multicast
   admission control when processing multicast join requests, and only
   creates replication state in the AN if admission succeeds.

3.1.2.  Message Flow

   With the NAS-initiated use case, a Multicast Replication Control
   Message is sent by the NAS to the AN with a directive to either join
   or leave one (or more) multicast flow(s).  The AN uses a Generic
   Response message to convey the outcome of the directive.  Figure 1
   illustrates such an ANCP message exchange as well as the associated
   AN behavior.

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

           Figure 1: NAS Initiated Multicast Replication Control

3.2.  Conditional Access and Admission Control Use Case

3.2.1.  Goals

   One option for multicast handling is for the access/aggregation nodes
   to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping).
   In this scenario, on detecting a join/leave request from an enduser
   for a multicast flow (in the grey list), the AN uses ANCP to request
   conditional access and admission control decision from the NAS.  In
   turn, after conditional access and admission control checks, the NAS
   uses ANCP to instruct the AN to change the replication states
   accordingly.

3.2.2.  Message Flow

   For support of the conditional access and admission control use case,
   on detection of an IGMP/MLD Join, the AN sends an Admission Control
   message to the NAS to request conditional access and admission
   control check.  In case of positive outcome, the NAS sends a
   Multicast Replication Control Message to the AN with a directive to
   replicate the multicast flow to the corresponding user.  Similarly on
   detection of an IGMP/MLD leave, an Admission Control message is sent
   by the AN to the NAS to keep the NAS aware of user departure for the
   flow.  This message flow is illustrated in Figure 2.

   +----------+    +-------+   +-----+      ANCP           +-----+
   |Subscriber|    | Home  |   | AN  |<------------------->| NAS |
   +----------+    |Gateway|   +-----+                     +-----+
         |         +-------+      |                           |
         |            |           |                           |
         |       Join(Gr-Flow1)   |  Admission-Control        |
         |------------+---------->|   (Target,add,Gr-Flow1)   |
         |            |           |-------------------------->|
         |            |           |                          (*)
         |            |           | Multicast-Replication-Crl |
         |            |           |   (Target,add,Gr-Flow 1)  |
         |            |           |<--------------------------|
         |     Mcast Gr-Flow1     |                           |
         |<=======================+                           |
         |            |           |                           |
         ~            ~           ~                           ~
         |            |           |                           |
         |      Leave(Gr-Flow1)   |  Admission-Control        |
         |------------+---------->| (Target,delete,Gr-Flow1)  |
         |            |           |-------------------------->|
         | <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

       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.

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

                    Figure 3: Multicast Flow 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 5.4.3.1 of [I-D.ietf-ancp-protocol] defines the Provisioning
   message that is sent by the NAS to the AN to provision information in
   the AN.

   The present document specifies that the Provisioning message MAY be
   used by the NAS to provision multicast-related information (e.g.
   multicast service profiles).  The ANCP Provisioning message payload
   MAY contain:

   o  one or more instances of the Multicast-Service-Profile TLV.  The
      Multicast-Service-Profile TLV is defined in the present document
      in Section 5.1.  Each instance of the Multicast-Service-Profile
      TLV contains a Multicast Service Profile name and one or more list
      actions.  A list action consists of an action (add, delete,
      replace), a list type (White, Black, or Grey), and list content
      (multicast source and group addresses).

   o  an instance of the White-List-CAC TLV.  The White-List-CAC TLV is
      defined in section TLV_White_AC.  If present, this TLV indicates
      that the AN is required to do admission control before replicating
      White-listed flows.

   o  an instance of the MRepCtl_CAC TLV.  The MRepCtl-CAC TLV is
      defined in section TLV_MRepCtl_AC.  If present, this TLV indicates
      that the AN for
   multicast may be required to do admission control".

3. control before
      replicating flows specified in Multicast Use Cases

   Quoting from [I-D.ietf-ancp-framework]:

   "... Replication Control
      messages.

   See Section 6 for information on which multicast capabilities require
   support of these TLVs in the Access Node, aggregation node(s) and Provisioning message.

4.1.1.  Sender Behaviour

   When directed by the Policy Server or by management action, the NAS must all be
   involved in
   sends the Provisioning message to initially provision or to update
   the White, Black, and/or Grey multicast replication process.  This avoids that
   several copies channel lists associated with
   a set of named multicast service profiles, or to enable the same stream are sent AN to
   perform admission control for specific classes of flows.

   To provision or update a multicast service profile, the NAS MUST
   include within the access/
   aggregation network.  In case message one or more instances of an Ethernet-based access/aggregation
   network, this may, for example, the Multicast-
   Service-Profile TLV specifying the content to be achieved provisioned or
   updated.  The NAS SHOULD NOT include any list type (White, Black, or
   Grey) that is not supported by means the set of IGMP snooping
   or IGMP proxy in multicast capabilities
   negotiated between the Access Node NAS and aggregation node(s).  By
   introducing IGMP processing in the access/aggregation nodes, AN.  The NAS MUST NOT use the
   Provisioning message to send instances of the Multicast-Service-
   Profile TLV to the
   multicast replication process AN unless the Multicast-Service-Profile TLV is now divided between
   supported by the NAS, set of multicast capabilities negotiated between the
   aggregation node(s)
   NAS and Access Nodes.  In order the AN.

   To require admission control to ensure backward
   compatibility with be performed at the ATM-based model, AN on White-
   listed flows, the NAS, aggregation node NAS MUST include a copy of the White-List-CAC TLV
   in the Provisioning message.  The White-List-CAC TLV MUST NOT be
   provided unless the negotiated set of capabilities includes
   conditional access with White and
   Access Node need Black lists.

   To require admission control to behave as a single logical device.  This logical
   device must have exactly be performed at the same functionality as AN on Grey-listed
   flows or on NAS-initiated flows, the NAS MUST include a copy of the
   MRepCtl-CAC TLV in the ATM
   access/aggregation network. Provisioning message.  The Access Node Control Mechanism can MRepCtl-CAC TLV
   MUST NOT be
   used provided unless the negotiated set of capabilities
   includes NAS-initiated replication control or conditional access with
   Grey lists.

4.1.2.  Receiver Behaviour

   The receiving AN provisions/updates the White, Black, and/or Grey
   lists associated with the Multicast Service Profile names contained
   in the Multicast-Service-Profile TLV instances within the message.
   The AN MUST ignore instances of the Multicast-Service-Profile TLV
   referring to make sure any list type (White, Black, or Grey) that this logical/functional equivalence is
   achieved not
   supported by exchanging the necessary information set of multicast capabilities negotiated between the Access
   Node
   NAS and the NAS.  "

   [I-D.ietf-ancp-framework] describes AN.

   When a new Multicast Service Profile is identified by a Multicast-
   Service-Profile TLV, the initial state of all lists associated with
   that profile according to the negotiated set of multicast
   capabilities is empty until changed by the contents of Multicast-
   Service-Profile TLVs.

   If the use cases for ANCP associated
   with such multicast operations, White-List-CAC and/or MRepCtl-CAC TLV is present in the
   Provisioning message and identifies the respective associated ANCP
   requirements.  The present section describes a subset of these use
   cases as background capabilities have
   been negotiated, the AN prepares to facilitate reading do connection admission control
   on the indicated class(es) of this document, but flow.

   As indicated in [I-D.ietf-ancp-protocol], the
   reader is refered AN MUST NOT reply to [I-D.ietf-ancp-framework] for a more exhaustive
   description
   the Provisioning message if it processed it successfully.  If an
   error prevents successful processing of the ANCP multicast use cases.  Detailed example message flows can also be found content, the AN
   MUST return a Generic Response message as defined in Section 7.

3.1.  NAS Initiated Multicast Replication Control Use Case

3.1.1.  Goals

   One option for multicast handling is for

   [I-D.ietf-ancp-protocol], containing a Status-Info TLV with the subscriber to
   communicate
   appropriate content describing the "join/leave" information to error.  For this purpose, the NAS.  This can be
   done for instance
   presence of a list typein a Multicast-Service-Profile TLV which was
   ignored because it was not supported by terminating all subscriber IGMP ([RFC3376]) or
   MLD ([RFC2710], [RFC3810]) signaling on the NAS.  Another example
   could be a subscriber using some form negotiated set of application level signaling,
   which
   capabilities is redirected not considered to be an error.

      Editor's note: that means that if a NAS mistakenly adds the NAS.  In any case, this option is
   transparent to wrong
      list types there will be no debugging feedback.  On the access and aggregation network.  In other
      hand, this scenario,
   the NAS uses ANCP to create and remove replication state in the AN adds flexibility for efficient multicast replication.  Thus, the NAS only sends a
   single copy handling pre-assembled sets of the multicast stream towards the AN, which in turn
   performs replication
      list updates being sent out 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 ANs.  If there are no
      comments on this feature/bug, this Editor's note will be removed
      in the AN if admission succeeds.

3.1.2.  Message Flow

   With next version of the NAS-initiated use case, draft.

   When a new Multicast Replication Control
   Message Service Profile is sent identified by the NAS to the AN with a directive to either join
   or leave one (or more) multicast flow(s).  The AN uses a Multicast
   Status Message to convey Multicast-
   Service-Profile TLV, the outcome initial state of the directive.  Figure 1
   illustrates such an ANCP message exchange as well as the all lists associated
   AN behavior.

   +----------+    +-------+     +-----+        ANCP          +-----+
   |Subscriber|    | Home  |     | AN  |<-------------------->| NAS |
   +----------+    |Gateway|     +-----+                      +-----+
         |         +-------+         |                           |
         |            |              | Multicast-Replication-Crl |
         |            |              |   (Target,add, Flow 1)    |
         |            |              |<--------------------------|
         |       Mcast Flow 1        |                           |
         |<==========================+                           |
         |            |              |     Multicast-Status      |
         |            |              |-------------------------->|
         |            |              |                           |
         |            |              |                           |
         ~            ~              ~                           ~
         |            |              |                           |
         |            |              | Multicast-Replication-Crl |
         |            |              |   (Target,delete, Flow 1) |
         |            |              |<--------------------------|
         |            |              |                           |
         |  <Stop Replication with
   that profile according to the negotiated set of     X                           |
         |            Mcast Flow 1>  |     Multicast-Status      |
         |            |              |-------------------------->|

           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
   capabilities is for empty until changed by the contents of Multicast-
   Service-Profile TLVs.

4.2.  Port Management Message

   As specified in [I-D.ietf-ancp-protocol], the access/aggregation nodes NAS may send line
   configuration information to participate the AN ("ANCP based Line Configuration"
   use case) using GSMP Port Management messages modified to contain an
   extension block.  Section 5.4.3 of [I-D.ietf-ancp-protocol] defines a
   number of TLVs that can be included in IGMP/MLD processing (e.g. via IGMP/MLD snooping).
   In this scenario, on detecting the Extension Value field
   inside a join/leave request from an enduser
   for Port Management message to support line configuration.

   This document specifies that the Port Management message MAY also
   include the following TLVs:

   o  "Multicast-Service-Profile-Name" TLV (defined in Section 5.7).
      This TLV associates a multicast flow, Multicast Service Profile with the AN uses ANCP Access
      Port specified by the extension block.

   o  "Bandwidth-Allocation" TLV (defined in Section 5.3).  This TLV
      specifies the total multicast bandwidth available to request conditional access
   and admission control decision from the NAS.  In turn, after
   conditional access and AN for
      admission control checks, at the Access Port.

4.2.1.  Sender Behaviour

   The NAS uses ANCP to
   instruct sends the AN Port Management message at startup time to change
   initialize parameters associated with the replication states accordingly.

3.2.2.  Message Flow

   For support of Access Port specified in
   the conditional access message and admission control use case,
   on detection of an IGMP/MLD Join, with the AN sends an Admission Control
   message to multicast capabilities negotiated between
   the NAS to request conditional access and admission
   control check.  In the AN.  The NAS MAY send additional Port Management
   messages subsequent to startup, to update or, in the case of positive outcome, the NAS sends
   Bandwidth-Allocation TLV, reset these parameters.  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 Replication Control Message to Multicast-Service-Profile-
   Name TLV, the AN with a directive to
   replicate associates the multicast flow to named profile with the corresponding user.  Similarly on
   detection of an IGMP/MLD leave, an Admission Control message specified
   Access Port.  This association replaces any previous association.
   That is, a given Access Port is sent associated with at most one Multicast
   Service Profile.

   As specified in [I-D.ietf-ancp-framework], if a join request is later
   received by the AN to the NAS to keep the NAS aware of user departure for the
   flow.  This message a multicast flow that is illustrated in Figure 2.

   +----------+    +-------+   +-----+      ANCP           +-----+
   |Subscriber|    | Home  |   | AN  |<------------------->| NAS |
   +----------+    |Gateway|   +-----+                     +-----+
         |         +-------+      |                           |
         |            |           |                           |
         |       Join(Flow 1)     |  Admission-Control        |
         |------------+---------->|   (Target,add, Flow 1)    |
         |            |           |-------------------------->|
         |            |           |                          (*)
         |            |           | Multicast-Replication-Crl |
         |            |           |   (Target,add, Flow 1)    |
         |            |           |<--------------------------|
         |     Mcast Flow 1       |                           |
         |<=======================+                           |
         |            |           |                           |
         ~            ~           ~                           ~
         |            |           |                           |
         |      Leave(Flow 1)     |  Admission-Control        |
         |------------+---------->| (Target,delete, Flow 1)   |
         |            |           |-------------------------->|
         | <Stop Replication part of   X                           |
         |         Mcast Flow 1>  |                           |
         |            |           |                           |

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

       Figure 2: Multicast Conditional Access and Admission Control

3.3.  Multicast Flow Reporting Use Case

3.3.1.  Goals

   The multiple
   lists in the Multicast flow reporting use case allows Service Profile associated with the NAS to
   asynchronously query Access
   Port, then the AN to obtain an instantaneous status report
   related to multicast flows currently replicated most specific match MUST be used by the AN.

3.3.2.  Message Flow

   The NAS sends a Multicast Flow Query Request message to  If the AN
   most specific match occurs in
   order to query multiple lists, the AN about information such as Black list entry
   MUST take precedence over the Grey list, which MUST take precedence
   over the White list.  If the requested multicast flows
   are currently active on a given flow is not part of
   any list, the AN port or which ports are currently
   replicating SHOULD ignore the join request.

   If the Port Management message contains a given multicast flow.  The Bandwidth-Allocation TLV,
   the AN conveys adopts this as the requested
   information to current value of its total multicast
   bandwidth limit for the NAS Access Port.  If the AN has already committed
   multicast bandwidth exceeding the amount given in a Multicast Flow Query Response message.
   This message flow is illustrated the Bandwidth-
   Allocation TLV, the AN SHOULD NOT discontinue any multicast streams
   in Figure 3.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | order to bring bandwidth down to within the new limit.  However,
   the AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |  Multicast Flow   |
         |           |           |  Query Request    |
         |           |           |<------------------|
         |           |           |                   |
         |           |           | Multicast Flow    |
         |           |           | Query Response    |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |                   |

                    Figure 3: Multicast Flow Reporting

4.  ANCP Messages

   This section defines MUST NOT admit new ANCP messages 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 new usage of existing ANCP
   messages as well as procedures associated with
   the use Result field of these
   messages.

4.1.  Provisioning the request is Nack (0x1) or AckAll (0x2), the AN
   SHOULD add a Status-Info TLV to the Extension Value field in its
   reply if this will provide useful information beyond what is provided
   by the Code value returned in the response header.

4.3.  Multicast Replication Control Message

   [I-D.ietf-ancp-protocol]

   This section defines a new message called the Provisioning Multicast Replication
   Control message.  The Multicast Replication Control message that is sent
   by the NAS to the AN with one or more directives to provision information add (join) or
   delete (leave) a multicast flow on a target object identified in the AN.

   The present document specifies that
   content of the Provisioning message MAY be
   used by message.

   The Message Type for the NAS to provision multicast-related information (e.g. Multicast Service Profiles, Bandwidth Delegation activation/
   deactivation). Replication Control message is
   0x90.

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

   o  Multicast-Service-Profile TLV: the Multicast-Service-Profile TLV
      is defined in the present document in Section 5.1.  It MAY appear
      zero, one or multiple times.  Each instance of the Multicast-
      Service-Profile TLV contains a (possibly empty) White List, a
      (possibly empty) Grey List, a (possibly empty) Black List and the
      Multicast Service Profile name associated with this set of three
      lists.

   o  Bandwidth-Delegation-Control  Target TLV: The Bandwidth-Delegation-Control Target TLV is defined in the present document in Section 5.2. [I-D.ietf-ancp-protocol].
      It MAY MUST appear zero times or once.  When present it instructs the AN on
      whether Bandwidth Delegation is to be activated or deactivated.

   [Editor's Note: A generic mechanism should be defined in ancp-proto
   to deal with incorrect/invalid Provisioning message.  This should
   include an error code for the AN to indicate that it does not know a
   given TLV once and does not support the corresponding capability, only once.  It is encoded as specified in
      [I-D.ietf-ancp-protocol] and an
   error code for identifies the AN port subject to indicate that a given TLV and its
   corresponding capabilities have been "negotiated out" during the
   Capability negotiation phase.
      request for admission or release.

   o  Command TLV: The present document can indicate that
   (i) the 1st error code can Command TLV is defined in
      [I-D.ietf-ancp-protocol].  It MUST be used when Provisioning message contain present.  It MAY appear
      multiple times.  Each Command TLV contains a multicast related TLV but flow
      directive for the AN does not support it and (ii) target.

   The contents of the
   2nd error code can be used when Bandwidth-delegation-Control Command TLV
   indicates "active" but Bandwidth Delegation is not part of for the
   negotiated multicast capabilities].

4.2.  Port Management Multicast Replication Control
   Message

   As are defined in [I-D.ietf-ancp-protocol], the NAS may send line
   configuration information to the AN ("ANCP based Line Configuration"
   use case) using GSMP Port Management messages modified to contain an
   extension block.  [I-D.ietf-ancp-protocol] defines a number of TLVs
   that can be included in the Extension Value field inside a Port
   Management message (e.g.  "Access-Loop-Circuit-ID", "Service-
   Profile-Name").

   This document specifies that the Port Management message MAY also be
   used by the NAS Figure 4 and subsequent text.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Command Code  |R O M   Flags  |         Command Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Multicast Flow Source Address                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-\   /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   (Cont'd)  ...         /   \ | Multicast Flow Group Address  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-\   /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   (Cont'd)  ...        /   \  | Sub-TLVs ...                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+\   /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   (Cont'd)  ...        /   \  | Padding to associate a "Multicast-Service-Profile" (aka. a
   triple 32-bit boundary    |
       +-+-+-+-+-+-+-+-+-+-+-+-+\   /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4: Contents of White, Grey and Black lists) to a AN port.  To do so, the
   NAS includes a "Multicast-Service-Profile-Name" Command TLV (specified in
   Section 5.6) in the Port Management message.

   In addition, when bandwidth delegation is activated for this AN, the
   Port Management message MAY be used to provision the initial amount Multicast Replication
                              Control Message

   Command Code:
             Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
             All.

   Command Length:
             Length in bytes of bandwidth delegated to the AN for Command including multicast admission control
   (hereafter referred to as the "delegated bandwidth").  To do so, flow
             address, but excluding the
   NAS MAY include in Command Code header and flags.

   Flags:
             8 bit General purpose Flag field.  Currently the Port Management message a "Bandwidth-
   Allocation" TLV (defined following
             flags are defined:

             R -       Resource Admitted Flag.  Set to 1 in Section 5.3) .

   [Editor's Note: the Port Management message requires the
   specification of an Access-Loop-Circuit-Id TLV indicating the target
   of the assignment.  Thinking about the possibility of PON, will we be
   updating the definition of Access-Loop-Circuit-Id TLV add
                       command to include
   default naming formats for PON?  Of indicate that the authors, TT prefers this
   route, leaving Target flow resources have
                       been reserved by admission control.  Cleared to designate multiple targets 0
                       otherwise.

             O -       Flow Accounting.  When set in add command
                       indicates that byte accounting for the same
   command.]

4.3.  Multicast Replication Control Message

   This section defines a new message called the Multicast Replication
   Control message.  The Multicast Replication Control message flow is sent
   by the NAS to
                       commence.

             M -       When set, indicates that the AN with one or more directives to add (join) or
   delete (leave) a multicast flow on a target object identified in is
                       SSM; the Command MUST then specify both the
   content of
                       source and the message. group address.  When a response not set,
                       indicates that the multicast flow is needed an AN ASM; the
                       Command MUST use then specify the group address only,
                       omitting the Source Address field.

   Multicast Status message (defined Flow Source Address:
             a field containing three sub-fields as illustrated in Section 4.4) to convey the
   outcome of
             Figure 5, giving the directive.

   The Message Type source address for the Multicast Replication Control message is
   0x90.  The sender of a Multicast Replication Control message an SSM flow.  This
             field MUST set be present if the Result field to "0x00" meaning "Ignore".  The sender M flag is set, and MUST
   populate NOT be
             present if the ANCP Transaction Identifier field with M flag is cleared.

   Multicast Flow Group Address:
             a unique value, field containing three sub-fields as described illustrated in section 5.4.5 of [I-D.ietf-ancp-protocol].

   The NAS MAY issue a Multicast Replication Control message to
             Figure 5, giving the group address for the AN
   to convey one or more directives to add (join) or delete (leave) a multicast flow.
             This field MUST be present.

   The NAS sends this message on its own initiative to
   support address family of the NAS initiated Multicast Control use case presented in
   [I-D.ietf-ancp-framework] group address MAY differ from the address
   family of the source address, if present.

   For future extensibility, each Command TLV MAY also have additional
   sub-TLVs appended following the command and summarized in Section 3.1.  The NAS
   sends this message in response to a Multicast Admission Control
   message (defined multicast flow
   information (shown as "Sub-TLVs" in Section 4.5) received from Figure 4).  Unrecognized sub-TLVs
   SHOULD be silently discarded.

   If needed, padding is done at the AN to support end of the command data so that the
   conditional access and admission control use case presented
   TLV is 32-bit aligned.

   As shown in
   [I-D.ietf-ancp-framework] and summarized Figure 5, each address entry in Section 3.2.

   The ANCP Multicast Replication Control message payload contains the Command TLV consists
   of the following TLVs:

   o  Target TLV: three sub-fields with no intervening padding:

   Address Family:
      The Target TLV is address family of the address with values as defined in [I-D.ietf-ancp-protocol].
      It MUST appear once
      [IANAAEA].

   Encoding Type:
      The type of encoding used within a specific Address Family.  The
      value `0' is reserved for this field, and only once.  It represents the native
      encoding of the Address Family.  This is encoded as consistent with the
      address encoding specified in
      [I-D.ietf-ancp-protocol] [RFC4601].

   Address:
      The address as represented by the given Address Family and identifies
      Encoding Type.  This is consistent with the AN port subject to address encoding
      specified in [RFC4601].

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | IP Address                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+
       |                    IP Address (Cont'd)  ...   \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+

       Figure 5: Structure of the
      request for admission or release.

   o  Command TLV: The Command TLV is defined Address Fields in
      [I-D.ietf-ancp-protocol].  It MUST be present.  It MAY appear
      multiple times.  Each the Command TLV contains a multicast flow
      directive for the target.

   The contents figure below is an example of the Command TLV for the a Multicast Replication Control
   Message are defined
   message that would result in Figure 4 and subsequent text.

       0                   1                   2                   3 a swap from multicast SSM flows
   192.0.2.1, 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target
   identified by the "Access Loop Circuit ID":

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Command Code  |R O M   Flags        Type (0x88-0C)         |         Command           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family Vers  | Encoding Type  Sub  |MessageType=90 | Multicast Flow Source Address 0x02  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Source Address (Cont'd)  ... Partition ID  |            Transaction Identifier = 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      | Addr Family           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Encoding        Type = Target 0x1000   | Multicast Flow Group Address        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Group Address (Cont'd)  ... Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ...                                                               | Padding to 32-bit boundary
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4:
       |        Type = Command TLV in Multicast Replication Control Message

   Command Code:
             Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
             All.

   Command Length:     |       Command-TLV Length in bytes of the Command including multicast flow
             address, but excluding the      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x02 |0 0 1          |      Command Code header and flags.

   Flags:
             8 bit General purpose Flag field.  Currently the following
             flags are defined:

             R -       Resource Admitted Flag.  Set to Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Mcast Source (Ctnd) 192.0.2.1  | AddrFamily 01 | EncType 0x0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Mcast Flow : 233.252.0.2                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |        Type = Command-TLV     |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1 in an add
                       command          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.2      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Mcast Source (Ctnd) 192.0.2.2  | AddrFamily 01 | EncType 0x0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mcast Flow: 233.252.0.3                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.1.  Sender Behaviour

   The NAS MAY issue a Multicast Replication Control message to indicate that the flow resources have
                       been reserved by admission control, 0 otherwise.
                       Not used in delete command.

             O -       Flow Accounting.  When set in add command
                       indicates that byte accounting for the flow is AN
   to
                       commence.

             M -       When set, indicates that the convey one or more directives to add (join) or delete (leave) one
   or more multicast flow is
                       SSM; the Command MUST then specify both flows.

   The NAS MAY send this message on its own initiative to support the
                       source
   NAS initiated Multicast Control use case presented in
   [I-D.ietf-ancp-framework] and the group address.  When not set,
                       indicates summarized in Section 3.1.  In that
   case, the multicast flow is ASM; the
                       Command NAS MUST then specify the group address only,
                       omitting set the Source Address field.

   Address Family: Result field to AckAll (0x2) or Nack (0x1)
   according to its requirements.

   The address family of the address with values as defined NAS MAY also send this message in
             [IANAAEA].

   Encoding Type:
             The type of encoding used within response to a specific Address Family.
             The value `0' is reserved for this field, and represents
             the native encoding of Multicast
   Admission Control message (defined in Section 4.4) received from the Address Family.  This is
             consistent with
   AN to support the address encoding specified conditional access and admission control use case
   presented in
             [RFC4601].

   Address:
             The address as represented by the given Address Family [I-D.ietf-ancp-framework] and
             Encoding Type.  This is consistent with the address
             encoding specified summarized in [RFC4601].

   If needed, padding is done after both addresses so Section 3.2.
   In that case, the NAS MUST set the Result field to NAck (0x1).

   In either case, the sender MUST populate the TLV is
   32-bit aligned.

   If Code field with the AN receives a Multicast Replication Control Message containing
   an unrecognized Target TLV,
   value 0x000 and the AN MUST return ANCP Transaction Identifier field with a Multicast Status
   Message (Section 4.4) indicating the "Unrecognised port Type - 0x04"
   error. unique
   value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol].

   Each Multicast Replication Control Message MAY contain one or more
   commands, each encapsulated in its own Command TLV.  The sender MUST
   use a separate Command TLV for each distinct multicast flow.

   When the order of processing of two commands does not matter, the
   commands MUST be transmitted in separate Multicast Replication
   Control messages.

   The NAS MAY choose to perform admission control before adding a
   particular flow even if admission control has been enabled on the AN.
   If it does so, it MUST set the R flag in the Command TLV concerned.
   Conversely, if admission control has been enabled on the AN, the NAS
   MAY choose to have the AN do admission control by clearing the R
   flag.

      Note that clearing the R flag causes the AN to allocate resources
      for the flow out of its bandwidth budget as opposed to any
      bandwidth budget managed for the same access line at the NAS.

4.3.2.  Receiver Behaviour

   When successive commands (in the same or different messages) relate
   to the same Target and multicats multicast flow, the state of each feature
   controlled or affected by flags or by optional attributes received in
   the Multicast Replication Control message, SHALL be as set by the
   last command or message referring to that target and flow and
   containing the controlling flag or optional attribute.  As an
   example, successive Multicast Replication Control messages containing
   add commands for a given port and flow, but differing only in the
   accounting flag setting SHALL be interpreted to mean that the state
   of the accounting feature is as set in the final command received,
   but all other feastures 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.  The

   If admission control for Multicast Replication Control messages has
   not been enabled (through provisioning of the MRepCtl_CAC TLV, the AN
   MUST use ignore the assigned sequence number R flag in any response message when
   necessary to distinguish the Command TLV instance to which TLVs.  Otherwise, if a given
   status code applies.

   The processing/execution of multiple commands contained in Command TLV
   adds a single
   Multicast Control message MUST be interrupted at flow, the first error
   encountered, and R flag within the remaining commands in TLV is not set, and the AN is
   performing admission control for Multicast Replication Control message discarded.  In such a case a Multicast Status message
   messages, then the AN MUST be sent indicating perform admission control before
   replicating the command number that resulted in flow.  If the error
   along with admission control check fails, the AN
   MUST treat the failure as an error code.

   When as described below.  The
   appropriate Code value for the order of processing of two commands does not matter, response is 18 (0x012) "Insufficient
   resources".

   If the
   commands MUST be transmitted in separate AN processes the complete Multicast Replication Control messages.

   Each command directive is equipped with an 8-bit Flags field that
   allows specification of Multicast ASM or SSM modes of operation, and
   an indication of other features or conditions attached to this
   command (e.g.  To enable accounting for the flow, etc).  Unassigned
   flags are reserved for future use,
   message successfully and could in the future be subject Result field of the capability negotiation.  When receiving a Multicast
   Replication Control Message containing an unrecognized Flag message was set (to
   1), a recipient to AckAll (0x2), the AN MUST interpret it as an error, and generate an
   Multicast Status
   respond with a Generic Response message indicating the error.

   The multicast flow subject to where the command Result field is specified by means of
   one or two well known Address Family designators ([IANAAEA]), the
   IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02).  When set
   to Success (0x3), the M flag Code field is set the two Address-Family tuples MUST be present in
   the strict order specifying the multicast flow source to 0x000, and group
   respectively.  When the M flag is cleared only one Address-Family Transaction
   Identifier field is
   allowed, specifying copied from the multicast flow.

   For future extensibility, each Command TLV Multicast Replication Control
   message.  The body of the response MAY also have additional
   [sub- be empty or same level ????]  TLVs appended following MAY be copied from
   the command and
   multicast flow information (referred to as "TLVs" Multicast Replication Control message.

   The processing/execution of multiple commands contained in a single
   Multicast Control message MUST be interrupted at the first error
   encountered, and the remaining commands in the Multicast Replication
   Control message
   format above).  Unrecognized TLVs SHOULD be silently discarded.  The
   figure below is

   If the AN detects an example of error in a received Multicast Replication
   Control message
   that would result and the Result field in that message was set to Nack
   (0x1) or AckAll (0x2), the AN MUST generate a swap from multicast SSM flows 192.0.2.1,
   233.252.0.2, Generic Response
   message providing error information to 192.0.2.2, 233.252.0.3 on the Target identified by NAS.  This specification
   identifies the "Access Loop Circuit ID":

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=90 | 0x02  | following new 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 = values beyond those specified in
   [I-D.ietf-ancp-protocol], which MAY be used in a Generic Response
   sent in reply to a Multicast Replication Control message:

   0x100  Command error.  This SHOULD be reported for the following
      cases:

      *  invalid command code;

      *  undefined flag set.

   0x101  Bad flow address.  This SHOULD be reported for the following
      cases:

      *  unsupported address family;

      *  unsupported address encoding;

      *  source address present when M flag cleared, or absent when M
         flag set.

   0x102  Multicast flow does not exist.  This SHOULD be reported if the
      NAS attempts to delete a flow that is not enabled.

   A Generic Response message responding to the Multicast Replication
   Control message and containing one of the above Code values MUST
   include a Status-Info TLV     |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x02 |0 0 1          | which includes one or two sub-TLVs as
   follows:

   o  a Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Mcast Source (Ctnd) 192.0.2.1  | AddrFamily 01 | EncType 0x0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Mcast Flow : 233.252.0.2                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |        Type = Command-TLV     |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1          | Number TLV as described in Section 5.2, giving the
      sequence number of the failed command, MUST be included;

   o  the failed Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.2      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Mcast Source (Ctnd) 192.0.2.2  | AddrFamily 01 | EncType 0x0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mcast Flow: 233.252.0.3                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV itself SHOULD be included.

      Note that the Error Message field of the Status-Info TLV MAY be
      used to report more details than implied by the Code value in the
      message header.  For example, the Code value could be 0x101 and
      the Error Message field could contain the text: "Source address
      present when M flag cleared".

4.4.  Multicast Status Admission Control Message

   This section defines a new message called the Multicast Status Admission
   Control message.  The Multicast Admission Control message is sent by
   the AN to the NAS to request admission of a multicast flow, or to
   notify of the removal of a multicast flow, for a given target.

   The Message Type for the Multicast Admission Control message is 0x92.

   The ANCP Multicast Admission Control message payload contains two
   TLVs:

   o  Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
      It MUST appear once and only once in the Multicast Admission
      Control message.  The general purpose of the Multicast Status message  It is to
   provide information on encoded as specified in
      [I-D.ietf-ancp-protocol] and identifies the success or failure AN port subject to process a message
   previously received from the sender's peer.  Depending on the
   particular use case, the Multicast Status message MAY be sent by
   either the NAS
      request for admission or release.

   o  Command TLV: The Command TLV is defined in
      [I-D.ietf-ancp-protocol].  It MUST be present.  If it appears more
      than once, only the AN.  In some cases the Multicast Status message first instance is REQUIRED, even when processing considered meaningful in the
      present version of this specification and the original message is
   successful.  In other cases instances are
      ignored.

   Informative note:

      In the Multicast Status message is used only
   to report failures.  For further details see future, the descriptions specification of
   other multicast-related messages presented in this section.

   The Message Type for the Multicast Status message is 0x91.

   A Multicast Status Admission Control message MUST use
      may be extended to allow transport of more than a single directive
      (e.g. to carry both a leave from one group and a join to another
      group for the same ANCP Transaction ID as 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 it can not be executed are not
      executed either.  When the strict sequenced processing of the
      directives is responding to. not required the directives are distributed across
      separate messages.

4.4.1.  Sender Behaviour

   The Success or Failure
   status is reported in AN sending the Multicast Admission Control message MUST set the
   Result field of to Ignore (0x0).

   The AN MUST populate the ANCP header Transaction Identifier field with a
   unique value, as described in section 5 of [I-D.ietf-ancp-protocol].

   A Multicast Status Message indicating Success SHOULD simply consist
   only of 5.4.5
   of[I-D.ietf-ancp-protocol] .

   The AN MUST encode the base ANCP header Command TLV as specified in Section 4.3 with no body, however
   the following additional rules:

   o  the R flag MUST be set to 0;

   o  the O flag MUST be set to 0;

   o  the Command Code field MUST be set to "0x01 - Add" when the
      message MAY
   contain one or more TLVs that are meant conveys a Join , to communicate any relevant
   information "0x02 - Delete" when the message
      conveys a Leave and to an application. "0x03 - Delete All" when the message
      conveys a Leave of all channels (on the target);

   o  The payload M Flag, Multicast Source Address and Multicast Flow Address of a
      the Command TLV identify the multicast flow subject to the request
      for admission or release.  When the Command Code is 0x03, the M
      Flag, Multicast Status
   Message indicating Failure Source address, and Multicast Flow Address are
      meaningless and MUST contain be set to all zeroes.

   o  a Status-Info TLV (0x12) Request-Source-IP sub-TLV (as defined in [I-D.ietf-ancp-protocol]) as its first TLV.  This SHOULD Section 5.8) MAY be followed
      included by the Target 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 (as defined in
   [I-D.ietf-ancp-protocol]) and Port-info [???].  Other TLVs MAY be
   present.  A Multicast Status message indicating Failure MUST be sent
   whenever the Admission
      Control message.  If it appears more than once, only the first
      instance is considered meaningful and the other instances are
      ignored.

   o  a multicast control message cannot be fulfilled or results
   in an execution error.  The Cmnd Nmbr parameter Request-Source-MAC sub-TLV (as defined in the Status-Info
   TLV contained Section 5.9) MAY be
      included by the Multicast Status Message is used AN to indicate convey the
   sequence number MAC address of the command in sender of the Multicast Replication Control
   Message
      join/leave message (e.g.  IGMP/MLD Join/Leave) that resulted in an error.  In the case where triggered the problem is
   with
      AN to include the Multicast Replication Control Message as a whole, or corresponding Command TLV in the
   case where Admission
      Control message.  If it appears more than once, only the problem is with a message that first
      instance is not a considered meaningful and the other instances are
      ignored.

4.4.2.  Receiver Behaviour

   On receipt of an Multicast
   Replication Admission Control message, the Cmnd Nmbr parameter SHOULD be set to
   0x00.

   The following values are defined for NAS:

   o  MUST ignore the Result Code field in field;

   o  if the
   Status-Info TLV contained directive in a the Multicast Status Message:

        0x00 - Success

        0x01 - Malformed Admission Control message

        0x02 - Command not supported

        0x03 - Flag set but not supported

        0x04 - Unrecognized Target
        0x05 - Unsupported Address Family

        0x06 - Malformed flow address

        0x07 - No resources

        0x08 - Unknown Target

        0x09 - Target down

        0x0a is
      "0x02 - Configuration error (such as Port not enabled for
        multicast)

        0x0b Delete" or "0x03 - Delete All" and is processed correctly
      by the NAS, the NAS MUST NOT generate any ANCP message in response
      to the Multicast flow does not exist

        0x0c - Unsupported address encoding

        0x0d Admission Control message;

   o  if the directive in the Multicast Admission Control message is
      "0x01 - Additional info needed Add" and is accepted by the NAS, the NAS MUST generate a
      Multicast Replication Control in response to execute command (payload MAY
        contain an indication of the expected info)

        0x0e - Multicast flow count exceeded

        0x0f - M Flag set, but no IP Source address provided

        0x10 - Transaction-id out of sequence

        0x11 - Invalid preferred bandwidth amount

        0x12 - Bandwidth delegation not activated

        0x13 - Delegated bandwidth reset required

   An example of
      Admission Control message.  The Multicast Replication Control
      message:

      *  MUST contain a failure message for an invalid address, including Result set to Nack (0x1);

      *  MUST contain a Transaction ID generated by the
   Target TLV NAS (distinct
         non-zero, and linearly incremented by NAS for a 4 byte "Access Loop Circuit ID", followed each request per
         adjacency);

      *  MUST contain the directive as accepted by the NAS.  The R flag
         in the returned Command TLV
   padding, is as follows:

       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 MUST have value 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=91 | 0x4   |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Status-info-TLV=0x12  |      Status-TLV-Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Result Code  |  Cmd Number   |    Error Message Length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Error Message (padded to 4) if Length > 0           |
       +---------------------------------------------------------------+
       |     Target TLV=0x10           |        Target-Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Access Loop ID type       |     Access-Loop ID  Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            circuit ID                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.5.  Multicast Admission Control Message

   This section defines a new message called the Multicast Admission
   Control message.  The NAS
         intends the AN to perform admission control before installing
         the flow, 1 otherwise.  Note that the AN will ignore the R flag
         unless the MRepCtl_CAC TLV has been provisioned on the AN.

   o  if the directive in the Multicast Admission Control message is sent
      "0x01 - Add", is processed correctly but not accepted by the AN to the NAS to request
      (i.e. it does not pass the admission of a multicast flow, control or to
   notify of conditional access
      check), the removal of a multicast flow, over a given target.  The NAS will use MAY generate a Multicast Replication Control
      message (as discussed in
   Section 4.3) in order to convey back response to the AN the outcome of the
   admission request.

   The Message Type for the Multicast Admission Control message.
      This optional message is 0x92.

   The can be used by the AN sending to maintain statistics
      about admission control reject and, in the future, when the
      protocol between the subscriber and the AN allows explicit
      notification of join reject (e.g.
      [I-D.morin-mboned-igmpmld-error-feedback]).  When used in this
      situation, the Multicast Admission Replication Control message message:

      *  MUST set the contain a Result field set to "0x00" meaning "Ignore".

   The AN 0x00;

      *  MUST populate the ANCP contain a Transaction Identifier field ID generated by the NAS (distinct
         non-zero, and linearly incremented by NAS for each request per
         adjacency);

      *  MUST contain the directive rejected by the NAS (i.e.  Target
         TLV and Command TLV) but with a
   unique value, as described in section 5.4.5
   of[I-D.ietf-ancp-protocol] .

   The ANCP Multicast Command Code set to "0x04 -
         Admission Control Reject", "0x05 - Conditional Access Reject"
         or "0x06 - Admission Control message payload contains two
   TLVs:

   o  Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
      It MUST appear once and only once in Conditional Access Reject".

   o  if the Multicast Admission Control message.  It message cannot be processed
      correctly by the NAS (e.g. the message is encoded as specified in

      [I-D.ietf-ancp-protocol] and identifies malformed, the AN port subject to multicast
      flow does not exist etc.), the
      request NAS MUST generate a Generic
      Response message (defined in [I-D.ietf-ancp-protocol]) with
      appropriate content indicating the reason for admission or release.

   o  Command TLV: the failure.

4.5.  Bandwidth Reallocation Request Message

   The Command TLV Bandwidth Reallocation Request message is defined used when the bandwidth
   delegation capability is included in
      [I-D.ietf-ancp-protocol]. the negotiated set.  It MUST MAY be present.  If it appears more
      than once, only
   sent either by the first instance is considered meaningful NAS or by the AN to request an adjustment in the
      present version
   amount of delegated bandwidth.  It will be sent by the document and NAS typically
   to reduce the other instances are
      ignored .  The Command TLV is encoded as specified in Section 4.3
      with multicast bandwidth allocated to the following additional rules:

      * AN in order for
   the R flag is set NAS to 0

      *  the O flag is set satisfy a request to 0

      * add one or more flows.  Conversely,
   the Command field is set AN will send a Bandwidth Reallocation Request to "0x01 - Add" when obtain
   additional bandwidth to satisfy a request to add a multicast channel.
   In each case, the message
         conveys requestor has a Join , minimum requirement for additional
   bandwidth, and MAY ask for additional bandwidth beyond this amount
   (e.g., to "0x02 - Delete" when handle anticipated future requests).

   The Bandwidth Reallocation Request message contains two TLVs:

   o  the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]),
      specifying a single access line;

   o  the Bandwidth-Request TLV (Section 5.6), specifying the message conveys a
         Leave required
      and to "0x03 - Delete All" when preferred amounts of delegated bandwidth.

   The Message Type for the Bandwidth Reallocation Request message conveys a
         Leave is
   0x94.

4.5.1.  Sender Behaviour

   The Result field in the header of all channels (on the target).

      *  The M Flag, Multicast Source Address Bandwidth Reallocation Request
   message is not used and Multicast Flow Address
         of the Command TLV identify sender MUST set it to Ignore (0x0).

   The bandwidth values in the Bandwidth-Request TLV are expressed in
   terms of total multicast flow subject bandwidth allocated to the
         request for admission or release.

      *  a Request-Source-IP sub-TLV (as defined in Section 5.7) MAY AN.

      The choice of "total bandwidth" rather than "incremental
      bandwidth" was made so that it would be
         included by easier for the AN and NAS
      to convey the IP address keep their respective views of the sender current amount of delegated
      bandwidth synchronized.

   Because the join/leave message (e.g.  IGMP/MLD Join/Leave) that
         triggered values are totals rather than desired increments/
   decrements, the AN to include relationship between the corresponding Command TLV in required amount and the Admission Control message.  If it appears more than once,
         only
   preferred amount will differ depending on whether the first instance Bandwidth
   Reallocation Request message is considered meaningful and the other
         instances are ignored.

      *  a Request-Source-MAC sub-TLV (as defined in Section 5.8) MAY be
         included issued by the AN to convey NAS or the MAC address of AN.

   o  If the sender of NAS is making the join/leave message (e.g.  IGMP/MLD Join/Leave) that
         triggered request, the AN preferred amount MUST be
      less than or equal to include the corresponding Command TLV in
         the Admission Control message.  If it appears more required amount.  The required amount
      MUST be less than once,
         only the first instance is considered meaningful and the other
         instances are ignored.

   In currently amount of delegated bandwidth.

   o  If the future, AN is making the specification of request, the Admission Control message may preferred amount MUST be extended to allow transport of more
      greater than a single directive (e.g.
   to carry both a leave from one group and a join or equal to another group for the same Target).  It is expected that this would support a similar
   notion of strict sequenced processing as required amount.  The required amount
      MUST be greater than the currently defined for
   handling multiple directives in amount of delegated bandwidth.

4.5.2.  Receiver Behaviour

   When the Multicast Replication Control
   message whereby all directives following peer receives a valid Bandwidth Reallocation Request
   message, it SHOULD determine whether it can satisfy the first directive request from
   its existing allocation of unused video bandwidth.  If it decides
   that it can
   not be executed are not executed either.  When reallocate bandwidth to the strict sequenced
   processing of peer, it MAY choose to return
   any amount between the directives is not required and the directives are
   distributed across separate messages.

   On receipt of an Multicast Admission Control message, preferred amounts indicated
   in the NAS:

   o Bandwidth Reallocation Request message.

   The peer MUST ignore return a Bandwidth Transfer message Section 4.6
   indicating its decision.  If the request is met, the Result field

   o  if the directive in of
   the Multicast Admission Control Bandwidth Transfer message is
      "0x02 - Delete" or "0x03 - Delete All" and is processed correctly
      by the NAS, MUST be set to Success (0x3), the NAS Code
   field MUST NOT generate any ANCP message in response be set to 0x000, and the Multicast Admission Control message

   o  if Bandwidth-Allocation TLV
   (Section 5.3) MUST contain the directive in new value of total multicast
   bandwidth.  This new value MUST lie between the Multicast Admission Control message is
      "0x01 - Add" required and
   preferred values, inclusive, from the request message.  If the
   request is accepted by not met, the NAS, Result field of the NAS Bandwidth Transfer
   message MUST generate a
      Multicast Replication Control in response be set to Failure (0x4), the Multicast
      Admission Control message.  The Multicast Replication Control
      message:

      * Code field MUST contain a Result be set to 0x00

      *
   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 Transaction ID generated by different view
   of the amount of bandwidth from the receiver:

   o  the NAS (distinct
         non-zero, and linearly incremented by NAS for each receives a request per
         adjacency).

      *  MUST contain where the directive as accepted by required amount is less than
      its view of the NAS current amount of delegated bandwidth;

   o  if  the directive in AN receives a request where the Multicast Admission Control message is
      "0x01 - Add", required amount is processed correctly but not accepted by the NAS
      (i.e. it does not pass greater
      than its view of the admission control or conditional access
      check), current amount of delegated bandwidth.

   If one of these cases occurs, the NAS MAY generate receiver with one exception MUST
   send a Multicast Replication Control Bandwidth Transfer message indicating Success.

   o  If the NAS received the request, the allocated amount in response to the Multicast Admission Control message.
      This optional message can NAS's
      response MUST be used by at least equal to NAS's view of the current
      amount of delegated bandwidth.

   o  If the AN to maintain statistics
      about admission control reject and, received the request, the allocated amount in the future, when AN's
      response MUST be no greater than the
      protocol between AN's view of the subscriber and current
      amount of delegated bandwidth.

   The exception is when the AN allows explicit
      notification NAS receives a request while it has a
   request of join reject (e.g.
      [I-D.morin-mboned-igmpmld-error-feedback]).  When used in this
      situation, its own outstanding.  Handling of that case is described
   below.

      While the Multicast Replication Control message:

      *  MUST contain cases just described are an error condition, the success
      response achieves a Result set graceful recovery.

   To avoid deadlock due to 0x00

      * race conditions, the following rules MUST contain a Transaction ID generated by be
   applied:

   a.  If the NAS (distinct
         non-zero, and linearly incremented by NAS receives a Bandwidth Reallocation Request message
       while it has a Bandwidth Reallocation Request message of its own
       outstanding for each request per
         adjacency).

      *  MUST contain the directive rejected by same access line, the NAS (i.e.  Target
         TLV and Command TLV) but MUST provide an
       immediate failure response to the request from the AN, with a Command
       Code value set to "0x04 -
         Admission Control Reject", "0x05 - Conditional Access Reject"
         or "0x06 - Admission Control and Conditional Access Reject".

   o  if 0x105 "Bandwidth request conflict".

   b.  If the Multicast Admission Control AN receives a Bandwidth Reallocation Request message cannot be processed
      correctly by 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 (e.g. taking the message is malformed, released
       bandwidth into account.

   If the multicast
      flow does not exist etc.), receiver is unable to process the NAS MUST generate a Multicast
      Status Bandwidth Reallocation
   Request message (defined in Section 4.4) in response due to an error, then the
      Multicast Admission Control message.  The Multicast Status
      message:

      * receiver MUST contain return a
   Bandwidth Transfer message where:

   o  the Result field is set to "Failure" in Failure (0x4),

   o  the ANCP header

      *  MUST contain a Transaction ID Code field is set appropriately to indicate the type of error
      that echoes was detected,

   o  the Bandwidth Allocation TLV contains the value of the
         Transaction ID received in current
      amount of delegated bandwidth as the Multicast Admission Control
         message.

      *  MUST contain responder views it, and

   o  a Status Status-Info TLV including a Result MAY follow the Bandwidth Allocation TLV giving
      further information about the error.

   This specification provides three new Code indicating values applicable
   specifically to the reason why contents of the Admission Control message could not Bandwidth-Request TLV.  These
   Code values by their nature MUST only be
         processed used when the error is being
   reported in a Bandwidth Transfer message rather than a Generic
   Response message.

   0x103  invalid preferred bandwidth amount.  This indicates that the
      preferred and encoded as specified required amounts of bandwidth in the TLV do not have
      the numerical relationship described in the previous section.

   0x104  inconsistent views of delegated bandwidth amount.  This will
      appear only in a Bandwidth Transfer message from the NAS to the AN
      in the case where the NAS has an outstanding Bandwidth
      Reallocation Request.  The recommended procedure for recovery is
      described in Section 4.4. 4.6.2.

   0x105  bandwidth request conflict.  The NAS has rejected the AN's
      request for more bandwidth because the NAS has an outstanding
      bandwidth request.

4.6.  Bandwidth Reallocation Request Transfer Message

   The Bandwidth Reallocation Request Transfer message is used when to transfer video bandwidth
   from the Bandwidth
   Delegation capability has been activated.  It sender to the peer for a specific access line.  This message
   MAY be sent either by from the NAS AN or by from the AN to request an adjustment NAS.  As described in the amount of
   delegated bandwidth.  It will be sent by
   previous section, it is the NAS typically required response to reduce
   the multicast bandwidth allocated a valid Bandwidth
   Reallocation Request message.

   The Bandwidth Transfer message MAY also be used to the AN in order for the NAS transfer bandwidth
   autonomously from one peer to
   satisfy a request another.  One example of this usage is
   to add a unicast video channel.  Conversely, release bandwidth borrowed earlier by means of the AN
   will send a Bandwidth
   Reallocation Request message.  When the message is used in this way,
   the Result field in the Bandwidth Transfer message MUST be set to obtain additional
   bandwidth
   Ignore (0x0).

      This allows the receiver to satisfy distinguish between an autonomous
      transfer and a request response to add a multicast channel.  In each
   case, the requestor has a minimum requirement for additional
   bandwidth, and MAY ask previous Bandwidth Reallocation
      Request, for additional bandwidth beyond this amount
   (say to handle anticipated future requests). purposes of validation.

   The Message Type for the Bandwidth Reallocation Request Bandwidth Transfer message is 0x95.  The
   Bandwidth Transfer message contains the following TLVs:

   o  the Target TLV, designating the access line concerned;

   o  an instance of the Bandwidth-Allocation TLV (Section 5.3).  The
      bandwidth value in the Bandwidth-Allocation TLV is the new amount
      of delegated bandwidth allocated to the target.

4.6.1.  Sender Behaviour

   When sending a Bandwidth Transfer message where the Result value is
   Ignore (0x0) or Success (0x3), the following relationships MUST hold:

   o  if the message is
   0x94.  The Result field sent by the NAS, the bandwidth value in the header
      Bandwidth-Allocation TLV MUST be greater than or equal to the
      sender's view of the Bandwidth Reallocation
   Request current amount of delegated bandwidth for the
      access line concerned;

   o  if the message is not used and sent by the AN, the bandwidth value in the
      Bandwidth-Allocation TLV MUST be set less than or equal to Ignore (0x00).  The
   Bandwidth Reallocation Request message MUST contain two TLVs:

   o the Target TLV (section 5.4.5.1.1
      sender's view of [I-D.ietf-ancp-protocol]),
      specifying a single access line; [TT - I would prefer the Access-
      Loop-Circuit-Id TLV, believing it should evolve to include non-DSL
      identifiers, but current amount of delegated bandwidth for the majority overruled me];

   o
      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 Bandwidth-Request TLV (Section 5.4), specifying NAS

   If the required
      and preferred amounts amount of delegated bandwidth.

   The bandwidth values provided in the Bandwidth-Request Bandwidth-
   Allocation TLV are expressed in
   terms is not greater than the NAS's view of total bandwidth delegated to the AN.

      The choice current
   amount of "total bandwidth" rather than "incremental
      bandwidth" was made so that it would be easier for delegated bandwidth, the AN and NAS
      to keep their respective views MUST update its view of the
   current amount of delegated bandwidth synchronized.

   Because the values are totals rather than desired increments/
   decrements, the relationship between to the required amount and indicated in the
   preferred amount will differ depending on
   Bandwidth Transfer message.  This is required regardless of whether
   the Bandwidth
   Reallocation Request Result field of that message indicates Success or Failure.

   If the amount of delegated bandwidth provided in the Bandwidth-
   Allocation TLV is issued by greater than the NAS's view of the current amount
   of delegated bandwidth, the NAS or MAY accept the AN.

   o  If given value as its new
   value of delegated bandwidth.  Alternatively, the NAS is making the request, MAY force the preferred amount MUST be
      less than or equal
   AN to modify its view of the required amount.  The required amount
      MUST be less than the current of delegated bandwidth value.

   o  If the AN is making to that
   held by the request, NAS, by sending a Port Management message for the preferred amount MUST be
      greater than or target
   access line concerned, containing a Bandwidth-Allocation TLV with a
   value equal to the required amount.  The required amount
      MUST be greater than the current of delegated bandwidth value.

   If these conditions are violated and the problem is NAS wishes to
   enforce.

4.6.2.2.  Behaviour of the relationship
   between AN

   If the required amount and of delegated bandwidth provided in the Bandwidth-
   Allocation TLV of the Bandwidth Transfer message differs from the receiver's
   AN's view of the current amount of delegated bandwidth, the AN MUST
   update its view of the current amount of delegated bandwidth reset procedure
   described to the
   amount indicated in Section 4.10 MUST be performed.  If the problem Bandwidth Transfer message.  This is the
   relationship between the preferred and required amounts, the peer
   receiving
   with the exception of a Bandwidth Reallocation Request Transfer message MUST return with a
   Multicast Status message where the Result
   field in the header
   indicates equal to Failure (0x4) and the Status-Info TLV contains the
   following values:

      Result a Code = invalid preferred field equal to 0x104
   "Inconsistent views of delegated bandwidth amount (0x11);

      Command Number = 0x1;

      Error Message Length = 0x0 (or optionally amount" or 0x105
   "Bandwidth request conflict".  If Code value 0x104 is received, the length of an error
      message, padded to
   AN MUST issue a four-octet boundary);

      Error Message (optional text);

      the Target TLV, copied from the Delegated Bandwidth Reallocation Query Request
      message; message to
   determine the Bandwidth-Request TLV, also copied from NAS's current view of the amount of delegated
   bandwidth.  The AN MUST update its own view based on the request message.

   When value
   returned in the peer receives a valid Delegated Bandwidth Reallocation Request
   message, it Query Response.  If Code value
   0x105 is received, the AN SHOULD determine whether carry out this procedure unless it
   can satisfy account for the request from
   its existing allocation discrepancy as a result of a transfer of unused video bandwidth.  If it decides
   that it can reallocate
   bandwidth to the peer, it MAY choose NAS that was carried out just before the incoming
   Bandwidth Transfer message was processed.

      The two Code values indicate a race condition where the AN may
      have just completed a transfer of bandwidth to return
   any amount between the required and NAS.  As a
      result, the preferred amounts indicated value given in the Bandwidth Reallocation Request message.  The peer MUST return
   a Bandwidth Transfer message Section 4.7 indicating its decision.  If may be
      outdated, and the request is met, AN needs to query the Result field of NAS to find its latest
      view.  The procedure assumes that ordering is preserved between
      the Bandwidth Transfer message MUST be set sent by the AN in response to Success (0x3), the
      NAS's request and the Bandwidth-Allocation
   TLV (Section 5.3) 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 contain NOT terminate
   any currently-active programs, but MUST NOT honour any more "join"
   requests until it is possible to do so within the new limit set by its
   current value of delegated bandwidth.
   This new value MUST lie between the required and preferred values,
   inclusive, from the request message.  If

4.7.  Delegated Bandwidth Query Request Message

   The Message Type for the request Delegated Bandwidth Query Request (and
   Response) messages is not met, 0x96.

   The Delegated Bandwidth Query Request message MAY be sent either by
   the
   Result field of NAS or by the Bandwidth Transfer message MUST be set AN to Failure
   (0x4) and the Bandwidth Allocation TLV MUST contain retrieve the value peer's view of the
   current amount of
   delegated bandwidth as bandwidth.  The request contains one TLV:

   o  a Target TLV designating the responder views it.

   To avoid deadlock due to race conditions, access line for which the following rules information
      is requested.

4.7.1.  Sender Behaviour

   The sender MUST be
   applied:

   a.  If set the NAS receives a Bandwidth Reallocation Request message
       while it has a Result field in the header of the Delegated
   Bandwidth Reallocation Query Request message of its own
       outstanding for the same access line, the NAS to AckAll (0x2).  The Code value MUST provide an
       immediate failure response
   be set to 0x000.  The sender MUST populate the request from the AN.

   b. ANCP Transaction
   Identifier field with a unique value, as described in section 5.4.5
   of [I-D.ietf-ancp-protocol].

4.7.2.  Receiver Behaviour

   If the AN or NAS receives a valid Delegated Bandwidth Reallocation Query Request message while
   message, it has MUST respond with a Delegated Bandwidth Reallocation Request message of its own
       outstanding for Query Response
   message.  The Result field in the same access line, header of 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.

   [Editor's Note: This is an arbitrary rule which gives priority be set
   to
   unicast over multicast.  Is that the right direction?]

4.7.  Bandwidth Transfer Message Success (0x3).  The Bandwidth Transfer message is used to transfer video bandwidth
   from the sender Code field MUST be set to the peer for a specific access line.  This message
   MAY 0x000.  The
   Transaction-Id field MUST be sent either copied from the AN or request message.  The
   body of the response MUST contain the Target TLV, copied from the NAS.  As described in
   request message.  Finally, the
   previous section, it is body of the required response to MUST contain a valid Bandwidth
   Reallocation Request message.

   The Bandwidth Transfer message MAY also be used to transfer
   Bandwidth-Allocation TLV, containing the current amount of delegated
   bandwidth
   autonomously from one peer to another.  One example the point of this usage is
   to release bandwidth borrowed earlier by means view of the receiver of the request.

   If the contents of the Delegated Bandwidth
   Reallocation Query Request message.  When the message is used are
   in this way, error, the receiver MUST return a Delegated Bandwidth Query
   Response message with the Result field in the Bandwidth Transfer message header set to Failure
   (0x3).  The Code field MUST be set to
   Ignore (0x0). the value that indicates the
   nature of the error (e.g., 0x004 "Unrecognized target").  The
   Transaction-Id field MUST be copied from the request.  The body of
   the response MUST contain the Target TLV copied from the request.
   This allows MAY be followed by a Status-Info TLV giving further infromation
   about the receiver error.

4.8.  Delegated Bandwidth Query Response Message

   The Delegated Bandwidth Query Response message is sent in reply to distinguish between an autonomous
      transfer and a
   Delegated Bandwidth Query Request.  The response to a previous Bandwidth Reallocation
      Request, for purposes valid request
   contains two TLVs:

   o  the Target TLV, copied from the request;

   o  a Bandwidth-Allocation TLV, giving the responder's view of validation. the
      current amount of multicast bandwidth delegated to the AN.

   The Message Type for the Delegated Bandwidth Transfer Query Response message
   is 0x95.  The 0x96.

4.8.1.  Sender Behaviour

   Sender behaviour for the Delegated Bandwidth Transfer Query Response message MUST contain
   is specified in Section 4.7.2.

4.8.2.  Receiver Behaviour

   If the following TLVs:

   o Delegated Bandwidth Query Response message indicates Success
   (0x3), the Target TLV, designating following actions apply.

4.8.2.1.  Behaviour at the access line concerned;

   o  an instance of NAS

   If the Bandwidth-Allocation TLV (Section 5.3).

   The amount of delegated bandwidth value provided in the Bandwidth-Allocation Bandwidth-
   Allocation TLV is less than the new NAS's view of the current amount of
   delegated bandwidth.  The following relationships bandwidth, the NAS MUST hold:

   o  if update its view of the message is sent by current
   amount of delegated bandwidth to the NAS, amount indicated in the
   Delegated Bandwidth Query Response message.

   If the amount of delegated bandwidth value provided in the
      Bandwidth-Allocation Bandwidth-
   Allocation TLV MUST be is greater than or equal to 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;

   o  if concerned, containing a Bandwidth-Allocation TLV with a
   value equal to the message is sent by amount of delegated bandwidth the AN, NAS wishes to
   enforce.

4.8.2.2.  Behaviour at the AN

   The AN SHOULD accept the bandwidth value returned in the
      Bandwidth-Allocation 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 less than or equal not to act on the current
      amount result of delegated bandwidth for
      the access line concerned.

   In either case, equality first query, but to repeat the current delegated bandwidth is
   permitted only for a failure response to a previous Bandwidth
   Reallocation Request.

   If query after sending the
      Bandwidth Transfer message satifies these conditions, 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
   receiver MUST update its view of Multicast Flow Query
   Request and Multicast Flow Query Response.  The Multicast Flow Query
   Request is sent by the amount of delegated bandwidth NAS to request information about the value given in the Bandwidth-Allocation TLV.  If, multicast
   flows that are active on the other
   hand, the bandwidth value in the Bandwidth-Value TLV AN.  The Multicast Flow Query Response
   is invalid, sent in response by the
   receiver MAY either accept AN to provide the new value or MAY choose requested information to initiate
   the delegated bandwidth reset procedure described in Section 4.10.

4.8.  Delegated Bandwidth Query Request and Response Messages NAS.

   The Message Type for the Delegated Bandwidth Multicast Flow Query Request and Multicast
   Flow Query Response messages is 0x96. 0x97.

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

4.9.1.  Sender Behaviour

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

   The Multicast Flow Query Request MAY be sent used by the NAS to retrieve 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 total amount of delegated bandwidth multicast flows currently active on each
      and every port of the amount that is already committed.  The request contains one
   TLV:

   o  a Target TLV designating AN.

   To retrieve the access line(s) for AN's view of which the
      information is requested.

   Consistently with other multicast-related messages, the Result field
   in the header multicast flows are currently
   active on one (or multiple) given port(s) of the Delegated Bandwidth Query Request message MUST
   be set to Ignore (0x0).

   If AN, the AN receives an invalid Delegated Bandwidth Multicast
   Flow Query Request
   message, it payload MUST return a Multicast Status message with the Result
   field in contain the header set to Failure (0x4).  The following cases may
   occur: TLVs:

   o  if the  Target TLV.  It MUST appear at least once.  Each occurence
      identifies one AN port for which information on active multicast
      flows is invalid, the Status-Info TLV contains the
      following values:

         Result Code = unrecognized target (0x04);

         Command Number = queried.  It is encoded as specified in
      [I-D.ietf-ancp-protocol].

   To retrieve the order AN's view of the invalid Target TLV within the
         request, numbering from 1 for the first which ports one listed;

         Error Message Length = 0x0 (or optionally the length of an
         error message, padded to a four-octet boundary);

         Error Message (optional text);

         the invalid Target TLV, copied from multiple) given
   multicast flow(s) is (are) currently active on, the Delegated Bandwidth Multicast Flow
   Query Request message. payload MUST contain the following TLVs:

   o  if bandwidth delegation  Multicast-Flow TLV.  It MUST appear at least once.  Each occurence
      identifies one multicast flow for which information is not activated queried.
      It is encoded as specified in Section 5.10.

   To retrieve the AN's view of all the multicast flows currently active
   on each port of the AN, the Status-
      Info TLV contains Multicast Flow Query Request payload MUST
   NOT contain any instance of the following values:

         Result Code = bandwidth delegation not activated (0x12);

         Command Number = 0x1;

         Error Message Length = 0x0 (or optionally Target TLV or the length of an
         error message, padded to a four-octet boundary);

         Error Message (optional text). Multicast-Flow TLV.

4.9.2.  Receiver Behaviour

   The AN MUST respond to a Multicast Flow Query Request message that
   has a valid request format and a valid content with a Delegated Bandwidth Multicast Flow Query Response.
   Response message.  The Result field in the header of this message response MUST be set to
   Success (0x3).  This message contains  The Code field MUST be set to 0x000.  The
   Transaction-Id field MUST be copied from the request.

   If the Multicast Flow Query Request contained one (or more) Target
   TLVs, the AN MUST include, for each of these Target TLVs, the
   following set of TLVs:

   o  Target TLV.  This MUST be identical to the Target TLV in the
      received Multicast Flow Query Request message.

   o  Multicast-Flow TLV(s).  The Multicast-Flow TLV MUST appear once
      per multicast flow that is currently active on the AN port
      identified in the preceding Target TLV, copied TLV.

   The Target TLVs MUST appear in the response from the request;

   o AN in the same
   order as in the query from the NAS.

   If the Multicast Flow Query Request contained one instance of (or more)
   Multicast-Flow TLVs, the Bandwidth-Status TLV (Section 5.5) AN MUST include, for each
      access line designated of these
   Multicast-Flow TLVs, the following set of TLVs:

   o  Multicast-Flow TLV.This MUST be identical to the Target TLV in the
      received Multicast Flow Query Request message.

   o  Target TLV. 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 instances Multicast-Flow TLVs MUST have
      the same order appear in the response as from the corresponding access lines AN in
   the Target TLV.

   [Editor's Note: the base protocol draft is incomplete regarding the
   specification of multiple access lines same order as in the Target TLV.]

4.9.  Multicast Flow Query Request and Response Messages

   This section defines two new messages called query from the NAS.

   If the Multicast Flow Query Request contained no Target TLV and no
   Multicast Flow Query Response.  The Multicast Flow Query
   Request is sent by the NAS to request information about TLV, the multicast
   flows that are active on AN MUST include, for each AN port, the AN.
   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 Query Response that is sent in response by currently active on the AN to provide port
      identified in the requested information to preceding Target TLV.

   If the NAS.

   The Message Type for contents of the Multicast Flow Query Request and Multicast
   Flow Query Response messages is 0x97.  The sender of are in error, the
   AN MUST reply with a Multicast Flow Query Request and Multicast Flow Query Response message MUST set with the
   Result field set to "0x00" meaning "Ignore".

   The Multicast Flow Query Request message MAY be sent by Failure (0x4) and the NAS Code field set to
   retrieve indicate
   the AN's view of which multicast flows are currently active
   on one (or multiple) given port(s) nature of the AN.  In that case, error.  If the
   Multicast Flow Query Request payload MUST contain request contained multiple instances
   of the following TLVs:

   o Target TLV.  It MUST appear at least once.  Each occurence
      identifies TLV or the Multicast-Flow TLV and one AN port for which information on active multicast
      flows is queried.  It is encoded as specified of these is in
      [I-D.ietf-ancp-protocol].

   The Multicast Flow Query Request
   error, the response message MAY MUST contain the results for the
   preceding instances of the TLV as if there had been no error.  These
   successful results MUST be sent followed by the NAS 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
   retrieve provide further information on
   the AN's view nature of which ports one (or multiple) given
   multicast flow(s) is (are) currently active on.  In that case, the
   Multicast Flow Query Request payload MUST contain error.

5.  ANCP TLVs and Sub-TLVs

   This section defines new ANCP TLVs and sub-TLVs or extends existing
   ones.

5.1.  Multicast-Service-Profile TLV

   This document defines the following TLVs:

   o  Multicast-Flow new Multicast-Service-Profile TLV.

   The Multicast-Service-Profile TLV MAY be included in a Provisioning
   message as specified in Section 4.1.

   The Multicast-Service-Profile is illustrated in Figure 6.  It MUST appear at least once.  Each occurence
      identifies
   consists of a TLV header, a Multicast-Service-Profile-Name sub-TLV,
   and one multicast flow for which information or more List-Action sub-TLVs.  The sub-TLVs are packed
   consecutively with no intervening padding.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Mcast Service Profile |             TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Multicast-Service-Profile-Name Sub-TLV                      |
       |   Sub-TLV type = 0x01                                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   List-Action Sub-TLV                                         |
       |   Sub-TLV type = 0x02                                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          ...                                  |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   List-Action Sub-TLV                                         |
       |   Sub-TLV type = 0x02                                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: Multicast-Servive-Profile TLV

   Multicast Service Profile TLV Type:

             TLV (0x13) : indicating that this is queried.
      It a Multicast Service
             Profile TLV

   The Multicast-Service-Profile-Name sub-TLV is encoded as specified shown in Section 5.9. Figure 7.  It
   consists of an eight-bit sub-TLV identifier with value 0x01, an
   eight-bit length field, and an identifier.  The Multicast Flow Query Request message MAY be sent by the NAS to
   retrieve length field gives
   the AN's view length of all the multicast flows currently active on
   each and every port identifier in octets.  The identifier consists of the AN.  In that case, the Multicast Flow
   Query Request payload MUST NOT contain the Target TLV nor the
   Multicast-Flow TLV.

   If the AN receives
   an invalid Multicast Flow Query Request message,
   it MUST return a Multicast Status message with the Result field in
   the header set opaque sequence of octets used to refer to Failure (0x4).  The following cases may occur:

   o  if the Target is invalid, the Status-Info TLV contains the
      following values:

         Result Code = unrecognized profile when
   activating it for a given target (0x04);
         Command Number = the order of the invalid Target TLV within a Port Management message
   (see Section 4.2).  The identifier MUST be unique over all profiles
   provisioned to the
         request, numbering from same AN partition.

        0 1 for the first one listed;

         Error Message Length 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 = 0x0 (or optionally the length 0x01   |  Length       |   Identifier ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 7: Multicast-Service-Profile-Name sub-TLV

   The List-Action sub-TLV is shown in Figure 8.  It consists of an
   eight-bit sub-TLV identifier with value 0x02, a four-bit action
   field, a four-bit list type field, a sixteen-bit length, and a
   sequence of multicast flow fields organized by address family.
   Either an
         error message, padded to a four-octet boundary);

         Error Message (optional text);

         the invalid Target TLV, copied from IPv4 list or an IPv6 list or both MAY be present in the
   sub-TLV.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type = 0x02   | Oper  | LType |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Version                    |          List Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Multicast Flow Query
         Request message.

   o  [Editor's note: if needed, add other error codes ???- eg if query
      contained both Target TLV and flow fields                      |
                                 ......
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Version                    |          List Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Multicast Flow TLV] flow fields                      |
                                 ......
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 8: List-Action Sub-TLV

   The AN MUST respond to a valid Multicast Flow Query Request message
   with a Multicast Flow Query Response message.

   If the Multicast Flow Query Request contained one (or more) Target
   TLV, fields within the AN MUST include, for each of these Target TLVs, List-Action TLV are defined as follows:

   Type:  always 0x02.

   Oper:  operation to be performed.  The possible values are Add (0x1),
      Delete (0x2), or Replace (0x3).  The operation indicates whether
      the
   following set of TLVs:

   o  Target TLV.  This MUST listed multicast flows are to be identical added to the Target TLV in list identified
      by the
      received Multicast Flow Query Request message.

   o  Multicast Flow TLV(s).  The Multicast Flow TLV MUST appear once
      per Multicast Flow list type field within the profile identified by the
      Multicast-Service-Profile-Name sub-TLV, deleted from that is currently active on list, or
      whether the listed flows should replace the current contents of
      the AN port identified in list.

   Ltype:  the preceding Target TLV. list type being modified by this list action.  The Target TLVs MUST appear in
      possible values are White (0x1), Black (0x2), or Grey (0x3).

   Length:  the response from length (in octets) of the AN in contents of the same
   order as in List-Action
      sub-TLV following the query from Length field itself.

   IP Version:  the NAS.

   If IP version of the Multicast Flow Query Request contained one (or more) Multicast
   Flow TLV, set of multicast flow fields that
      follow.  Possible values are 0x0000 (IPv4) or 0x0001 (IPv6).  As
      indicated above, either an IPv4 list or an IPv6 list or both MAY
      be present in the AN MUST include, for each sub-TLV.

   List length:  the length (in octets) of these Multicast Flow TLVs, the list of multicast flow
      fields following set the list length field.

   Multicast flow field:  a field identifying one or more multicast
      flows.  It consists of TLVs:

   o an 8-bit group address prefix length, an
      8-bit source address prefix length, a 0-16 octet group prefix, and
      a 0-16 octet source prefix, as shown in Figure 9.

   Each multicast flow field refers either to a Single Source Multicast Flow TLV.This MUST
   (SSM) channel or to an Any Source Multicast (ASM) group.  The scope
   of the designation may be identical broadened to multiple channels or groups
   through use of prefix length values smaller than the Target TLV in total address
   length for the
      received given address family.  Multicast Flow Query Request message.

   o  Target TLV(s).  The Target TLV flow fields MUST appear once per AN port on
      which be
   placed consecutively within the sub-TLV without intervening padding
   except to round out individual addresses to the nearest octet
   boundary.

   A multicast flow identified field consists of two single-octet prefix lengths
   followed by zero to two prefix values as shown in the preceding Figure 9:

       +-+-+-+-+-+-+-+-+
       | Group PrefLen |
       +-+-+-+-+-+-+-+-+
       | Source PrefLen|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Group Prefix (multicast)  (0 to 16 octets)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Source Prefix (unicast, SSM only) (0 to 16 octets)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 9: Organization of a Single Multicast Flow TLV Field

   The prefix length has its usual meaning.  It is active. the number of most-
   significant bits specified within the corresponding prefix.  The Multicast Flow TLVs MUST appear
   prefix length MAY vary from 0 to 32 in the response IPv4 sub-list, and from the AN 0
   to 128 in the same order as in IPv6 sub-list.

   A value of 0x00 for either the query from Group PrefLen (prefix length) or the NAS.

   If
   Source PrefLen indicates that any value of the Multicast Flow Query Request contained no Target TLV and no
   Multicast Flow TLV, corresponding address
   will match (wild card).  If the AN MUST include, value 0x00 is provided for each and every AN port, a
   particular prefix length, the following set of TLVs:

   o  Target TLV.  This MUST identify one AN port.

   o  Multicast Flow TLV(s).  The Multicast Flow TLV corresponding prefix MUST appear once
      per Multicast Flow that is currently active on the AN port
      identified in the preceding Target TLV.

4.10.  Delegated Bandwidth Reset Procedure

   As described above, be omitted
   from the receiver of a Bandwidth Reallocation Request
   or Bandwidth Transfer message may determine that field contents.  In particular, a bandwidth value in
   that message bears of 0x00 for the
   Source PrefLen indicates an incorrect relationship to its view of ASM multicast entry, and the
   current amount of delegated bandwidth. Source
   Prefix will be absent.

   The probable cause length of this
   condition is a discrepancy between its view and its peer's view of
   this amount.  Upon detecting this condition, the receiver MAY choose Source or Group Prefix field is equal to initiate the reset procedure described in this section.  If so, it
   MUST send a Multicast Status message (PrefLen +
   7)/8 octets, truncated to its peer with the Result
   field in nearest integer.  Unused bits at the header
   end of the prefix MUST be set to Failure (0x4) and a Status-Info zeroes.

5.2.  Command Number TLV
   containing the following values:

      Result Code = delegated bandwidth reset required (0x13);

   The Command Number = 0x1;

      Error Message Length = 0x0 (or optionally TLV conveys the length sequence number of an error
      message, padded to a four-octet boundary);

      Error Message (optional text); specific
   command within a Multicast Replication Control or Multicast Admission
   Request message.  Within this specification, the Target Command Number TLV
   itself is used as a sub-TLV within a Status-Info TLV, copied in a Generic
   Response reporting a failed command.

   The Command TLV has the format shown in Figure 10.  The sequnce
   number field is the sequence number of a specific command within a
   request, where numbering starts from 1 for the received message

      an instance first command.

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Command Number      |          TLV Length = 2       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Sequence number              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 10: Structure of the Command Number TLV

5.3.  Bandwidth-Allocation TLV containing the
      receiver's view of

   The Bandwidth-Allocation TLV is used to indicate the current total amount of
   video bandwidth delegated bandwidth.

   Upon sending or receiving a Multicast Status message containing this
   Result Code, the NAS MUST take to the following actions:

   1.  halt processing of AN for multicast admission requests control
   for the a given access line
       indicated by line, in kilobits per second.  The TLV has the Target
   format shown in Figure 11.  The TLV until Type for the reset procedure Bandwidth-Allocation
   TLV is
       complete;

   2.  issue a 0x15.

        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 Bandwidth Query request message amount (kbits/s)                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: The Bandwidth-Allocation TLV

5.4.  White-List-CAC TLV

   The White-List-CAC TLV is used to indicate that the AN to
       determine NAS wishes the amount of bandwidth it has currently committed AN
   to
       multicast usage, and its view of the amount of delegated
       bandwidth;

   3.  based do admission control for White-listed flows.  Details on when the reply and possibly
   White-List-CAC TLV may be provisioned are specified in consultation with the Policy
       Server, apply policy to determine what the amount of delegated
       bandwidth should be;

   4.  issue a Port Management message where the Access-Loop-Circuit-Id Section 6.

   The White-List-CAC TLV contains no data, thus its TLV Length field
   MUST have value 0.

5.5.  MRepCtl-CAC TLV

   The MRepCtl-CAC TLV is derived from used to indicate that the Target TLV in NAS wishes the AN to
   do admission control for flows added by the Multicast Status Replication
   Control message.  Details on when the MRepCtl-CAC TLV may be
   provisioned are specified in Section 6.

   The Port Management message MUST contain a Bandwidth-
       Allocation MRepCtl-CAC TLV giving the decided amount of delegated bandwidth.

   5.  update contains no data, thus its own view TLV Length field MUST
   have value 0.

5.6.  Bandwidth-Request TLV

   The Bandwidth-Request TLV is used to request an adjustment of the current
   total amount of delegated video bandwidth allocated to the decided amount.

   At this point the reset procedure is complete and the NAS can resume
   processing of AN for multicast
   admission requests control for the affected access line.

   Upon sending or receiving a Multicast Status message containing this
   Result Code, the AN MUST take given line.  The "Required amount" field
   indicates the following actions:

   1.  halt processing of admission requests for minimum adjustment required to meet the access line
       indicated by request.  The
   "Preferred amount" field indicates the Target TLV until adjustment the reset procedure is
       complete;

   2.  wait for and respond requestor would
   prefer to a Delegated Bandwidth Query request
       message, indicating have, if possible.  Section 4.5 discusses the amount required
   relationships between the "Required amount", "Preferred amount", and
   current values of total bandwidth it has currently
       committed allocated to multicast usage and its view of the amount of
       delegated bandwidth;

   3.  wait AN.

   The Bandwidth-Request TLV has the format shown in Figure 12.  The TLV
   Type for a Port Management message giving the decided Bandwidth-Request TLV is 0x16.

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = 0x16              |            TLV Length = 8       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Required amount  (kbits/s)                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Preferred amount (kbits/s)                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 12: The Bandwidth-Request TLV

5.7.  Multicast-Service-Profile-Name TLV

   The Multicast-Service-Profile-Name TLV carries the identifier of
       delegated bandwidth for a
   multicast service profile provisioned on the AN.

   o  Type (Multicast-Service-Profile-Name = 0x18): Reference to a
      multicast service profile on the access line concerned;

   4.  update its view of AN, that defines a White, Black,
      and/or Grey List depending on the current amount set of delegated bandwidth negotiated capabilities.

   o  Length : (up to 255 octets)

   o  Value : opaque sequence of octets identifying a specific profile.
      This MUST match one of the amount received in the Port Management message.

   At this point the reset procedure is complete and multicast service profile names
      provisioned on the AN can resume
   processing of admission requests for the affected access line.

5.  ANCP TLVs and Sub-TLVs

   This section in a Provisioning message or by other means.

5.8.  Request-Source-IP sub-TLV

   [I-D.ietf-ancp-protocol] defines new ANCP TLVs the Command TLV that can be used in
   a Multicast Replication Control message and sub-TLVs or extends existing
   ones.

5.1.  Multicast-Service-Profile (as defined in this
   document) in the Admission Control message.  The Command TLV MAY
   include sub-TLVs immediately following the Command Info field.

   This document defines the new Multicast-Service-Profile TLV. Request-Source-IP sub-TLV.

   The Multicast-Service-Profile TLV Request-Source-IP sub-TLV MAY be included in a Provisioning
   message as specified in Section 4.1. Command TLV inside
   an Admission Control message.

   The Multicast-Service-Profile Request-Source-IP sub-TLV is illustrated in Figure 5:

                            1                   2                   3 below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV
       |sub-TLV Type = Mcast Service Profile Request-Source-IP |             TLV Request-S-IP sub-TLV Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Multicast-Service-Profile-Name Sub-TLV                      |
       |   Sub-TLV type = 0x0001                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   White-List Sub-TLV                                          |
       |   Sub-TLV type = 0x0002                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Grey-List Sub-TLV                                           |
       |   Sub-TLV type = 0x0003                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Black-List Sub-TLV Addr Family   | Encoding Type   |   Sub-TLV type = 0x0004   Unicast Address           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: Multicast-Servive-Profile TLV

   Multicast Service Profile TLV Type:

             TLV (0x13) : indicating that this is a Multicast Service
             Profile TLV

   Each of the four sub-TLVs begins with a 32-bit header consisting of a
   16-bit

   Request-Source-IP sub-TLV type code followed by Type:

             sub-TLV (0x92) indicating the contents to be a 16-bit Request-
             Source-IP sub-TLV.

   Request-Source-IP sub-TLV Length:

             Combined length field giving the
   amount in bytes of the data following this inside sub-TLV.
             Excludes the sub-TLV header in octets.  The Header.

   Address Family, Encoding type
   code values for the respective sub-TLVs are indicated in and Unicast Address:

             Contains the figure.
   The content IP address of the sub-TLV follows immediately after the sub-TLV
   header.  The sub-TLVs are placed into sender of the list consecutively without
   intervening padding.  The Multicast Service Profile Name sub-TLV MUST
   be present, and MUST be unique over all profiles provisioned to join/leave
             message (e.g.  IGMP/MLD Join/Leave) that triggered the
   same AN partition.  At least one other sub-TLV MUST be present, but
   any of White List, Grey List, or Black List sub-TLV MAY be omitted if
   not applicable
             to this profile. include the corresponding Command TLV in an Admission
             Control message.  The Multicast-Service-Profile-Name sub-TLV IP address is an opaque sequence of
   octets used to refer to encoded as per
             [IANAAEA].

5.9.  Request-Source-MAC sub-TLV

   This document defines the profile when activating it for a given
   target within a Port Management message (see Section 4.2). new Request-Source-MAC sub-TLV.

   The content of the White-List, Grey-List, and Black-List sub-TLVs
   following their respective headers is in each case a sequence of
   multicast flow fields organized by address family.  IPv4 addresses
   are listed first, followed by IPv6 addresses.  Either set of
   addresses Request-Source-MAC sub-TLV MAY be omitted if not applicable, but at least one set of
   addresses MUST be present.  Figure 6 shows the detailed layout of a
   white, grey, or black list, where the detailed layout of an
   individual multicast flow field is described below.  The list length included in Figure 6 a Command TLV
   inside an Admission Control message.

   The Request-Source-MAC sub-TLV is the number of octets of multicast flow field data for
   that address family following the list header.

                            1                   2                   3 illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Sub-TLV tag = 0x0002,3,4      |       Sub-TLV Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Ver=0x0000  (IPv4)         |          List Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Multicast flow fields                      |
                                 ......
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Ver=0x0001  (IPv6)         |          List Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Multicast flow fields                      |
                                 ......
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 6: Organization of a White, Grey, or Black List

   Each multicast flow field refers either to a Single Source Multicast
   (SSM) channel or to an Any Source Multicast (ASM) group.  The scope
   of the designation may be broadened to multiple channels or groups
   through use of prefix length values smaller than the total address
   length for the given address family.  Multicast flow fields MUST be
   placed consecutively within the
       |sub-TLV Type=Request-Source-MAC  |Request-S-MAC sub-TLV without intervening padding
   except to round out individual addresses to the nearest octet
   boundary.

   A multicast flow field consists of two single-octet prefix lengths
   followed by zero to two prefix values as shown in Figure 7:

       +-+-+-+-+-+-+-+-+
       | Group PrefLen |
       +-+-+-+-+-+-+-+-+
       | Source PrefLen|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Group Prefix (multicast)  (0 to 16 octets)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Source Prefix (unicast, SSM only) (0 to 16 octets)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 7: 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 Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TBD                                                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Request-Source-MAC sub-TLV Type:

             sub-TLV (0x93) indicating the IPv4 sub-list, and from 0 contents to 128 be a Request-
             Source-MAC sub-TLV.

   Request-Source-MAC sub- TLV Length:

             Combined length in bytes of the IPv6 sub-list.  A match to the multicast flow
   specification is performed based on data inside sub-TLV.
             Excludes the prefix values only, ignoring
   lower-order bits in sub-TLV Header.

   TBD:

             Contains the respective addresses.

   A value IEEE MAC address of 0x00 for either the Group PrefLen (prefix length) or sender of the
   Source PrefLen indicates join/
             leave message (e.g.  IGMP/MLD Join/Leave) that any value of triggered
             the AN to include the corresponding Command TLV in an
             Admission Control message.  The IP address
   will match (wild card).  If the value 0x00 is provided for a
   particular prefix length, encoded as
             per TBD.

5.10.  Multicast-Flow TLV

   This document defines the corresponding prefix MUST new Multicast-Flow TLV.

   The Multicast-Flow TLV MAY be omitted
   from the field contents.  In particular, included in a Multicast Flow Query
   Request or Response message as specified in Section 4.9.

   The Multicast-Flow TLV is illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Multicast-Flow      |          TLV Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Source Address |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Source Address (Cont'd)  ...                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Group Address  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Group Address (Cont'd)  ...                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ...                          | Padding to 32-bit boundary    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Multicast-Flow TLV

   Multicast-Flow TLV Type:

             TLV (0x19) : indicating that this is a value Multicast-Flow TLV

   Multicast-Flow TLV Length:

             Length in bytes of 0x00 for the
   Source PrefLen indicates an ASM multicast entry, and the Source
   Prefix will be absent.

   The length of a Source or Group Prefix Value 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.1.1.  Profile Processing At the Access Node

   When the AN receives an IGMP/MLD Join request, it first checks
   whether TLV.  Excludes
             the program limit TLV Header (Type and Length).

   Addr Family, Encoding Type, Multicast Flow Source Address, Multicast
   Flow Group Address and Padding are encoded as specified for that subscriber has been exceeded.  If
   so, it discards the request.  Otherwise its next step is to determine
   whether the source and group
   corresponding field of the request match Command TLV in Section 4.3.

6.  Multicast Capabilities

   Section 5.3 of [I-D.ietf-ancp-protocol] defines a multicast flow
   specification capability
   negotiation mechanism as well as a number of capabilities.  This
   section defines four new capabilities in the support of different modes
   of multicast operation:

   o  NAS-initiated replication (capability type 0x05);

   o  conditional access with white list, the grey list, or the and black list
   according to the profile assigned to the access line.

   If the requested multicast flow matches multiple lists associated (capability type
      0x06);

   o  conditional access with grey lists (capability type 0x07);

   o  bandwidth delegation (capability type 0x08).

   The "Capability Data" field within the access line, then Capability TLV for all of
   these capabilities is empty.

   The remainder of this section consists of three sub-sections.
   Section 6.1 specifies the most specific match will protocol elements that must be considered
   by implemented
   in order to support each capability.  Section 6.2 specifies the AN.  If
   procedures that apply to each capability on its own.  Section 6.3
   specifies how the most specific match occurs capabilities interact if more than one multicast
   capability is included in multiple lists, the
   Black list entry takes precedence over the Grey list, which takes
   precedence over set of capabilities negotiated between
   the White list.  In this context, AN and the most specific
   match NAS.

   Note that if a request contains content that is defined as:

   o  first, most specific match on not supported
   (according to the multicast flow address (i.e. on
      G of <S,G>)

   o  then, most specific match on tables in Section 6.1) by the multicast source address (i.e. on
      S negotiated set of <S,G>)

   If the requested
   multicast flow capabilities, the appropriate response is to return a
   Generic Response message indicating Failure (0x4) with an appropriate
   code value (e.g., 0x84 "TLV or value not part supported by negotiated
   capability set").  The body of any list, the join message SHOULD be discarded by the AN. MUST contain a Status-Info
   TLV.  See Sections 5.4.5.1 and 5.4.5.2 in [I-D.ietf-ancp-protocol]
   for more details.

6.1.  Required Protocol Support

   This default behavior can
   easily section specifies the protocol elements that must be changed by means implemented
   to support each of a "catch-all" statement 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 either the
   White list or supported set.

6.1.1.  Protocol Requirements For NAS-initiated Replication

   Table 1 specifies the Grey list. protocol elements within Section 4 and
   Section 5 that must be implemented to support the NAS-initiated
   replication multicast capability.

   +--------------+----------------------------------------------------+
   | Reference    | Protocol Element                                   |
   +--------------+----------------------------------------------------+
   | Section 4.1  | Provisioning message with MRepCtl_CAC TLV          |
   |              |                                                    |
   | Section 4.2  | Port Management message with Bandwidth-Allocation  |
   |              | TLV.                                               |
   |              |                                                    |
   | Section 4.3  | Multicast Replication Control message              |
   |              |                                                    |
   | Section 4.9  | Multicast Flow Query Request and Response messages |
   |              |                                                    |
   | Section 5.2  | Command Number TLV                                 |
   |              |                                                    |
   | Section 5.5  | MRepCtl-CAC TLV                                    |
   |              |                                                    |
   | Section 5.10 | Multicast-Flow TLV                                 |
   +--------------+----------------------------------------------------+

   Table 1: Protocol Support Requirements For instance, adding (<S=*,G=*>) in the NAS-initiated Replication

6.1.2.  Protocol requirements For Conditional Access With White List would make and
        Black Lists

   Table 2 specifies the default behavior to accept join messages
   for a multicast flow protocol elements within Section 4 and
   Section 5 that has no other match on any list.

   If the requested multicast flow matches a flow in the black list, the
   AN discards the Join request.

   Otherwise, if bandwidth delegation is active for must be implemented to support the conditional access line, the
   AN determines whether it has enough unused capacity out of
   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, White and Black     |
   |              | lists only                                         |
   |              |                                                    |
   | Section 5.3  | Bandwidth-Allocation TLV                           |
   |              |                                                    |
   | Section 5.4  | White-List-CAC TLV                                 |
   |              |                                                    |
   | Section 5.7  | Multicast-Service-Profile-Name TLV                 |
   |              |                                                    |
   | Section 5.10 | Multicast-Flow TLV                                 |
   +--------------+----------------------------------------------------+

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

6.1.3.  Protocol requirements For Conditional Access With Grey Lists

   Table 3 specifies the total
   video bandwidth protocol elements within Section 4 and
   Section 5 that has been delegated must be implemented to it for multicast admission
   control.  If so, it does white or support the conditional access
   with grey list processing as described
   below.  If there is not enough unused bandwidth, it MAY issue a
   Bandwidth Reallocation lists multicast capability.

   +--------------+----------------------------------------------------+
   | 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 message.  The required bandwidth
   amount in and Response messages |
   |              |                                                    |
   | Section 5.1  | Multicast-Service-Profile TLV, Grey lists only     |
   |              |                                                    |
   | Section 5.2  | Command Number TLV                                 |
   |              |                                                    |
   | Section 5.3  | Bandwidth-Allocation TLV                           |
   |              |                                                    |
   | Section 5.5  | MRepCtl-CAC TLV                                    |
   |              |                                                    |
   | Section 5.7  | Multicast-Service-Profile-Name TLV                 |
   |              |                                                    |
   | Section 5.8  | Request-Source-IP sub-TLV                          |
   |              |                                                    |
   | Section 5.9  | Request-Source-MAC sub-TLV                         |
   |              |                                                    |
   | Section 5.10 | Multicast-Flow TLV                                 |
   +--------------+----------------------------------------------------+

    Table 3: Protocol Support Requirements For Conditional Access with
                                Grey Lists

6.1.4.  Protocol requirements For Delegated Bandwidth

   Table 4 specifies the Bandwidth-Request TLV MUST be large enough protocol elements within Section 4 and
   Section 5 that if the
   request is granted, there will must be sufficient unused capacity implemented to
   accommodate the Join request.  The AN MAY set the preferred amount in 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.3  | Bandwidth-Allocation TLV                           |
   |              |                                                    |
   | Section 5.6  | Bandwidth-Request TLV to the same value                              |
   |              |                                                    |
   | Section 5.10 | Multicast-Flow TLV                                 |
   +--------------+----------------------------------------------------+

      Table 4: Protocol Support Requirements For Delegated Bandwidth

6.2.  Capability-Specific Procedures for Providing Multicast Service

   This section describes multicast service procedures for each
   capability as the required amount,
   or to some higher amount determined by configured policy.  If the
   request fails or if the AN does not choose to issue a Bandwidth
   Reallocation Request (e.g., because another such request failed
   recently), it does no further processing of the Join request.

   If were the bandwidth check succeeds or if bandwidth delegation is not
   active, then:

   o  if only multicast capability within the requested
   negotiated set.  Procedures involving combinations of multicast flow matches a flow
   capabilities are described in Section 6.3.

   The use of the white list, Multicast Flow Query Request and Response messages to
   determine the AN MUST autonomously start replicating association between multicast flows and ports is common
   to all multicast traffic
      according capabilities.  No additional text is required here,
   beyond that already given in Section 4.9 to describe the request;

   o  if the requested flow matches use of those
   messages.

6.2.1.  Procedures For NAS-initiated Replication

   NAS-initiated replication MAY be negotiated to support a flow in the grey list, mode of
   operation where IGMP/MLD requests are terminated on the AN MUST
      send a Multicast Admission Control message (Section 4.5) NAS.
   Alternatively, it MAY be negotiated to allow the NAS with the value of Command set to Add (0x01) and await respond to
   requests sent by other means (e.g., through application signalling)
   that require the
      Multicast Replication Control message (Section 4.3) which responds replication of multicast channels to it.  Note that, when bandwidth delegation is active, a given access
   line.

   The NAS MAY enable admission control at the AN
      MUST NOT send the Multicast Admission Control message until for Nas-initiated
   replication.  To do this, it has
      fully established that the bandwidth checks succeeds (either
      because MUST include the AN has enough unused capacity MRepCtl-CAC TLV in a
   Provisioning message sent to the delegated
      bandwidth or because the AN requested and obtained the necessary
      increased delegated bandwidth AN.  It MUST also include a
   Bandwidth-Allocation TLV in a Bandwidth REallocation Response
      from the NAS).  When the Multicast ReplicationControl Port Management message
      arrives, for each access
   line.

   The procedures associated with NAS-initiated replication are
   straightforward.  To initiate replication, the AN NAS MUST act according to its content.  The AN MAY set send a timer after which it will take no further action on the Join
      request and will ignore the
   Multicast Replication Control
      response, if any.

   [Editor's Note: for grey list requests, there is a currently
   unfulfilled need to indicate to the NAS (or require the NAS message to know)
   whether admission control has been done at the AN. AN, containing one or
   more commands adding flows, as described in section ReplicSend.  If so,
   it does admission control itself, it MUST set the NAS
   can skip R flag in the Add
   commands.  If it has enabled admission control step in the AN and just apply policy.]

   When wishes
   the AN receives a Leave request to perform admission control for an admitted flow, the flows, it halts
   replication of MUST clear the indicated channel to
   R flag in the access line concerned.
   In Command TLV requesting the case of a grey list flow, it also notifies flow addition.  To terminate
   replication the NAS using the MUST send a a Multicast Admission Replication Control
   message with the Command TLV set to
   Delete (0x03).

5.2.  Bandwidth-Delegation-Control TLV

   This document defines where the new Bandwidth-Delegation-Control TLV. commands delete instead of adding them flows.

6.2.2.  Procedures For Conditional Access With Black and White Lists

6.2.2.1.  Provisioning

   The Bandwidth-Delegation-Control TLV MAY be included in a NAS provisions named multicast service profiles containing White
   and Black lists on the AN using the Provisioning message as specified in Section 4.1.

   The Bandwidth-Delegation-Control is illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Band-Del-Control    |          TLV Length = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|                Reserved                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ containing
   one or more Multicast-Service-Profile TLVs.  The Bandwidth-Delegation-Control TLV

   Bandwidth-Delegation-Control TLV Type:

             TLV (0x14) : indicating that this is a Bandwidth-
             Delegation-Control TLV

   Bandwidth-Delegation-Control TLV Length:

             Combined length in bytes of the data inside sub-TLV.
             Excludes NAS MAY update the sub-TLV Header.

   E Flag::

             When set
   contents of these profiles from time to 0, indicates that Bandwidth Delegation is time as required, by sending
   additional Provisioning messages with Multicast-Service-Profile TLVs
   containing incremental modifications to the existing White and Black
   lists or replacements for them.

   The NAS assigns a specific multicast service profile to be
             disabled on an individual
   access line using the AN.  When set Port Management message containing a Multicast-
   Service-Profile-Name TLV.

   The NAS MAY choose to 1, indicates enable admission control at the AN for White-
   listed flows.  To do this, it MUST send a Provisioning message as
   described in section provisioning, which includes the White-List-CAC
   TLV.  It MUST also provide a multicast bandwidth allocation for each
   access line by including a Bandwidth-Allocation TLV in a Port
   Management message.

6.2.2.2.  Multicast Service Procedures

   The conditional access with White and Black lists capability assumes
   that
             Bandwidth Delegation is to be enabled IGMP/MLD requests are terminated on the AN.  When
             Bandwidth Delegation is enabled, the AN
   receives a "join" request, it MUST subject
             multicast channels matching check to see whether the White List requested
   flow is White-listed or Black-listed as described below.  Requests
   for Black-listed flows MUST be discarded.  If the Grey List
             to NAS has enabled
   admission control according to on the Bandwidth Delegation
             procedures defined given access line as described in [I-D.ietf-ancp-framework].

   If Bandwidth Delegation is enabled, the NAS SHOULD provision an
   initial value for
   previous section, but the flow would cause the amount of committed
   multicast bandwidth delegated to exceed the provisioned limit, the request MUST
   be discarded.  Flows passing these checks are replicated to the
   access line.

   To determine if a requested flow is White-listed, the AN searches for
   multicast admission control for each line, in
   a Port Management (Line
   Configuration) message.  An initial delegated amount MAY be
   configured directly best match to the flow in the applicable multicast service profile.
   Matching is done on the AN.  A delegated bandwidth value received prefixes specified in a Port Management message overrides any configured value. the profile, ignoring
   the address bits of lower order than those in the prefix.

   If no
   value is configured and no value is provisioned the requested multicast flow matches multiple lists associated
   with the access line, then the most specific match will be considered
   by the NAS, AN.  If the
   default initial amount of delegated bandwidth is zero.

      This implies that most specific match occurs in multiple lists, the absence of provisioning or configuration,
   Black list entry takes precedence over the AN will issue a Bandwidth Reallocation Request message to White list.  In this
   context, the most specific match is defined as:

   o  first, most specific match (longest prefix length) on the
      NAS asking for
      multicast bandwidth, flow address (i.e., on G of <S,G>)

   o  then, most specific match (longest prefix length) on the first time it receives an
      IGMP/MLD Join for multicast
      source address (i.e. on S of <S,G>)

   If the given line.

5.3.  Bandwidth-Allocation TLV

   The Bandwidth-Allocation TLV requested multicast flow is used to indicate the total amount not part of
   video bandwidth delegated to any list, the AN for multicast admission control
   for join
   message SHOULD be discarded by the AN.  This default behavior can
   easily be changed by means of a given line, "catch-all" statement in kilobits per second.  The TLV has the format
   shown White
   list.  For instance, adding (<S=*,G=*>) in Figure 8.

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

                  Figure 8: The Bandwidth-Allocation TLV

   Bandwidth-Allocationl TLV Type:

             TLV (0x15) : indicating that this is a Bandwidth-Allocation
             TLV

5.4.  Bandwidth-Request TLV

   The Bandwidth-Request TLV is used to request an adjustment of the
   total amount of video bandwidth delegated White List would make
   the default behavior to the AN accept join messages for a multicast
   admission control for flow
   that has no other match on any list.

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

6.2.3.  Procedures For Conditional Access With Grey Lists

6.2.3.1.  Provisioning

   The "Required amount" field
   indicates NAS provisions named multicast service profiles containing Grey
   lists on the minimum adjustment required to meet AN using the request. Provisioning message containing one or more
   Multicast-Service-Profile TLVs.  The
   "Preferred amount" field indicates NAS MAY update the adjustment 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 requestor would
   prefer existing Grey lists or replacements
   for them.

   The NAS assigns a specific multicast service profile to have, if possible.  Section 4.6 discusses an individual
   access line using the required
   relationships between Port Management message containing a Multicast-
   Service-Profile-Name TLV.

   The NAS can enable admission control at the "Required amount", "Preferred amount", and
   current values of total bandwidth delegated AN for Grey-listed flows.

   To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning
   message sent to the AN.

   The Bandwidth-Request  It MUST also provide a Bandwidth-Allocation
   TLV has the format shown in Figure 9.

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

                    Figure 9: a Port Management message for each access line.

6.2.3.2.  Multicast Service Procedures

   The Bandwidth-Request TLV

   Bandwidth-Request TLV Type:

             TLV (0x16) : indicating conditional access with Grey lists capability assumes that this is IGMP/
   MLD requests are terminated on the AN.  When the AN receives a Bandwidth-Request
             TLV

5.5.  Bandwidth-Status TLV

   The Bandwidth-Status TLV "join"
   request, it MUST determine whether there is used a match to the requested
   flow in the Delegated Bandwidth Query
   Response Grey list of the multicast service profile provisioned
   against the given access line.  If there is no match, the request is
   discarded.  Otherwise, the AN MUST send a Multicast Admission Control
   message to report the AN's view of NAS with content identifying the current amount of delegated
   bandwidth access line and the amount of bandwidth within that quantity that is
   already committed
   multicast flow to active programs.  The Bandwidth-Status TLV has be added.  As indicated in Section 4.4, the format shown 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 Figure 10.

        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 = Band-Status       |            TLV Length = 8       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Delegated amount  (kbits/s)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Committed amount (kbits/s)                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 10: The Bandwidth-Status TLV

   Bandwidth-Status TLV Type:

             TLV (0x17) : indicating that this is
   section ReplicSend.  If admission control has been enabled at the AN
   for flows added by Multicast Replication Control messages, the NAS
   MAY invoke admission control for a Bandwidth-Status TLV

   The committed amount SHOULD be less than or equal to specific flow at the delegated
   amount.  One case where this may not be so is if AN by
   clearing the procedure
   described R flag in Section 4.10 the Command TLV that adds the flow.

   When the AN receives the Multicast Replication Control request, it
   performs admission control if admission control has been performed enabled and
   invoked by the NAS returned a
   delegated amount lower than clearing of the R flag.  If admitting the flow would
   cause the current committed amount.  Another
   case might be if bandwidth delegation was activated after multicast bandwidth had been allocated by other means.  Obviously such cases
   are exceptional and transient in nature.

5.6.  Multicast-Service-Profile-Name TLV

   [I-D.ietf-ancp-protocol] defines at the access line to exceed
   the provisioned limit, the AN reports an Extension TLV that can be used error to the NAS as
   described in
   ANCP messages.  It also defines section ReplicRecv.  Otherwise it replicates the
   multicast flow as requested.

   If the NAS decides not to permit the flow, it MAY send a number Multicast
   Replication Control message in response to the Multicast Admission
   Control message to allow the AN to update its internal records.  The
   content of TLVs that can be included this message is described in Section 4.4.2.

   When the Extension TLV when present (with AN receives a Tech Type set "leave" request, it MUST terminate replication
   of the flow to "DSL") in the access line.  It MUST then send a Port Management Multicast
   Admission Control message (e.g.  "Access-Loop-Circuit-ID", "Service-
   Profile-Name").

   This document defines an additional TLV that can appear in to the NAS indicating the deletion.  The
   NAS updates its internal records but MUST NOT respond to the message.

6.2.4.  Procedures For Delegated Bandwidth
6.2.4.1.  Provisioning

   The NAS SHOULD provision an
   Extension TLV initial amount of Tech Type "DSL" in a delegated multicast
   bandwidth for each access line using the Port Management message:

   o  Type (Multicast-Service-Profile-Name = 0x18): Reference message
   containing the Bandwidth-Allocation TLV.  (If it fails to do so and a
      multicast service profile
   value has not been provisioned on the AN, that defines a <White List,
      Black List, Grey List> triple.

         Length : (up to 64 bytes)

         Value : ASCII string containing the multicast profile name.

5.7.  Request-Source-IP sub-TLV

   [I-D.ietf-ancp-protocol] defines AN by other means, the Command TLV that can AN will
   be used in forced to request a bandwidth allocation as soon as it receives a
   "join" request.)

6.2.4.2.  Multicast Replication Control message and (as defined in this
   document) in the Admission Control message. Service Procedures

   The Command TLV MAY
   include sub-TLVs immediately following delegated bandwidth capability assumes that IGMP/MLD requests are
   terminated on the Command Info field.

   This document defines AN.  When the new Request-Source-IP sub-TLV.

   The Request-Source-IP sub-TLV MAY be included in AN receives a Command TLV inside
   an Admission Control message.

   The Request-Source-IP sub-TLV is illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type   |   Unicast Address           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Request-Source-IP sub-TLV Type:

             sub-TLV (0x92) indicating "join" request, it
   checks whether it has sufficient remaining uncommitted multicast
   bandwidth on the contents access line to be a Request-
             Source-IP sub-TLV.

   Request-Source-IP sub-TLV Length:

             Combined length in bytes of the data inside sub-TLV.
             Excludes the sub-TLV Header.

   Address Family, Encoding type and Unicast Address:

             Contains accommodate the IP address of new multicast flow.
   If not, it MAY send a request to the sender NAS for an increased allocation
   of delegated bandwidth, using the join/leave Bandwidth Reallocation Request
   message.  The NAS MUST return a Bandwidth Transfer message (e.g.  IGMP/MLD Join/Leave) that triggered 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 include admit the corresponding Command TLV in an Admission
             Control message.  The IP address is encoded
   request, either originally or as per
             [IANAAEA].

5.8.  Request-Source-MAC sub-TLV

   This document defines the new Request-Source-MAC sub-TLV.

   The Request-Source-MAC sub-TLV MAY be included in result of a Command TLV
   inside an Admission Control message.

   The Request-Source-MAC sub-TLV is illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |sub-TLV Type=Request-Source-MAC  |Request-S-MAC sub-TLV Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TBD                                                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Request-Source-MAC sub-TLV Type:

             sub-TLV (0x93) indicating successful request
   to the contents NAS, it replicates the requested flow to be the access line.
   Otherwise it discards the request.

   When the AN receives a Request-
             Source-MAC sub-TLV.

   Request-Source-MAC sub- TLV Length:

             Combined length in bytes "leave" request for an active flow, it ceases
   replication.

   The NAS or AN MAY at some point detect that their respective views of
   the data inside sub-TLV.
             Excludes 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 sub-TLV Header.

   TBD:

             Contains NAS or the IEEE MAC address of AN MAY
   from time to time check the sender peer's view of the join/
             leave message (e.g.  IGMP/MLD Join/Leave) that triggered amount of delegated
   bandwidth using the Delegated Bandwidth Query message.

   The NAS or AN MAY at any time release bandwidth to include the corresponding Command TLV in peer using an
             Admission Control
   autonomous Bandwidth Transfer message.  The IP address is encoded as
             per TBD.

5.9.  Multicast-Flow TLV

   This document defines the new Multicast-Flow TLV.

   The Multicast-Flow TLV MAY be included in a Multicast Flow Query
   Request or Response contents of this message as specified
   are described in Section 4.9.

   The Multicast-Flow TLV is illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Multicast-Flow      |          TLV Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Source Address |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Source Address (Ctnd)  ...                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Group Address  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 4.6.

6.3.  Combinations of Multicast Flow Group Address (Ctnd)  ...                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ...                          | Padding Capabilities

6.3.1.  Combination of NAS-Initiated Replication with Other Capabilities

   NAS-initiated replication can coexist with the other capabilities,
   but some means must exist to 32-bit boundary    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ prevent double replication of flows.
   The Multicast-Flow TLV

   Multicast-Flow TLV Type:

             TLV (0x19) : indicating that simplest way to do this is a Multicast-Flow TLV

   Multicast-Flow TLV Length:

             Length in bytes of the Value field of the TLV.  Excludes to terminate all IGMP/MLD requests on
   the TLV Header (Type and Length).

   Addr Family, Encoding Type, Multicast Flow Source Address, Multicast
   Flow Group Address AN, so that NAS-initiated replication is stimulated 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 Padding are encoded as specified for the
   corresponding field other
   multicast capabilities is in the area of admission control.
   Specifically, inclusion of the Command MRepCtl-CAC TLV in Section 4.3.

6.  New Capabilities

   [I-D.ietf-ancp-protocol] defines a capability negotiation mechanism
   as well as a number of capabilities.

   This document defines the following generic Provisiong
   message enables admission control for flows added by Multicast Capability Type
   allowing negotiation
   Replication Control messages, regardless of the level whether they are part of subcapability within the
   Multicast capability:

   o  Capability Type : Multicast = 0x03

         Length (in bytes) : 1

         Capability Data (1 byte):
   NAS-initiated replication or Grey list multicast service processing.
   The following values are defined:

         +  0x00: Reserved

         +  0x01: "Transactional Multicast"

         +  0x02: "Transactional Multicast" and "Multicast Admission
            Control without Bandwidth Delegation"

         +  0x03: "Transactional Multicast", "Multicast Admission
            Control without Bandwidth Delegation" and "Multicast
            Admission Control with Bandwidth Delegation"

         +  other values: Reserved

   Both the NAS and can control whether the AN MUST advertise the Multicast capability in
   their originated adjacency messages when they support it.  Initially,
   they indicate the full set of multicast subcapabilities that they
   respectively support does admission control for
   individual flows by its setting the Capability Value to the value
   corresponding to their respective supported set of subcapabilities.
   Then, if a received adjacency message indicates that the originating
   device supports a smaller set or clearing of multicast subcapabilities that the
   device receiving R flag in the message,
   Command TLV.  It is up to the receiving device NAS to choose how video bandwidth will turn off the
   multicast subcapabilities that are not supported by
   be allocated between itself and the other device AN, and will send an updated adjacency message to choose which
   allocation must support specific requests.

6.3.2.  Conditional Access With White, Black, and Grey Lists

   If conditional access with an updated Capability
   Value that now matches the one White and Black lists is combined with
   conditional access with Grey lists, provisioning of the other device.  This process
   will eventually result multicast
   service profiles is as described in both sides agreeing on the common set of
   supported Section 6.2.2.1 except that
   multicast subcapabilities.

   For example, if the NAS supports "Transactional Multicast" and
   "Multicast service profiles will also include Grey lists.  Admission Control without Bandwidth Delegation" while
   control is enabled independently for White lists by including the
   AN only supports "Transactional Multicast",
   White-list-CAC TLV in the NAS Provisioning message and AN will
   initially advertise for Grey lists by
   including the Multicast capability with a respective
   Capability Data of 0x02 MRepCtl-CAC TLV in the Provisioning message.  The
   Bandwidth-Allocation TLV provisions an amount that applies to both
   White- and 0x01.  On receipt Grey- listed flows if admission control is enabled for
   both.

   With regard to multicast service procedures, one point of the adjacency
   message difference
   from the AN, individual capabilities must be noted.  This is an
   interaction during the NAS will turn off its "Multicast Admission
   Control without Bandwidth Delegation" subcapability and will send a
   new adjacency message with a Multicast capability containing a
   Capability Data of 0x01.  From profile matching procedure.  The AN MUST seek
   the best match amongst multiple lists as described in
   Section 6.2.2.2.  However, if there on, are multiple matches of equal
   precision, the NAS order of priority is Black list first, Grey list
   second, and AN agree to make
   use White list last.

   Once profile matching has been completed, processing of (only) the "Transactional Multicast" subcapability.

   A NAS a "join"
   request is as described in Section 6.2.2.2 for White or AN supporting the "Transactional Multicast" subcapability
   MUST support the Multicast Replication message and the Multicast
   Status message.

   A NAS Black listed
   flows or AN supporting Section 6.2.3.2 for Grey listed flows.  Requests that do not
   match any list SHOULD be discarded.

   When the "Transactional Multicast" and "Multicast
   Admission Control without Bandwidth Delegation" subcapabilities AN receives a "leave" request, it MUST
   support terminate replication
   of the Multicast Admission Control message, flow to the Multicast
   Replication message and access line.  If the flow was Grey-listed, the Multicast Status message.

   A NAS or AN supporting the "Transactional Multicast", "Multicast
   Admission Control without Bandwidth Delegation" and "Multicast
   Admission Control with Bandwidth Delegation" capability
   MUST support
   the then send a Multicast Admission Control message, message to the Multicast Replication
   message, NAS
   indicating the Multicast Status message, deletion.  Thus the Bandwidth Reallocation
   Request and Response messages, AN needs to retain the Autonomous Bandwidth Transfer
   message and fact that
   the Delegated Bandwidth Query Request and Response
   messages.

7.  Example flow was Grey-listed for the life of Messages and Message Flows

   This section provides example message flows.

7.1.  Multicast the flow.

6.3.3.  Conditional Access and CAC without AN Combined With Delegated Bandwidth
      Delegation

   This section describes ANCP operations when multicast flows

   If either or both conditional access capabilities are
   subject to multicast Conditional Access and Admission Control without
   Bandwidth Delegation.

7.1.1.  List/Profile Provisioning

   The combined with
   the delegated bandwidth capability, the AN provisioning is performed by NAS using always does admission
   control.  Delegated bandwith simply provides a Provisioning message
   that contains White/Black/Grey lists and their corresponding
   "Multicast Service Profile Name".  To indicate to means for flexible
   sharing of video bandwidth between the AN that it need
   not perform any CAC operation on those flows, and the Provisioning
   message also conveys an indication that Bandwidth Delegation is NAS or Policy
   Server.  The provisioning, admission, and bandwidth management
   procedures of Section 6.2.4 apply in addition to be
   deactivated. the procedures in
   Section 6.2.2, Section 6.2.3, or Section 6.3.2 as applicable.

7.  Security Considerations

   The corresponding message flow is illustrated security considerations of ANCP are discussed in
   Figure 11.

 +----------+      +---------+               +-----+             +-----+
 |Subscriber|
   [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats].

8.  IANA Considerations

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

        +--------------------------------+--------+---------------+
        | Message                        | Number | Source        |
        +--------------------------------+--------+---------------+
        | Multicast Replication Control  | 90     | This document |  Home
        |                                | AN        |               | NAS
        |
 +----------+ Multicast Status               | 91     | This document | Gateway
        |               +-----+             +-----+                                |            +---------+        |               |
        | Multicast Admission Control    | 92     | This document |
        |                                |                      |(M1) Provisioning        |               |
        | Bandwidth Reallocation Request | (Mcast S Prof name, 94     | This document |
        |                                |     White List,        |               |
        | Bandwidth Transfer             |      Grey List, 95     | This document |
        |                                |        |      Black List,               |
        | Delegated Bandwidth Query      | 96     | This document | Bw Del Deactivated)
        |                                |        |                      |<--------------------|

        Figure 11: Provisioning AN with White/Grey/Black Lists               |
        | Multicast Flow Query           | 97     | This document |
        +--------------------------------+--------+---------------+

   This document defines the following values for
                            Conditional Access

   The Provisioning message M1 contains:

   o  an the ANCP Header with:

      *  Message-Type = 93 - Provisioning

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by NAS

   o  a Multicast-Service-Profile TLV containing:

      *  a Multicast-Service-Profile-Name sub-TLV

      *  an Empty White-List in our example (and hence no White-List
         sub-TLV)

      *  a Grey-List sub-TLV containing a catch-all entry for IPv4 (in
         our example)

      *  an Empty Black-List in our example (and hence no Black-List
         sub-TLV)

   The Provisioning message M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status-Info
   Result Code Registry :

   +----------------------------------------------+--------+-----------+
   |        Type (0x88-0C) Status                                       |           Length Number |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reference | Vers
   +----------------------------------------------+--------+-----------+
   |  Sub  |MessageType=93 Command not supported                        | 0x00 0x02   |        Code This      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID                                              |            Transaction Identifier = 0008        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number document  |           Length
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                              | Mcast-Service-Prof TLV Type        | Mcast-Service-Prof TLV Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sub-TLV Type = 0x0001 Flag set but not supported                   | 0x03   | This      |
   |                                              |        | document  |
   |                                              |       sub-TLV Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |
   |
       ~                    Multicast service profile name             ~ Unsupported Address Family                   | 0x05   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This      | sub-TLV Type = 0x0003
   |   sub-TLV Length = 0x06                                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        | IP ver = 0x00 document  |       List length = 0x02
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                              | Grp PLen=0x00        | Src PLen=0x00           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 12

7.1.2.  Profile Mapping

   As soon as the AN port comes up, the AN sends an ANCP PORT_UP message
   to the NAS specifying the Access Loop Circuit ID.  The NAS replies
   with an ANCP PORT_MNGT message that, together with the other
   parameters, includes the Multicast Service Profile Name to be
   associated to that Port.  The corresponding message
   | Malformed flow is
   illustrated in Figure 13.

 +----------+      +---------+               +-----+             +-----+
 |Subscriber| address                       |  Home 0x06   | This      | AN
   |                                              | NAS        |
 +----------+ document  | Gateway
   |               +-----+             +-----+                                              |            +---------+        |           |
   | Configuration error (such as Port not        | 0x0a   | This      |
   | enabled for multicast)                       |        | document  |
   |                                              |        |           |
   |      DSL Synch. Multicast flow does not exist                | 0x0b   | This      |                 |--------------------->|
   |                                              |        |                      |(M1)PORT_UP(Port ID) document  |
   |                                              |                      |-------------------->|        |           |
   |                    (*) Unsupported address encoding                 | 0x0c   |                      |(M2) PORT_MNGT This      |
   |                                              |        |    (Port ID, document  |
   |                                              |                      |Mcast S Profile Name)|        |           |                      |<--------------------|

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

               Figure 13: Associating Profile ID to AN Port

7.1.3.  Successful Join/Leave Operations

   The message flows in Figure 14 illustrates the ANCP message flow in
   case of a simple join and leave for a multicast flow that matches the
   grey list and when the "Bandwidth Delegation" mechanism is not
   activated in the AN.  In that case the AN queries the NAS that
   performs Conditional Access and Admission Control.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|
   | Home Additional info needed to execute command    | 0x0d   | This      | AN  |<---------->| NAS
   |
   +----------+    |Gateway|   +-----+            +-----+ (payload MAY contain an indication of the    |         +-------+        | document  |
   | expected info)                               |        |           |
   |      Join(Grey-Fl)                                              |     Admission        |
         |-----------+---------->|      Control (M1)           |
   | Multicast flow count exceeded                |           |------------------>| 0x0e   | This      |
   |                                              |        | document  |
   |     Multicast                                              |        |           |
   |     Replication  (*) M Flag set, but no IP Source address         | 0x0f   | This      |     Control (M2)
   | provided                                     |     Mcast Grey Flow   |<------------------|
         |<======================+        | document  |
   |                                              |        |
         ~           ~           ~                   ~           |
   | Invalid preferred bandwidth amount           | 0x11   | This      |     Leave(Grey-Fl)
   |     Admission                                              |
         |-----------+---------->|      Control (M3)        | document  |
   |           |------------------>|                                              |        |           |
   |

   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (Bandwidth Delegation bandwidth delegation not activated on AN)

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

                Figure 14: Successful Join/Leave Operations

   The Multicast Admission Control message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Add
      *  R = 0

      *  O = 0

      *  the multicast flow for which the IGMP Join was received by AN=
         (192.0.2.1, 233.252.2.2)

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

   The Multicast Admission Control message M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |        Type (0x88-0C) 0x12   |           Length This      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers                                              |  Sub  |MessageType=92        | 0x00 document  |        Code
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                              | Partition ID        |            Transaction Identifier = 0001           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number
   |           Length Delegated bandwidth reset required           | 0x13   | This      |
   |                                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        | document  |
   +----------------------------------------------+--------+-----------+

   This document defines the following additional values within the ANCP
   TLV Type = 0x1000 (Target) Registry:

      +--------------------------------+-----------+---------------+
      |        Target TLV Length Name                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Code | Access-Loop-Circuit-ID 0x0001 Reference     |        Circuit-ID Length
      +--------------------------------+-----------+---------------+
      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multicast-Service-Profile      | 0x13      |
       ~                    Access Loop Circuit ID                     ~ This document |
      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                |  Type = 0xTBD (Command) TLV           |       Command-TLV Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cmd Code=0x01 |0 0 1 Bandwidth-Delegation-Control   |      Command Length 0x14      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document | AddrFamily 01
      | EncType 0x0                                |  Mcast Source: 192.0.2.1           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               | AddrFamily 01
      | EncType 0x0 Bandwidth-Allocation           |  Mcast Flow : 233.252.2.2 0x15      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV This document | Request-S-IP sub-TLV Length
      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                | AddrFamily 01           | EncType 0x0               |  Source : 192.0.2.100
      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

   The Multicast Replication Control message M2 contains:

   o  an ANCP Header with:

      *  Message-Type = 90 - Multicast Replication Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by NAS

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Add

      *  R= 1 (since in our example the flow resources have been
         admitted by NAS)

      *  O = 0 (since in our example flow accounting is not required)

      *  the multicast flow for which the IGMP Join was received by AN=
         (192.0.2.1, 233.252.2.2)

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

   The Multicast Admission Control message M2 is illustrated below:

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bandwidth-Request              |        Type (0x88-0C) 0x16      |           Length This document |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers                                |  Sub  |MessageType=90           | 0x00               |
      | Bandwidth-Status               | 0x17      | This document |
      |                                |           |               |
      | Multicast-Service-Profile-Name | 0x18      | This document |
      |                                |           |               |
      | Multicast-Flow                 | 0x19      | This document |
      +--------------------------------+-----------+---------------+

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

   +-------------------------------------+----------------+------------+
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command Code Directive Name         | Partition ID Command Code   |            Transaction Identifier = 0009 Reference  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number
   |           Length                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value          |   Type = 0x1000 (Target)            |        Target TLV Length
   +-------------------------------------+----------------+------------+
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Add                                 | Access-Loop-Circuit-ID 0x0001 0x01           |        Circuit-ID Length This       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                     |
       ~                | document   |
   |                                     |                |            |
   | Delete                              | 0x02           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Delete All                          | 0x03           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Admission Control Reject            | 0x04           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Conditional Access Loop Circuit ID                     ~ Reject           | 0x05           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This       |  Type = 0xTBD (Command) TLV
   |       Command-TLV Length                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                | Cmd Code=0x01 |1 0 1 document   |      Command Length
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                     | AddrFamily 01                | EncType 0x0            |  Mcast Source: 192.0.2.1
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Admission Control and Conditional   | AddrFamily 01 0x06           | EncType 0x0 This       |  Mcast Flow : 233.252.2.2
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) Access Reject                       |                | document   |
   +-------------------------------------+----------------+------------+

   This document defines the following additional values to the ANCP
   sub-TLV Type registry:

            +--------------------+-----------+---------------+
            | Request-S-IP sub-TLV Length Name       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Code | AddrFamily 01 Reference     | EncType 0x0
            +--------------------+-----------+---------------+
            |  Source : 192.0.2.100 Request-Source-IP  | 0x92      | This document |
            |                    |           |               |
            | Request-Source-MAC | 0x93      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ This document |
            +--------------------+-----------+---------------+

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 Admission Control message M3 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying Flow Reporting solution.
   Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided
   substantial contributions on the AN Port

   o  a Command TLV containing:

      *  a Command Code = Delete

      *  R = 0

      *  O = 0

      * solution for the NAS initiated
   multicast flow control use case.

10.  References

10.1.  Normative References

   [I-D.ietf-ancp-framework]
              Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
              Wadhwa, "Framework and Requirements for an Access Node
              Control Mechanism in Broadband  Multi-Service Networks",
              draft-ietf-ancp-framework-12 (work in progress),
              October 2009.

   [I-D.ietf-ancp-protocol]
              Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt,
              N., and R. Maglione, "Protocol for Access Node Control
              Mechanism in Broadband Networks",
              draft-ietf-ancp-protocol-07 (work in progress),
              October 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

10.2.  Informative References

   [I-D.ietf-ancp-security-threats]
              Moustafa, H., Tschofenig, H., and S. Cnodder, "Security
              Threats and Security Requirements for which the IGMP leave was received by AN=
         (192.0.2.1, 233.252.2.2)

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

   The Multicast Admission Control message M3 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0002      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0002 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~ Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x02 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = 0xTBD (Request-S.) TLV  |    Request-S.-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

7.1.4. Node
              Control  Protocol (ANCP)",
              draft-ietf-ancp-security-threats-08 (work in progress),
              July 2009.

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

   [IANAAEA]  "http://www.iana.org/assignments/address-family-numbers",
              2005.

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

Appendix A.  Example of Messages and Message Flows

   This section provides example message flows.

A.1.  Multicast Conditional Access and CAC without AN bandwidth
      delegation

   This section describes ANCP operations when multicast flows are
   subject to multicast Conditional Access and Admission Control Reject without NAS Response
   bandwidth delegation.

A.1.1.  List/Profile Provisioning

   The message flow in Figure 15 illustrates the ANCP message flow in
   case of a join that AN provisioning is rejected performed by the NAS because of admission
   control using a Provisioning message
   that contains White/Black/Grey lists and without explicit response from their corresponding
   "Multicast Service Profile Name".  To indicate to the NAS.  In AN that case, it need
   not perform any CAC operation on those flows, the multicast Provisioning
   message also conveys an indication that bandwidth delegation is to be
   deactivated.  The corresponding message flow is never replicated simply by virtue of the NAS
   not requesting replication. illustrated in
   Figure 13.

 +----------+    +-------+      +---------+               +-----+    ANCP             +-----+
 |Subscriber|      |  Home   |               | AN  |<---------->|  |             | NAS |
 +----------+    |Gateway|      | Gateway |               +-----+             +-----+
      |         +-------+     |            +---------+                 |                     |
      |                 |                      |                     |      Join(Grey-Fl)
      |     Admission                 |
         |-----------+---------->|      Control (M1)                      |(M1) Provisioning    |
      |                 |           |------------------>|                      | (Mcast S Prof name, |
      |                 |                      |     White List,     |
      |                  (*)                 |                      |      Grey List,     |
      |                 |     Mcast Grey Flow                      |      Black List,    |
      |       not replicated  x                 |                      | Bw Del Deactivated) |
      |                 |

   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (Bandwidth Delegation not activated on AN)

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

        Figure 15: Admission Control Reject without NAS Response 13: Provisioning AN with White/Grey/Black Lists for
                            Conditional Access

   The Multicast Admission Control Provisioning message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 93 - Multicast Admission Control Provisioning

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying the AN Port NAS

   o  a Command Multicast-Service-Profile TLV containing:

      *  a Command Code = Add

      *  R = 0

      *  O = 0 Multicast-Service-Profile-Name sub-TLV

      *  the multicast flow for which the IGMP join was received by AN=
         (192.0.2.1, 233.252.2.3).  an Empty White-List in our example (and hence no White-List
         sub-TLV)

      *  a Request-Source-IP Grey-List sub-TLV containing the IGMP join source IP
         (192.0.2.100). a catch-all entry for IPv4 (in
         our example)

      *  an Empty Black-List in our example (and hence no Black-List
         sub-TLV)

   The Multicast Admission Control Provisioning message M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92  |MessageType=93 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0003 0008      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Mcast-Service-Prof TLV Type = 0x1000 (Target)   |        Target Mcast-Service-Prof TLV Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID sub-TLV Type = 0x0001         |        Circuit-ID       sub-TLV Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                    Multicast service profile name             ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | sub-TLV Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1 0x0003         |      Command   sub-TLV Length = 0x06       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.3     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type IP ver = (Request-S-IP) sub-TLV 0x00                 | Request-S-IP sub-TLV Length       List length = 0x02      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0 Grp PLen=0x00 |  Source : 192.0.2.100 Src PLen=0x00 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

7.1.5.  Admission Control Reject with NAS Response

   The message flow in
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 16 illustrates 14

A.1.2.  Profile Mapping

   As soon as the AN port comes up, the AN sends an ANCP PORT_UP message flow in
   case of a join that is rejected by
   to the NAS because of admission
   control and with explicit response from the NAS.  In that case, specifying the
   multicast flow is not replicated by virtue of Access Loop Circuit ID.  The NAS replies
   with an ANCP PORT_MNGT message that, together with the NAS explicitely
   signaling to other
   parameters, includes the AN Multicast Service Profile Name to be
   associated to that the multicast Port.  The corresponding message flow is not to be replicated.
   illustrated in Figure 15.

 +----------+    +-------+      +---------+               +-----+    ANCP             +-----+
 |Subscriber|      |  Home   |               | AN  |<---------->|  |             | NAS |
 +----------+    |Gateway|      | Gateway |               +-----+             +-----+
      |         +-------+            +---------+                 |                     |
      |                 |                      |                     |
      |      Join(Grey-Fl)                 |     Admission                      |
         |-----------+---------->|      Control (M1)                     |
      |                 |           |------------------>|      DSL Synch.      |                     |
      |                 |--------------------->|                     |
      |                 |                      |(M1)PORT_UP(Port ID) |     Multicast    (*)
      |                 |                      |-------------------->|
      |     Replication                 |                      |                    (*)
      |                 |     Control (M2)                      |(M2) PORT_MNGT       |
      |     Mcast Grey Flow   |<------------------|                 |       not replicated  x                      |    (Port ID,        |
      |                 |                      |Mcast S Profile Name)|
      |

   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (Bandwidth Delegation not activated on AN)                 |                      |<--------------------|

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

               Figure 16: Admission Control Reject with NAS Response 15: Associating Profile ID to AN Port

A.1.3.  Successful Join/Leave Operations

   The Multicast Admission Control message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying flows in Figure 16 illustrates the AN Port

   o ANCP message flow in
   case of a Command TLV containing:

      * simple join and leave for a Command Code = Add

      *  R = 0

      *  O = 0

      *  the multicast flow for which that matches the IGMP join was received by AN=
         (192.0.2.1, 233.252.2.4).

      *  a Request-Source-IP sub-TLV containing
   grey list and when the IGMP join source IP
         (192.0.2.100).

   The Multicast Admission Control message M1 "bandwidth delegation" mechanism is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ not
   activated in the AN.  In that case the AN queries the NAS that
   performs Conditional Access and Admission Control.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    |        Type (0x88-0C) Home  |           Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AN  |<---------->| NAS | Vers
   +----------+    |Gateway|   +-----+            +-----+
         |  Sub  |MessageType=92         +-------+     | 0x00                   |        Code
         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           | Partition ID           |            Transaction Identifier = 0004                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number
         |           Length      Join(Grey-Fl)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Admission     |   Type = 0x1000 (Target)
         |-----------+---------->|      Control (M1) |        Target TLV Length
         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           | Access-Loop-Circuit-ID 0x0001           |------------------>|
         |        Circuit-ID Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |                   |
       ~                    Access Loop Circuit ID                     ~
         |           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |  Type = 0xTBD (Command) TLV     Multicast     |       Command-TLV Length
         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           | Cmd Code=0x01 |0 0 1           |      Command Length     Replication  (*)
         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           | AddrFamily 01           | EncType 0x0     Control (M2)  |
         |     Mcast Source: 192.0.2.1 Grey Flow   |<------------------|
         |<======================+                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | AddrFamily 01           | EncType 0x0           |  Mcast Flow : 233.252.2.4                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV
         ~           ~           ~                   ~
         | Request-S-IP sub-TLV Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           | AddrFamily 01                   | EncType 0x0
         |  Source : 192.0.2.100     Leave(Grey-Fl)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+     Admission     |
         |-----------+---------->|      Control (M3) |
         |           |           |------------------>|
         |           |           |                   |

   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (bandwidth delegation not activated on AN)

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

                Figure 16: Successful Join/Leave Operations

   The Multicast Replication Admission Control message M2 M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 90 92 - Multicast Replication Admission Control

      *  Result= 0x00

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

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Admission Control Reject (since in our example
         the flow is rejected by NAS because of bandwidth admission
         control and not because of conditional access) Add
      *  R=  R = 0 (since in our example the flow resources have not been
         admitted by NAS)

      *  O = 0 (since in our example flow accounting is not required)

      *  the multicast flow for which the IGMP Join was received by AN=
         (192.0.2.1, 233.252.2.4) 233.252.2.2)

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

   The Multicast Admission Control message M2 M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=90  |MessageType=92 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0010 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0xTBD|0 Code=0x01 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4 233.252.2.2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

7.2.  Example Flows For Bandwidth Delegation

   As noted in Section 5.1.1, the operation of bandwidth delegation is
   supplemental to the operation of request processing in the absence of
   bandwidth delegation.  Thus the same flows shown in the previous
   section continue to hold, except that the AN does multicast call
   admission before doing grey and white list processing.

   The example
   flows of this section are therefore limited to the incremental
   operations of bandwidth delegation.  They include initial
   provisioning, Multicast Replication Control message M2 contains:

   o  an ANCP Header with:

      *  Message-Type = 90 - Multicast Replication Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by NAS

   o  a successful request from Target TLV identifying the AN for an increase Port

   o  a Command TLV containing:

      *  a Command Code = Add

      *  R= 1 (since in
   delegated bandwidth, an autonomous transfer of the borrowed bandwidth
   back to the NAS, and the initiation of the bandwidth reset procedure
   (Section 4.10) by the NAS when it finds that our example the amount of delegated
   bandwidth passed flow resources have been
         admitted by the AN NAS)

      *  O = 0 (since in our example flow accounting is larger than its current view of that
   amount.

7.2.1.  Activation and Provisioning of Delegated Bandwidth

   Activation of bandwidth delegation occurs at not required)

      *  the level of multicast flow for which the AN as a
   whole and is done IGMP Join was received by including AN=
         (192.0.2.1, 233.252.2.2)

      *  a Bandwidth-Delegation-Control TLV in
   the Provisioning message with Request-Source-IP sub-TLV containing the E-flag set to 1. IGMP join source IP
         (192.0.2.100).

   The Multicast Admission Control message flow M2 is as shown in Figure 11.  In place of Figure 12 we have the
   following content within the Provisioning message:

                       1                   2                   3 illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=93  |MessageType=90 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0008 0009      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Mcast-Service-Prof TLV   Type = 0x1000 (Target)      | Mcast-Service-Prof        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | sub-TLV Type = Access-Loop-Circuit-ID 0x0001 |       sub-TLV        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Multicast service profile name                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | sub-TLV  Type = 0x0003 0xTBD (Command) TLV   |   sub-TLV       Command-TLV Length = 0x06      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP ver = 0x00 Cmd Code=0x01 |1 0 1          |       List length = 0x02      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Grp PLen=0x00 AddrFamily 01 | Src PLen=0x00 EncType 0x0   |           Padding = 0x00  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | TLV Type AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = Band-Del-Control (Request-S-IP) sub-TLV  |       TLV Request-S-IP sub-TLV Length = 0x04   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|      Reserved  = 0x00
       |        Reserved AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

   The Multicast Admission Control message M3 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 17

   Once bandwidth delegation has been activated, the NAS must provision
   the amount of delegated bandwidth for each access line (unless it is
   pre-configured on the AN).  This requires

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying the AN Port Management message
   with

   o  a Bandwidth-Allocation TLV.  The same Port Management message
   may be used to provision other information, such as Command TLV containing:

      *  a Command Code = Delete

      *  R = 0

      *  O = 0

      *  the multicast
   service profile name applicable to flow for which the IGMP leave was received by AN=
         (192.0.2.1, 233.252.2.2)

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

   The information
   flow is therefore similar to that in Figure 13.  In the following
   figure, an initial allocation of 8000 kbits/s Multicast Admission Control message M3 is provided.

    0                   1                   2                   3 illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92 | 0x00  | Msg Type = 32 |Rslt =1|        Code = 0           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0002      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Port   Type = 0 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Port Session Number Access-Loop-Circuit-ID 0x0002 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Event Sequence Number                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x|   Duration
       |    Func  Type = 8 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x02 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = 0xTBD (Request-S.) TLV  |    Request-S.-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

A.1.4.  Admission Control Reject without NAS Response

   The message flow in Figure 17 illustrates the ANCP message flow in
   case of a join that is rejected by the NAS because of admission
   control and without explicit response from the NAS.  In that case,
   the multicast flow is never replicated simply by virtue of the NAS
   not requesting replication.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |      Join(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M1) | X-Func = 0
         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |           Event Flags           |------------------>|
         |        Flow Control Flags           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Msg Type = 32           | Tech Type = 5                   | Block Len = 0
         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |     # of TLVs = 2           | Ext Block length                  (*)
         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |      TLV Type = 0x01           |  Access-Loop-Cct-ID length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Mcast Grey Flow   |
   ~                 Access-Loop-Circuit-ID                        ~                   |
         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       not replicated  x                   |  TLV Type = Bandwidth-Alloc
         |         TLV length = 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |                 Delegated amount = 8000                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (bandwidth delegation not activated on AN)

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

         Figure 18: Port Management Message Allocating Delegated Bandwidth

7.2.2.  Successful Request For More Delegated Bandwidth

   Suppose that the AN allocates all 8000 kbits/s of its delegated
   amount and receives a Join request requiring another 2000 kbits/s. 17: Admission Control Reject without NAS Response

   The Multicast Admission Control message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

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

   o  a Bandwidth Reallocation Request message where the
   required amount field is set to acquire this amount of additional
   bandwidth.  Since the request is framed in terms of total delegated
   bandwidth, required amount is 10000 kbits/s.  Suppose that Target TLV identifying the AN is
   configured with Port

   o  a policy that causes it to request enough Command TLV containing:

      *  a Command Code = Add

      *  R = 0

      *  O = 0

      *  the multicast flow for one
   additional channel as which the IGMP join was received by AN=
         (192.0.2.1, 233.252.2.3).

      *  a preferred amount.  Hence Request-Source-IP sub-TLV containing the preferred amount
   is set to 12000 kbits/s. IGMP join source IP
         (192.0.2.100).

   The Bandwidth Reallocation Request Multicast Admission Control message
   has the following format:

    0                   1                   2                   3 M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0003      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.3     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

A.1.5.  Admission Control Reject with NAS Response

   The message flow in Figure 18 illustrates the ANCP message flow in
   case of a join that is rejected by the NAS because of admission
   control and with explicit response from the NAS.  In that case, the
   multicast flow is not replicated by virtue of the NAS explicitely
   signaling to the AN that the multicast flow is not to be replicated.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |  Sub                   | MsgTyp = 94   |Rslt=0
         |        Code = 0      Join(Grey-Fl)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Admission     | Partition ID
         |-----------+---------->|      Control (M1) |            Transaction Identifier
         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number           |           Length           |------------------>|
         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |    TLV Type = Target           |        Target-TLV Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Access-Loop-Circuit-ID=0x0001           |       Circuit-ID Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Multicast    (*)
         |           |
   ~                    Access Loop Circuit ID                     ~           |     Replication   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Request
         |          TLV Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           |           Required amount =  10000     Control (M2)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Preferred amount = 12000     Mcast Grey Flow   |<------------------|
         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       not replicated  x                   |
         |           |           |                   |

   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (bandwidth delegation not activated on AN)

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

           Figure 19: Example Bandwidth Reallocation Request Message

   In response to this request, the 18: Admission Control Reject with NAS is willing to grant the full
   preferred amount.  (It could have granted any value between 10000 and
   12000, or it could have rejected the request.) Response

   The Bandwidth
   Transfer Multicast Admission Control message sent as M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a response indicates that the new delegated
   bandwidth amount is 12000 kbits/s, as shown in Target TLV identifying the next figure. AN Port

   o  a Command TLV containing:

      *  a Command Code = Add

      *  R = 0                   1                   2                   3

      *  O = 0

      *  the multicast flow for which the IGMP join was received by AN=
         (192.0.2.1, 233.252.2.4).

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

   The Multicast Admission Control message M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92 | MsgTyp = 95   |Rslt=3 0x00  |        Code = 0           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0004      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    TLV   Type = Target 0x1000 (Target)      |        Target-TLV        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID=0x0001 Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV
       |  Type = Bandwidth-Alloc     | 0xTBD (Command) TLV   |       Command-TLV Length = 4      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Delegated amount Cmd Code=0x01 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = 12000 (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 20: Example Bandwidth Transfer Message (Success Response)

7.2.3.  Failed Autonomous Transfer With Reset

   Suppose the AN decides after an interval that it should return 2000
   kbits/s of the 4000 kbits/s that it acquired from the NAS in the
   previous transaction.  It therefore issues a Bandwidth Transfer
   message of its own.  This message differs from the message in
   Figure 20 in two ways.  First, because this is an autonomous transfer
   rather than a response, the Result field in the header is set to
   Ignore (0x0).  Secondly, the Delegated amount is reduced to 10000
   kbits/s.

   Now suppose that somehow the NAS forgot that it passed an additional
   4000 kbits/s to the AN.  Thus its current view of the amount of
   delegated bandwidth is 8000 kbits/s.
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

   The 10000 kbits/s appearing in
   the Bandwidth Transfer Multicast Replication Control message is higher than this, so there is
   clearly M2 contains:

   o  an ANCP Header with:

      *  Message-Type = 90 - Multicast Replication Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by NAS

   o  a disgareement between Target TLV identifying the NAS and AN Port

   o  a Command TLV containing:

      *  a Command Code = Admission Control Reject (since in our example
         the AN.  The flow is rejected by NAS chooses
   to initiate the reset procedure, perhaps because it is close to
   committing all of its available video bandwidth for unicast service.
   As admission
         control and not because of conditional access)

      *  R= 0 (since in our example the initial step flow resources have not been
         admitted by NAS)

      *  O = 0 (since in this procedure, it issues our example flow accounting is not required)

      *  the multicast flow (192.0.2.1, 233.252.2.4)

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

   The Multicast Status Admission Control message indicating that a reset of the delegated amount is required.
   This M2 is shown in the following figure. illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=91  |MessageType=90 | 0x4 0x00  |        Code = 0           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0010      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Status-info-TLV=TBD    |      Status-TLV-Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Rslt Code = xx | Cmd No = 1    |    Error Message Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Error Message (padded to 4) if Length > 0           |
   +---------------------------------------------------------------+
   |    TLV   Type = Target 0x1000 (Target)      |        Target-TLV        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID=0x0001 Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV
       |  Type = Bandwidth-Alloc     | 0xTBD (Command) TLV   |       Command-TLV Length = 4      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Delegated amount Cmd Code=0xTBD|0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = 8000 (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Result Code field within the Status-Info TLV contains
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

A.2.  Example Flows For bandwidth delegation

   As noted in TBD, the value:
   delegated operation of bandwidth reset required (0xTBD).

        Figure 21: Example Initiation delegation is
   supplemental to the operation of Delegated Bandwidth Reset

   The NAS stops request processing video service requests for in the given access
   line when it sends absence of
   bandwidth delegation.  Thus the same flows shown in the previous
   section continue to hold, except that the AN does multicast call
   admission before doing grey and white list processing.  The example
   flows of this message.  Similarly, section are therefore limited to the incremental
   operations of bandwidth delegation.  They include initial
   provisioning, a successful request from the AN stops processing for an increase in
   total multicast video service requests when it receives bandwidth, an autonomous transfer of the message.  [To
   think about: can service requests that release borrowed
   bandwidth be safely
   processed?  Probably.]  The next step is up back to the NAS: it sends a
   Bandwidth Delegation Query Request message NAS, and the initiation of the bandwidth reset
   procedure [text to be modified] by the AN.  The Result
   field in NAS when it finds that the header
   amount of total multicast bandwidth passed by the AN is set to Ignore (0x0) larger than
   its current view of that amount.

A.2.1.  Activation and Provisioning of total multicast Bandwidth

   Activation of bandwidth delegation occurs at the level of the AN as usual for multicast-
   related messages.  The Target TLV a
   whole and is done by including a copy of the one received Bandwidth-Delegation-Control TLV in
   the original Bandwidth Transfer message. Provisioning message with the E-flag set to 1.  The message flow
   is as shown in Figure 13.  In place of Figure 14 we have the
   following figure:

    0 content within the Provisioning message:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type (0x88-0C)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  |MessageType=93 | MsgTyp = 96   |Rslt=0 0x00  |        Code = 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier = 0008      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Mcast-Service-Prof TLV Type = Target   |        Target-TLV Mcast-Service-Prof TLV Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 sub-TLV Type = 0x0001         |       Circuit-ID       sub-TLV Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                    Multicast service profile name             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sub-TLV Type = 0x0003         |   sub-TLV Length = 0x06       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP ver = 0x00                 |       List length = 0x02      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Grp PLen=0x00 | Src PLen=0x00 |           Padding = 0x00      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TLV Type = Band-Del-Control   |       TLV Length = 0x04       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|      Reserved  = 0x00       |        Reserved  = 0x00       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 22: Example Delegated Bandwidth Query Request Message

   The AN returns a Delegated Bandwidth Query Response message showing
   that it believes that 19

   Once bandwidth delegation has been activated, the NAS must provision
   the amount of delegated total multicast bandwidth is 10000
   kbits/s and for each access line (unless
   it has committed 8000 kbits/s of it. is pre-configured on the AN).  This requires a Port Management
   message with a Bandwidth-Allocation TLV.  The Result field in same Port Management
   message may be used to provision other information, such as the header shows Success (0x3)
   multicast service profile name applicable to distinguish the response. [... in
   case we decide access line.  The
   information flow is therefore similar to make that in Figure 15.  In the query bidirectional ...]
   following figure, an initial allocation of 8000 kbits/s is provided.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | MsgTyp Msg Type = 96   |Rslt=3 | 32 |Rslt =1|        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port = 0                          |
   ~                    Access Loop Circuit ID                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Request
   |          TLV Length = 8                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x|   Duration    |           Delegated amount    Func =  10000                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8   |           Committed amount X-Func =  8000 0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 23: Example Delegated Bandwidth Query Response Message

   The NAS decides to reset the delegated bandwidth amount to 8000
   kbits/s.  It issues a Port Management message looking exactly like
   the one in Figure 18.  Once it sends this message, it resumes
   processing service requests for the access line concerned.
   Similarly, the AN resumes request processing after it receives the
   Port Management message and resets its view of the current delegated
   bandwidth.  In the short run, this means that it will have to ask for
   more bandwidth if it receives another Join request.  [It seems
   reasonable that the AN would not do so for a period of time after a
   reset or a response to a Bandwidth Reallocation Request that grants
   less than the preferred amount.  Should we establish a timer?]

7.3.  Example Flows For Multicast Flow Reporting

7.3.1.  Per Port Multicast Flow Reporting

   Figure 24 illustrate a message flow in the case where the NAS queries
   the AN about which multicast flow is active on port 10, on port 20
   and on port 11 of the AN.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home
   |           Event Flags         | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+        Flow Control Flags     |         +-------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type = 5 | Block Len = 0 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs = 2             |  Multicast Flow Ext Block length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TLV Type = 0x01          |  Access-Loop-Cct-ID length    |  Query Request
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                 Access-Loop-Circuit-ID                        ~
   |                                                               |      (M1)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TLV Type = Bandwidth-Alloc   |         TLV length = 4        |           |<------------------|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Delegated amount = 8000                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 20: Port Management Message Allocating total multicast
                                 Bandwidth

A.2.2.  Successful Request For More Multicast Bandwidth

   Suppose that the AN allocates all 8000 kbits/s of its total multicast
   amount and receives a Join request requiring another 2000 kbits/s.
   The AN issues a Bandwidth Reallocation Request message where the
   required amount field is set to acquire this amount of additional
   bandwidth.  Since the request is framed in terms of total total
   multicast bandwidth, required amount is 10000 kbits/s.  Suppose that
   the AN is configured with a policy that causes it to request enough
   for one additional channel as a preferred amount.  Hence the
   preferred amount is set to 12000 kbits/s.  The Bandwidth Reallocation
   Request message has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | MsgTyp = 94   |Rslt=0 |        Code = 0       | Multicast Flow
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      | Query Response           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          |        Target-TLV Length      |      (M2)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |           |------------------>|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Request   |          TLV Length = 8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Required amount =  10000                            |

               Figure 24: Per Port Multicast Flow Reporting

   The Multicast Flow Query
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Preferred amount = 12000                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 21: Example Bandwidth Reallocation Request Message

   In response to this request, the NAS is willing to grant the full
   preferred amount.  (It could have granted any value between 10000 and
   12000, or it could have rejected the request.)  The Bandwidth
   Transfer message (M1) sent as a response indicates that the new total
   multicast bandwidth amount is illustrated 12000 kbits/s, as shown in
   Figure 25. the next
   figure.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Msg Type MsgTyp = 97 |Rslt=00| 95   |Rslt=3 |        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          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port20)                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   |TLV Type = 0x1000 (Target) Bandwidth-Alloc     |        Target          TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port11)            ~
   |           Delegated amount = 12000                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 25: Multicast Flow Query Request 22: Example Bandwidth Transfer Message (Success Response)

A.2.3.  Failed Autonomous Transfer With Reset

   Suppose the AN decides after an interval that it should return 2000
   kbits/s of the 4000 kbits/s that it acquired from the NAS in the
   previous transaction.  It therefore issues a Bandwidth Transfer
   message for per-port Mulicast
                              Flow Reporting of its own.  This message differs from the message in
   Figure 22 in two ways.  First, because this is an autonomous transfer
   rather than a response, the Result field in the header is set to
   Ignore (0x0).  Secondly, the Delegated amount is reduced to 10000
   kbits/s.

   Now suppose that somehow the NAS forgot that it passed an additional
   4000 kbits/s to the AN.  Thus its current view of the amount of total
   multicast bandwidth is 8000 kbits/s.  The Multicast Flow Query Response 10000 kbits/s appearing in
   the Bandwidth Transfer message (M2) is illustrated in
   Figure 26.  It indicates that higher than this, so there is one active multicast flow
   [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on
   port 20
   clearly a disgareement between the NAS and two active the AN.  The NAS chooses
   to initiate the reset procedure, perhaps because it is close to
   committing all of its available video bandwidth for unicast service.
   As the initial step in this procedure, it issues a Multicast Status
   message indicating that a reset of the total multicast 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 amount is
   required.  This is shown in the following figure.

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type (0x88-0C)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  |MessageType=91 | 0x4   | Msg Type = 97 |Rslt=00|        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port10)             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0        Status-info-TLV=TBD    |  Mcast Source: 192.0.2.1      Status-TLV-Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Rslt Code = xx | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |   Type Cmd No = 0x1000 (Target) 1    |        Target TLV    Error Message Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID           Error Message (padded to 4) if Length > 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port20)             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +---------------------------------------------------------------+
   |    TLV Type = 0x1000 (Target)      | Target TLV          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port11)                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4
   |TLV Type = Bandwidth-Alloc     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |Type=0x19 (Multicast-Flow)          TLV | Multicast Flow-TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.2           Delegated amount = 8000                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.10    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+

   The Result Code field within the Status-Info TLV contains the value:
   total multicast bandwidth reset required (0xTBD).

        Figure 26: 23: Example Initiation of Multicast Flow Bandwidth Reset

   The NAS stops processing video service requests for the given access
   line when it sends this message.  Similarly, the AN stops processing
   multicast video service requests when it receives the message.  [To
   think about: can service requests that release bandwidth be safely
   processed?  Probably.]  The next step is up to the NAS: it sends a
   bandwidth delegation Query Response Request message to the AN.  The Result
   field in the header is set to Ignore (0x0) as usual for per-port
                          Mulicast Flow Reporting

8.  Security Considerations multicast-
   related messages.  The security considerations Target TLV is a copy of ANCP are discussed the one received in
   [I-D.ietf-ancp-protocol] and
   the original Bandwidth Transfer message.  The message is shown in [I-D.ietf-ancp-security-threats].

9.  IANA Considerations

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

        +--------------------------------+--------+---------------+
        | Message                        | Number | Source        |
        +--------------------------------+--------+---------------+
        | Multicast Replication Control  | 90     | This document |
        | figure:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | MsgTyp = 96   |Rslt=0 | Multicast Status        Code = 0       | 91
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | This document Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          | Multicast Admission Control        Target-TLV Length      | 92
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | This document Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 24: Example Delegated Bandwidth Reallocation Query Request | 94     | This document |
        |                                |        |               |
        | Bandwidth Transfer             | 95     | This document |
        |                                |        |               |
        | Message

   The AN returns a Delegated Bandwidth Query      | 96     | This document |
        |                                |        |               |
        | Multicast Flow Query           | 97     | This document |
        +--------------------------------+--------+---------------+

   This document defines the following values for Response message showing
   that it believes that the ANCP Status-Info amount of total multicast bandwidth is
   10000 kbits/s and it has committed 8000 kbits/s of it.  The Result Code Registry :

   +----------------------------------------------+--------+-----------+
   | Status                                       | Number | Reference |
   +----------------------------------------------+--------+-----------+
   | Command not supported                        | 0x02   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Flag set but not supported                   | 0x03   | This      |
   |                                              |        | document  |
   |                                              |        |
   field in the header shows Success (0x3) to distinguish the response.
   [... in case we decide to make the query bidirectional ...]
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  | Unsupported Address Family  Sub  | 0x05 MsgTyp = 96   |Rslt=3 | This        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             | document
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Malformed flow address Access-Loop-Circuit-ID=0x0001 | 0x06       Circuit-ID Length       | This
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               | document
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Request   |          TLV Length = 8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Delegated amount =  10000                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Committed amount =  8000                            | Configuration error (such as
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 25: Example Delegated Bandwidth Query Response Message

   The NAS decides to reset the total multicast bandwidth amount to 8000
   kbits/s.  It issues a Port not        | 0x0a   | This      |
   | enabled Management message looking exactly like
   the one in Figure 20.  Once it sends this message, it resumes
   processing service requests for multicast)                       |        | document  |
   |                                              |        |           |
   | Multicast flow does not exist                | 0x0b   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Unsupported address encoding                 | 0x0c   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Additional info needed the access line concerned.
   Similarly, the AN resumes request processing after it receives the
   Port Management message and resets its view of the current total
   multicast bandwidth.  In the short run, this means that it will have
   to execute command    | 0x0d   | This      |
   | (payload MAY contain an indication ask for more bandwidth if it receives another Join request.  [It
   seems reasonable that the AN would not do so for a period of time
   after a reset or a response to a Bandwidth Reallocation Request that
   grants less than the    |        | document  |
   | expected info)                               |        |           |
   |                                              |        |           |
   | preferred amount.  Should we establish a timer?]

A.3.  Example Flows For Multicast Flow Reporting

A.3.1.  Per Port Multicast Flow Reporting

   Figure 26 illustrate a message flow count exceeded                | 0x0e   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | M Flag set, but no IP Source address         | 0x0f   | This      |
   | provided                                     |        | document  |
   |                                              |        |           |
   | Invalid preferred bandwidth amount           | 0x11 in the case where the NAS queries
   the AN about which multicast flow is active on port 10, on port 20
   and on port 11 of the AN.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | This Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         | document         +-------+     |                   |
         |           |           |  Multicast Flow   | Bandwidth delegation not activated
         | 0x12           | This           |  Query Request    |
         |           | document           |      (M1)         |
         |           |           |<------------------|
         |           | Delegated bandwidth reset required           | 0x13                   | This
         |           |           | Multicast Flow    | document
         |
   +----------------------------------------------+--------+-----------+

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

      +--------------------------------+-----------+---------------+           | TLV Name           | Type Code Query Response    | Reference
         |
      +--------------------------------+-----------+---------------+           | Multicast-Service-Profile           | 0x13      (M2)         | This document
         |           |           |------------------>|
         |           |           |                   | Bandwidth-Delegation-Control
         | 0x14           | This document           |                   |

               Figure 26: Per Port Multicast Flow Reporting

   The Multicast Flow Query Request message (M1) is illustrated in
   Figure 27.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Msg Type = 97 |Rslt=00|        Code = 0       | Bandwidth-Allocation
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x15 Partition ID  | This document            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      | Bandwidth-Request
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x16 Access-Loop-Circuit-ID 0x0001 | This document        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port10)            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Bandwidth-Status   Type = 0x1000 (Target)      | 0x17        Target TLV Length      | This document
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port20)            ~
   | Multicast-Service-Profile-Name                                                               | 0x18
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | This document   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Multicast-Flow                                                               | 0x19
   ~                    Access Loop Circuit ID (port11)            ~
   | This document                                                               |
      +--------------------------------+-----------+---------------+

   This document defines the following values
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 27: Multicast Flow Query Request message for the ANCP Command Code
   registry:

   +-------------------------------------+----------------+------------+
   | Command Code Directive Name         | Command Code   | Reference  |
   |                                     | Value          |            |
   +-------------------------------------+----------------+------------+
   | Add                                 | 0x01           | This       |
   |                                     |                | document   |
   |                                     |                |            | per-port Mulicast
                              Flow Reporting

   The Multicast Flow Query Response message (M2) is illustrated in
   Figure 28.  It indicates that there is one active multicast flow
   [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on
   port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and
   (192.0.2.2, 233.252.2.10)] on port 11.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Delete Vers  | 0x02  Sub  | This Msg Type = 97 |Rslt=00|        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             | document
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Delete All Access-Loop-Circuit-ID 0x0001 | 0x03        Circuit-ID Length      | This
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port10)             ~
   |                                                               | document
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      | Admission Control Reject
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x04 AddrFamily 01 | This EncType 0x0   |  Mcast Flow : 233.252.2.4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |   Type = 0x1000 (Target)      | document        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               | Conditional
   ~                    Access Reject           | 0x05           | This       |
   |                                     |                | document Loop Circuit ID (port20)             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admission Control and Conditional Access-Loop-Circuit-ID 0x0001 | 0x06        Circuit-ID Length      | This
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Reject                       |                | document Loop Circuit ID (port11)            ~
   |
   +-------------------------------------+----------------+------------+

   This document defines the following additional values to the ANCP
   sub-TLV Type registry:

            +--------------------+-----------+---------------+                                                               | sub-TLV Name
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=0x19 (Multicast-Flow) TLV | Type Code Multicast Flow-TLV Length     | Reference
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
            +--------------------+-----------+---------------+ AddrFamily 01 | Request-Source-IP EncType 0x0   | 0x92  Mcast Source: 192.0.2.1      | This document
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length     | Request-Source-MAC
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0x93 AddrFamily 01 | This document EncType 0x0   |
            +--------------------+-----------+---------------+

10.  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  Mcast Source: 192.0.2.2      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.10    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       Figure 28: 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.

11.  References

11.1.  Normative References

   [I-D.ietf-ancp-framework]
              Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
              Wadhwa, "Framework and Requirements for an Access Node
              Control Mechanism in Broadband  Multi-Service Networks",
              draft-ietf-ancp-framework-10 (work in progress), May 2009.

   [I-D.ietf-ancp-protocol]
              Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt,
              N., and R. Maglione, "Protocol for Access Node Control
              Mechanism in Broadband Networks",
              draft-ietf-ancp-protocol-05 (work in progress),
              March 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

11.2.  Informative References

   [I-D.ietf-ancp-security-threats]
              Moustafa, H., Tschofenig, H., and S. Cnodder, "Security
              Threats and Security Requirements Query Response message for the Access Node
              Control  Protocol (ANCP)",
              draft-ietf-ancp-security-threats-07 (work in progress),
              March 2009.

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

   [IANAAEA]  "http://www.iana.org/assignments/address-family-numbers",
              2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006. per-port
                          Mulicast 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
   Telecom Italia
   Via Reiss Romoli 274
   Torino  10148
   Italy

   Phone:
   Email: roberta.maglione@telecomitalia.it

   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   Canada

   Phone: +1 613 680 2675
   Email: tom.taylor@rogers.com tom111.taylor@bell.net