Protocol for Access Node Control Mechanism in Broadband Networks
updated by
- rfc-7256 — Multicast Control Extensions for the Access Node Control Protocol (ANCP)
Extracted elements (27)
ANCP reuses GSMPv3's TCP port (6068) and Ethernet encapsulation identifier (0x880C) because existing implementations made reversing that decision impractical. To allow peers to distinguish the two protocols, ANCP was assigned version number 50 (outside the GSMPv3 range of 1–3), and a joint GSMP/ANCP version registry was established.
The AN is required to initiate the TCP connection to the NAS rather than the reverse, because it is easier to configure each AN with the single IP address of its NAS than to provision the NAS with the addresses of all ANs it serves.
Although ANCP originated from GSMPv3 (RFC 3292), it introduces so many extensions and modifications that the two protocols are not interoperable. ANCP uses version number 50 to distinguish itself; GSMPv3 uses versions 1 through 3.
After a TCP connection is established, adjacency protocol messages MUST be exchanged as specified before any other ANCP messages are sent. ANCP messages other than adjacency protocol messages MUST NOT be sent until the adjacency protocol has achieved synchronization (ESTAB state).
All text fields in ANCP use UTF-8 encoding. When extracting text fields from a message, the ANCP agent MUST NOT assume that the fields are zero-terminated.
Because ANCP uses TCP (a reliable transport), the GSMPv3 fragmentation mechanism is unnecessary. An ANCP agent MUST set the I Flag and SubMessage Number fields to 1 to signify 'no fragmentation'.
If the negotiated set of ANCP capabilities for a session is empty, the sender of the SYNACK MUST raise an alarm to management, halt the adjacency procedure, and tear down the TCP session if it is not being used by another adjacency.
If the recipient of an ANCP message does not understand a particular TLV, it MUST silently ignore it. TLVs MAY be added to a message in any order unless otherwise specified.
Loss of synchronization MAY be declared if no valid ANCP messages are received within three times the negotiated Timer value, or if a mismatch in adjacency state is detected. In either case, the detecting peer MUST send an RSTACK to initiate resynchronization.
Reserved and unused fields in ANCP messages MUST be set to zeroes by the sender and MUST be ignored by the receiver. This applies to both explicitly reserved fields and to unused bits in flag fields.
Support of the Generic Response message, both as sender and as receiver, is REQUIRED for all ANCP agents regardless of what capabilities they support. It is used to return a result code and diagnostic information (via Status-Info TLV) when no data other than success/failure need be returned.
The Access Node MUST initiate the TCP session to the NAS using destination port 6068. The NAS MUST listen on port 6068 for incoming connections from Access Nodes.
The ANCP protocol version field in all ANCP messages MUST be set to 50. This value distinguishes ANCP messages from GSMPv3 messages received over the same TCP port and encapsulation.
Transaction IDs in ANCP request messages MUST be set to a value in the range (1, 2^24 - 1), maintained independently for each message type within each ANCP adjacency. They SHOULD be incremented by 1 for each new message of a given type, cycling back to 1 after reaching the maximum.
ANCP capability negotiation occurs during adjacency establishment: each peer advertises its supported capabilities in SYN/SYNACK Capability Fields (each with a 16-bit Capability Type, 16-bit Capability Length, and optional Capability Data padded to 4-byte boundary). The session operates using only the intersection of capabilities supported by both peers.
DSL access line identification uses TLVs carrying the Access-Aggregation-Circuit-ID-ASCII (circuit identifier as UTF-8 string), Access-Aggregation-Circuit-ID-Binary, and Remote-ID, modeled on DSL Forum TR-101. These TLVs are carried in topology discovery and line configuration messages to uniquely identify subscriber access lines.
DSL line attribute TLVs carried in topology discovery messages report physical line parameters using 32-bit unsigned values in kbps or milliseconds: DSL-Type, Actual/Minimum/Attainable/Maximum Net Data Rate (upstream and downstream), Maximum/Actual Interleaving Delay (upstream and downstream), Minimum-Net-Low-Power-Data-Rate, DSL-Line-State, and Access-Loop-Encapsulation.
The DSL Line Configuration capability (Type 0x02) allows the NAS to configure DSL line parameters on the AN via a Port Management message. The Service-Profile-Name TLV carries a UTF-8 string naming the service profile to apply to the specified access line.
The DSL Remote Line Connectivity Testing capability (Type 0x04) allows the NAS to initiate OAM loopback tests on DSL lines via a Port Management (OAM) message. Test parameters are carried in the OAM-Loopback-Test-Parameters TLV; test results are returned in an OAM-Loopback-Test-Response-String TLV. The same message type is used for both request and response, distinguished by the Result field.
The DSL Topology Discovery capability (Type 0x01) enables the AN to report subscriber line status changes to the NAS via Port Up and Port Down event messages. The AN MUST send a Port Up event when a line comes up and a Port Down event when a line goes down, carrying DSL line attributes in the message body.
This document establishes eight new IANA registries for ANCP: Message Type, Result Code, Port Management Function, Technology Type, Command Code, TLV Type, Capability Type, and a joint GSMP/ANCP Version Registry. Registration policies range from Standards Action (Message Type, Version) to IETF Review or Expert Review for extensibility points.
ANCP mandates TCP/IPsec+IKEv2/IP as its transport, with IPsec providing peer authentication and message integrity and confidentiality protection. This requirement stems from RFC 5713 security requirements: unauthenticated ANCP messages could allow an attacker to spoof DSL line attributes, alter QoS configurations, or disrupt subscriber connectivity.
The ANCP adjacency protocol defines three states: SYNSENT (SYN sent, awaiting SYNACK or SYN), SYNRCVD (SYN received and SYNACK sent), and ESTAB (fully synchronized). Transitions are triggered by SYN, SYNACK, ACK, and RSTACK messages; mismatch conditions (failed B or C checks) cause RSTACK transmission and reversion to earlier states.
ANCP messages transported over TCP MUST be prepended with a 4-byte encapsulating header: a 16-bit Identifier field (MUST be set to 0x880C) and a 16-bit Length field giving the total byte length of the ANCP message, excluding the 4-byte header itself.
ANCP TLVs consist of a 16-bit IANA-registered Type field, a 16-bit Length field (byte count of the Value field, excluding padding), and a variable-length Value field padded with zeroes to a 4-byte word boundary. TLVs may be nested; padding within inner TLVs MUST be included in the outer Length.
The ANCP adjacency message contains (in order): Version (8 bits), Message Type (8 bits, always 10), Timer (8 bits, units of 100 ms, default 250), M flag (1 bit), Code (7 bits, values 1=SYN/2=SYNACK/3=ACK/4=RSTACK), Sender Name (48 bits), Receiver Name (48 bits), Sender Port (32 bits), Receiver Port (32 bits), PType (4 bits), P Flag (4 bits), Sender Instance (24 bits), Partition ID (8 bits), Receiver Instance (24 bits), Reserved (8 bits), # of Caps (8 bits), Total Length (16 bits), and variable-length Capability Fields.
The general ANCP message header (used for all non-adjacency messages) contains: Version (8 bits), Message Type (8 bits), Result (4 bits), Result Code (12 bits), Partition ID (8 bits), Transaction Identifier (24 bits), I flag + SubMessage Number (1 + 15 bits), and Length (16 bits), followed by the message payload.