Secondary residential subscriber policy components
Overview
This section describes additional and optional policy components that can be applied to a residential subscriber configuration, depending on the specific application and service delivery model:
ANCP policies
An ANCP policy defines the behavior of the residential subscriber host with which the policy is associated.
An ANCP policy includes one of the following:
An ANCP policy conveys status and control information based on port-up/port-down messages and changes to the current access line rate between the edge device and the access node. This allows supporting NEs to adjust the HQoS subscriber scheduler with the correct rate or raises an alarm when the rate goes below a set threshold. The policy can be changed if the rate drops below a minimal threshold value. The ANCP actual upstream synchronization rate is configured in the ingress panel while the ANCP actual downstream synchronization rate is configured in the egress panel.
PPPoE policies
PPPoE is used in subscriber networks to encapsulate PPP frames inside Ethernet frames. PPPoE combines the point-to-point protocol used with DSL sessions with the Ethernet protocol used to support multiple subscribers in a local area network. PPPoE takes advantage of the speed of a packet-based Ethernet network with the security and accounting functions of a PPP network. PPPoE allows service providers to use existing RADIUS authentication.
Since more than one subscriber is sharing the same connection to a service provider, PPPoE organizes subscribers during two stages:
During the discovery stage, the subscriber and service provider identify each other’s MAC address and establish a PPPoE session ID.
The PPPoE discovery stage consists of the following steps:
-
PPPoE Active Discovery Initiation (PADI). The client initiates a session by broadcasting a PADI packet to the LAN to request a service.
-
PPPoE Active Discovery Offer (PADO). Any access device that can deliver the service requested by PADI packet, replies with a PADO packet that contains its name, unicast address and service requested.
-
PPPoE Active Discovery Request (PADR).The client selects one of the PADOs that it receives and sends a PADR packet to indicate the services required.
-
PPPoE Active Discovery Session Confirmation (PADS). When the selected device receives the PADR packet, it can accept or reject the PPPoE session. To accept the session the device sends the client a PADS packet with a unique ID and a service name. If the device rejects the session, it sends a PADS packet with a service name error and resets the session ID to zero.
During the session stage, PPPoE behaves as a peer-to-peer protocol. Each PPPoE session is identified by the MAC address of the peer and the session ID. Once a session is established, both end points build a point to point connection over the Ethernet and exchange packets. Once the connect is established, the RADIUS accounting policy can begin. LCP negotiates authentication parameters. After a session is authenticated IPCP sends an IP address to the PPPoE client. IP Addresses can be stored in the DHCP local user database, if configured.
After a session is established both end points monitor the session and can terminate a session after a configured number of keep alive intervals are exceeded. An alarm is raised by the NFM-P when a PPPoE session fails. Either peer can send a PPPoE Active Discovery Termination (PADT) packet. See Local DHCP server in this chapter for more information on associating PPPoE with a local DHCP server.
PPPoA sessions
PPPoA is used in subscriber networks to encapsulate PPP frames inside ATM Adaption Layer 5 packets. Each PPP session is carried over a single ATM VC to the BNG. Two types of encapsulation are supported:
PPPoEoA sessions
PPPoEoA is used in subscriber networks to encapsulate PPPoE messaging within ATM Adaption Layer 5 packets. Each PPP session can be directly terminated on any host within the customer Ethernet network and then transported over an ATM network to the BNG. Two types of encapsulation are supported:
PPP policies
A PPP policy defines PPP parameters for an access interface. A PPP policy is applied to an access interface.
MSAP policies
An MSAP policy defines how parameters are applied in the creation of an MSAP. An MSAP policy is applied to capture SAP L2 access interfaces and MSAP L2 and L3 access interfaces. An MSAP policy can be configured to create sticky MSAPs, which are not automatically cleared by the system when they become idle. Sticky MSAPs must be cleared manually; see To clear idle sticky MSAPs.
Host tracking policies
A host tracking policy is used to allow a subscriber's video traffic (multicast) to be included in the egress rate control for the subscriber. When a host tracking policy is specified in a subscriber profile, the egress traffic rate for the subscriber takes into account the unicast and multicast traffic in the aggregate egress rate or in the egress scheduler rate specified in the ANCP policy. There is no default host tracking policy.
When a host tracking policy is applied to a subscriber profile, all subscribers associated with the subscriber profile are tracked using that host tracking policy. You can view the tracked subscribers on the associated local host tracking policy property form.
You can also configure IGMP host tracking parameters on VPLS, IES, and VPRN service sites and SAPs.
The following on-demand host tracking information is available:
-
on the Residential Subscriber Instance form, Host Tracking Info tab, which hosts are being tracked for this particular subscriber
-
on the Residential Subscriber Instance form, Host Tracking Status tab, the egress traffic rate reduction for this particular subscriber
-
on the VPLS L2 access interface property form, Host Tracking Info tab, which hosts are being tracked
-
on the IES and VPRN service access point property form, Host Tracking Info tab, which hosts are being tracked
On-demand historical and real-time host tracking statistics are supported for SAPs and residential subscribers. Only historical statistical plotting is supported. The statistics and read-only host tracking information can be cleared by the NFM-P.
Category map policies
A category map policy combines up to sixteen credit category mappings for association with SLA profiles and credit control policies. Each category specifies a group of queues and policers, as well as credit exhausting IP filter entries.
Credit control policies
A credit control policy is used to associate additional policy objects with a credit control server. If the credit control server is a RADIUS server, a category map policy is specified. If the credit control server is a diameter server, a diameter policy, diameter application policy, and category map policy are specified. A credit control policy also specifies out-of-credit and error handling actions. The credit control policy is configured on SLA profiles.
IGMP policies
An IGMP policy specifies IGMP group parameters and a list of static multicast group addresses and static source addresses. The IGMP policy is associated with subscriber profiles.
IPoE session policies
The IPoE session policy allows dual-stack IPoE subscriber sessions to function simlarly to dual-stack PPoE sessions. The policy specifies which session key information in the trigger packet is used to instantiate the IPoE session, and session timeout information. The IPoE session policy is bound to a VPLS capture SAP, and to a VPRN or IES group interface.
Diameter policies
The NFM-P supports diameter policies and associated diameter peers. Diameter policies are used in a subscriber management context to provide a credit control mechanism. The diameter policy establishes a server/peer configuration, as well as Diameter Credit-Control Application (DCCA) support. The NE functions as the credit control client, while the peer acts as the credit control server.
DCCA represents an alternative to RADIUS for providing a mechanism to support pre-paid service model in access networks. Under a DCCA configuration, the credit control server is used to grant service to a subscriber for pre-defined duration. Before a subscriber host is created, the BNG queries the credit control server about the credit for the given subscriber. If credit is granted, the subscriber host is installed with the appropriate SLA level. If the subscriber has no credit, the credit control server denies access and no subscriber host is created.
The diameter policy is used to specify common diameter protocol parameters, while the diameter peer defines the relationship with an external diameter server. The diameter protocol parameters defined on the diameter policy describe connection and session characteristics, and indicate which AVPs to use in messages.
The diameter policy is configured on the credit control policy.
Peers
The diameter policy defines a set of peers with which to establish diameter sessions. Peers share the configuration of the policy with which they are associated, but can override individual timer parameters inherited from the policy. In addition, each peer defines transport and connection-specific parameters, values for destination-specific AVPs, and a preference value.
The 7750 SR and 7450 ESS provide read-only operational values and statistics for the peer definition of local diameter policies. The NFM-P can provide a snapshot view of operational values and statistics. Operational values include the peer's timer values, the current state of the peer's state machine, and the peer's order among the other peers within the policy.
DCCA
The 7750 SR supporst a DCCA, which can be customized through a set of parameters on the diameter policy in the NFM-P. The parameters allow customization of DCCA error handling, DCCA timer(s), and AVP value definitions.
Subscriber multicast CAC policies
The subscriber multicast CAC policy defines bandwidth constraints for multicast CAC. The subscriber multicast CAC policy is applied to a subscriber profile.
Mobile gateway/peer profiles
The mobile gateway/peer profile configures a signalling interface between the WLAN gateway and the mobile gateway. The mobile gateway/peer profile is applied to a PGW or a GGSN.
Host lockout policies
A host lockout policy implements the ability to hold off a misconfigured or malicious subscriber that is continuously retrying to connect. This conserves resources on the NE and on the RADIUS server.
A host lockout policy can be associated with the following objects:
Host lockouts can be cleared at the policy level, at the NE level, or from the SAP to which they are applied.
RADIUS script policies
HTTP redirect policies
The HTTP redirect policy specifies a redirect URL and destination port, as well as a list of forwarding address/port pairs. An HTTP redirect policy is associated with a WLAN GW configuration on an IES or VPRN group interface.
MLD policies
The MLD policy specifies MLD group-related parameters, as well as a list of static multicast group/source address pairs. An MLD policy is configured on a subscriber profile.
Diameter application policies
The NFM-P supports diameter application policies and associated diameter peer policies. The diameter application policy is used to specify common diameter protocol parameters. The diameter protocol parameters defined on the diameter application policy describe connection and session characteristics, and indicate which AVPs to use in messages.
The protocols and AVP types vary, depending on the policy’s application type:
The diameter application policy can be configured on local user database IPoE and PPP hosts, and on VPRN and IES group interfaces.
Diameter NASREQ
In network configurations where a Diameter infrastructure is available, Diameter NASREQ can be used an alternative to a local user database and RADIUS for ESM host authentication. If the diameter application policy is configured for NASREQ, it can be configured as a Diameter Authentication Policy on IES and VPRN group interfaces, on local user database IPoE and PPP hosts, and on VPLS capture SAPs.
Distributed subscriber management traffic policers
The distributed subscriber management traffic policer object specifies per-subscriber bandwidth policing on the anchor ISA. Distributed subscriber management traffic policers can be configured in two ways:
-
Single-bucket policers monitor bandwidth using a single traffic flow rate (PIR) and burst parameter (MBS)
-
Dual-bucket policers monitor bandwidth using dual traffic flow rates (PIR/CIR) and dual burst parameters (MBS/CBS).
Distributed subscriber management traffic policers are available to all the ISAs in a WLAN-GW group. A default policer template for the WLAN-GW group is always created on the ISA when a WLAN-GW IOM is added to a WLAN-GW group. When a UE is authenticated, RADIUS returns a policer template in a VSA. On an anchor ISA, the ingress and egress policer is instantiated for the subscriber, based on the policer template and overrides for rates/bursts returned from RADIUS.
Distributed subscriber management IP filter policies
The distributed subscriber management IP filter policy installs shared per-SAP filters on SAPs between the anchor ISA and the IOM. The filters map the DSCP on ingress and egress traffic to per-SAP queues.
You can create a redirect filter with a drop action and configure RADIUS to perform a COA to associate this drop action filter with a given UE. The policy filter name is included in the RADIUS VSA.
PIM policies
The PIM policy is configured on a subscriber profile to enable PIM on residential subscriber hosts. For more information, see PIM on IES group interfaces.
SHCV policies
See SHCV policies. To create an SHCV policy, see To configure an SHCV policy.
RIP policies
The RIP policy is used to authenticate an associated host object on a RIP listener interface. A RIP policy can be configured on the following host objects:
To create a RIP policy, see To configure a RIP policy.
BRG profiles
The Bridged Residential Gateway (BRG) profile is used to apply default attributes to a virtual CPE, including SLA and subscriber profile strings, SHCV timers and hold times, RADIUS server policy, RADIUS proxy servers, and DHCPv4 configuration. A BRG profile can be configured on IES and VPRN group interfaces.
To create a BRG profile, see To configure a BRG profile.
Trace profiles
The Trace profile allows debug information for IPoE sessions to be collected as a trace. It correlates debug information across multiple applications into a single trace, allowing you to easily find the root cause of an issue.
Use a trace profile to gather debug information for the following applications:
To create a trace profile, see .
Workflow to configure call trace debugging
Complete the following procedures to deploy call trace debugging in a network.
-
Configure a trace profile; see To configure a trace profile.
Specify the applications for which you want to gather debug information, and specify the type of output for gathered information. Deploy the profile to NEs you want to trace.
-
Specify trace log file storage information on traced NEs; see To configure call-trace debug storage on an NE.
UPnP policies
The universal plug and play (UPnP) policy is configured on a subscriber profile to add UPnP port mapping functionality on residential subscriber hosts. UPnP provides user-friendly, automatic creation/deletion of port mappings for non-technical users.
UPnP performs NAT port mapping management by application (P2P, gaming, etc.). In a typical routed home, a CPE router (with NAT) acts as a UPnP IGD, accepting UPnP requests from home devices and applications to add or remove NAT port mappings as required.
MAP-T domain policies
The MAP-T domain policy defines a series of MAP rules to associate with a MAP domain. The MAP domain is configured as part of a NAT configuration on a VPRN service site.
Mapping Address and Port with Translation (MAP-T) functionality is used to connect a private IPv4 network and associated customer equipment (CE), over an IPv6 network, to a public IPv4 network connected to a centralized border router. MAP-T can also be used for direct communication between CEs.
Figure 64-1: MAP-T domain
APN policies
See HSQ.
Service chaining policies
For information on service chaining, see ISA service chaining.
For information on configuring service chaining policies, see To configure a service chaining EVPN policy and To configure a service chaining VAS filter policy.