Internet DRAFT - draft-boucadair-lisp-ms-assisted-forwarding
draft-boucadair-lisp-ms-assisted-forwarding
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.
Boucadair & Jacquenet Expires March 20, 2016 [Page 1]
Internet-Draft MS-Assisted Forwarding September 2015
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
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
3. Disable Data Gleaning . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative references . . . . . . . . . . . . . . . . . . 8
7.2. Informative references . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
Boucadair & Jacquenet Expires March 20, 2016 [Page 2]
Internet-Draft MS-Assisted Forwarding September 2015
This document makes the following assumptions:
o 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.
o Interconnection between these Mapping Systems is required for the
sake of global connectivity and also to minimize the risk of
fragmenting the Internet.
o 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.
o A leaf LISP-enabled network subscribes to the Mapping Service
provided by one or several Mapping Service operators.
o 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.
o 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.
o Like [RFC6830], this document does not make any assumption of the
Mapping Service other than it supports the primitives defined in
[RFC6833].
This document focuses on the sole LISP inter-domain use case. As
such, it is out of scope of this document to discuss the
applicability of the proposed solution to other LISP use cases (e.g.,
LISP-based data center networking) .
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
Boucadair & Jacquenet Expires March 20, 2016 [Page 3]
Internet-Draft MS-Assisted Forwarding September 2015
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).
Boucadair & Jacquenet Expires March 20, 2016 [Page 4]
Internet-Draft MS-Assisted Forwarding September 2015
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
Boucadair & Jacquenet Expires March 20, 2016 [Page 5]
Internet-Draft MS-Assisted Forwarding September 2015
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:
Section 4: "In order to defer the need for a mapping lookup in the
reverse direction, an ETR MAY create a cache entry that maps the
source EID (inner-header source IP address) to the source RLOC
(outer-header source IP address) in a received LISP packet. Such
a cache entry is termed a "gleaned" mapping and only contains a
single RLOC for the EID in question."
Boucadair & Jacquenet Expires March 20, 2016 [Page 6]
Internet-Draft MS-Assisted Forwarding September 2015
Section 6.2: "Either side (more likely the server-side ETR)
decides not to send a Map-Request. For example, if the server-
side ETR does not send Map-Requests, it gleans RLOCs from the
client-side ITR, giving the client-side ITR responsibility for
bidirectional RLOC reachability and preferability. Server-side
ETR gleaning of the client-side ITR RLOC is done by caching the
inner-header source EID and the outer-header source RLOC of
received packets. The client-side ITR controls how traffic is
returned and can alternate using an outer- header source RLOC,
which then can be added to the list the server-side ETR uses to
return traffic. Since no Priority or Weights are provided using
this method, the server-side ETR MUST assume that each client-side
ITR RLOC uses the same best Priority with a Weight of zero. In
addition, since EID-Prefix encoding cannot be conveyed in data
packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be
very large."
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
Boucadair & Jacquenet Expires March 20, 2016 [Page 7]
Internet-Draft MS-Assisted Forwarding September 2015
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,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
7.2. Informative references
[I-D.boucadair-connectivity-provisioning-protocol]
Boucadair, M., Jacquenet, C., Zhang, D., and P.
Georgatsos, "Connectivity Provisioning Negotiation
Protocol (CPNP)", draft-boucadair-connectivity-
provisioning-protocol-10 (work in progress), 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,
<http://www.rfc-editor.org/info/rfc6830>.
Boucadair & Jacquenet Expires March 20, 2016 [Page 8]
Internet-Draft MS-Assisted Forwarding 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 9]
