Intelligent Services Gateway (ISG) is a Cisco software feature set that provides a structured framework in which edge devices can deliver flexible and scalable services to subscribers. This document provides information about what ISG is, the benefits of ISG, and how to begin implementing it.
Your software release
may not support all the features documented in this module. For the latest
caveats and feature information, see
Bug Search Tool and the
release notes for your platform and software release. To find information about
the features documented in this module, and to see a list of the releases in
which each feature is supported, see the feature information table.
Use Cisco Feature
Navigator to find information about platform support and Cisco software image
support. To access Cisco Feature Navigator, go to
An account on Cisco.com is not required.
Intelligent Services Gateway (ISG) is a structured framework in which edge access devices deliver flexible and scalable services to subscribers. ISG handles the following key aspects of subscriber management:
Service and policy determination
Session policy enforcement
Session life-cycle management
Accounting for access and service usage
Session state monitoring
In addition, ISG introduces a dynamic element to the provisioning and activation of services through control policies and Change of Authorization (CoA) extensions to the RADIUS protocol.
An ISG-enabled device may be deployed at the access edge and service edge of a network and is applicable to a range of subscriber network environments, such as digital subscriber line (DSL), public wireless LAN (PWLAN), and mobile wireless network. Moreover, ISG has been designed to accommodate a flexible distribution of subscriber and service information within a given solution. The figure below illustrates a typical DSL deployment for which service profile data may be stored in an authentication, authorization, and accounting (AAA) database and retrieved and cached on demand.
Figure 1. Sample Topology for a DSL Deployment
It is also possible to define services directly on an ISG. In all cases, service activation may be triggered as a result of a locally defined control policy, user profile associations, or CoA commands from an external policy server or portal application.
Fundamental to the ISG architecture is the provisioning of a common session layer at which the management of generic subscriber sessions is decoupled from the technology that is used to provide access to the edge device.
Within this session management layer, common methods are provided for the extraction of subscriber identity information and the determination and activation of services. These methods are described in the following sections:
An ISG subscriber session is a generic system context that is created for every subscriber who interacts with the edge device. A subscriber session is created on first interaction so that policies may be applied as early as possible. Such policies may facilitate the retrieval of subscriber identity information. All subscriber sessions are assigned a locally unique identifier that may subsequently be used to reference the session.
The session context is the basis for common handling at the session management layer, but the type of traffic that is encompassed in a session context may vary. Broadly, session types may be categorized as Layer 2 or Layer 3, depending on the packet types that are being handled by the session. For instance, a PPP session is a Layer 2 session in that it includes all packets transferred over a link that was established using PPP negotiation. An IP session is Layer 3 because it includes all IP packets exchanged with a subscriber device at a single IP address. Whether a session is Layer 2 or Layer 3 will, to some extent, determine the type of polices that may be activated for the session.
ISG also provides flexibility in terms of how an IP session is defined for an interface. For example, on a particular interface, ISG can be provisioned to classify IP sessions on the basis of a single address (an IP session), a subnet (an IP subnet session), or the interface itself (an IP interface session), wherein all IP packets transferred over the interface are encompassed by the same session.
In a network deployment, ISG session types should be provisioned to represent individual subscriber entities. For example, a particular ISG interface may be directly connected to a subscriber household in which several subscriber devices with individual IP addresses are attached to a household LAN. If the plan is to model each LAN-attached device as a separate subscriber and apply different policies and services to each, the interface should be provisioned to expect IP sessions. However, if the household represents a single subscriber account, and common handling is required for all packets exchanged, the interface should be provisioned as an IP interface or subnet session.
Under ISG, the provisioning and handling of specific access media and protocols is decoupled as far as possible from the functionality that is applicable to all session types. This model has the following benefits:
A common set of subscriber services may be used on an ISG at which heterogeneous subscriber networks are aggregated.
A common set of subscriber services may be used for multiple ISGs, even when the access technology differs.
For a given subscriber, the access method may be altered (through provisioning or roaming) without any need to change the service provisioning.
As new access protocols become available, they can be leveraged by existing edge deployments without requiring changes to the service content; new access protocols plug into the ISG framework.
A subscriber session is created when the first control protocol packet is received from the subscriber device. The control protocol will vary depending on the session type. If there is no control protocol, the session is signaled by the first data packet from the subscriber.
At session start, certain identity information is available, although typically not enough to completely identify the subscriber. Through the use of control policies, the identity information available at session start can be used to drive the extraction of further identity from the subscriber and determine new policy for the session. The following example illustrates how ISG might handle subscriber identity:
For an IP session, where session start is signaled by a DHCP protocol event, a TCP redirection policy could be activated. This policy would facilitate the collection of a username and credential at an external web portal.
An ISG service is a collection of policies applicable to a subscriber session. When a service is activated on a session, all policies contained within that service are activated on the session. Likewise, when a service is deactivated, all policies that are contained within the service are deactivated or removed from the session.
Services are useful for handling fixed policy combinations that are applicable to a number of subscribers. This application reduces duplication of persistent data and allows a group of policies to be activated with a single action and a single reference.
A service may be defined on the edge device directly, through the command-line interface (CLI), or in an external repository and downloaded as required. A downloaded service definition is cached on the device for as long as it is active on one or more sessions.
A service may be activated in one of the following ways:
As a result of control policy execution
By receipt of a CoA service-logon command
By reference in a user profile, where the service is flagged for automatic activation
Services primarily contain traffic policies. There are some restrictions regarding the policies that may be combined in a given service; for example, a service may not contain two traffic policies that specify a different nondefault traffic class unless they apply to different traffic directions (inbound versus outbound).
Where a service contains a network-forwarding policy, it is known as a primary service
. Only one primary service may be active for a given session at any point in time; that is, primary services are mutually exclusive.
ISG introduces support for two basic policy types:
Traffic policies define the handling of data packets and consist of a traffic class, which defines the packet-based criteria for which the policy is applicable, and one or more traffic actions, which are functional instances that perform specific operations on a data stream and are often referred to as features
. The traffic actions configured within a traffic policy are invoked for data packets that meet the criteria defined by the traffic class.
Network-forwarding policies are a specific type of traffic policy, for which the action is a network-forwarding action, such as to route packets using a specific virtual routing and forwarding instance (VRF) or to forward packets over a Layer 2 connection. Network-forwarding policies are “classless” in that it is not possible to refine the criteria for which the forwarding action is applicable.
Control policies define the handling of system events and consist of one or more control policy rules and a decision strategy that governs how the constituent policy rules are evaluated. A control policy rule consists of a control class (a flexible condition clause), an event for which the condition is evaluated, and one or more control actions. Control actions are general system functions, such as “authenticate” or “activate a service.”
Control policies may be activated on various targets, such as interfaces or ATM virtual circuits (VCs), and typically control the extraction and authentication of subscriber identity and the activation of services on sessions. Traffic policies may be activated only on sessions and are typically (though not always) applied through service activation.
Control policies are a structured replacement for feature-specific configuration commands and allow configurable functionality to be expressed in terms of an event, a condition, and an action. Control policies represent an intuitive and extensible framework for specifying system behavior. As additional functionality is added to the system, an administrator just has to learn what new events and actions can be included in a control policy, not a completely new set of configuration commands.
Dynamic Policy Updates
Traditionally, subscriber policy has been determined at one point only, at session establishment time, once the principal identity of a subscriber has been authenticated. ISG introduces a dynamic policy model in which session policy may be altered at any time.
Session policy is evaluated at session start and may be reassessed whenever additional identity or service selection information is gleaned from the subscriber via the access protocol. In addition, policy may be updated for a session through the activation of control policies or by means of CoA commands from an external application. In the latter case, the external application may update policy as a result of administrator activity, back-end processing, or subscriber activity (such as service selection at a web portal).
Benefits of ISG
ISG provides the following benefits:
A common system for session management across Cisco products and access technologies. New access protocols, forwarding protocols, and features may be plugged in with minimal impact and maximum potential for reuse.
Separation of the concerns of subscriber identification, service application, and subscriber access and session type.
Flexible session definitions.
Flexible session detection.
Flexible, iterative approach to identification, service activation, and policy activation.
Different trust levels. Session authorization is not contingent on authentication.
Control policies. Control policies facilitate distributed policy decision-making, reducing round-trip latency between the edge device and policy server, and allow system event handling to be described in a consistent and intuitive manner.
Common policy model and language for control and traffic policy.
Provision for dynamic policy updates via CoA (through service activation or “policy push”).
Use of existing Cisco IOS infrastructure to provide session functionality.
Use of existing Cisco IOS infrastructure to track session state and life cycle.
Creation of a session context at first instance of subscriber interaction, thereby facilitating the immediate application of policy to subscriber traffic.
Flexible distribution of service data.
Range of accounting options, including prepaid accounting, postpaid accounting, tariff switching for prepaid and postpaid accounting, interim accounting, event-based accounting, and flow-based accounting.
Single sign-on services to an external application.
Flexible infrastructure in support of “equal-access” deployments, such as service-based Dynamic Host Configuration Protocol (DHCP) pool and DHCP server determination, dynamic readdressing through DHCP, and VRF transfer.
Support for standard external interfaces, such as RADIUS and CoA.
Planning for ISG Implementation
ISG is very flexible and supports a wide variety of functionality. Before you begin to configure ISG, you should plan your system carefully. The following sections describe some of the important aspects of your system that you should consider:
Trust levels are determined by the security needs of a particular application domain and the inherent security afforded by the subscriber network. In the following situations, it may not be necessary to authenticate subscriber identity:
When security is not considered paramount
When end-to-end security is provided in-band
When the subscriber network is intrinsically secure
Whether or not subscribers must be authenticated will influence the choice of access protocol. When authentication is not required, control policies may be used to determine authorization and other session policy on the basis of subscriber identity.
Where authentication is considered necessary, the authenticated identity may be trusted:
For the duration of the session
Until a periodic reauthentication is instigated
Beyond the duration of a session; for example, for the lifetime of a subscription
For complete security, cryptographic methods may be used to secure the session (to the edge) following authentication, obviating the need for reauthentication. However, there are administrative and performance overheads associated with this practice.
Subscriber Access Model
The trust model will, to a large extent, determine the choice of access protocol. However, the access model will also depend on other factors such as the underlying media (for example, ATM versus Ethernet), type of endpoint (for example, PC, cell phone, PDA), mobility requirements, the system’s ability to influence the software installed on a subscriber device, and scalability requirements.
Single Sign-On Requirements
Where a subscriber will have access to services provided by other devices in the administrative domain of the access or service provider, is an additional authentication required, or should the identity of the subscriber be trusted? It may be necessary for the latter device to query the access device to collect additional subscriber identity information and ascertain whether the subscriber has already been authenticated by the access device. The single sign-on facility is provided through the “session query” capability of CoA.
How should subscribers be given access to network services? Network forwarding options include the following:
Layer 2 connections; for example, a Layer 2 Tunneling Protocol (L2TP) tunnel to an L2TP network server (LNS)
Layer 3 connections, by associating all session packets with a particular VRF or routing domain
How should subscriber policies be organized into services, if at all? Some considerations for service packaging include the following:
Are certain policy combinations common to multiple subscribers?
Are shared policy combinations dependent on a particular forwarding domain?
Is it necessary for a subscriber to move between service domains?
Should services be defined on the device or in a remote repository? Externally defined services will be cached locally for as long as they are activated for one or more sessions.
How should subscribers be billed for service usage? Billing options include the following:
Billing by usage of time or volume
Billing in advance (prepaid) or at regular intervals (traditional postpaid)
Billing according to policies provisioned for the session
Billing according to the time of day (tariff switching)
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.
To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1 Feature Information for the Overview of ISG
Feature Configuration Information
ISG:Session: Auth: Single Sign-on
Cisco IOS XE Release 2.2.
Single sign-on eliminates the need to authenticate a session more than once when a subscriber has access to services provided by other devices in the administrative domain of the access or service provider.