One document matched: draft-boucadair-lisp-ms-assisted-forwarding-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc rfcedstyle="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<rfc category="exp" docName="draft-boucadair-lisp-ms-assisted-forwarding-00"
ipr="trust200902">
<front>
<title abbrev="MS-Assisted Forwarding">Mapping System-Assisted Forwarding
for Inter-Domain LISP Deployments</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<date day="" month="" year="" />
<area>Internet</area>
<keyword>IPv4 service continuity</keyword>
<keyword>IPv4 address exhaustion</keyword>
<keyword>Service Availability</keyword>
<keyword>Address sharing</keyword>
<keyword>IPv6</keyword>
<keyword>Reliability</keyword>
<keyword>IPv4 over IPv6</keyword>
<abstract>
<t>One of the issues with current LISP operation is that some packets
are likely to be lost when there is no matching mapping entry maintained
by the Ingress Tunnel Router (ITR). This document proposes a solution to
address this issue with a particular focus on LISP deployments at large
scale.</t>
<t>This document introduces the concept of Implicit Map-Request and
Unsolicited Map-Reply messages. Also, it describes a solution to disable
data gleaning for a given flow at the upstream Egress Tunnel Router
(ETR).</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>Locator/ID Separation Protocol (LISP, <xref target="RFC6830"></xref>
) operation relies upon a mapping mechanism that is used by
ingress/egress Tunnel Routers (xTR) to forward traffic over the LISP
network. It is commonly acknowledged that some packets are likely to be
lost in some specific situations, such as the absence of a mapping entry
in the mapping cache maintained by an ITR. This phenomenon is usually
denoted as the "first packet loss" issue.</t>
<t>This document suggests a solution that relies upon the assistance of
the Mapping System for the forwarding of the first packet(s) of a flow,
while corresponding mapping resolution is in progress.</t>
<t>Deploying LISP at the scale of the Internet heavility relies upon the
reliability of the LISP Mapping service. In particular, LISP deployments
at large scale must not degrade the level of quality as currently
provided by several decades of inter-domain routing practices. <?rfc subcompact="yes" ?></t>
<t>This document makes the following assumptions:<list style="symbols">
<t>Various LISP players (network operators, service providers, etc.)
are likely to deploy and operate LISP Mapping Systems. Multiple
Mapping Systems will therefore coexist for various reasons, e.g.,
avoid country-centric governance, allow for distinct technologies to
implement the mapping service, business opportunities, service
innovation, etc.</t>
<t>Interconnection between these Mapping Systems is required for the
sake of global connectivity and also to minimize the risk of
fragmenting the Internet.</t>
<t>The entries of the mapping tables are exchanged between these
Mapping systems so that Map-Request messages can be processed as
close to the LISP leaf networks as possible.</t>
<t>A leaf LISP-enabled network subscribes to the Mapping Service
provided by one or several Mapping Service operators.</t>
<t>The contribution of each player involved in the provisioning and
the operation of a LISP-based connectivity forwarding service should
be rationalized so that clear interfaces are defined and adequate
mechanisms for troubleshooting, diagnosis and repair purposes can be
easily implemented and adopted. The inability of identifying what is
at the origin of the degradation of a LISP connectivity service is
seen as one of the hurdles that are likely to jeopardize LISP
deployments at large scale.</t>
<t>ITRs are configured with a list of one or more Map-Resolvers
locators. Whether the provisioning of MR-related information to ITRs
is achieved using a configuration interface or a specific discovery
mechanism is out of scope of this document.</t>
<t>Like <xref target="RFC6830"></xref>, this document does not make
any assumption of the Mapping Service other than it supports the
primitives defined in <xref target="RFC6833"></xref>.</t>
</list></t>
<t><?rfc subcompact="no" ?>This document focuses on the sole LISP
inter-domain use case. As such, it is out of scope of this document to
discuss the applicability of the proposed solution to other LISP use
cases (e.g., LISP-based data center networking) .</t>
<t>Within this document, "Unsolicited Map-Reply" is used to refer to a
Map-Reply that is not associated with an (explicit) Map-Request message.
An unsolicited Map-Reply is sent to an ITR without receiving a
Map-Request from that ITR.</t>
</section>
<section title="Proposed Solution">
<t>The rationale adopted by this document is that, instead of dropping
packets that do not match an existing mapping entry in a local cache
maintained by an ITR, these packets are used as Implicit Map-Requests.
In particular, the LISP-based forwarding of the first packet(s) can be
delegated to the Mapping System (MS) that is supposed to maintain the
required information to process the packet (preferably close to the LISP
leaf network or at least without inducing severe path stretch). This
mode is called MS-assisted LISP forwarding.</t>
<t>Although this feature can be supported by an upstream transit
provider, this document focuses on the deployment of the MS-assisted
LISP forwarding solution at the Mapping System side.</t>
<t>The detailed procedure that aims at minimizing the risk of the
aforementioned "first packet loss" issue is specified hereafter (see
<xref target="ex"></xref> for a typical flow example):<?rfc subcompact="yes" ?></t>
<t><list style="format %d">
<t>The Mapping System is configured with a list of networks that are
allowed to invoke the MS-assisted forwarding service. The
corresponding authorization procedure may rely upon the service
subscription procedure itself (using static or dynamic means such as
<xref
target="I-D.boucadair-connectivity-provisioning-protocol"></xref>).
<list style="symbols">
<t>Also, the Mapping System provides a leaf LISP network with
the appropriate RLOC (referred to as MS_RLOC) so that it can use
the MS-assisted forwarding feature.</t>
<t>MS_RLOC may be identical or distinct from the locator
assigned to one of the Map-Resolvers that can be solicited by
the leaf LISP network.</t>
</list></t>
<t>ITRs MUST support a configuration parameter to enable/disable
this procedure. The default value of this parameter is
"Disabled".</t>
<t>ITRs MAY be configured with a dedicated RLOC for this feature.
This RLOC MAY NOT be the same locator as the one used to contact a
Map-Resolver. If no dedicated RLOC is explicitly configured on an
ITR for which the MS-assisted forwarding procedure is enabled, the
ITR MUST use the locator of its Map-Resolver (i.e.,
MS_RLOC=ITR_Locator).</t>
<t>When an ITR receives a packet to be forwarded outside a given
LISP domain, it MUST proceed to a lookup of the local mapping cache
to check whether an entry matches this packet.<list
style="format 4.%d">
<t>If a mapping entry is found, the ITR MUST proceed as in <xref
target="RFC6830"></xref>.</t>
<t>If no mapping entry is found and the MS-assisted forwarding
feature is enabled, the ITR MUST use the MS_RLOC to forward the
packet. That is, the origin packet is forwarded using a LISP
encapsulation header; the destination IP address of the outer
header is set to MS_RLOC (instead of the remote ETR's RLOC
associated with the destination EID). <list
style="format 4.2.%d">
<t>The ITR MUST set the nonce-present and echo-nonce-request
bits.</t>
<t>Once forwarded, the ITR MUST listen, using port 4343, to
Unsolicited Map-Reply messages that will be received from
the Map-Resolver.</t>
<t>The ITR MUST follow the same behavior for packets that
belong to the same flow until a mapping is retrieved from
the Mapping System side. The packet will be used as an
"implicit Map-Request" from a downstream ITR.</t>
</list></t>
</list></t>
<t>Upon receipt of the encapsulated packet, the Mapping System:<list
style="format 5.%d">
<t>MUST extract the destination EID and proceed to the lookup in
its global mapping table to retrieve the corresponding entry. If
a mapping entry is found, it MUST rewrite the source RLOC to be
set to the destination RLOC of the encapsulated packet received
from the leaf LISP network and the destination RLOC to the RLOC
retrieved from the mapping table. Then, the packet is forwarded
to the next hop. <list style="format 5.1.%d">
<t>Using the initial source RLOC to forward the packet might
be tempting, but this behavior is discouraged as upstream
networks implementing ingress filtering may consider this
packet as a spoofing attack.</t>
<t>The Mapping System may decide to reset the nonce-present
and echo-nonce-request bits. The setting of these bits can
be part of the service agreement contracted between the leaf
LISP network and the Mapping Service provider.</t>
<t>Because upstream ETRs may use the outer LISP header if it
implemented information "gleaning", the LISP packet may
provide an explicit indication to the ETR to not rely upon
the outer header to create a "gleaned" Map-Cache entry but
rather proceed with an explicit Map-Request. instead <xref
target="glean"></xref> proposes a solution for carrying such
indication in the LISP header.</t>
</list></t>
<t>In the meantime, an unsolicited Map-Reply message that
carries records associated with the destination EID, MUST be
sent to the ITR so that it can handle the packets locally
without any assistance from the Mapping System. <list
style="format 5.2.%d">
<t>The Map-Reply message MUST use the same Nonce that was
included in the LISP-encapsulated packet received from the
downstream ITR.</t>
<t>A timer (or a maximum number of the packets) MAY be used
so that the assistance mode is deactivated at the Mapping
System side for this leaf LISP network/EID. Discarding
subsequent packets and associated settings are
deployment-specific. It is out of scope of this document to
elaborate on such design considerations.</t>
</list></t>
</list></t>
<t>Upon receipt of the Unsolicited Map-Reply message, the ITR MUST
proceed to Nonce validation checks. <list style="format 6.%d">
<t>If no error is found, it MUST retrieve the record carried in
the Map-Reply message.</t>
<t>The ITR MUST stop using the MS-assisted mode (i.e., for
forthcoming packets matching this mapping entry).</t>
</list></t>
<t>Subsequent packets that belong to the same flow are handled
locally (i.e., normal LISP operation is in progress).</t>
</list></t>
<t><?rfc subcompact="no" ?><figure anchor="ex" title="Flow Example">
<artwork align="center"><![CDATA[ +-------+
|Mapping|
+--------+ |System | +--------+
| ITR | +-------+ | ETR |
+--------+ | +--------+
| | |
src=s_EID| | |
-------->|src=RLOC_itr dst=RLOC_ms| |
dst=d_EID|===Encapsulated Packet===>|src=RLOC_ms dst=RLOC_etr|
| Unsolicited Map-Reply |===Encapsulated Packet===>|
|<-------------------------| |
| |
src=s_EID| |
-------->|src=RLOC_itr dst=RLOC_etr|src=s_EID
dst=d_EID|===================Encapsulated Packet==============>|-------->
| |dst=d_EID
....
src=s_EID| |
-------->|src=RLOC_itr dst=RLOC_etr|src=s_EID
dst=d_EID|===================Encapsulated Packet==============>|-------->
| |dst=d_EID
]]></artwork>
</figure></t>
</section>
<section anchor="glean" title="Disable Data Gleaning">
<t><xref target="RFC6830"></xref> indicates the following:</t>
<t><list style="empty">
<t>Section 4: "In order to defer the need for a mapping lookup in
the reverse direction, an ETR MAY create a cache entry that maps the
source EID (inner-header source IP address) to the source RLOC
(outer-header source IP address) in a received LISP packet. Such a
cache entry is termed a "gleaned" mapping and only contains a single
RLOC for the EID in question."</t>
<t>Section 6.2: "Either side (more likely the server-side ETR)
decides not to send a Map-Request. For example, if the server-side
ETR does not send Map-Requests, it gleans RLOCs from the client-side
ITR, giving the client-side ITR responsibility for bidirectional
RLOC reachability and preferability. Server-side ETR gleaning of the
client-side ITR RLOC is done by caching the inner-header source EID
and the outer-header source RLOC of received packets. The
client-side ITR controls how traffic is returned and can alternate
using an outer- header source RLOC, which then can be added to the
list the server-side ETR uses to return traffic. Since no Priority
or Weights are provided using this method, the server-side ETR MUST
assume that each client-side ITR RLOC uses the same best Priority
with a Weight of zero. In addition, since EID-Prefix encoding cannot
be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers
can grow to be very large."</t>
</list></t>
<t>But the LISP specification does not describe any means for an ITR to
explicitly inform an ETR that it MUST NOT rely upon the data gleaning
but, instead, privilege the sending of an explicit Map-request.</t>
<t>For the particular case covered in this document, the lack of such
capability may lead to the involvement of an intermediate node for both
traffic directions. This behavior may not be suitable in some deployment
situations (e.g., mis-use the relay in the MS domain to forward traffic,
abuse, denial-of-service, etc.). In order to solve this issue, this
document proposes to associate a meaning with one of the reserved flag
bits (see Section 5.3 of <xref target="RFC6830"></xref>) to explicitly
indicate that, when this bit is set, data gleaning must be deactivated.
This bit is called the G-bit ("Gleaning" flag bit).</t>
<t><xref target="gflag"></xref> shows the required change to the LISP
header.</t>
<t><figure anchor="gflag" title="G-bit in the LISP Header">
<artwork><![CDATA[OLD:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|G|flg| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>The "flg" bits are reserved bits for future assignment as additional
flag bits. These additional flag bits MUST each be set to zero and MUST
be ignored upon receipt.</t>
<t>The description of the remaining fields is the same as in <xref
target="RFC6830"></xref>.</t>
</section>
<section title="Security Considerations">
<t>Security considerations discussed in <xref target="RFC6833"></xref>
and <xref target="RFC6830"></xref> should be taken into account.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not make any request to IANA.</t>
</section>
<section title="Acknowledgments">
<t>This work is partly funded by ANR LISP-Lab project
#ANR-13-INFR-009-X.</t>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc include='reference.RFC.6833'
?>
<?rfc include='reference.RFC.2119'?>
</references>
<references title="Informative references">
<?rfc include='reference.RFC.6830'?>
<?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:27 |