RFC 7256
Multicast Control Extensions for the Access Node Control Protocol (ANCP)
6. Multicast Capabilities
Section 3.5 of [RFC6320] defines a capability negotiation mechanism as well as a number of capabilities. This section defines five new capabilities in support of different modes of multicast operation: o NAS-initiated multicast replication (capability type 3); o committed bandwidth reporting (capability type 5); o conditional access and admission control with white and black lists (capability type 6);
o conditional access and admission control with grey lists
(capability type 7); and
o bandwidth delegation (capability type 8).
The "Capability Data" field within the Capability TLV for all of
these capabilities is empty. All of these capabilities are
independent of the access technology.
The remainder of this section consists of three sub-sections.
Section 6.1 specifies the protocol elements that must be implemented
in order to support each capability. Section 6.2 specifies the
procedures that apply to each capability on its own. Section 6.3
specifies how the capabilities interact if more than one multicast
capability is included in the set of capabilities negotiated between
the AN and the NAS.
6.1. Required Protocol Support
This section specifies the protocol elements that MUST be implemented
to support each of the five multicast capabilities. Support of
multiple multicast capabilities requires implementation of the union
of the sets of protocol elements applying to each of the individual
capabilities in the supported set.
In addition to the elements listed below, implementation of the
Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the
capabilities specified in this document.
6.1.1. Protocol Requirements for NAS-Initiated Multicast Replication
Table 1 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the NAS-initiated
multicast replication capability. Additionally, implementation of
the Multicast Replication Control message requires implementation of
the Command TLV (Section 4.4 of [RFC6320] with additional details in
Section 4.3 of this document).
+--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.1 | Provisioning message with MRepCtl-CAC TLV | | | | | Section 4.2 | Port Management message with Bandwidth-Allocation | | | TLV | | | | | Section 4.3 | Multicast Replication Control message | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.4 | Sequence Number TLV | | | | | Section 5.5 | Bandwidth-Allocation TLV | | | | | Section 5.7 | MRepCtl-CAC TLV | | | | | Section 5.12 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 1: Protocol Requirements for NAS-Initiated Multicast Replication
6.1.2. Protocol Requirements for Committed Multicast Bandwidth Reporting
Table 2 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the committed multicast bandwidth reporting capability. +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.1 | Provisioning message with Report-Buffering-Time | | | TLV | | | | | Section 4.10 | Committed Bandwidth Report message | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.13 | Report-Buffering-Timer TLV | | | | | Section 5.14 | Committed-Bandwidth TLV | | | | | Section 5.12 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 2: Protocol Requirements for Committed Multicast Bandwidth Reporting
6.1.3. Protocol Requirements for Conditional Access and Admission Control with White and Black Lists
Table 3 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the conditional access and admission control with white and black lists multicast capability. +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.1 | Provisioning message with Multicast-Service- | | | Profile TLV, white and black lists only, and | | | White-List-CAC TLV | | | | | Section 4.2 | Port Management message with Multicast-Service- | | | Profile-Name and Bandwidth-Allocation TLVs | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.1 | Multicast-Service-Profile TLV | | | | | Section 5.2 | Multicast-Service-Profile-Name TLV | | | | | Section 5.3 | List-Action TLV, white and black lists only | | | | | Section 5.5 | Bandwidth-Allocation TLV | | | | | Section 5.6 | White-List-CAC TLV | | | | | Section 5.12 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 3: Protocol Requirements for Conditional Access and Admission Control with White and Black Lists
6.1.4. Protocol Requirements for Conditional Access and Admission Control with Grey Lists
Table 4 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the conditional access and admission control with grey lists multicast capability. Additionally, implementation of the Multicast Replication Control message requires implementation of the Command TLV (Section 4.4 of [RFC6320] with additional details in Section 4.3 of this document). +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.1 | Provisioning message with Multicast-Service- | | | Profile TLV, grey lists only, and MRepCtl-CAC TLV | | | | | Section 4.2 | Port Management message with Multicast-Service- | | | Profile-Name and Bandwidth-Allocation TLVs | | | | | Section 4.3 | Multicast Replication Control message | | | | | Section 4.4 | Multicast Admission Control message | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.1 | Multicast-Service-Profile TLV, grey lists only | | | | | Section 5.2 | Multicast-Service-Profile-Name TLV | | | | | Section 5.3 | List-Action TLV, grey lists only | | | | | Section 5.4 | Sequence Number TLV | | | | | Section 5.5 | Bandwidth-Allocation TLV | | | | | Section 5.7 | MRepCtl-CAC TLV | | | | | Section 5.9 | Request-Source-IP TLV | | | | | Section 5.10 | Request-Source-MAC TLV | | | | | Section 5.11 | Request-Source-Device-Id TLV | | | | | Section 5.12 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 4: Protocol Requirements for Conditional Access and Admission Control with Grey Lists
6.1.5. Protocol Requirements for Bandwidth Delegation
Table 5 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the bandwidth delegation capability. +--------------+----------------------------------------------------+ | Reference | Protocol Element | +--------------+----------------------------------------------------+ | Section 4.2 | Port Management message with Bandwidth-Allocation | | | TLV | | | | | Section 4.5 | Bandwidth Reallocation Request message | | | | | Section 4.6 | Bandwidth Transfer message | | | | | Section 4.7 | Delegated Bandwidth Query Request message | | | | | Section 4.8 | Delegated Bandwidth Query Response message | | | | | Section 4.9 | Multicast Flow Query Request and Response messages | | | | | Section 5.5 | Bandwidth-Allocation TLV | | | | | Section 5.8 | Bandwidth-Request TLV | | | | | Section 5.12 | Multicast-Flow TLV | +--------------+----------------------------------------------------+ Table 5: Protocol Requirements for Bandwidth Delegation6.2. Capability-Specific Procedures for Providing Multicast Service
This section describes multicast service procedures for each capability as if it were the only multicast capability within the negotiated set. Procedures involving combinations of multicast capabilities are described in Section 6.3. The use of the Multicast Flow Query Request and Response messages to determine the association between multicast flows and ports is common to all multicast capabilities. No additional text is required here, beyond that already given in Section 4.9 to describe the use of those messages.
6.2.1. Procedures for NAS-Initiated Multicast Replication
NAS-initiated multicast replication may be negotiated to support a mode of operation where IGMP/MLD requests are terminated on the NAS. Alternatively, it may be negotiated to allow the NAS to respond to requests sent by other means (e.g., through application signaling) that require the replication of multicast channels to a given access line.6.2.1.1. Provisioning
The NAS MAY perform admission control for NAS-initiated replication. In this case, it MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. Alternatively, the NAS MAY enable admission control at the AN for NAS-initiated multicast replication. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN, and it MUST also include a Bandwidth-Allocation TLV in a Port Management message for each access line.6.2.1.2. Multicast Service Procedures
The procedures associated with NAS-initiated multicast replication are straightforward. To initiate replication, the NAS MUST send a Multicast Replication Control message to the AN, containing one or more commands adding flows, as described in Section 4.3.1. To terminate replication, the NAS MUST send a Multicast Replication Control message where the commands delete instead of adding the flows. The AN acts upon these messages as specified in Section 4.3.2.6.2.2. Procedures for Committed Bandwidth Reporting
Committed bandwidth reporting may be negotiated if the NAS requires current knowledge of the amount of multicast bandwidth committed to each access line and cannot obtain this information by other means.6.2.2.1. Provisioning
The default buffering time when committed bandwidth reporting is enabled is zero (immediate reporting). To change this, the NAS MAY send an instance of the Report-Buffering-Time TLV containing a non- zero time value to the AN in a Provisioning message. If the NAS subsequently wishes to change the buffering time again, it MAY do so in another Provisioning message.
6.2.2.2. Multicast Service Procedures
If the buffering time for committed bandwidth reporting is zero, the AN MUST send a Committed Bandwidth Report message to the NAS each time the amount of multicast bandwidth committed to any access line under its control changes. If a non-zero value is provided in the Report-Buffering-Time TLV, the AN is in one of two states at any given moment: not-buffering or buffering. The AN enters buffering state if it is in not-buffering state and the multicast bandwidth amount committed to some access line changes. It leaves buffering state when the AN sends a Committed Bandwidth Report message. Upon entry to the buffering state, the AN MUST start a buffering timer and create a Committed Bandwidth Report message containing a Committed-Bandwidth TLV for the triggering access line, but it MUST NOT send it. If a multicast bandwidth change occurs for another access line, the AN MUST add a new Committed-Bandwidth TLV to the message for that additional line. If a multicast bandwidth change occurs for a line for which a Committed-Bandwidth TLV is already present in the buffered report, the AN MUST update the corresponding Committed-Bandwidth TLV to contain the new bandwidth value rather than adding another Committed-Bandwidth TLV for the same access line. The buffering timer expires after the period provided by the Report- Buffering-Time TLV. When it expires, the AN MUST send the Committed Bandwidth Report message that it has been accumulating to the NAS. Exceptionally, the AN MAY choose to send the message before the timer expires, in which case it MUST clear the buffering timer when the message is sent. In either case, the AN enters the not-buffering state as a result. Note: Report buffering implies that NAS reaction to changes in multicast bandwidth usage is delayed by the amount of the buffering period. The choice of buffering period must take this into consideration.6.2.3. Procedures for Conditional Access and Admission Control with Black and White Lists
6.2.3.1. Provisioning
The NAS provisions named multicast service profiles containing white and black lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required by sending
additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing white and black lists or replacements for them. The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast- Service-Profile-Name TLV. The NAS MAY change the multicast service profile for a given access line at any time by sending a Port Management message identifying a new multicast service profile. The NAS MAY choose to enable admission control at the AN for white- listed flows. To do this, it MUST send a Provisioning message as described in Section 4.1, which includes the White-List-CAC TLV, and it MUST provide a multicast bandwidth allocation for each access line by including a Bandwidth-Allocation TLV in a Port Management message.6.2.3.2. Multicast Service Procedures
The conditional access and admission control with white and black lists capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it MUST check to see whether the requested flow is white-listed or black-listed as described below. Requests for black-listed flows MUST be discarded. If the NAS has enabled admission control on the AN as described in the previous section, but a white-listed flow would cause the amount of committed multicast bandwidth to exceed the provisioned limit, the request MUST be discarded. The AN replicates flows passing these checks to the access line. To determine if a requested flow is white-listed, the AN searches for a best match to the flow in the applicable multicast service profile. Matching is done on the prefixes specified in the profile, ignoring the address bits of lower order than those in the prefix. If the requested multicast flow matches multiple lists associated with the access line, then the most specific match will be considered by the AN. If the most specific match occurs in multiple lists, the black list entry takes precedence over the white list. In this context, the most specific match is defined as: o first, most specific match (longest prefix length) on the multicast group address (i.e., on G of <S,G>), and o then, most specific match (longest prefix length) on the unicast source address (i.e., on S of <S,G>).
If the requested multicast flow is not part of any list, the join message SHOULD be discarded by the AN. This default behavior can easily be changed by means of a "catch-all" statement in the white list. For instance, adding (<S=*,G=*>) in the white List would make the default behavior to accept join messages for a multicast flow that has no other match on any list. When the AN receives a leave request, it terminates replication of the multicast flow. If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile is currently assigned. Similarly, if a Port Management message assigns a new multicast service profile to a given port, the AN MUST review all active flows on that port. If the most specific match for any flow is a black list entry, the flow MUST be terminated immediately. If any of the remaining flows do not match an entry in the white list, they also MUST be terminated immediately. White-listed flows MUST be allowed to continue.6.2.4. Procedures for Conditional Access and Admission Control with Grey Lists
6.2.4.1. Provisioning
The NAS provisions named multicast service profiles containing grey lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required by sending additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing grey lists or replacements for them. The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast- Service-Profile-Name TLV. The NAS MAY change profiles on the line by sending a subsequent Port Management message identifying a new profile. The NAS MAY perform admission control for grey-listed flows. In that case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. Alternatively, the NAS MAY enable admission control at the AN for grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST also provide a Bandwidth-Allocation TLV in a Port Management message for each access line.
6.2.4.2. Multicast Service Procedures
The conditional access and admission control with grey lists capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it MUST determine whether there is a match to the requested flow in the grey list of the multicast service profile provisioned against the given access line. If there is no match, the request is discarded. Otherwise, the AN MUST send a Multicast Admission Control message to the NAS with content identifying the access line and the multicast flow to be added. As indicated in Section 4.4, the AN MAY add information identifying the requesting device. If the NAS decides to enable the flow, it MUST send a Multicast Replication Control message to the AN to replicate the flow to the access line with the Result field set to Nack (0x1), as described in Section 4.3.1. When the AN receives the Multicast Replication Control message, it performs admission control if that has been enabled as described in the previous section. If admitting the flow would cause the committed multicast bandwidth at the access line to exceed the provisioned limit, the AN reports an error to the NAS as described in Section 4.3.2. Otherwise, it replicates the multicast flow as requested. If the NAS decides not to permit the flow, it MAY send a Multicast Replication Control message in response to the Multicast Admission Control message to allow the AN to update its internal records. The content of this message is described in Section 4.4.2. When the AN receives a leave request, it MUST terminate replication of the flow to the access line. It MUST then send a Multicast Admission Control message to the NAS indicating the deletion. The NAS updates its internal records but MUST NOT respond to the message. If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile has been assigned. Similarly, if the AN receives a Port Management message that assigns a new profile to a given port, the AN MUST review all active flows on that port. In either case, if any flow does not match an entry in the grey list, it MUST be terminated immediately.
6.2.5. Procedures for Bandwidth Delegation
6.2.5.1. Provisioning
The NAS SHOULD provision an initial amount of delegated multicast bandwidth for each access line using the Port Management message containing the Bandwidth-Allocation TLV. Note: If it fails to do so and a value has not been provisioned on the AN by other means, the AN will be forced to request a bandwidth allocation as soon as it receives a join request. The NAS MAY, at any time, force an update of the amount of delegated bandwidth by the same means.6.2.5.2. Multicast Service Procedures
The bandwidth delegation capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it checks whether it has sufficient remaining uncommitted multicast bandwidth on the access line to accommodate the new multicast flow. If not, it MAY send a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message. The NAS MUST return a Bandwidth Transfer message indicating whether it has granted the request and, if so, the new amount of delegated bandwidth. If the AN has sufficient uncommitted multicast capacity to admit the request, either originally or as the result of a successful request to the NAS, it replicates the requested flow to the access line. Otherwise, it discards the request. When the AN receives a leave request for an active flow, it ceases replication. The NAS or AN MAY, at some point, detect that their respective views of the amount of delegated bandwidth are inconsistent. If so, they can recover using procedures described in Sections 4.5 and 4.6. As a further aid to synchronization, either the NAS or the AN MAY from time to time check the peer's view of the amount of delegated bandwidth using the Delegated Bandwidth Query message. The NAS or AN MAY, at any time, release bandwidth to the peer using an autonomous Bandwidth Transfer message. The contents of this message are described in Section 4.6.
6.3. Combinations of Multicast Capabilities
6.3.1. Combination of Conditional Access and Admission Control with White and Black Lists and Conditional Access and Admission Control with Grey Lists
If conditional access and admission control with white and black lists is combined with conditional access and admission control with grey lists, provisioning of the multicast service profiles is as described in Section 6.2.3.1 except that multicast service profiles will also include grey lists. Admission control is enabled independently on the AN for white lists by including the White-List- CAC TLV in the Provisioning message and for grey lists by including the MRepCtl-CAC TLV in the Provisioning message. The Bandwidth- Allocation TLV provisions an amount that applies to both white- and grey-listed flows if admission control is enabled for both. With regard to multicast service procedures, one point of difference from the individual capabilities must be noted. This is an interaction during the profile matching procedure. The AN MUST seek the best match among multiple lists as described in Section 6.2.3.2. However, if there are multiple matches of equal precision, the order of priority is black list first, grey list second, and white list last. Once profile matching has been completed, processing of a join request is as described in Section 6.2.3.2 for white- or black-listed flows or Section 6.2.4.2 for grey-listed flows. Requests that do not match any list SHOULD be discarded. When the AN receives a leave request, it MUST terminate replication of the flow to the access line. If the flow was grey-listed, the AN MUST then send a Multicast Admission Control message to the NAS indicating the deletion. If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile is currently assigned. Similarly, if a Port Management message assigns a new multicast service profile to a given port, the AN MUST review all active flows on that port. If any flow has its most specific match in a black list entry, it MUST be terminated immediately. If any of the remaining flows do not match an entry in the white or grey list, they MUST also be terminated immediately. Finally, if any remaining flows were originally admitted because they were white-listed but after the change they are grey-listed, the AN MUST generate a Multicast Flow Query Response message autonomously as if it were responding to a Multicast Flow Query Request message, listing all
such flows. These flows MUST be allowed to continue until the NAS or the subscriber terminates them. Flows with their most specific match in the white list MUST be allowed to continue. The autonomously generated Multicast Flow Query Response message MUST be formatted as if it were a successful response to a request containing no Target and no Multicast-Flow TLV, as described in Section 4.9.2, with the exception that the Transaction Identifier field MUST be set to all zeroes. Note: The procedures in the previous paragraphs imply that the AN has to retain a memory of whether an admitted flow was white- listed or grey-listed at the time of its admission/readmission.6.3.2. Combination of Conditional Access and Admission Control with Bandwidth Delegation
The provisioning and bandwidth management procedures of Section 6.2.5 apply in addition to the procedures in Sections 6.2.3, 6.2.4, or 6.3.1 as applicable. Conditional access follows the rules given in those sections in terms of matching flows against white and black and/or grey lists. When admission control is enabled at the AN, the amount of bandwidth used by the AN is negotiable as described in Section 6.2.5.2.6.3.3. Combination of NAS-Initiated Replication with Other Capabilities
NAS-initiated multicast replication can coexist with the other capabilities, but some means must exist to prevent double replication of flows. The simplest way to do this is to terminate all IGMP/MLD requests on the AN, so that NAS-initiated multicast replication is stimulated only by signaling through other channels. Other arrangements are possible but need not be discussed here. Assuming the necessary separation of responsibilities, the only point of interaction between NAS-initiated multicast replication and the other multicast capabilities is in the area of admission control. Specifically, if the AN is to do admission control for flows added by Multicast Replication Control messages, regardless of whether they are part of NAS-initiated replication or grey list multicast service processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning message and the Bandwidth-Allocation TLV in a Port Management message. If, instead, the NAS will do admission control for flows added by Multicast Replication Control messages, regardless of whether they are part of NAS-initiated replication or grey list multicast service processing, it does not send the MRepCtl-CAC TLV in
a Provisioning message to the AN. The NAS can independently enable admission control for white flows on the AN by including the White- List-CAC TLV in the Provisioning message.6.3.4. Combinations of Committed Bandwidth Reporting with Other Multicast Capabilities
Committed bandwidth reporting can take place independently of other multicast capabilities that have been negotiated. However, some combinations do not make sense because of redundancy. In particular, the NAS obtains the same information that committed bandwidth reporting gives if the only other capabilities operating are NAS- initiated replication and/or conditional access and admission control with grey lists.7. Miscellaneous Considerations
This section deals with two sets of considerations. "Report Buffering Considerations" considers requirements for configuration in support of some of the committed bandwidth reporting capability. "Congestion Considerations" is a warning to implementors about the possibility of control-plane congestion, with suggestions for mitigation.7.1. Report Buffering Considerations
The committed bandwidth reporting capability allows the provisioning of a report buffering period to reduce the number of messages the AN passes to the NAS. An appropriate value for this period, if buffering is allowed at all, depends first on the effect of delay in reporting bandwidth changes and secondly on the rate at which bandwidth changes are expected to occur. Let us assume, in the first instance, that a delay in adjusting hierarchical scheduling at the NAS causes additional bandwidth demand to be served momentarily on a best-effort basis, introducing the possibility of jitter and, more crucially, packet loss. Appendix IV of ITU-T Recommendation G.1080 [ITU-T_G.1080] indicates that the maximum tolerable duration of a loss episode is less than 16 ms. This would more likely apply in the middle of a program rather than when it was starting up but at least gives an (extremely conservative) order of magnitude for setting the buffering period. The next question is whether enough messaging is likely to be generated that multiple bandwidth changes would be observed within such an interval. Let us consider a reasonable example in a DSL environment, where during the busiest hour of the day subscribers start watching at the rate of one program per subscriber per hour.
Typically, because of program scheduling, the new channel requests might be concentrated within a three-minute period, giving an effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second) * 16 ms = 0.00009 requests per buffering interval of 16 ms. With these figures, an AN serving 10,000 subscribers will report an average of 0.9 bandwidth changes per 16 ms buffering interval. It appears that buffering is worthwhile only for larger-scale deployments. Note that simple replacement of one channel with another -- channel surfing -- does not require reporting or adjustment at the NAS end.7.2. Congestion Considerations
Implementors must beware of the possibility that a single channel- surfing subscriber could generate enough control messaging to overload the AN or the messaging channel between the AN and the NAS. The implementation problem is to strike the right balance between minimizing the processing of requests that have been overtaken by subsequent events and meeting requirements for what is termed "channel zapping delay". Nominally, such a requirement is to be found in Section 8.1 of [ITU-T_G.1080], but unfortunately no quantitative value was available at the time of publication of this document. Implementors will therefore have to base their work on discussions with customers until standardized requirements become available. (It is possible that regional bodies or more specialized bodies have overtaken the ITU-T in this regard.) A typical strategy for minimizing the work associated with request processing includes deliberate buffering of join requests for a short period in case matching Release requests are detected, followed by discard of both requests. More generally, processing of requests from individual subscribers may be rate limited, and the global rate of messaging to the NAS can also be limited. If the AN gets overloaded, deliberate dropping of stale requests can be implemented, for some definitions of "stale".8. Security Considerations
The security considerations of ANCP are discussed in [RFC6320] and in [RFC5713]. Multicast does not, in principle, introduce any new security considerations, although it does increase the attractiveness of ANCP as a means of denial of service (e.g., through direction of multicast streams onto the target) or theft of service. As mentioned in Section 4.4, the inclusion of the Request-Source-MAC TLV or Request-Source-IP TLV in the Multicast Admission Control message presents privacy issues. An attacker able to get access to
the contents of this message would, like the content provider, be able to track consumption of multicast content to the individual device and potentially to individual persons if they are associated with particular devices. To make the connection between devices and individuals, the attacker needs to get information from sources other than ANCP, of course, but let us assume that this has happened. The protection specified for ANCP in [RFC6320] will apply to the transmission of the Multicast Admission Control message across the access network to the NAS. Hence, the attacker's potential points of access are between the subscriber and the AN, at the AN and at the NAS. Moreover, if the MAC or IP address are transmitted onwards from the NAS to AAA in a request for policy, that whole onward path has to be examined for vulnerability. The question is how many of these potential points of attack can be eliminated through operational practice. The segment from the subscriber through the AN itself seems out of the scope of this discussion -- protection of this segment is basic to subscriber privacy in any event and likely a business requirement. The segment from the AN to the NAS is covered by the basic ANCP protection specified in [RFC6320]. This leaves the NAS and the path between the NAS and AAA for consideration. The operator can eliminate the path between the NAS and AAA as a point where the attacker can access per-device information by downloading per-device policy to the NAS for all identified user devices for the particular subscriber. The NAS then selects the applicable policy based on the particular device identifier it has received. This is as opposed to the NAS sending the identifier of the device in question to AAA and getting policy just for that device. The alternative is to protect the path between the NAS and AAA. If Diameter is used as the AAA protocol, Section 2.2 of [RFC6733] mandates use of IPsec, TLS/TCP, or DTLS/SCTP for that purpose. If RADIUS is used, the operator should deploy TLS transport as specified in [RFC6614]. This leaves the NAS itself as a point of attack. In theory, the NAS could be eliminated if the AN remapped the requesting MAC or IP address to an identifier known to itself and AAA but not the NAS. This would require local configuration on the AN, which may be possible under some circumstances. The Request-Source-Device-Id TLV specified in Section 5.11 is available to transmit such an identifier in place of the Request-Source-MAC TLV or Request-Source-IP TLV.
9. IANA Considerations
This document defines the following additional values within the "ANCP Message Types" registry: +--------------+--------------------------------+-----------+ | Message Type | Message Name | Reference | +--------------+--------------------------------+-----------+ | 144 | Multicast Replication Control | RFC 7256 | | | | | | 145 | Multicast Admission Control | RFC 7256 | | | | | | 146 | Bandwidth Reallocation Request | RFC 7256 | | | | | | 147 | Bandwidth Transfer | RFC 7256 | | | | | | 148 | Delegated Bandwidth Query | RFC 7256 | | | | | | 149 | Multicast Flow Query | RFC 7256 | | | | | | 150 | Committed Bandwidth Report | RFC 7256 | +--------------+--------------------------------+-----------+ This document defines the following additional values for the "ANCP Result Codes" registry. In support of these assignments, IANA has changed the lower limit of 0x100 specified by [RFC6320] for assignments by IETF Consensus to 0x64. +------------+------------------------------------------+-----------+ | Result | One-Line Description | Reference | | Code | | | +------------+------------------------------------------+-----------+ | 0x64 | Command error. | RFC 7256 | | | | | | 0x65 | Invalid flow address. | RFC 7256 | | | | | | 0x66 | Multicast flow does not exist. | RFC 7256 | | | | | | 0x67 | Invalid preferred bandwidth amount. | RFC 7256 | | | | | | 0x68 | Inconsistent views of delegated | RFC 7256 | | | bandwidth amount. | | | | | | | 0x69 | Bandwidth request conflict. | RFC 7256 | +------------+------------------------------------------+-----------+
This document defines the following additional values for the "ANCP Command Codes" registry: +----------------+--------------------------------------+-----------+ | Command Code | Command Code Directive Name | Reference | | Value | | | +----------------+--------------------------------------+-----------+ | 1 | Add | RFC 7256 | | | | | | 2 | Delete | RFC 7256 | | | | | | 3 | Delete All | RFC 7256 | | | | | | 4 | Admission Control Reject | RFC 7256 | | | | | | 5 | Conditional Access Reject | RFC 7256 | | | | | | 6 | Admission Control and Conditional | RFC 7256 | | | Access Reject | | +----------------+--------------------------------------+-----------+
This document defines the following additional values within the
"ANCP TLV Types" registry:
+-----------+--------------------------------+-----------+
| Type Code | TLV Name | Reference |
+-----------+--------------------------------+-----------+
| 0x0013 | Multicast-Service-Profile | RFC 7256 |
| | | |
| 0x0015 | Bandwidth-Allocation | RFC 7256 |
| | | |
| 0x0016 | Bandwidth-Request | RFC 7256 |
| | | |
| 0x0018 | Multicast-Service-Profile-Name | RFC 7256 |
| | | |
| 0x0019 | Multicast-Flow | RFC 7256 |
| | | |
| 0x0021 | List-Action | RFC 7256 |
| | | |
| 0x0022 | Sequence-Number | RFC 7256 |
| | | |
| 0x0024 | White-List-CAC | RFC 7256 |
| | | |
| 0x0025 | MRepCtl-CAC | RFC 7256 |
| | | |
| 0x0092 | Request-Source-IP | RFC 7256 |
| | | |
| 0x0093 | Request-Source-MAC | RFC 7256 |
| | | |
| 0x0094 | Report-Buffering-Time | RFC 7256 |
| | | |
| 0x0095 | Committed-Bandwidth | RFC 7256 |
| | | |
| 0x0096 | Request-Source-Device-Id | RFC 7256 |
+-----------+--------------------------------+-----------+
This document defines the following additional values for the "ANCP Capability Types" registry: +-------+-------------------------+--------+------------+-----------+ | Value | Capability Type Name | Tech | Capability | Reference | | | | Type | Data? | | +-------+-------------------------+--------+------------+-----------+ | 3 | NAS-Initiated Multicast | 0 | No | RFC 7256 | | | Replication | | | | | | | | | | | 5 | Committed Bandwidth | 0 | No | RFC 7256 | | | Reporting | | | | | | | | | | | 6 | Conditional Access and | 0 | No | RFC 7256 | | | Admission Control with | | | | | | White and Black Lists | | | | | | | | | | | 7 | Conditional Access and | 0 | No | RFC 7256 | | | Admission Control with | | | | | | Grey Lists | | | | | | | | | | | 8 | Bandwidth Delegation | 0 | No | RFC 7256 | +-------+-------------------------+--------+------------+-----------+10. Acknowledgements
The authors would like to acknowledge Wojciech Dec for providing useful input to this document, Robert Rennison for his help in shaping the definition of the Multicast-Service-Profile TLV, Shridhar Rao for his comments and suggestions, and Aniruddha A for his proposal that formed the base of the Multicast Flow Reporting solution. Philippe Champagne, Sanjay Wadhwa, and Stefaan De Cnodder provided substantial contributions on the solution for the NAS- initiated multicast control use case. Kristian Poscic provided the committed bandwidth reporting use case. Thanks to the Document Shepherd, Matthew Bocci, and Area Director, Ted Lemon, for points raised by their reviews following Working Group Last Call. Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg for their reviews on behalf of the Security, Operations, and Gen-Art directorates. Dacheng's comments led to changes at several points in the document, while Mehmet's led to creation of the Miscellaneous Considerations section. Finally, thanks to Brian Haberman for stimulating a review of the architectural assumptions and their relationship to the ability of user devices to obtain access to non- IPTV multicast services. This also led to changes in the document.
(next page on part 4)
