Overview of ISG

Overview of ISG

Last Updated: November 30, 2011

Intelligent Services Gateway (ISG) is a Cisco IOS 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.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see 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 at the end of this document.

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.

Information About ISG

What Is ISG

ISG is a structured framework in which edge access devices can deliver flexible and scalable services to subscribers. ISG handles the following key aspects of subscriber management:

  • Subscriber identification
  • 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. 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 1Sample 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.

ISG Principles

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:

Subscriber Sessions

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.

Subscriber Access

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.

Subscriber Identification

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 examples illustrate how an ISG might handle subscriber identity:

  • When the subscriber access protocol is PPPoA, the ATM virtual connection on which the call request arrived is available at session start. A control policy could be defined to forward all sessions on virtual path identifier (VPI) 1 over the tunnel defined by service "ISP-A" but to request a username from all subscribers attempting to access the network via VPI 2.
  • 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.

Subscriber Services

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
  • Control policies

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 Model

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.

Network Forwarding

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

Service Packaging

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.

Billing Model

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)

Additional References

Related Documents

Related Topic

Document Title

ISG commands

Cisco IOS Intelligent Services Gateway Command Reference

Technical Assistance



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.


Feature Information for the Overview of ISG

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 1Feature Information for the Overview of ISG

Feature Name


Feature Configuration Information

ISG:Session: Auth: Single Sign-on

12.2(28)SB 12.2(33)SRC 15.0(1)S

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.

In Cisco IOS Release 12.2(33)SRC, support was added for the Cisco 7600 router.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2011 Cisco Systems, Inc. All rights reserved.