tech-invite   World Map     

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

RFC 7256

 
 
 

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

Part 2 of 4, p. 17 to 51
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part