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

• 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.

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).

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.

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.

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)