Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

IN THIS PAGE

Resource Management and Packet Steering

 

This topic provides functional details of what the resource management and packet steering daemon (RMPSD) in a Service Control Gateway must handle steering of different packet types to the appropriate module. Implicit filters for steering control packets to the correct session PIC and routes for steering data packets are needed to be programmed by RMPSD.

Selection of a Session PIC and Control Packet Steering to the Session PIC

Service Control Gateway uses a single IP address but the control plane is implemented in a distributed fashion by multiple SPICs which share the same IP address. In Service Control Gateway, two types of packets are sent to the serving session PIC—RADIUS requests and Diameter requests.

RADIUS Accounting Start/Stop packets need to be intercepted by an appropriate implicit filter programmed by RMPSD to direct these packets over to the correct session PIC for subsequent processing and retrieving the UE IP address located inside the payload. For this, an implicit filter for the INET family with a match condition of the destination IP address equivalent to the Service Control Gateway’s loopback IP address needs to be programmed by RMPSD. The loopback interface would represent the public interface towards the access network to which packets from subscriber edge network element would be directed. Moreover, the filter captures only those packets that are originating from a configured set of AAA client IP addresses. The implicit filter rule is as follows:

If Dest_IP matches Service Control Gateway loopback address and Src_IP matches configured set of AAA client addresses, then steer to session PIC next hop.

RADIUS Accounting requests are recognized by destination port 1813 and Diameter requests are recognized by destination port 3868.

Selection of a Session PIC to Handle Incoming RADIUS Requests

The following are the requirements and conditions related to selecting session PIC to handle incoming RADIUS request and possible solutions.

  • There is no information about the user equipment (UE) address prior to receiving RADIUS request.

    The UE address is inside the RADIUS request as Framed-IP-Address.

  • All control packets related to the same UE address should ‘land’ to the same session PIC.

  • Duplicate RADIUS request detection needs to be done locally on session PIC.

  • Selection of a session PIC is based on the source IP address and destination IP address combination. This method of selection is useful if multiple source interfaces are configured on the Service Control Gateway and if the client (PGW) recognizes multiple Service Control Gateway addresses and it (client) is configured in such a way that different APNs target different Service Control Gateway addresses. The selected session PIC (SPIC) that is always the same for a given destination address becomes a dedicated SPIC. It handles all incoming requests until its capacity is full in which case the dedicated SPIC will forward requests to next available SPIC. The dedicated SPIC maintains the request cache locally. Two watermarks (high and low) start and stop forwarding to another SPIC. A global database is not used for SPIC selection.

Service PIC Selection and Data Packet Steering

In Service Control Gateway, the IP address pool information is not known through configuration at the time of initialization of the box. Subsequently, the address chunks cannot be formed during that time and need to be computed dynamically as each connection request packet is processed. When the RADIUS accounting-start packets are processed by the control plane, aggregated subscriber routes are programmed on the PFEs pointing to a selected Service PIC where the subscribers would be anchored. These chunks are generated from the UE IP addresses in the connection request packets and the appropriate route pointing to a selected service PIC is programmed on the PFEs.

When each address chunk is formed, a service PIC or an anchor Packet Forwarding Engine is selected and the prefix corresponding to that chunk is pointed to it and programmed as a route to the PFEs. The selection of service PICs happens dynamically as each connection request is processed. Each request has an IP address for the UE. When the chunk, corresponding to the UE IP address has been formed, a hash computation of the VRF identifier of the incoming connection request and this newly formed chunk needs to map to a service PIC. Subsequently, the new route is programmed pointing to this service PIC.

The UE IP address is obtained from the incoming connection request and a prefix is constructed. If a route for that prefix does not exist already, then a service PIC is selected based on the load-balanced criterion and program a route for that prefix pointing to the selected service PIC.

The load-balancing criterion can be a hash of the combination of the VRF and the chunk prefix. If the route already exists but CAC does not allow subscriber creation on that service PIC, then no further /32 host route is programmed pointing to a different service PIC. The data packet is forwarded to the pointed service PIC and if the subscriber has not been created yet, then default policy serving is provided. Moreover, the boundaries of the prefixes do not change once they have been allocated and assigned to a service PIC.

Data Packet Steering

Data packets that are pertinent to the Service Control Gateway function need to be steered to the appropriate Service PIC or an anchor Packet Forwarding Engine. Any other data packet needs to be forwarded as-is using a default route out of the Service Control Gateway in the proper direction (uplink or downlink). Data packets are categorized as originating from a potential subscriber or not. All non-subscriber packets would be initially filtered out by a Service Control Gateway service filter that would have the knowledge of IP ranges not belonging to a valid subscriber. Subsequently, all packets that pass the above filter are be steered to a service PIC for processing. If the subscriber is currently absent, then these steered packets are serviced by a default policy and routed out of the gateway.

For uplink packets, the source address of the packet would have to be matched with the route and steered to the designated Service PIC. For downlink packets, the destination address of the packet would be matched with the route. The logical interface on which the packet arrived indicates the direction of the packet and the appropriate lookup selected. All packets that do not match the already programmed aggregate routes fall back to a default route that directs the packet in a load-balanced fashion (based on a hash of the user IP address) to a Service PIC for a default policy service, before being routed out of the gateway. This default route needs to be programmed by RMPSD pointing to a list of service PICs over which to load-balance.

Packet Forwarding Engine Functionalities

The Packet Forwarding Engine system component is responsible for packet steering at its core. But as a part of the Mobile Broadband Gateway solution, the Packet Forwarding Engine has been enhanced to provide subscriber-aware forwarding plane, which is capable of providing subscriber and flow aware services, inline. These enhancements are leveraged to provide a uniform, scalable and efficient “subscriber-aware” data plane for Service Control Gateway. A subscriber in Service Control Gateway is an entity represented by its IP address.

The IP address is the address identifier assigned to the subscriber by the GGSN/PGW. In addition to the IP, Service Control Gateway uses the routing instance to which the subscriber belongs to provide IP isolation for subscribers belonging to different APNs, and also to be able to interact with multiple GGSN/PGW. Therefore, essentially in Service Control Gateway, the subscriber is represented by (VRF ID, IP address) pair. The Packet Forwarding Engine subsystem can operate in non-anchor Packet Forwarding Engine mode where it acts as a packet steering entity that is responsible for steering of data traffic to the tethered service modules implemented in Service PICs. In this mode, the forwarding plane is not subscriber-aware, but rather directs subscriber traffic to the services plane for further processing. The service plane is subscriber-aware and is able to provide subscriber-aware services on the subscriber traffic.

In addition, Packet Forwarding Engine is also responsible for steering of control packets to the session plane that is comprised of session PICs. Functionally, the following components contribute to the forwarding path functionality in Service Control Gateway.

  • Packet handling at subscriber edge network element facing and MIF interface

  • Control packet steering

  • Packet handling at service Packet Forwarding Engine

Packet Handling at Subscriber Edge Network Element-Facing and MIF Interfaces

This functionality is common and available in the Packet Forwarding Engine. The packet from Subscriber enters the chassis using subscriber edge network element facing interface. This interface is present on the Trio-chip based line card and this interface is explicitly marked as Service Control Gateway subscriber facing Interfaces. The packets that are originated by the subscriber towards PDN are referred to as uplink packets and the reverse traffic from PDN towards subscriber are referred to as downlink packets. On the subscriber edge network element facing interface, for the uplink packets, source IP-based lookup is performed to identify and steer the packet for subscriber-aware services, whereas for downlink packets, destination IP address-based lookup is performed to identify and steer the packet for subscriber-aware services.

The Service Control Gateway-specific functions performed in the subscriber edge network element facing interface are as follows:

Handling Service Control Gateway Subscriber and Non-Subscriber Traffic

Either include or exclude IP address range can be configured to filter the Service Control Gateway subscriber and non-subscriber traffic. If the includeIP address range is configured, then all packets which belongs to include IP address range are called Service Control Gateway subscriber traffic and the rest are called Service Control Gateway non-subscriber packets. If exclude” IP address range is configured then all packets that do not match the exclude IP address range are considered as Service Control Gateway subscriber packets and the matched packets are called Service Control Gateway non-subscriber traffic. If both include and exclude” filters are not configured, then every other traffic on the interface is considered as Service Control Gateway subscriber traffic except the radius packets. RADIUS packets are filtered by adding the implicit exclude filters.

Handling Subscriber and Potential Subscriber Packets

Both uplink and downlink packets received on subscriber edge network element facing interface are subjected to subscriber prefix lookup using subscriber demultiplexer (demux) table. This subscriber demux lookup table is a prefix-based route table, which consists of route prefixes pointing to service PIC index and also the MIF logical interface next-hop. The control plane groups the set of subscribers with the common prefix and host them on the same anchor service Packet Forwarding Engine. This demux lookup table is constructed and pushed to forwarding plane by learning the subscriber IP from radius control packets in case of radius triggered model or data packets in case of packet triggered model. During MIF logical interface interface style services processing, the service PIC index is used to select the service NH in the aggregated multiservices (ams) unilist NH.

Packets that match the subscriber learned prefix route would result in executing the MIF logical interface (MIFL) topology, where subscriber related services-filters are applied. Packets that match the subscriber related services-filter on the MIFL will be steered to anchor service Packet Forwarding Engine where the subscriber is hosted. Packets that do not match services filter are continued to route lookup and forwarded. Packets that are steered to anchor service Packet Forwarding Engine from MIFL topology is considered as “subscriber traffic” if the subscriber is already created on the anchor service Packet Forwarding Engine otherwise they are considered as “potential subscriber traffic” and default policy will be applied. Packets that do not match the subscriber learned demux route in the subscriber demux table are called “potential subscriber traffic” and they may (if there is default or “include” IP range route is present) get load balanced and sent to anchor service Packet Forwarding Engine for applying the default policy. Subscriber IP prefix will be used to compute the hash, which will be used for load balancing the “potential subscriber traffic”. With this, all packets of same subscribers will be sent to same anchor service Packet Forwarding Engine.

Control Packet Steering

In Service Control Gateway, the control plane signaling to create a subscriber can be received from PCRF using the Gx/Sd interface or using RADIUS Accounting Start messages received using the subscriber edge network element facing interfaces. This control traffic needs to be steered to the corresponding control plane implemented in session PIC, by Packet Forwarding Engine. RMPSD installs specific route implicit filters that checks on the source IP address or the destination IP and RADIUS or Diameter ports of the packets that arrive on that VRF. These implicit filters are executed before the subscriber demultiplexer lookup, if they are coming on subscriber edge network element facing logical interface and before the inet or inet6 route lookup if they are coming on any other interfaces. If the packet is found to be destined to AAA server of interest or to a PCEF, then the packets are steered to session PICs in the chassis, for further processing. Multiple instances of session PICs might be running in the system. In such a scenario, the control packets need to be load balanced across available session PICs