Mapping System-Assisted Forwarding for Inter-Domain LISP Deployments
draft-boucadair-lisp-ms-assisted-forwarding-00

Abstract

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.

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).

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 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. Proposed Solution
• 3. Disable Data Gleaning
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgments
• 7. References
• 7.1. Normative references
• 7.2. Informative references
• Authors' Addresses

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. 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.

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.

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.

This document makes the following assumptions:

• 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.
• Interconnection between these Mapping Systems is required for the sake of global connectivity and also to minimize the risk of fragmenting the Internet.
• 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.
• A leaf LISP-enabled network subscribes to the Mapping Service provided by one or several Mapping Service operators.
• 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.
• 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.
• Like [RFC6830], this document does not make any assumption of the Mapping Service other than it supports the primitives defined in [RFC6833].

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.

2. Proposed Solution

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.

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.

The detailed procedure that aims at minimizing the risk of the aforementioned "first packet loss" issue is specified hereafter (see Figure 1 for a typical flow example):

1

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 [I-D.boucadair-connectivity-provisioning-protocol]).

• 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.
• 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.

2

ITRs MUST support a configuration parameter to enable/disable this procedure. The default value of this parameter is "Disabled".

3

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).

4

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.

4.1

If a mapping entry is found, the ITR MUST proceed as in [RFC6830].

4.2

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).

4.2.1

The ITR MUST set the nonce-present and echo-nonce-request bits.

4.2.2

Once forwarded, the ITR MUST listen, using port 4343, to Unsolicited Map-Reply messages that will be received from the Map-Resolver.

4.2.3

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.

5

Upon receipt of the encapsulated packet, the Mapping System:

5.1

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.

5.1.1

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.

5.1.2

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.

5.1.3

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 Section 3 proposes a solution for carrying such indication in the LISP header.

5.2

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.

5.2.1

The Map-Reply message MUST use the same Nonce that was included in the LISP-encapsulated packet received from the downstream ITR.

5.2.2

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.

6

Upon receipt of the Unsolicited Map-Reply message, the ITR MUST proceed to Nonce validation checks.

6.1

If no error is found, it MUST retrieve the record carried in the Map-Reply message.

6.2

The ITR MUST stop using the MS-assisted mode (i.e., for forthcoming packets matching this mapping entry).

7

Subsequent packets that belong to the same flow are handled locally (i.e., normal LISP operation is in progress).

                                +-------+
                                |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

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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+