Encapsulation

The GRE encapsulation is based on RFC 1701/2784, Generic Routing Encapsulation (GRE), WLAN-GW will encapsulate according to RFC 1701 with all the flag fields set to 0, and no optional fields present. WLAN-GW is able to receive both encapsulation specified in RFC 1701 and RFC 2784, with all flag fields set to 0, and no optional fields present in the header.

Figure 161:  Encapsulation Example 

The encapsulation is built as follows:

Soft-GRE tunnel termination is performed on dedicated IOMs with MS-ISAs (referred to as WLAN-GW IOM). Each WLAN-GW IOM requires both MS-ISAs to be plugged in for soft-GRE tunnel termination. MS-ISA provides tunnel encapsulation/de-capsulation and anchor point for inter-AP mobility. The carrier IOMs of the ISA where the tunnel is terminated performs bandwidth shaping per tunnel (or per-tunnel per SSID). ESM function such as per-subscriber anti-spoofing (IP and MAC), filters, hierarchical policing, and lawful intercept are provided on the carrier IOM corresponding to the ISA where the subscriber is anchored.

N:M warm standby redundancy is supported for WLAN-GW IOM slots. Up to 4 WLAN-GW IOMs can be configured per 7750 SR. A maximum 3 WLAN-GW IOMs can be active. One or more WLAN-GW group can be configured with set of WLAN-GW IOMs, and a limit of active IOMs. Incoming soft-GRE tunnel contexts and corresponding subscribers are load-balanced amongst the MS-ISAs on active IOMs. Tunnel load-balancing is based on outer source IP address of the tunnel. Subscriber load-balancing is based on UE’s MAC address in the source MAC of the Ethernet payload in the tunnel. IOM(s) beyond the active limit act as warm standby, and take over the tunnel termination and subscriber management functions from failed WLAN-GW slot.MS-ISAs on WLAN-GW IOMs can also be configured to perform NAT function.

An ESM and soft-gre configuration is required for wlan-gw functions. Subscriber and group interfaces are configured as part of normal ESM configuration. The group interface is enabled for wlan-gw by configuration. L2oGRE is the currently supported soft tunnel types. The wlan-gw related configuration includes the following:

Data Path

In the upstream direction, the ingress IOM receiving the GRE tunneled packets from the WIFI AP or AC, load-balances tunnel processing amongst the set of MS-ISAs on the active WLAN-GW IOMs in the WLAN-GW group. The load-balancing is based on a hash of source IP address in the outer IP header. The MS-ISA receiving the GRE encapsulated packets removes the tunnel encapsulation, and internally tunnels (MAC-in-MAC, using BVPLS) the packet to an anchor MS-ISA on the WLAN-GW IOM. All traffic from a given UE is always forwarded to the same anchor MS-ISA based on hashing on UE’s MAC address. The MS-ISA provides a mobility anchor point for the UE. The UE MAC’s association to the GRE tunnel identifier is created or updated. The corresponding IOM provides ESM functions including ESM lookup, ingress ACLs and QoS. DHCP packets are forwarded to the CPM from the anchor IOM.

In the downstream direction, the IP packets are forwarded as normal from the network IOM (based on route lookup yielding subscriber subnet) to the IOM where the ESM host is anchored. ESM processing including per UE hierarchical policing and LI is performed on the anchor IOM. Configured MTU on the group-interface is enforced on the IOM, and if required packets are fragmented. The packets are then forwarded to the appropriate anchor MS-ISA housed by this IOM. Lookup based on UE’s MAC address is performed to get the tunnel identification, and the packets are MAC-in-MAC tunneled to the MS-ISA terminating the GRE tunnel. Aggregate shaping on the tunneled traffic (per tunnel or per retailer) is performed on the carrier IOM housing the tunnel termination MS-ISA. The tunnel termination MS-ISA removes MAC-in-MAC encapsulation, and GRE encapsulates the Layer 2 packet, which exits on the Layer 3 SAP to the carrier IOM. The GRE tunneled packet is forwarded to the right access IOM towards the WIFI AP based on a routing lookup on IP DA in the outer header.

Operational Commands

Egress per tunnel (or per tunnel, per SSID) QoS with aggregate rate-limit and port-scheduler.

Egress per tunnel (or per tunnel, per SSID) QoS with hierarchical virtual scheduler.

EAP-Based Authentication

In this model the WIFI AP supports a RADIUS client, and originates RADIUS messages based on 802.1x/EAP exchange with the UE. It sends EAP payload in RADIUS messages towards the RADIUS server or RADIUS proxy. 7750 WLAN-GW can be configured as a RADIUS proxy for the WIFI APs. The WIFI AP should be configured with the IP address of the RADIUS proxy, and should send authentication and accounting messages non-tunneled, natively routed to the RADIUS proxy. See Figure 162.

The RADIUS proxy function allows 7750 SR to look at the RADIUS authentication and accounting messages and create or update corresponding subscriber state. RADIUS proxy transparently forwards RADIUS messages between AP (authenticator) and the AAA server. The access-request message contains standard RADIUS attributes (including user-name), and the EAP payload. Standard authentication algorithms negotiated with EAP involve multiple round-trips (challenge/response) between AP (and UE) and the AAA server.

Once authentication is complete, AAA server passes back subscriber related configuration parameters as well as the computed session keys (aka pair-wise master key) for 802.11i to the AP. These keys are encrypted using shared secret between AP (authenticator) and the AAA server. 7750 WLAN-GW can optionally cache authentication information of the subscriber from access-request and access-accept messages. The cached information allows local authorization of subsequent DHCP messages from the UEs behind the AP against the cached state on the 7750 RADIUS proxy, and avoids another trip to the RADIUS server.

Figure 162:  EAP Authentication Call Flow with WLAN-GW RADIUS Proxy 

Portal Authentication

For SSIDs without 802.11i/WPA2-based key exchange and encryption, it is common to authenticate the user by directing user’s HTTP traffic to a portal, where the user is prompted for its credentials, which are verified against a subscriber database. The backend can optionally remember the MAC@ and subscriber credentials for a set period of time such that subsequent logins of the user do not require portal redirection. Some UEs support a client application (aka WISPr client), which automatically posts subscriber credentials on redirect, and parse HTTP success or failure response from the portal sever.

7750 WLAN-GW uses existing http-redirect action in IP filter to trigger redirect port-80 traffic. In case of open SSID, on receiving DHCP DISCOVER, MAC based authentication is performed with the RADIUS server as per configured authentication policy. The SLA-profile returned from RADIUS server in authentication-accept (or the default SLA-profile) contains the filter with http-redirect. Redirect via HTTP 302 message to the UE is triggered from the CPM. Once the user posts its credentials, RADIUS server generates a CoA-request message removing the http-redirect by specifying an SLA-profile without redirect action. If the portal authentication fails, the RADIUS server generates a disconnect-request message to remove the ESM host. In case of wlan-gw tunnel from the AP, the DHCP messages and data are both tunneled to the WLAN-GW. See Figure 163.

Figure 163:  Portal Authentication for Open SSIDs 

The following output displays a portal authentication for open SSIDs configuration example.

Triggered Interim Accounting-Updates

Using location based policy for WIFI subscribers is important. The business logic in AAA could use the location of the subscriber. Therefore, it is important to notify location change of the subscriber to AAA. Standard way to do this is by generating an interim accounting update when the WLAN-GW learns of the location change for a subscriber. The location for a WIFI subscriber can be inferred from MAC@ (preferred) or WAN IP@ of the AP.

For open-SSID, learning about mobility could be “data-triggered” or “IAPP packet triggered.” If triggered, interim accounting-update is configured via CLI, then on detecting a location change for the UE, an interim accounting-update is sent immediately to the AAA server with the new AP’s MAC@ (if already known to WLAN-GW). The accounting-update contains NASP-port-id (which contains the AP’s IP@), and circuit-id (from DHCP option-82) which contains AP’s MAC@ and SSID. In case of data-triggered mobility, if the new AP’s MAC@ is not already known to WLAN-GW, a GRE encapsulated ARP packet is generated towards the AP to learn the MAC@ of the AP. The AP is expected to reply with a GRE encapsulated ARP response containing its MAC@. The generation of ARP to learn the AP’s MAC@ is controlled via CLI. The GRE encapsulated ARP packet is shown in Figure 164.

Figure 164:  GRE Encapsulated ARP Request 

The standard ARP request must be formatted as follows:

The AP MUST generate a GRE encapsulated ARP response when it receives the GRE encapsulated ARP request for its WAN IP@ (that is used to source tunneled packets). The standard ARP response should be formatted as follows:

For 802.1x/EAP SSID, the location change (mobility) is learnt from an interim-accounting update from the AP. The called-station-Id (containing the AP MAC@) is compared against the current stored called-station-Id that the subscriber is associated with. If the called-station-id is different then the received interim accounting update is immediately forwarded to the accounting server, if triggered interim accounting-update is configured via CLI. In previous releases, the interim-update received from the AP is not immediately forwarded by the accounting proxy. Only a regularly scheduled interim-update is sent.

Operational Support

Following command shows if GRE encapsulated ARP request is enabled.

Signaling Call Flow

The decision to setup a GTP tunnel for a subscriber or locally breakout subscriber’s traffic is AAA based, and received in authentication response. If the traffic is to be tunneled to the PGW or GGSN, the signaling interface or PGW/GGSN interface would be provided via AAA. Absence of these attributes in the authentication response implicitly signifies local-breakout.

APN Resolution

The default WLAN APN is either configured via CLI or obtained from RADIUS in authentication response. The APN FQDN is constructed and resolved in DNS to obtain a set of GGSN/PGW IP addresses. The GTP sessions for UEs are load-balanced across the set of these gateways in a round-robin fashion. The APN FQDN generated for DNS resolution is composed of the Network-ID (NI) portion and the Operator-ID (OI) portion (MCC and MNC) as per 3GPP TS 29.303 and is formatted as APN-NI.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org. Only basic DNS procedure and A-records from DNS server are supported in this release. S-NAPTR procedure is not yet supported and will be added in a follow-on release. The NI portion or both NI and OI portions of the APN can be locally configured or supplied via RADIUS in a VSA (Alc-Wlan-APN-Name). By default the Operator-ID (OI) portion of the APN is learnt from the IMSI. If the RADIUS returns both the NI and OI portions in the APN attribute, then it is used as is for the FQDN construction. A DNS resolution is limited to a maximum of 20 IP addresses in this

Configuration Objects

The Mobile gateway (PGW or GGSN) IP address can be obtained via DNS resolution of the AP or provided by AAA server in authentication response. Profiles with signaling related configuration per mobile gateway can be created locally on the WLAN-GW. A map of these profiles (mgw-profiles) keyed on the IP@ of the mobile gateway is configurable per router. The serving network (<MCC> & <MNC>) that the WLAN-GW belongs to is configurable per system. The configurable signaling information per mobile gateway includes the type of interface between WLAN-GW and the mobile gateway (Gn, S2a, or S2b), path management parameters, and retransmission parameters for signaling messages. The type of signaling interface can also be explicitly overridden via RADIUS in authentication response. DNS servers and source IP address to be used for DNS resolutions can be configured in the service the APN corresponds to.

GTP related configuration on WLAN-GW

Figure 165:  GTP Signaling to PGW or GGSN Based on AAA Decision 

Figure 166:  LTE to WIFI Mobility with IP Address Preservation 

Figure 167:  WIFI to LTE Mobility with IP Address Preservation 

RADIUS Support

Table 98 describes 3GPP attributes and ALU specific attributes related to GTP signaling are supported.

QoS Support with GTP

WLAN-GW provides appropriate traffic treatment and (re)marking based on DSCP bits in the outer and/or inner header in GTP packet. In the downstream (PGW/GGSN to WLAN-GW) direction, the DSCP bits from the inner and/or outer header in GTP packet can be mapped to a forwarding class which can be preserved through the chassis as the packet passes to the egress IOM. In case of wlan-gw, as the packet passes through the ISA(s), the FC is carried through (based on static mapping of FC to dot1P bits in internal encapsulation using VLAN tags through the ISAs). The egress IOM (which forwards the GRE tunneled packet towards the AP) can classify on FC to set the DSCP bits in the outer GRE header based on configuration.

In the upstream direction, the DSCP bits from the wlan-gw can be mapped to the DSCP bits in the outer header in GTP encapsulated packet.

Selective Breakout

This feature adds support for selecting subset of traffic from a UE (via IP filter) for local forwarding, while tunneling the remaining traffic to GGSN/PGW. This allows the selected traffic to bypass the mobile packet core. The IP address for the UE comes from the GGSN/PGW during GTP session setup. Therefore, the selected traffic for local breakout from WLAN-GW requires an implicit NAT function in order to draw the return traffic back to the WLAN-GW. To support address overlap with GTP, the implicit NAT function is L2-aware. The selection of traffic for local breakout (local forwarding and NAT) is based on a new action in an IP filter applied to the UE. Selective breakout can be enabled on a per UE basis via RADIUS VSA (ALC-GTP-Local-Breakout) in access-accept. This attribute cannot be changed (enabled/disabled) via COA.

AA function (based on per-UE application profile) is supported for local breakout traffic. Also, LI (after NAT) is supported for local breakout traffic and is enabled via existing secure CLI (as stated in the 7x50 SR OS OAM Diagnostics Guide).

On traffic ingressing WLAN-GW from the UE, normal ESM host lookup and CAM lookup with ingress host filter is performed. If there is a match in the filter indicating “gtp-local-breakout,” the traffic is forwarded within the chassis to the WLAN-GW anchor IOM for the UE, where it is subjected to L2-aware NAT function and is IP forwarded to the destination based on FIB lookup. The inside IP address is the address returned in GTP, and the outside IP is an address belonging to NAT outside IP address range on the ISA. If there is no match in the filter, the traffic is GTP tunneled using the TEIDs corresponding to the ESM host. The traffic received from the network can be a normal L3 packet or a GTP encapsulated packet. The normal Layer 3 packet is expected to be destined to the NAT outside IP and is normally routed to the NAT ISA.

By default, per UE accounting includes counters that are aggregated across GTP and local-breakout traffic. Separate counters can be obtained by directing the GTP and local-breakout traffic into different queues associated with the corresponding ESM host. NAT information (outside IP and port range) associated with an ESM host subjected to selective breakout is included in accounting-updates.

Location Notification in S2a

This feature adds support on WLAN-GW for reporting UE’s WLAN location (TWAN Identifier IE) and cellular location (ULI IE) over S2a interface to PGW and UE’s cellular location (ULI IE) to GGSN (over Gn interface). Location information is useful for charging on PGW/GGSN.

Cellular Location over S2a

The “User Location Info” IE is included in “Create Session Request and is described in 3GPP TS 29.274 version 8.1.1 Release 8. The encoding for individual location identifiers (CGI, SAI, RAI, TAI, and ECGI) is also defined in the same reference (as shown in Figure 168).

Figure 168:  User Location Information 

The AP’s MAC@ and IP@ are provided to AAA server in RADIUS messages during EAP authentication and accounting. If AAA provides the cellular location (corresponding to this AP) in 3GPP attribute 3GPP-User-Location-Info in access-accept, and location reporting is enabled via CLI. The ULI IE will be included in GTPv2 “create session request”. The 3GPP-User-Location-Info attribute is described in 3GPP TS 29.061 v9.3.0.

Cellular Location over Gn Interface

The “User Location Info” IE (as shown in Figure 169) can be included in create-pdp-context message as described in 3GPP TS 29.060 V10.1.0. The geographic location type field describes the type of location included in the “Geographic Location” field that follows. The location can be CGI (cell global identification), SAI (service area identity), or RAI (routing area identity). The formats for these location identifiers are defined in the same reference 3GPP TS 29.060 V10.1.0.

Figure 169:  User Location Information IE 

AP MAC address and SSID is reported to AAA (including changes on mobility). AAA can then specify the ULI IE contents based on static mapping of AP’s MAC address to one of the cellular location types (CGI, SAI or RAI). AAA should provide the cellular location in 3GPP attribute 3GPP-User-Location-Info (below) in access-accept. The attribute is described in 3GPP TS 29.061 v9.3.0.

In case a UE moves to a different WLAN-GW, UE is authenticated based on data-trigger. In this case, the AAA server can provide the WLAN location (AP’s MAC@ and SSID) in called-station-ID attribute and cellular location in 3GPP-User-Location-Info attribute. The WLAN location is then encoded in TWAN identifier in “create session request” message, and the cellular location is encoded in the ULI IE.

Operational Commands

These commands show state related to mobile gateways and GTP sessions.

Migrant User Support with Portal-Authentication

Migrant User Support with EAP Authentication

Migrant user support can only be used for closed SSIDs when there is no RADIUS-proxy configured on WLAN-GW. If no RADIUS proxy is configured, then initial RADIUS request carrying EAP from the AP is normally forwarded to a RADIUS server. The RADIUS exchange is between AP and the AAA server, and no information from EAP authentication is cached on the WLAN-GW. The subsequent DHCP DISCOVER after successful EAP authentication is received on the ISA. However, for subscriber that needs to be GTP tunneled to PGW/GGSN, the DHCP is forwarded to the CPM, where it triggers a RADIUS authorization. RADIUS correlates the MAC address with calling-station-id from EAP authentication for the user. GTP tunnel initiation, and ESM host creation then follows after receiving an access-accept. However, for a “local-breakout” subscriber DHCP and L2-aware NAT is handled on the ISA (as in the case for migrant users with portal based authentication). Shared inside IP address can be handed out to each subscriber. The first L3 packet triggers MAC address based RADIUS authorization from the ISA. RADIUS server can correlate the EAP authentication with the MAC address of the user and send an access-accept. This triggers ESM host creation as normal.

For closed SSIDs with EAP authentication, if a RADIUS proxy function is configured on WLAN-GW, then the initial EAP authentication from the AP is processed by the RADIUS-proxy on the CPM, and is forwarded to the RADIUS server based on configured authentication policy. Based on authentication response, ESM host creation with local DHCP address assignment or GTP tunnel initiation proceeds as usual.

Data Triggered Subscriber Creation

With data-triggered-ue-creation configured under wlan-gw group interface or per VLAN range (such as, per one or more SSIDs), the first UDP or TCP packet received on WLAN-GW ISA from an unknown subscriber (with no prior state, such as an unknown MAC address) will trigger RADIUS authentication from the ISA. The authentication is based on configured isa-radius-policy (under aaa context). If RADIUS authentication succeeds, then ESM host is created from the CPM. The ESM host can get deleted based on idle-timeout. Data-triggered authentication and subscriber creation enables stateless inter WLAN-GW redundancy, as shown in Figure 170. If the AP is configured with a backup WLAN-GW address (or FQDN), it can tunnel subscriber traffic to the backup WLAN-GW, when it detects failure of the primary WLAN-GW (based on periodic liveness detection). With “data-triggered-ue-creation” configured, the first data packet results in authentication and ESM host creation on the backup WLAN-GW. If the subscriber had obtained an IP address via DHCP with L2-aware NAT on the primary WLAN-GW, it can retain it with L2 aware NAT on the backup WLAN-GW. The NAT outside pool for the subscriber changes on the backup WLAN-GW based on local configuration. For a subscriber that needs to be anchored on GGSN/PGW (as indicated via RADIUS access-accept), RADIUS server will return the IP address of PGW/GGSN where the UE was anchored before the switch-over. GTP tunnel is then signaled with “handover indication” set. The PGW/GGSN must return the requested IP address of the UE, which is the address with which the UE originated data packet that triggered authentication.

The same data-triggered authentication and subscriber creation is also used to support inter WLAN-GW mobility, such as when a UE moves form one AP to another AP such that the new AP is anchored on a different WLAN-GW. This is shown in Figure 171.

Figure 170:  N:1 WLAN-GW Redundancy Based on “Data-Triggered” Authentication and Subscriber Creation 

Figure 171:  Inter WLAN-GW Mobility Based on “Data-Triggered” Authentication and Subscriber Creation 

The following output displays the configuration for migrant user support and “data-triggered” subscriber creation.

Migrant User NAT Configuration

DHCP

Based on DHCP and L2 NAT configuration on the ISA, the configured IP address (l2-aware-ip-address configured under vlan-range or default vlan-range) is assigned to the user via DHCP. A different DHCP lease-time can be configured for an un-authenticated and an authenticated user for which an ESM or DSM host has been created. DHCP return options, for example, DNS and NBNS server addresses can be configured. This configuration can be per soft-wlan-gw group interface (by explicitly configuring it under vlan-range default), or per VLAN range (where a VLAN tag corresponds to an SSID). By default, for open SSIDs, DHCP DORA is completed, and authentication request is is sent to AAA server only on reception of the first Layer 3 packet. However, with a authenticate-on-dhcp command configured under vlan-range (default or specific range), authentication can be triggered on received DHCP DISCOVER or REQUEST when no UE state is present. If UE anchoring on GGSN/PGW is required, then authenticate-on-dhcp must be enabled, since the decision to setup GTP tunnel (in which case the IP@ for the UE comes from the GGSN/PGW) is based on RADIUS response.

Authentication and Accounting

The authentication is initiated from RADIUS client on the ISA anchoring the user, based on an isa-radius-policy (configured under aaa) and specified on the wlan-gw group-interface. This support exists in prior releases and is described in Authentication and Forwarding. The auth-policy can contain up to ten servers, five of which can be for authentication and all ten can be COA servers.

In order to generate accounting updates for DSM UEs, an accounting policy (type isa-radius-policy) must be configured under the aaa node and specified under vlan-range (default or specific range) on the wlan-gw interface. Accounting for DSM UEs includes accounting-start, accounting-stop and interim-updates. Interim-update interval is configurable under vlan-range on wlan-gw interface. The user-name format to be included in RADIUS messages is configurable in the auth-policy and accounting-policy via the user-name-format command. By default, the user-name contains the UE MAC address, but can be configured to include the UEs MAC address and IP address, or circuit-id or DHCP vendor options. If authenticate-on-dhcp is enabled, then the IP address for the UE is not known prior to authentication, and, if the user-name is configured to contain both MAC and IP address, then only the MAC address will be included.

The accounting-policy can be configured with attributes to be included in the accounting messages. The details of the attributes are covered in the 7750 SR-OS RADIUS Attributes Reference Guide. The attributes are included here for reference.

The isa-radius-policy for auth/COA and accounting specifies the server selection method for the servers specified in the policy with respect to load-balancing and failure of one or more servers. The three methods implemented include:

If a response is not received for a RADIUS message from a particular server for a configurable timeout value (per server), and the time elapsed since the last packet received from this RADIUS server is longer than this configured timeout value, then the server is deemed to be down. Periodically an accounting-on message is sent to a server that is marked as down, to probe if it has become responsive. If a response is received then the server is marked as up.

IP Filtering

Filtering based on protocol, destination IP, destination port or any combination is supported for traffic to and from the UE. The match entries and corresponding actions can be specified within the dsm-ip-filter which can be created in the subscriber-mgmt>wlan-gw>dsm context. The filter can be associated with a vlan-range (default or specific vlan-range) on wlan-gw interface, in which case all subscribers associated with the vlan-range will be associated with an instance of this filter.

The supported filter actions include drop and forward. The first match will cause corresponding action to be executed and no further match entries will be executed. In case there is no match or no action configured for a match, configurable default action for the filter will be executed. The filter can be overridden on a per UE basis via RADIUS access-accept or COA. The new VSA Alc-Wlan-Dsm-Ip-Filter is defined for specifying the per UE filter from RADIUS. The VSA is defined in the RADIUS guide.

Idle-Timeout and Session-Timeout Management

The per UE idle-timeout value can be provided in RADIUS access-accept or COA for a DSM UE in standard Idle-Timeout attribute. The minimum idle-timeout allowed is 150 seconds. The idle-timeout is enforced on the ISA for a DSM UE. If there is no data to/from a UE for up to idle-timeout value, the UE is removed and accounting-stop is sent. Subsequently, if a UE re-associates and connects to an open SSID on an AP, and has an IP address with a valid lease, then the first data packet from the UE triggers authentication. Successful authentication results in creation of DSM UE.

To improve idle-timeout behavior an optional SHCV check can be performed after idle-timeout expires. This check verifies connectivity to all of the DHCP, DHCPv6 and /128 SLAAC addresses using ARP and/or NDP. While the check is performed for every address, the result is applied to the whole UE. The UE is only deleted when verification of all addresses fails. When at least one connectivity verification succeeds the UE and all of the allocated addresses are kept and the idle-timeout process is restarted.

The per UE session timeout value can be provided in RADIUS access-accept or COA in standard Session-Timeout attribute. The value is interpreted as “absolute value”, and the UE is unconditionally deleted regardless of activity. The minimum allowed value for session-timeout is 300 seconds.

Operational Commands

The following shows the command usage to dump information on UE under LI (only allowed to users with LI privilege).

Pool Manager

To support allocations of unique IP addresses each ISA is assigned pools from a centralized pool manager on the CPM. The ISA can subsequently assign addresses from these pools to UEs, but this state is not synchronized back to the CPM. Different applications have different pools, for example, SLAAC and DHCPv6 IA_NA cannot share a single pool. To support Wholesale/Retail scenarios a pool-manager can be configured per subscriber-interface.

The allocation of additional pools and freeing up unused pools is based on configurable high and low watermarks. When the usage level of all pools combined on an ISA reaches the high watermark, a new pool is allocated. When the usage level of a single pool reaches zero and the usage level of the other pools combined is below the low watermark, this pool is freed.

In the case of redundancy the pool manager will signal the pools that were allocated to the failed ISA back to the new active ISA. These pools can no longer be used to allocate new addresses because allocations are lost. However, these can still be used to forward traffic based on data-triggered UE creation. This is supported both for IOM redundancy and Active/Standby WLAN-GW redundancy. The new active ISA will also receive new pools that it can use for new allocations.

The Pool Manager uses DHCPv6 Prefix Delegation to allocate pools to the ISAs. Each ISA is represented by a separate DHCPv6 Client ID. These clients request fixed prefix sizes to accommodate up to 64K UEs. In the case of Active/Standby redundancy the Pool Manager uses a DHCPv6 Lease Query Message to retrieve the prefixes that were allocated to the failed WLAN-GW. In order to identify the correct PD leases in the DHCPv6 server, a configurable virtual-chassis-name is added to the DHCPv6 client-id, this value should be identical on both WLAN-GWs and unique otherwise. The Pool Manager will always send out a DHCPv6 Relay message and supports up to eight DHCPv6 servers.

DHCPv6 and SLAAC

DHCPv6 and SLAAC support can be configured per VLAN range. Authentication can be triggered by a Router Solicit, DHCPv6 or DHCP packet but will only be triggered once per UE. Each UE can be assigned a unique DHCPv6 IA_NA address (/128) or SLAAC prefix (/64) from the ISA pools. The IPv6 pools are installed by the centralized pool manager. SLAAC privacy extensions are supported and up to three /128 SLAAC addresses can be learned via either Duplicate Address Detection or upstream data. Wholesale/retail is supported (IPv6 only) both via radius and per vlan-range CLI, the applicable pool is selected from the retailer service. ESM and DSM IPv6 are not supported in the same vlan-range context.

Configuration of other DHCPv6/SLAAC parameters, such as server DUID and RA flags is taken from the wlan-gw group-interface configuration. For DSM only the configuration of the wlan-gw group interface applies, the retailer interface cannot override this configuration.

A subset of DHCPv6 options retrieved by the pool-manager in the PD process is reflected in DHCPv6 towards the client. For IA_NA leases these are included in the associated DHCPv6 messages. For SLAAC allocations, the DNS option can be reflected in the Router Advertisement and all options can also be reflected in a stateless DHCPv6 Information Reply message.

When using a captive portal, different valid/preferred lifetimes can be configured for authenticated and un-authenticated UEs. The DHCPv6 lease time will be equal to the applied valid-lifetime and can be extended via the regular renew process. SLAAC lifetime is equal to the applied valid-lifetime and will be extended when sending an RA including the SLAAC prefix. To avoid infinite SLAAC allocations, when sending an unsolicited RA, SHCV will be performed for all learned /128 addresses. If SHCV fails for all addresses, the unsolicited RA will not contain the SLAAC prefix and the SLAAC lifetime will not be extended.

In redundancy scenarios the new active ISA will migrate the leases in the old pools as soon as possible to a lease in the new pools. For SLAAC this is done by sending an unsolicited RA to deprecate the old prefix (lifetimes 0) and include a new prefix. For DHCPv6 this is done during the first Renew, that will again deprecate the old address (lifetimes 0) and include a new address in the same IA.

Call Trace

The call trace feature is an enhanced debugging feature that allows an operator to monitor the full control plane (like the setup) of a single entity. When call trace is enabled all protocols related to this entity are captured. This allows an operator to easily debug problematic entities (like a WiFi UE) instead of debugging and verify every separate protocol (like DHCP, ARP, RADIUS, DHCPv6, ICMPv6, and so on). Call trace can present the captured packets for further processing in one of following ways.

For DSM, call trace can be enabled on a per UE basis by providing the UE’s exact MAC address. When enabled, all protocols as seen by the ISA will be traced.

Enhanced Subscriber Management

For ESM support authenticate-on-dhcp should always be enabled under configure>service>vprn|ies svc>subscriber-interface sub-if>group-interface grp-it>wlan-gw vlan-tag-ranges range start start end end. When receiving DHCPv4 the ISA will send the DHCP message and the cached access-accept to the CPM which will further process the setup sequence. On the CPM a regular radius authentication policy should be picked up for the UE either through configuration on the group-interface or via the LUDB. Typically this policy will reflect the ISA-policy. This policy will be used as a context to store the access-accept on the CPM for 10s.

IPv6 hosts are supported but can only be authenticated after DHCPv4 has triggered the promote from ISA to CPM. When ipoe-linking is enabled a SLAAC host will be created together with the DHCPv4 host as usual. If an additional IPv6 host would arrive after the 10s timeout, a regular radius authentication will be started from the CPM using the previously mentioned radius policy.

When tracking is enabled, the radius messages are handled on the ISA and specific tracking actions (mobility, delete) are sent directly to the CPM

Distributed Subscriber Management

For DSM support the radius-proxy cache is directly tied to the UE record on the anchor ISA and is automatically used during UE creation. Tracking immediately executes the associated actions (mobility, timed host-delete) on the UE record. If a cached accept would time out before DHCP is received, a regular radius authentication will be used using the configuration under configure>service>vprn|ies svc>subscriber-interface sub-if>group-interface grp-it>wlan-gw vlan-tag-ranges range start start end end>authentication.

Operational Commands

The following commands will display all statistics related to the radius-proxy, both for communication towards the client and for communication towards the server.

show router router-id radius-proxy-server server-name statistics

clear router router-id radius-proxy-server server-name statistics

Example output:

The following RADIUS proxy messages sent to the server using this policy will also be counted here.

show aaa isa-radius-policy policy-name

clear aaa isa-radius-policy policy-name statistics

Example output:

DHCP Server Redundancy

1:1 redundancy provided with this feature only handles complete failure of WLAN-GW (either due to chassis reboot or due to number of operational WLAN-GW IOMs in WLAN-GW group falling below the number of active WLAN-GW IOMs, which will operationally bring down the WLAN-GW group, and trigger switchover). For any partial failures (port, MDA or IOM failure), it is assumed there is network level redundancy, such that the soft-GRE tunnel will be re-routed to the primary WLAN-GW. This ensures there is only one active WLAN-GW owning the subnets defined on the two WLAN-GWs (that is, allows local/local subnets). The DHCP server(s) state will be synchronized between the two WLAN-GWs using MCS.

Supported access includes:

Unnumbered case should work both in relay and proxy scenarios. IPv6 is not supported in this release (as we don’t support data-triggered auth and subscriber creation for IPv6). Therefore, DHCPv6 server synchronization is not applicable. Also, IPv4 address from LUDB is not supported in this release (as data-triggered authentication against LUDB is not supported).

Subscriber Creation after Switchover

When standby WLAN-GW transitions to active state, and receives data on the anchor ISA there will not be any UE state on the anchor ISA. Data-triggered authentication Data Triggered Subscriber Creation will be used to create the subscriber. In order to infer how the UE originally obtained the IP@ (DHCP relay versus proxy, such as AAA or GTP), the following holds:

If authentication indicates GTP for the subscriber, then create-session-request will be signaled with Handover indication. Data-triggered subscriber creation based on IPv6 packet is not supported in R12. However, for dual-sack subscriber over soft-GRE, if AAA returns the SLAAC prefix in access-accept (in response to IPv4 data-triggered auth), and linking is configured, RA message will be sent (unicast to client’s MAC@), and a SLAAC host is created.

IPv6 GRE Tunnels

Support for IPv6 GRE tunnels require configuration of local IPv6 tunnel end-point address under wlan-gw configuration on the group-interface. The transport for L2oGRE (or L2VPNoGRE) packet is IPv6 as shown below. The outer IPv6 header contains the value 0x2F (GRE) in its Next Header field. GRE header contains protocol Ethernet (0x6558) or Ethernet-over-MPLS (0x8847) as in the case IPv4 GRE.

IPv6 Transport for L2oGRE Packet:

A single wlan-gw endpoint instance on the group-interface can have both IPv4 and IPv6 address configured as shown below. Inter-AP mobility between IPv4 and IPv6 only APs is supported in this scenario.

IPv6 Endpoint Configuration for WLAN-GW:

The data-path for IPv6 GRE tunneled packets, including load-balancing of tunneled packets amongst set of ISAs in the WLAN-GW group, and anchoring after tunnel de-capsulation remains unchanged. Per tunnel traffic shaping is supported similar to IPv4 tunnels. All existing per tunnel configuration on the group-interface described in previous sections (including mobility, egress shaping, VLAN ranges, etc.) is supported identically for IPv6 tunnels. Tunnel reassembly for upstream tunneled traffic is not supported for IPv6 tunnels in this release. TCP mss-adjust is supported for IPv6 tunnels, and is configurable under wlan-gw mode on group-interface. APs must use globally routable addresses for GRE IPv6 transport. Packets with extension headers are dropped.

IPv6 Client-Side RADIUS Proxy

RADIUS proxy is extended to listen for incoming IPv6 RADIUS messages from IPv6 RADIUS clients on AP/CPEs. The listening interface that the RADIUS proxy binds to must be configured with an IPv6 address as shown below. The IPv6 RADIUS proxy is solely for DHCPv4-based UEs behind IPv6 only AP/CPEs (IPv6-capable UEs are not supported in this release). All RADIUS-proxy functions (including caching, correlation with DHCPv4, and mobility tracking) are supported identically to existing IPv4 client-side RADIUS-proxy.

Configuration for IPv6 Client-Side RADIUS Proxy:

Dual-Stack UEs over WLAN-GW

This feature adds support for dual-stack UEs over wlan-gw. Each dual-stack UE appears to WLAN-GW as a bridged client. Dual-stack UE support includes both SLAAC and DHCPv6, with and without linking with DHCPv4. Handling of DHCPv6, RS/RA, and NS/NA messages over wlan-gw has been added. WLAN-GW can assign /128 GUA to the UE via DHCPv6 and/or assign a /64 prefix in SLAAC to each UE. Each UE can be handed via DHCPv6, a /128 IA_NA from a unique /64 prefix, with the “on-link” flag is off in the RA message. This is because the public WIFI users are distinct subscribers, and the communication must always be via WLAN-GW. The CPE MUST prevent local-switching on the WIFI link even if the /64 prefix is signaled as “on-link” or if the UEs are handed out /128 from the same /64 prefix.

Existing ESMv6 support on normal group-interface is applicable to wlan-gw group-interface, and is already documented in general ESMv6 sections in this guide. There are a few exceptions that are mentioned in sections below.