SecGW is enabled via a StarOS image running in a virtualized environment supported on the ASR 9000 VSM. StarOS runs in four hypervisor-initiated virtual machines (one per CPU) on the VSM.

The VSM is a service blade for the ASR 9000 router that supports multiple services and applications running simultaneously on top of a virtualized hardware environment.

Figure 2. VSM High Level Block Diagram

The ASR 9000 services architecture encompasses how the platform interfaces with the services independent of where the service is actually instantiated. It provides a common control plane, management plane and data plane infrastructure such that a consistent end user experience is provided whether the service is running on a service blade, on the RSP, on an attached appliance or server, or even running inline in the router.

The figure below shows the relationship between IOS-XR running on the ASR 9000 and StarOS running on the VSM.

Figure 3. IOS-XR and VSM

The 10GE interfaces on the SecGW virtual machines are visible as 10GbE interfaces on the ASR 9000. The ASR 9000 line card forwards IP traffic to VSM 10GbE ports.

There are four CPU sockets on the VSM. Each CPU supports multiple cores. A VPC-VSM instance uses multiple virtual CPUs (vCPUs) consisting of available cores for its virtual machine.

Each CPU socket is associated with a Crypto engine. PCI Ports are also assigned to accept traffic from the ASR 9000 line cards.

The table below shows how resources are assigned among the four CPUs on the VSM.

Only twelve PCI ports can be mapped to ASR 9000 line card traffic. The table below shows how the interfaces are distributed.

Virtualized Packet Core for VSM (VPC-VSM) consists of the set virtualized mobility functions that implement mobility specific services and applications within the core of the network. VPC-VSM is essentially StarOS running within a Virtual Machine (VM).

VPC-VSM only interacts with supported hypervisors. It has little or no knowledge of physical devices.

Each VPC-VSM VM takes on the roles of an entire StarOS system. The only interfaces exposed outside the VM are those for external management and service traffic. Each VM is managed independently.

For a complete description of VPC-VSM functionality, refer to the VPC-VSM System Administration Guide.

The StarOS-based Security Gateway (SecGW) application is a solution for Remote-Access (RAS) and Site-to-Site (S2S) mobile network environments. It is implemented via StarOS as a WSG (Wireless Security Gateway) service that leverages the IPSec features supported by StarOS.

SecGW delivers the S2S IP Encryption capabilities required in UMTS/HSPA and LTE 3GPP LTE/SAE network architectures.

For complete descriptions of supported IPSec features, see the IPSec Reference.

Each SecGW creates a oneP session with the ASR 9000 for route insertions, policy creation and flow creation. For additional information, refer to the oneP Communication chapter.

The process recovery feature stores backup Security Association (SA) data in an AAA manager task. This manager runs on the SecGW where the recoverable tasks are located.

Figure 4. Process Recovery Diagram

In this redundancy scenario, Interchassis Session Recovery ICSR utilizes the Service Redundancy Protocol (SRP) implemented between VMs in a VSM running separate instances of VPC-VSM/SecGW in the same ASR 9000 chassis.

VSM card status data is exchanged between VPN managers on active and standby VSMs via SRP. SA data is also exchanged via SRP.

The VPC-VSM System Administration Guide fully describes ICSR configuration procedures.

SecGW HA supports hot standby redundancy between VMs in a VSM in different ASR 9000 chassis. The Standby VSM is ready to become active once a switchover is triggered. SA re-negotiation is not required and traffic loss is minimal.

For additional information, see the Reverse Route Injection (RRI) chapter.

HA involves configuration of both SRP and ConnectedApps (CA) for RRI to work.

HA employs ConnectedApps (CA) communication between the client running on the wsg-service VM and IOS-XR running on the ASR 9000.

StarOS connectedapps commands configure the CA client parameters, including those associated with HA mode. For additional information, refer to the oneP Communication chapter.

In a RAS scenario, a remote host negotiates a child SA with the SecGW and sends traffic inside the child SA that belongs to a single IP address inside the remote host. This is the inner IP address of the child SA. The outer IP address is the public IP address of the remote host. The addresses on the trusted network behind the SecGW to which the host talks could be a single IP or a network.

Figure 5. RAS Tunnel

In an S2S scenario, the remote peer sets up a child SA to the SecGW. The source of the traffic inside the child SA can be from multiple IP addresses on the remote peer's side. As in the remote access scenario, the addresses on the trusted network behind the SecGW can be a single IP or a network.

In this scenario also, the remote peer can setup multiple child SAs to the SecGW.

For S2S tunnels established using the WSG service, the TSi and TSr contain protocol as well as source and destination IP ranges.

Figure 6. S2S Tunnel