One document matched: draft-ietf-lisp-introduction-09.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="info" docName="draft-ietf-lisp-introduction-09.txt"
ipr="trust200902">
<front>
<title abbrev="LISP Introduction">An Architectural Introduction to the Locator/ID Separation Protocol (LISP)</title>
<author fullname="Albert Cabellos" initials="A." surname="Cabellos">
<organization>UPC-BarcelonaTech</organization>
<address>
<postal>
<street>c/ Jordi Girona 1-3</street>
<city>Barcelona</city>
<code>08034</code>
<region>Catalonia</region>
<country>Spain</country>
</postal>
<email>acabello@ac.upc.edu</email>
</address>
</author>
<author fullname="Damien Saucez (Ed.)" initials="D." surname="Saucez (Ed.)">
<organization>INRIA</organization>
<address>
<postal>
<street>2004 route des Lucioles BP 93</street>
<city>Sophia Antipolis Cedex</city>
<code>06902</code>
<country>France</country>
</postal>
<email>damien.saucez@inria.fr</email>
</address>
</author>
<date day="12" month="November" year="2014"/>
<area>Routing Area</area>
<keyword>LISP</keyword>
<keyword>Architecture</keyword>
<abstract>
<t>This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory purposes,
more details can be found in RFC6830, the protocol specification.</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">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document introduces the Locator/ID Separation Protocol (LISP)
<xref target="RFC6830"/> architecture, its main operational mechanisms and its design
rationale. Fundamentally, LISP is built following a well-known
architectural idea: decoupling the IP address overloaded semantics.
Indeed and as pointed out by <xref target="Chiappa"/>, currently IP addresses both
identify the topological location of a network attachment point as
well as the node's identity. However, nodes and routing have
fundamentally different requirements, routing systems require that
addresses are aggregatable and have topological meaning, while nodes
require to be identified independently of their current location <xref target="RFC4984"/>.</t>
<t>LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
RLOCs (Routing LOCators), both are typically
syntactically identical to the current IPv4 and IPv6 addresses. EIDs
are used to uniquely identify nodes irrespective of their topological
location and are typically routed intra-domain. RLOCs are assigned
topologically to network attachment points and are typically routed
inter-domain. With LISP, the edge of the Internet (where the nodes
are connected) and the core (where inter-domain routing occurs) can be
logically separated and interconnected by LISP-capable routers.
LISP also introduces a database, called the
Mapping System, to store and retrieve mappings between identity and
location. LISP-capable routers exchange packets over the Internet
core by encapsulating them to the appropriate location.</t>
<t>In summary:</t>
<t><list style="symbols">
<t>RLOCs have meaning only in the underlay network</t>
<t>EIDs have meaning only in the overlay network (unless they are
leaked into the underlay network)</t>
<t>The LISP edge maps EIDs to RLOCs</t>
<t>Within the underlay network, RLOCs have both locator and
identifier semantics</t>
<t>An EID within a LISP site carries both identifier and locator
semantics to other nodes within that site</t>
<t>An EID within a LISP site carries identifier and limited locator
semantics to nodes at other LISP sites (i.e., enough locator
information to tell that the EID is external to the site)</t>
</list></t>
<t>The relationship described above is not unique to LISP but it is
common to other overlay technologies.</t>
<t>
The initial motivation in the LISP effort is to be find in the
routing scalability problem <xref target="RFC4984"/>, where, if LISP is completely
deployed, the Internet core is populated with RLOCs while Traffic
Engineering mechanisms are pushed to the Mapping System.
In such scenario RLOCs are quasi-static (i.e., low churn), hence making the routing system
scalable <xref target="Quoitin"/>, while EIDs can roam anywhere with no churn to the
underlying routing system. <xref target="RFC7215"/> discusses the impact of LISP on the global routing
system during the transition period. However, the separation between location and identity
that LISP offers makes it suitable for use in additional
scenarios such as Traffic Engineering (TE), multihoming, and
mobility among others.</t>
<t>This document describes the LISP architecture, its main operational
mechanisms as its design rationale. It is important to note that this
document does not specify or complement the LISP protocol. The
interested reader should refer to the main LISP specifications <xref
target="RFC6830"/> and the complementary documents <xref
target="RFC6831"/>, <xref target="RFC6832"/>, <xref
target="RFC6833"/>, <xref target="RFC6834"/>, <xref target="RFC6835"/>,
<xref target="RFC6836"/>, <xref target="RFC7052"/> for the protocol specifications along with the
LISP deployment guidelines <xref target="RFC7215"/>.</t>
</section>
<section title="Definition of Terms">
<t>This document describes the LISP architecture and does not define or
introduce any new term. The reader is referred to <xref
target="RFC6830"/>, <xref target="RFC6831"/>, <xref target="RFC6832"/>, <xref
target="RFC6833"/>, <xref target="RFC6834"/>, <xref target="RFC6835"/>,
<xref target="RFC6836"/>, <xref target="RFC7052"/>, <xref target="RFC7215"/> for the LISP definition of terms.</t>
</section>
<section title="LISP Architecture">
<t>This section presents the LISP architecture, it first details the
design principles of LISP and then it proceeds to describe its main aspects:
data-plane, control-plane, and inetrworking mechanisms.</t>
<section title="Design Principles">
<t>The LISP architecture is built on top of four basic design
principles:</t>
<t><list style="symbols">
<t>Locator/Identifier split: By decoupling the overloaded semantics of the
current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to
scale. Devices are assigned with relatively opaque identity meaningful addresses that
are independent of their topological location.</t>
<t>Overlay architecture: Overlays route packets over the current
Internet, allowing deployment of new protocols without changing the
current infrastructure hence, resulting into a low deployment
cost.</t>
<t>Decoupled data and control-plane: Separating the data-plane
from the control-plane allows them to scale independently and use
different architectural approaches. This is important given that
they typically have different requirements and allows for other data-planes to be added. While decoupled, data and control-plane
are not completely isolated because the LISP data-plane may
trigger control-plane activity.</t>
<t>Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters.</t>
</list></t>
</section>
<section title="Overview of the Architecture">
<t>LISP splits architecturally the core from the edge of the Internet
by creating two separate namespaces: Endpoint Identifiers (EIDs) and
Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Autonomous
System) that use EID addresses. EIDs are typically -but not limited to- IPv4 or IPv6
addresses that uniquely identify communication end-hosts and are assigned and
configured by the same mechanisms that exist at the time of this writing. EIDs do not contain inter-domain topological information and can be
thought as an analogy to Provider Independent (PI <xref target="RFC4116"/>) addresses. Because of this, EIDs are usually
only routable at the edge with a LISP site.</t>
<t>With LISP, LISP sites (edge) and the core of the Internet are
interconnected by means of LISP-capable routers (e.g., border routers)
using tunnels.
When packets originated from a LISP site are flowing towards the core network, they ingress into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When packets flow from the core network to a LISP site, they egress from an encapsulated tunnel to an Egress Tunnel Router (ETR).
An xTR is a router which can perform both ITR and ETR operations. In this context ITRs
encapsulate packets while ETRs decapsulate them, hence LISP operates
as an overlay on top of the current Internet core.</t>
<t><figure>
<artwork><![CDATA[
/-----------------\ ---
| Mapping | |
. System | | Control
-| |`, | Plane
,' \-----------------/ . |
/ \ ---
,.., - _,..--..,, `, ,.., |
/ ` ,' ,-` `', . / ` |
/ \ +-----+ ,' `, +--'--+ / \ |
| EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data
| Space |-| |---| Space |---| |-| Space | | Plane
\ / +-----+ . / +-----+ \ / |
`. .' `. ,' `. .' |
`'-` `., ,.' `'-` ---
``''--''``
LISP Site (Edge) Core LISP Site (Edge)
Figure 1.- A schema of the LISP Architecture
]]></artwork>
</figure></t>
<t>With LISP, the core uses RLOCs, an RLOC is typically -but not limited to- an IPv4 or IPv6
address assigned to an Internet-facing network interface of an ITR or
ETR. Typically RLOCs are numbered from topologically aggregatable
blocks assigned to a site at each point to which it attaches to the
global Internet. The topology is defined by the connectivity of
networks, in this context RLOCs can be thought of Provider Aggregatable
addresses <xref target="RFC4116"/>.</t>
<t>A typically distributed database, called the Mapping
System, stores mappings between EIDs and RLOCs. Such mappings relate
the identity of the devices attached to LISP sites (EIDs) to the set
of RLOCs configured at the LISP-capable routers servicing the site.
Furthermore, the mappings also include traffic engineering policies
and can be configured to achieve multihoming and load balancing. The
LISP Mapping System is conceptually similar to the DNS
where it is organized as a distributed multi-organization network database.
With LISP, ETRs register mappings while ITRs retrieve them.</t>
<t>Finally, the LISP architecture emphasizes a cost
effective incremental deployment. Given that LISP represents an
overlay to the current Internet architecture, endhosts as well as
intra and inter-domain routers remain unchanged, and the only required
changes to the existing infrastructure are to routers connecting the
EID with the RLOC space. Such LISP capable routers, in most cases, only require a software upgrade.
Additionally, LISP requires the deployment of
an independent Mapping System, such distributed database is a new
network entity.</t>
<t>The following describes a simplified packet flow sequence
between two nodes that are attached to LISP sites. Client HostA
wants to send a packet to server HostB.</t>
<t><figure>
<artwork><![CDATA[
/----------------\
| Mapping |
| System |
.| |-
` \----------------/ `.
,` \
/ `.
,' _,..-..,, ',
/ -` `-, \
.' ,' \ `,
` ' \ '
+-----+ | | RLOC_B1+-----+
HostA | | | RLOC |-------| | HostB
EID_A--|ITR_A|----| Space | |ETR_B|--EID_B
| | RLOC_A1 |-------| |
+-----+ | | RLOC_B2+-----+
, /
\ /
`', ,-`
``''-''``
Figure 2.- Packet flow sequence in LISP
]]></artwork>
</figure></t>
<t><list style="numbers">
<t>HostA retrieves the EID_B of HostB (typically querying the DNS)
and generates an IP packet as in the Internet, the packet
has source address EID_A and destination address EID_B.</t>
<t>The packet is routed towards ITR_A in the LISP site using
standard intra-domain mechanisms.</t>
<t>ITR_A upon receiving the packet queries the Mapping System to
retrieve the locator of ETR_B that is servicing HostB's EID_B. In order
to do so it uses a LISP control message called Map-Request, the
message contains EID_B as the lookup key. In turn it receives
another LISP control message called Map-Reply, the message
contains two locators: RLOC_B1 and RLOC_B2 along with traffic
engineering policies: priority and weight per locator.
ITR_A also stores the mapping in a local cache to speed-up
forwarding of subsequent packets.</t>
<t>ITR_A encapsulates the packet towards RLOC_B1 (chosen according
to the priorities/weights specified in the mapping). The packet contains two
IP headers, the outer header has RLOC_A1 as source and RLOC_B2 as
destination, the inner original header has EID_A as source and EID_B as
destination. Furthermore ITR_A adds a LISP header, more details
about LISP encapsulation can be found in <xref
target="encapsulation"/>.</t>
<t>The encapsulated packet is forwarded by the Internet core as a
normal IP packet, making the EID invisible from the Internet core.</t>
<t>Upon reception of the encapsulated packet by ETR_B, it
decapsulates the packet and forwards it to HostB.</t>
</list></t>
</section>
<section title="Data-Plane">
<t>This section provides a high-level description of the LISP data-plane,
which is specified in detail in <xref target="RFC6830"/>. The LISP data-plane is responsible for
encapsulating and decapsulating data packets and caching the
appropriate forwarding state. It includes two main entities, the ITR
and the ETR, both are LISP capable routers that connect the EID with
the RLOC space (ITR) and vice versa (ETR). </t>
<section anchor="encapsulation" title="LISP Encapsulation">
<t>ITRs encapsulate data packets towards ETRs. LISP data packets are
encapsulated using UDP (port 4341). A particularity of LISP is that UDP packets should
include a zero checksum <xref target="RFC6935"/> <xref
target="RFC6936"/> that it is not verified in reception, LISP also
supports non-zero checksums that may be verified. This decision was
made because the typical transport protocols used by the
applications already include a checksum, by neglecting the
additional UDP encapsulation checksum xTRs can forward packets
more efficiently.</t>
<t>LISP-encapsulated packets also include a LISP header (after the
UDP header and before the original IP header). The LISP header is prepended by ITRs and striped by
ETRs. It carries reachability information (see more details in <xref target="reachability"/>) and the Instance ID
field.
The Instance ID field is used to distinguish traffic to/from
different tenant address spaces at the LISP site and that may use
overlapped but logically separated EID addressing.</t>
<t>Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends ("outer" to "inner"):</t>
<t><list style="numbers">
<t>Outer IP header containing RLOCs as source and destination
addresses. This header is originated by ITRs and stripped by
ETRs.</t>
<t>UDP header (port 4341) with zero checksum. This header is
originated by ITRs and stripped by ETRs.</t>
<t>LISP header that contains various forwarding-plane features (such as reachability) and an
Instance ID field. This header is originated by ITRs and
stripped by ETRs.</t>
<t>Inner IP header containing EIDs as source and destination
addresses. This header is created by the source end-host and
is left unchanged by LISP data plane processing on the ITR and ETR.</t>
</list></t>
<t>Finally, in some scenarios Recursive and/or Re-encapsulating
tunnels can be used for Traffic Engineering and re-routing.
Re-encapsulating tunnels are consecutive LISP tunnels and occur when
a decapsulator (an ETR action) removes a LISP header and then acts as an encapsultor (an ITR action) to prepend
another one. On the other hand, Recursive tunnels are nested tunnels
and are implemented by using multiple LISP encapsulations on a packet.
Typically such functions are implemented by Reencapsulating Tunnel
Routers (RTRs).</t>
</section>
<section title="LISP Forwarding State">
<t>In the LISP architecture, ITRs keep just enough information to route
traffic flowing through it. Meaning that, ITRs retrieve from the LISP
Mapping System mappings between EID prefixes and RLOCs that are used
to encapsulate packets. Such mappings are stored in a local cache
called the Map-Cache for subsequent packets addressed to the same EID
prefix. Note that, in case of overlapping EID-prefixes, following a
single request, the ITR may receive a set of mappings, covering the
requested EID-prefix and all more-specifics (cf., Section 6.1.5
<xref target="RFC6830"/>). Mappings include a (Time-to-Live) TTL (set by the ETR).
More details about the Map-Cache management can be found in <xref target="management"/>.
</t>
</section>
</section>
<section title="Control-Plane">
<t>
The LISP control-plane, specified in <xref target="RFC6833"/>, provides a standard
interface to register and request mappings. The LISP
Mapping System is a database that stores such
mappings. The following first describes the mappings, then the
standard interface to the Mapping System, and finally its architecture.</t>
<section title="LISP Mappings">
<t>Each mapping includes the bindings between EID prefix(es) and
set of RLOCs as well as traffic engineering policies, in the form of
priorities and weights for the RLOCs. Priorities allow the ETR to
configure active/backup policies while weights are used to
load-balance traffic among the RLOCs (on a per-flow basis).</t>
<t>Typical mappings in LISP bind EIDs in the form of IP prefixes with
a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are
encoded using the appropriate Address Family Identifier (AFI)
<xref target="RFC3232"/>. However LISP can also support more general address encoding
by means of the ongoing effort around the LISP Canonical Address Format (LCAF)
<xref target="I-D.ietf-lisp-lcaf"/>.</t>
<t>With such a general syntax for address encoding in place, LISP
aims to provide flexibility to current and future applications. For
instance LCAFs could support
MAC addresses, geo-coordinates, ASCII names and application specific
data.</t>
</section>
<section title="Mapping System Interface">
<t>LISP defines a standard interface between data and control
planes. The interface is specified in <xref target="RFC6833"/> and
defines two entities:</t>
<t><list style="hanging">
<t hangText="Map-Server:">A network infrastructure component
that learns mappings from ETRs and publishes them into the LISP
Mapping System. Typically Map-Servers are not authoritative to
reply to queries and hence, they forward them to the ETR.
However they can also operate in proxy-mode, where the ETRs
delegate replying to queries to Map-Servers. This setup is
useful when the ETR has limited resources (i.e., CPU or power).</t>
<t hangText="Map-Resolver:">A network infrastructure component
that interfaces ITRs with the Mapping System by proxying queries
and in some cases responses. </t>
</list> The interface defines four LISP control messages which are
sent as UDP datagrams (port 4342):</t>
<t><list style="hanging">
<t hangText="Map-Register:">This message is used by ETRs to
register mappings in the Mapping System and it is authenticated
using a shared key between the ETR and the Map-Server.</t>
<t hangText="Map-Notify:">When requested by the ETR, this message is sent by the
Map-Server in response to a Map-Register to acknowledge the correct
reception of the mapping and convey the latest Map-Server state on the
EID to RLOC mapping. In some cases a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs.</t>
<t hangText="Map-Request:">This message is used by ITRs or
Map-Resolvers to resolve the mapping of a given EID.</t>
<t hangText="Map-Reply:">This message is sent by Map-Servers or ETRs in response to
a Map-Request and contains the resolved mapping. Please note that a
Map-Reply may contain a negative reply if, for example, the queried EID is not part
of the LISP EID space. In such cases the ITR typically forwards the
traffic natively (non encapsulated) to the public Internet, this
behavior is defined to support incremental deployment of LISP.</t>
</list></t>
</section>
<section title="Mapping System">
<t>LISP architecturally decouples control and data-plane by means of
a standard interface. This interface glues the data-plane, routers
responsible for forwarding data-packets, with the LISP Mapping
System, a database responsible for storing
mappings.</t>
<t>With this separation in place the data and control-plane can use
different architectures if needed and scale independently.
Typically the data-plane is optimized to route packets according to
hierarchical IP addresses. However the control-plane may have
different requirements, for instance and by taking advantage of the
LCAFs, the Mapping System may be used to store
non-hierarchical keys (such as MAC addresses),
requiring different architectural approaches for scalability.
Another important difference between the LISP control and
data-planes is that, and as a result of the local mapping cache
available at ITR, the Mapping System does not need to operate at
line-rate.</t>
<t>
The LISP WG has explored application of the following distributed system techniques to the Mapping System architecture:
graph-based databases in the form of LISP+ALT <xref
target="RFC6836"/>, hierarchical databases in the form of LISP-DDT
<xref target="I-D.ietf-lisp-ddt"/>, monolithic databases in the form
of LISP-NERD <xref target="RFC6837"/>, flat databases
in the form of LISP-DHT <xref target="I-D.cheng-lisp-shdht"/>,<xref
target="I-D.mathy-lisp-dht"/> and, a multicast-based database <xref target="I-D.curran-lisp-emacs"/>. Furthermore it is worth noting that, in some
scenarios such as private deployments, the Mapping System can operate as logically centralized.
In such cases it is typically composed of a single Map-Server/Map-Resolver.</t>
<t>The following focuses on the two mapping systems that have
been implemented and deployed (LISP-ALT and LISP+DDT).</t>
<section title="LISP+ALT">
<t>
The LISP Alternative Topology (LISP+ALT) <xref target="RFC6836"/> was the first
Mapping System proposed, developed and deployed on the LISP pilot
network. It is based on a distributed BGP overlay participated by
Map-Servers and Map-Resolvers. The nodes connect to their peers
through static tunnels. Each Map-Server involved in the ALT topology
advertises the EID-prefixes registered by the serviced ETRs, making
the EID routable on the ALT topology.
</t>
<t>When an ITR needs a mapping it sends a Map-Request to a Map-Resolver
that, using the ALT topology, forwards the Map-Request towards the
Map-Server responsible for the mapping. Upon reception the Map-Server
forwards the request to the ETR that in turn, replies directly to the
ITR using the native Internet core.</t>
</section>
<section title="LISP-DDT">
<t>
LISP-DDT <xref target="I-D.ietf-lisp-ddt"/> is conceptually similar to the DNS, a
hierarchical directory whose internal structure mirrors the
hierarchical nature of the EID address space. The DDT hierarchy is
composed of DDT nodes forming a tree structure, the leafs of the tree
are Map-Servers. On top of the structure there is the DDT root node
<xref target="DDT-ROOT"/>, which is a particular instance of a DDT node and that
matches the entire address space. As in the case of DNS, DDT supports
multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers
are the clients of the DDT hierarchy and can query either the DDT root
and/or other DDT nodes.
</t>
<t><figure>
<artwork><![CDATA[
/---------\
| |
| DDT Root|
| /0 |
,.\---------/-,
,-'` | `'.,
-'` | `-
/-------\ /-------\ /-------\
| DDT | | DDT | | DDT |
| Node | | Node | | Note | ...
| 0/8 | | 1/8 | | 2/8 |
\-------/ \-------/ \-------/
_. _. . -..,,,_
-` -` \ ````''--
+------------+ +------------+ +------------+ +------------+
| Map-Server | | Map-Server | | Map-Server | | Map-Server |
| EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4|
+------------+ +------------+ +------------+ +------------+
Figure 3.- A schematic representation of the DDT tree structure,
please note that the prefixes and the structure depicted
should be only considered as an example.
]]></artwork>
</figure></t>
<t>The DDT structure does not actually index EID-prefixes but
eXtended EID-prefixes (XEID). An XEID-prefix is just the
concatenation of the following fields (from most significant bit
to less significant bit): Database-ID, Instance ID, Address Family
Identifier and the actual EID-prefix. The Database-ID is provided
for possible future requirements of higher levels in the hierarchy
and to enable the creation of multiple and separate database
trees.</t>
<t>In order to resolve a query LISP-DDT operates in a similar way to the
DNS but only supports iterative lookups. DDT clients (usually Map-Resolvers)
generate Map-Requests to the DDT root node. In response they
receive a newly introduced LISP-control message: a Map-Referral. A
Map-Referral provides the list of RLOCs of the set of DDT nodes
matching a configured XEID delegation. That is, the information
contained in the Map-Referral points to the child of the queried
DDT node that has more specific information about the queried
XEID-prefix. This process is repeated until the DDT client walks
the tree structure (downwards) and discovers the Map-Server
servicing the queried XEID. At this point the client sends a
Map-Request and receives a Map-Reply containing the mappings. It
is important to note that DDT clients can also cache the
information contained in Map-Referrals, that is, they cache the
DDT structure. This is used to reduce the mapping retrieving
latency<xref target="Jakab"/>.</t>
<t>The DDT Mapping System relies on manual configuration. That is
Map- Resolvers are manually configured with the set of available
DDT root nodes while DDT nodes are manually configured with the
appropriate XEID delegations. Configuration changes in the DDT
nodes are only required when the tree structure changes itself,
but it doesn't depend on EID dynamics (RLOC allocation or traffic
engineering policy changes).</t>
</section>
</section>
</section>
<section title="Interworking Mechanisms">
<t>EIDs are typically identical to either IPv4 or IPv6 addresses and
they are stored in the LISP Mapping System, however they are usually not
announced in the Internet global routing system. As a result LISP
requires an inetrworking mechanism to allow LISP sites to speak
with non-LISP sites and vice versa. LISP inetrworking mechanisms are
specified in <xref target="RFC6832"/>.</t>
<t>LISP defines two entities to provide inetrworking:</t>
<t><list style="hanging">
<t hangText="Proxy Ingress Tunnel Router (PITR):">PITRs provide
connectivity from the legacy Internet to LISP sites. PITRs
announce in the global routing system blocks of EID prefixes
(aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID),
the PITR LISP-encapsulates it towards the RLOC(s) of
the appropriate LISP site. The impact of PITRs in the routing
table size of the DFZ is, in the worst-case, similar to the case
in which LISP is not deployed. EID-prefixes will be aggregated
as much as possible both by the PITR and by the global routing system.</t>
<t hangText="Proxy Egress Tunnel Router (PETR):">PETRs provide
connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulated
packets with a local EID address as a source to the legacy Internet. For instance when Unicast Reverse Path
Forwarding (uRPF) is used by Provider Edge routers, or when an
intermediate network between a LISP site and a non-LISP site does
not support the desired version of IP (IPv4 or IPv6). In both
cases the PETR overcomes such limitations by
encapsulating packets over the network.
There is no specified provision for the distribution of PETR RLOC addresses to the ITRs.</t>
</list></t>
</section>
</section>
<section title="LISP Operational Mechanisms">
<t>This section details the main operational mechanisms defined in
LISP.</t>
<section anchor="management" title="Cache Management">
<t>LISP's decoupled control and data-plane, where mappings are
stored in the control-plane and used for forwarding in the data
plane, requires of a local cache in ITRs to reduce signaling
overhead (Map-Request/Map-Reply) and increase forwarding speed. The
local cache available at the ITRs, called Map-Cache, is used by the
router to LISP-encapsulate packets. The Map-Cache is indexed by
(Instance ID, EID-prefix) and contains basically the set
of RLOCs with the associated traffic engineering policies (priorities and
weights).</t>
<t>The Map-Cache, as any other cache, requires cache coherence
mechanisms to maintain up-to-date information. LISP defines three
main mechanisms for cache coherence:</t>
<t><list style="hanging">
<t hangText="Time-To-Live (TTL):">Each mapping contains a TTL
set by the ETR, upon expiration of the TTL the ITR has to refresh
the mapping by sending a new Map-Request. Typical values for TTL
defined by LISP are 24 hours.</t>
<t hangText="Solicit-Map-Request (SMR):">SMR is an explicit
mechanism to update mapping information. In particular a special
type of Map-Request can be sent on demand by ETRs to request refreshing
a mapping. Upon reception of a SMR
message, the ITR must refresh the bindings by sending a
Map-Request to the Mapping System.</t>
<t hangText="Map-Versioning:">This optional mechanism piggybacks in the LISP header of data-packets the
version number of the mappings used by an xTR. This way, when an xTR receives
a LISP-encapsulated packet from a remote xTR, it can check whether its own
Map-Cache or the one of the remote xTR is outdated. If its Map-Cache is
outdated, it sends a Map-Request for the remote EID so to obtain the newest
mappings. On the contrary, if it detects that the remote xTR Map-Cache is
outdated, it sends a SMR to notify it that a new mapping is available.</t>
</list></t>
<t>Finally it is worth noting that in some cases an entry in the
map-cache can be proactively refreshed using the mechanisms described
in the section below.</t>
</section>
<section anchor="reachability" title="RLOC Reachability">
<t>The LISP architecture is an edge to edge pull architecture, where the network
state is stored in the control-plane while the data-plane pulls it on
demand. This has consequences concerning the
propagation of xTRs reachability/liveness information. On the contrary BGP is a push architecture, where the required
network state is pushed by means of BGP UPDATE messages to BGP
speakers. In push architectures, reachability information is also
pushed to the interested routers. However pull architectures require explicit mechanisms to propagate reachability information. LISP
defines a set of mechanisms to inform ITRs and PITRS about the
reachability of the cached RLOCs:</t>
<t>Locator Status Bits (LSB): LSB is a passive technique, the LSB field is carried by data-packets
in the LISP header and can be set by a ETRs to specify which RLOCs of the ETR site are
up/down. This information
can be used by the ITRs as a hint about the reachability to perform
additional checks. Also note that LSB does not provide path
reachability status, only hints on the status of RLOCs.</t>
<t>Echo-nonce: This is also a passive technique, that can only operate
effectively when data flows bi-directionally between two communicating xTRs.
Basically, an ITR piggybacks a random number (called nonce) in LISP
data packets, if the path and the probed locator are up, the ETR will
piggyback the same random number on the next data-packet, if this is
not the case the ITR can set the locator as unreachable. When traffic
flow is unidirectional or when the ETR receiving the traffic is not
the same as the ITR that transmits it back, additional mechanisms are
required.</t>
<t>RLOC-probing: This is an active probing algorithm where ITRs send
probes to specific locators, this effectively probes both the locator
and the path. In particular this is done by sending a Map-Request
(with certain flags activated) on the data-plane (RLOC space) and
waiting in return a Map-Reply, also sent on the data-plane. The active
nature of RLOC-probing provides an effective mechanism to determine
reachability and, in case of failure, switching to a different
locator. Furthermore the mechanism also provides useful RTT
estimates of the delay of the path that can be used by other network
algorithms.</t>
<t>Additionally, LISP also recommends inferring reachability of
locators by using information provided by the underlay, in
particular:</t>
<t>It is worth noting that RLOC probing and Echo-nonce can work together.
Specifically if a nonce is not echoed, an ITR could RLOC-probe to
determine if the path is up when it cannot tell the difference between a
failed bidirectional path or the return path is not used (a unidirectional path).</t>
<t>ICMP signaling: The LISP underlay -the current Internet- uses the
ICMP protocol to signal unreachability (among other things). LISP can
take advantage of this and the reception of a ICMP Network Unreachable
or ICMP Host Unreachable message can be seen as a hint that a locator
might be unreachable, this should lead to perform additional
checks.</t>
<t>Underlay routing: Both BGP and IBGP carry reachability information,
LISP-capable routers that have access to underlay routing information
can use it to determine if a given locator or path are reachable.</t>
</section>
<section title="ETR Synchronization">
<t>All the ETRs that are authoritative to a particular EID-prefix must
announce the same mapping to the requesters, this means that ETRs must be
aware of the status of the RLOCs of the remaining ETRs. This is known as
ETR synchronization.</t>
<t>At the time of this writing LISP does not specify a mechanism to achieve ETR
synchronization. Although many well-known techniques could be applied to solve this issue
it is still under research, as a result operators must
rely on coherent manual configuration</t>
</section>
<section title="MTU Handling">
<t>Since LISP encapsulates packets it requires dealing with packets that exceed the MTU of the path between the ITR
and the ETR. Specifically LISP defines two mechanisms:</t>
<t><list style="hanging">
<t hangText="Stateless:">With this mechanism the effective MTU is assumed from the
ITR's perspective. If a payload packet is too big for the effective MTU, and
can be fragmented, the payload packet is fragmented on the ITR, such that
reassembly is performed at the destination host.</t>
<t hangText="Stateful:">With this mechanism ITRs keep track of the MTU of the paths
towards the destination locators by parsing the ICMP Too Big packets
sent by intermediate routers. Additionally ITRs will send ICMP Too Big
messages to inform the sources about the effective MTU.</t>
</list></t>
<t>In both cases if the packet cannot be fragmented (IPv4 with DF=1 or IPv6) then the ITR drops
it and replies with a ICMP Too Big message to the source.</t>
</section>
</section>
<section title="Mobility">
<t>The separation between locators and identifiers in LISP was initially proposed
for traffic engineering purpose where LISP sites can change their attachment
points to the Internet (i.e., RLOCs) without impacting endpoints or the
Internet core. In this context, the border routers operate the xTR
functionality and endpoints are not aware of the existence of LISP. However,
this mode of operation does not allow seamless mobility of endpoints between
different LISP sites as the EID address might not be routable in a visited
site. Nevertheless, LISP can be used to enable seamless IP mobility when LISP
is directly implemented in the endpoint or when the endpoint roams to an attached xTR.
Each endpoint is then an xTR and the EID address is the one presented to the network stack used by applications
while the RLOC is the address gathered from the network when it is visited.</t>
<t>Whenever the device changes of RLOC, the xTR updates the RLOC of its
local mapping and registers it to its Map-Server. To avoid the need of a
home gateway, the ITR also indicates the RLOC change to all remote devices
that have ongoing communications with the device that moved. The
combination of both methods ensures the scalability of the system as
signaling is strictly limited the Map-Server and to hosts with which
communications are ongoing.</t>
</section>
<section title="Multicast">
<t>LISP also supports transporting IP multicast packets sent from the EID
space, the operational changes required to the multicast protocols are
documented in <xref target="RFC6831"/>.</t>
<t>In such scenarios, LISP may create multicast state both at the core
and at the sites (both source and receiver). When signaling is used
to create multicast state at the sites, LISP routers unicast encapsulate
PIM Join/Prune messages from receiver to source sites. At the core,
ETRs build a new PIM Join/Prune message addressed to the RLOC of the
ITR servicing the source. An simplified sequence is shown below</t>
<t><list style="numbers">
<t>An end-host willing to join a multicast channel sends an IGMP
report. Multicast PIM routers at the LISP site propagate PIM
Join/Prune messages (S-EID, G) towards the ETR.</t>
<t>The join message flows to the ETR, upon reception the ETR builds two join messages,
the first one unicast LISP-encapsulates the original join message towards the RLOC of the
ITR servicing the source. This message creates (S-EID, G) multicast state at the source site.
The second join message contains as destination address the RLOC of the ITR
servicing the source (S-RLOC, G) and creates multicast state at the core.</t>
<t>Multicast data packets originated by the source (S-EID, G) flow from the source
to the ITR. The ITR LISP-encapsulates the multicast packets, the outter header includes its own RLOC
as the source (S-RLOC) and the original multicast group address (G) as the destination. Please
note that multicast group address are logical and are not resolved by the mapping system. Then
the multicast packet is transmitted through the core towards the receiving ETRs that decapsulates
the packets and sends them using the receiver's site multicast state.</t>
</list></t>
<t>LISP can also support non-PIM mechanisms to maintain multicast state.</t>
</section>
<section title="Security Considerations">
<t>LISP uses a pull architecture to learn mappings. While in a push system,
the state necessary to forward packets is learned independently of the traffic
itself, with a pull architecture, the system becomes reactive and data-plane
events (e.g., the arrival of a packet for an unknown destination) may trigger
control-plane events. This on-demand learning of mappings provides many
advantages as discussed above but may also affect the way security is enforced.</t>
<t>Usually, the data-plane is implemented in the fast path of routers to
provide high performance forwarding capabilities while the control-plane
features are implemented in the slow path to offer high flexibility and a
performance gap of several order of magnitude can be observed between the slow
and the fast paths. As a consequence, the way data-plane events are notified
to the control-plane must be thought carefully so to not overload the slow path
and rate limiting should be used as specified in <xref target="RFC6830"/>.</t>
<t>Care must also be taken so to not overload the mapping system (i.e., the
control plane infrastructure) as the operations to be performed by the mapping
system may be more complex than those on the data-plane, for that reason
<xref target="RFC6830"/> recommends to rate limit the sending of messages to the
mapping system.</t>
<t>To improve resiliency and reduce the overall number of messages exchanged,
LISP offers the possibility to leak information, such as reachabilty
of locators, directly into data plane packets. In environments that are not
fully trusted, control informations gleaned from data-plane packets should be
verified before using them.</t>
<t>Mappings are the centrepiece of LISP and all precautions must be taken to
avoid them to be manipulated or misused by malicious entities. Using trustable
Map-Servers that strictly respect <xref target="RFC6833"/> and the lightweight
authentication mechanism proposed by LISP-Sec <xref target="I-D.ietf-lisp-sec"/> reduces the risk of attacks to the mapping integrity. In more critical environments, secure measures may be needed.</t>
<t>
As with any other tunneling mechanism, middleboxes on the path between an ITR (or PITR) and an ETR (or PETR) must implement mechanisms to strip the LISP encapsulation to correctly
inspect the content of LISP encapsulated packets. </t>
<t>
Like other map-and-encap mechanisms, LISP enables triangular routing (i.e., packets of a flow
cross different border routers depending on their direction). This means that
intermediate boxes may have incomplete view on the traffic they inspect or
manipulate. </t>
<t>More details about security implications of LISP are discussed in
<xref target="I-D.ietf-lisp-threats" />.
</t>
</section>
<section title="Use Cases">
<section title="Traffic Engineering">
<t> BGP is the standard protocol to implement inter-domain routing. With
BGP, routing informations are propagated along the network and each
autonomous system can implement its own routing policy that will influence
the way routing information are propagated. The direct consequence is that
an autonomous system cannot precisely control the way the traffic will
enter the network.</t>
<t> As opposed to BGP, a LISP site can strictly impose via which ETRs the
traffic must enter the the LISP site network even though the path followed to reach the
ETR is not under the control of the LISP site. This fine control is
implemented with the mappings. When a remote site is willing to send
traffic to a LISP site, it retrieves the mapping associated to the
destination EID via the mapping system. The mapping is sent directly by an
authoritative ETR of the EID and is not altered by any intermediate network. </t>
<t>A mapping associates a list of RLOCs to an EID prefix. Each RLOC
corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward
packets to EIDs in the prefix. Each RLOC is tagged with a priority and a
weight in the mapping. The priority is used to indicates which RLOCs
should be preferred to send packets (the least preferred ones being
provided for backup purpose). The weight permits to balance the load
between the RLOCs with the same priority, proportionally to the weight
value.</t>
<t>As mappings are directly issued by the authoritative ETR of the EID and are not altered
while transmitted to the remote site, it offers highly flexible incoming
inter-domain traffic engineering with even the possibility for a site to
issue a different mapping for each remote site, implementing so precise
routing policies.</t>
</section>
<section title="LISP for IPv6 Co-existence">
<t>LISP encapsulations allows to transport packets using EIDs from a given
address family (e.g., IPv6) with packets from other address families (e.g., IPv4). The absence of correlation between
the address family of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6 to be deployed when all of the core
network may not have IPv6 enabled.</t>
<t>For example, two IPv6-only data centers could be interconnected via the
legacy IPv4 Internet. If their border routers are LISP capable, sending
packets between the data center is done without any form of translation as
the native IPv6 packets (in the EID space) will be LISP encapsulated and
transmitted over the IPv4 legacy Internet by the mean of IPv4 RLOCs.</t>
</section>
<section title="LISP for Virtual Private Networks">
<t>It is common to operate several virtual networks over the same
physical infrastructure. In such virtual private networks, it is essential to distinguish which virtual
network a packet belongs and tags or labels are used for that purpose.
When using LISP, the distinction can be made with the Instance ID field. When an
ITR encapsulates a packet from a particular virtual network (e.g., known
via the VRF or VLAN), it tags the encapsulated packet with the Instance ID
corresponding to the virtual network of the packet. When an ETR receives a
packet tagged with an Instance ID it uses the Instance ID to determine how
to treat the packet. </t>
<t>The main usage of LISP for virtual private networks does not introduce
additional requirements on the underlying network, as long as it is running IP.</t>
</section>
<section title="LISP for Virtual Machine Mobility in Data Centers">
<t>A way to enable seamless virtual machine mobility in data center is to
conceive the datacenter backbone as the RLOC space and the subnet
where servers are hosted as forming the EID space. A LISP router is placed
at the border between the backbone and each subnet. When a virtual
machine is moved to another subnet, it can keep (temporarily) the address it had before the move so to continue without a transport layer connection reset. When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System.</t>
<t>To inform the other LISP routers that the machine moved and where, and then
to avoid detours via the initial subnetwork, mechanisms such as the
Solicit-Map-Request messages are used.</t>
</section>
</section>
<section title="Security Considerations">
<t>This document does not specify any protocol or operational practices and hence, does not have
any security considerations.</t>
</section>
<section title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document was initiated by Noel Chiappa and much of the core
philosophy came from him. The authors acknowledge the important contributions
he has made to this work and thank him for his past efforts.</t>
<t>The authors would also like to thank Dino Farinacci, Fabio Maino,
Luigi Iannone, Sharon Barakai, Isidoros Kouvelas, Christian Cassar,
Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica,
Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, as well as every people acknowledged in <xref target="RFC6830" />.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3232"?>
<?rfc include="reference.RFC.4116"?>
<?rfc include="reference.RFC.4984"?>
<?rfc include="reference.RFC.6830"?>
<?rfc include="reference.RFC.6831"?>
<?rfc include="reference.RFC.6832"?>
<?rfc include="reference.RFC.6833"?>
<?rfc include="reference.RFC.6834"?>
<?rfc include="reference.RFC.6835"?>
<?rfc include="reference.RFC.6836"?>
<?rfc include="reference.RFC.6837"?>
<?rfc include="reference.RFC.7215"?>
<?rfc include="reference.RFC.6935"?>
<?rfc include="reference.RFC.6936"?>
<?rfc include="reference.RFC.7052"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-lisp-ddt"?>
<?rfc include="reference.I-D.ietf-lisp-lcaf"?>
<?rfc include="reference.I-D.ietf-lisp-threats"?>
<?rfc include="reference.I-D.ietf-lisp-sec"?>
<reference anchor="Jakab" target="">
<front>
<title>LISP-TREE: A DNS Hierarchy to Support the LISP Mapping
System, IEEE Journal on Selected Areas in Communications, vol. 28,
no. 8, pp. 1332-1343</title>
<author initials="L." surname="Jakab"/>
<author initials="A." surname="Cabellos"/>
<author initials="D." surname="Saucez"/>
<author initials="O." surname="Bonaventure"/>
<date month="October" year="2010"/>
</front>
</reference>
<reference anchor="I-D.mathy-lisp-dht" target="">
<front>
<title>"LISP-DHT: Towards a DHT to map identifiers onto locators"
draft-mathy-lisp-dht-00 (work in progress)</title>
<author initials="L." surname="Mathy"/>
<author initials="L." surname="Iannone"/>
<author initials="O." surname="Bonaventure"/>
<date month="April" year="2008"/>
</front>
</reference>
<reference anchor="I-D.cheng-lisp-shdht">
<front>
<title>LISP Single-Hop DHT Mapping Overlay</title>
<author fullname="Li Cheng" initials="L" surname="Cheng">
<organization/>
</author>
<author fullname="Jun Wang" initials="J" surname="Wang">
<organization/>
</author>
<date day="15" month="July" year="2013"/>
<abstract>
<t>This draft specifies the LISP Single-Hop Distributed Hash Table
Mapping Database (LISP-SHDHT), a distributed mapping database
which consists of a set of SHDHT Nodes to provide mappings from
LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). EID
namespace is dynamically distributed among SHDHT Nodes based on
DHT Hash algorithm. Each SHDHT Node is configured with one or more
hash spaces which contain multiple EID-prefixes along with RLOCs
of corresponding Map Servers.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-cheng-lisp-shdht-04"/>
<format target="http://www.ietf.org/internet-drafts/draft-cheng-lisp-shdht-04.txt"
type="TXT"/>
</reference>
<reference anchor="I-D.curran-lisp-emacs">
<front>
<title>EID Mappings Multicast Across Cooperating Systems for LISP</title>
<author fullname="S. Brim" initials="S" surname="Brim">
<organization/>
</author>
<author fullname="Dino Farinacci" initials="D" surname="Farinacci">
<organization/>
</author>
<author fullname="Dave Meyer" initials="D" surname="Meyer">
<organization/>
</author>
<author fullname="J Curran" initials="J" surname="Curran">
<organization/>
</author>
<date day="9" month="November" year="2007"/>
<abstract>
<t> One of the potential problems with the "map-and-encapsulate"
approaches to routing architecture is that there is a significant
chance of packets being dropped while a mapping is being retrieved.
Some approaches pre-load ingress tunnel routers with at least part of
the mapping database. Some approaches try to solve this by providing intermediate "default" routers which have a great deal more knowledge
than a typical ingress tunnel router. This document proposes a
scheme which does not drop packets yet does not require a great deal
of knowledge in any router. However, there are still some issues
that need to be worked out.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-curran-lisp-emacs-00"/>
<format target="http://tools.ietf.org/html/draft-curran-lisp-emacs-00"
type="TXT"/>
</reference>
<reference anchor="DFZ" target="">
<front>
<title>Growth of the BGP Table - 1994 to Present
http://bgp.potaroo.net/</title>
<author initials="Geoff" surname="Huston"/>
<date month="August" year="2013"/>
</front>
</reference>
<reference anchor="DDT-ROOT" target="">
<front>
<title>http://ddt-root.org/</title>
<author surname="LISP DDT ROOT"/>
<date month="August" year="2013"/>
</front>
</reference>
<reference anchor="Chiappa" target="">
<front>
<title>Endpoints and Endpoint names: A Propose Enhancement to the
Internet Architecture,
http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt</title>
<author initials="J." surname="Chiappa"/>
<date year="1999"/>
</front>
</reference>
<reference anchor="Quoitin" target="">
<front>
<title>"Evaluating the Benefits of the Locator/Identifier Separation" in Proceedings of 2Nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture</title>
<author initials="B." surname="Quoitin"/>
<author initials="L." surname="Iannone"/>
<author initials="C." surname="Launois"/>
<author initials="O." surname="Bonaventure"/>
<date year="2007"/>
</front>
</reference>
</references>
<section title="A Brief History of Location/Identity Separation">
<t>The LISP system for separation of location and identity resulted from
the discussions of this topic at the Amsterdam IAB Routing and
Addressing Workshop, which took place in October 2006 <xref target="RFC4984"/>.</t>
<t>A small group of like-minded personnel from various scattered
locations within Cisco, spontaneously formed immediately after that
workshop, to work on an idea that came out of informal discussions at
the workshop and on various mailing lists. The first
Internet-Draft on LISP appeared in January, 2007.</t>
<t>Trial implementations started at that time, with initial trial
deployments underway since June 2007; the results of early experience
have been fed back into the design in a continuous, ongoing process
over several years. LISP at this point represents a moderately
mature system, having undergone a long organic series of changes and
updates.</t>
<t>LISP transitioned from an IRTF activity to an IETF WG in March 2009,
and after numerous revisions, the basic specifications moved to
becoming RFCs at the start of 2013 (although work to expand and
improve it, and find new uses for it, continues, and undoubtly will
for a long time to come).</t>
<section title="Old LISP Models">
<t>LISP, as initially conceived, had a number of potential operating
modes, named 'models'. Although they are note used anymore, one
occasionally sees mention of them, so they are briefly described
here.</t>
<t><list style="hanging">
<t hangText="LISP 1:">EIDs all appear in the normal routing and forwarding
tables of the network (i.e. they are 'routable');this property is
used to 'bootstrap' operation, by using this to load EID->RLOC
mappings. Packets were sent with the EID as the destination in
the outer wrapper; when an ETR saw such a packet, it would send a
Map-Reply to the source ITR, giving the full mapping.</t>
<t hangText="LISP 1.5:">Similar to LISP 1, but the routability of EIDs happens
on a separate network.</t>
<t hangText="LISP 2:">EIDs are not routable; EID->RLOC mappings are available
from the DNS.</t>
<t hangText="LISP 3:">EIDs are not routable; and have to be looked up in in a
new EID->RLOC mapping database (in the initial concept, a system
using Distributed Hash Tables). Two variants were possible: a
'push' system, in which all mappings were distributed to all ITRs,
and a 'pull' system in which ITRs load the mappings they need, as
needed.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:00:39 |