One document matched: draft-barkai-lisp-nfv-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.rodrigueznatal-lisp-sdn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rodrigueznatal-lisp-sdn.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-barkai-lisp-nfv-04" ipr="trust200902">
<front>
<title abbrev="">LISP Based FlowMapping for Scaling NFV</title>
<author fullname="Sharon Barkai" initials="S.B" surname="Barkai">
<organization>ConteXtream Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>sbarkai@gmail.com</email>
</address>
</author>
<author fullname="Dino Farinacci" initials="D.F" surname="Farinacci">
<organization>lispers.net</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<author fullname="David Meyer" initials="D.M" surname="Meyer">
<organization>Brocade</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>dmm@1-4-5.net</email>
</address>
</author>
<author fullname="Fabio Maino" initials="F.M" surname="Maino">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>fmaino@cisco.com</email>
</address>
</author>
<author fullname="Vina Ermagan" initials="V.E" surname="Ermagan">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>vermagan@cisco.com</email>
</address>
</author>
<author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez-Natal">
<organization>Technical University of Catalonia</organization>
<address>
<postal>
<street></street>
<city>Barcelona</city>
<region></region>
<code></code>
<country>Spain</country>
</postal>
<phone></phone>
<email>arnatal@ac.upc.edu</email>
</address>
</author>
<author fullname="Albert Cabellos-Aparicio" initials="A." surname="Cabellos-Aparicio">
<organization>Technical University of Catalonia</organization>
<address>
<postal>
<street></street>
<city>Barcelona</city>
<region></region>
<code></code>
<country>Spain</country>
</postal>
<phone></phone>
<email>acabello@ac.upc.edu</email>
</address>
</author>
<date year="2014" />
<area>Internet</area>
<workgroup>LISP Working Group</workgroup>
<keyword>LISP; deployment</keyword>
<abstract>
<t>This draft describes an RFC 6830 Locator ID Separation Protocol
(LISP) based distributed flow-mapping-fabric for dynamic scaling of
virtualized network functions (NFV). Network functions such as
subscriber-management, content-optimization, security and quality of
service, are typically delivered using proprietary hardware appliances
embedded into the network as turn-key service-nodes or service-blades
within routers. Next generation network functions are being implemented
as pure software instances running on standard servers - unbundled
virtualized components of capacity and functionality. LISP-SDN based
flow-mapping, dynamically assembles these components to whole solutions
by steering the right traffic in the right sequence to the right virtual
function instance.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref></t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This draft describes an RFC 6830 Locator ID Separation Protocol
(LISP) based distributed flow-mapping-fabric for dynamic scaling of
virtualized network functions (NFV).<xref
target="RFC6830"></xref>Network functions such as subscriber-management,
content-optimization, security and quality of service, are typically
delivered using proprietary hardware appliances embedded into the
network as turn-key service-nodes or service-blades within routers.</t>
<t>This monolithic service delivery method increases the complexity of
service roll-out and capacity planning, limits providers' choices, and
slows down revenue generating service innovation. Next generation
network functions are being implemented as pure software instances
running on standard servers - unbundled ("googlized") virtualized
components of capacity and functionality. Such a component based model
opens up service provider networks to the savings of elasticity and open
architecture driven innovation. However this model also presents the
network with the new challenges of assembling components, developed by
3rd parties, into whole solutions, by forwarding the right traffic to
the right function-block at the right sequence.</t>
<t>While this is possible, to some extent, by traditional virtual
networking - virtual bridges(vBridges) and virtual-routing-forwarding
(VRF) - these mechanisms are relatively static and require complex and
intensive configuration of network interfaces, while elastic components
are not network topology bound. Software-defined-networks, (SDN) flow
based models are much more dynamically programmable but are also very
centralized and hence have limited scale and resiliency. By enhancing
SDN models with RFC6830 overlay model, as <xref target="I-D.rodrigueznatal-lisp-sdn"></xref> suggests,
we offer a best fit to dynamic assembly of virtualized network functions
in the service-providers data-centers and distribution-centers.</t>
</section>
<section title="Terminology">
<t>The following terms are used to describe a LISP based implementation
of Software-Defined Flow-Mapping-Fabric for NFV:<list style="symbols">
<t>LISP-SDN - is an enhancement to the basic SDN model of (1)
hop-to-hop (2) push-down flow-commands (3) by
concentrated-controller.. to a LISP based architecture of (1)
distributed-overlay e.g. SDN over IP (2) based on a
pull-publish-subscribe actions from xTR-edges up.. (3) to a global
mapping service. A mapping service scaled by and connected over the
IP underlay network. LISP-SDN protocol operation details are
covered in <xref target="I-D.rodrigueznatal-lisp-sdn"></xref>.</t>
<t>Virtualized Network Function (VNF) - is a process instance with
an EID and RLOC that performs a defined set of inline network
functions. a VNF can be software on a virtual-machine (VM)
performing a function like multimedia signaling, mobility
management, content caching or streaming, security, filtering,
optimization, etc. A VNF class type and VNF instance capacity, load,
and location are attributes that can be resolved by the LISP-SDN
mapping service.</t>
<t>Client-Flow - is a sequence of packets that corresponds to a
specific communication thread or network conversation between a
client application and a network service. Client-flows are typically
processed by various in-network functions either as the end service
side to the network conversation, or as middle-box
functionality.</t>
<t>SDN-xTR - is a LISP xTR that behaves as defined in <xref target="I-D.rodrigueznatal-lisp-sdn"></xref>. It classifies traffic into
application flows, maps, encapsulates, and decapsulates flows in
order to emerge a flow-mapping solution - along with a collection of
the SDN-xTR elements, and the LISP-SDN mapping service.</t>
<t>SDN-Overlay - is the network formed by the collection of
inter-connected SDN-xTR</t>
<t>SDN-Underlay - is the IPvN network connecting SDN-xTRs</t>
<t>SDN-Outerlay (interim name)- is the collection of networks and
interfaces aggregated by the various SDN-xTRs connecting VNFs and
Client-flows coming from access networks or the Internet.</t>
<t>Flow-Rule - is a set of pattern tuples that match any part of a
packet header and is used to classify packets into flows as well as
trigger forwarding actions such as encapsulation / decapsulation,
network address translation (NAT), etc. We differentiate between
exact-match rules (many) which include an exact set of tuple bits,
and best match rules (fewer) which contain both tuple bits and
wild-cards "*".</t>
<t>Virtual IP (VIP) - is an IP address or EID that identifies a
function rather then a specific destination. For example all the
encapsulated client-flow traffic sent from a base-station eNodeBs
over a transport network, can have as destination a VIP which
represents in a given LISP-SDN solution, the function mobile-gateway
or PGW, and not any specific destination.</t>
<t>Flow-Affinity - is the association between a client-flow and a
VNF instance. VNF logic will typically create long-lived (minutes)
in memory states in order to perform its functions. Therefore once
an affinity is established it is best to keep it for as long as
possible in order not to stress or break the VNF application.</t>
</list></t>
</section>
<section anchor="connectivity_models" title="Connectivity Model">
<t>The basic connectivity model used to assemble VNFs into whole
solution is the flow-mapping-fabric. Unlike topological forwarding which
is based on source-subnet >> routed hop by hop >>
destination-subnet, a flow-mapping-fabric maps, forwards and "patches"
flows by identity directly to the end systems. The identities used for
the flow-mapping-fabric are those associated with the client-flows e.g.
Subscriber ID, phone number, TCP port, etc. and those associated with
the VNF e.g. the type, location, physical address, etc. the
flow-mapping-fabric is implemented as a LISP-SDN overlay, over in-place
IP underlay, assembling outerlay flows into solutions. Bellow are basic
assumptions regarding the Underlay, Outerlay, and Overlay in the
solution:</t>
<t><list style="symbols">
<t>The underlying physical network is assumed to be topology based
and implemented using standard bridging and routing. Conventional
design principles are applied in order to achieve both capacity and
availability of connectivity. Typical examples of underlays include
spine-leaf switching for clustering server racks, and, core-edge
routing inter-connecting server clusters across points of presence.
Edge networks are also used to connect to access networks and
Internet.</t>
<t>The flow-mapping-fabric maps outerlay client-flows to VNFs. This
enables assembly, scaling, balanced high-utilization, massive
concurrency, and hence, performance of NFVs. By mapping each
client-flow to the correct functional instance the system engages as
many VNF components as are available, scaled within and across
data-centers. Applied recursively client-flow mapping can chain a
sequence of VNF components to make up an end-to-end service.</t>
<t>The overlay network is based on location-identity-separation and
forms a virtualization indirection ring around spines and cores. The
overlay edges aggregate outerlay client-flows and VNFs. Outerlay
flows are classified, mapped, and encapsulated over the edge through
the underlay interfaces and are transported to the right identity's
locations.</t>
</list><vspace /><figure align="center"
title="Core-Edge Spine-Leaf Underlays">
<artwork align="center"><![CDATA[
POP3 POP4
\ / \ /
EdgeR -- EdgeRouter
| |
Access ... | Core | ... Internet
| |
EdgeR -- EdgeR
/ \
/ \
^ Spine1 Spine2 ... Spine5
| / \ / \ __/ / .. |
| | \/ | __/ / |
P | /\ || / |
O Leaf1 Leaf2 ... Leaf300
P |-PC1 |-PC1
1 |-PC2 |-PC2
| |.. |..
| |-PC40 |-PC40
v
]]></artwork>
</figure></t>
<t><figure align="center" title="Flow-Mapping-Fabric">
<artwork align="center"><![CDATA[
v << FunctionA FunctionB .. FunctionN
v
Recursion Instance1..i Instance1..j Instance1..k
v | | | | | | | | | | | |
v | | | | | | | | | | | |
SubsFlow1 o o o o - - -+ o o o - - -o o o o
| | | | | | | | | | | |
SubsFlow2 o + o o - - -o o o o - - -o o o o
| | | | | | | | | | | |
. ... ... ...
. ... ... ...
. ... ... ...
| | | | | | | | | | | |
SubsFlowM o o o o - - -o o o o - - -+ o o o
| | | | | | | | | | | |
]]></artwork>
</figure></t>
<t></t>
<t><figure align="center"
title="NFV Outerlay, LISP-SDN Overlay, IP Underlay">
<artwork align="center"><![CDATA[
Virtualized Network Functions: Data-Center A
| | | | | | | | |
OuterLay OuterLay OuterLay
\ | / \ | / \ | /
Mux Mux Mux
| | |
XTR XTR XTR
|| || ||
A ===============================
c || ||
c \ _|| ||_ /
e -XTR_ | | _XTR- Internetwork flows
s / || IPvN || \
s \ _|| Underlay ||_ /
-XTR_ | | _XTR- Internetwork flows
F / || || \
l || ||
o ===============================
w || || ||
s XTR XTR XTR
| | |
Mux Mux Mux
/ | \ / | \ / | \
OuterLay OuterLay OuterLay
| | | | | | | | |
Virtualized Network Functions: Distribution-Center B
]]></artwork>
</figure></t>
</section>
<section anchor="architecture" title="Flow-Mapping Elements">
<t>In order to implement NFV Flow-Mapping-Fabric using LISP-SDN We use
the following components and capabilities:</t>
<t><list style="numbers">
<t>Flow-Switching: is a component within an SDN-xTR and contains a
set of n-tuple flow-rules matched against each packet in order to
separate it to (LOCALLY defined) sequences representing flows. Flows
are either Encapsulated into the Overlay, decapsulated to the
Outerlay, or forwarded to SDN-xTR Control Agents.</t>
<t>Control-Agents: are software processes running in SDN-xTRs and
are invoked for each flow where an exact match was not present in
the Flow-Switching. The default "catch-all" Flow-Handler maps IP
flows to locations and gateways based on RFC 6830. Protocol and
application specific handlers can be loaded into the SDN-xTR for
handling specific mapping and AFFINITY requirements of network
functions. Examples of such protocols and applications can be SIP,
GTP, S1X etc.</t>
<t>Global-Mapping: is how GLOBALLY significant key-value mappings is
translated to LOCALLY defines flow masks and encapsulation actions.
Examples of such mappings include: Map a functional instance ID to a
function class ID; map subscriber-application ID to virtual function
instance ID; map instance ID to location; instance to health, load,
tenant; etc.</t>
</list></t>
<t><figure align="center" title="Identity-Location Overlay">
<artwork align="center"><![CDATA[
Orchestration Authorization OSS/BSS
Mappings Mappings Mappings
v v v
(Class-Instance) (3A, ACL) (Subs-Service)
v v v
_________________________________
| |
| LISP-MAP |
|_________________________________|
^ ^ ^
Runtime Mappings(location, affinity, load)
^ ^ ^
^ ------- ------- -------
| | Mapper| | Mapper| | Mapper|
| |-------| |-------| |-------|
X |Agents | |Agents | |Agents |
| |-------| |-------| |-------|
v | FlowX | | FlowX | | FlowX |
------- ------- ------- ]]></artwork>
</figure></t>
</section>
<section anchor="DayInaLife" title="Day-in-life of a Mapped Flow">
<t>Let us walk through detailed steps of the use of RFC6830 and LISP
architecture in order to perform resource virtualization and flow
assignment to virtual function instances.</t>
<t>At a high level, when a client-flow packet first arrives at a SDN-xTR
on the edge of the LISP overlay, the SDN-xTR must decide on a VNF
instance that is best suited to service this flow, assign this flow to
the selected VNF, and encapsulate this flow to the RLOC of the selected
virtual function instance.</t>
<t>To select the best suited VNF instance, the SDN-xTR queries the
Mapping System with the extracted identity parameters, both the client
and the function EIDs, and receives the list of all VNF instances that
represent that Function along with their RLOC and health-load
attributes. The SDN-xTR runs local algorithms on the returned set to
select the best suited virtual function instance.</t>
<t>Once selected, the SDN-xTR stores (registers) the assignment of this
flow to the associated VNF instance in the Mapping System. This
assignment is referred to as the Affinity for this flow. The SDN-xTR
also programs an exact match flow rule in its data-plane, so future
packets from this flow will be mapped to the same EID-RLOC.</t>
<t>In the following subsections We describe this process in more
detail.</t>
<section title="XTR Flow Edge">
<t>SDN-xTR locations define the boundary of the virtual network. For
the purpose of LISP-SDN flow-mapping-fabric We refer to the bellow
SDN-XTR generic reference architecture. Actual vendor implementations
may vary, but most likely will include similar components and
structure. The SDN-XTR includes:<list style="symbols">
<t>Mux-DeMux: Interfaces to the Underlay and Outerlay</t>
<t>Flow-Rules: Patterns-Actions, Exact / Best Match,
Encap-Decap</t>
<t>Control-Agents: Application specific flow-handlers registered
in the Flow-Rules</t>
</list><figure align="center" title="SDN-XTR Reference Architecture">
<artwork><![CDATA[
_______________________________________________
| Control Agents per Virtualized App |
| O O O O O O O |
| ___________________________________ |
| | 0101010*01* action (best match) | |
| | ... (100s) | |
| | 010100101010 action (exact match) | |
| |____________... (100Ks)____________| |
|_______________________________________________|
| SDN-XTR defines the Overlay |
Outer-Lay Underlay
VNFs and Client-Flows Other SDN-XTR-RLOCs
]]></artwork>
</figure>SDN-XTR Flow Switching works as follows:<list
style="numbers">
<t>For traffic from the Outerlay of THIS xTR that has an exact
match of all the source-dest-tags.. n-tuples, the packets are
processed by rule actions including encapsulation to the RLOC of
the xTR which aggregates the relevant function instance to which
this flow is mapped to.</t>
<t>For traffic from the Underlay that has an exact match of all
the source-dest-tags.. n-tuples, the packets are processed by rule
actions including decapsulation and forwarding to the Outerlay of
THIS xTR.</t>
<t>Traffic from the Outer-Lay or Underlay that does NOT have an
exact match of all the source-dest-tags.. tuples required for
normal forwarding, packets are forwarded to the control agent
registered in the best-matching rule.</t>
</list>SDN-XTR Control Agents work as follows:<list style="numbers">
<t>Mapping agent type and application scope is defined by the best
match entries that point to it. Control agents will typically
self-register in the flow-switch. XTR control-agents can register
to an existing best-match rule, or instantiate a new one.</t>
<t>Typical rule-patterns are pattern-scoped by an agent
registration, and can include: protocol or service type header
indications; specific virtual IP addresses (VIP) that represent a
service and not a specific destination; a specific source and
wild-card destination; or vice versa.</t>
<t>Mapping agents work with the LISP-SDN mapping service in order
to establish a global context and local considerations for mapping
decision. The goal of the agents' decision is ultimately to
provision the correct exact-match rule and actions that will
offload the flow-packets to flow-switching described above.</t>
</list>The SDN-xTR control agents query the LISP-SDN Mapping System
with the flow attributes including the destination VIP, as
followes:</t>
<t>Mapping System Lookup: Map-Request (Client identity,
Function-EID)</t>
<t>Two outcomes are possible based on whether an affinity already
exists for this flow (flow has already been assigned to a virtual
function instance):</t>
<t><list style="symbols">
<t>Outcome A:<list style="symbols">
<t>If an affinity already exists in the Mapping System, the
Mapping System returns the locator address (RLOC) associated
with the Function-Instance-EID that the (Client-EID,
Function-EID) is mapped to.</t>
<t>Map-Reply: ( (Client-EID, Function-EID) ->
Function-Instance-RLOC )</t>
<t>In this case the Mapping System also subscribes the SDN-xTR
to the Function-Instance-EID, and to the (Client-EID,
Function-EID) flow in order to receive updates in case of
changes on these entries. Examples of these changes are change
of RLOC for the Function-Instance-EID (specially if this is a
virtual application), or change of affinity for (Client-EID,
Function-EID) to another Function-Instance-EID.</t>
<t>After receiving the Map-Reply form the Mapping System, the
SDN-xTR programs an exact match for the flow in the xTR
data-plane.</t>
</list></t>
<t>Outcome B:<list style="symbols">
<t>If there is no affinity previously stored, the Mapping
System returns a list of Records, including one Record per
each instance of the Function-EID, with their associated RLOCs
and flags (weight, priority).</t>
<t>Map-Reply: (client EID, Function-Instance-Record 1,
Function-Instance-Record 2...)</t>
<t>the SDN-xTR then selects the best suited
Function-Instance-EID for this flow based on local algorithms,
and registers the affinity in the Mapping System. The Mapping
System stores the affinity and subscribes the SDN-xTR to the
affinity and to the Function-Instance-EID in the affinity, so
that SDN-xTR would receive updates if any of these
changes.</t>
<t>Map-Register ( (Client-EID, Function-EID) ->
Function-Instance-EID)</t>
</list></t>
<t>Note: An SDN-xTR must be able to query for the list of
App-Instance-Records even if an affinity already exists. For this
purpose a flag is required in the Map-Request to indicate whether
xTR wants this info or not. We can overload the M bit in
Map-Request, or allocate a new bit for this.</t>
<t></t>
</list></t>
<t></t>
</section>
<section title="Map Resolvers-Servers"></section>
<section title="XTRs-Mappers Scaling"></section>
</section>
<section title="Message Formats">
<t>This section specifies the packet formats used throughout the
flow-mapping process explained above. This section is expected to
be extended and moved to <xref target="I-D.rodrigueznatal-lisp-sdn"></xref>.</t>
<t>A Map-Request is used with a 2-Tuple Src/Dst LCAF to query the
Mapping System for the affinity or list of virtual function instance
records for this flow.</t>
<t><figure align="center"
title="LISP Map-Request with 2-Tuple Src/Dst LCAF">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EID mask-len | EID-prefix-AFI = 16387 |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Rsvd1 | Flags | Type = 12 | Rsvd2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 4 + n | Reserved |
L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C | Source-ML | Dest-ML | AFI = x |
A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F | Source-Prefix ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AFI = x | Destination-Prefix ... |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Source-Prefix = Client-EID
Destination-Prefix = App-EID
]]></artwork>
</figure></t>
<t>In order to specify a 5 tuple flow, rather than just a two tuple
source and destination, the combination of LCAF type 12 and LCAF type 4
must be used.</t>
<t></t>
<t>If an affinity exists in the Mapping System, meaning that the flow is
already assigned to a virtual function instance, then the RLOC of that
Function-Instance must be returned by the Mapping System. A Map-Reply
with a 2-Tuple Src/Dst Lcaf can be used for this.</t>
<t><figure align="center"
title="Map-Reply containing 2-Tuple LCAF and Associated Function-Instance-RLOC">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
e | Locator Count | EID mask-len | ACT |A| Reserved |
c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o | Rsvd | Map-Version Number | EID-prefix-AFI = 16387 |
r +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | | Rsvd1 | Flags | Type = 12 | Rsvd2 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | 4 + n | Reserved |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C | Source-ML | Dest-ML | AFI = x |
| A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | Source-Prefix ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | AFI = x | Destination-Prefix ... |
| +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>If no affinity exists, the Mapping System returns a list of records,
including one record per each Function-Instance for the flow's
Function-EID. A LISP Map-Reply can be used for this purpose with a
2-Tuple Src/Dst LCAF as the EID prefix in each Record.</t>
<t>If it is desired to return tuples of (Function-Instance-EID ->
RLOC) per each record, a new LCAF, introduced as below, could be
used.</t>
<t><figure align="center" title="EID-RLOC LCAF:">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 | Rsvd2 | 4 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID-ML | RSVD3 | EID-AFI = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLOC-AFI = x | Locator Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>In which, for the purpose of NFV, EID prefix will be used to specify
Function-Instance-EID, and Locator address is the RLOC associated with
that Funstion-Instance-EID. This LCAF can be used in place of the
Loc-AFI in the Map-Reply Message above to include a list of
(Function-Instance-EID,RLOC) for every (Client-EID, Function-EID) in the
Map-Reply.</t>
<t>Finally to store the affinity of the flow in the Mapping System a
Map-Register can be used where EID AFI is filled with a LCAF type 12
(2-Tuple Src/Dst LCAF), and Loc-AFI is filled with the AFI of the
Function-Instance-EID, and the Locator is filled with the
Function-Instance-EID. This way, a query on the flow 2-Tuple returns the
Function-Instance-EID that the flow is assigned to.</t>
</section>
<section anchor="qos" title="QOS and Echo Measurements">
<t></t>
</section>
<section anchor="security" title="Security Considerations">
<t>there are no security considerations related with this memo.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>there are no IANA considerations related with this memo.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include="reference.RFC.6830"
?>
&I-D.rodrigueznatal-lisp-sdn;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:32:01 |