Overview of ISG
Information About ISG
5
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.
Policies
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).
To Next Page
Loading...
Need help?
General