LISP Based FlowMapping for Scaling NFV

This draft describes distributed flow-mapping applied according to RFC 6830 Locator ID Separation Protocol (LISP) for dynamic scaling of virtualized network functions (NFV) .Network functions such as subscriber management-mobility-security-quality are typically delivered using proprietary appliances topologically embedded into the network as service-nodes or service-blades. This monolithic service delivery method increases the complexity of roll-out and capacity planning, limits functional choices, and inhibits service innovation. Next generation virtualized network functions are pure software instances running on standard servers - unbundled building blocks of compute capacity and modular functionality. This component based model opens up service provider networks to the savings of elasticity and the innovation of an open architectures. However this model also presents the network (or the virtual network rather) with the brand new challenges of assembling components into whole solutions by forwarding the right traffic to the right process at the right sequence and the right time. While it is possible, to some extent, to use traditional virtual networking mechanisms such as virtual-LANs (VLAN) and virtual-private-networks (VPN) in-order to map traffic to functions-processes, these mechanisms are relatively static and require complex and intense configuration of physical network interfaces with vbridge vrf configuration. NGN software-defined flow based models on the other hand are much more programmable and dynamic, and if orchestrated properly offer a better fit to next generation service-provider data-centers. LISP based flow-mapping enables such a dynamic global orchestration of flows. LISP xTRs wire virtual function instances into the data-path, based on dynamic identity-function and identity-location mappings, perform these actions in a dynamically programmable and elastic manner, and operate based on subscriber-profiles and function-demand global information.

The basic connectivity model used to map flows to function is an identity-matrix forwarding. Unlike topological forwarding models which are based on source-subnet >> routed hop by hop >> to destination-subnet, identity-matrices are based on flow-identity "patched" to function-identity. This model is implemented using the LISP distributed overlay and LISP distributed database mechanisms. These mechanisms are applied over in-place physical networks in a manner described bellow: The topological network basis or the "location" network is assumed to be implemented using standard bridging and routing. Basic design principles are applied in order to achieve both physical capacity and physical availability of connectivity. Typical examples of these practices include spine-leafs switching for cluster many server racks that are used as the compute and virtual compute foundations to functions. These practices also include core-edge routing for inter-connecting server clusters across points of presence, as well as for inter-connecting these points of presence to the access networks and to the public Internet. The functional network or the "identity" matrix is there to map identified subscriber-flows carrying an application thread to the right function task or instance. This identity-matrix enables scaling and massive concurrency of the logical compute functions. By mapping each subscriber-application flow to the correct processes based on global definitions of the service and application, the system can engage as many functional components as there are available within and across data canters. Applied recursively flow-function matrix mapping can chain as many distinct functional components that make up a service as defined globally by the operator. The overlay network or the location-identity fabric enables the implementation of the functional network on the physical in-place bridge-routed network. The overlay forms a virtualization ring around the core-spine physical networks. All subscriber flows and function flows are aggregated at the outer interfaces of this virtualization ring, and are encapsulated over the inner interfaces of this ring in order to reach each of the locations. Ingress-Aggregation, Flow-Seperation, Matrix-Mapping, Encapsulation-Decapsulation, Egress-Delivry are all based on LISP xTRs and LISP mmap architecture and services.

In order to map subscriber flows to virtualized function instances and essentially to overlay identity grid onto topology based bridge-routed network we use the following XTR 3-tier reference architecture: Flow-Switching: is a set of n-tuple LOCALLY defined masks, BEST matched against each packet in-order to separate traffic to LOCALLY significant sequences representing application threads. Flows are either Encapsulated in-to the overlay, Decapsulated out-of the overlay, Forwarded up-to xTR internally registered Flow-Handlers .. Flow-Handlers: are a set of control processes invoked for each flow where a specific identity-location mapping has not been defined and provisioned into the Flow-Switching. The default "catch-all" Flow-Handler maps IP flows to locations and gateways based on RFC 6830. In addition protocol-specific handlers can be loaded into the xTR for dealing with specific mapping and AFFINITY requirements of network functions such as SIP, GTP, S1X etc. Global-Mappers: is how GLOBALLY significant key-value mappings is translated by Flow-Handlers to LOCALLY defines masks and encapsulation headers. Examples of such mappings include functional VIP to actual function processes EIDs, application specific SubscriberIDs to function EIDs, public IP-Port to SubscriberID, and EIDs to RLOCs.

There are no security considerations related with this memo.

There are no IANA considerations related with this memo.