The approach of access selection on a flow basis stands out as the key value proposition of IFOM (IP Flow Mobility), the touted feature of Client-based mobility management approach. The ability to selective route discrete IP flows on different access networks based on the exchanged policies, is always looked at as some thing which the approaches of client-based mobility models can deal with in the most efficient manner, in comparison to the network-based mobility management approaches. Quite a bit of standardization efforts went into 3GPP and IETF mobility architectures around these specifications. But, now I’m beginning to wonder if the requirement is misunderstood, or if the problem has a much simpler solution.
Let us look at the primary service level requirements in the mobile network today:
These are the service-level requirements one can expect from the mobile network. Based on these service properties dictated by operator policies, the mobile network has to classify user flows into the following categories. Each of these flow types are associated with specific requirements.
Flow-X: Requires special QoS treatment from the 3GPP network. These flows cannot be offloaded to WLAN access whenever possible. Ex: SIP Flows.
Flow-Y: The operator does not care about seamless mobility for these flows. Whenever WLAN network is available, any new flows can be created over that WLAN access using simple IP, and can be routed without having them hit the ePDG (untrusted access over S2/b), or WLAN controller (trusted access over S2/a). Based on the policy, all existing sessions may break, or the policy applies only to the new flows created when WLAN access is available.
Flow-Z: The operator wants mobility for these flows, but they do not need any special treatment from the 3GPP network. Whenever WLAN access is available, these flows need to be moved to WLAN network, but they still need to be anchored in PDN GW. This just translates to change of access, but still anchoring the flows on the packet core.
A simple network illustration, consisting of a UE attached to the macro-network and an untrusted WLAN-access network. We can off course, bring the trusted WLAN access network, chained to EPC over S2/a PMIPv6, but we can ignore that for this discussion.
Now, can we meet the service requirements without introducing a client mobility stack on the UE. Lets look at the potential APN configuration, traffic flow policy and lets explore how this policy can be applied on some reference flows.
Example Flow Policy: Voice-flows & Video-flows: Should always stay over macro network, full mobility. Type=Flow-X Youtube-flow & Pandora-flow: Should be offloaded to WLAN network, with no mobility. Type=Flow-Y Skype-flow: Should be offloaded to WLAN network but should be brought back to EPC, with mobility. Type=Flow-Z
Can we not just define two APN’s and solve this issue. We just need two groups, all flows that need to stay in macro network and all flows that need to be moved to WLAN. Any time the mobile falls back to single access, all the sessions can be offloaded to the available access. Do we need any thing more than this. Is any operator looking at providing more extensive flow mobility support beyond this. However I see, its a flow group movement and not a discrete flow movement across access.
So, the question stands out, do we need client-based mobility management approach specifically for solving the IP flow mobility problem ? Are we looking at the requirement in a complex way ?
Below is a link to a video showing how to analyze traceroute output in L3VPN and look up CEF forwarding and MPLS/TE/SR/SR-TE forwarding for labels through a domain. Some basic examples of traffic engineering are used but the concepts lend the...
This document summarises various health checks that can be done on a Cisco VIM pod.
Cloud sanity checks the health status of network, storage and various openstack infrastructure components like mariadb, rabbitmq etc....
The following pre-requisites are necessary for the migration from RSP440 to RSP880-LT to be successful.
Make sure that you have console access to the router.
Verify that the system is running a minimum o...
BGP flowspec in a nutshell is a feature that will allow you to receive IPv4/IPv6 traffic flow specification (source X, destination Y, protocol UDP, source port A .. etc) and actions that need to be taken on that traffic (...
While gNMI is fairly new, it's becoming more and more powerful. Its abilities to simplify network management by the use of protocol buffer files and standard definitions are enabling our customers to integrate a lot better in multi-vendor e...