One document matched: draft-boucadair-lisp-itr-failure-02.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-itr-failure-02"
ipr="trust200902">
<front>
<title abbrev="ITR Resiliency">Improving ITR Resiliency in Locator/ID
Separation Protocol (LISP) Networks</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</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>Orange</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>This document defines an extension to the Locator/ID Separation
Protocol (LISP) to minimize LISP service disruption during Ingress
Tunnel Routers (ITRs) failure events.</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.</t>
<t>A reboot of an ITR may dramatically affect the LISP-based forwarding
service for hosts connected to the LISP network. Because of the purge of
the mapping cache maintained by the rebooting ITR, the absence of a
matching entry for packets to be forwarded over the LISP network will
simply cause the dropping of such packets, even though other ITRs of the
LISP domain may be "ready-to-serve".</t>
<t>An ITR that loses its local mapping table for some reason is very
likely to drop incoming packets whose forwarding decision relies upon
the entries of the local mapping table. This type of ITR failure may
rarely occur, but when it does, it is likely to provoke severe service
degradation.</t>
<t>This document proposes a solution to enhance the robustness of LISP
networks during such ITR failure events. This document assumes that
several ITRs are available within the LISP network. The solution allows
for an automatic discovery of the available ITRs of a given LISP
domain.</t>
<t>The approach exclusively focuses on engineering tweaks that can be
implemented within a LISP-enabled network without soliciting the help of
the LISP Mapping System. <xref
target="I-D.boucadair-lisp-subscribe"></xref> is a companion document
that specifies a procedure that is meant to rapidly populate a local
mapping cache upon restart or whenever failures affect ITR
operation.</t>
</section>
<section anchor="proc" title="Procedure">
<t>The overall procedure is as follows:</t>
<t><list style="numbers">
<t>A dedicated IPv4 and/or IPv6 multicast address is reserved for
ITR resiliency (called @MCAST in this document). An address can be
reserved by an administrator for this purpose.</t>
<t>A list of unicast addresses of available ITRs in a given domain
is maintained by the requesting ITR (ITR-PEER-LIST).</t>
<t>When an ITR loses its mapping table for some reason (power
failure, software issue, etc.), but can still forward packets, it
checks whether it maintains a list of peer ITRs. If the peer ITR
list is empty, it sends a message, denoted Map-Solicit-Request
(<xref target="req"></xref>), to @MCAST. If a list is available, the
ITR follows Steps (5, 6, and 7). <vspace blankLines="1" />Note that
the same IP address (@MCAST) is used to announce the availability of
an ITR within a LISP domain on a regular basis.</t>
<t>Once this message is received by another ITR reachable in the
LISP domain, it replies with a Map-Solicit-Reply (<xref
target="res"></xref>) using its unicast address as the source IP
address. The Map-Solicit-Reply includes the following
information:<list style="symbols">
<t>Database Status (including cache status). A status set to
'Null' indicates this ITR does not maintain any cache because,
e.g., it is a new ITR, it lost its mappings, etc.</t>
<t>The content of local ITR-PEER-LIST: This is to accelerate the
process of discovering other ITRs within a LISP domain without
waiting for responses from other ITRs.</t>
<t>Synchronisation reachability information (address, port
number, protocol, etc.)</t>
</list></t>
<t>Bulk mapping requests (e.g., <xref
target="I-D.boucadair-lisp-bulk"></xref>) are then sent to peer ITRs
to retrieve a copy of their map cache. One or several ITRs can be
solicited.</t>
<t>In the meantime, cache synchronisation is in progress, packets
that do not match a mapping entry are redirected to another ITR in
the domain that has its database 'ready-to-serve'. These packets are
encapsulated in a LISP header using the unicast address discovered
in the previous steps.</t>
<t>A peer ITR decapsulates the packet, encapsulates it according to
the matching mapping entry, and forwards the encapsulated packet
towards the next hop. Moreover, it sends an unsolicited Map-Reply to
the original ITR so that it can handle locally subsequent packets
that belong to this flow. <vspace blankLines="1" />The 'nonce' of
the unsolicited Map-Reply must echo the one included in the
encapsulated packet received from the first ITR. <vspace
blankLines="1" />An indication to disable data gleaning may be
included by the relay ITR (e.g., using the extension defined in
Section 3 of <xref
target="I-D.boucadair-lisp-ms-assisted-forwarding"></xref>).</t>
</list><figure anchor="ex" title="Flow Example">
<artwork align="center"><![CDATA[
+--------+ +--------+ +--------+ +--------+
| ITR1 | | ITR2 | | ITR3 | | ETR |
+--------+ +--------+ +--------+ +--------+
| | | |
|Map-Solicit-Request | | |
| to @MCAST | | |
|--------> | | |
| Map-Solicit-Reply| | |
|<--------------------------| | |
| Map-Solicit-Reply| |
|<-------------------------------------| |
src=s_EID| | |
-------->|src=RLOC_itr1 dst=RLOC_itr2| |
dst=d_EID|===Encapsulated Packet====>|src=RLOC_itr2 dst=RLOC_etr|src=s_EID
| Unsolicited Map-Reply |===Encapsulated Packet===>|-------->
|<--------------------------| |dst=d_EID
| |
src=s_EID| |
-------->|src=RLOC_itr1 dst=RLOC_etr|src=s_EID
dst=d_EID|===================Encapsulated Packet===============>|-------->
| |dst=d_EID
....
src=s_EID| |
-------->|src=RLOC_itr1 dst=RLOC_etr |src=s_EID
dst=d_EID|===================Encapsulated Packet===============>|-------->
| |dst=d_EID]]></artwork>
</figure></t>
</section>
<section anchor="req"
title="Map-Solicit-Request: Message Format & Behavior">
<t>The format of the Map-Solict-Request message is shown in <xref
target="ms"></xref>.</t>
<t><figure anchor="ms" title="Map-Solicit-Request Message Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tbd |R|S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>The description of the fields is as follows:<list
style="symbols">
<t>Type is to be defined.</t>
<t>R: MUST be set to 0 for Map-Solicit-Request messages.</t>
<t>S: when set, this flag indicates that the originating ITR
supports a mechanism for state synchronisation of the mapping cache
between ITRs. When this flag is set, the message MUST carry the port
number, protocol, and IP Address used for synchronisation purposes.
This specification allows to indicate a distinct IP address for
state synchronisation purposes.</t>
<t>D: This flag indicates the status of the mapping cache table. It
is RECOMMENDED to set this flag to 1 when the ITR is up and running
for at least one hour and has a non-empty mapping cache. An ITR that
lost its stae MUST set this flag to 0.</t>
<t>Nonce, Key ID, Authentication Data Length, and Authentication
Data are similar to those of a LISP Map-Register message (<xref
target="RFC6830"></xref>).</t>
<t>IP Address: If S-bit is set, this field indicates the IP address
used to receive state synchronisation messages. If S-bit is unset,
this field MUST be set to zero at the originating ITR and MUST be
ignored at receipt. The length of this field is 128 bits. IPv4
addresses are encoded as IPv4-mapped IPv6 addresses <xref
target="RFC4291"></xref> (::ffff:0:0/96).</t>
<t>Port Number: If the S-bit is set, this field indicates the port
number used to receive state synchronisation messages. If unset,
this field MUST be set to zero at the originating ITR and MUST be
ignored at receipt.</t>
<t>Protocol: If the S-bit is set, this field indicates the protocol
used to transport state synchronisation messages. If unset, this
field MUST be set to zero at the originating ITR and MUST be ignored
upon receipt.</t>
</list></t>
<t>An ITR that issues this message MUST use one of its unicast IP
addresses as the source address. The destination IP address MUST be set
to the @MCAST multicast address introduced in <xref
target="proc"></xref>. An ITR that loses its cache MUST issue this
message with a D-bit set to 0.</t>
</section>
<section anchor="res"
title="Map-Solicit-Reply: Message Format & Behavior">
<t>All ITRs of a LISP domain MUST subscribe to the multicast group
defined by the aforementioned @MCAST multicast address.</t>
<t>Upon receipt of the Map-Solicit-Request message by an ITR within the
domain, it replies (unicast) with a Map-Solicit-Reply. It is the
responsibility of the first ITR to initiate a state synchronisation with
that peer if the D-bit and S-bit are unset and if it supports the
synchronisation protocol indicated in the Map-Solicit-Reply.</t>
<t>ITRs of a LISP domain MUST send Map-Solict-Reply in a regular
interval (that is configured by an administrator) or upon major change
in the ITR stats (e.g., loss of the mapping cache, change of the IP
address). This message MUST use one of the ITR unicast IP addresses as
the source address while the destination IP address MUST be set to the
@MCAST.</t>
<t>The format of the Map-Solict-Reply message is shown in <xref
target="mr"></xref>.<figure anchor="mr"
title="Map-Solicit-Response Message Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tbd |R|S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Port Number |Protocol |ITR List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Peer ITR Unicast Address |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Peer ITR Unicast Address |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>The description of the fields is as follows:<list
style="symbols">
<t>Type is to be defined. The same type code as <xref
target="req"></xref> is used for Map-Solicit-Reply.</t>
<t>R: MUST be set to 1.</t>
<t>S: when set, this flag indicates that the originating ITR
supports a mechanism for state synchronisation of the mapping caches
between ITRs. When set, the message MUST carry the port number,
protocol, and IP Address used for synchronisation purposes. This
specification allows to indicate a distinct IP address for state
synchronisation purposes.</t>
<t>D: This flag indicates the status of the mapping cache table. It
is RECOMMENDED to set this flag when the ITR is up and running for
at least one hour and has a non-empty mapping cache.</t>
<t>Nonce: The 'Nonce' field of multicast Map-Solict-Reply MUST be
set to 0 while it MUST echo the one included in a Map-Solict-Request
when replying to a multicast Map-Solict-Request.</t>
<t>Key ID, Authentication Data Length, and Authentication Data are
similar to those of a LISP Map-Register message (<xref
target="RFC6830"></xref>).</t>
<t>IP Address: If the S-bit is set, this field indicates the IP
address used to receive state synchronisation messages. If unset,
this field MUST be set to zero at the originating ITR and MUST be
ignored upon receipt. The length of this field is 128 bits. IPv4
addresses are encoded as IPv4-mapped IPv6 addresses <xref
target="RFC4291"></xref> (::ffff:0:0/96).</t>
<t>Port Number: If the S-bit is set, this field indicates the port
number used to receive state synchronisation messages. If unset,
this field MUST be set to zero at the originating ITR and MUST be
ignored upon receipt.</t>
<t>Protocol: If the S-bit is set, this field indicates the protocol
used to transport state synchronisation messages. If unset, this
field MUST be set to zero at the originating ITR and MUST be ignored
upon receipt.</t>
<t>ITR List Count: This field indicates whether peer ITR addresses
are also included. When this field is set to 0, it indicates that no
peer other than the solicited Peer ITR are known to the originating
ITR.</t>
<t>Peer ITR Unicast Address: one or multiple IP addresses that
belong to other ITRs in the domain as known to the originating ITR.
The length of each "Peer ITR Unicast Address" is 128 bits. IPv4
addresses are encoded as IPv4-mapped IPv6 addresses
(::ffff:0:0/96).</t>
</list>A Map-Solicit-Reply can be generated by an ITR to advertise its
availability to the other ITRs of the LISP domain, as per normal LISP
operation.</t>
<t>When an ITR receives a LISP-encapsulated packet from an ITR that is
present in its list of peer ITRs, it may generate an unsolicited
Map-Reply that conveys the mapping entry that was used to process the
encapsulated packet.</t>
<t>Upon failure or reboot that lead to lose the contents of its mapping
cache, an ITR uses the list of peers ITRs it discovered by means of the
Map-Solicit-Request message sent to @MCAST to redirect packets that do
not match any entry of its local cache (which is likely to be
empty).</t>
<t>In order to minimize the risk of overloading some ITRs, a mechanism
to distribute the load among all the peer ITRs or part of them is deemed
useful. Of course, other traffic load distribution policies may be
enforced. The exact set of policies to be enforced are implementation-
and deployment-specific.</t>
</section>
<section title="Security Considerations">
<t>LISP security considerations are discussed in <xref
target="RFC6830"></xref>.</t>
<t>This document specifies a mechanism that enhances the serveiceabilty
of LISP networks by redirecting traffic that do not match a local
mapping entry to other ITRs of the domain. These ITRs are assumed to
belong to the same administrative domain. Means to ensure that only
trusted ITRs are maintained in a peer list MUST be enabled.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>To be completed.</t>
</section>
<section title="Acknowledgments">
<t>This work is partly funded by ANR LISP-Lab project
#ANR-13-INFR-009-X.</t>
<t>Many thanks to Chi Dung Phung for the review.</t>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc ?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4291'?>
<?rfc include='reference.RFC.6830'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.boucadair-lisp-bulk'?>
<?rfc include='reference.I-D.boucadair-lisp-subscribe'?>
<?rfc include='reference.I-D.boucadair-lisp-ms-assisted-forwarding'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:28 |