Network Working Group M. Boucadair Internet-Draft C. Jacquenet Intended status: Experimental Orange Expires: January 26, 2017 July 25, 2016 Improving ITR Resiliency in Locator/ID Separation Protocol (LISP) Networks draft-boucadair-lisp-itr-failure-02 Abstract This document defines an extension to the Locator/ID Separation Protocol (LISP) to minimize LISP service disruption during Ingress Tunnel Routers (ITRs) 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 January 26, 2017. Copyright Notice Copyright (c) 2016 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 Boucadair & Jacquenet Expires January 26, 2017 [Page 1] Internet-Draft ITR Resiliency July 2016 carefully, as they describe your rights and restrictions with respect 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: Message Format & Behavior . . . . . . . 5 4. Map-Solicit-Reply: Message Format & Behavior . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative references . . . . . . . . . . . . . . . . . . 9 8.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. 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. 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. [I-D.boucadair-lisp-subscribe] is a Boucadair & Jacquenet Expires January 26, 2017 [Page 2] Internet-Draft ITR Resiliency July 2016 companion document that specifies a procedure that is meant to rapidly populate a local mapping cache upon restart or whenever failures affect ITR operation. 2. Procedure The overall procedure is as follows: 1. 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. 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, denoted Map-Solicit-Request (Section 3), to @MCAST. If a list is available, the ITR follows Steps (5, 6, and 7). Note that the same IP address (@MCAST) is used to announce the availability of an ITR within a LISP domain on a regular basis. 4. Once this message is received by another ITR reachable in the LISP domain, it replies with a Map-Solicit-Reply (Section 4) using its unicast address as the source IP address. The Map- Solicit-Reply 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 Boucadair & Jacquenet Expires January 26, 2017 [Page 3] Internet-Draft ITR Resiliency July 2016 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- Reply to the original ITR so that it can handle locally 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 (e.g., using the extension defined in Section 3 of [I-D.boucadair-lisp-ms-assisted-forwarding]). +--------+ +--------+ +--------+ +--------+ | 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 Figure 1: Flow Example Boucadair & Jacquenet Expires January 26, 2017 [Page 4] Internet-Draft ITR Resiliency July 2016 3. Map-Solicit-Request: Message Format & Behavior The format of the Map-Solict-Request message is shown in Figure 2. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Map-Solicit-Request Message Format The description of the fields is as follows: o Type is to be defined. o R: MUST be set to 0 for Map-Solicit-Request messages. 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. An ITR that lost its stae MUST set this flag to 0. o Nonce, Key ID, Authentication Data Length, and Authentication Data are similar to those of a LISP Map-Register message ([RFC6830]). Boucadair & Jacquenet Expires January 26, 2017 [Page 5] Internet-Draft ITR Resiliency July 2016 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). 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. 4. Map-Solicit-Reply: Message Format & Behavior 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-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. 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. The format of the Map-Solict-Reply message is shown in Figure 3. Boucadair & Jacquenet Expires January 26, 2017 [Page 6] Internet-Draft ITR Resiliency July 2016 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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Map-Solicit-Response Message Format The description of the fields is as follows: o Type is to be defined. The same type code as Section 3 is used for Map-Solicit-Reply. o R: MUST be set to 1. 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 January 26, 2017 [Page 7] Internet-Draft ITR Resiliency July 2016 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-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. o Key ID, Authentication Data Length, and Authentication Data are similar to those of a LISP Map-Register 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-Reply 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 January 26, 2017 [Page 8] Internet-Draft ITR Resiliency July 2016 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. 5. Security Considerations LISP security considerations are discussed in [RFC6830]. 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. 6. IANA Considerations To be completed. 7. Acknowledgments This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 009-X. Many thanks to Chi Dung Phung for the review. 8. References 8.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, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . Boucadair & Jacquenet Expires January 26, 2017 [Page 9] Internet-Draft ITR Resiliency July 2016 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . 8.2. Informative References [I-D.boucadair-lisp-bulk] Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk Retrieval", draft-boucadair-lisp-bulk-02 (work in progress), June 2016. [I-D.boucadair-lisp-ms-assisted-forwarding] Boucadair, M. and C. Jacquenet, "Mapping System-Assisted Forwarding for Inter-Domain LISP Deployments", draft- boucadair-lisp-ms-assisted-forwarding-00 (work in progress), September 2015. [I-D.boucadair-lisp-subscribe] Boucadair, M. and C. Jacquenet, "Improving Mapping Services in LISP Networks", draft-boucadair-lisp- subscribe-02 (work in progress), March 2016. Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France EMail: mohamed.boucadair@orange.com Christian Jacquenet Orange Rennes 35000 France EMail: christian.jacquenet@orange.com Boucadair & Jacquenet Expires January 26, 2017 [Page 10]