LISP Based FlowMapping for Scaling NFVConteXtream Inc.CaliforniaUSASharon@Contextream.c.CaliforniaUSAfarinacci@gmail.comBrocadeCaliforniaUSAdmm@1-4-5.netCisco SystemsCaliforniaUSAfmaino@cisco.comCisco SystemsCaliforniaUSAvermagan@cisco.com
Internet
LISP Working GroupLISP; deploymentThis 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. Next generation virtualized network
functions are pure software instances running on standard servers -
unbundled building blocks of processing capacity and modular
functionality. LISP based flow-mapping dynamically wires VNF instances
into the data-path, and scales virtualized functions by steering the
right traffic in the right sequence to the right process.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .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.