Network Working Group | M. Boucadair |
Internet-Draft | C. Jacquenet |
Intended status: Experimental | France Telecom |
Expires: March 18, 2016 | September 15, 2015 |
Improving Mapping Services in LISP Networks
draft-boucadair-lisp-subscribe-00
Mapping Services in Locator/ID Separation Protocol (LISP) networks are key to proper LISP forwarding operation. When considering the deployment of LISP at large scale, these Mapping Services are even more crucial for the sake of the LISP forwarding efficiency. This document introduces two additional LISP messages that are meant to facilitate the dynamic discovery of Mapping Systems, improve Ingress Tunnel Routers (ITR) recovery times and optimize the solicitation of the LISP Mapping System as a function of the ITR location, in particular.
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].
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 18, 2016.
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.
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. The ability of dynamically discovering the Map-Resolver and Map-Server entities that provide such mapping services is meant to facilitate global LISP operation. In particular, the ability to inform Ingress Tunnel Routers (ITR) of a LISP network about the availability and the status of several Mapping Services is likely to improve the overall LISP forwarding serviceability.
This section lists a set of issues that need further investigation:
This document makes the following assumptions:
This document specifies a couple of additional LISP messages that are meant to improve the subscription to Mapping Services, let alone their serviceability. They are described in the following sections.
A simple method to redirect ITR-originated mapping requests towards another Map-Resolver when some conditions are met (e.g., overload of a Map-Resolver, enforcement of traffic engineering policies, etc.) is defined in Section 2 and Section 3. Section 8 specifies how advanced Map-Resolver forwarding policies are installed in ITRs.
The format of the Map-Subscribe message is shown in Figure 1.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |U|B|I| Reserved | Filter Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiry Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ : : Filter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ : : Filter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Map-Subscribe Message Format
The description of the fields is as follows:
The format of the Map-Subscribe-Ack 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |U|B|I|R| Reserved | Result | Filter Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiry Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ : : Filter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ : : Filter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Redirect Map-Resolver | | IP Address (128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Map-Subscribe-Ack Message Format
An ITR uses the U-bit to inform a Map-Resolver whether it is ready to handle unsolicited Map-Reply messages or not. The ITR MUST set the U-bit when it supports such capability.
An ITR uses the B-bit to inform a Map-Resolver whether it supports the mapping bulk transfer method or not. The ITR MUST set to the B-bit when it supports such method (e.g., [I-D.boucadair-lisp-bulk]).
An ITR that joins the LISP network is likely to delete all notifications that are bound to its RLOCs. It does so by including a Null filter prior to any filter that it wishes the Map-Resolver to record.
An ITR that loses its mapping cache for some reason SHOULD generate a Map-Subscribe message towards its Map-Resolver(s) with the I-bit set.
An ITR MAY generate several Map-Subscribe messages to make the Map-Resolver install the required filters. Nevertheless, an ITR MUST expect that the Map-Resolver may limit the number of filters that may be installed. Filters that are not accepted or not processed by the Map-Resolvers are not included in a Map-Subscribe-Ack message.
An ITR that wants to delete one or a set of filters MUST generate a Map-Subscribe message which carries those filters with an Expiry Timer set to 0.
A Map-Resolver that does not support the Map-Subscribe message MUST silently ignore any Map-Subscribe message it receives.
Map-Resolvers MUST support a configurable parameter to enable/disable the processing of Map-Subscribe messages. The default value is set to "enabled".
A Map-Resolver SHOULD support a configuration parameter to limit the number of filters per leaf LISP network, per ITR, etc.
If a Map-Resolver receives a Map-Subscribe message and is enabled to process it, a Map-Resolver MUST reply with a Map-Subscribe-Ack message to acknowledge the receipt of the corresponding Map-Subscribe message.
When building a Map-Subscribe-Ack message, the Map-Resolver MUST:
If the I-bit is set in the Map-Subscribe request and the Map-Resolver supports the unsolicited mapping retrieval capability, the Map-Resolver SHOULD generate unsolicited Map-Reply messages or dedicated bulk transfer messages that carry the EID-RLOC mapping entries that match the filters already present in the Mapping System for that ITR or that match those carried by the Map-Subscribe message.
If filters are included in the request, the Map-Resolver MUST extract those filters and update its mapping system subscription for that ITR accordingly. In particular, the Map-Resolver MUST delete all filters that are active for that ITR if a Null filter is included in the Map-Subscribe request or if the expiry timer is null.
If filters are not allowed for a given ITR, the 'Result' field MUST be set to FILTERS-PROHIBITED.
If all filters are successfully installed, the 'Result' field MUST be set to SUCCESS.
If the Map-Resolver fails to install some of the filters included in a request because the filter limits for that ITR are exceeded, it MUST NOT echo the corresponding filters in the Map-Subscribe-Ack message. The 'Result' field MUST be set to PARTIAL-FILTERS-INSTALLED-LIMIT.
If the Map-Resolver fails to install some of the filters included in a request because these filters were malformed, it MUST NOT echo the corresponding filters in the Map-Subscribe-Ack message; only successfully installed filters MUST be included. The 'Result' field MUST be set to PARTIAL-FILTERS-INSTALLED-BAD.
If, for some other reasons, the Map-Resolver fails to apply the filters included in a request, it MUST NOT echo the said filters in the Map-Subscribe-Ack message; only the successfully installed filters MUST be included. The 'Result' field MUST be set to PARTIAL-FILTERS-INSTALLED-LOCAL.
If a filter that is included in the request is more specific than a filter that is already present in the mapping system for the same ITR, the Map-Resolver MUST NOT add a new filter but MUST include the old filter in the response to the requesting ITR.
If a more specific filter exists in the mapping system for the same ITR, the Map-Resolver MUST replace the old filter (i.e., the one already stored in the system) with the new filter (i.e., the one included in the Map-Subscribe message).
A Map-Resolver that is overloaded or configured by means of a specific policy to redirect requests sent by a set of ITRs to other Map-Resolvers, the Map-Resolver MUST reply with a Map-Subscribe-Ack message with the R-bit set and 'Redirect Map-Resolver IP Address' field set to the redirect Map-Resolver'address. All other bit flags MUST be returned unset. Moreover, the Expiry Timer MUST be set to 0. No Filter MUST be included in the message.
If an event matches one of the filters that have been installed by an ITR, the Map-Resolvers MUST generate the corresponding unsolicited mapping update message (e.g., Map-Reply, mapping bulk method).
Upon expiry of the validity timer associated with a filter, the Map-Resolver MUST delete that filter from its mapping subscription system.
Upon receipt of a Map-Subscribe-Ack message, the ITR MUST check whether the message matches a Map-Subscribe message it sent to the same Map-Resolver. If no matching state is found, the message MUST be silently dropped. If a state is found, in addition to authentication checks, the ITR MUST proceed as follows:
In order to subscribe to multiple Map-Resolvers, an ITR sends Map-Subscribe messages to a list of Map-Resolvers. Each of these requests is handled as specified in Section 4.
Section 2 and Section 3 specifies a solution for a Map-Resolver to redirect an ITR to another Map-Resolver. This section focuses on the dynamic provisioning of advanced mapping resolution forwarding policy tables.
This section assumes that the entity managing a leaf LISP network has subscribed to a Mapping Service using a variety of means, including static or dynamic such as [I-D.boucadair-connectivity-provisioning-protocol]. For the sake of network automation, we assume that the outcome of such negotiation is translated into appropriate provisioning actions, which include in particular the identity of Map-Resolvers that will be solicited by the ITRs of the leaf LISP network.
The provisioning information may be as simple as a list of IP addresses or names, but it may also be enriched with traffic engineering rules, such as priority information, geolocation information of the a Map-Resolver, the set of destination EIDs that are serviced by a given Map-Resolver, etc. A leaf LISP network can be provisioned with a list of Map-Resolvers together with policies to instruct the ITR how to contact these Map-Resolvers. These policies are enclosed in a Mapping Policy Table. This table is similar to the one defined in [RFC6724].
Typically, the Mapping Policy Table may be structured as follows:
An ITR may use the selection algorithm defined in Section 6 of [RFC6724] to contact a Map-Resolver.
<<to be completed>>
This section includes a set of examples to illustrate the usage of the methods defined in Section 2.
The example shown in Figure 3, illustrates an example of an ITR (ITR1) that is redirected to another Map-Resolver (MR2).
+--------+ +--------+ +--------+ | ITR1 | | MR1 | | MR2 | +--------+ +--------+ +--------+ | | | |Map-Subscribe | | |-------------------------->| | | Map-Subscribe-Ack (R, MR2)| | |<--------------------------| | |Map-Subscribe | | |------------------------------------->| | Map-Subscribe-Ack| |<-------------------------------------| | | |Map-Request | |------------------------------------->| | Map-Reply| |<-------------------------------------|
Figure 3: Example of Map-Resolver Redirection
The example shown in Figure 4, illustrates an example of an ITR (ITR1) that restores its mapping tables upon reboot according to the filters already present in the mapping system. The example in Figure 4, indicates how an ITR retrieves the mappings that match the filters included in the Map-Subscribe request. The example in Figure 5, assumes that multiple records bound to distinct EIDs are included in the same Map-Reply message.
This procedure applies to ITRs which do not store the mapping table in a permanent memory storage facility.
Owing to this procedure, the ITR is ready-to-serve as soon as reboot is completed or right after a mapping cache clear event.
+--------+ +--------+ | ITR1 | | MR | +--------+ +--------+ | | | | |Map-Subscribe(d_EID, d_EID2,| |..., d_EIDn) | |--------------------------->| | Map-Subscribe-Ack (d_EID,| | d_EID2, ..., d_EIDn)| |<---------------------------| | | <<ITR Reboot>> |Map-Subscribe(I) | |--------------------------->| | Map-Subscribe-Ack (I)| |<---------------------------| | Map-Reply (d_EID)| |<---------------------------| | Map-Reply (d_EID2)| |<---------------------------| .... | Map-Reply (d_EIDn)| |<---------------------------|
Figure 4: Example of Mapping Cache Retrieval: Matching the Filters Installed in the Mapping System
+--------+ +--------+ | ITR1 | | MR | +--------+ +--------+ | | | | |Map-Subscribe(d_EID, d_EID2,| |..., d_EIDn) | |--------------------------->| | Map-Subscribe-Ack (d_EID,| | d_EID2, ..., d_EIDn)| |<---------------------------| | | <<ITR Reboot>> |Map-Subscribe(I) | |--------------------------->| | Map-Subscribe-Ack (I)| |<---------------------------| | Map-Reply (d_EID, d_EID2, | ..., )| |<---------------------------|
Figure 5: Example of Bulk Mapping Cache Retrieval: Matching the Filters Installed in the Mapping System
+--------+ +--------+ | ITR1 | | MR | +--------+ +--------+ | | | | <<ITR Reboot>> | | |Map-Subscribe(I, d_EID | | d_EID2, ..., d_EIDn) | |--------------------------->| | Map-Subscribe-Ack (I, d_EID| | d_EID2, ..., d_EIDn)| |<---------------------------| | Map-Reply (d_EID)| |<---------------------------| | Map-Reply (d_EID2)| |<---------------------------| .... | Map-Reply (d_EIDn)| |<---------------------------|
Figure 6: Example of Mapping Cache Retrieval: Matching the Filters Conveyed in the request
The example shown in Figure 7, illustrates an ITR (ITR1) that is notified with the new EID-RLOC mapping that it subscribed to.
+--------+ +--------+ +--------+ | ITR1 | | MR | | ETR | +--------+ +--------+ +--------+ | | | | | | |Map-Subscribe | | |--------------------------->| | | Map-Subscribe-Ack (d_EID)| | |<---------------------------| | | | | | Map-Reply (d_EID)| | |<---------------------------| | .... src=s_EID| | -------->|src=RLOC_itr1 dst=RLOC_etr|src=s_EID dst=d_EID|==============Encapsulated Packet==========>|--------> | |dst=d_EID ....
Figure 7: Example of Unsolicited Map-Reply
This document does not introduce any additional security issues other than those discussed in [RFC6830] and [RFC6833].
To be completed.
This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-009-X.
[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. |
[RFC6724] | Thaler, D., Draves, R., Matsumoto, A. and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012. |
[RFC6830] | Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013. |
[RFC6833] | Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013. |
[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-09, March 2015. |
[I-D.boucadair-lisp-bulk] | Boucadair, M., and C. Jacquenet, "LISP Mapping Bulk Retrieval", September 2015. |