Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Experimental France Telecom
Expires: March 20, 2016 September 17, 2015

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

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:

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

Figure 1: Flow Example

3. Disable Data Gleaning

[RFC6830] indicates the following:

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.

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 [RFC6830]) to explicitly indicate that, when this bit is set, data gleaning must be deactivated. This bit is called the G-bit ("Gleaning" flag bit).

Figure 2 shows the required change to the LISP header.

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

Figure 2: G-bit in the LISP Header

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.

The description of the remaining fields is the same as in [RFC6830].

4. Security Considerations

Security considerations discussed in [RFC6833] and [RFC6830] should be taken into account.

5. IANA Considerations

This document does not make any request to IANA.

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.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013.

7.2. Informative references

[I-D.boucadair-connectivity-provisioning-protocol] Boucadair, M., Jacquenet, C., Zhang, D. and P. Georgatsos, "Connectivity Provisioning Negotiation Protocol (CPNP)", Internet-Draft draft-boucadair-connectivity-provisioning-protocol-10, September 2015.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013.

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