GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7256

Internet Engineering Task Force (IETF) F. Le Faucheur Request for Comments: 7256 R. Maglione Updates: 6320 Cisco Category: Standards Track T. Taylor ISSN: 2070-1721 Huawei

                                                             July 2014

Multicast Control Extensions for the Access Node Control Protocol (ANCP)

Abstract

 This document specifies the extensions to the Access Node Control
 Protocol (ANCP) (RFC 6320) required for support of the multicast use
 cases defined in the Access Node Control Protocol framework document
 (RFC 5851) and one additional use case described in this document.
 These use cases are organized into the following ANCP capabilities:
 o  multicast replication initiated by the Network Access Server
    (NAS);
 o  conditional access and admission control with white and black
    lists;
 o  conditional access and admission control with grey lists;
 o  bandwidth delegation; and
 o  committed bandwidth reporting.
 These capabilities may be combined according to the rules given in
 this specification.
 This document updates RFC 6320 by assigning capability type 3 to a
 capability specified in this document and by changing the starting
 point for IANA allocation of result codes determined by IETF
 Consensus from 0x100 to 0x64.

Le Faucheur, et al. Standards Track [Page 1] RFC 7256 ANCP Multicast Extensions July 2014

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7256.

Copyright Notice

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

Table of Contents

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

Le Faucheur, et al. Standards Track [Page 2] RFC 7256 ANCP Multicast Extensions July 2014

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

Le Faucheur, et al. Standards Track [Page 3] RFC 7256 ANCP Multicast Extensions July 2014

         6.1.2. Protocol Requirements for Committed
                Multicast Bandwidth Reporting ......................54
         6.1.3. Protocol Requirements for Conditional
                Access and Admission Control with White
                and Black Lists ....................................55
         6.1.4. Protocol Requirements for Conditional
                Access and Admission Control with Grey Lists .......56
         6.1.5. Protocol Requirements for Bandwidth Delegation .....57
    6.2. Capability-Specific Procedures for Providing
         Multicast Service .........................................57
         6.2.1. Procedures for NAS-Initiated Multicast
                Replication ........................................58
         6.2.2. Procedures for Committed Bandwidth Reporting .......58
         6.2.3. Procedures for Conditional Access and
                Admission Control with Black and White Lists .......59
         6.2.4. Procedures for Conditional Access and
                Admission Control with Grey Lists ..................61
         6.2.5. Procedures for Bandwidth Delegation ................63
    6.3. Combinations of Multicast Capabilities ....................64
         6.3.1. Combination of Conditional Access and
                Admission Control with White and Black Lists
                and Conditional Access and Admission Control
                with Grey Lists ....................................64
         6.3.2. Combination of Conditional Access and
                Admission Control with Bandwidth Delegation ........65
         6.3.3. Combination of NAS-Initiated Replication
                with Other Capabilities ............................65
         6.3.4. Combinations of Committed Bandwidth
                Reporting with Other Multicast Capabilities ........66
 7. Miscellaneous Considerations ...................................66
    7.1. Report Buffering Considerations ...........................66
    7.2. Congestion Considerations .................................67
 8. Security Considerations ........................................67
 9. IANA Considerations ............................................69
 10. Acknowledgements ..............................................72
 11. References ....................................................73
    11.1. Normative References .....................................73
    11.2. Informative References ...................................73
 Appendix A.  Example of Messages and Message Flows ................75
   A.1.  Provisioning Phase ........................................75
   A.2.  Handling Grey-Listed Flows ................................81
   A.3.  Handling White-Listed Flows ...............................87
   A.4.  Handling of Black-Listed Join Requests ....................92
   A.5.  Handling of Requests to Join and Leave the On-Line Game ...92
   A.6.  Example Flow for Multicast Flow Reporting .................95

Le Faucheur, et al. Standards Track [Page 4] RFC 7256 ANCP Multicast Extensions July 2014

1. Introduction

 [RFC5851] defines a framework and requirements for an Access Node
 (AN) control mechanism between a Network Access Server (NAS) and an
 Access Node (e.g., a Digital Subscriber Line Access Multiplexer
 (DSLAM)) in a multi-service reference architecture in order to
 perform QoS-related, service-related, and subscriber-related
 operations.  [RFC6320] specifies a protocol for Access Node Control
 in broadband networks in line with this framework.
 [RFC6320] supports, specifically for DSL access, three use cases
 defined in [RFC5851]: the Topology Discovery use case, the Line
 Configuration use case, and the Remote Connectivity Test use case.
 However, it does not support the multicast use cases defined in
 [RFC5851].  The present document specifies the extensions to the
 Access Node Control Protocol required for support of these multicast
 use cases.  In addition, it supports the Committed Bandwidth
 Reporting use case, described below.  In terms of ANCP, these use
 cases are organized into five capabilities:
 o  NAS-initiated multicast replication;
 o  conditional access and admission control with white and black
    lists;
 o  conditional access and admission control with grey lists;
 o  bandwidth delegation; and
 o  committed bandwidth reporting.
 NAS-initiated multicast replication assumes that multicast join and
 leave requests are terminated on the NAS or that the NAS receives
 requests to establish multicast sessions through other means (e.g.,
 application-level signaling).  The NAS sends commands to the AN to
 start or stop replication of specific multicast flows on specific
 subscriber ports.  This use case is described briefly in the next-to-
 last paragraph of Section 3.4 of [RFC5851].
 Conditional access is described in Section 3.4.1 of [RFC5851].
 Section 3.4.2.2 of [RFC5851] mentions a way in which conditional
 access can be combined with admission control to allow best-effort
 multicast flows, and Section 3.4.2.3 points out the necessary
 conditions for using both conditional access and admission control.
 In the case of "conditional access and admission control with white
 and black lists", multicast join and leave requests are terminated at
 the AN and accepted or ignored in accordance with the direction

Le Faucheur, et al. Standards Track [Page 5] RFC 7256 ANCP Multicast Extensions July 2014

 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 combine conditional access with admission
 control of white-listed flows by appropriate provisioning.
 Conditional access and admission control with grey lists is similar
 to conditional access and admission control with white lists, except
 that before accepting any request matching a grey list entry, the AN
 sends a request to the NAS for permission to replicate the flow.
 Again, the NAS can enable admission control of grey-listed flows at
 the AN.
 Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851].
 It allows flexible sharing of total video bandwidth on an access line
 between the AN and the NAS.  One application of such bandwidth
 sharing is where the AN does multicast admission control, while the
 NAS or Policy Server does unicast admission control.  In that case,
 bandwidth delegation allows dynamic sharing of bandwidth between
 unicast and multicast video traffic on each access line.
 Committed bandwidth reporting is described in Section 3.4.  The AN
 reports the amount of multicast bandwidth it has granted to a given
 access line each time that value changes.  These reports may be
 buffered for a NAS-provisionable interval so that reports for
 multiple access lines can be bundled into the same message.
 The formal specification of the behaviors associated with each of
 these capabilities, singly and in combination, is given in Section 6.
 In addition to the multicast service processing behavior just
 sketched, the definition of each capability includes support for the
 multicast accounting and reporting services described in
 Section 3.4.3 of [RFC5851].  Because of this common content and
 because of other protocol overlaps between the different
 capabilities, the protocol descriptions for the multicast extensions
 specified in this document are merged into a single non-redundant
 narrative.  Tables in Section 6 then indicate the specific sub-
 sections of the protocol description that have to be implemented to
 support each capability.
 This document updates RFC 6320 by assigning capability type 3 to the
 NAS-initiated multicast replication capability and by changing the
 starting point for IANA allocation of result codes determined by IETF
 Consensus from 0x100 to 0x64.

Le Faucheur, et al. Standards Track [Page 6] RFC 7256 ANCP Multicast Extensions July 2014

1.1. A Note on Scope

 The requirements in [RFC5851] were formulated with the IPTV
 application in mind.  Two basic assumptions underlie the use case
 descriptions:
 o  that the Home Gateway operates in bridged mode, and
 o  that multicast signaling uses IGMP ([RFC2236] [RFC3376]) or
    Multicast Listener Discovery (MLD) [RFC3810] rather than PIM
    [RFC4601].
 Without the first assumption the AN may lose sight of individual
 subscriber devices making requests for multicast service.  This has a
 very minor effect on the capabilities described below but prevents
 the application of per-device policies at the NAS.  Changing the
 second assumption would require that, in applications where the AN is
 responsible for snooping IGMP and MLD, it now also monitors for PIM
 signaling.  The capabilities described in the present document do not
 depend explicitly on what type of multicast signaling is used, but
 the multiple phases of PIM setup could add complexity to their
 implementation.

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].
 This document uses the terms "connection admission control" ("CAC" or
 simply "admission control") and "conditional access" as they are used
 in [RFC5851].
 The expression "delegated bandwidth" is used as a shorter way of
 saying: "the total amount of video bandwidth delegated to the AN for
 multicast admission control".

3. Multicast Use Cases

 Quoting from [RFC5851]:
    ... the Access Node, aggregation node(s), and the NAS must all be
    involved in the multicast replication process.  This prevents
    several copies of the same stream from being 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).

Le Faucheur, et al. Standards Track [Page 7] RFC 7256 ANCP Multicast Extensions July 2014

    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.
 [RFC5851] describes the use cases for ANCP associated with such
 multicast operations and identifies the associated ANCP requirements.
 This section describes a subset of these use cases as background to
 facilitate reading of this document, but the reader is referred to
 [RFC5851] for a more exhaustive description of the ANCP multicast use
 cases.  Detailed example message flows can also be found in
 Appendix A.
 In the diagrams below, participation of the Home Gateway is optional,
 depending on whether it is operating in bridged or routed mode.  Note
 that devices behind the Home Gateway may require the Home Gateway to
 operate in routed mode to ensure that they can obtain access to non-
 IPTV multicast services.

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
 performs conditional access and admission control when processing
 multicast join requests and only creates replication state in the AN
 if admission succeeds.

Le Faucheur, et al. Standards Track [Page 8] RFC 7256 ANCP Multicast Extensions July 2014

3.1.2. Message Flow

 With the NAS-initiated use case, a Multicast Replication Control
 message is sent by the NAS to the AN with a directive to either join
 or leave one (or more) multicast flow(s).  In the example message
 flow, the AN uses a Generic Response message to convey the outcome of
 the directive.  Figure 1 illustrates such an ANCP message exchange as
 well as the associated AN behavior.
 +----------+    +-------+     +-----+        ANCP          +-----+
 |Subscriber|    | Home  |     | AN  |<-------------------->| NAS |
 +----------+    |Gateway|     +-----+                      +-----+
       |         +-------+         |                           |
       |            |              |                          (*)
       |            |              | Multicast-Replication-Ctl |
       |            |              |   (Target, add, Flow 1)   |
       |            |              |<--------------------------|
       |       Mcast Flow 1        |                           |
       |<===========+==============+                           |
       |            |              |     Generic Response      |
       |            |              |-------------------------->|
       |            |              |                           |
       |            |              |                           |
       ~            ~              ~                           ~
       |            |              |                           |
       |            |              | Multicast-Replication-Ctl |
       |            |              |   (Target,delete, Flow 1) |
       |            |              |<--------------------------|
       |            |              |                           |
       |  <Stop Replication of     X                           |
       |            Mcast Flow 1>  |     Generic Response      |
       |            |              |-------------------------->|
      (*) The NAS may optionally seek direction from an external
     Authorization/Policy Server before admitting the flow.
         Figure 1: NAS-Initiated Multicast Replication Control

3.2. Conditional Access and Admission Control Use Case

3.2.1. Goals

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

Le Faucheur, et al. Standards Track [Page 9] RFC 7256 ANCP Multicast Extensions July 2014

 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 request, the AN sends a Multicast
 Admission Control message to the NAS to request a conditional access
 and admission control check.  In the case of a positive outcome, the
 NAS sends a Multicast Replication Control message to the AN with a
 directive to replicate the multicast flow to the corresponding user.
 Similarly, on detection of an IGMP/MLD leave, a Multicast 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)   |  Multicast-Admission-Crl  |
       |------------+---------->|   (Target,add,Gr-Flow1)   |
       |            |           |-------------------------->|
       |            |           |                          (*)
       |            |           | Multicast-Replication-Crl |
       |            |           |   (Target,add,Gr-Flow1)   |
       |            |           |<--------------------------|
       |     Mcast Gr-Flow1     |                           |
       |<===========+===========+                           |
       |            |           |                           |
       ~            ~           ~                           ~
       |            |           |                           |
       |      Leave(Gr-Flow1)   |  Multicast-Admission-Crl  |
       |------------+---------->| (Target,delete,Gr-Flow1)  |
       |            |           |-------------------------->|
       | <Stop Replication of   X                           |
       |       Mcast Gr-Flow1>  |                           |
       |            |           |                           |
 Gr-Flow1: a multicast flow matching the grey list for that port
 (*) The NAS may optionally seek direction from an external
     Authorization/Policy Server before admitting the flow.
     Figure 2: Multicast Conditional Access and Admission Control

Le Faucheur, et al. Standards Track [Page 10] RFC 7256 ANCP Multicast Extensions July 2014

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

3.4. Committed Bandwidth Reporting Use Case

3.4.1. Goals

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

Le Faucheur, et al. Standards Track [Page 11] RFC 7256 ANCP Multicast Extensions July 2014

3.4.2. Message Flow

 The message flow associated with this use case is shown in Figure 4.
 The figure assumes that a non-zero buffering interval was previously
 provisioned on the AN.
 +-----+    +-------+       +-----+    ANCP    +-----+
 |Subs |+   | Home  |+      | AN  |<---------->| NAS |
 |1,2  ||   |GW 1,2 ||      +-----+            +-----+
 +-----+|   +-------+|         |                   |
  +|----+    +|------+         |                   |
   | |        | |              |                   |
   | |Join(Subs1, Ch1)         |                   |
   |----------+--------------->|  Start buffering  |
   | |        | Multicast flow |  timer. Create    |
   |<=========+================|  message with     |
   | |        | |              |  initial contents |
   | |        | |              |  reporting new    |
   | |        | |              |  Subs1 bandwidth. |
   | | Join(Subs2, Ch2)        |                   |
   | |----------+------------->|  Add report for   |
   | |        | Multicast flow |  new Subs2 b/w.   |
   | |<=========+==============|                   |
   | |        | |              |                   |
   | |Leave(Subs1, Ch1)        |                   |
   |----------+--------------->|  Replace report   |
   | |        | |              |  for Subs1 with   |
   | |      Stop replication   X  new value (which |
   | |        | |              |  happens to be    |
   | |        | |              |  the same as the  |
   | |        | |              |  starting value). |
   | |        | |              |                   |
   | |        | |             >|< TIMER expires    |
   | |        | |              |                   |
   | |        | |              |Committed          |
   | |        | |              |  Bandwidth Report |
   | |        | |              |------------------>|
   | |        | |              |   (for latest     |
   | |        | |              |   Subs1 and Subs2 |
   | |        | |              |   bandwidth)      |
   | |        | |              |                   |
       Figure 4: Message Flow for Committed Bandwidth Reporting

Le Faucheur, et al. Standards Track [Page 12] RFC 7256 ANCP Multicast Extensions July 2014

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.
 Unless stated otherwise, receivers MUST ignore message contents that
 are not supported by the set of capabilities negotiated between the
 NAS and the Access Node.

4.1. Provisioning Message

 Section 4.1 of [RFC6320] defines the Provisioning message that is
 sent by the NAS to the AN to provision information in the AN.
 The present document specifies that the Provisioning message MAY be
 used by the NAS to provision multicast-related information (e.g.,
 multicast service profiles).  The ANCP Provisioning message payload
 MAY contain:
 o  one or more instances of the Multicast-Service-Profile TLV.  The
    Multicast-Service-Profile TLV is defined in the present document
    in Section 5.1.  Each instance of the Multicast-Service-Profile
    TLV contains a multicast service profile name and one or more list
    actions.  A list action consists of an action (add, delete,
    replace), a list type (white, black, or grey), and list content
    (multicast source and group addresses).
 o  an instance of the White-List-CAC TLV.  The White-List-CAC TLV is
    defined in Section 5.6.  If present, this TLV indicates that the
    AN is required to do admission control before replicating white-
    listed flows.
 o  an instance of the MRepCtl-CAC TLV.  The MRepCtl-CAC TLV is
    defined in Section 5.7.  If present, this TLV indicates that the
    AN is required to do admission control before replicating flows
    specified in Multicast Replication Control messages.
 o  an instance of the Report-Buffering-Time TLV.  The Report-
    Buffering-Time TLV is defined in Section 5.13.  If present, this
    TLV indicates Committed Bandwidth Report messages should be
    buffered for the amount of time given by the TLV before being
    transmitted to the NAS.
 See Section 6 for information on which multicast capabilities require
 support of these TLVs in the Provisioning message.

Le Faucheur, et al. Standards Track [Page 13] RFC 7256 ANCP Multicast Extensions July 2014

4.1.1. Sender Behavior

 When directed by the Policy Server or by management action, the NAS
 sends the Provisioning message to initially provision or to update
 the white, black, and/or grey multicast channel lists associated with
 a set of named multicast service profiles or to direct the AN to
 perform admission control for specific classes of flows.
 To provision or update a multicast service profile, the NAS MUST
 include within the message one or more instances of the Multicast-
 Service-Profile TLV specifying the content to be provisioned or
 updated.  The NAS MUST NOT include any list type (white, black, or
 grey) that is not supported by the set of multicast capabilities
 negotiated between the NAS and the AN.  The NAS MUST NOT use the
 Provisioning message to send instances of the Multicast-Service-
 Profile TLV to the AN unless the Multicast-Service-Profile TLV is
 supported by the set of multicast capabilities negotiated between the
 NAS and the AN.
 To require admission control to be performed at the AN on white-
 listed flows, the NAS MUST include a copy of the White-List-CAC TLV
 in the Provisioning message.  The White-List-CAC TLV MUST NOT be
 provided unless the negotiated set of capabilities includes
 conditional access and admission control with white and black lists.
 To require admission control to be performed at the AN on grey-listed
 flows or on NAS-initiated flows, the NAS MUST include a copy of the
 MRepCtl-CAC TLV in the Provisioning message.  The MRepCtl-CAC TLV
 MUST NOT be provided unless the negotiated set of capabilities
 includes NAS-initiated multicast replication or conditional access
 and admission control with grey lists.
 To require buffering of Committed Bandwidth Report messages so that
 reports for multiple access lines can be included in the same
 message, the NAS MUST include a copy of the Report-Buffering-Time TLV
 containing a non-zero time value in a Provisioning message sent to
 the AN.  The Report-Buffering-Time TLV MUST NOT be provided unless
 the negotiated set of capabilities includes committed bandwidth
 reporting.

4.1.2. Receiver Behavior

 The receiving AN provisions/updates the white, black, and/or grey
 lists associated with the multicast service profile names contained
 in the Multicast-Service-Profile TLV instances within the message
 according to the contents of the associated List-Action TLVs.  The AN
 MUST process List-Action TLVs in the order in which they appear
 within the message.  In keeping with the general rule stated in

Le Faucheur, et al. Standards Track [Page 14] RFC 7256 ANCP Multicast Extensions July 2014

 Section 4, the AN MUST ignore instances of the List-Action TLV
 referring to any list type (white, black, or grey) that is not
 supported by the set of multicast capabilities negotiated between the
 NAS and the AN.
 When a new multicast service profile is identified by a Multicast-
 Service-Profile TLV, the initial state of all lists associated with
 that profile according to the negotiated set of multicast
 capabilities is empty until changed by the contents of Multicast-
 Service-Profile TLVs.
 The receipt of a Provisioning message containing updates to an
 existing multicast service profile subsequent to startup will cause
 the AN to review the status of active flows on all ports to which
 that profile has been assigned.  For further details, see Section 6.
 If the White-List-CAC and/or MRepCtl-CAC TLV is present in the
 Provisioning message and the respective associated capabilities have
 been negotiated, the AN prepares (or continues) to do admission
 control on the indicated class(es) of flow.  If one or both of these
 TLVs was present in an earlier Provisioning message but is absent in
 the latest message received, the AN ceases to do admission control on
 the indicated class(es) of flow.
 The buffering time specified in an instance of the Report-Buffering-
 Time TLV will not be applied until the current accumulation process
 of Committed Bandwidth Report messages finishes.
 As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning
 message if it processed it successfully.  If an error prevents
 successful processing of the message content, the AN MUST return a
 Generic Response message as defined in [RFC6320], containing a
 Status-Info TLV with the appropriate content describing the error.
 For this purpose, the presence of a list type in a Multicast-Service-
 Profile TLV, which was ignored because it was not supported by the
 negotiated set of capabilities, is not considered to be an error.

4.2. Port Management Message

 As specified in [RFC6320], the NAS may send DSL line configuration
 information to the AN (ANCP-based DSL line configuration use case)
 using ANCP Port Management messages.  See Section 7.3 of [RFC6320]
 for the format of the Port Management message in that usage.
 This document specifies that the Port Management message MAY be used
 to convey either or both of the following TLVs:

Le Faucheur, et al. Standards Track [Page 15] RFC 7256 ANCP Multicast Extensions July 2014

 o  Multicast-Service-Profile-Name TLV (defined in Section 5.2).  This
    TLV associates a Multicast Service Profile with the access line
    specified by the extension block and, in the case of white and
    black lists, delegates conditional access to the AN for the
    specified access line and channels.
 o  Bandwidth-Allocation TLV (defined in Section 5.5).  This TLV
    specifies the total multicast bandwidth available to the AN for
    admission control at the access line.
 When the Port Management message is used for this purpose:
 o  the Function field in the Port Management message MUST be set to
    8, "Configure Connection Service Data".
 o  the message MUST include TLV(s) to identify the access line
    concerned.  If the access line is a DSL loop, the line-identifying
    TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320].  For
    non-DSL access lines, the appropriate alternative line-identifying
    TLV(s) MUST be present.  Line configuration data other than the
    two TLVs listed in the previous paragraph MAY be present.

4.2.1. Sender Behavior

 The NAS sends the Port Management message at startup time to
 initialize parameters associated with the access line specified in
 the message and with the multicast capabilities negotiated between
 the NAS and the AN.  The NAS MAY send additional Port Management
 messages subsequent to startup, to update or, in the case of the
 Bandwidth-Allocation TLV, reset these parameters.  If the NAS
 includes a Multicast-Service-Profile-Name TLV in the Port Management
 message, the name MUST match a profile name provided in a Multicast-
 Service-Profile TLV in a prior Provisioning message.  The NAS MUST
 NOT include a TLV unless it is supported by the set of multicast
 capabilities negotiated between the NAS and the AN.  See Section 6
 for further information.

4.2.2. Receiver Behavior

 If the Port Management message contains a Multicast-Service-Profile-
 Name TLV, the AN associates the named profile with the specified
 access line.  This association replaces any previous association.
 That is, a given access line is associated with at most one multicast
 service profile.  The replacement of one multicast service profile
 with another will cause the AN to review the status of all active
 flows on the target port.  For further details see Section 6.

Le Faucheur, et al. Standards Track [Page 16] RFC 7256 ANCP Multicast Extensions July 2014

 If the Port Management message contains a Bandwidth-Allocation TLV,
 the AN adopts this as the current value of its total multicast
 bandwidth limit for the target port.  If the AN has already committed
 multicast bandwidth exceeding the amount given in the Bandwidth-
 Allocation TLV, the AN SHOULD NOT discontinue any multicast streams
 in order to bring bandwidth down to within the new limit, unless such
 action is required by local policy.  However, the AN MUST NOT admit
 new multicast streams that are subject to admission control until it
 can do so within the limit specified by the Bandwidth-Allocation TLV.
 If the Port Management request cannot be processed due to error and
 the Result field of the request is Nack (0x1) or AckAll (0x2), the AN
 SHOULD add a Status-Info TLV to the Extension Value field in its
 reply if this will provide useful information beyond what is provided
 by the Result Code value returned in the response header.  In
 particular, if the name within the Multicast-Service-Profile-Name TLV
 does not match a profile name given in a prior Provisioning message,
 the AN SHOULD return a reply where the Result Code field in the
 header indicates 0x55, "Invalid TLV contents", the Error Message
 field in the Status-Info TLV contains the text "Multicast profile
 name not provisioned", and the Status-Info TLV contains a copy of the
 Multicast-Service-Profile-Name TLV.

4.3. Multicast Replication Control Message

 This section defines a new message called the Multicast Replication
 Control message.  The Multicast Replication Control message is sent
 by the NAS to the AN with one or more directives to add (join) or
 delete (leave) a multicast flow on a target object identified in the
 content of the message.
 The Message Type for the Multicast Replication Control message is
 144.
 The ANCP Multicast Replication Control message payload contains the
 following TLVs:
 o  Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320].
    It MUST appear once and only once.  It is encoded as specified in
    [RFC6320] or extensions and identifies the AN port subject to the
    request for admission or release.
 o  Command TLV: The Command TLV is defined in Section 4.4 of
    [RFC6320].  It MUST be present.  It MAY appear multiple times.

Le Faucheur, et al. Standards Track [Page 17] RFC 7256 ANCP Multicast Extensions July 2014

 As [RFC6320] indicates, the contents of the Command Info field within
 the Command TLV are specific to the message in which the TLV occurs.
 For the Multicast Replication Control message, these contents consist
 of:
 o  a Command Code field;
 o  an Accounting field; and
 o  an instance of the Multicast-Flow TLV.
 Figure 5 illustrates the complete Command TLV with the contents
 specific to the Multicast Replication Control message.
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | TLV Type = Command     0x0011 |       Command TLV Length      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Command Code |  Accounting     |         Reserved              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Multicast-Flow TLV                        |
  |                           ...                                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Other embedded TLV Type     |   Other embedded TLV Length   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                   Other embedded TLV data                     ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Figure 5: Contents of the Command TLV in the Multicast Replication
                            Control Message

Le Faucheur, et al. Standards Track [Page 18] RFC 7256 ANCP Multicast Extensions July 2014

 o  Command Code: One of the following command directives:
       1 "Add"
       2 "Delete"
       3 "Delete All"
       4 "Admission Control Reject"
       5 "Conditional Access Reject"
       6 "Admission Control and Conditional Access Reject"
    Directives 4 through 6 are used as described in Section 4.4.2.
 o  Accounting: Meaningful only when the Command Code is "Add" (1).
    In that case, 0 indicates flow accounting is disabled, and 1
    indicates that octet accounting for the flow is requested.  The
    sender MUST set the Accounting field to 0, and the receiver MUST
    ignore the Accounting field for other Command Code values.
 o  Reserved: Reserved for future use.  MUST be set to zeroes by the
    sender and ignored by the receiver.
 o  Multicast-Flow TLV: An instance of the Multicast-Flow TLV
    (Section 5.12) specifying the flow to be added or deleted.  The
    Multicast-Flow TLV is omitted if the Command Code has value
    "Delete All" (3).
 o  Other embedded TLV data: No other embedded TLVs are currently
    specified within the Multicast Replication Control message and
    Command TLV.  However, see the description of the Multicast
    Admission Control message (Section 4.4).  Unrecognized embedded
    TLVs SHOULD be silently discarded.
 The figure below is an example of a Multicast Replication Control
 message that would result in a swap from multicast Source-Specific
 Multicast (SSM) flows 2001:DB8::1, FF34::2 to 2001:DB8::2, FF34::3 on
 the target identified by the Access Loop Circuit ID:

Le Faucheur, et al. Standards Track [Page 19] RFC 7256 ANCP Multicast Extensions July 2014

                          1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type (0x880C)          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |  MsgType=144  | Res=2 |   Result Code = 0     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier = 18        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target   0x1000 |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Command  0x0011 |     Command TLV Length = 44   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cmd Code = 2  |   Acctg = 0   |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = Multicast-Flow  0x0019 |        TLV Length = 36        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flow Type = 2 |  AddrFam = 2  |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Multicast Group Address                     ~
   |                          = FF34::2                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Source Address                        ~
   |                          = 2001:DB8::1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Command  0x0011 |     Command-TLV Length = 44   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cmd Code = 1  |   Acctg = 1   |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = Multicast-Flow  0x0019 |        TLV Length = 36        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flow Type = 2 |  AddrFam = 2  |      Reserved = 0x0000        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Multicast Group Address                     ~
   |                          = FF34::3                            |

Le Faucheur, et al. Standards Track [Page 20] RFC 7256 ANCP Multicast Extensions July 2014

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Source Address                        ~
   |                          = 2001:DB8::2                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Figure 6: Example Change of Source Flow Using Multicast Replication
                            Control Message

4.3.1. Sender Behavior

 The NAS MAY issue a Multicast Replication Control message to the AN
 to convey one or more directives to add (join) or delete (leave) one
 or more multicast flows.
 The NAS MAY send this message on its own initiative to support the
 NAS-initiated multicast control use case presented in [RFC5851] and
 summarized in Section 3.1.  In that case, the NAS MUST set the Result
 field to AckAll (0x2) or Nack (0x1) according to its requirements.
 The NAS MAY also send this message in response to a Multicast
 Admission Control message (defined in Section 4.4) received from the
 AN to support the conditional access and admission control use case
 presented in [RFC5851] and summarized in Section 3.2.  In that case,
 the NAS MUST set the Result field to Nack (0x1).
 In either case, the sender MUST populate the Result Code field with
 the value 0 and the ANCP Transaction Identifier field with a unique
 value, as described in Section 3.6.1.6 of [RFC6320].
 Each Multicast Replication Control message MUST contain one or more
 commands, each encapsulated in its own Command TLV.  The sender MUST
 use a separate Command TLV for each distinct multicast flow.
 When the order of processing of two commands does not matter, the
 commands MUST be transmitted in separate Multicast Replication
 Control messages.

4.3.2. Receiver Behavior

 When successive commands (in the same or different messages) relate
 to the same target and multicast flow, the state of each feature
 controlled or affected by attributes received in the Multicast
 Replication Control message SHALL be as set by the last command or
 message referring to that target and flow and containing the
 controlling attribute.  As an example, successive Multicast
 Replication Control messages containing add commands for a given port
 and flow but differing only in the Accounting field update the state

Le Faucheur, et al. Standards Track [Page 21] RFC 7256 ANCP Multicast Extensions July 2014

 of the accounting feature to what is set in the final command
 received, but all other features are unaffected by the second
 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 1 for the first command.
 If a Command TLV adds one or more flows and the AN is performing
 admission control for Multicast Replication Control messages, then
 the AN MUST perform admission control before replicating the flows.
 If the admission control check fails, the AN MUST treat the failure
 as an error as described below.  The appropriate Result Code value
 for the response is 0x13 "Out of resources".
 If the AN processes the complete Multicast Replication Control
 message successfully and the Result field of the Multicast
 Replication Control message was set to AckAll (0x2), the AN MUST
 respond with a Generic Response message where the Result field is set
 to Success (0x3), the Result Code field is set to 0, and the
 Transaction Identifier field is copied from the Multicast Replication
 Control message.  The body of the response MAY be empty or MAY be
 copied from the Multicast Replication Control message.
 If the AN processes the complete Multicast Replication Control
 message successfully and the Result field of the Multicast
 Replication Control message was set to Nack (0x1), the AN MUST NOT
 respond to the message.
 The processing/execution of multiple commands contained in a single
 Multicast Replication Control message MUST be interrupted at the
 first error encountered and the remaining commands in the Multicast
 Replication Control message discarded.  Similarly, if a given command
 specifies multiple Single-Source Multicast (SSM) flows and an error
 occurs, processing MUST be interrupted at that point, and the
 remainder of the Command TLV discarded.
 If the AN detects an error in a received Multicast Replication
 Control message and the Result field in that message was set to Nack
 (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message
 providing error information to the NAS.  This specification
 identifies the following new Result Code values beyond those
 specified in [RFC6320], which MAY be used in a Generic Response sent
 in reply to a Multicast Replication Control message:

Le Faucheur, et al. Standards Track [Page 22] RFC 7256 ANCP Multicast Extensions July 2014

 0x64  Command error.
       Where detected: ANCP agent at the AN.
       Further description: an invalid command code has been received.
       Required additional information in the message: see below.
       Target: ANCP agent at the NAS.
       Action RECOMMENDED for the receiving ANCP agent: Report the
       error to the control application with an indication of the
       erroneous information associated with the invalid TLV(s).
 0x65  Invalid flow address.
       Where detected: ANCP agent at the AN.
       Further description: either inconsistent flow address
       information has been provided or the address family is
       unsupported.
       Required additional information in the message: see below.
       Target: ANCP agent at the NAS.
       Action RECOMMENDED for the receiving ANCP agent: Report the
       error to the control application with an indication of the
       erroneous information associated with the invalid TLV(s).
 0x66  Multicast flow does not exist.
       Where detected: control application at the AN.
       Further description: the NAS has attempted to delete a flow
       that is not active on the given access line.
       Required additional information in the message: see below.
       Target: control application at the NAS.
       Action RECOMMENDED for the receiving ANCP agent: report the
       error to the control application with an indication of the
       erroneous information associated with the invalid TLV(s).

Le Faucheur, et al. Standards Track [Page 23] RFC 7256 ANCP Multicast Extensions July 2014

 A Generic Response message responding to the Multicast Replication
 Control message and containing one of the above Result Code values
 MUST include a Status-Info TLV, which includes one or two embedded
 TLVs as follows:
 o  a Sequence-Number TLV as described in Section 5.4, giving the
    sequence number of the failed command, MUST be included; and
 o  the failed Command TLV itself SHOULD be included.
    Note: The Error Message field of the Status-Info TLV MAY be used
    to report more details than implied by the Result Code value in
    the message header.  For example, the Result Code value could be
    0x65, and the Error Message field could contain the text: "Source
    address present for ASM flow".

4.4. Multicast Admission Control Message

 This section defines a new message called the Multicast Admission
 Control message.  The Multicast Admission Control message is sent by
 the AN to the NAS to request admission of a multicast flow, or to
 notify of the removal of a multicast flow, for a given target.
 The Message Type for the Multicast Admission Control message is 145.
 The ANCP Multicast Admission Control message payload contains two
 TLVs:
 o  Target TLV: The Target TLV is defined in [RFC6320].  It MUST
    appear once and only once in the Multicast Admission Control
    message.  It is encoded as specified in [RFC6320] or extensions
    and identifies the AN port subject to the request for admission or
    release.
 o  Command TLV: The Command TLV is defined in [RFC6320].  It MUST be
    present.  If it appears more than once, only the first instance is
    considered meaningful in the present version of this
    specification, and the other instances are ignored.
    Note: In the future, the specification of the Multicast Admission
    Control message may be extended to allow transport of more than a
    single directive (e.g., to carry both a leave from one group and a
    join to another group for the same target).  It is expected that
    this would support a similar notion of strict sequenced processing
    as currently defined for handling multiple directives in the
    Multicast Replication Control message whereby all directives
    following the first directive that cannot be executed are not

Le Faucheur, et al. Standards Track [Page 24] RFC 7256 ANCP Multicast Extensions July 2014

    executed either.  When the strict sequenced processing of the
    directives is not required, the directives are distributed across
    separate messages.
 The Command TLV has the same contents as were described above for the
 Multicast Replication Control message, with the following additions:
 o  A Request-Source-IP TLV MAY be appended to the Command TLV as an
    additional embedded TLV.
 o  Similarly, a Request-Source-MAC TLV MAY be appended to the Command
    TLV as an additional embedded TLV.
 o  Finally and preferably, a Request-Source-Device-Id TLV MAY be
    appended to the Command TLV as an additional embedded TLV.
 Note that the Command TLV length includes the length of any embedded
 TLVs, including the embedded TLV headers.

4.4.1. Sender Behavior

 The AN sending the Multicast Admission Control message MUST set the
 Result field to Ignore (0x0).
 The AN MUST populate the ANCP Transaction Identifier field with a
 unique value, as described in Section 3.6.1.6 of [RFC6320].
 The AN MUST encode the Command TLV as specified in Section 4.3 with
 the following additional rules:
 o  The Accounting field MUST be set to 0.
 o  The Command Code field MUST be set to "Add" (1) when the message
    conveys a join request, to "Delete" (2) when the message conveys a
    leave, and to "Delete All" (3) when the message conveys a leave of
    all channels (on the target).
 o  The Multicast-Flow TLV within the Command TLV identifies the
    multicast flow subject to the request for admission or release.
    When the Command Code is 3, the Multicast-Flow TLV is omitted.
 o  The Request-Source-IP embedded TLV MAY be included by the AN to
    convey the IP address of the sender of the join/leave message
    (e.g., IGMP/MLD join/leave) that triggered the AN to include the
    corresponding Command TLV in the Multicast Admission Control
    message.  If it appears more than once, only the first instance is
    considered meaningful, and the other instances are ignored.

Le Faucheur, et al. Standards Track [Page 25] RFC 7256 ANCP Multicast Extensions July 2014

 o  The Request-Source-MAC embedded TLV MAY be included by the AN to
    convey the Media Access Control (MAC) address of the sender of the
    join/leave message (e.g., IGMP/MLD join/leave) that triggered the
    AN to include the corresponding Command TLV in the Multicast
    Admission Control message.  If it appears more than once, only the
    first instance is considered meaningful, and the other instances
    are ignored.
 o  As a third alternative, the Request-Source-Device-Id embedded TLV
    MAY be included by the AN to convey a local identifier of the
    sender of the join/leave message (e.g., IGMP/MLD join/leave) that
    triggered the AN to include the corresponding Command TLV in the
    Multicast Admission Control message.  If it appears more than
    once, only the first instance is considered meaningful, and the
    other instances are ignored.
 The inclusion of Request-Source-IP or Request-Source-MAC in the
 Multicast Admission Control message is typically done to allow the
 application of policies applicable to specific devices within the
 customer's network.  However, transmission of either of these fields
 beyond the AN introduces potential privacy issues.  Instead of
 transmitting either of these identifiers, it is RECOMMENDED that the
 AN map the required identifier to a local value known to the AN and
 Authentication, Authorization, and Accounting (AAA) but not to the
 NAS, as discussed in Section 8.  The local identifier is transmitted
 using the Request-Source-Device-Id TLV.

4.4.2. Receiver Behavior

 On receipt of a Multicast Admission Control message:
 o  The NAS MUST ignore the Result field.
 o  If the directive in the Multicast Admission Control message is
    "Delete" (2) or "Delete All" (3) and is processed correctly by the
    NAS, the NAS MUST NOT generate any ANCP message in response to the
    Multicast Admission Control message.
 o  If the directive in the Multicast Admission Control message is
    "Add" (1) and is accepted by the NAS, the NAS MUST generate a
    Multicast Replication Control message in response to the Multicast
    Admission Control message.  The Multicast Replication Control
    message:
  • MUST contain a Result set to Nack (0x1);
  • MUST contain a Transaction ID with a unique value, as described

in Section 3.6.1.6 of [RFC6320]; and

Le Faucheur, et al. Standards Track [Page 26] RFC 7256 ANCP Multicast Extensions July 2014

  • MUST contain the directive as accepted by the NAS. The NAS MAY

modify the Accounting field if flow accounting is required.

 o  If the directive in the Multicast Admission Control message is
    "Add" (1) and is processed correctly but not accepted by the NAS
    (i.e., it does not pass the conditional access and admission
    control check), the NAS MAY generate a Multicast Replication
    Control message in response to the Multicast Admission Control
    message.  This optional message can be used by the AN to maintain
    statistics about admission control rejections.  When used in this
    situation, the Multicast Replication Control message:
  • MUST contain a Result set to 0x0;
  • MUST contain a Transaction ID with a unique value, as described

in Section 3.6.1.6 of [RFC6320]; and

  • MUST contain the directive rejected by the NAS (i.e., Target

TLV and Command TLV) but with a Command Code set to "Admission

       Control Reject" (4), "Conditional Access Reject" (5), or
       "Admission Control and Conditional Access Reject" (6) as
       applicable.
 o  If the Multicast Admission Control message cannot be processed
    correctly by the NAS (e.g., the message is malformed, the
    multicast flow does not exist, etc.), the NAS MUST generate a
    Generic Response message (defined in Section 4.2 of [RFC6320])
    with appropriate content indicating the reason for the failure.

4.5. Bandwidth Reallocation Request Message

 The Bandwidth Reallocation Request message is used when the bandwidth
 delegation capability is included in the negotiated set.  It MAY be
 sent either by the NAS or by the AN to request an adjustment in the
 amount of delegated bandwidth.  It will be sent by the NAS typically
 to reduce the multicast bandwidth allocated to the AN in order for
 the NAS to satisfy a request to add one or more flows.  Conversely,
 the AN will send a Bandwidth Reallocation Request message to obtain
 additional bandwidth to satisfy a request to add a multicast channel.
 In each case, the requestor has a minimum requirement for additional
 bandwidth and MAY ask for additional bandwidth beyond this amount
 (e.g., to handle anticipated future requests).
 The Bandwidth Reallocation Request message contains two TLVs:
 o  the Target TLV (Section 4.3 of [RFC6320] or an extension),
    specifying a single access line; and

Le Faucheur, et al. Standards Track [Page 27] RFC 7256 ANCP Multicast Extensions July 2014

 o  the Bandwidth-Request TLV (Section 5.8), specifying the required
    and preferred amounts of delegated bandwidth.
 The Message Type for the Bandwidth Reallocation Request message is
 146.

4.5.1. Sender Behavior

 The Result field in the header of the Bandwidth Reallocation Request
 message is not used, and the sender MUST set it to Ignore (0x0).
 The bandwidth values in the Bandwidth-Request TLV are expressed in
 terms of total multicast bandwidth allocated to the AN.
    Note: The choice of "total bandwidth" rather than "incremental
    bandwidth" was made so that it would be easier for the AN and NAS
    to keep their respective views of the current amount of delegated
    bandwidth synchronized.
 Because the values are totals rather than desired increments/
 decrements, the relationship between the required amount and the
 preferred amount will differ depending on whether the Bandwidth
 Reallocation Request message is issued by the NAS or the AN.
 o  If the NAS is making the request, the preferred amount MUST be
    less than or equal to the required amount.  The required amount
    MUST be less than the current amount of delegated bandwidth.
 o  If the AN is making the request, the preferred amount MUST be
    greater than or equal to the required amount.  The required amount
    MUST be greater than the current amount of delegated bandwidth.

4.5.2. Receiver Behavior

 When the peer receives a valid Bandwidth Reallocation Request
 message, it SHOULD determine whether it can satisfy the request from
 its existing allocation of unused video bandwidth.  If it decides
 that it can reallocate bandwidth to the peer, it MAY choose to return
 any amount between the required and the preferred amounts indicated
 in the Bandwidth Reallocation Request message.
 The peer MUST return a Bandwidth Transfer message (Section 4.6)
 indicating its decision.  If the request is met, the Result field of
 the Bandwidth Transfer message MUST be set to Success (0x3), the
 Result Code field MUST be set to 0x000, and the Bandwidth-Allocation
 TLV (Section 5.5) MUST contain the new value of total multicast
 bandwidth.  This new value MUST lie between the required and
 preferred values, inclusive, from the request message.  If the

Le Faucheur, et al. Standards Track [Page 28] RFC 7256 ANCP Multicast Extensions July 2014

 request is not met, the Result field of the Bandwidth Transfer
 message MUST be set to Failure (0x4), the Result Code field MUST be
 set to 0, and the Bandwidth-Allocation TLV MUST contain the value of
 the currently allocated amount of delegated bandwidth as the
 responder views it.
 The following cases indicate that the sender holds a different view
 of the amount of delegated bandwidth from the receiver:
 o  The NAS receives a request where the required amount is less than
    its view of the current amount of delegated bandwidth.
 o  The AN receives a request where the required amount is greater
    than its view of the current amount of delegated bandwidth.
 If one of these cases occurs, the receiver, with one exception, MUST
 send a Bandwidth Transfer message indicating Success.
 o  If the NAS received the request, the allocated amount in the NAS's
    response MUST be at least equal to the NAS's view of the current
    amount of delegated bandwidth.
 o  If the AN received the request, the allocated amount in the AN's
    response MUST be no greater than the AN's view of the current
    amount of delegated bandwidth.
 The exception is when the NAS receives a request while it has a
 request of its own outstanding.  Handling of that case is described
 below.
    Note: While the cases just described are an error condition, the
    success response achieves a graceful recovery.
 To avoid deadlock due to race conditions, the following rules MUST be
 applied:
 a.  If the NAS receives a Bandwidth Reallocation Request message
     while it has a Bandwidth Reallocation Request message of its own
     outstanding for the same access line, the NAS MUST provide an
     immediate failure response to the request from the AN, with a
     Result Code value set to 0x68 "Inconsistent views of delegated
     bandwidth amount" or 0x69 "Bandwidth request conflict" as
     applicable.  (See below for more information).
 b.  If the AN receives a Bandwidth Reallocation Request message while
     it has a Bandwidth Reallocation Request message of its own
     outstanding for the same access line, the AN MUST release any
     bandwidth it has already committed to an outstanding join request

Le Faucheur, et al. Standards Track [Page 29] RFC 7256 ANCP Multicast Extensions July 2014

     while it is awaiting a response from the NAS.  It MUST decide
     upon and send its response to the NAS taking the released
     bandwidth into account.
 If the receiver is unable to process the Bandwidth Reallocation
 Request message due to an error, then the receiver MUST return a
 Bandwidth Transfer message where:
 o  the Result field is set to Failure (0x4),
 o  the Result Code field is set appropriately to indicate the type of
    error that was detected,
 o  the Bandwidth-Allocation TLV contains the value of the current
    amount of delegated bandwidth as the responder views it, and
 o  a Status-Info TLV MAY follow the Bandwidth-Allocation TLV giving
    further information about the error.
 This specification provides three new Result Code values applicable
 specifically to the contents of the Bandwidth-Request TLV.  These
 Result Code values by their nature MUST only be used when the error
 is being reported in a Bandwidth Transfer message rather than a
 Generic Response message.
 0x67  Invalid preferred bandwidth amount.
       Where detected: control application at the receiver of the
       Bandwidth Reallocation Request message.
       Further description: the preferred and required amounts of
       bandwidth in the TLV do not have the numerical relationship
       described above.
       Required additional information in the message: as described
       above.
       Target: control application at the sender of the Bandwidth
       Reallocation Request message.
       Action RECOMMENDED for the receiving ANCP agent: report the
       error to the control application with the returned value of the
       Bandwidth-Allocation TLV.  See also Section 4.6.2.2.

Le Faucheur, et al. Standards Track [Page 30] RFC 7256 ANCP Multicast Extensions July 2014

 0x68  Inconsistent views of delegated bandwidth amount.
       Where detected: control application at the NAS.
       Further description: the NAS has an outstanding Bandwidth
       Reallocation Request, so it is rejecting a similar request from
       the AN.  In the AN request, the required amount was less than
       the NAS's view of the current amount of delegated bandwidth.
       Required additional information in the message: as described
       above.
       Target: control application at the AN.
       Action RECOMMENDED for the receiving ANCP agent: report the
       error to the AN control application with the returned value of
       the Bandwidth-Allocation TLV.  See also Section 4.6.2.2.
 0x69  Bandwidth request conflict.
       Where detected: control application at the NAS.
       Further description: the NAS has an outstanding Bandwidth
       Reallocation Request, so it is rejecting a similar, valid
       request from the AN.
       Required additional information in the message: as described
       above.
       Target: control application at the AN.
       Action RECOMMENDED for the receiving ANCP agent: report the
       error to the AN control application with the returned value of
       the Bandwidth-Allocation TLV.  See also Section 4.6.2.2.

4.6. Bandwidth Transfer Message

 The Bandwidth Transfer message is used to transfer video bandwidth
 from the sender to the peer for a specific access line.  This message
 MAY be sent either from the AN or from the NAS.  As described in the
 previous section, it is the required response to a valid Bandwidth
 Reallocation Request message.
 The Bandwidth Transfer message MAY also be used to transfer bandwidth
 autonomously from one peer to another.  One example of this usage is
 to release bandwidth borrowed earlier by means of the Bandwidth

Le Faucheur, et al. Standards Track [Page 31] RFC 7256 ANCP Multicast Extensions July 2014

 Reallocation Request message.  When the message is used in this way,
 the Result field in the Bandwidth Transfer message MUST be set to
 Ignore (0x0).
    Note: This allows the receiver to distinguish between an
    autonomous transfer and a response to a previous Bandwidth
    Reallocation Request message, for purposes of validation.
 The Message Type for the Bandwidth Transfer message is 147.  The
 Bandwidth Transfer message contains the following TLVs:
 o  the Target TLV, designating the access line concerned;
 o  an instance of the Bandwidth-Allocation TLV (Section 5.5).  The
    bandwidth value in the Bandwidth-Allocation TLV is the new amount
    of delegated bandwidth allocated to the target.

4.6.1. Sender Behavior

 When sending a Bandwidth Transfer message where the Result value is
 Ignore (0x0) or Success (0x3), the following relationships MUST hold:
 o  If the message is sent by the NAS, the bandwidth value in the
    Bandwidth-Allocation TLV MUST be greater than or equal to the
    sender's view of the current amount of delegated bandwidth for the
    access line concerned.
 o  If the message is sent by the AN, the bandwidth value in the
    Bandwidth-Allocation TLV MUST be less than or equal to the
    sender's view of the current amount of delegated bandwidth for the
    access line concerned.
 Further sender behavior is specified above, in Section 4.5.2.

4.6.2. Receiver Behavior

4.6.2.1. Behavior of the NAS

 If the amount of delegated bandwidth provided in the Bandwidth-
 Allocation TLV is not greater than the NAS's view of the current
 amount of delegated bandwidth, the NAS MUST update its view of the
 current amount of delegated bandwidth to the amount indicated in the
 Bandwidth Transfer message.  This is required regardless of whether
 the Result field of that message indicates Success or Failure.
 If the amount of delegated bandwidth provided in the Bandwidth-
 Allocation TLV is greater than the NAS's view of the current amount
 of delegated bandwidth, the NAS MAY accept the given value as its new

Le Faucheur, et al. Standards Track [Page 32] RFC 7256 ANCP Multicast Extensions July 2014

 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 that contains a Bandwidth-Allocation TLV with a
 value equal to the amount of delegated bandwidth the NAS wishes to
 enforce.

4.6.2.2. Behavior of the AN

 If the amount of delegated bandwidth provided in the Bandwidth-
 Allocation TLV of the Bandwidth Transfer message differs from the
 AN's view of the current amount of delegated bandwidth, the AN MUST
 update its view of the current amount of delegated bandwidth to the
 amount indicated in the Bandwidth Transfer message.  This is required
 with the exception of a Bandwidth Transfer message with a Result
 field equal to Failure (0x4) and a Result Code field equal to 0x68
 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth
 request conflict".  If Result Code value 0x68 is received, the AN
 MUST issue a Delegated Bandwidth Query Request message to determine
 the NAS's current view of the amount of delegated bandwidth.  The AN
 MUST update its own view based on the value returned in the Delegated
 Bandwidth Query Response message.  If Result Code value 0x69 is
 received, the AN SHOULD carry out this procedure unless it can
 account for the discrepancy as a result of a transfer of bandwidth to
 the NAS that was carried out just before the incoming Bandwidth
 Transfer message was processed.
    Note: The two Result Code values indicate a race condition where
    the AN may have just completed a transfer of bandwidth to the NAS.
    As a result, the value given in the Bandwidth Transfer message may
    be outdated, and the AN needs to query the NAS to find its latest
    view.  The procedure assumes that ordering is preserved between
    the Bandwidth Transfer message sent by the AN in response to the
    NAS's request and the subsequent Delegated Bandwidth Query Request
    message.
 If the AN has already committed multicast bandwidth exceeding the
 amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT
 discontinue any multicast streams in order to bring bandwidth down to
 within the new limit, unless such action is required by local policy.
 However, the AN MUST NOT admit new multicast streams that are subject
 to admission control until it can do so within the limit specified by
 the Bandwidth-Allocation TLV.  As specified in Section 6.2.5.2, the
 AN MAY attempt to correct the situation by sending a request to the
 NAS for an increased allocation of delegated bandwidth using the
 Bandwidth Reallocation Request message.

Le Faucheur, et al. Standards Track [Page 33] RFC 7256 ANCP Multicast Extensions July 2014

4.7. Delegated Bandwidth Query Request Message

 The Message Type for the Delegated Bandwidth Query Request (and
 Response) messages is 148.
 The Delegated Bandwidth Query Request message MAY be sent either by
 the NAS or by the AN to retrieve the peer's view of the amount of
 delegated bandwidth.  The request contains one TLV:
 o  a Target TLV designating the access line for which the information
    is requested.

4.7.1. Sender Behavior

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

4.7.2. Receiver Behavior

 If the AN or NAS receives a valid Delegated Bandwidth Query Request
 message, it MUST respond with a Delegated Bandwidth Query Response
 message.  The Result field in the header of the response MUST be set
 to Success (0x3).  The Result Code field MUST be set to 0.  The
 Transaction Identifier field MUST be copied from the request message.
 The body of the response MUST contain the Target TLV, copied from the
 request message.  Finally, the body of the response MUST contain a
 Bandwidth-Allocation TLV, containing the current amount of delegated
 bandwidth from the point of view of the receiver of the request.
 If the contents of the Delegated Bandwidth Query Request message are
 in error, the receiver MUST return a Delegated Bandwidth Query
 Response message with the Result field in the header set to Failure
 (0x3).  The Result Code field MUST be set to the value that indicates
 the nature of the error (e.g., 0x500 "One or more of the specified
 ports do not exist").  The Transaction Identifier field MUST be
 copied from the request.  The body of the response MUST contain the
 Target TLV copied from the request.  This MAY be followed by a
 Status-Info TLV giving further information about the error.

4.8. Delegated Bandwidth Query Response Message

 The Delegated Bandwidth Query Response message is sent in reply to a
 Delegated Bandwidth Query Request message.  The response to a valid
 request contains two TLVs:

Le Faucheur, et al. Standards Track [Page 34] RFC 7256 ANCP Multicast Extensions July 2014

 o  the Target TLV, copied from the request; and
 o  a Bandwidth-Allocation TLV, giving the responder's view of the
    current amount of multicast bandwidth delegated to the AN.
 The Message Type for the Delegated Bandwidth Query Response message
 is 148.

4.8.1. Sender Behavior

 Sender behavior for the Delegated Bandwidth Query Response message is
 specified in Section 4.7.2.

4.8.2. Receiver Behavior

 If the Delegated Bandwidth Query Response message indicates Success
 (0x3), the actions described in Sections 4.8.2.1 and 4.8.2.2 apply.

4.8.2.1. Behavior at the NAS

 If the amount of delegated bandwidth provided in the Bandwidth-
 Allocation TLV is less than the NAS's view of the current amount of
 delegated bandwidth, the NAS MUST update its view of the current
 amount of delegated bandwidth to the amount indicated in the
 Delegated Bandwidth Query Response message.
 If the amount of delegated bandwidth provided in the Bandwidth-
 Allocation TLV is greater than the NAS's view of the current amount
 of delegated bandwidth, the NAS MAY accept the given value as its new
 value of delegated bandwidth.  Alternatively, the NAS MAY force the
 AN to modify its view of the amount of delegated bandwidth to that
 held by the NAS by sending a Port Management message for the target
 access line concerned that contains a Bandwidth-Allocation TLV with a
 value equal to the amount of delegated bandwidth the NAS wishes to
 enforce.

4.8.2.2. Behavior at the AN

 The AN SHOULD accept the value returned in the Bandwidth-Allocation
 TLV of the Delegated Bandwidth Query Response message as the correct
 value of the current amount of delegated bandwidth.  If the AN has
 already committed multicast bandwidth exceeding the amount given in
 the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any
 multicast streams in order to bring bandwidth down to within the new
 limit, unless such action is required by local policy.  However, the
 AN MUST NOT admit new multicast streams that are subject to admission
 control until it can do so within the limit specified by the
 Bandwidth-Allocation TLV.  As specified in Section 6.2.5.2, the AN

Le Faucheur, et al. Standards Track [Page 35] RFC 7256 ANCP Multicast Extensions July 2014

 MAY attempt to correct the situation by sending a request to the NAS
 for an increased allocation of delegated bandwidth using the
 Bandwidth Reallocation Request message.
    Note: A race condition is possible where the AN sends a query, the
    NAS requests more bandwidth, then receives and responds to the
    query, and then receives the Bandwidth Transfer message responding
    to its request.  It is up to the AN to take appropriate action in
    this case.  The best action appears to be not to act on the result
    of the first query but to repeat the query after sending the
    Bandwidth Transfer message.  Similar considerations apply to a
    race between queries from both sides.

4.9. Multicast Flow Query Request and Response Messages

 This section defines two new messages called the Multicast Flow Query
 Request and Multicast Flow Query Response.  The Multicast Flow Query
 Request message is sent by the NAS to request information about the
 multicast flows that are active on the AN.  The Multicast Flow Query
 Response message is sent in response by the AN to provide the
 requested information to the NAS.
 The Message Type for the Multicast Flow Query Request and Multicast
 Flow Query Response messages is 149.
 The contents of the Multicast Flow Query Request and Multicast Flow
 Query Response messages depend on the nature of the query, as
 described below.

4.9.1. Sender Behavior

 The sender of a Multicast Flow Query Request message MUST set the
 Result field to AckAll (0x2).  The Result Code field MUST be set to
 0x000.  The sender MUST populate the ANCP Transaction Identifier
 field with a unique value, as described in Section 3.6.1.6 of
 [RFC6320].
 The Multicast Flow Query Request message MAY be used by the NAS to
 retrieve:
 o  the AN's view of which multicast flows are currently active on a
    specified set of access ports; or
 o  the AN's view of the access ports on which a specified set of
    multicast flows are currently active; or
 o  the AN's view of all the multicast flows currently active on each
    access port of the AN.

Le Faucheur, et al. Standards Track [Page 36] RFC 7256 ANCP Multicast Extensions July 2014

 To retrieve the AN's view of which multicast flows are currently
 active on a given port of the AN, the NAS MUST include a Target TLV
 in the Multicast Flow Query Request payload identifying that port.
 The Target TLV is encoded as specified in [RFC6320].
 To retrieve the AN's view of the ports currently receiving a given
 multicast flow, the NAS MUST include a Multicast-Flow TLV in the
 Multicast Flow Query Request payload identifying that flow.  The
 Multicast-Flow TLV is encoded as specified in Section 5.12.
 The NAS MAY include multiple Target TLVs or multiple Multicast-Flow
 TLVs in the Multicast Flow Query Request message but MUST NOT include
 both Target and Multicast-Flow TLVs in the same message.
 To retrieve the AN's view of all of the multicast flows currently
 active on each port of the AN, the NAS MUST send a Multicast Flow
 Query Request message that does not contain any instance of the
 Target TLV or the Multicast-Flow TLV.

4.9.2. Receiver Behavior

 The AN MUST respond to a Multicast Flow Query Request message that
 has a valid format and a valid content with a Multicast Flow Query
 Response message.  The Result field in the response MUST be set to
 Success (0x3).  The Result Code field MUST be set to 0.  The
 Transaction Identifier field MUST be copied from the request.
 If the Multicast Flow Query Request contains one (or more) Target
 TLVs, the AN MUST include, for each of these Target TLVs, the
 following set of TLVs:
 o  Target TLV.  This MUST be identical to the Target TLV in the
    received Multicast Flow Query Request message.
 o  Multicast-Flow TLV(s).  The Multicast-Flow TLV MUST appear once
    per multicast flow that is currently active on the AN port
    identified in the preceding Target TLV.
 The Target TLVs MUST appear in the response from the AN in the same
 order as in the query from the NAS.
 If the Multicast Flow Query Request message contains one (or more)
 Multicast-Flow TLVs, the AN MUST include, for each of these
 Multicast-Flow TLVs, the following set of TLVs:
 o  Multicast-Flow TLV.  This MUST be identical to the Multicast-Flow
    TLV in the received Multicast Flow Query Request message.

Le Faucheur, et al. Standards Track [Page 37] RFC 7256 ANCP Multicast Extensions July 2014

 o  Target TLV(s).  The Target TLV MUST appear once per AN port on
    which the multicast flow identified in the preceding Multicast-
    Flow TLV is active.
 The Multicast-Flow TLVs MUST appear in the response from the AN in
 the same order as in the query from the NAS.
 If the Multicast Flow Query Request message contains no Target TLV
 and no Multicast Flow TLV, the AN MUST include, for each AN port
 currently receiving multicast flow(s), the following set of TLVs:
 o  Target TLV.  This MUST identify one AN port.
 o  Multicast-Flow TLV(s).  The Multicast-Flow TLV MUST appear once
    per Multicast Flow that is currently active on the AN port
    identified in the preceding Target TLV.
 If the contents of the Multicast Flow Query Request message are in
 error, the AN MUST reply with a Multicast Flow Query Response message
 with the Result field set to Failure (0x4) and the Result Code field
 set to indicate the nature of the error.  If the request contained
 multiple instances of the Target TLV or the Multicast-Flow TLV and
 one of these is in error, the response message MUST contain the
 results for the preceding instances of the TLV as if there had been
 no error.  These successful results MUST be followed by the TLV in
 error, copied from the request.  The AN MUST NOT do further
 processing of the request.  The AN MAY add a Status-Info TLV to
 provide further information on the nature of the error.

4.10. Committed Bandwidth Report Message

 This section describes the Committed Bandwidth Report message, which
 is sent from the AN to the NAS to report the most recent amount of
 multicast bandwidth usage committed to one or more access lines.
 The Message Type for the Committed Bandwidth Report message is 150.
 The Committed Bandwidth Report message contains one or more instances
 of the Committed-Bandwidth TLV, as described in Section 5.14.

4.10.1. Sender Behavior

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

Le Faucheur, et al. Standards Track [Page 38] RFC 7256 ANCP Multicast Extensions July 2014

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

4.10.2. Receiver Behavior

 The usage of the contents of a Committed Bandwidth Report message
 received by the NAS is implementation-dependent.  One example is that
 the NAS uses the reports of multicast bandwidth commitments to adjust
 its forwarding scheduler operation to provide the intended level of
 QoS.
 The NAS MUST NOT reply to a valid Committed Bandwidth Report message.
 The NAS MAY send a Generic Response message indicating the nature of
 any errors detected in a Committed Bandwidth Report message that it
 has received.

5. ANCP TLVs For Multicast

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

5.1. Multicast-Service-Profile TLV

 This document defines the new Multicast-Service-Profile TLV.
 The Multicast-Service-Profile TLV MAY be included in a Provisioning
 message as specified in Section 4.1.
 The Multicast-Service-Profile TLV is illustrated in Figure 7.  It
 consists of a TLV header encapsulating a single instance of the
 Multicast-Service-Profile-Name TLV and one or more instances of the
 List-Action TLV.

Le Faucheur, et al. Standards Track [Page 39] RFC 7256 ANCP Multicast Extensions July 2014

                      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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Mcast-Service-Profile 0x0013 |             TLV Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Multicast-Service-Profile-Name TLV                          |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   List-Action TLV                                             |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          ...                                  |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   List-Action TLV                                             |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 7: Multicast-Service-Profile TLV
 The Multicast-Service-Profile TLV has the following fields:
 o  TLV Type: 0x0013
 o  TLV Length: determined by the contents following the TLV header.
 o  Multicast-Service-Profile-Name TLV: described in Section 5.2.  The
    Multicast-Service-Profile-Name TLV MUST contain an identifier that
    is unique over all profiles provisioned to the same AN partition.
    This identifier will be used to refer to the profile when
    activating it for a given target within a Port Management message
    (see Section 4.2).
 o  List-Action TLV: described in Section 5.3.  The List-Action TLV(s)
    provide the content of a newly defined multicast service profile
    or modify the existing content.  If more than one List-Action TLV
    is present, the order of the TLVs may be significant, since List-
    Action TLVs are processed in the order in which they appear.

Le Faucheur, et al. Standards Track [Page 40] RFC 7256 ANCP Multicast Extensions July 2014

5.2. Multicast-Service-Profile-Name TLV

 The Multicast-Service-Profile-Name TLV carries the identifier of a
 multicast service profile provisioned on the AN.  It is illustrated
 in Figure 8.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Mcast-Svc-Profile-Name 0x0018 |             TLV Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Multicast service profile identifier                        |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 8: Multicast-Service-Profile-Name TLV
 The Multicast-Service-Profile-Name TLV has the following fields:
 o  TLV Type: 0x0018
 o  TLV Length: up to 255 octets.
 o  Multicast service profile identifier: an opaque sequence of octets
    identifying a specific multicast service profile.
       Note: The identifier could have the form of human-readable text
       or an arbitrary binary value, depending on the operator's
       practices.

5.3. List-Action TLV

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

Le Faucheur, et al. Standards Track [Page 41] RFC 7256 ANCP Multicast Extensions July 2014

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = List-Action 0x0021 |          TLV Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Operation     | List Type     |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Address Family                |     Number of flow fields     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Multicast flow fields                      |
                           ......
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Address Family                |     Number of flow fields     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Multicast flow fields                      |
                                  ......
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 9: List-Action TLV
 The List-Action TLV contains the following fields:
 o  TLV Type: 0x0021
 o  TLV Length: length of the subsequent contents.
 o  Operation: operation to be performed upon the white, black, or
    grey list identified by the List Type field within the profile
    identified by the associated Multicast-Service-Profile-Name
    embedded TLV.  The possible values are:
  • 1 "Add": the multicast flow fields are to be added to the list.
  • 2 "Delete": the multicast flow fields are to be removed from

the list. Each multicast flow field in the List-Action MUST

       match exactly an existing entry in the list concerned.  Thus,
       to remove part of the range provided by a wildcarded list
       entry, it is necessary to remove the entire entry and add back
       the remaining partial range(s).
  • 3 "Replace": the multicast flow fields replace the existing

contents of the list.

 o  List Type: the list type being modified by this List-Action TLV.
    The possible values are 1 "White", 2 "Black", or 3 "Grey".

Le Faucheur, et al. Standards Track [Page 42] RFC 7256 ANCP Multicast Extensions July 2014

 o  Reserved: a sender MUST set this field to zeroes.  A receiver MUST
    ignore the contents of this field.
 o  Address Family: the IP version of the set of multicast flow fields
    that follow, encoded according to [PIMreg].  Possible values are 1
    "IPv4" or 2 "IPv6".  Either an IPv4 list or an IPv6 list or both
    MAY be present in the List-Action TLV.
 o  Number of flow fields: the number of multicast flow fields of the
    given address family that follows.
 o  Multicast flow field: a field identifying one or more multicast
    flows.  It consists of an 8-bit group address prefix length, an
    8-bit source address prefix length, a group prefix of 0-16 octets,
    and a source prefix of 0-16 octets, as shown in Figure 10.
 Each multicast flow field refers either to a Source-Specific
 Multicast (SSM) channel or to an Any-Source Multicast (ASM) group.
 The scope of the designation may be broadened to multiple channels or
 groups through use of prefix length values smaller than the total
 address length for the given address family.  Multicast flow fields
 MUST be placed consecutively within the embedded TLV without
 intervening padding except to round out individual addresses to the
 nearest octet boundary.
 A multicast flow field consists of two single-octet prefix lengths
 followed by zero to two prefix values as shown in Figure 10:
  +-+-+-+-+-+-+-+-+
  | Group PrefLen |
  +-+-+-+-+-+-+-+-+
  | Source PrefLen|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Group Prefix (multicast)  (0 to 16 octets)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Source Prefix (unicast, SSM only) (0 to 16 octets)            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Figure 10: Organization of a Single Multicast Flow Field
 The prefix length has its usual meaning.  It is the number of most-
 significant bits specified within the corresponding prefix.  The
 prefix length MAY vary from 0 to 32 in the IPv4 sub-list and from 0
 to 128 in the IPv6 sub-list.

Le Faucheur, et al. Standards Track [Page 43] RFC 7256 ANCP Multicast Extensions July 2014

 A value of 0 for either the Group PrefLen (prefix length) or the
 Source PrefLen indicates that any value of the corresponding address
 will match (wildcard).  If the value 0 is provided for a particular
 prefix length, the corresponding prefix MUST be omitted from the
 field contents.
 The length of a Source or Group Prefix field is equal to (PrefLen +
 7)/8 octets, truncated to the nearest integer.  Unused bits at the
 end of the prefix MUST be set to zeroes.

5.4. Sequence-Number TLV

 The Sequence-Number TLV conveys a sequence number of some sort.  The
 specific meaning of the sequence number is message-specific.  Within
 this specification, the Sequence-Number TLV is used as an embedded
 TLV in a Status-Info TLV in a Generic Response message reporting a
 failed command in a Multicast Replication Control or Multicast
 Admission Request message.  It identifies the sequence number within
 the message of the command that failed.
 The Sequence-Number TLV has the format shown in Figure 11.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = Sequence-Number 0x0022 |          TLV Length = 4       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Sequence number                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 11: Sequence-Number TLV
 The Sequence-Number TLV has the following fields:
 o  TLV Type: 0x0022
 o  TLV Length: 4
 o  Sequence number: the sequence number of a specific entity within a
    series, where numbering starts from 1 for the first entity in the
    series.  Represented as a 32-bit binary number, most significant
    bit first.

Le Faucheur, et al. Standards Track [Page 44] RFC 7256 ANCP Multicast Extensions July 2014

5.5. Bandwidth-Allocation TLV

 The Bandwidth-Allocation TLV is used to indicate the total amount of
 video bandwidth delegated to the AN for multicast admission control
 for a given access line, in kilobits per second.  The TLV has the
 format shown in Figure 12.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Bandwidth-Allocation 0x0015 |          TLV Length = 4       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Delegated amount (kbits/s)                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 12: Bandwidth-Allocation TLV
 The Bandwidth-Allocation TLV has the following fields:
 o  TLV Type: 0x0015
 o  TLV Length: 4
 o  Delegated amount: the bandwidth amount delegated to the AN for
    admission of multicast video on a given port, kilobits per second.
    Represented as a 32-bit binary value, most significant bit first.

5.6. White-List-CAC TLV

 The White-List-CAC TLV is used to indicate that the NAS wishes the AN
 to do admission control for white-listed flows.  Details on when the
 White-List-CAC TLV may be provisioned are specified in Section 6.
 The White-List-CAC TLV is illustrated in Figure 13.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type = White-List-CAC 0x0024 |          TLV Length = 0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 13: White-List-CAC TLV
 The White-List-CAC TLV contains the following fields:
 o  TLV Type: 0x0024
 o  TLV Length: 0, since the TLV contains no data other than the TLV
    header.

Le Faucheur, et al. Standards Track [Page 45] RFC 7256 ANCP Multicast Extensions July 2014

5.7. MRepCtl-CAC TLV

 The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to
 do admission control for flows added by the Multicast Replication
 Control message.  Details on when the MRepCtl-CAC TLV may be
 provisioned are specified in Section 6.  The MRepCtl-CAC TLV is
 illustrated in Figure 14.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |TLV Type = MRepCtl-CAC  0x0025 |          TLV Length = 0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 14: MRepCtl-CAC TLV
 The MRepCtl-CAC TLV contains the following fields:
 o  TLV Type: 0x0025
 o  TLV Length: 0, since the TLV contains no data other than the TLV
    header.

5.8. Bandwidth-Request TLV

 The Bandwidth-Request TLV is used to request an adjustment of the
 total amount of video bandwidth allocated to the AN for multicast
 admission control for a given line.  The "Required amount" field
 indicates the minimum adjustment required to meet the request.  The
 "Preferred amount" field indicates the adjustment the requestor would
 prefer to have, if possible.  Section 4.5 discusses the required
 relationships between the "Required amount", "Preferred amount", and
 current values of total bandwidth allocated to the AN.
 The Bandwidth-Request TLV has the format shown in Figure 15.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=Bandwidth-Request 0x0016 |          TLV Length = 8       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Required amount  (kbits/s)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Preferred amount (kbits/s)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 15: Bandwidth-Request TLV

Le Faucheur, et al. Standards Track [Page 46] RFC 7256 ANCP Multicast Extensions July 2014

 The Bandwidth-Request TLV has the following fields:
 o  TLV Type: 0x0016
 o  TLV Length: 8 octets
 o  Required amount: the minimum or maximum amount, depending on
    whether the sender is the AN or the NAS respectively, of delegated
    video bandwidth that is being requested, in kilobits per second.
    Represented as a 32-bit binary value, most significant bit first.
 o  Preferred amount: the preferred amount of delegated video
    bandwidth that is being requested, in kilobits per second.
    Represented as a 32-bit binary value, most significant bit first.

5.9. Request-Source-IP TLV

 The Request-Source-IP TLV provides the IP address of the entity that
 originated a specific request to join or leave a multicast channel.
 The TLV is illustrated in Figure 16.
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  TLV Type = Request-Source-IP |   TLV Length = 4 or 16        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Unicast Address                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 16: Request-Source-IP TLV
 The Request-Source-IP TLV contains the following fields:
 o  TLV Type: 0x0092
 o  TLV Length: 4 for an IPv4 address or 16 for an IPv6 address.
 o  Unicast address: IP address of the source of a multicast flow join
    request, in network byte order.

Le Faucheur, et al. Standards Track [Page 47] RFC 7256 ANCP Multicast Extensions July 2014

5.10. Request-Source-MAC TLV

 The Request-Source-MAC TLV provides the MAC address of the entity
 that originated a specific request to join or leave a multicast
 channel.  The TLV is illustrated in Figure 17.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |TLV Type=Request-Source-MAC    |     TLV Length = 6 or 8       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +-+-+-                      IEEE MAC Address              +-+-+-+
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 17: Request-Source-MAC TLV
 The Request-Source-MAC TLV contains the following fields:
 o  TLV Type: 0x0093.
 o  TLV Length: either 6 octets (MAC-48 or EUI-48) or 8 octets (EUI-
    64).
 o  IEEE MAC Address: MAC address of the device originating the
    request to join a multicast flow.  Within the address, bytes and
    bits, respectively, shall be ordered from most to least
    significant, consistent with [IEEE48] for MAC-48 and EUI-48 and
    with [IEEE64] for EUI-64.
       Note: EUI-48 and EUI-64 are registered trademarks of the IEEE.

5.11. Request-Source-Device-Id TLV

 The Request-Source-Device-Id TLV provides a local identifier of the
 entity that originated a specific request to join or leave a
 multicast channel.  The TLV is illustrated in Figure 18.
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Request-Source-Device-Id   |       TLV Length = 4          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Identifier value                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 18: Request-Source-Device-Id TLV

Le Faucheur, et al. Standards Track [Page 48] RFC 7256 ANCP Multicast Extensions July 2014

 The Request-Source-Device-Id TLV contains the following fields:
 o  TLV Type: 0x0096.
 o  TLV Length: 4
 o  Identifier value: local device identifier value, known to the AN
    and AAA.  Given that the scope of the identifier is a single
    customer network, 32 bits is a more-than-sufficient numbering
    space.

5.12. Multicast-Flow TLV

 IGMPv3 [RFC3376] and MLDv2 [RFC3810] allow multicast listeners to
 specify multiple source addresses for the same multicast group.
 Similarly, the Multicast-Flow TLV specifies a multicast flow in terms
 of its multicast group address and, if applicable, one or more
 unicast source addresses.  The Multicast-Flow TLV is illustrated in
 Figure 19.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = Multicast-Flow  0x0019 |      TLV Length               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Flow Type   |  Addr Family  |   Number of Source Addresses  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Multicast Group Address                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
 |           Unicast Source Address (for SSM flows only)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 19: Multicast-Flow TLV
 The Multicast-Flow TLV has the following fields:
 o  TLV Type: 0x0019
 o  TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow)
    upwards.  Total length is 4 + 4*(Number of Source Addresses +1)
    for IPv4 or 4 + 16*(Number of Source Addresses + 1) for IPv6.
 o  Flow Type: 1 "Any-Source Multicast (ASM)", 2 "Source-Specific
    Multicast (SSM)".
 o  Addr Family: address family of the multicast source and group
    addresses, encoded in accordance with the IANA "PIM Address
    Family" registry ([PIMreg]). 1 indicates IPv4; 2 indicates IPv6.

Le Faucheur, et al. Standards Track [Page 49] RFC 7256 ANCP Multicast Extensions July 2014

 o  Number of Source Addresses: 0 for ASM, 1 or more for SSM.
 o  Multicast Group Address: a multicast group address within the
    given address family.  The group address MUST always be present.
 o  Unicast Source Address: unicast address within the given address
    family.  If the Flow Type is "ASM" (1), a source address MUST NOT
    be present.  If the Flow Type is "SSM" (2), the number of source
    addresses given by the Number of Source Addresses field MUST be
    present.
 The full versions of IGMPv3 and MLDv2 support both INCLUDE and
 EXCLUDE modes for specifying the desired sources for SSM flows.  The
 Multicast-Flow TLV supports INCLUDE mode only.  [RFC5790]
 (Lightweight IGMPv3 and MLDv2) provides guidance on converting
 EXCLUDE mode IGMP/MLD records to INCLUDE mode for the Multicast-Flow
 TLV.

5.13. Report-Buffering-Time TLV

 The Report-Buffering-Time TLV provides the time for which a Committed
 Bandwidth Report message must be held with the intention of
 accumulating multiple reports of changed committed multicast
 bandwidth in one report, to reduce the volume of messages sent to the
 NAS.  For further information see Section 6.2.2.  The TLV is
 illustrated in Figure 20.
                      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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Report-Buffering-Time  0x0094 |      TLV Length = 4           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Buffering Time (ms)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 20: Report-Buffering-Time TLV
 The Report-Buffering-Time TLV contains the following fields:
 o  TLV Type: 0x0094
 o  TLV Length: 4 octets
 o  Buffering Time is a 32-bit unsigned integer containing a time
    value in milliseconds (ms).

Le Faucheur, et al. Standards Track [Page 50] RFC 7256 ANCP Multicast Extensions July 2014

5.14. Committed-Bandwidth TLV

 The Committed-Bandwidth TLV identifies an access line and provides
 the current amount of multicast bandwidth that the AN has committed
 to it.  The TLV is illustrated in Figure 21.
                      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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Committed-Bandwidth    0x0095 |      TLV Length (variable)    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Committed Multicast Bandwidth   (kbits/s)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                           Target TLV                          ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 21: Committed-Bandwidth TLV
 The Committed-Bandwidth TLV contains the following fields:
 o  TLV Type: 0x0095
 o  TLV Length: 4 octets plus the length of the Target TLV, including
    its header and any padding.
 o  Committed Multicast Bandwidth: a 32-bit unsigned integer providing
    a bandwidth amount in kbits/s.
 o  Target TLV: identifies the access line to which this amount of
    multicast bandwidth is currently committed.

6. Multicast Capabilities

 Section 3.5 of [RFC6320] defines a capability negotiation mechanism
 as well as a number of capabilities.  This section defines five new
 capabilities in support of different modes of multicast operation:
 o  NAS-initiated multicast replication (capability type 3);
 o  committed bandwidth reporting (capability type 5);
 o  conditional access and admission control with white and black
    lists (capability type 6);

Le Faucheur, et al. Standards Track [Page 51] RFC 7256 ANCP Multicast Extensions July 2014

 o  conditional access and admission control with grey lists
    (capability type 7); and
 o  bandwidth delegation (capability type 8).
 The "Capability Data" field within the Capability TLV for all of
 these capabilities is empty.  All of these capabilities are
 independent of the access technology.
 The remainder of this section consists of three sub-sections.
 Section 6.1 specifies the protocol elements that must be implemented
 in order to support each capability.  Section 6.2 specifies the
 procedures that apply to each capability on its own.  Section 6.3
 specifies how the capabilities interact if more than one multicast
 capability is included in the set of capabilities negotiated between
 the AN and the NAS.

6.1. Required Protocol Support

 This section specifies the protocol elements that MUST be implemented
 to support each of the five multicast capabilities.  Support of
 multiple multicast capabilities requires implementation of the union
 of the sets of protocol elements applying to each of the individual
 capabilities in the supported set.
 In addition to the elements listed below, implementation of the
 Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the
 capabilities specified in this document.

6.1.1. Protocol Requirements for NAS-Initiated Multicast Replication

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

Le Faucheur, et al. Standards Track [Page 52] RFC 7256 ANCP Multicast Extensions July 2014

 +--------------+----------------------------------------------------+
 | Reference    | Protocol Element                                   |
 +--------------+----------------------------------------------------+
 | Section 4.1  | Provisioning message with MRepCtl-CAC TLV          |
 |              |                                                    |
 | Section 4.2  | Port Management message with Bandwidth-Allocation  |
 |              | TLV                                                |
 |              |                                                    |
 | Section 4.3  | Multicast Replication Control message              |
 |              |                                                    |
 | Section 4.9  | Multicast Flow Query Request and Response messages |
 |              |                                                    |
 | Section 5.4  | Sequence Number TLV                                |
 |              |                                                    |
 | Section 5.5  | Bandwidth-Allocation TLV                           |
 |              |                                                    |
 | Section 5.7  | MRepCtl-CAC TLV                                    |
 |              |                                                    |
 | Section 5.12 | Multicast-Flow TLV                                 |
 +--------------+----------------------------------------------------+
      Table 1: Protocol Requirements for NAS-Initiated Multicast
                              Replication

Le Faucheur, et al. Standards Track [Page 53] RFC 7256 ANCP Multicast Extensions July 2014

6.1.2. Protocol Requirements for Committed Multicast Bandwidth

      Reporting
 Table 2 specifies the protocol elements within Section 4 and
 Section 5 that MUST be implemented to support the committed multicast
 bandwidth reporting capability.
 +--------------+----------------------------------------------------+
 | Reference    | Protocol Element                                   |
 +--------------+----------------------------------------------------+
 | Section 4.1  | Provisioning message with Report-Buffering-Time    |
 |              | TLV                                                |
 |              |                                                    |
 | Section 4.10 | Committed Bandwidth Report message                 |
 |              |                                                    |
 | Section 4.9  | Multicast Flow Query Request and Response messages |
 |              |                                                    |
 | Section 5.13 | Report-Buffering-Timer TLV                         |
 |              |                                                    |
 | Section 5.14 | Committed-Bandwidth TLV                            |
 |              |                                                    |
 | Section 5.12 | Multicast-Flow TLV                                 |
 +--------------+----------------------------------------------------+
   Table 2: Protocol Requirements for Committed Multicast Bandwidth
                               Reporting

Le Faucheur, et al. Standards Track [Page 54] RFC 7256 ANCP Multicast Extensions July 2014

6.1.3. Protocol Requirements for Conditional Access and Admission

      Control with White and Black Lists
 Table 3 specifies the protocol elements within Section 4 and
 Section 5 that MUST be implemented to support the conditional access
 and admission control with white and black lists multicast
 capability.
 +--------------+----------------------------------------------------+
 | Reference    | Protocol Element                                   |
 +--------------+----------------------------------------------------+
 | Section 4.1  | Provisioning message with Multicast-Service-       |
 |              | Profile TLV, white and black lists only, and       |
 |              | White-List-CAC TLV                                 |
 |              |                                                    |
 | Section 4.2  | Port Management message with Multicast-Service-    |
 |              | Profile-Name and Bandwidth-Allocation TLVs         |
 |              |                                                    |
 | Section 4.9  | Multicast Flow Query Request and Response messages |
 |              |                                                    |
 | Section 5.1  | Multicast-Service-Profile TLV                      |
 |              |                                                    |
 | Section 5.2  | Multicast-Service-Profile-Name TLV                 |
 |              |                                                    |
 | Section 5.3  | List-Action TLV, white and black lists only        |
 |              |                                                    |
 | Section 5.5  | Bandwidth-Allocation TLV                           |
 |              |                                                    |
 | Section 5.6  | White-List-CAC TLV                                 |
 |              |                                                    |
 | Section 5.12 | Multicast-Flow TLV                                 |
 +--------------+----------------------------------------------------+
  Table 3: Protocol Requirements for Conditional Access and Admission
                  Control with White and Black Lists

Le Faucheur, et al. Standards Track [Page 55] RFC 7256 ANCP Multicast Extensions July 2014

6.1.4. Protocol Requirements for Conditional Access and Admission

      Control with Grey Lists
 Table 4 specifies the protocol elements within Section 4 and
 Section 5 that MUST be implemented to support the conditional access
 and admission control with grey lists multicast capability.
 Additionally, implementation of the Multicast Replication Control
 message requires implementation of the Command TLV (Section 4.4 of
 [RFC6320] with additional details in Section 4.3 of this document).
 +--------------+----------------------------------------------------+
 | Reference    | Protocol Element                                   |
 +--------------+----------------------------------------------------+
 | Section 4.1  | Provisioning message with Multicast-Service-       |
 |              | Profile TLV, grey lists only, and MRepCtl-CAC TLV  |
 |              |                                                    |
 | Section 4.2  | Port Management message with Multicast-Service-    |
 |              | Profile-Name and Bandwidth-Allocation TLVs         |
 |              |                                                    |
 | Section 4.3  | Multicast Replication Control message              |
 |              |                                                    |
 | Section 4.4  | Multicast Admission Control message                |
 |              |                                                    |
 | Section 4.9  | Multicast Flow Query Request and Response messages |
 |              |                                                    |
 | Section 5.1  | Multicast-Service-Profile TLV, grey lists only     |
 |              |                                                    |
 | Section 5.2  | Multicast-Service-Profile-Name TLV                 |
 |              |                                                    |
 | Section 5.3  | List-Action TLV, grey lists only                   |
 |              |                                                    |
 | Section 5.4  | Sequence Number TLV                                |
 |              |                                                    |
 | Section 5.5  | Bandwidth-Allocation TLV                           |
 |              |                                                    |
 | Section 5.7  | MRepCtl-CAC TLV                                    |
 |              |                                                    |
 | Section 5.9  | Request-Source-IP TLV                              |
 |              |                                                    |
 | Section 5.10 | Request-Source-MAC TLV                             |
 |              |                                                    |
 | Section 5.11 | Request-Source-Device-Id TLV                       |
 |              |                                                    |
 | Section 5.12 | Multicast-Flow TLV                                 |
 +--------------+----------------------------------------------------+
  Table 4: Protocol Requirements for Conditional Access and Admission
                        Control with Grey Lists

Le Faucheur, et al. Standards Track [Page 56] RFC 7256 ANCP Multicast Extensions July 2014

6.1.5. Protocol Requirements for Bandwidth Delegation

 Table 5 specifies the protocol elements within Section 4 and
 Section 5 that MUST be implemented to support the bandwidth
 delegation capability.
 +--------------+----------------------------------------------------+
 | Reference    | Protocol Element                                   |
 +--------------+----------------------------------------------------+
 | Section 4.2  | Port Management message with Bandwidth-Allocation  |
 |              | TLV                                                |
 |              |                                                    |
 | Section 4.5  | Bandwidth Reallocation Request message             |
 |              |                                                    |
 | Section 4.6  | Bandwidth Transfer message                         |
 |              |                                                    |
 | Section 4.7  | Delegated Bandwidth Query Request message          |
 |              |                                                    |
 | Section 4.8  | Delegated Bandwidth Query Response message         |
 |              |                                                    |
 | Section 4.9  | Multicast Flow Query Request and Response messages |
 |              |                                                    |
 | Section 5.5  | Bandwidth-Allocation TLV                           |
 |              |                                                    |
 | Section 5.8  | Bandwidth-Request TLV                              |
 |              |                                                    |
 | Section 5.12 | Multicast-Flow TLV                                 |
 +--------------+----------------------------------------------------+
        Table 5: Protocol Requirements for Bandwidth Delegation

6.2. Capability-Specific Procedures for Providing Multicast Service

 This section describes multicast service procedures for each
 capability as if it were the only multicast capability within the
 negotiated set.  Procedures involving combinations of multicast
 capabilities are described in Section 6.3.
 The use of the Multicast Flow Query Request and Response messages to
 determine the association between multicast flows and ports is common
 to all multicast capabilities.  No additional text is required here,
 beyond that already given in Section 4.9 to describe the use of those
 messages.

Le Faucheur, et al. Standards Track [Page 57] RFC 7256 ANCP Multicast Extensions July 2014

6.2.1. Procedures for NAS-Initiated Multicast Replication

 NAS-initiated multicast replication may be negotiated to support a
 mode of operation where IGMP/MLD requests are terminated on the NAS.
 Alternatively, it may be negotiated to allow the NAS to respond to
 requests sent by other means (e.g., through application signaling)
 that require the replication of multicast channels to a given access
 line.

6.2.1.1. Provisioning

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

6.2.1.2. Multicast Service Procedures

 The procedures associated with NAS-initiated multicast replication
 are straightforward.  To initiate replication, the NAS MUST send a
 Multicast Replication Control message to the AN, containing one or
 more commands adding flows, as described in Section 4.3.1.  To
 terminate replication, the NAS MUST send a Multicast Replication
 Control message where the commands delete instead of adding the
 flows.  The AN acts upon these messages as specified in
 Section 4.3.2.

6.2.2. Procedures for Committed Bandwidth Reporting

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

6.2.2.1. Provisioning

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

Le Faucheur, et al. Standards Track [Page 58] RFC 7256 ANCP Multicast Extensions July 2014

6.2.2.2. Multicast Service Procedures

 If the buffering time for committed bandwidth reporting is zero, the
 AN MUST send a Committed Bandwidth Report message to the NAS each
 time the amount of multicast bandwidth committed to any access line
 under its control changes.
 If a non-zero value is provided in the Report-Buffering-Time TLV, the
 AN is in one of two states at any given moment: not-buffering or
 buffering.  The AN enters buffering state if it is in not-buffering
 state and the multicast bandwidth amount committed to some access
 line changes.  It leaves buffering state when the AN sends a
 Committed Bandwidth Report message.
 Upon entry to the buffering state, the AN MUST start a buffering
 timer and create a Committed Bandwidth Report message containing a
 Committed-Bandwidth TLV for the triggering access line, but it MUST
 NOT send it.  If a multicast bandwidth change occurs for another
 access line, the AN MUST add a new Committed-Bandwidth TLV to the
 message for that additional line.  If a multicast bandwidth change
 occurs for a line for which a Committed-Bandwidth TLV is already
 present in the buffered report, the AN MUST update the corresponding
 Committed-Bandwidth TLV to contain the new bandwidth value rather
 than adding another Committed-Bandwidth TLV for the same access line.
 The buffering timer expires after the period provided by the Report-
 Buffering-Time TLV.  When it expires, the AN MUST send the Committed
 Bandwidth Report message that it has been accumulating to the NAS.
 Exceptionally, the AN MAY choose to send the message before the timer
 expires, in which case it MUST clear the buffering timer when the
 message is sent.  In either case, the AN enters the not-buffering
 state as a result.
    Note: Report buffering implies that NAS reaction to changes in
    multicast bandwidth usage is delayed by the amount of the
    buffering period.  The choice of buffering period must take this
    into consideration.

6.2.3. Procedures for Conditional Access and Admission Control with

      Black and White Lists

6.2.3.1. Provisioning

 The NAS provisions named multicast service profiles containing white
 and black lists on the AN using the Provisioning message containing
 one or more Multicast-Service-Profile TLVs.  The NAS MAY update the
 contents of these profiles from time to time as required by sending

Le Faucheur, et al. Standards Track [Page 59] RFC 7256 ANCP Multicast Extensions July 2014

 additional Provisioning messages with Multicast-Service-Profile TLVs
 containing incremental modifications to the existing white and black
 lists or replacements for them.
 The NAS assigns a specific multicast service profile to an individual
 access line using the Port Management message containing a Multicast-
 Service-Profile-Name TLV.  The NAS MAY change the multicast service
 profile for a given access line at any time by sending a Port
 Management message identifying a new multicast service profile.
 The NAS MAY choose to enable admission control at the AN for white-
 listed flows.  To do this, it MUST send a Provisioning message as
 described in Section 4.1, which includes the White-List-CAC TLV, and
 it MUST provide a multicast bandwidth allocation for each access line
 by including a Bandwidth-Allocation TLV in a Port Management message.

6.2.3.2. Multicast Service Procedures

 The conditional access and admission control with white and black
 lists capability assumes that IGMP/MLD requests are terminated on the
 AN.  When the AN receives a join request, it MUST check to see
 whether the requested flow is white-listed or black-listed as
 described below.  Requests for black-listed flows MUST be discarded.
 If the NAS has enabled admission control on the AN as described in
 the previous section, but a white-listed flow would cause the amount
 of committed multicast bandwidth to exceed the provisioned limit, the
 request MUST be discarded.  The AN replicates flows passing these
 checks to the access line.
 To determine if a requested flow is white-listed, the AN searches for
 a best match to the flow in the applicable multicast service profile.
 Matching is done on the prefixes specified in the profile, ignoring
 the address bits of lower order than those in the prefix.
 If the requested multicast flow matches multiple lists associated
 with the access line, then the most specific match will be considered
 by the AN.  If the most specific match occurs in multiple lists, the
 black list entry takes precedence over the white list.  In this
 context, the most specific match is defined as:
 o  first, most specific match (longest prefix length) on the
    multicast group address (i.e., on G of <S,G>), and
 o  then, most specific match (longest prefix length) on the unicast
    source address (i.e., on S of <S,G>).

Le Faucheur, et al. Standards Track [Page 60] RFC 7256 ANCP Multicast Extensions July 2014

 If the requested multicast flow is not part of any list, the join
 message SHOULD be discarded by the AN.  This default behavior can
 easily be changed by means of a "catch-all" statement in the white
 list.  For instance, adding (<S=*,G=*>) in the white List would make
 the default behavior to accept join messages for a multicast flow
 that has no other match on any list.
 When the AN receives a leave request, it terminates replication of
 the multicast flow.
 If the AN receives a Provisioning message that updates an existing
 multicast service profile, the AN MUST review the status of active
 flows on all ports to which the updated profile is currently
 assigned.  Similarly, if a Port Management message assigns a new
 multicast service profile to a given port, the AN MUST review all
 active flows on that port.  If the most specific match for any flow
 is a black list entry, the flow MUST be terminated immediately.  If
 any of the remaining flows do not match an entry in the white list,
 they also MUST be terminated immediately.  White-listed flows MUST be
 allowed to continue.

6.2.4. Procedures for Conditional Access and Admission Control with

      Grey Lists

6.2.4.1. Provisioning

 The NAS provisions named multicast service profiles containing grey
 lists on the AN using the Provisioning message containing one or more
 Multicast-Service-Profile TLVs.  The NAS MAY update the contents of
 these profiles from time to time as required by sending additional
 Provisioning messages with Multicast-Service-Profile TLVs containing
 incremental modifications to the existing grey lists or replacements
 for them.
 The NAS assigns a specific multicast service profile to an individual
 access line using the Port Management message containing a Multicast-
 Service-Profile-Name TLV.  The NAS MAY change profiles on the line by
 sending a subsequent Port Management message identifying a new
 profile.
 The NAS MAY perform admission control for grey-listed flows.  In that
 case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning
 message sent to the AN.  Alternatively, the NAS MAY enable admission
 control at the AN for grey-listed flows.  To do this, it MUST include
 the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST
 also provide a Bandwidth-Allocation TLV in a Port Management message
 for each access line.

Le Faucheur, et al. Standards Track [Page 61] RFC 7256 ANCP Multicast Extensions July 2014

6.2.4.2. Multicast Service Procedures

 The conditional access and admission control with grey lists
 capability assumes that IGMP/MLD requests are terminated on the AN.
 When the AN receives a join request, it MUST determine whether there
 is a match to the requested flow in the grey list of the multicast
 service profile provisioned against the given access line.  If there
 is no match, the request is discarded.  Otherwise, the AN MUST send a
 Multicast Admission Control message to the NAS with content
 identifying the access line and the multicast flow to be added.  As
 indicated in Section 4.4, the AN MAY add information identifying the
 requesting device.
 If the NAS decides to enable the flow, it MUST send a Multicast
 Replication Control message to the AN to replicate the flow to the
 access line with the Result field set to Nack (0x1), as described in
 Section 4.3.1.
 When the AN receives the Multicast Replication Control message, it
 performs admission control if that has been enabled as described in
 the previous section.  If admitting the flow would cause the
 committed multicast bandwidth at the access line to exceed the
 provisioned limit, the AN reports an error to the NAS as described in
 Section 4.3.2.  Otherwise, it replicates the multicast flow as
 requested.
 If the NAS decides not to permit the flow, it MAY send a Multicast
 Replication Control message in response to the Multicast Admission
 Control message to allow the AN to update its internal records.  The
 content of this message is described in Section 4.4.2.
 When the AN receives a leave request, it MUST terminate replication
 of the flow to the access line.  It MUST then send a Multicast
 Admission Control message to the NAS indicating the deletion.  The
 NAS updates its internal records but MUST NOT respond to the message.
 If the AN receives a Provisioning message that updates an existing
 multicast service profile, the AN MUST review the status of active
 flows on all ports to which the updated profile has been assigned.
 Similarly, if the AN receives a Port Management message that assigns
 a new profile to a given port, the AN MUST review all active flows on
 that port.  In either case, if any flow does not match an entry in
 the grey list, it MUST be terminated immediately.

Le Faucheur, et al. Standards Track [Page 62] RFC 7256 ANCP Multicast Extensions July 2014

6.2.5. Procedures for Bandwidth Delegation

6.2.5.1. Provisioning

 The NAS SHOULD provision an initial amount of delegated multicast
 bandwidth for each access line using the Port Management message
 containing the Bandwidth-Allocation TLV.
    Note: If it fails to do so and a value has not been provisioned on
    the AN by other means, the AN will be forced to request a
    bandwidth allocation as soon as it receives a join request.
 The NAS MAY, at any time, force an update of the amount of delegated
 bandwidth by the same means.

6.2.5.2. Multicast Service Procedures

 The bandwidth delegation capability assumes that IGMP/MLD requests
 are terminated on the AN.  When the AN receives a join request, it
 checks whether it has sufficient remaining uncommitted multicast
 bandwidth on the access line to accommodate the new multicast flow.
 If not, it MAY send a request to the NAS for an increased allocation
 of delegated bandwidth using the Bandwidth Reallocation Request
 message.  The NAS MUST return a Bandwidth Transfer message indicating
 whether it has granted the request and, if so, the new amount of
 delegated bandwidth.
 If the AN has sufficient uncommitted multicast capacity to admit the
 request, either originally or as the result of a successful request
 to the NAS, it replicates the requested flow to the access line.
 Otherwise, it discards the request.
 When the AN receives a leave request for an active flow, it ceases
 replication.
 The NAS or AN MAY, at some point, detect that their respective views
 of the amount of delegated bandwidth are inconsistent.  If so, they
 can recover using procedures described in Sections 4.5 and 4.6.  As a
 further aid to synchronization, either the NAS or the AN MAY from
 time to time check the peer's view of the amount of delegated
 bandwidth using the Delegated Bandwidth Query message.
 The NAS or AN MAY, at any time, release bandwidth to the peer using
 an autonomous Bandwidth Transfer message.  The contents of this
 message are described in Section 4.6.

Le Faucheur, et al. Standards Track [Page 63] RFC 7256 ANCP Multicast Extensions July 2014

6.3. Combinations of Multicast Capabilities

6.3.1. Combination of Conditional Access and Admission Control with

      White and Black Lists and Conditional Access and Admission
      Control with Grey Lists
 If conditional access and admission control with white and black
 lists is combined with conditional access and admission control with
 grey lists, provisioning of the multicast service profiles is as
 described in Section 6.2.3.1 except that multicast service profiles
 will also include grey lists.  Admission control is enabled
 independently on the AN for white lists by including the White-List-
 CAC TLV in the Provisioning message and for grey lists by including
 the MRepCtl-CAC TLV in the Provisioning message.  The Bandwidth-
 Allocation TLV provisions an amount that applies to both white- and
 grey-listed flows if admission control is enabled for both.
 With regard to multicast service procedures, one point of difference
 from the individual capabilities must be noted.  This is an
 interaction during the profile matching procedure.  The AN MUST seek
 the best match among multiple lists as described in Section 6.2.3.2.
 However, if there are multiple matches of equal precision, the order
 of priority is black list first, grey list second, and white list
 last.
 Once profile matching has been completed, processing of a join
 request is as described in Section 6.2.3.2 for white- or black-listed
 flows or Section 6.2.4.2 for grey-listed flows.  Requests that do not
 match any list SHOULD be discarded.
 When the AN receives a leave request, it MUST terminate replication
 of the flow to the access line.  If the flow was grey-listed, the AN
 MUST then send a Multicast Admission Control message to the NAS
 indicating the deletion.
 If the AN receives a Provisioning message that updates an existing
 multicast service profile, the AN MUST review the status of active
 flows on all ports to which the updated profile is currently
 assigned.  Similarly, if a Port Management message assigns a new
 multicast service profile to a given port, the AN MUST review all
 active flows on that port.  If any flow has its most specific match
 in a black list entry, it MUST be terminated immediately.  If any of
 the remaining flows do not match an entry in the white or grey list,
 they MUST also be terminated immediately.  Finally, if any remaining
 flows were originally admitted because they were white-listed but
 after the change they are grey-listed, the AN MUST generate a
 Multicast Flow Query Response message autonomously as if it were
 responding to a Multicast Flow Query Request message, listing all

Le Faucheur, et al. Standards Track [Page 64] RFC 7256 ANCP Multicast Extensions July 2014

 such flows.  These flows MUST be allowed to continue until the NAS or
 the subscriber terminates them.  Flows with their most specific match
 in the white list MUST be allowed to continue.
 The autonomously generated Multicast Flow Query Response message MUST
 be formatted as if it were a successful response to a request
 containing no Target and no Multicast-Flow TLV, as described in
 Section 4.9.2, with the exception that the Transaction Identifier
 field MUST be set to all zeroes.
    Note: The procedures in the previous paragraphs imply that the AN
    has to retain a memory of whether an admitted flow was white-
    listed or grey-listed at the time of its admission/readmission.

6.3.2. Combination of Conditional Access and Admission Control with

      Bandwidth Delegation
 The provisioning and bandwidth management procedures of Section 6.2.5
 apply in addition to the procedures in Sections 6.2.3, 6.2.4, or
 6.3.1 as applicable.  Conditional access follows the rules given in
 those sections in terms of matching flows against white and black
 and/or grey lists.  When admission control is enabled at the AN, the
 amount of bandwidth used by the AN is negotiable as described in
 Section 6.2.5.2.

6.3.3. Combination of NAS-Initiated Replication with Other Capabilities

 NAS-initiated multicast replication can coexist with the other
 capabilities, but some means must exist to prevent double replication
 of flows.  The simplest way to do this is to terminate all IGMP/MLD
 requests on the AN, so that NAS-initiated multicast replication is
 stimulated only by signaling 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 multicast replication and the
 other multicast capabilities is in the area of admission control.
 Specifically, if the AN is to do admission control for flows added by
 Multicast Replication Control messages, regardless of whether they
 are part of NAS-initiated replication or grey list multicast service
 processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning
 message and the Bandwidth-Allocation TLV in a Port Management
 message.  If, instead, the NAS will do admission control for flows
 added by Multicast Replication Control messages, regardless of
 whether they are part of NAS-initiated replication or grey list
 multicast service processing, it does not send the MRepCtl-CAC TLV in

Le Faucheur, et al. Standards Track [Page 65] RFC 7256 ANCP Multicast Extensions July 2014

 a Provisioning message to the AN.  The NAS can independently enable
 admission control for white flows on the AN by including the White-
 List-CAC TLV in the Provisioning message.

6.3.4. Combinations of Committed Bandwidth Reporting with Other

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

7. Miscellaneous Considerations

 This section deals with two sets of considerations.  "Report
 Buffering Considerations" considers requirements for configuration in
 support of some of the committed bandwidth reporting capability.
 "Congestion Considerations" is a warning to implementors about the
 possibility of control-plane congestion, with suggestions for
 mitigation.

7.1. Report Buffering Considerations

 The committed bandwidth reporting capability allows the provisioning
 of a report buffering period to reduce the number of messages the AN
 passes to the NAS.  An appropriate value for this period, if
 buffering is allowed at all, depends first on the effect of delay in
 reporting bandwidth changes and secondly on the rate at which
 bandwidth changes are expected to occur.
 Let us assume, in the first instance, that a delay in adjusting
 hierarchical scheduling at the NAS causes additional bandwidth demand
 to be served momentarily on a best-effort basis, introducing the
 possibility of jitter and, more crucially, packet loss.  Appendix IV
 of ITU-T Recommendation G.1080 [ITU-T_G.1080] indicates that the
 maximum tolerable duration of a loss episode is less than 16 ms.
 This would more likely apply in the middle of a program rather than
 when it was starting up but at least gives an (extremely
 conservative) order of magnitude for setting the buffering period.
 The next question is whether enough messaging is likely to be
 generated that multiple bandwidth changes would be observed within
 such an interval.  Let us consider a reasonable example in a DSL
 environment, where during the busiest hour of the day subscribers
 start watching at the rate of one program per subscriber per hour.

Le Faucheur, et al. Standards Track [Page 66] RFC 7256 ANCP Multicast Extensions July 2014

 Typically, because of program scheduling, the new channel requests
 might be concentrated within a three-minute period, giving an
 effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second)
 * 16 ms = 0.00009 requests per buffering interval of 16 ms.  With
 these figures, an AN serving 10,000 subscribers will report an
 average of 0.9 bandwidth changes per 16 ms buffering interval.  It
 appears that buffering is worthwhile only for larger-scale
 deployments.
 Note that simple replacement of one channel with another -- channel
 surfing -- does not require reporting or adjustment at the NAS end.

7.2. Congestion Considerations

 Implementors must beware of the possibility that a single channel-
 surfing subscriber could generate enough control messaging to
 overload the AN or the messaging channel between the AN and the NAS.
 The implementation problem is to strike the right balance between
 minimizing the processing of requests that have been overtaken by
 subsequent events and meeting requirements for what is termed
 "channel zapping delay".  Nominally, such a requirement is to be
 found in Section 8.1 of [ITU-T_G.1080], but unfortunately no
 quantitative value was available at the time of publication of this
 document.  Implementors will therefore have to base their work on
 discussions with customers until standardized requirements become
 available.  (It is possible that regional bodies or more specialized
 bodies have overtaken the ITU-T in this regard.)
 A typical strategy for minimizing the work associated with request
 processing includes deliberate buffering of join requests for a short
 period in case matching Release requests are detected, followed by
 discard of both requests.  More generally, processing of requests
 from individual subscribers may be rate limited, and the global rate
 of messaging to the NAS can also be limited.  If the AN gets
 overloaded, deliberate dropping of stale requests can be implemented,
 for some definitions of "stale".

8. Security Considerations

 The security considerations of ANCP are discussed in [RFC6320] and in
 [RFC5713].  Multicast does not, in principle, introduce any new
 security considerations, although it does increase the attractiveness
 of ANCP as a means of denial of service (e.g., through direction of
 multicast streams onto the target) or theft of service.
 As mentioned in Section 4.4, the inclusion of the Request-Source-MAC
 TLV or Request-Source-IP TLV in the Multicast Admission Control
 message presents privacy issues.  An attacker able to get access to

Le Faucheur, et al. Standards Track [Page 67] RFC 7256 ANCP Multicast Extensions July 2014

 the contents of this message would, like the content provider, be
 able to track consumption of multicast content to the individual
 device and potentially to individual persons if they are associated
 with particular devices.  To make the connection between devices and
 individuals, the attacker needs to get information from sources other
 than ANCP, of course, but let us assume that this has happened.
 The protection specified for ANCP in [RFC6320] will apply to the
 transmission of the Multicast Admission Control message across the
 access network to the NAS.  Hence, the attacker's potential points of
 access are between the subscriber and the AN, at the AN and at the
 NAS.  Moreover, if the MAC or IP address are transmitted onwards from
 the NAS to AAA in a request for policy, that whole onward path has to
 be examined for vulnerability.
 The question is how many of these potential points of attack can be
 eliminated through operational practice.  The segment from the
 subscriber through the AN itself seems out of the scope of this
 discussion -- protection of this segment is basic to subscriber
 privacy in any event and likely a business requirement.  The segment
 from the AN to the NAS is covered by the basic ANCP protection
 specified in [RFC6320].  This leaves the NAS and the path between the
 NAS and AAA for consideration.
 The operator can eliminate the path between the NAS and AAA as a
 point where the attacker can access per-device information by
 downloading per-device policy to the NAS for all identified user
 devices for the particular subscriber.  The NAS then selects the
 applicable policy based on the particular device identifier it has
 received.  This is as opposed to the NAS sending the identifier of
 the device in question to AAA and getting policy just for that
 device.
 The alternative is to protect the path between the NAS and AAA.  If
 Diameter is used as the AAA protocol, Section 2.2 of [RFC6733]
 mandates use of IPsec, TLS/TCP, or DTLS/SCTP for that purpose.  If
 RADIUS is used, the operator should deploy TLS transport as specified
 in [RFC6614].
 This leaves the NAS itself as a point of attack.  In theory, the NAS
 could be eliminated if the AN remapped the requesting MAC or IP
 address to an identifier known to itself and AAA but not the NAS.
 This would require local configuration on the AN, which may be
 possible under some circumstances.  The Request-Source-Device-Id TLV
 specified in Section 5.11 is available to transmit such an identifier
 in place of the Request-Source-MAC TLV or Request-Source-IP TLV.

Le Faucheur, et al. Standards Track [Page 68] RFC 7256 ANCP Multicast Extensions July 2014

9. IANA Considerations

 This document defines the following additional values within the
 "ANCP Message Types" registry:
     +--------------+--------------------------------+-----------+
     | Message Type | Message Name                   | Reference |
     +--------------+--------------------------------+-----------+
     | 144          | Multicast Replication Control  | RFC 7256  |
     |              |                                |           |
     | 145          | Multicast Admission Control    | RFC 7256  |
     |              |                                |           |
     | 146          | Bandwidth Reallocation Request | RFC 7256  |
     |              |                                |           |
     | 147          | Bandwidth Transfer             | RFC 7256  |
     |              |                                |           |
     | 148          | Delegated Bandwidth Query      | RFC 7256  |
     |              |                                |           |
     | 149          | Multicast Flow Query           | RFC 7256  |
     |              |                                |           |
     | 150          | Committed Bandwidth Report     | RFC 7256  |
     +--------------+--------------------------------+-----------+
 This document defines the following additional values for the "ANCP
 Result Codes" registry.  In support of these assignments, IANA has
 changed the lower limit of 0x100 specified by [RFC6320] for
 assignments by IETF Consensus to 0x64.
 +------------+------------------------------------------+-----------+
 | Result     | One-Line Description                     | Reference |
 | Code       |                                          |           |
 +------------+------------------------------------------+-----------+
 | 0x64       | Command error.                           | RFC 7256  |
 |            |                                          |           |
 | 0x65       | Invalid flow address.                    | RFC 7256  |
 |            |                                          |           |
 | 0x66       | Multicast flow does not exist.           | RFC 7256  |
 |            |                                          |           |
 | 0x67       | Invalid preferred bandwidth amount.      | RFC 7256  |
 |            |                                          |           |
 | 0x68       | Inconsistent views of delegated          | RFC 7256  |
 |            | bandwidth amount.                        |           |
 |            |                                          |           |
 | 0x69       | Bandwidth request conflict.              | RFC 7256  |
 +------------+------------------------------------------+-----------+

Le Faucheur, et al. Standards Track [Page 69] RFC 7256 ANCP Multicast Extensions July 2014

 This document defines the following additional values for the "ANCP
 Command Codes" registry:
 +----------------+--------------------------------------+-----------+
 | Command Code   | Command Code Directive Name          | Reference |
 | Value          |                                      |           |
 +----------------+--------------------------------------+-----------+
 | 1              | Add                                  | RFC 7256  |
 |                |                                      |           |
 | 2              | Delete                               | RFC 7256  |
 |                |                                      |           |
 | 3              | Delete All                           | RFC 7256  |
 |                |                                      |           |
 | 4              | Admission Control Reject             | RFC 7256  |
 |                |                                      |           |
 | 5              | Conditional Access Reject            | RFC 7256  |
 |                |                                      |           |
 | 6              | Admission Control and Conditional    | RFC 7256  |
 |                | Access Reject                        |           |
 +----------------+--------------------------------------+-----------+

Le Faucheur, et al. Standards Track [Page 70] RFC 7256 ANCP Multicast Extensions July 2014

 This document defines the following additional values within the
 "ANCP TLV Types" registry:
      +-----------+--------------------------------+-----------+
      | Type Code | TLV Name                       | Reference |
      +-----------+--------------------------------+-----------+
      | 0x0013    | Multicast-Service-Profile      | RFC 7256  |
      |           |                                |           |
      | 0x0015    | Bandwidth-Allocation           | RFC 7256  |
      |           |                                |           |
      | 0x0016    | Bandwidth-Request              | RFC 7256  |
      |           |                                |           |
      | 0x0018    | Multicast-Service-Profile-Name | RFC 7256  |
      |           |                                |           |
      | 0x0019    | Multicast-Flow                 | RFC 7256  |
      |           |                                |           |
      | 0x0021    | List-Action                    | RFC 7256  |
      |           |                                |           |
      | 0x0022    | Sequence-Number                | RFC 7256  |
      |           |                                |           |
      | 0x0024    | White-List-CAC                 | RFC 7256  |
      |           |                                |           |
      | 0x0025    | MRepCtl-CAC                    | RFC 7256  |
      |           |                                |           |
      | 0x0092    | Request-Source-IP              | RFC 7256  |
      |           |                                |           |
      | 0x0093    | Request-Source-MAC             | RFC 7256  |
      |           |                                |           |
      | 0x0094    | Report-Buffering-Time          | RFC 7256  |
      |           |                                |           |
      | 0x0095    | Committed-Bandwidth            | RFC 7256  |
      |           |                                |           |
      | 0x0096    | Request-Source-Device-Id       | RFC 7256  |
      +-----------+--------------------------------+-----------+

Le Faucheur, et al. Standards Track [Page 71] RFC 7256 ANCP Multicast Extensions July 2014

 This document defines the following additional values for the "ANCP
 Capability Types" registry:
 +-------+-------------------------+--------+------------+-----------+
 | Value | Capability Type Name    | Tech   | Capability | Reference |
 |       |                         | Type   | Data?      |           |
 +-------+-------------------------+--------+------------+-----------+
 | 3     | NAS-Initiated Multicast | 0      | No         | RFC 7256  |
 |       | Replication             |        |            |           |
 |       |                         |        |            |           |
 | 5     | Committed Bandwidth     | 0      | No         | RFC 7256  |
 |       | Reporting               |        |            |           |
 |       |                         |        |            |           |
 | 6     | Conditional Access and  | 0      | No         | RFC 7256  |
 |       | Admission Control with  |        |            |           |
 |       | White and Black Lists   |        |            |           |
 |       |                         |        |            |           |
 | 7     | Conditional Access and  | 0      | No         | RFC 7256  |
 |       | Admission Control with  |        |            |           |
 |       | Grey Lists              |        |            |           |
 |       |                         |        |            |           |
 | 8     | Bandwidth Delegation    | 0      | No         | RFC 7256  |
 +-------+-------------------------+--------+------------+-----------+

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 Multicast Flow Reporting
 solution.  Philippe Champagne, Sanjay Wadhwa, and Stefaan De Cnodder
 provided substantial contributions on the solution for the NAS-
 initiated multicast control use case.  Kristian Poscic provided the
 committed bandwidth reporting use case.
 Thanks to the Document Shepherd, Matthew Bocci, and Area Director,
 Ted Lemon, for points raised by their reviews following Working Group
 Last Call.
 Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg
 for their reviews on behalf of the Security, Operations, and Gen-Art
 directorates.  Dacheng's comments led to changes at several points in
 the document, while Mehmet's led to creation of the Miscellaneous
 Considerations section.  Finally, thanks to Brian Haberman for
 stimulating a review of the architectural assumptions and their
 relationship to the ability of user devices to obtain access to non-
 IPTV multicast services.  This also led to changes in the document.

Le Faucheur, et al. Standards Track [Page 72] RFC 7256 ANCP Multicast Extensions July 2014

11. References

11.1. Normative References

 [PIMreg]   IANA, "Protocol Independent Multicast (PIM) Parameters",
            <http://www.iana.org/assignments/pim-parameters>.
 [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.
 [RFC5790]  Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
            Group Management Protocol Version 3 (IGMPv3) and Multicast
            Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
            February 2010.
 [RFC6320]  Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
            Taylor, "Protocol for Access Node Control Mechanism in
            Broadband Networks", RFC 6320, October 2011.

11.2. Informative References

 [IEEE48]   IEEE, "Guidelines for 48-Bit Global Identifier",
            <http://standards.ieee.org/regauth/oui/tutorials/
            EUI48.html>.
 [IEEE64]   IEEE, "Guidelines for 64-Bit Global Identifier",
            <http://standards.ieee.org/regauth/oui/tutorials/
            EUI64.html>.
 [ITU-T_G.1080]
            ITU-T, "Quality of experience requirements for IPTV
            services", ITU-T Recommendation G.1080, December 2008.
 [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
            2", RFC 2236, November 1997.

Le Faucheur, et al. Standards Track [Page 73] RFC 7256 ANCP Multicast Extensions July 2014

 [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
            "Protocol Independent Multicast - Sparse Mode (PIM-SM):
            Protocol Specification (Revised)", RFC 4601, August 2006.
 [RFC5713]  Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
            Threats and Security Requirements for the Access Node
            Control Protocol (ANCP)", RFC 5713, January 2010.
 [RFC5851]  Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
            Wadhwa, "Framework and Requirements for an Access Node
            Control Mechanism in Broadband Multi-Service Networks",
            RFC 5851, May 2010.
 [RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
            "Transport Layer Security (TLS) Encryption for RADIUS",
            RFC 6614, May 2012.
 [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
            "Diameter Base Protocol", RFC 6733, October 2012.

Le Faucheur, et al. Standards Track [Page 74] RFC 7256 ANCP Multicast Extensions July 2014

Appendix A. Example of Messages and Message Flows

 This appendix provides an example in which most of the possible
 message flows for multicast control are illustrated.  This appendix
 is for informational purposes only.  In case of discrepancy with text
 in the body of this document, the text in the body of the document is
 to be considered as the normative text.
 Assume the following, for a given access port:
 o  The basic subscribed service is white-listed.  The AN will be
    responsible for admission control for this service.
 o  Some premium services are available, but requests for these
    services must be referred to the Policy Server for proper credit
    processing.  For this reason, they are grey-listed.  The NAS will
    be responsible for admission control for these services.
 o  The subscriber has asked that certain services be blocked so that
    his children cannot view them.  These services are black-listed.
 o  All of the above services are Source-Specific Multicast (SSM).  In
    addition, by means that bypass the AN, the subscriber can signal
    intent to join an on-line game service that is Any-Source
    Multicast (ASM).  The NAS is responsible for admission control for
    this service.
 o  Bandwidth delegation is, in effect, to share video bandwidth
    between the AN and the NAS.
 The stated conditions require the use of four of the five
 capabilities specified in this memo.

A.1. Provisioning Phase

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

Le Faucheur, et al. Standards Track [Page 75] RFC 7256 ANCP Multicast Extensions July 2014

 o  Message Type is 93.
 o  The Result and Result Code fields in the header are set to zeroes,
    as specified [RFC6320].
 o  A Transaction Identifier is assigned by the NAS.
 o  The Multicast-Service-Profile TLV (of which typically there would
    be multiple instances) contains a Multicast-Service-Profile-Name
    TLV (with a length of 20 octets assumed for the example) and three
    List-Action TLVs, one each for the white, grey, and black lists
    within the profile.  The white list flows come in two sets of
    group addresses: 233.252.0.0/29, coming from a server at
    192.0.2.15, and 233.252.0.32/29, coming from a server at
    192.0.2.16.  The grey-listed flows are in the band
    233.252.0.64/29, coming from a server at 192.0.2.21.  Finally, the
    black list flows are two individual flows that happen to overlap
    with the grey list band: 233.252.0.65 and 233.252.0.69, also with
    source 192.0.2.21.
 o  The White-List-CAC TLV indicates that the AN does admission
    control on white-listed flows.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 132        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type = 93 | Res=0 |    Result Code = 0    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |       Length = 132            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Mcast-Service-Profile  0x0013 |       TLV Length = 112        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Mcast-Svc-Profile-Name 0x0018 |  Embedded TLV Length = 20     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Multicast service profile name               |
 ~                  = "Cust 0127-53681-0003"                     ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = List-Action 0x0021 |   Embedded TLV Length = 28    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Operation = 1 | List Type = 1 |        Reserved = 0x0000      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Address Family = 1         |       List Length = 20        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Faucheur, et al. Standards Track [Page 76] RFC 7256 ANCP Multicast Extensions July 2014

 | G PrefLen = 29| S PrefLen = 32| Group prefix =                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      233.252.0.0              | Source prefix =               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      192.0.2.15               | G PrefLen = 29| S PrefLen = 32|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Group prefix = 233.252.0.32                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Source prefix = 192.0.2.16                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = List-Action 0x0021 |   Embedded TLV Length = 18    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Operation = 1 | List Type = 3 |        Reserved = 0x0000      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Address Family = 1         |       List Length = 10        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | G PrefLen = 29| S PrefLen = 32| Group prefix =                /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /      233.252.0.64             | Source prefix =               /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /      192.0.2.21               |   Padding = 0x0000            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = List-Action 0x0021 |   Embedded TLV Length = 28    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Operation = 1 | List Type = 2 |        Reserved = 0x0000      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Address Family = 1         |       List Length = 20        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | G PrefLen = 32| S PrefLen = 32| Group prefix =                /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /      233.252.0.65             | Source prefix =               /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /      192.0.2.21               | G PrefLen = 32| S PrefLen = 32|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Group prefix = 233.252.0.69                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Source prefix = 192.0.2.21                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = White-List-CAC  0x0024 |          TLV Length = 0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 22: Example Provisioning Message
 Note that the padding after the middle List-Action TLV is counted as
 part of the length of the Multicast-Service-Profile TLV but is not
 included in the length of that List-Action TLV.  Note also that the
 Length field in the message header, unlike those in the TLVs,
 includes the message header itself, as required by [RFC6320].

Le Faucheur, et al. Standards Track [Page 77] RFC 7256 ANCP Multicast Extensions July 2014

 Finally, note that the Provisioning message does not include a
 MRepCtl-CAC TLV since in our example admission control for grey-
 listed flows and for NAS-initiated replication is performed by the
 NAS.
 As soon as the AN port comes up, the AN sends an ANCP PORT_UP message
 to the NAS specifying the Access Loop Circuit ID.  The NAS replies
 with an ANCP Port Management message that, together with the other
 parameters, includes the multicast service profile name to be
 associated to that port along with the initial amount of delegated
 bandwidth.  The corresponding message flow is illustrated in
 Figure 23.
  +----------+      +---------+         +-----+               +-----+
  |Subscriber|      |  Home   |         | AN  |               | NAS |
  +----------+      | Gateway |         +-----+               +-----+
       |            +---------+            |                     |
       |                 |                 |                     |
       |                 |                 |                     |
       |                 |   DSL Synch.    |                     |
       |                 |---------------->|                     |
       |                 |                 |(M1)PORT_UP(Port ID) |
       |                 |                 |-------------------->|
       |                 |                 |                    (*)
       |                 |                 |(M2) PORT_MNGT       |
       |                 |                 |    (Port ID,        |
       |                 |                 |Mcast S Profile Name,|
       |                 |                 |Bandwidth Allocation)|
       |                 |                 |<--------------------|
 (*) The NAS may optionally seek direction from an external
     Authorization/Policy Server
  Figure 23: Configuring an AN Port with Multicast Service Profile ID
                    and Delegated Bandwidth Amount
 The Port Management message will typically contain other TLVs, but
 our example (Figure 24) just shows the Target, Multicast-Service-
 Profile-Name, and Bandwidth-Allocation TLVs.  The Target TLV
 identifies the subscriber line, the Multicast-Service-Profile-Name
 TLV is identical to the one contained in the Provisioning message,
 and the Bandwidth-Allocation TLV provides just enough bandwidth (2000
 kbits/s) for one channel to start with.
 The following fields in the Port Management message header are shown
 with specific values either as directed by the base protocol document
 or for the sake of our example:

Le Faucheur, et al. Standards Track [Page 78] RFC 7256 ANCP Multicast Extensions July 2014

 o  Message Type is 32.
 o  Result is set to Nack (0x1) for this example.
 o  Result Code is 0.
 o  A Transaction Identifier is assigned by the NAS.
 o  Port is set to 0.
 o  Event Sequence Number, the R flag and the other bits marked x,
    Duration, the Event Flags, and the Flow Control Flags are all
    irrelevant for this function and are set to 0.
 o  Function is set to "Configure Connection Service Data" (8).
 o  X-Function is set to 0.
 o  Tech Type is "DSL" (5).
 o  Block lengths are calculated assuming a Circuit-Id length of 4 in
    our example.  Recall that the example Multicast-Service-Profile-
    Name TLV length is 20.

Le Faucheur, et al. Standards Track [Page 79] RFC 7256 ANCP Multicast Extensions July 2014

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 84         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type = 32 | Res=1 |    Result Code = 0    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 84         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Port = 0                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Port Session Number                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Event Sequence Number = 0                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|x|x|x|x|x|x|x| Duration = 0  | Function = 0x8| X-Function = 0|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Event Flags         |        Flow Control Flags     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |x|x|x|x|x|x|x|x| Msg Type = 32 |  Tech Type=5  | Blk Len = 56  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     # of TLVs = 3             | Extension Block length = 44   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Mcast-Svc-Profile-Name 0x0018 |       TLV Length = 20         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Multicast service profile name               |
 ~                  = "Cust 0127-53681-0003"                     ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Bandwidth-Allocation  0x0015 |       TLV Length = 4          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Bandwidth value = 2000 (kbits/s)               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 24: Example Port Management Message

Le Faucheur, et al. Standards Track [Page 80] RFC 7256 ANCP Multicast Extensions July 2014

A.2. Handling Grey-Listed Flows

 Suppose now that the subscriber chooses to watch the premium channel
 characterized by source 192.0.2.21, group 233.252.0.67.  Upon
 receiving the join request, the AN matches it against the multicast
 service profile for the port and determines that it is a grey-listed
 flow.  Figure 25 illustrates the resulting ANCP message flow for the
 case of a simple join and leave, when admission control for grey-
 listed flows is not activated on the AN.
 To start the flow, the AN sends a Multicast Admission Control message
 (M1) to the NAS.  The NAS decides whether the flow can be admitted,
 applying both policy and bandwidth criteria.  It returns its decision
 (positive in this example) in a Multicast Replication Control message
 (M2).  Later, when the subscriber leaves the flow, the AN informs the
 NAS by sending another Multicast Admission Control message.
 +----------+    +-------+   +-----+    ANCP    +-----+
 |Subscriber|    | Home  |   | AN  |<---------->| NAS |
 +----------+    |Gateway|   +-----+            +-----+
       |         +-------+     |                   |
       |           |           |     Multicast     |
       |      Join(Grey-Fl)    |     Admission     |
       |-----------+---------->|      Control (M1) |
       |           |           |------------------>|
       |           |           |                   |  (NAS performs
       |           |           |     Multicast     |   admission
       |           |           |     Replication  (*)  control)
       |           |           |     Control (M2)  |
       |     Mcast Grey Flow   |<------------------|
       |<======================+                   |
       |           |           |                   |
       ~           ~           ~                   ~
       |           |           |     Multicast     |
       |     Leave(Grey-Fl)    |     Admission     |
       |-----------+---------->|      Control (M3) |
       |           |           |------------------>|
       |           |           |                   |
 Grey-Fl: multicast flow matching an entry in grey list
 (*) The NAS may optionally seek direction from an external
 Authorization/Policy Server.
     Figure 25: Successful Join/Leave Operations, Grey-Listed Flow

Le Faucheur, et al. Standards Track [Page 81] RFC 7256 ANCP Multicast Extensions July 2014

 The Multicast Admission Control message M1 contains:
 o  an ANCP Header with:
  • Message Type is 145;
  • Result = Ignore (0x0); and
  • a Transaction Identifier assigned by the AN.
 o  a Target TLV identifying the AN Port
 o  a Command TLV containing:
  • Command Code = "Add" (1);
  • Accounting = "No" (0);
  • a Multicast-Flow embedded TLV indicating the multicast flow for

which the AN received the IGMP join: flow type "SSM" (2),

       address family "IPv4" (1), Group address = 233.252.0.67, Source
       Address = 192.0.2.21; and
  • a Request-Source-Device-Id embedded TLV containing the IGMP

join source local device identifier value 5.

Le Faucheur, et al. Standards Track [Page 82] RFC 7256 ANCP Multicast Extensions July 2014

 The Multicast Admission Control message M1 is illustrated in
 Figure 26:
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 98         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=145  | Res=0 |    Result Code = 0    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 98         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Command     0x0011 |       TLV Length = 28         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Cmd Code = 1 |   Acctg = 0   |      Reserved = 0x0000        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = Multicast-Flow  0x0019 |   Embedded TLV Length = 12    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Flow Type = 2 |  Addr Fam = 1 |     Reserved = 0x0000         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Multicast Group Address = 233.252.0.67            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Unicast Source Address =  192.0.2.21            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
 |Request-Source-Device-Id 0x0092|   Embedded TLV length = 4     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Value = 5                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 26: Multicast Admission Control Message Seeking to Add a Flow
 The Multicast Replication Control message M2 contains:
 o  an ANCP Header with:
  • Message Type = "Multicast Replication Control" (144);
  • Result= 0x1 (Nack); and
  • a Transaction Identifier assigned by the NAS;

Le Faucheur, et al. Standards Track [Page 83] RFC 7256 ANCP Multicast Extensions July 2014

 o  a Target TLV identifying the AN Port
 o  a Command TLV containing:
  • Command Code = "Add" (1);
  • Accounting = "Yes" (1), since in our example the operator wants

accounting on this flow; and

  • a Multicast-Flow embedded TLV indicating the multicast flow

that the NAS is admitting for this access line: flow type "SSM"

       (2), address family "IPv4" (1), Group address = 233.252.0.67,
       Source Address = 192.0.2.21.
 The Multicast Admission Control message M2 is illustrated in
 Figure 27.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 48         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=144  | Res=1 |    Result Code =  0   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 48         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Target          Type = 0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Command     0x0011 |       TLV Length = 20         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Cmd Code = 1 |   Acctg = 1   |      Reserved = 0x0000        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = Multicast-Flow  0x0019 |   Embedded TLV Length = 12    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Flow Type = 2 |  Addr Fam = 1 |     Reserved = 0x0000         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Multicast Group Address = 233.252.0.67            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Unicast Source Address =  192.0.2.21            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 27: Multicast Replication Control Message Admitting a Flow

Le Faucheur, et al. Standards Track [Page 84] RFC 7256 ANCP Multicast Extensions July 2014

 The Multicast Admission Control message M3 advising the NAS that the
 flow has been terminated contains:
 o  an ANCP Header with:
  • Message Type is 145;
  • Result = Ignore (0x0); and
  • a Transaction Identifier assigned by the AN.
 o  a Target TLV identifying the access line
 o  a Command TLV containing:
  • a Command Code = "Delete" (2);
  • Accounting = "No" (0);
  • a Multicast-Flow embedded TLV indicating the multicast flow for

which the AN received the IGMP leave: flow type "SSM" (2),

       address family "IPv4" (1), Group address = 233.252.0.67, Source
       Address = 192.0.2.21; and
  • a Request-Source-Device-Id embedded TLV containing the IGMP

leave request source, the device identified by the local value

       5.

Le Faucheur, et al. Standards Track [Page 85] RFC 7256 ANCP Multicast Extensions July 2014

 The Multicast Admission Control message M3 is illustrated in
 Figure 28.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=145  | Res=0 |    Result Code = 0    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Command     0x0011 |       TLV Length = 28         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Cmd Code = 2 |    Acctg = 0  |      Reserved = 0x0000        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Multicast-Flow  Type = 0x0019 |   Embedded TLV Length = 12    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Flow Type = 2 |  Addr Fam = 1 |     Reserved = 0x0000         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Multicast Group Address = 233.252.0.67            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Unicast Source Address =  192.0.2.21            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Request-Source-Device-Id 0x0092|   Embedded TLV length = 4     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Value = 5                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Figure 28: Multicast Admission Control Message Signaling Flow
                              Termination

Le Faucheur, et al. Standards Track [Page 86] RFC 7256 ANCP Multicast Extensions July 2014

A.3. Handling White-Listed Flows

 The NAS has enabled white list admission control on the AN, and the
 bandwidth delegation capability has been negotiated.  White-listed
 flows in themselves require no messages to the NAS, either upon
 admission or upon termination, but the AN may request an increase in
 the amount of delegated bandwidth if it needs the increase to admit a
 flow.
 Consider an example where the AN has already admitted one white-
 listed flow, thereby using up the initially provisioned amount of
 delegated bandwidth (2000 kbits/s).  A request is received to join a
 new flow in the white list range.  The AN chooses to send a Bandwidth
 Reallocation Request message to the NAS, requesting that the
 delegated bandwidth allocation be increased to 4000 kbits/s at a
 minimum and preferably to 6000 kbits/s.
 In our example, the NAS is managing bandwidth tightly, as witnessed
 by its minimal initial allocation of just enough for one flow.  It is
 willing to provide the minimum additional amount only and therefore
 returns a Bandwidth Transfer message where the delegated bandwidth
 value is given as 4000 kbits/s.  With this amount, the AN is able to
 admit the second white-listed flow.  The AN could send a similar
 Bandwidth Transfer message back to the NAS bringing the delegated
 bandwidth amount back down to 2000 kbits/s when one of the flows is
 terminated, but this shows nothing new and is omitted.
 As one more point of illustration, suppose that the NAS chooses to
 audit the current amount of delegated bandwidth to ensure it is
 synchronized with the AN.  It sends a Delegated Bandwidth Query
 Request message to the AN and receives a Delegated Bandwidth Query
 Response message with the current allocation as the AN sees it.
 The complete message flow is shown in Figure 29.

Le Faucheur, et al. Standards Track [Page 87] RFC 7256 ANCP Multicast Extensions July 2014

 +----------+    +-------+   +-----+    ANCP    +-----+
 |Subscriber|    | Home  |   | AN  |<---------->| NAS |
 +----------+    |Gateway|   +-----+            +-----+
       |         +-------+     |                   |
       |           |           |                   |
       |      Join(White-F1)   |                   |
       |-----------+---------->|                   |
       |           |           |AN performs        |
       |  Mcast White Flow 1   | admission control |
       |<======================+                   |
       |           |           |                   |
       |      Join(White-F2)   |                   |
       |-----------+---------->|No bandwidth left  |
       |           |           |                   |
       |           |           |Bandwidth          |
       |           |           | Reallocation Req  |
       |           |           |------------------>|(M1)
       |           |           |                   |
       |           |           |                  (*)
       |           |           |Bandwidth Transfer |
       |           AN can now  |<------------------|(M2)
       |           admit flow  |                   |
       |   Mcast White Flow 2  |                   |
       |<======================+                   |
       |           |           |                   |
       ~           ~           ~                   ~
       |           |           |Delegated Bandwidth|
       |           |           | Query request     |
       |           |           |<------------------|(M3)
       |           |           |                   |
       |           |           |Delegated Bandwidth|
       |           |           | Query response    |
       |           |           |------------------>|(M4)
       |           |           |                   |
 (*) The NAS may optionally seek direction from an external
 Authorization/Policy Server.
    Figure 29: Successful Join/Leave Operations, White-Listed Flow

Le Faucheur, et al. Standards Track [Page 88] RFC 7256 ANCP Multicast Extensions July 2014

 The Bandwidth Reallocation Request message (M1) is shown in
 Figure 30.  The contents require little explanation.  The Message
 Type for the Bandwidth Reallocation Request is 146.  The Result field
 is set to Ignore (0x0).  Besides the Target TLV, the message has one
 other TLV, the Bandwidth-Request, with a TLV Type of 0x0016.  The TLV
 contains Required Amount and Preferred Amount fields, set to 4000 and
 6000 kbits/s respectively.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 36         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=146  | Res=0 |     Result Code = 0   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 36         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Bandwidth-Request    0x0016 |          TLV Length = 8       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Required Amount = 4000 (kbits/s)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Preferred Amount = 6000 (kbits/s)               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 30: Bandwidth Reallocation Request Message

Le Faucheur, et al. Standards Track [Page 89] RFC 7256 ANCP Multicast Extensions July 2014

 The Bandwidth Transfer message (M2) is shown in Figure 31.  Again,
 the contents are easily understood.  The Message Type for the
 Bandwidth Transfer message is 147.  The Result field is set to
 Success (0x3).  The message contains the Target TLV and the
 Bandwidth-Allocation TLV.  The latter has a TLV Type of 0x0015 and
 contains a Delegated Amount field, set to 4000 kbits/s.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 32         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=147  | Res=3 |     Result Code = 0   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 32         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Bandwidth-Allocation  0x0015 |          TLV Length = 4       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Delegated Amount = 4000 (kbits/s)              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 31: NAS Response, Bandwidth Transfer Message

Le Faucheur, et al. Standards Track [Page 90] RFC 7256 ANCP Multicast Extensions July 2014

 The Delegated Bandwidth Query Request message (M3) is shown in
 Figure 32.  The Message Type for the Delegated Bandwidth Query
 request message is 148.  The Result field is set to AckAll (0x2).
 The message contains the Target TLV only.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 24         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=148  | Res=2 |     Result Code = 0   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 24         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Figure 32: Delegated Bandwidth Query Request Message

Le Faucheur, et al. Standards Track [Page 91] RFC 7256 ANCP Multicast Extensions July 2014

 Finally, the Delegated Bandwidth Query Response message (M4) is shown
 in Figure 33.  The Message Type for the Delegated Bandwidth Query
 response message is 148.  The Result field is set to Success (0x3).
 The message contains the Target TLV and the Bandwidth-Allocation TLV
 with the Delegated Amount field set to 4000 kbits/s.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 32         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=148  | Res=3 |     Result Code = 0   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  | Transaction Identifier (copied from request)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 32         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Bandwidth-Allocation  0x0015 |          TLV Length = 4       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Delegated Amount = 4000 (kbits/s)              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Figure 33: Delegated Bandwidth Query Response Message

A.4. Handling of Black-Listed Join Requests

 This section introduces no new messages, since requests for flows in
 the black list are simply ignored.  The one thing to point out is the
 overlap in our example between the set of flows in the grey list and
 the flows in the black list.  This does not create any ambiguity,
 since not only does the black list have priority for equally good
 matches, but also the black list entries are more specific (group
 prefix lengths of 32 versus 29 in the grey list) than the grey list
 flow prefixes.

A.5. Handling of Requests to Join and Leave the On-Line Game

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

Le Faucheur, et al. Standards Track [Page 92] RFC 7256 ANCP Multicast Extensions July 2014

 When the subscriber requests to join the game, the NAS (after
 applying policy and bandwidth checks) sends a Multicast Replication
 Control message to the AN to enable the flow on the port concerned.
 The AN knows not to apply admission control, since it has not
 received an MRepCtl-CAC TLV in the Provisioning message.  When the
 subscriber leaves, the NAS sends another Multicast Replication
 Control message to delete the flow.  This message sequence is shown
 in Figure 34.
 It is possible that the NAS finds that there is not enough bandwidth
 available to accommodate the subscriber's request.  In this case, the
 NAS could send a Bandwidth Reallocation Request message to the AN,
 asking it to release some of the bandwidth delegated to it.  This is
 not shown in the present example, since the messages are the same as
 those already presented with the exception that the Preferred Amount
 in the request will be *less than* or equal to the Required amount,
 rather than *greater than* or equal to it.
 +----------+    +-------+   +-----+    ANCP    +-----+
 |Subscriber|    | Home  |   | AN  |<---------->| NAS |
 +----------+    |Gateway|   +-----+            +-----+
       |         +-------+     |                   |
       |           |           |                   |
       |      Join game        |                   |
       |-----------+------------------------------>|
       |           |           |     Multicast     |   NAS performs
       |           |           |     Replication  (*)  admission
       |           |           |     Control (M1)  |   control
       |     Mcast Game Flow   |<------------------|
       |<=====================>+                   |
       |           |           |                   |
       ~           ~           ~                   ~
       |           |           |                   |
       |     Leave game        |                   |
       |-----------+------------------------------>|
       |           |           |     Multicast     |
       |           |           |     Replication   |
       |           |           |     Control (M2)  |
       |     Mcast Game Flow   |<------------------|
       |       discontinued    |                   |
       |           |           |                   |
 (*) The NAS may optionally seek direction from an external
 Authorization/Policy Server.
           Figure 34: NAS-Initiated Flows for On-Line Gaming

Le Faucheur, et al. Standards Track [Page 93] RFC 7256 ANCP Multicast Extensions July 2014

 The Multicast Replication Control message (M1) in Figure 35 looks
 like the message in Figure 27 with two exceptions.  The first is that
 the NAS has the option to set the Result field to AckAll (0x02) if it
 needs positive reassurance that the flow has been enabled.  This was
 not done here to save having to depict a response differing only in
 the Result field.  The larger difference in this example is that the
 flow description in the Multicast-Flow embedded TLV is that of an ASM
 multicast group (Flow Type = 1) with IPv4 (1) group address
 233.252.0.100.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length = 44         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type=144  | Res=1 |     Result Code = 0   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length = 44         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length = 8  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length = 4  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Access Loop Circuit ID                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Command     0x0011 |       TLV Length = 16         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Cmd Code = 1 |   Acctg = 1   |      Reserved = 0x0000        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = Multicast-Flow  0x0019 |   Embedded TLV Length = 12    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Flow Type = 1 |  Addr Fam = 1 |     Reserved = 0x0000         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Multicast Group Address =  233.252.0.100           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
      Figure 35: Enabling the Subscriber to Join an On-Line Game
 Message M2 terminating the flow when the subscriber leaves the game
 looks the same as the message in Figure 35 with two exceptions: the
 Command Code becomes "Delete" (2), and Accounting is set to "No" (0)
 to turn off flow accounting.  Of course, the Transaction Identifier
 values will differ between the two messages.

Le Faucheur, et al. Standards Track [Page 94] RFC 7256 ANCP Multicast Extensions July 2014

A.6. Example Flow for Multicast Flow Reporting

 The example in this section is independent of the example in the
 preceding sections.
 Figure 36 illustrates a message flow in a case where the NAS queries
 the AN about which multicast flows are active on port 10, port 11,
 and port 20 of the AN.
 +----------+    +-------+   +-----+    ANCP    +-----+
 |Subscriber|    | Home  |   | AN  |<---------->| NAS |
 +----------+    |Gateway|   +-----+            +-----+
       |         +-------+     |                   |
       |             |         |  Multicast Flow   |
       |             |         |  Query Request    |
       |             |         |      (M1)         |
       |             |         |<------------------|
       |             |         |                   |
       |             |         | Multicast Flow    |
       |             |         | Query Response    |
       |             |         |      (M2)         |
       |             |         |------------------>|
       |             |         |                   |
       |             |         |                   |
             Figure 36: Per-Port Multicast Flow Reporting

Le Faucheur, et al. Standards Track [Page 95] RFC 7256 ANCP Multicast Extensions July 2014

 The Multicast Flow Query Request message (M1) is illustrated in
 Figure 37.  The Message Type is 149.  The Result field is set to
 AckAll (0x2).  Three Target TLVs are present, identifying port 10,
 port 20, and port 11, respectively.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type = 149| Res=2 |     Result Code = 0   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Access Loop Circuit ID (port10)            ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Access Loop Circuit ID (port20)            ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Access Loop Circuit ID (port11)            ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Figure 37: Multicast Flow Query Request Message for Per-Port
                       Multicast Flow Reporting

Le Faucheur, et al. Standards Track [Page 96] RFC 7256 ANCP Multicast Extensions July 2014

 The Multicast Flow Query Response message (M2) is illustrated in
 Figure 38.  It indicates that there is one active multicast flow
 [(192.0.2.1, 233.252.0.4)] on port 10, no active multicast flow on
 port 20, and two active multicast flows [(192.0.2.1, 233.252.0.4) and
 (192.0.2.2, 233.252.0.10)] on port 11.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type (0x880C)          |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version     | Msg Type = 149|Rslt=3 |    Result Code = 0    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |            Transaction Identifier             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |I|      SubMessage Number      |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                   Access Loop Circuit ID (port10)             ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = Multicast-Flow  0x0019 |    Embedded TLV Length = 12   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Flow Type = 2 |  Addr Fam = 1 |       Reserved = 0x0000       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Multicast Group Address = 233.252.0.4             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Unicast Source Address = 192.0.2.1             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
 | TLV Type = Target      0x1000 |        Target TLV Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                   Access Loop Circuit ID (port20)             ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | TLV Type = Target      0x1000 |        Target TLV Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Access Loop Circuit ID (port11)            ~
 |                                                               |

Le Faucheur, et al. Standards Track [Page 97] RFC 7256 ANCP Multicast Extensions July 2014

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = Multicast-Flow  0x0019 |    Embedded TLV Length = 12   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Flow Type = 2 |  Addr Fam = 1 |       Reserved = 0x0000       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Multicast Group Address = 233.252.0.4             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Unicast Source Address = 192.0.2.1             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
 | Type = Multicast-Flow  0x0019 |   Embedded TLV Length = 12    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Flow Type = 2 |  Addr Fam = 1 |       Reserved = 0x0000       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Multicast Group Address: 233.252.0.10             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Unicast Source Address = 192.0.2.2             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
     Figure 38: Multicast Flow Query Response Message for Per-Port
                       Multicast Flow Reporting

Le Faucheur, et al. Standards Track [Page 98] RFC 7256 ANCP Multicast Extensions July 2014

Authors' Addresses

 Francois Le Faucheur
 Cisco Systems
 45 Allee des Ormes
 Mougins  06250
 France
 Phone: +33 4 97 23 26 19
 EMail: flefauch@cisco.com
 Roberta Maglione
 Cisco Systems
 181 Bay Street
 Toronto, ON  M5J 2T3
 Canada
 EMail: robmgl@cisco.com
 Tom Taylor
 Huawei Technologies
 Ottawa
 Canada
 EMail: tom.taylor.stds@gmail.com

Le Faucheur, et al. Standards Track [Page 99]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7256.txt · Last modified: 2014/07/04 01:10 (external edit)