Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7256

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

Pages: 99
Proposed Standard
Updates:  6320
Part 2 of 4 – Pages 17 to 51
First   Prev   Next

Top   ToC   RFC7256 - Page 17   prevText

4.3. Multicast Replication Control Message

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

   o  a Command Code field;

   o  an Accounting field; and

   o  an instance of the Multicast-Flow TLV.

   Figure 5 illustrates the complete Command TLV with the contents
   specific to the Multicast Replication Control message.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | TLV Type = Command     0x0011 |       Command TLV Length      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Command Code |  Accounting     |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Multicast-Flow TLV                        |
    |                           ...                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Other embedded TLV Type     |   Other embedded TLV Length   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                   Other embedded TLV data                     ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 5: Contents of the Command TLV in the Multicast Replication
                              Control Message
Top   ToC   RFC7256 - Page 19
   o  Command Code: One of the following command directives:

         1 "Add"

         2 "Delete"

         3 "Delete All"

         4 "Admission Control Reject"

         5 "Conditional Access Reject"

         6 "Admission Control and Conditional Access Reject"

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

   o  Accounting: Meaningful only when the Command Code is "Add" (1).
      In that case, 0 indicates flow accounting is disabled, and 1
      indicates that octet accounting for the flow is requested.  The
      sender MUST set the Accounting field to 0, and the receiver MUST
      ignore the Accounting field for other Command Code values.

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

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

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

   The figure below is an example of a Multicast Replication Control
   message that would result in a swap from multicast Source-Specific
   Multicast (SSM) flows 2001:DB8::1, FF34::2 to 2001:DB8::2, FF34::3 on
   the target identified by the Access Loop Circuit ID:
Top   ToC   RFC7256 - Page 20
                            1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Type (0x880C)          |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Version     |  MsgType=144  | Res=2 |   Result Code = 0     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Partition ID  |            Transaction Identifier = 18        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |I|      SubMessage Number      |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = Target   0x1000 |        Target TLV Length      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                    Access Loop Circuit ID                     ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = Command  0x0011 |     Command TLV Length = 44   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cmd Code = 2  |   Acctg = 0   |      Reserved = 0x0000        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type = Multicast-Flow  0x0019 |        TLV Length = 36        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Flow Type = 2 |  AddrFam = 2  |      Reserved = 0x0000        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                   Multicast Group Address                     ~
     |                          = FF34::2                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                         Source Address                        ~
     |                          = 2001:DB8::1                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TLV Type = Command  0x0011 |     Command-TLV Length = 44   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cmd Code = 1  |   Acctg = 1   |      Reserved = 0x0000        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type = Multicast-Flow  0x0019 |        TLV Length = 36        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Flow Type = 2 |  AddrFam = 2  |      Reserved = 0x0000        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                   Multicast Group Address                     ~
     |                          = FF34::3                            |
Top   ToC   RFC7256 - Page 21
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                         Source Address                        ~
     |                          = 2001:DB8::2                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 6: Example Change of Source Flow Using Multicast Replication
                              Control Message

4.3.1. Sender Behavior

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

4.3.2. Receiver Behavior

When successive commands (in the same or different messages) relate to the same target and multicast flow, the state of each feature controlled or affected by attributes received in the Multicast Replication Control message SHALL be as set by the last command or message referring to that target and flow and containing the controlling attribute. As an example, successive Multicast Replication Control messages containing add commands for a given port and flow but differing only in the Accounting field update the state
Top   ToC   RFC7256 - Page 22
   of the accounting feature to what is set in the final command
   received, but all other features are unaffected by the second
   message.

   If more than one Command TLV is present in a Multicast Replication
   Control message, the AN MUST act on the commands in the order in
   which they are presented in the message.  The AN SHALL assign a
   sequence number to each command in a given Multicast Replication
   Control message, starting from 1 for the first command.

   If a Command TLV adds one or more flows and the AN is performing
   admission control for Multicast Replication Control messages, then
   the AN MUST perform admission control before replicating the flows.
   If the admission control check fails, the AN MUST treat the failure
   as an error as described below.  The appropriate Result Code value
   for the response is 0x13 "Out of resources".

   If the AN processes the complete Multicast Replication Control
   message successfully and the Result field of the Multicast
   Replication Control message was set to AckAll (0x2), the AN MUST
   respond with a Generic Response message where the Result field is set
   to Success (0x3), the Result Code field is set to 0, and the
   Transaction Identifier field is copied from the Multicast Replication
   Control message.  The body of the response MAY be empty or MAY be
   copied from the Multicast Replication Control message.

   If the AN processes the complete Multicast Replication Control
   message successfully and the Result field of the Multicast
   Replication Control message was set to Nack (0x1), the AN MUST NOT
   respond to the message.

   The processing/execution of multiple commands contained in a single
   Multicast Replication Control message MUST be interrupted at the
   first error encountered and the remaining commands in the Multicast
   Replication Control message discarded.  Similarly, if a given command
   specifies multiple Single-Source Multicast (SSM) flows and an error
   occurs, processing MUST be interrupted at that point, and the
   remainder of the Command TLV discarded.

   If the AN detects an error in a received Multicast Replication
   Control message and the Result field in that message was set to Nack
   (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message
   providing error information to the NAS.  This specification
   identifies the following new Result Code values beyond those
   specified in [RFC6320], which MAY be used in a Generic Response sent
   in reply to a Multicast Replication Control message:
Top   ToC   RFC7256 - Page 23
   0x64  Command error.

         Where detected: ANCP agent at the AN.

         Further description: an invalid command code has been received.

         Required additional information in the message: see below.

         Target: ANCP agent at the NAS.

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

   0x65  Invalid flow address.

         Where detected: ANCP agent at the AN.

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

         Required additional information in the message: see below.

         Target: ANCP agent at the NAS.

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

   0x66  Multicast flow does not exist.

         Where detected: control application at the AN.

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

         Required additional information in the message: see below.

         Target: control application at the NAS.

         Action RECOMMENDED for the receiving ANCP agent: report the
         error to the control application with an indication of the
         erroneous information associated with the invalid TLV(s).
Top   ToC   RFC7256 - Page 24
   A Generic Response message responding to the Multicast Replication
   Control message and containing one of the above Result Code values
   MUST include a Status-Info TLV, which includes one or two embedded
   TLVs as follows:

   o  a Sequence-Number TLV as described in Section 5.4, giving the
      sequence number of the failed command, MUST be included; and

   o  the failed Command TLV itself SHOULD be included.

      Note: The Error Message field of the Status-Info TLV MAY be used
      to report more details than implied by the Result Code value in
      the message header.  For example, the Result Code value could be
      0x65, and the Error Message field could contain the text: "Source
      address present for ASM flow".

4.4. Multicast Admission Control Message

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

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

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

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

   o  Finally and preferably, a Request-Source-Device-Id TLV MAY be
      appended to the Command TLV as an additional embedded TLV.

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

4.4.1. Sender Behavior

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

   o  As a third alternative, the Request-Source-Device-Id embedded TLV
      MAY be included by the AN to convey a local identifier of the
      sender of the join/leave message (e.g., IGMP/MLD join/leave) that
      triggered the AN to include the corresponding Command TLV in the
      Multicast Admission Control message.  If it appears more than
      once, only the first instance is considered meaningful, and the
      other instances are ignored.

   The inclusion of Request-Source-IP or Request-Source-MAC in the
   Multicast Admission Control message is typically done to allow the
   application of policies applicable to specific devices within the
   customer's network.  However, transmission of either of these fields
   beyond the AN introduces potential privacy issues.  Instead of
   transmitting either of these identifiers, it is RECOMMENDED that the
   AN map the required identifier to a local value known to the AN and
   Authentication, Authorization, and Accounting (AAA) but not to the
   NAS, as discussed in Section 8.  The local identifier is transmitted
   using the Request-Source-Device-Id TLV.

4.4.2. Receiver Behavior

On receipt of a Multicast Admission Control message: o The NAS MUST ignore the Result field. o If the directive in the Multicast Admission Control message is "Delete" (2) or "Delete All" (3) and is processed correctly by the NAS, the NAS MUST NOT generate any ANCP message in response to the Multicast Admission Control message. o If the directive in the Multicast Admission Control message is "Add" (1) and is accepted by the NAS, the NAS MUST generate a Multicast Replication Control message in response to the Multicast Admission Control message. The Multicast Replication Control message: * MUST contain a Result set to Nack (0x1); * MUST contain a Transaction ID with a unique value, as described in Section 3.6.1.6 of [RFC6320]; and
Top   ToC   RFC7256 - Page 27
      *  MUST contain the directive as accepted by the NAS.  The NAS MAY
         modify the Accounting field if flow accounting is required.

   o  If the directive in the Multicast Admission Control message is
      "Add" (1) and is processed correctly but not accepted by the NAS
      (i.e., it does not pass the conditional access and admission
      control check), the NAS MAY generate a Multicast Replication
      Control message in response to the Multicast Admission Control
      message.  This optional message can be used by the AN to maintain
      statistics about admission control rejections.  When used in this
      situation, the Multicast Replication Control message:

      *  MUST contain a Result set to 0x0;

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

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

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

4.5. Bandwidth Reallocation Request Message

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

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

4.5.1. Sender Behavior

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

4.5.2. Receiver Behavior

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

   The following cases indicate that the sender holds a different view
   of the amount of delegated bandwidth from the receiver:

   o  The NAS receives a request where the required amount is less than
      its view of the current amount of delegated bandwidth.

   o  The AN receives a request where the required amount is greater
      than its view of the current amount of delegated bandwidth.

   If one of these cases occurs, the receiver, with one exception, MUST
   send a Bandwidth Transfer message indicating Success.

   o  If the NAS received the request, the allocated amount in the NAS's
      response MUST be at least equal to the NAS's view of the current
      amount of delegated bandwidth.

   o  If the AN received the request, the allocated amount in the AN's
      response MUST be no greater than the AN's view of the current
      amount of delegated bandwidth.

   The exception is when the NAS receives a request while it has a
   request of its own outstanding.  Handling of that case is described
   below.

      Note: While the cases just described are an error condition, the
      success response achieves a graceful recovery.

   To avoid deadlock due to race conditions, the following rules MUST be
   applied:

   a.  If the NAS receives a Bandwidth Reallocation Request message
       while it has a Bandwidth Reallocation Request message of its own
       outstanding for the same access line, the NAS MUST provide an
       immediate failure response to the request from the AN, with a
       Result Code value set to 0x68 "Inconsistent views of delegated
       bandwidth amount" or 0x69 "Bandwidth request conflict" as
       applicable.  (See below for more information).

   b.  If the AN receives a Bandwidth Reallocation Request message while
       it has a Bandwidth Reallocation Request message of its own
       outstanding for the same access line, the AN MUST release any
       bandwidth it has already committed to an outstanding join request
Top   ToC   RFC7256 - Page 30
       while it is awaiting a response from the NAS.  It MUST decide
       upon and send its response to the NAS taking the released
       bandwidth into account.

   If the receiver is unable to process the Bandwidth Reallocation
   Request message due to an error, then the receiver MUST return a
   Bandwidth Transfer message where:

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

   o  the Result Code field is set appropriately to indicate the type of
      error that was detected,

   o  the Bandwidth-Allocation TLV contains the value of the current
      amount of delegated bandwidth as the responder views it, and

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

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

   0x67  Invalid preferred bandwidth amount.

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

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

         Required additional information in the message: as described
         above.

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

         Action RECOMMENDED for the receiving ANCP agent: report the
         error to the control application with the returned value of the
         Bandwidth-Allocation TLV.  See also Section 4.6.2.2.
Top   ToC   RFC7256 - Page 31
   0x68  Inconsistent views of delegated bandwidth amount.

         Where detected: control application at the NAS.

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

         Required additional information in the message: as described
         above.

         Target: control application at the AN.

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

   0x69  Bandwidth request conflict.

         Where detected: control application at the NAS.

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

         Required additional information in the message: as described
         above.

         Target: control application at the AN.

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

4.6. Bandwidth Transfer Message

The Bandwidth Transfer message is used to transfer video bandwidth from the sender to the peer for a specific access line. This message MAY be sent either from the AN or from the NAS. As described in the previous section, it is the required response to a valid Bandwidth Reallocation Request message. The Bandwidth Transfer message MAY also be used to transfer bandwidth autonomously from one peer to another. One example of this usage is to release bandwidth borrowed earlier by means of the Bandwidth
Top   ToC   RFC7256 - Page 32
   Reallocation Request message.  When the message is used in this way,
   the Result field in the Bandwidth Transfer message MUST be set to
   Ignore (0x0).

      Note: This allows the receiver to distinguish between an
      autonomous transfer and a response to a previous Bandwidth
      Reallocation Request message, for purposes of validation.

   The Message Type for the Bandwidth Transfer message is 147.  The
   Bandwidth Transfer message contains the following TLVs:

   o  the Target TLV, designating the access line concerned;

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

4.6.1. Sender Behavior

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

4.6.2. Receiver Behavior

4.6.2.1. Behavior of the NAS
If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is not greater than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Bandwidth Transfer message. This is required regardless of whether the Result field of that message indicates Success or Failure. If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new
Top   ToC   RFC7256 - Page 33
   value of delegated bandwidth.  Alternatively, the NAS MAY force the
   AN to modify its view of the amount of delegated bandwidth to that
   held by the NAS by sending a Port Management message for the target
   access line concerned that contains a Bandwidth-Allocation TLV with a
   value equal to the amount of delegated bandwidth the NAS wishes to
   enforce.

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

4.7. Delegated Bandwidth Query Request Message

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

4.7.1. Sender Behavior

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

4.7.2. Receiver Behavior

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

4.8. Delegated Bandwidth Query Response Message

The Delegated Bandwidth Query Response message is sent in reply to a Delegated Bandwidth Query Request message. The response to a valid request contains two TLVs:
Top   ToC   RFC7256 - Page 35
   o  the Target TLV, copied from the request; and

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

   The Message Type for the Delegated Bandwidth Query Response message
   is 148.

4.8.1. Sender Behavior

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

4.8.2. Receiver Behavior

If the Delegated Bandwidth Query Response message indicates Success (0x3), the actions described in Sections 4.8.2.1 and 4.8.2.2 apply.
4.8.2.1. Behavior at the NAS
If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is less than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Delegated Bandwidth Query Response message. If the amount of delegated bandwidth provided in the Bandwidth- Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new value of delegated bandwidth. Alternatively, the NAS MAY force the AN to modify its view of the amount of delegated bandwidth to that held by the NAS by sending a Port Management message for the target access line concerned that contains a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wishes to enforce.
4.8.2.2. Behavior at the AN
The AN SHOULD accept the value returned in the Bandwidth-Allocation TLV of the Delegated Bandwidth Query Response message as the correct value of the current amount of delegated bandwidth. If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN
Top   ToC   RFC7256 - Page 36
   MAY attempt to correct the situation by sending a request to the NAS
   for an increased allocation of delegated bandwidth using the
   Bandwidth Reallocation Request message.

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

4.9. Multicast Flow Query Request and Response Messages

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

4.9.1. Sender Behavior

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

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

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

   To retrieve the AN's view of all of the multicast flows currently
   active on each port of the AN, the NAS MUST send a Multicast Flow
   Query Request message that does not contain any instance of the
   Target TLV or the Multicast-Flow TLV.

4.9.2. Receiver Behavior

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

   The Multicast-Flow TLVs MUST appear in the response from the AN in
   the same order as in the query from the NAS.

   If the Multicast Flow Query Request message contains no Target TLV
   and no Multicast Flow TLV, the AN MUST include, for each AN port
   currently receiving multicast flow(s), the following set of TLVs:

   o  Target TLV.  This MUST identify one AN port.

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

   If the contents of the Multicast Flow Query Request message are in
   error, the AN MUST reply with a Multicast Flow Query Response message
   with the Result field set to Failure (0x4) and the Result Code field
   set to indicate the nature of the error.  If the request contained
   multiple instances of the Target TLV or the Multicast-Flow TLV and
   one of these is in error, the response message MUST contain the
   results for the preceding instances of the TLV as if there had been
   no error.  These successful results MUST be followed by the TLV in
   error, copied from the request.  The AN MUST NOT do further
   processing of the request.  The AN MAY add a Status-Info TLV to
   provide further information on the nature of the error.

4.10. Committed Bandwidth Report Message

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

4.10.1. Sender Behavior

The sender of a Committed Bandwidth Report message MUST set the Result field to Ignore (0x0). The Result Code field MUST be set to 0x000. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
Top   ToC   RFC7256 - Page 39
   Each instance of the Committed-Bandwidth TLV included in the message
   MUST identify an access line for which the amount of committed
   multicast bandwidth has changed since the previous Committed
   Bandwidth Report message was sent and MUST report the latest amount
   of multicast bandwidth committed to that line.  There MUST be only
   one instance of the Committed-Bandwidth TLV present in the message
   for any given access line.  The message MUST include an instance of
   the Committed-Bandwidth TLV for every access line for which committed
   multicast bandwidth has changed since the previous Committed
   Bandwidth Report message was sent.

   Further behavior at the AN is specified in Section 6.2.2.

4.10.2. Receiver Behavior

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

5. ANCP TLVs For Multicast

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

5.1. Multicast-Service-Profile TLV

This document defines the new Multicast-Service-Profile TLV. The Multicast-Service-Profile TLV MAY be included in a Provisioning message as specified in Section 4.1. The Multicast-Service-Profile TLV is illustrated in Figure 7. It consists of a TLV header encapsulating a single instance of the Multicast-Service-Profile-Name TLV and one or more instances of the List-Action TLV.
Top   ToC   RFC7256 - Page 40
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Mcast-Service-Profile 0x0013 |             TLV Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Multicast-Service-Profile-Name TLV                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   List-Action TLV                                             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ...                                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   List-Action TLV                                             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: Multicast-Service-Profile TLV

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

   o  TLV Type: 0x0013

   o  TLV Length: determined by the contents following the TLV header.

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

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

5.2. Multicast-Service-Profile-Name TLV

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

5.3. List-Action TLV

The List-Action TLV identifies multicast flows to be added to or removed from a list of white-, black-, or grey-listed flows. It is meaningful only in association with a Multicast-Service-Profile-Name TLV identifying the profile to which the List-Action TLV applies. Such an association can be achieved by placing both TLVs in the same base message payload or as embedded TLVs of another TLV such as the Multicast-Service-Profile TLV. The List-Action TLV is shown in Figure 9.
Top   ToC   RFC7256 - Page 42
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TLV Type = List-Action 0x0021 |          TLV Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Operation     | List Type     |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family                |     Number of flow fields     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast flow fields                      |
                             ......
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family                |     Number of flow fields     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Multicast flow fields                      |
                                    ......
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 9: List-Action TLV

   The List-Action TLV contains the following fields:

   o  TLV Type: 0x0021

   o  TLV Length: length of the subsequent contents.

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

      *  1 "Add": the multicast flow fields are to be added to the list.

      *  2 "Delete": the multicast flow fields are to be removed from
         the list.  Each multicast flow field in the List-Action MUST
         match exactly an existing entry in the list concerned.  Thus,
         to remove part of the range provided by a wildcarded list
         entry, it is necessary to remove the entire entry and add back
         the remaining partial range(s).

      *  3 "Replace": the multicast flow fields replace the existing
         contents of the list.

   o  List Type: the list type being modified by this List-Action TLV.
      The possible values are 1 "White", 2 "Black", or 3 "Grey".
Top   ToC   RFC7256 - Page 43
   o  Reserved: a sender MUST set this field to zeroes.  A receiver MUST
      ignore the contents of this field.

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

   o  Number of flow fields: the number of multicast flow fields of the
      given address family that follows.

   o  Multicast flow field: a field identifying one or more multicast
      flows.  It consists of an 8-bit group address prefix length, an
      8-bit source address prefix length, a group prefix of 0-16 octets,
      and a source prefix of 0-16 octets, as shown in Figure 10.

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

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

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

         Figure 10: Organization of a Single Multicast Flow Field

   The prefix length has its usual meaning.  It is the number of most-
   significant bits specified within the corresponding prefix.  The
   prefix length MAY vary from 0 to 32 in the IPv4 sub-list and from 0
   to 128 in the IPv6 sub-list.
Top   ToC   RFC7256 - Page 44
   A value of 0 for either the Group PrefLen (prefix length) or the
   Source PrefLen indicates that any value of the corresponding address
   will match (wildcard).  If the value 0 is provided for a particular
   prefix length, the corresponding prefix MUST be omitted from the
   field contents.

   The length of a Source or Group Prefix field is equal to (PrefLen +
   7)/8 octets, truncated to the nearest integer.  Unused bits at the
   end of the prefix MUST be set to zeroes.

5.4. Sequence-Number TLV

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

5.5. Bandwidth-Allocation TLV

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

5.6. White-List-CAC TLV

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

5.7. MRepCtl-CAC TLV

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

5.8. Bandwidth-Request TLV

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

   o  TLV Type: 0x0016

   o  TLV Length: 8 octets

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

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

5.9. Request-Source-IP TLV

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

5.10. Request-Source-MAC TLV

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

5.11. Request-Source-Device-Id TLV

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

   o  TLV Type: 0x0096.

   o  TLV Length: 4

   o  Identifier value: local device identifier value, known to the AN
      and AAA.  Given that the scope of the identifier is a single
      customer network, 32 bits is a more-than-sufficient numbering
      space.

5.12. Multicast-Flow TLV

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

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

   o  Unicast Source Address: unicast address within the given address
      family.  If the Flow Type is "ASM" (1), a source address MUST NOT
      be present.  If the Flow Type is "SSM" (2), the number of source
      addresses given by the Number of Source Addresses field MUST be
      present.

   The full versions of IGMPv3 and MLDv2 support both INCLUDE and
   EXCLUDE modes for specifying the desired sources for SSM flows.  The
   Multicast-Flow TLV supports INCLUDE mode only.  [RFC5790]
   (Lightweight IGMPv3 and MLDv2) provides guidance on converting
   EXCLUDE mode IGMP/MLD records to INCLUDE mode for the Multicast-Flow
   TLV.

5.13. Report-Buffering-Time TLV

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

5.14. Committed-Bandwidth TLV

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


(page 51 continued on part 3)

Next Section