virtual Residential Gateway

In This Section

This section describes features and functionality for the router to act as a virtual Residential Gateway providing bridged home connectivity.

Topics in this section include:

  1. virtual Residential Gateway Overview
    1. Access Modes
    2. Home Context on the vRGW
    3. Device Context on the vRGW
    4. Dynamic Configuration Changes
    5. Per-Home Pool Management and L2-Aware NAT
    6. IPv6
    7. QoS and Filter Support
    8. Data-Triggered Authentication

virtual Residential Gateway Overview

A virtualized residential gateway transforms the Layer 3 routed Residential Gateway (RGW) in the home into a bridged Residential Gateway, by moving the Layer 3 functions of an RGW into the network resides on a node hereby referred to as a “virtual Residential Gateway” (vRGW). The Layer 3 functionality, such as address management (DHCP server, and static or sticky address assignment), routing, Internet connectivity, NAT, UPnP, Firewall and application awareness provides functions such as URL filtering and parental control, is moved to the network and resides on the vRGW. The Residential Gateway then operates in a bridged mode and performs local switching of intra-home traffic that originates and terminates on devices within the home. Bridged traffic destined for outside the home (such as to the Internet, or to the provider’s content, or to another home) over the WAN toward the vRGW is hereby referred to as a “Bridged Residential Gateway” (BRG).

This mode of operation allows an operator visibility of the connected devices on the home LAN, instead of just a single IP address per home as is the case for a Layer 3 routed Residential Gateway. This allows operational improvements through per-device control and troubleshooting, and the ability to offer new services faster and on a more granular device specific-basis.

The router, as a dedicated gateway or as a BNG, serves as a vRGW providing Layer 3 termination and ESM functionality for bridged homes, as shown in Figure 175.

Figure 175:  Virtualized Residential Gateway (vRGW) 

Access Modes

All vRGW functionality is supported on both regular group interfaces (SAPs, LAGs, PW-SAPs, and so on) and WLAN GW group interfaces (soft-GRE, soft-L2TPv3, VLAN).

A new configuration sub-node for the BRG is provided under the group-interface context for regular group interfaces and under the vlan-range context for WLAN-GW group interfaces. A regular group interface with a BRG sub-node does not support any non-BRG configuration and must operate in the ipoe-bridged mode.

In a WLAN-GW group interface, the BRG is configured in the vlan-range level. With a vlan-range it is not possible to mix BRG and other existing functionalities, but it is possible to mix BRG and other functionalities (such as WLAN-GW) on the same group interface. If a BRG also supports public WIFI, the expectation is that the BRG will have different SSIDs for public WIFI and for private home traffic on the BRG, each represented by a different VLAN tag.

Contrary to WLAN-GW UEs, which require anchoring based on their MAC addresses (for mobility), devices associated with a BRG are anchored based on the tunnel source IP address of the BRG. The system therefore load-balances on a per-BRG granularity basis across a set of configured ISAs. Anchoring based on the source IP address of the BRG allows all devices in the home to be anchored on the same ISA and IOM. This enables aggregate QoS functionality within a single home.

Tunnel QoS is not supported as this will be performed by regular subscriber QoS in the BRG scenario. WLAN-GW IOM (N:M) redundancy is supported. Data-triggered authentication (IPv4 only) is supported. All WLAN-GW access types (GRE, L2TPv3, L2-AP) are supported.

Home Context on the vRGW

The system keeps a management context for each connected home or BRG, which is identified by a BRG ID. This context is used for authentication, configuration, and retrieval of operational data. Authentication can be performed explicitly by the BRG, in which case the vRGW acts as a RADIUS proxy. Alternatively, the vRGW can implicitly authenticate on the BRG’s behalf when the first host from the BRG connects.

Initial configuration parameters are provided as RADIUS attributes during authentication. Configuration parameters provided on the home level will be used as defaults on the host level can be overridden on a per-host basis. Home-level configuration can be dynamically overridden by means of a RADIUS CoA message. For more details on the available configuration parameters, see the vRGW section in the RADIUS Attributes Reference Guide.

Operational data provides information on the BRG such as the number of connected devices, how long the BRG has been active, and which configuration parameters were provided. This can be retrieved via MIBs or show commands.

The vRGW communicates with a classic AAA server mainly to perform the authentication and with a separate configuration/operational platform. This separate configuration/operational platform referred to as a “controller” and can be combined in a single management control system.

Implicit Home Authentication

with implicit home authentication (Figure 176), the vRGW will authenticate a new BRG when the first associated device connects. In order to not impose restrictions on the connectivity model, the vRGW will not try to identify a BRG based on tunnel or VLAN data. The vRGW will always perform authentication of a new host and this authentication should return the BRG ID with which this host is associated. If this BRG ID is not yet known, the vRGW will trigger BRG-level authentication. This allows an operator flexibility to identify a home. For example, one deployment might use CVLANs as an identifier while another might use a BRG MAC as an identifier.

A home can be optionally authenticated with an AAA server. Each device in the home, on the other hand, is not typically authenticated with an AAA server, but merely authorized with a controller (via regular RADIUS messages and configured authentication policy) to get its configuration. This authorization is handled by the controller, which will identify and return the associated BRG ID and, optionally, any device-level configuration.

Per-home authentication is forwarded to the AAA server to be fully authenticated. In this case, it is expected that the controller performs an AAA proxy functionality so it can insert home configuration data in the final Access-Accept message. After both device and BRG authentication have been completed the resulting RADIUS attributes will be used to set up all required ESM objects (hosts, subscribers, SLA profile instances, filters, and so on).

Figure 176:  Implicit Home Authentication  

Explicit Home Authentication

With explicit home authentication (Figure 177), the BRG authenticates itself at boot time before allowing connectivity of any devices. The vRGW will act as a proxy for this authentication, and upon receipt of a successful authentication, the BRG context will be created and store all home parameters. As with implicit authentication, the vRGW performs authentication for each device and expects the BRG ID as a result.

Figure 177:  Explicit Home Authentication  

On the router, this functionality is obtained by including a RADIUS proxy in the vRGW configuration. This RADIUS proxy can be used for both WLAN-GW and vRGW scenarios and will determine the difference based on the presence of a BRG-ID attribute in the Access-Accept message. Proxy transactions in the context of a BRG will not be cached. Instead, a fully functional BRG context will already be created. Track accounting is not supported in the context of a BRG. Reauthentication is supported and behaves the same as on a CoA at the BRG level.

Change of Configuration

It is possible to change the configuration on a home level with the use of a RADIUS CoA. The CoA should use the BRG ID as a key and contain attributes for all new or updated parameters. For all correctly specified parameters, the vRGW will overwrite the existing configuration on the home level and update all devices connected to the BRG.

Home Lifetime

A configurable ping based on a smart connectivity-verification mechanism is provided to detect whether a BRG is alive. The BRG state is removed if it is not deemed alive (subject to a configurable hold time). A BRG is always considered to be alive as long as there are connected non-static devices. Static devices are not considered because there is no control plane to track whether they are alive or not. When no sessions are present, the home context can still be in one of the following three states.

  1. On explicit authentication, where there is no session connected yet, the BRG state should be kept alive. To handle this, an initial hold time applies during which the BRG context cannot be removed. Any connected device will cancel the timer. If the timer expires and there are still no connections present, the BRG fall backs to the behavior as if the last session was removed.
  1. If the last session was removed and connectivity verification is configured, the vRGW will try to ping the BRG. This ping mechanism uses ICMP or ICMPv6 ping toward the tunnel source IP or, if not present, toward the RADIUS source IP address. As long as the pinging is successful, the BRG context is kept. If the pinging is unsuccessful or impossible to perform (such as no IP known), the BRG falls back to the hold time. If during the connectivity verification a host connects to the BRG, the verification is stopped and the BRG is assumed to be alive again.
  1. If the last session was removed and connectivity verification failed or was not configured, a configurable hold time applies during which time the BRG is not removed. If during the hold time a new device connects, the timer is canceled. If the timer is not canceled, the BRG is removed when the timer expires. The configured hold time can be zero and can be different from the initial hold time.

Device Context on the vRGW

The router maps every device in a home to an IPoE session, which can contain one or more ESM hosts depending on the number of IP stacks active on the device. The vRGW will still authorize every single device and store the resulting configuration data with the IPoE session. Whenever the session is created or updated, the vRGW will combine the configuration data of the home context with the configuration data of the device. When the same configuration object is present on both levels, the device level will apply. The resulting combined configuration data will be used to install or update the ESM objects.

Dynamic Configuration Changes

It is possible to dynamically change the configuration on both the home level and the device level by means of a RADIUS CoA. A CoA on the home level should use the BRG ID as key. The included attributes will overwrite the existing stored configuration on the home level and subsequently update all devices connected to the home. All devices will pick up the new home-level configuration unless a more specific configuration exists on the device level.

A CoA on the device level can use all existing ESM keys as detailed in the RADIUS Attributes Reference Guide. This will update the existing configuration on the device level. If the device inherited the specified parameter from the home level, this parameter will only be updated on the device level; the existing home-level configuration will stay intact and will be used as the default for other devices.

In certain cases, the configuration can be removed on the device level to be able to fall back to the home level. To support this, the RADIUS attribute “Alc-Remove-Override” has been created. This attribute lists which overrides must be removed on the session level and fall back (revert) to the home-level configuration. If the home parameter changes, the device will also pick up this new configuration.

For more details on RADIUS configuration attributes, refer to the RADIUS Attributes Reference Guide.

Per-Home Pool Management and L2-Aware NAT

This feature allows the provisioning of a DHCP pool per home in a vRGW context. The addresses in a per-home pool are unique, so local bridging within the home functions. Devices in different homes can, however, be allocated the same address. L2-aware NAT is then used to handle address translation and connectivity toward the network and between homes. Per- home default GW, subnet and address range (out of which addresses are allocated to home devices) can be configured via the CLI. The address range can be overridden from RADIUS. The subnet associated with the home pool must be within the configured L2-aware inside subnet. L2-aware source NAT can optionally be combined with destination NAT to support enhanced traffic redirection (such as for stateful DNS overwrite function). More details on network address translation forwarding can be found in the Multiservice Integrated Service Adapter Guide.In addition to the IPv4 addresses from the home pool, the following hosts can be set up:

  1. IPv4 DHCP proxy hosts using an AAA-provisioned address
    Note that only non L2-aware hosts can get a framed IP address from RADIUS
  1. IPv6 SLAAC hosts using an AAA-provisioned address or a Local Address Assignment
  1. IPv6 IA_NA hosts using DHCPv6 relay, an AAA-provisioned address, or a Local Address Assignment

Sticky IP Addresses

The vRGW can be programmed with a list of sticky IP addresses per BRG. A sticky IP address is an IPv4 address from the home pool allocation range that is set aside for a specific device based on the MAC address and will never be allocated to any other device. This can be used for devices where a persistent IP address is desirable but configuring a static IP address on the device is too cumbersome (such as a network printer). The device will still use DHCP to gain connectivity but will always be assigned the same IP address.Public (non-NAT) sticky IP addresses are not directly supported in pool management but can be provisioned in the following manner.

  1. Create a local DHCP server and pool to manage the public address space.
  2. For each public sticky IP address that must be provisioned, create a sticky lease in this pool. See Address Reservation for Sticky Leases in the DHCP server section for further details. Both the user identification and hostname can be the MAC address of the associated device.
  3. When the device linked to the sticky lease authorizes with the controller, it returns the allocated address as a framed IP address. This address will take precedence over any home pool configuration and a DHCP proxy host will be installed.

Managed Static IPv4 Addresses

Similar to sticky IP addresses, the vRGW can be programmed with a list of static IP addresses per BRG. However, for static IP addresses, DHCP is not expected from clients and will be dropped. The vRGW will automatically install all of these addresses as IPv4 hosts contained in IPoE sessions. Because every host must be linked to a specific point of access (such as a SAP or tunnel) the vRGW does need to wait on a data-trigger or the first non-static host in a home before static hosts can be created. Similar to regular (DHCP-triggered) hosts, a device-level authorization will be performed for each static host in order to retrieve the per-device level configuration.This type of static host can cover both private (inside the home subnet) and public (non-L2-aware NAT) addresses. The created hosts can only be explicitly removed by the management interface, and mechanisms such as session-timeout and idle-timeout are not supported.

DMZ

A single DMZ address can be provisioned per home via RADIUS (VSA Alc-DMZ-Address), which can be any address inside the home subnet except for the default gateway. When a host exists with this address, the DMZ mode will be activated. Note that DMZ will be activated if a host exists with the address and the subscriber uses only 1 port range per IP. Without DMZ mode enabled, any traffic arriving for the NAT outside IP that does not match an existing flow, pinhole, or port-forward, will be dropped. With DMZ mode enabled, this traffic will be forwarded to the provisioned DMZ host.

IPv6

The vRGW feature set supports the following IPv6 host types:

  1. IPv6 SLAAC hosts using an AAA-provisioned address or a Local Address Assignment.
  2. IPv6 IA_NA hosts using DHCPv6 relay, an AAA-provisioned address, or a Local Address Assignment.

The vRGW only operates in IPoE bridge mode. For regular group interfaces, IPoE bridge mode must be explicitly enabled before the BRG can be enabled. For WLAN-GW group interfaces, IPoE bridge mode is implicitly assumed for a VLAN the range with BRG enabled. This has the following consequences:

  1. SLAAC hosts from the same home can share a /64 prefix.
  2. When a local address assignment is used, SLAAC hosts from the same home are automatically assigned the same /64 prefix.
  3. IA_NA hosts from the same BRG can get unique addresses from a shared /64 prefix. This prefix is automatically signaled in an RA.

QoS and Filter Support

The vRGW is based on existing ESM QoS configurations on the router where each home maps to a single subscriber instance. Home-level bandwidth can be provided by an aggregate rate or scheduler policy on the subscriber level. Groups of home devices (such as telephones, computers, televisions, and security systems) can be given a shared bandwidth by assigning a different SLA profile per such group. Individual device-level QoS can be provisioned by mapping a specific device to a specific forwarding class using IP classifiers based on the device IP. This forwarding class can then be mapped to its own individual queue. Dynamic QoS overrides can be provisioned on both the home level and the device level. While QoS overrides are represented by a single RADIUS attribute, the device level does not override the whole attribute but only the QoS objects specified on that level. For example, if on the home level, the scheduler bandwidth is overridden, and on the device level, queue bandwidth is overridden. The resulting override is a combination of both.

Data-Triggered Authentication

ISA-based IPv4 data-triggered authentication (Figure 178) and host creation is supported on WLAN-GW group interfaces. When authenticating a data-triggered device, the controller has less data to derive the BRG from connection data only unlike DHCP where the BRG can insert its identifier, such as a circuit-id. For pure Layer 2 access, a BRG ID can be hard-coded to a port and VLANs, although for tunneled access, this is not always possible as the corresponding value would be the tunnel source IP address . This IP address can be dynamically assigned and changed with a BRG reboot. The following alternatives are suggested.

  1. Use the “AP MAC” as the identifier. This can be signaled in DHCP and DHCPv6 as specified in the WIFI Aggregation and Offload section. For data-trigger purposes, it can also be sent as part of the L2TPv3 header or if a GRE, it can be learned upon data-trigger via an ARPoGRE/NDoGRE message.
  1. Use a custom identifier that is sent in DHCP in a circuit-id option or a vendor-specific option. While a DHCP lease is active, a controller keeps state to map the device MAC to the BRG identifier in order for the data-trigger can be handled.

If the data-triggered device is the first device to come up in the home and the BRG did not perform explicit authentication, the vRGW will also trigger an implicit authentication. After authentication, two possibilities exist to install the data-triggered host.

  1. It is determined that the data trigger was for a static IP address. This is usually the case when the static device is the first to send upstream data in the home. In this case, the triggering static host and any other provisioned static hosts will installed.
  1. The trigger was sent for a dynamic host (sticky/not sticky). This usually occurs when connection with a device was lost (based on an idle-timeout) but the lease was still valid. A DHCP lease will be re created using the provisioned lease time (on the home level). This installed lease time is usually excessive compared to the actual remaining lease time on the device, but this is corrected when the lease performs DHCP renew or rebind procedures.
    Note however the actual remaining lease time will be used if known. Normally if a host goes idle and sends a data trigger, the actual remaining lease time will be used.
Figure 178:  Data-Triggered Authentication  

BRG and vRG Caveats

  1. Static IPv6 hosts are not supported in vRGW. It is possible to provide a static IPv4 host with a SLAAC prefix and use IPoE linking to automatically create an associated IPv6 host.
  1. Wholesale/retail is not supported in vRGW.
  1. Subnets provisioned for BRG pool management must lie in a pre-configured L2-aware NAT inside prefix. The dynamic range of a BRG pool must not contain the configured L2-aware NAT inside IP address.
  1. BRG connectivity verification is limited to a maximum of 10000 BRGs. If more BRGs are connected, connectivity verification will be performed for the excess numbers and only hold-time will apply before the BRG instance is deleted from the vRGW.
  1. On regular group interfaces, only a single BRG is supported per SAP.
  1. There is a maximum of one SLAAC prefix per BRG.
  1. There is a maximum of 128 IPoE sessions per BRG, and a maximum of 8 static hosts per BRG.
  1. There is a maximum of 32 SLAAC hosts per shared prefix.
  1. The idle timeout is based on SLA profile instance, not per host. For hosts under the same BRG sharing an SLA profile, it is not possible to detect early disconnect of a single host. This restriction may be fixed in a future release.
  1. All SLAAC hosts under a BRG sharing the same prefix will use a common forwarding context downstream. For predictable behavior, the same SLA-profile should be used for each SLAAC host. This restriction may be fixed in a future release.