tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7256

 
 
 

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

Part 3 of 4, p. 51 to 72
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 51 
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);

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

Top      Up      ToC       Page 53 
   +--------------+----------------------------------------------------+
   | 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

Top      Up      ToC       Page 54 
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

Top      Up      ToC       Page 55 
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

Top      Up      ToC       Page 56 
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

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

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

Top      Up      ToC       Page 59 
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

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

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

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

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

Top      Up      ToC       Page 64 
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

Top      Up      ToC       Page 65 
   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

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

Top      Up      ToC       Page 67 
   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

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

Top      Up      ToC       Page 69 
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  |
   +------------+------------------------------------------+-----------+

Top      Up      ToC       Page 70 
   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                        |           |
   +----------------+--------------------------------------+-----------+

Top      Up      ToC       Page 71 
   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  |
        +-----------+--------------------------------+-----------+

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


Next RFC Part