Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Experimental France Telecom
Expires: March 20, 2016 September 17, 2015
Improving ITR Resiliency in LISP Networks
draft-boucadair-lisp-itr-failure-00
Abstract
This document defines an extension to the Locator/ID Separation
Protocol (LISP) to minimize LISP service disruption during ITR
failure events.
Requirements Language
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 RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 20, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Boucadair & Jacquenet Expires March 20, 2016 [Page 1]
Internet-Draft ITR Resiliency September 2015
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Map-Solicit-Request & Map-Solicit-Response Message Formats . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative references . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies
upon a mapping mechanism that is used by Ingress/Egress Tunnel
Routers (xTR) to forward traffic over the LISP network.
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".
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.
This document proposes a solution to enhance the robustness of LISP
networks during such ITR failure events (even if they are marginal).
This document assumes that several (inter-domain) ITRs are available
within the LISP network. The proposed solution allows for an
automatic discovery of the available ITRs of a given LISP domain.
The proposed approach exclusively focuses on engineering tweaks that
can be implemented within a LISP-enabled network without soliciting
the help of the LISP Mapping System. A companion document will
specify a procedure that is meant to rapidly populate a local mapping
cache upon restart or whenever failures affect ITR operation.
Boucadair & Jacquenet Expires March 20, 2016 [Page 2]
Internet-Draft ITR Resiliency September 2015
2. Procedure
The overall procedure is as follows:
1. A well-known IPv4 and/or IPv6 multicast address is reserved for
ITR resiliency (called @MCAST in this document).
2. A list of unicast addresses of available ITRs in a given domain
is maintained by the requesting ITR (ITR-PEER-LIST).
3. 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 to @MCAST. This message is
denoted Map-Solicit-Request. Note that the same IP address is
also used to announce the availability of an ITR within a LISP
domain on a regular basis. If a list is available, the ITR
follows Steps (4, 6, and 7).
4. Once this message is received by another ITR reachable in the
LISP domain, it replies with a Map-Solicit-Response using its
unicast address as the source IP address. The Map-Solicit-
Response includes the following information:
* 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.
* 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.
* Synchronisation reachability information (address, port
number, protocol, etc.)
5. Bulk mapping requests (e.g., [I-D.boucadair-lisp-bulk]) are then
sent to peer ITRs to retrieve a copy of their map cache. One or
several ITRs can be solicited.
6. 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.
7. 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-
Boucadair & Jacquenet Expires March 20, 2016 [Page 3]
Internet-Draft ITR Resiliency September 2015
Reply to the original ITR so that it can locally handle
subsequent packets that belong to this flow. The nonce of the
unsolicited Map-Reply must echo the one included in the
encapsulated packet received from the first ITR. An indication
to disable data gleaning may be included by the relay ITR.
+--------+ +--------+ +--------+ +--------+
| ITR1 | | ITR2 | | ITR3 | | ETR |
+--------+ +--------+ +--------+ +--------+
| | | |
|Map-Solicit-Request | | |
| to @MCAST | | |
|--------> | | |
| Map-Solicit-Response| | |
|<--------------------------| | |
| Map-Solicit-Response| |
|<-------------------------------------| |
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
Figure 1: Flow Example
3. Map-Solicit-Request & Map-Solicit-Response Message Formats
The format of the Map-Solict-Request message is shown in Figure 2.
Boucadair & Jacquenet Expires March 20, 2016 [Page 4]
Internet-Draft ITR Resiliency September 2015
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 |S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Map-Solicit-Request Message Format
The description of the fields is as follows:
o Type is to be defined (see Section 5).
o 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.
o 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.
o Nonce, Key ID, Authentication Data Length, and Authentication Data
are similar to those of a LISP Map-Request message ([RFC6830]).
o 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 [RFC4291]
(::ffff:0:0/96).
Boucadair & Jacquenet Expires March 20, 2016 [Page 5]
Internet-Draft ITR Resiliency September 2015
o 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.
o 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.
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 Section 2. An ITR
that loses its cache MUST issue this message with a D-bit set to 0.
All ITRs of a LISP domain MUST subscribe to the multicast group
defined by the aforementioned @MCAST multicast address. Upon receipt
of the Map-Solicit-Request message by an ITR within the domain, it
replies (unicast) with a Map-Solicit-Response. 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-Response.
ITRs of a LISP domain MUST send Map-Solict-Response 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.
The format of the Map-Solict-Response message is shown in Figure 3.
Boucadair & Jacquenet Expires March 20, 2016 [Page 6]
Internet-Draft ITR Resiliency September 2015
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 |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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Map-Solicit-Response Message Format
The description of the fields is as follows:
o Type is to be defined (see Section 5).
o 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.
Boucadair & Jacquenet Expires March 20, 2016 [Page 7]
Internet-Draft ITR Resiliency September 2015
o 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.
o Nonce: The 'Nonce' field of multicast Map-Solict-Response 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.
o Key ID, Authentication Data Length, and Authentication Data are
similar to those of a LISP Map-Request message ([RFC6830]).
o 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 [RFC4291]
(::ffff:0:0/96).
o 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.
o 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.
o 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.
o 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).
A Map-Solicit-Response can be generated by an ITR to advertise its
availability to the other ITRs of the LISP domain, as per normal LISP
operation.
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.
Boucadair & Jacquenet Expires March 20, 2016 [Page 8]
Internet-Draft ITR Resiliency September 2015
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).
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.
4. Security Considerations
This document does not introduce any additional security issues other
than those discussed in [RFC6830].
5. IANA Considerations
To be completed.
6. Acknowledgments
This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-
009-X.
7. References
7.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>.
Boucadair & Jacquenet Expires March 20, 2016 [Page 9]
Internet-Draft ITR Resiliency September 2015
7.2. Informative References
[I-D.boucadair-lisp-bulk]
Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk
Retrieval", draft-boucadair-lisp-bulk-00 (work in
progress), September 2015.
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes 35000
France
EMail: christian.jacquenet@orange.com
Boucadair & Jacquenet Expires March 20, 2016 [Page 10]