RFC 7256
Multicast Control Extensions for the Access Node Control Protocol (ANCP)
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.
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
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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Source Address ~ | = 2001:DB8::2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Example Change of Source Flow Using Multicast Replication Control Message4.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
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:
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).
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
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.
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
* 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
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
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
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.
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
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
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.
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:
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
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.
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.
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].
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.
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.
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.
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".
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.
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.
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.
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
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.
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
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.
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).
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)
