tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7256

Proposed STD
Pages: 99
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ANCP

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

Part 1 of 4, p. 1 to 17
None       Next RFC Part

Updates:    6320


Top       ToC       Page 1 
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.

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

Top      ToC       Page 3 
           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

Top      ToC       Page 4 
           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

Top      ToC       Page 5 
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

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
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).

Top      ToC       Page 8 
      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.

Top      ToC       Page 9 
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

Top      ToC       Page 10 
   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

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
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

Top      ToC       Page 13 
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.

Top      ToC       Page 14 
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

Top      ToC       Page 15 
   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:

Top      ToC       Page 16 
   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.

Top      ToC       Page 17 
   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.



(page 17 continued on part 2)

Next RFC Part