An IP session includes all the traffic that is associated with a single subscriber IP address. If the IP address is not unique to the system, other distinguishing characteristics such as a VRF or a MAC address form part of the identity of the session. ISG can be configured to create IP sessions when it receives DHCP packets, packets with unclassified IP or MAC addresses, or RADIUS packets. See the “IP Subscriber Session Initiation” section for more information.

IP sessions may be hosted for a connected subscriber device (one routing hop from the ISG) or a subscriber device that is more than one hop from the gateway.

An IP interface session includes all the IP traffic that is received on a specific physical or virtual interface. IP interface sessions are created when the IP interface session commands are entered. The session remains continuous even when the interface is shut down. By default, IP interface sessions come up in the unauthenticated state with full network access.

IP interface sessions can be used in situations where a subscriber is represented by an interface (with the exception of PPP) and communicates using more than one IP address. For example, a subscriber using a routed bridge encapsulation (RBE) access might have a dedicated ATM virtual circuit (VC) to home customer premises equipment (CPE) that is hosting a number of PCs.

An IP subnet session represents all the traffic that is associated with a single IP subnet. IP subnet sessions are used to apply uniform edge processing to packets associated with a particular IP subnet. When an IP subnet session is configured, ISG treats the subnet as a single subscriber, that is ISG features and functionality are applied to the subnet traffic as an aggregate.

IP subnet sessions are supported for routed IP subscriber traffic.

IP subnet sessions are created in the same way as IP sessions, except that when a subscriber is authorized or authenticated and the Framed-IP-Netmask attribute is present in the user or service profile, ISG converts the source-IP-based session into a subnet session with the subnet value in the Framed-IP-Netmask attribute.

Note

Where an ingress interface maps to a single subnet, the subnet might be accommodated with an IP interface session. However, if an ISG device is more than one hop away from a subscriber, and multiple subnets could be accessible through the same interface, IP subnet sessions may be defined to distinguish the traffic and apply appropriate edge functionality to each subnet.

Layer 2-connected subscribers are either directly attached to the physical interfaces of ISG or connected to ISG through a Layer 2 access network, such as a bridged or a switched network. Layer 3 forwarding is either absent or not used to direct subscriber traffic in the Layer 2 access network. IP addresses of the subscribers may or may not be on the same subnet as the Layer 2-connected physical interfaces. The figure below shows an example of a Layer 2-connected access network.

Figure 1. Layer 2-Connected Access Network

Roaming can be configured on Layer 2-connected IP subscriber sessions by using the ip subscriber l2-roaming command. When a Layer 2-connected IP subscriber tries to establish a session with an existing MAC address and a new IP address on an interface that is different from the one that is running the current session, ISG terminates the existing session and creates a new session with a new MAC address-IP address pair. When the subscriber tries to establish a session with an existing MAC address and a new IP address on the same interface that is running the current session, ISG blocks the new session.

For routed access networks, subscriber traffic is routed through a Layer 3 access network with at least one transit router before reaching the ISG. IP addresses of the subscribers are at least routable in the Layer 3 access network. Layer 3 access networks contain a single routing domain and therefore, do not support overlapping IP addresses. The figure below shows an example of a routed access network.

Figure 2. Routed Access Network

IP subscribers either have IP addresses configured statically or obtain IP addresses dynamically through some network protocol that has the ability to assign IP addresses. For a subscriber to be routable within a given IP service domain, the subscriber must present a domain-specific IP address to the network. If a subscriber transfers between IP service domains (including any private domain managed by the access provider), the IP address presented to the network must change to reflect the new domain.

The following sections describe the methods of IP address assignment that ISG supports for each type of Layer 3 session:

An IP address falls in either the public or the private IP address category, irrespective of the method used to assign the IP address to the IP subscriber. If an IP subscriber is assigned a private IP address and the subscriber has to reach the Internet, a Layer 3 gateway, such as an ISG or a firewall, that is present between the subscriber and the Internet must perform Network Address Translation (NAT) for the subscriber’s private IP address.

When the access network is a Layer 2-connected network, a subscriber IP address can be either native or foreign to an access interface. A native subscriber IP address belongs to the subnet provisioned on the access interface. A foreign subscriber IP address does not belong to the subnet provisioned on the access interface. A foreign subscriber IP address could result when a retail ISP assigns an IP address to the IP subscriber from its own IP address allotment, which is different from the wholesale ISPs, or when an IP subscriber with a static IP address that is native in the home access network roams to a foreign access network. To support IP subscribers with foreign IP addresses, ISG must be able to respond to Address Resolution Protocol (ARP) requests that originate from foreign IP addresses with a MAC address of the ISG itself. Because the access network is Layer 2-connected, ISG maintains an adjacency to every subscriber.

When the access network is a routed network, a subscriber IP address must be routable in the access network; otherwise, subscriber traffic will never be able to reach ISG. ISG may not have an adjacency for each subscriber in this case, but has an adjacency of the next hop towards a subscriber. The next hop is determined by the routing process on ISG.

When an access network is deployed without VPN capability, the IP address space in the access network is shared among all IP subscribers. When the IP addresses are assigned dynamically, care must be taken to ensure that these addresses do not overlap. When overlapping IP addresses are assigned to IP subscribers intentionally, the access network should use a Layer 2 separation mechanism to differentiate the IP address spaces. For example, the access network may put each IP address space in a different VLAN.

When the access network serves both local IP subscribers and roaming users, the static private IP address of a roaming subscriber may overlap the native private IP address of another subscriber. For example, a public wireless hotspot that generally assigns dynamic IP addresses may provide access to occasional roaming users with statically configured IP addresses. To support this special overlapping condition, all IP subscribers must be in a Layer 2-connected access network in which overlapping MAC addresses do not exist. In this case, IP subscribers can be distinguished using MAC addresses.

When ISG is in the path of DHCP requests (as either a DHCP server or a DHCP relay), ISG can influence the IP address pool and the DHCP server that are used to assign subscriber IP addresses. To enable ISG to influence the IP addresses assigned to subscribers, associate a DHCP address pool class with an address domain. The DHCP address pool class must also be configured in a service policy map, service profile, or user profile that is associated with a subscriber. When a DHCP request is received from a subscriber, DHCP uses the address pool class that is associated with the subscriber to determine which DHCP address pool should be used to service the request. As a result, on a per-request basis, an IP address is either provided by the local DHCP server or relayed to a remote DHCP server that is defined in the selected pool.

By definition, subscriber IP addresses are at least routable in the access network. If the access network is a routed network, subscriber IP addresses can be used to uniquely identify IP subscribers.

When using a subscriber IP address as the identifier, ISG assumes that the subscriber IP address is unique. If the access network is deployed with Layer 3 load balancing, redundancy, or asymmetric routing, ISG also assumes that IP traffic from the same IP subscriber may arrive at different access interfaces. To support this type of deployment, ISG assumes a single IP address space for all access interfaces connecting to the same access network.

If there is a requirement to support several IP address spaces over a single physical access network, the access network must use some Layer 2 encapsulation to create a separate logical access network for each IP address space. In this case, ISG can still have a single IP address space for all the logical access interfaces that connect to a logical access network.

When subscriber IP addresses are private IP addresses, the access network must be able to route such subscriber traffic. If the subscriber traffic is destined for the Internet, NAT must be performed.

For routed IP subscribers, the subscriber IP address serves as the key for an IP session. ISG associates IP traffic with an IP session as follows:

• In the upstream direction, the source IP address of an IP packet is used to identify the IP session. The source IP address is the subscriber IP address.

• In the downstream direction, the destination IP address of an IP packet is used to identify the IP session. The destination IP address is the subscriber IP address.

If the IP subscriber is a VPN user, the subscriber IP address must be routable in both the global routing table and the VPN routing table on ISG.

For an IP subnet subscriber, a subscriber IP address is defined as an IP prefix address instead of a /32 IP host address. This IP prefix covers a range of IP addresses used by end users but represents a single logical IP subscriber for ISG. In this deployment, all end users share the same connectivity and services provided by ISG.

To normalize the classification of IP subscribers that have different network masks, ISG uses the network mask in conjunction with the subscriber IP address for routed IP subscribers.

You must configure the collect identifier mac-address command at the start of a session. This instructs the ISG devices to store the MAC address as part of the session identifiers. For routed IP subscriber sessions, the MAC address is collected from the DHCP server using the DHCP lease Query Protocol. For information about configuring the command, see the “Configuring ISG Control Policies” module.

The DHCP lease query message is a DHCP message type transmitted from a DHCP relay agent to a DHCP server. A DHCP lease query-aware relay agent sends the location of an IP endpoint to the DHCP lease query message.

The DHCP lease query transaction is a DHCP transaction with special message types that enable clients to query DHCP servers regarding the owner and the lease expiration time of an IP address.

A Layer 2-connected access network can provide IP connectivity to IP subscribers with native IP addresses and foreign and overlapping IP addresses. Because subscriber IP addresses might not be unique in such an access network, ISG uses the subscriber MAC address to identify Layer 2-connected IP subscribers.

Traffic that comes from IP subscribers with private or overlapping IP addresses and that is destined to the Internet is subject to NAT.

For Layer 2-connected IP subscribers, both the subscriber MAC address (unique within a VLAN) and the IP address, serve as keys for the IP session and are used in the following directions:

• In the upstream direction, the VLAN ID and source MAC address of an IP packet are used to identify the IP session.

• In the downstream direction, the destination IP address and the VLAN ID of an IP packet are used to identify the IP subscriber context.

An IP session may be terminated in one of the following ways:

• DHCP lease expiry or DHCP release from client—If DHCP is used to detect a new session, its departure may also be signaled by a DHCP event.

• Application stop—The application stop command is typically used to terminate a session when a subscriber initiates an account logout from a web portal. An application stop may also result from the actions of an administrator, such as action taken in response to rogue behavior from a subscriber.

• Idle timeout and session timeout—Idle timeouts and session timeouts can be used to detect or impose termination of an IP session.

• Control policy—A control policy containing the service disconnect action can be used to terminate a session.

When an IP session is terminated (for example, by account logoff or session timeout) or lost (for example, by router reload), the client may continue to hold an unexpired DHCP lease. When the client continues to hold an unexpired DHCP lease, ISG performs a session restart to prevent the client’s IP connection from being nonfunctional until the DHCP lease expires. A control policy can be configured to define the actions that ISG performs when the session restart event occurs. If a policy is not defined, a default policy takes effect. The default policy causes ISG to disconnect the session after 60 seconds after a session restart and is the equivalent of the following configuration:

policy-map type control GLOBAL
 class type control always event session-restart
  1 service disconnect delay 60

This default policy appears in the output of the show subscriber policy rules command, as follows:

Rule: internal-rule-session-restart
 Class-map: always event session-restart
  Action: 1 service disconnect delay 60
  Executed: 0

New IP sessions may require a default service to allow subsequent subscriber packets to be processed appropriately; for example, to permit or force TCP packets to a captive portal where menu-driven authentication and service selection can be performed. A default service policy map or service profile may be configured for IP sessions to redirect traffic, enable port-bundle host-key functionality for session identification, or enable transparent autologin. A default service might also include a network service, which allows subscribers to access a web portal for authentication and service selection.

DSCP feature enables to mark or remark the flow of subscriber traffic with the configured DSCP making value. This can be used to provide low-latency to critical network traffic such as voice or streaming media while providing best service to non-critical services such as web traffic.

DSCP can be dynamically constructed from both Radius and Diameter Servers. Incase of Radius server Cisco VSA is used to provide details on the feature parameters and incase of Diameter server, GX-AVP’s are used to provide details on the feature parameters.

The following configuration example describes a simple ISG TC service with both rate-limiting and DSCP Remarking feature. The keyword dscp is newly introduced as part of this feature and is used to configure the feature through the command

policy-map type service SERVICE1 
  class type traffic Local7_TC
   dscp input 28     
   dscp output 28   
   police input 10000   
   police output 20000