One document matched: draft-maino-nvo3-lisp-cp-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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-maino-nvo3-lisp-cp-02" ipr="trust200902">
<front>
<title abbrev="LISP Control Plane for NVO3">LISP Control Plane for Network
Virtualization Overlays</title>
<author fullname="Fabio Maino" initials="F.M" surname="Maino">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<code>95134</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>170 Tasman Drive</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region>
<country>USA</country>
</postal>
<email>vermagan@cisco.com</email>
</address>
</author>
<author fullname="Dino Farinacci" initials="D.F" surname="Farinacci">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region>
<country>USA</country>
</postal>
<email>dino@cisco.com</email>
</address>
</author>
<author fullname="Michael Smith" initials="M.S" surname="Smith">
<organization>Insieme Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>michsmit@insiemenetworks.com</email>
</address>
</author>
<date day="22" month="October" year="2012" />
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<keyword>LISP; deployment</keyword>
<abstract>
<t>The purpose of this draft is to analyze the mapping between the
Network Virtualization over L3 (NVO3) requirements and the capabilities
of the Locator/ID Separation Protocol (LISP) control plane. This
information is provided as input to the NVO3 analysis of the suitability
of existing IETF protocols to the NVO3 requirements.</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>The purpose of this draft is to analyze the mapping between the
Network Virtualization over L3 (NVO3) <xref
target="I-D.ietf-nvo3-overlay-problem-statement"></xref> requirements
and the capabilities of the Locator/ID Separation Protocol (LISP) <xref
target="I-D.ietf-lisp"></xref> control plane. This information is
provided as input to the NVO3 analysis of the suitability of existing
IETF protocols to the NVO3 requirements.</t>
<t>LISP is a flexible map and encap framework that can be used for
overlay network applications, including Data Center Network
Virtualization.</t>
<t>The LISP framework provides two main tools for NVO3: (1) a Data Plane
that specifies how Endpoint Identifiers (EIDs) are encapsulated in
Routing Locators (RLOCs), and (2) a Control Plane that specifies the
interfaces to the LISP Mapping System that provides the mapping between
EIDs and RLOCs.</t>
<t>This document focuses on the control plane for L2 over L3 LISP
encapsulation, where EIDs are associated with MAC addresses. As such the
LISP control plane can be used with the data path encapsulations defined
in VXLAN <xref target="I-D.mahalingam-dutt-dcops-vxlan"></xref> and in
NVGRE <xref target="I-D.sridharan-virtualization-nvgre"></xref>. The
LISP control plane can, of course, be used with the L2 LISP data path
encapsulation defined in <xref
target="I-D.smith-lisp-layer2"></xref>.</t>
<t>The LISP control plane provides the Mapping Service for the Network
Virtualization Edge (NVE), mapping per-tenant end system identity
information on the corresponding location at the NVE. As required by
NVO3, LISP supports network virtualization and tenant separation to hide
tenant addressing information, tenant-related control plane activity and
service contexts from the underlay network.</t>
<t>The LISP control plane is extensible, and can support non-LISP data
path encapsulations such as <xref
target="I-D.sridharan-virtualization-nvgre"></xref>, or other
encapsulations that provide support for network virtualization. <xref
target="I-D.ietf-lisp-interworking"></xref> specifies an open
interworking framework to allow LISP to non-LISP sites
communication.</t>
<t>Broadcast, unknown unicast, and multicast in the overlay network are
supported by either replicated unicast, or core-based multicast as
specified in <xref target="I-D.ietf-lisp-multicast"></xref>, <xref
target="I-D.farinacci-lisp-mr-signaling"></xref>, and <xref
target="I-D.farinacci-lisp-te"></xref>.</t>
<t>Finally, the LISP architecture has a modular design that allows the
use of different Mapping Databases, provided that the interface to the
Mapping System remains the same <xref target="I-D.ietf-lisp-ms"></xref>.
This allows for different Mapping Databases that may fit different NVO3
deployments. As an example of the modularity of the LISP Mapping System,
a worldwide LISP pilot network is currently using an hierarchical
Delegated Database Tree <xref target="I-D.fuller-lisp-ddt"></xref>,
after having been operated for years with an overlay BGP mapping
infrastructure <xref target="I-D.ietf-lisp-alt"></xref>.</t>
<t>The LISP mapping system supports network virtualization, and a single
mapping infrastructure can run multiple instances, either public or
private, of the mapping database.</t>
<t>The rest of this document, after giving a quick a LISP overview in
<xref target="overview"></xref>, follows the functional model defined in
<xref target="I-D.lasserre-nvo3-framework"></xref> that provides in
<xref target="reference"></xref> an overview of the LISP NVO3 reference
model, and in <xref target="components"></xref> a description of its
functional components. <xref target="key-aspects"></xref> contains
various considerations on key aspects of LISP NVO3, followed by security
considerations in <xref target="security"></xref>.</t>
</section>
<section anchor="terms" title="Definition of Terms">
<t><list style="empty">
<t>Flood-and-Learn: the use of dynamic (data plane) learning in
VXLAN to discover the location of a given Ethernet/IEEE 802 MAC
address in the underlay network.</t>
<t>ARP-Agent Reply: the ARP proxy-reply of an agent (e.g. an ITR)
with a MAC address of some other system in response to an ARP
request to a target which is not the agent's IP address</t>
</list></t>
<t>For definition of NVO3 related terms, notably Virtual Network (VN),
Virtual Network Identifier (VNI), Network Virtualization Edge (NVE),
Data Center (DC), please consult <xref
target="I-D.lasserre-nvo3-framework"></xref>.</t>
<t>For definitions of LISP related terms, notably Map-Request,
Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR),
Map-Server (MS) and Map-Resolver (MR) please consult the LISP
specification <xref target="I-D.ietf-lisp"></xref>.</t>
</section>
<section anchor="overview" title="LISP Overview">
<t>This section provides a quick overview of L2 LISP, with focus on
control plane operations.</t>
<t>The modular and extensible architecture of the LISP control plane
allows its use with both L2 or L3 LISP data path encapsulation. In fact,
the LISP control plane can be used even with other L2 overlay data path
encapsulations such as VXLAN and NVGRE. When used with VXLAN, the LISP
control plane replaces the use of dynamic data plane learning
(Flood-and-Learn), as specified in <xref
target="I-D.mahalingam-dutt-dcops-vxlan"></xref> improving scalability
and mitigating multicast requirements in the underlay network.</t>
<t>For a detailed LISP overview please refer to <xref
target="I-D.ietf-lisp"></xref> and related drafts.</t>
<t>To exemplify LISP operations let’s consider two data centers
(LISP sites) A and B that provide L2 network virtualization services to
a number of tenant end systems, as depicted in <xref
target="l2-nve"></xref>. The Endpoint Identifiers (EIDs) are encoded
according to <xref target="I-D.ietf-lisp-lcaf"></xref> as an
<IID,MAC> tuple that contains the Instance ID, or Virtual Network
Identifier (VNI), and the endpoint Ethernet/IEEE 802 MAC address.</t>
<t>The data centers are connected via a L3 underlay network, hence the
Routing Locators (RLOCs) are IP addresses (either IPv4 or IPv6) encoded
according to <xref target="I-D.ietf-lisp-lcaf"></xref>.</t>
<t>In LISP the network virtualization edge function is performed by
Ingress Tunnel Routers (ITRs) that are responsible for encapsulating the
LISP ingress traffic, and Egress Tunnel Routers (ETRs) that are
responsible for decapsulating the LISP egress traffic. ETRs are also
responsible to register the EID-to-RLOC mapping for a given LISP site in
the LISP mapping database system. ITRs and ETRs are collectively
referred as xTRs.</t>
<t>The EID-to-RLOC mapping is stored in the LISP mapping database, a
distributed mapping infrastructure accessible via Map Servers (MS) and
Map Resolvers (MR). <xref target="I-D.fuller-lisp-ddt"></xref> is an
example of a mapping database used in many LISP deployments. Another
example of of mapping database is <xref
target="I-D.ietf-lisp-alt"></xref>.</t>
<t>For small deployments the mapping infrastructure can be very minimal,
in some cases even a single system running as MS/MR.</t>
<t><figure align="center" anchor="l2-nve"
title="Example of L2 NVO3 Services">
<artwork align="center"><![CDATA[
,---------.
,' `.
(Mapping System )
`. ,'
`-+------+'
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
| |
.--..--. .--. ..
( ' '.--.
.-.' L3 '
( Underlay )
( '-'
._.'--'._.'.-._.'.-._)
RLOC=IP_A // \\ RLOC=IP_B
+---+--+ +-+--+--+
.--.-.|xTR A |'.-. .| xTR B |.-.
( +---+--+ ) ( +-+--+--+ )
( __. ( '.
..' LISP Site A ) .' LISP Site B )
( .'-' ( .'-'
'--'._.'. )\ '--'._.'. )\
/ '--' \ / '--' \
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
: Device : : Device : : Device : : Device :
'--------' '--------' '--------' '--------'
EID= EID= EID= EID=
<IID1,MAC_W> <IID2,MAC_X> <IID1,MAC_Y> <IID1,MAC_Z>
]]></artwork>
</figure></t>
<section anchor="configuration" title="LISP Site Configuration">
<t>In each LISP site the xTRs are configured with an IP address (the
site RLOCs) per each interface facing the underlay network.</t>
<t>Similarly the MS/MR are assigned an IP address in the RLOC
space.</t>
<t>The configuration of the xTRs includes the RLOCs of the MS/MR and a
shared secret that is optionally used to secure the communication
between xTRs and MS/MR.</t>
<t>To provide support for multi-tenancy multiple instances of the
mapping database are identified by a LISP Instance ID (IID), that is
equivalent to the 24-bit VXLAN Network Identifier (VNI) or Tenant
Network Identifier (TNI) that identifies tenants in <xref
target="I-D.mahalingam-dutt-dcops-vxlan"></xref>.</t>
</section>
<section anchor="provisioning" title="End System Provisioning">
<t>We assume that a provisioning framework will be responsible for
provisioning end systems (e.g. VMs) in each data center. The
provisioning configures each end system with an Ethernet/IEEE 802 MAC
address and provision the network with other end system specific
attributes such as IP addresses, and VLAN information. LISP does not
introduce new addressing requirements for end systems.</t>
<t>The provisioning infrastructure is also responsible to provide a
network attach function, that notifies the network virtualization edge
(the LISP site ETR) that the end system is attached to a given virtual
network (identified by its VNI/IID) and that the end system is
identified, within that virtual network, by a given Ethernet/IEEE 802
MAC address.</t>
</section>
<section anchor="registration" title="End System Registration">
<t>Upon notification of end system network attach, that includes the
EID=<IID,MAC> tuple that identifies that end system, the ETR
sends a LISP Map-Register to the Mapping System. The Map-Register
includes the EID and RLOCs of the LISP site. The EID-to-RLOC mapping
is now available, via the Mapping System Infrastructure, to other LISP
sites that are hosting end systems that belong to the same tenant.</t>
<t>For more details on end system registration see <xref
target="I-D.ietf-lisp-ms"></xref>.</t>
</section>
<section anchor="flow" title="Packet Flow and Control Plane Operations">
<t>This section provides an example of the unicast packet flow and the
control plane operations when in the topology shown in <xref
target="l2-nve"></xref> end system W, in LISP site A, wants to
communicate to end system Y in LISP site B. We’ll assume that W
knows Y’s EID MAC address (e.g. learned via ARP).</t>
<t><list style="symbols">
<t>W sends an Ethernet/IEEE 802 MAC frame with destination
EID=<IID1,MAC_Y> and source EID=<IID1,MAC_W>.</t>
<t>ITR A does a lookup in its local map-cache for the destination
EID=<IID1, MAC_Y>. Since this is the first packet sent to
MAC_Y, the map-cache is a miss, and the ITR sends a Map-request to
the mapping database system looking up the
EID=<IID1,MAC_Y>.</t>
<t>The mapping systems forwards the Map-Request to ETR B, that is
aware of the EID-to-RLOC mapping for <IID1,MAC_Y>.
Alternatively, depending on the mapping system configuration, a
Map-Server which is part of the mapping database system may send a
Map-Reply directly to ITR A.</t>
<t>ETR B sends a Map-Reply to ITR A that includes the EID-to-RLOC
mapping: EID=<IID1,MAC_Y> -> RLOC=IP_B, where IP_B is the
locator of ETR B, hence the locator of LISP site B. In order to
facilitate interoperability, the Map-Reply may also include
attributes such as the data plane encapsulations supported by the
ETR.</t>
<t>ITR A populates the local map-cache with the EID to RLOC
mapping, and either L2 LISP, VXLAN, or NVGRE encapsulates all
subsequent packets with a destination EID=<IID1,MAC_Y> with
a destination RLOC=IP_B.</t>
</list>It should be noted how the LISP mapping system replaces the
use of Flood-and-Learn based on multicast distribution trees
instantiated in the underlay network (required by VXLAN’s
dynamic data plane learning), with a unicast control plane and a cache
mechanism that “pulls” on-demand the EID-to-RLOC mapping
from the LISP mapping database. This improves scalability, and
simplifies the configuration of the underlay network.</t>
<section anchor="arp"
title="Supporting ARP Resolution with LISP Mapping System">
<t>A large majority of data center applications are IP based, and in
those use cases end systems are provisioned with IP addresses as
well as MAC addresses.</t>
<t>In this case, to eliminate the flooding of ARP traffic and
further reduce the need for multicast in the underlay network, the
LISP mapping system is used to support ARP resolution at the ITR. We
assume that as shown in <xref target="l3-nve"></xref>: (1) end
system W has an IP address IP_W, and end system Y has an IP address
IP_Y, (2) end system W knows Y’s IP address (e.g. via DNS
lookup). We also assume that during registration Y has registered
both its MAC address and its IP address as EID. End system Y is then
identified by the EID = <IID1,IP_Y,MAC_Y>.</t>
<t><figure align="center" anchor="l3-nve"
title="Example of L3 NVO3 Services">
<artwork align="center"><![CDATA[
,---------.
,' `.
(Mapping System )
`. ,'
`-+------+'
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
| |
.--..--. .--. ..
( ' '.--.
.-.' L3 '
( Underlay )
( '-'
._.'--'._.'.-._.'.-._)
RLOC=IP_A // \\ RLOC=IP_B
+---+--+ +-+--+--+
.--.-.|xTR A |'.-. .| xTR B |.-.
( +---+--+ ) ( +-+--+--+ )
( __. ( '.
..' LISP Site A ) .' LISP Site B )
( .'-' ( .'-'
'--'._.'. )\ '--'._.'. )\
/ '--' \ / '--' \
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
: Device : : Device : : Device : : Device :
'--------' '--------' '--------' '--------'
EID= EID= EID= EID=
<IID1,IP_W, <IID2,IP_X, <IID1,IP_Y, <IID1,IP_Z,
MAC_W> MAC_X> MAC_Y> MAC_Z>
]]></artwork>
</figure>The packet flow and control plane operation are as
follows:</t>
<t><list style="symbols">
<t>End system W sends a broadcast ARP message to discover the
MAC address of end system Y. The message contains IP_Y in the
ARP message payload.</t>
<t>ITR A, acting as a L2 switch, will receive the ARP message,
but rather than flooding it on the overlay network sends a
Map-Request to the mapping database system for EID =
<IID1,IP_Y,*>.</t>
<t>The Map-Request is routed by the mapping system
infrastructure to ETR B, that will send a Map-Reply back to ITR
A containing the mapping EID=<IID1,IP_Y,MAC_Y> ->
RLOC=IP_B, (the locator of ETR B). Alternatively, depending on
the mapping system configuration, a Map-Server in the mapping
system may send directly a Map-Reply to ITR A.</t>
<t>ITR A populates the map-cache with the received entry, and
sends an ARP-Agent Reply to W that includes MAC_Y and IP_Y.</t>
<t>End system W learns MAC_Y from the ARP message and can now
send a packet to end system Y by including MAC_Y, and IP_Y, as
destination addresses.</t>
<t>ITR A will then process the packet as specified in Section
3.4.</t>
</list>This example shows how LISP, by replacing dynamic data
plane learning (Flood-and-Learn) largely reduces the need for
multicast in the underlay network, that is needed only when
broadcast, unknown unicast or multicast are required by the
applications in the overlay. In practice, the LISP mapping system,
constrains ARP within the boundaries of a link-local protocol. This
simplifies the configuration of the underlay network and removes the
significant scalability limitation imposed by VXLAN
Flood-and-Learn.</t>
<t>It’s important to note that the use of the LISP mapping
system, by pulling the EID-to-RLOC mapping on demand, also improves
end system mobility across data centers.</t>
</section>
</section>
<section anchor="mobility" title="End System Mobility">
<t>This section shows how the LISP control plane deals with mobility
when end systems are migrated from one Data Center to another. We'll
assume that a signaling protocol, as described in <xref
target="I-D.kompella-nvo3-server2nve"></xref>, signals to the NVE
operations such as creating/terminating/migrating an end system. The
signaling protocol consists of three basic messages: "associate",
"dissociate", and "pre-associate".</t>
<t>Let's consider the scenario shown in <xref
target="l2-mobility"></xref> where end system W moves from data center
A to data center B.</t>
<t><figure align="center" anchor="l2-mobility"
title="End System Mobility">
<artwork align="center"><![CDATA[
,---------.
,' `.
(Mapping System )
`. ,'
`-+------+'
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
| |
.--..--. .--. ..
( ' '.--.
.-.' L3 '
( Underlay )
( '-'
._.'--'._.'.-._.'.-._)
RLOC=IP_A // \\ RLOC=IP_B
+---+--+ +-+--+--+
.--.-.|xTR A |'.-. .| xTR B |.-.
( +---+--+ ) ( +-+--+--+ )
( __. ( '.
..' LISP Site A ) .' LISP Site B )
( .'-' ( .'-'
'--'._.'. )\ '--'._.'. )\
/ '--' \ / '--' \
'--------' '--------' '--------' '--------'
: End : : End : ==> : End : : End :
: Device : : Device : ==> : Device : : Device :
'--------' '--------' '--------' '--------'
EID= EID=<IID1,MAC_W> EID=
<IID2,MAC_X> <IID1,MAC_Z>
]]></artwork>
</figure>As a result of the end system registration, described in
<xref target="registration"></xref>, the Mapping System contains the
EID-to-RLOC mapping for end system W that associates EID=<IID1,
MAC_W> with the RLOC(s) associated with LISP site A (IP_A).</t>
<t>The process of migrating end system W from data center A to data
center B is initiated.</t>
<t>ETR B receives a pre-associate message that includes EID=<IID1,
MAC_W>. ETR B sends a Map-Register to the mapping system
registering RLOC=IP_B as an additional locator for end system W with
priority set to 255. This means that the RLOC MUST NOT be used for
unicast forwarding, but the mapping system is now aware of the new
location.</t>
<t>During the migration process of end system W, ETR A receives a
dissociate message, and sends a Map-Register with Record TTL=0 to
signal the mapping system that end system W is no longer reachable at
RLOC=IP_A. xTR A will also add an entry in its forwarding table that
marks EID=<IID1, MAC_W> as non-local. When end system W has
completed its migration, ETR B receives an associate message for end
system W, and sends a Map-Register to the mapping system setting a
non-255 priority for RLOC=IP_B. Now the mapping system is updated with
the new EID-to-RLOC mapping for end system W with the desired
priority.</t>
<t>The remote ITRs that were corresponding with end system W during
the migration will keep sending packets to ETR A. ETR A will keep
forwarding locally those packets until it receives a dissociate
message, and the entry in the forwarding table associated with
EID=<IID1, MAC_W> is marked as non-local. Subsequent packets
arriving at ETR A from a remore ITR, and destined to end system W will
hit the entry in the forwarding table that will generate an exception,
and will generate a Solicit-Map-Request (SMR) message that is returned
to the remote ITR. Upon receiving the SMR the remote ITR will
invalidate its local map-cache entry for EID=<IID1, MAC_W> and
send a new Map-Request for that EID. The Map-Request will generate a
Map-Reply that includes the new EID-to-RLOC mapping for end system W
with RLOC=IP_B. Similarly, unencapsulated packets arriving at ITR A
from local end systems and destined to end system W will hit the entry
in the forwarding table marked as non-local, and will generate an
exception that by sending a Map-Request for EID=<IID1, MAC_W>
will populate the map-cache of ITR A with an EID-to-RLOC mapping for
end system W with RLOC=IP_B.</t>
</section>
<section anchor="l3-lisp" title="L3 LISP">
<t>The two examples above shows how the LISP control plane can be used
in combination with either L2 LISP, VXLAN, or NVGRE encapsulation to
provide L2 network virtualization services across data centers.</t>
<t>There is a trend, led by Massive Scalable Data Centers, that is
accelerating the adoption of L3 network services in the data center,
to preserve the many benefits introduced by L3 (scalability,
multi-homing, …).</t>
<t>LISP, as defined in <xref target="I-D.ietf-lisp"></xref>, provides
L3 network virtualization services over an L3 underlay network that,
as an alternative to L2 overlay solutions, matches the requirements
for DC Network Virtualization. L2 overlay solutions are necessary for
Data Centers that rely on non IPv4/IPv6 protocols, but when IP is
pervasive L3 LISP provides a better and more scalable overlay.</t>
</section>
</section>
<section anchor="reference" title="Reference Model">
<t></t>
<section anchor="lisp-model" title="Generic LISP NVE Reference Model">
<t>In the generic NVO3 reference model described in <xref
target="I-D.lasserre-nvo3-framework"></xref>, a Tenant End System
attaches to a Network Virtualization Edge (NVE) either directly or via
a switched network.</t>
<t>In a LISP NVO3 network the Tenant End Systems are part of a LISP
site, and the NVE function is provided by LISP xTRs. xTRs provide for
tenant separation, perform the encap/decap function, and interface
with the LISP Mapping System that maps tenant addressing information
(in the EID name space) on the underlay L3 infrastructure (in the RLOC
name space).</t>
<t>Tenant segregation across LISP sites is provided by the LISP
Instance ID (IID), a 24-bit value that is used by the LISP routers as
the Virtual Network Identifier (VNI). Virtualization and Segmentation
with LISP is addressed in section 5.5 of <xref
target="I-D.ietf-lisp"></xref>.</t>
<t><figure align="center"
title="Generic reference model for DC NVO3 LISP infrastructure">
<artwork align="center"><![CDATA[
............... ,---------. ..............
. +--------+ . ,' `. . +--------+ .
. | Tenant | . (Mapping System ) . | Tenant | .
. | End +---+ `. ,' +---| End | .
. | System | . | `-+------+' | . | System | .
. +--------+ . | ................... | . +--------+ .
. . | +-+--+ +--+-+ | . .
. . | | NV | | NV | | . .
. LISP Site . +--|Edge| |Edge|--+ . LISP Site .
. . +-+--+ +--+-+ . .
. . / (xTR) L3 Overlay (xTR)\ . .
. +--------+ . / . Network . \ . +--------+.
. | Tenant +---+ . . +----| Tenant |.
. | End | . . (xTR) . . | End |.
. | System | . . +----+ . . | System |.
. +--------+ . .....| NV |........ . +--------+.
............... |Edge| .............
+----+
.........|............
. |LISP Site .
. | .
. +--------+ .
. | Tenant | .
. | End | .
. | System | .
. +--------+ .
......................
]]></artwork>
</figure></t>
</section>
<section anchor="lisp-services" title="LISP NVE Service Types">
<t>LISP can be used to support both L2 NVE and L3 NVE service types
thanks to the flexibility provided by the LISP Canonical Address
Format <xref target="I-D.ietf-lisp-lcaf"></xref>, that allows for EIDs
to be encoded either as MAC addresses or IP addresses.</t>
<section anchor="l2-services" title="LISP L2 NVE Services">
<t>The frame format defined in <xref
target="I-D.mahalingam-dutt-dcops-vxlan"></xref>, has a header
compatible with the LISP data path encapsulation header, when MAC
addresses are used as EIDs, as described in section 4.12.2 of <xref
target="I-D.ietf-lisp-lcaf"></xref>.</t>
<t>The LISP control plane is extensible, and can support non-LISP
data path encapsulations such as NVGRE <xref
target="I-D.sridharan-virtualization-nvgre"></xref>, or other
encapsulations that provide support for network virtualization.</t>
</section>
<section anchor="l3-services" title="LISP L3 NVE Services">
<t>LISP is defined as a virtualized IP routing and forwarding
service in <xref target="I-D.ietf-lisp"></xref>, and as such can be
used to provide L3 NVE services.</t>
</section>
</section>
</section>
<section anchor="components" title="Functional Components">
<t>This section describes the functional components of a LISP NVE as
defined in Section 3 of <xref
target="I-D.lasserre-nvo3-framework"></xref>.</t>
<section anchor="generic-components"
title="Generic Service Virtualization Components">
<t>The generic reference model for NVE is depicted in Section 3.1 of
<xref target="I-D.lasserre-nvo3-framework"></xref>.</t>
<t><figure align="center" title="Generic reference model for NV Edge">
<artwork align="center"><![CDATA[
+------- L3 Network ------+
| |
| Tunnel Overlay |
+------------+---------+ +---------+------------+
| +----------+-------+ | | +---------+--------+ |
| | Overlay Module | | | | Overlay Module | |
| +---------+--------+ | | +---------+--------+ |
| |VN context| | VN context| |
| | | | | |
| +--------+-------+ | | +--------+-------+ |
| | VNI | | | | VNI | |
NVE1 | +-+------------+-+ | | +-+-----------+--+ | NVE2
| | VAPs | | | | VAPs | |
+----+------------+----+ +----+------------+----+
| | | |
-------+------------+-----------------+------------+-------
| | Tenant | |
| | Service IF | |
Tenant End Systems Tenant End Systems
]]></artwork>
</figure></t>
<section anchor="vap" title="Virtual Attachment Points (VAPs)">
<t>In a LISP NVE, Tunnel Routers (xTRs) implement the NVE
functionality on ToRs or Virtual Switches. Tenant End Systems attach
to the Virtual Access Points (VAPs) provided by the xTRs (either a
physical port or a virtual interface).</t>
</section>
<section anchor="overlay-modules"
title="Overlay Modules and Tenant ID">
<t>The xTR also implements the function of NVE Overlay Module, by
mapping the addressing information (EIDs) of the tenant packet on
the appropriate locations (RLOCs) in the underlay network. The
Tenant Network Identifier (TNI) is encoded in the encapsulated
packet (either in the 24-bit IID field of the LISP header for L2/L3
LISP encapsulation, or in the 24-bit VXLAN Network Identifier field
for VXLAN encapsulation, or in the 24-bit NVGRE Tenant Network
Identifier field of NVGRE). In a LISP NVE globally unique (per
administrative domain) TNIs are used to identify the Tenant
instances.</t>
<t>The mapping of the tenant packet address onto the underlay
network location is “pulled” on-demand from the mapping
system, and cached at the NVE in a per-TNI map-cache.</t>
</section>
<section anchor="tenant-instance" title="Tenant Instance">
<t>Tenants are mapped on LISP Instance IDs (IIDs), and the xTR keeps
an instance of the LISP control protocol per each IID. The ETR is
responsible to register the Tenant End System to the LISP mapping
system, via the Map-Register service provided by LISP Map-Servers
(MS). The Map-Register includes the IID that is used to identify the
tenant.</t>
</section>
<section anchor="tunnel-overlays"
title="Tunnel Overlays and Encapsulation Options">
<t>The LISP control protocol, as defined today, provides support for
L2 LISP and VXLAN L2 over L3 encapsulation, and LISP L3 over L3
encapsulation.</t>
<t>We believe that the LISP control Protocol can be easily extended
to support different IP tunneling options (such as NVGRE).</t>
</section>
<section anchor="control-plane" title="Control Plane Components">
<t></t>
<section anchor="auto-provisiioning"
title="Auto-provisioning/Service Discovery">
<t>The LISP framework does not include mechanisms to provision the
local NVE with the appropriate Tenant Instance for each Tenant End
Systems. Other protocols, such as VDP (in IEEE P802.1Qbg), should
be used to implement a network attach/detach function.</t>
<t>The LISP control plane can take advantage of such a network
attach/detach function to trigger the registration of a Tenant End
System to the Mapping System. This is particularly helpful to
handle mobility across DC of the Tenant End System.</t>
<t>It is possible to extend the LISP control protocol to advertise
the tenant service instance (tenant and service type provided) to
other NVEs, and facilitate interoperability between NVEs that are
using different service types.</t>
</section>
<section anchor="advertisement"
title="Address Advertisement and Tunnel mapping">
<t>As traffic reaches an ingress NVE, the corresponding ITR uses
the LISP Map-Request/Reply service to determine the location of
the destination End System.</t>
<t>The LISP mapping system combines the distribution of address
advertisement and (stateless) tunneling provisioning.</t>
<t>When EIDs are mapped on both IP addresses and MACs, the need to
flood ARP messages at the NVE is eliminated resolving the issues
with explosive ARP handling.</t>
</section>
<section anchor="tunnel-management" title="Tunnel Management">
<t>LISP defines several mechanisms for determining RLOC
reachability, including Locator Status Bits, "nonce echoing", and
RLOC probing. Please see Sections 5.3 and 6.3 of <xref
target="I-D.ietf-lisp"></xref>.</t>
</section>
</section>
</section>
</section>
<section anchor="key-aspects" title="Key Aspects of Overlay">
<section title="Overlay Issues to Consider">
<t></t>
<section title="Data Plane vs. Control Plane Driven">
<t>The use of LISP control plane minimizes the need for multicast in
the underlay network overcoming the scalability limitations of VXLAN
dynamic data plane learning (Flood-and-Learn).</t>
<t>Multicast or ingress replication in the underlay network are
still required, as specified in <xref
target="I-D.ietf-lisp-multicast"></xref>, <xref
target="I-D.farinacci-lisp-mr-signaling"></xref>, and <xref
target="I-D.farinacci-lisp-te"></xref>, to support broadcast,
unknown, and multicast traffic in the overlay, but multicast in the
underlay is no longer required (at least for IP traffic) for unicast
overlay services.</t>
</section>
<section anchor="separation"
title="Data Plane and Control Plane Separation">
<t>LISP introduces a clear separation between data plane and control
plane functions. LISP modular design allows for different mapping
databases, to achieve different scalability goals and to meet
requirements of different deployments.</t>
</section>
<section anchor="multicast"
title="Handling Broadcast, Unknown Unicast and Multicast (BUM) Traffic">
<t>Packet replication in the underlay network to support broadcast,
unknown unicast and multicast overlay services can be done by:</t>
<t><list style="symbols">
<t>Ingress replication</t>
<t>Use of underlay multicast trees</t>
</list><xref target="I-D.ietf-lisp-multicast"></xref> specifies
how to map a multicast flow in the EID space during distribution
tree setup and packet delivery in the underlay network.
LISP-multicast doesn’t require packet format changes in
multicast routing protocols, and doesn’t impose changes in the
internal operation of multicast in a LISP site. The only operational
changes are required in PIM-ASM <xref target="RFC4601"></xref>, MSDP
<xref target="RFC3618"></xref>, and PIM-SSM <xref
target="RFC4607"></xref>.</t>
</section>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t><xref target="I-D.ietf-lisp-sec"></xref> defines a set of security
mechanisms that provide origin authentication, integrity and anti-replay
protection to LISP's EID-to-RLOC mapping data conveyed via mapping
lookup process. LISP-SEC also enables verification of authorization on
EID-prefix claims in Map-Reply messages.</t>
<t>Additional security mechanisms to protect the LISP Map-Register
messages are defined in <xref target="I-D.ietf-lisp-ms"></xref>.</t>
<t>The security of the Mapping System Infrastructure depends on the
particular mapping database used. The <xref
target="I-D.fuller-lisp-ddt"></xref> specification, as an example,
defines a public-key based mechanism that provides origin authentication
and integrity protection to the LISP DDT protocol.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no IANA implications</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors want to thank Victor Moreno and Paul Quinn for the early
review, insightful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4601"?>
<?rfc include="reference.RFC.3618"?>
<?rfc include="reference.RFC.4607"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-23.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-fuller-lisp-ddt-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-ms-14.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-lcaf-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-sec-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-smith-lisp-layer2-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-alt-10"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-multicast-14"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-farinacci-lisp-te-00"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-interworking-06"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-farinacci-lisp-mr-signaling-00"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lasserre-nvo3-framework-03.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nvo3-overlay-problem-statement-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kompella-nvo3-server2nve-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mahalingam-dutt-dcops-vxlan-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-sridharan-virtualization-nvgre-00.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:20:20 |