Terminology
This section
defines some of the terms used in this manual.
Contexts
A context is
a logical grouping or mapping of configuration parameters that pertain
to various physical ports, logical IP interfaces, and services.
A context can be thought of as a virtual private network (VPN).
The system supports
the configuration of multiple contexts. Each is configured and operates
independently from the others. Once a context has been created, administrative
users can then configure services, logical IP interfaces, subscribers,
etc.for that context. Administrative users would then bind the logical
interfaces to physical ports.
Contexts can also
be assigned domain aliases, wherein if a subscriber’s domain
name matches one of the configured alias names for that context,
then that context is used.
Contexts on the system
can be categorized as follows:
- Source context: Also referred to as the “ingress” context, this context provides the subscriber’s point-of-entry in the system. It is also the context in which services are configured. For example, in a CDMA2000 network, the radio network containing the packet control functions (PCFs) would communicate with the system via R-P interfaces configured within the source context as part of the PDSN service.
- Destination context: Also referred to as the “egress” context, this context is where a subscriber is provided services (such as access to the Internet). Destination contexts are typically named after particular domains. For example, the system’s destination context would be configured with the interfaces facilitating subscriber data traffic to/from the Internet, a VPN, or other PDN.
- AAA context: This context provides authorization, authentication, and accounting (AAA) functionality for subscriber and/or administrative user sessions. The AAA context contains context-specific AAA policies, the logical interfaces for communicating with AAA servers, and records for locally configured subscribers and/or administrative users.
IMPORTANT:
It is important to
note that “source,” “destination,” and
AAA functionality can optionally be configured within the same context
or be configured as separate contexts. As a general rule, however,
if the carrier owns and operates the AAA server, it is recommended
that AAA functionality be configured within the source context.
Conversely, if a home network other than the carrier’s
own operates the AAA server, it is recommended that AAA functionality
be configured within the destination context.
AAA Realms
A AAA realm
is the location within the AAA context where subscriber-specific
templates can be defined that are applied to subscribers who match
that realm. A AAA realm is considered part of the AAA context; and
the AAA context itself is also considered to be a realm. There may
be many different AAA realms defined within a single AAA context.
An example of a realm
would be that within a source context named ingress, there could
be a domain alias of nova.com, another domain alias of bigco.com,
and a single AAA configuration that is used by the entire system.
In this example, the source context is also serving as a AAA context.
There would be three specific AAA realms in this case; ingress, nova.com,
and bigco.com, since all three could have their own subscriber templates
defined.
The primary purpose
of a AAA realm is to host a subscriber template for each realm that provides
AAA attributes that may be used in the event that an authenticated
subscriber’s access-accept message from RADIUS fails to
contain certain attributes. In this case, the default attributes contained
in the realm-based subscriber template would be used. However, if
the RADIUS authentication message contains an attribute from that
subscriber’s RADIUS user profile, then that information
will be used to overwrite any default attribute parameters that
are contained in the subscriber template.
More information about
subscriber templates will be provided later in this chapter when subscribers
are discussed.
Realms must be globally
unique in their naming convention in that each realm name can only
be used in one context in one system.
Ports
Ports are the
physical interfaces that reside upon the system’s line
cards (Ethernet 10/100, Gigabit Ethernet 1000 Line Cards
and the four-port Quad Gigabit Ethernet Line Card otherwise known
as the Quad Gig-E or QGLC). Ethernet Port configuration addresses
traffic profiles, data encapsulation methods, media type, and other
information needed to allow physical connectivity between the system
and the rest of the network. Ports are identified by the chassis
slot number in which the line card resides, followed by the number
of the physical connector on the line card. For example, Port 24/1
identifies connector number 1 on the card in slot 24.
Logical Interfaces
Prior to allowing
the flow of user data, the port must be associated with a virtual
circuit or tunnel called a logical interface. A logical interface
within the system is defined as the logical assignment of a virtual
router instance that provides higher-layer protocol transport, such
as Layer 3 IP addressing. Interfaces are configured as part of the
VPN context and are independent from the physical port that will
be used to bridge the virtual interfaces to the network.
Logical interfaces
are assigned to IP addresses and are bound to a specific port during
the configuration process. Logical interfaces are also associated
with services through bindings. Services are bound to an IP address
that is configured for a particular logical interface. When associated,
the interface takes on the characteristics of the functions enabled
by the service. For example, if an interface is bound to a PDSN
service, it will function as an R-P interface between the PDSN service
and the PCF. Services are defined later in this section.
There are several
types of logical interfaces that must be configured to support Simple
and Mobile IP data applications as described below:
- Management interface: This interface provides the system’s point of attachment to the management network. The interface supports remote access to the system CLI, Common Object Request Broker Architecture (CORBA)-based management via the Web Element Manager application, and event notification via the Simple Network Management Protocol (SNMP). The system defaults to a Local context which should not be deleted. Management interfaces are defined in the Local management context and should only be bound to the ports on the Switch Processor Input/Output (SPIO) cards .
- R-P interface: Also referred to as the A10/A11 interface, this interface is the communications path between the Radio Node (also referred to as a PCF) and the PDSN. The A10/A11 interface carries traffic signaling (A11) and user data traffic (A10). The A10/A11 interface is implemented in accordance with IS-835. R-P interfaces are bound to ports on either the Ethernet 10/100 or Ethernet 1000/QGLC Line Cards.
- Pi interface: The packet interface (Pi) is the communications path between the PDSN/Foreign Agent (PDSN/FA) and the Home Agent (HA) for Mobile IP applications. Pi interfaces are bound to ports on either the Ethernet 10/100 or Ethernet 1000/QGLC Line Cards.
- PDN interface: The interface to the packet data network (PDN). For Simple IP applications, this is the communications path between the PDSN and the PDN. For Mobile IP applications, this is the communications path between the HA and the PDN.PDN interfaces are bound to Ethernet ports.
- AAA interface: The AAA interface is the connection between the PDSN and/or HA and the network servers that perform AAA functions. With this release of the system, the Remote Authentication Dial-In User Service (RADIUS) Protocol is used for communication on this interface.AAA interfaces are bound to Ethernet ports. However, AAA interfaces can also be bound to the Local management context and to ports on the SPIO to provide AAA functions for subscribers, and for context-level administrative users.
- ICC interface: Inter-context communication (ICC) interfaces are only required when multiple services are configured in the same context. As mentioned previously, services are bound to interfaces. Creating an ICC interface provides a communication path between the services. For example, if an FA and HA service were configured in the same context, the FA service would need to be bound to an address assigned to the ICC interface and the HA service would need to be bound to a secondary address on the same ICC interface to provide a communications path between the two services.The ICC interface must be configured with multiple addresses (one per service that it is facilitating) and bound to a physical port.
Bindings
A binding is an association
between “elements” within the system. There are
two types of bindings: static and dynamic.
Static binding is
accomplished through the configuration of the system. Static bindings
are used to associate:
- A specific logical interface (configured within a particular context) to a physical port. Once the interface is bound to the physical port, traffic can flow through the context just as if it were any physically defined circuit. Static bindings support any encapsulation method over any interface and port type.
- A service to an IP address assigned to a logical interface within the same context. This allows the interface to take on the characteristics (i.e., support the protocols) required by the service. For example, a PDSN service bound to a logical interface will cause the logical interface to take on the characteristics of an R-P interface within a 3G CDMA2000 network.
Dynamic binding associates
a subscriber to a specific egress context based on the configuration
of their profile or system parameters. This provides a higher degree
of deployment flexibility as it allows a wireless carrier to support
multiple services and facilitates seamless connections to multiple
networks.
Services
Services are configured
within a context and enable certain functionality. The following
services can be configured on the system:
- PDSN services: Required for both Simple IP and Mobile IP applications, PDSN services define PDSN functionality for the system. The PDSN service must be bound to a logical interface within the same context. Once bound, the interface takes on the characteristics of an R-P interface. Multiple services can be bound to the same logical interface. Therefore, a single physical port can facilitate multiple R-P interfaces.The system treats the connection between the PCF and the PDSN service as a VPN (referred to as an RP-VPN). Individual R-P sessions are identified on this RP-VPN using the PCF address, the PDSN interface address, and the R-P Session ID.
- FA services: Currently supported only for use in CDMA 2000 networks, FA services are configured to support Mobile IP and define FA functionality on the system. The system supports multiple Mobile IP configurations. A single system can perform the function of a FA only, an HA only, or a combined PDSN/FA/HA. Depending on your configuration, the FA service can create and maintain the Pi interface between the PDSN/FA and the HA or it can communicate with an HA service configured within the same context.The FA service should be configured in a different context from the PDSN service. However, if the FA service will be communicating with an HA that is a separate network element, it must be configured within the same context as and be bound to the Pi interfaces that allow it to communicate with the HA.
- HA services: Currently supported only for use in CDMA 2000 networks, HA services are configured to support Mobile IP and define HA functionality on the system. Depending on your configuration, the HA service can be used to terminate the Pi interface from the FA or it can communicate with an FA service configured in the same context. If the HA service is configured within the same system as the PDSN/FA, then it should be configured within the same context as the FA service. This context, then, would also facilitate the PDSN interfaces to the data network.If the HA service is configured in a separate system, it should be configured in the same context as and bound to the Pi interfaces that allow it to communicate with the FA.
- LAC services: LAC services are configured on the system to provide Layer 2 Tunneling Protocol (L2TP) access concentrator (LAC) functionality. LAC services can be configured and used within either CDMA 2000 or GPRS/UMTS networks to provide secure tunneling to an L2TP network server (LNS) on a remote PDN.
The following figure
diagrams the relationship between services, interfaces, and contexts within
the system for CDMA 2000 networks.
AAA Servers
For most configurations,
AAA servers will be used to store profiles, perform authentication,
and maintain accounting records for each mobile data subscriber.
The AAA servers communicate with the system over the AAA interface.
The system supports the configuration of up to 128 AAA servers with
which to communicate.
It is important to
note that for Mobile IP, there can be foreign AAA (FAAA) and home
AAA (HAAA) servers. The FAAA server(s) typically resides in the
carrier’s network. The HAAA server(s) could be owned and
controlled by either the carrier or the home network. If the HAAA server
is owned and controlled by the home network, accounting data can
be transferred to the carrier via a AAA proxy server.
For most configurations,
AAA servers will be used to store subscriber profiles and perform authentication.
In addition, RADIUS AAA servers may be used to maintain accounting
records for each mobile data subscriber as opposed to a GTPP-based
Charging Gateway Function (CGF). The AAA servers communicate with
the system over the AAA interface. The system supports the configuration
of up to 128 AAA servers with which to communicate.
Subscribers
Subscribers are the
end-users of the service who gain access to the Internet, their
home network, or a public network through the system. There are
three primary types of subscribers/users:
- RADIUS-based Subscribers: The most common type of subscriber, these users are identified by their International Mobile Subscriber Identity (IMSI) number, an Electronic Serial Number (ESN), or by their domain name or user name and are configured on and authenticated by a RADIUS AAA server. Upon successful authentication various attributes (contained in the subscriber profile) are returned that dictate such things as session parameter settings (e.g. protocol settings, IP address assignment method, etc.), and what privileges the subscriber has (e.g. Simple IP, Mobile IP, etc.).Attribute settings received by the system from a RADIUS AAA server take precedence over local-subscriber attributes and parameters configured on the system.
- Local Subscribers: These are subscribers, primarily used for testing purposes, that are configured and authenticated within a specific context. Unlike RADIUS-based subscribers, the local subscriber’s user profile (containing attributes like those used by RADIUS-based subscribers) is configured within the context where they are created.When local subscriber profiles are first created, attributes for that subscriber are set to the system's default settings. The same default settings are applied to all subscriber profiles including the subscriber named default (created automatically by the system for each system context; refer to the Default Subscribers and Realm-based Subscriber Templates section for more information). When configuring local profile attributes, the changes are made on a subscriber-by-subscriber basis.Attributes configured for local subscribers take precedence over context-level parameters. However, they could be over-ridden by attributes returned from a RADIUS AAA server.
- Management Subscribers: A management user is an authorized user who can monitor, control, and configure the system through its command line interface (CLI) or Web Element Manager application. This management can be performed either locally, through the system’s console port, or remotely through the use of the Telnet or secure shell (SSH) protocols. Management users are typically configured as a local subscriber within the localout-of-band management context, which is used exclusively for system management and administration. Like a local subscriber, the management subscriber’s user profile is configured within the context where they are created (in this case the localout-of-band management context). However, management subscribers may also be authenticated remotely via RADIUS, if a AAA configuration exists within the localout-of-band management context.
Default Subscribers and Realm-based Subscriber Templates
Used for RADIUS-based
subscribers, default subscribers – created on a per context
basis, and subscriber templates – optionally created on
per realm basis, contain default AAA attributes that can be used
by subscribers who are remotely authenticated within a specific
context or domain alias (AAA realm) when needed.
Default Subscriber
When each context
is created, the system automatically creates a subscriber named
default. There is only one default subscriber per context. The profile
for the subscriber named default provides a configuration template
of attribute values for subscribers who are remotely authenticated
in that context. Any subscriber information that is not included
in a RADIUS-based subscriber’s user profile is configured
according to the defaults defined for the default subscriber.
No matter where created
all default subscribers initially have the same attributes set.
The attributes for the default subscriber in each context and be
changed from the CLI on a context by context basis.
IMPORTANT:
Realm-based Subscriber Templates
As defined earlier,
a context can have numerous domain aliases that allows a single
context to serve numerous different subscribers who have different
domain names. When assigned, these domain aliases become AAA realms
within the context.
Since each realm is
used for a specific group of subscribers (e.g. corporate subscribers
who may only have access to a specific corporate network that is
protected by a virtual private network), each realm must have the
ability to define what AAA attributes should be applied to these
different subscriber groups. This is achieved through the use of
realm-based subscriber templates.
A subscriber template
contains defined attributes that are specific to a select subscriber
who belongs to that realm. Like the default subscriber (subscriber
named default) who has a context-level set of configuration attributes,
the subscriber template is used to provide default attribute values
that may be used should a RADIUS user profile for a subscriber belonging
to the specific realm fail to contain a needed attribute.
IMPORTANT:
If a realm-based subscriber
template is not created for a specified realm, then the system will use
the attributes configured for default subscriber (named default)
within the context where the AAA realm exists.
Below is an example
of how realm-based subscriber templates may be used.
As depicted above,
a context named “ingress” contains:
- a PDSN service named “PDSN”.
- a AAA configuration that is used to communicate with an external RADIUS server.a default subscriber for the context named “default”. This default subscriber has an idle timeout attribute value of 45000 seconds.
- three additional realms,
based on the following domain alias names:
- “mega.com”, which has a realm-based subscriber template named “megauser”. This template contains an idle timeout attribute value of 36000 seconds.
- “bigco.com”, which has a realm-based subscriber template named “bigco”. This template contains an idle timeout attribute value of 3600 seconds.
- “smallco.com”, which has no realm-based subscriber template defined.
For this example,
we will assume that all subscribers enter the system through the
PDSN service defined in the [ingress] context.
Configuration procedures and context selection methods will be provided
in other sections in this document.
If a subscriber enters
the system with a domain name that matches the context name “ingress” (example:
user1@ingress), then the [ingress] context
would be used for authentication. If the RADIUS server authenticates
the subscriber and returns no value for the idle-timeout attribute,
then this subscriber would be assigned the value contained in the
subscriber default configuration.If a subscriber named user@mega.com
enters the system with a domain name that matches a configured domain
alias within the [ingress] context, in this case “mega.com”,
then the [ingress] context would be used for authentication.
However, since a realm-based subscriber template named “megauser” is
defined within this AAA realm, then should the RADIUS server return
no value for the idle-timeout attribute, then this subscriber would
be assigned the value contained in the “megauser” subscriber
template.
If a subscriber named
user@bigco.com enters the system with a domain name that
matches a configured domain alias within the [ingress] context,
in this case “bigco.com”, then the [ingress] context
would be used for authentication. However, since a realm-based subscriber
template name “bigco” is defined within this AAA
realm, any attributes not returned could be assigned from this subscriber
template. In this example, the RADIUS server returns an idle-timeout
of 18000 seconds. Because the RADIUS user profile contained a value
for this attribute, the system would use that value (18000) rather
than the value defined in the subscriber template.
If a subscriber name
user@smallco.org enters the system with a domain name that
matches a configured domain alias within the [ingress] context,
in this case “smallco.org”, then the [ingress] context
would be used for authentication. Note that the “smallco.org” domain
alias does not have a realm-based subscriber template defined. In
this case, the system would obtain any attribute values not returned
from the RADIUS server from the subscriber default configuration.
So if no attribute value was returned from RADIUS, user@smallco.org
would be assigned an idle-timeout value of 45000 seconds.
