Supported Platforms
ANCP Topology Discovery and Traffic Reporting Overview
This topic describes Access Node Control Protocol (ANCP) and the ANCP agent running in Junos OS as a means to monitor subscriber access lines and to report and modify subscriber traffic on the access lines between the subscribers and the access nodes.
Overview
ANCP acts as a control plane between a service-oriented Layer 3 edge device and a Layer 2 access node. The access nodes—ANCP neighbors—are network devices that terminate access loops from subscribers; for DSL access loops, the access node is a DSL access multiplexer (DSLAM). Queuing and scheduling mechanisms for subscriber traffic must avoid congestion within the access network while contending with multiple flows and distinct CoS requirements. These mechanisms require the edge device—a router acting as a broadband network gateway (BNG), often also called a network access server (NAS)—to provide information about the access network and subscriber traffic.
The ANCP agent can map an access line to an interface or interface set either statically or dynamically. The agent provides that information to both CoS and AAA. The agent passes on to both CoS and AAA the traffic shaping attributes for each subscriber access line that the access node sent to the ANCP agent. In addition, the agent sends to AAA all DSL Forum attributes that were sent by the access node. AAA can use these attributes during RADIUS accounting and authentication for both DHCP IP demux and PPPoE subscriber sessions. The traffic rates can also be used for shaping L2TP tunnel traffic.
You can monitor ANCP events and operations by including the traceoptions statement at the [edit protocols ancp] hierarchy level.
Junos OS supports the following interface types for ANCP:
- Static VLAN and VLAN demux interfaces and interface sets
- Dynamic VLAN and VLAN demux interfaces and interface sets
- Dynamic VLAN-tagged interface sets
- Dynamic agent circuit identifier (ACI) interface sets
- Dynamic DHCP IP demux subscriber interfaces
- Dynamic PPPoE subscriber interfaces
ANCP was developed as an extension of RFC 3292, General Switch Management Protocol (GSMP) V3, but is now defined in RFC 6320, Protocol for Access Node Control Mechanism in Broadband Networks.
Topology Discovery
The router uses topology discovery to collect information from the access node. The information includes the following:
- Topology of the access network
- DSL line state
- Actual upstream and downstream net data rates of a synchronized DSL link
- Maximum attainable upstream and downstream net data rates
- Interleaving delay
Subscriber Services
The router receives the service profile for the subscribers from a RADIUS server. Most of the services are enforced by the router itself. The router shapes the aggregate egress traffic to subscribers based on the local loop throughput reported by the DSLAM. This traffic shaping optimizes traffic flow while avoiding traffic drops in the access node.
Some service attributes, such as interleaving delay and multicast channel information, are enforced at the access node. The ANCP agent provides the line configuration mechanism that the edge device can use to pass the line configuration to the access nodes. Typically, multiple profiles are provisioned on the access node. The router instructs the access node which profile to use for a given subscriber.
Subscribers typically receive some combination of voice, data, and video services. Each service can be provisioned on a VLAN. A subscriber might receive only a single service over a single VLAN configured on a logical interface. A group of VLANs carrying services to a subscriber is an interface set.
ANCP Interfaces and Access Loop Circuit Identifiers
The access loop or access line in an ANCP topology consists of the physical elements between the subscriber device (CPE) and the access node. An identifier associated with the access loop serves to identify the subscriber as well. This identifier is an alphanumeric string that actually identifies the interface on the DSLAM from which subscriber requests originate. It can be referred to by various names.
- In ANCP messages, a TLV carries the access loop circuit ID, also referred to as the access line identifier, access loop circuit identifier, or access identifier.
- DHCP discovery packets can identify the line with the Agent Circuit ID suboption in the Option 82 field.
- PPPoE discovery packets can identify the line with the DSL Forum Agent-Circuit-ID VSA [26–1].
Each of these identifiers is abbreviated as ACI. When the ANCP agent receives a port management message from an access node, it uses the access loop circuit identifier contained in the message to determine which logical interface or interface set corresponds to the subscriber.
You can associate an identifier with an ANCP access line by static configuration. When you configure a logical interface by specifying the interface name at the [edit protocols ancp interfaces] hierarchy level, include the access-identifier statement to associate the access loop circuit identifier with the interface. When you configure an interface set by including the interface-set statement at the [edit protocols ancp interfaces] hierarchy level, associate the access loop circuit identifier with the interface set by including the access-identifier statement at the [edit protocols ancp interfaces interface-set interface-set-name] hierarchy level.
When the DHCP or PPPoE discovery packet includes an ACI, the ANCP agent can dynamically map the ACI to the subscriber interface or interface set. VLANs for the subscribers are created according to a dynamic profile; these are called agent circuit identifier-based or ACI-based dynamic VLANs.
Both static and dynamic ACIs must be unique across the network; no two interfaces across multiple neighbors (access nodes) can share the same identifier. ANCP support for RADIUS authentication and accounting requires that the ACIs be unique across the network. The DHCP and PPPoE processes do not have information about the access node IP addresses and consequently cannot distinguish between duplicate identifiers. This situation prevents the AAA services framework from correlating a DHCP or PPPoE client session with an access line for RADIUS authentication and accounting.
ANCP Neighbors
The ANCP agent can report traffic only for access nodes that are configured as ANCP neighbors. Neighbors can establish TCP connections with the router. Include the neighbor statement at the [edit protocols ancp] hierarchy level to configure an access node as an ANCP neighbor.
The ANCP agent exchanges adjacency messages with neighbors. If an adjacency message is not received from a neighbor within the expected period, then the neighbor is considered to be down and is disconnected. You can adjust how long the ANCP agent waits for adjacency messages from all neighbors by including the adjacency-timer statement at the [edit protocols ancp] hierarchy level. The interval between adjacency messages is negotiated between router and the neighbor during adjacency establishment. The larger of two timer values—either the value received in the ANCP SYN message or the configured value—is selected. Loss of synchronization between the router and a neighbor is declared when no valid messages are received for a period of time that exceeds three times the negotiated value.
You can also configure parameters for a specific neighbor that override global or default configurations by including any of the following statements at the [edit protocols ancp neighbor ip-address] hierarchy level:
- adjacency-timer—Adjust the interval between adjacency messages exchanged with this neighbor.
- ietf-mode—Prevent ANCP from operating in a backward-compatible mode for this neighbor; for neighbors that use the current IETF implementation of ANCP.
- maximum-discovery-table-entries—Specify how many discovery table entries are accepted from this neighbor. Include this statement at the [edit protocols ancp] hierarchy level to set the number of entries globally for all neighbors.
- pre-ietf-mode—Enable ANCP to operate in a backward-compatible mode for this neighbor; for neighbors that use the original IETF implementation of ANCP rather than the current implementation. Include this statement at the [edit protocols ancp] hierarchy level to operate in backward-compatible mode globally for all neighbors.
