Multicast Control Extensions for the Access Node Control Protocol (ANCP)
updates
- rfc-6320 — Protocol for Access Node Control Mechanism in Broadband Networks
Extracted elements (25)
The Bandwidth-Request TLV uses total delegated bandwidth values rather than incremental deltas so that both the AN and NAS can more easily keep their respective views of the current delegated bandwidth synchronized, avoiding accumulated rounding or ordering errors.
The Multicast Admission Control message currently permits only a single Command TLV because strict sequenced processing is required; a note acknowledges that future versions may permit multiple directives once the ordering semantics are fully specified.
This document updates RFC 6320 by assigning capability type 3 to the NAS-initiated multicast replication capability and by changing the starting point for IANA result code allocation by IETF Consensus from 0x100 to 0x64, affecting the ANCP result code registry.
Receivers MUST ignore message contents that are not supported by the set of capabilities negotiated between the NAS and the Access Node.
The AN MUST process Command TLVs in order of appearance and MUST interrupt processing at the first error, discarding remaining commands; processing of a Multicast Replication Control message with Result=AckAll MUST produce a Generic Response with Result=Success on complete success, while Result=Nack requires no response.
The NAS MUST NOT include any multicast TLV in Provisioning or Port Management messages unless that TLV is supported by the negotiated capability set; specifically, White-List-CAC MUST NOT be sent unless conditional access with white/black lists is negotiated, and MRepCtl-CAC MUST NOT be sent unless NAS-initiated replication or grey-list capabilities are negotiated.
To prevent deadlock in concurrent bandwidth requests: if the NAS receives a Bandwidth Reallocation Request while its own is outstanding for the same line, the NAS MUST immediately return a failure response with Result Code 0x68 or 0x69; if the AN receives one while its own is outstanding, it MUST release any bandwidth already committed to pending joins before responding.
Upon receiving a Bandwidth Transfer message with Result Code 0x68 ('Inconsistent views of delegated bandwidth'), the AN MUST issue a Delegated Bandwidth Query Request to learn the NAS's current view and update its own accordingly; for Result Code 0x69 ('Bandwidth request conflict') the AN SHOULD follow the same procedure unless it can account for the discrepancy.
When the NAS accepts an Add directive from a Multicast Admission Control message, it MUST respond with a Multicast Replication Control message with Result=Nack (0x1) containing the accepted directive; for Delete or Delete All directives processed correctly, the NAS MUST NOT generate any ANCP response.
When the Port Management message is used for multicast, the Function field MUST be set to 8 ('Configure Connection Service Data') and the message MUST include TLVs identifying the access line; for DSL loops, line-identifying TLVs MUST follow RFC 6320 Section 5.1.2.
Transmitting Request-Source-IP or Request-Source-MAC addresses beyond the AN introduces privacy risks for subscriber devices. It is RECOMMENDED that the AN map the device identifier to a local opaque value known only to the AN and AAA and transmit it via the Request-Source-Device-Id TLV instead.
Five ANCP multicast capabilities are defined: NAS-initiated multicast replication, conditional access and admission control with white/black lists, conditional access and admission control with grey lists, bandwidth delegation, and committed bandwidth reporting. Each may be combined according to rules in Section 6.
The Bandwidth Reallocation Request message (Message Type 146) may be sent by either the NAS or the AN to request adjustment of the delegated multicast bandwidth total for a given access line; it contains a Target TLV and Bandwidth-Request TLV specifying both required and preferred bandwidth amounts.
The Bandwidth Transfer message (Message Type 147) transfers delegated multicast bandwidth between peers for a specific access line; it is the mandatory response to a Bandwidth Reallocation Request and may also be sent autonomously (Result=Ignore) to release previously borrowed bandwidth.
The Delegated Bandwidth Query Request and Response messages (both Message Type 148) allow either peer to query the other's view of the current delegated multicast bandwidth for an access line; the response MUST set Result=Success and include a Bandwidth-Allocation TLV with the responder's current view.
The Multicast Admission Control message (Message Type 145) is sent by the AN to the NAS to request admission of a grey-listed multicast flow or to notify the NAS of a leave; it carries a single Target TLV and a single Command TLV that may optionally embed Request-Source-IP, Request-Source-MAC, or Request-Source-Device-Id TLVs.
The Multicast Flow Query Request and Response messages (both Message Type 149) allow the NAS to query the AN for the set of active multicast flows on specified ports, the set of ports receiving a specified flow, or all active flows across all ports.
The Multicast Replication Control message (Message Type 144) is sent by the NAS to the AN with one or more Command TLVs directing the AN to add or delete multicast flows on a target access port; each Command TLV embeds a Command Code, Accounting field, and Multicast-Flow TLV.
The Multicast-Service-Profile TLV (Section 5.1) associates a named profile with one or more List-Action TLVs; each List-Action TLV specifies an action (add, delete, replace), a list type (white, black, or grey), and multicast source/group address content.
The Provisioning message (from RFC 6320) is extended to carry multicast service profiles via the Multicast-Service-Profile TLV (5.1), and per-class admission control directives via the White-List-CAC TLV (5.6), MRepCtl-CAC TLV (5.7), and Report-Buffering-Time TLV (5.13).
IANA is directed to assign ANCP message types 144–150 for the new multicast messages (Multicast Replication Control through Committed Bandwidth Report), capability type 3 for NAS-Initiated Multicast Replication, result codes 0x64–0x69 for multicast-specific errors, and new TLV type codes for all 14 multicast TLVs defined in Section 5.
The multicast extensions inherit the ANCP security model from RFC 6320; unauthorized access to multicast replication control could allow an attacker to replicate traffic to unauthorized subscribers or exhaust admission control resources. Section 8 specifies that the TCP-based transport with MD5 or IPsec authentication defined in RFC 6320 applies.
Grey-list conditional access flow: AN detects IGMP/MLD join matching a grey-list entry → sends Multicast Admission Control (Add) to NAS → NAS responds with Multicast Replication Control (Add) to authorize replication, or a rejection command code to deny; on IGMP/MLD leave the AN sends Multicast Admission Control (Delete) and stops replication.
The Command TLV (Type 0x0011) within a Multicast Replication Control message contains an 8-bit Command Code (1=Add, 2=Delete, 3=Delete All, 4=Admission Control Reject, 5=Conditional Access Reject, 6=Both Reject), an 8-bit Accounting field meaningful only on Add, a 16-bit Reserved field, and an embedded Multicast-Flow TLV.
The Multicast-Flow TLV (Type 0x0019) encodes an 8-bit Flow Type, an 8-bit Address Family, a 16-bit Reserved field, a variable-length Multicast Group Address, and (for SSM flows) a variable-length Source Address; IPv6 SSM example shows TLV Length=36 with 16-byte addresses.