Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Experimental Orange
Expires: September 16, 2016 March 15, 2016

Improving Mapping Services in LISP Networks
draft-boucadair-lisp-subscribe-02

Abstract

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.

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 September 16, 2016.

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

1.1. Issues

This section lists a set of issues that need further investigation:

Discover ITRs:
Current LISP design does not allow to automatically discover active ITRs of a LISP domain (nor the mapping system of a given domain is aware of ITRs of the same domain that can solicit its services, let alone ITRs of other domains). The solution proposed in this document allows to fill that gap.
Optimize EID-ROLC resolution time:
Leaf LISP networks can be better serviced, for example by avoiding the cascading of Map-Resolvers, or by avoiding the solicitation of a Map-Resolver that is located an ocean away, etc. Policies should be taken into account when configuring Map-Resolver information on an ITR for improving EID-to-RLOC resolution. These policies should be modified and adjusted according to various events (e.g., installation of an additional Map-Resolver).
Accomodate Map-Resolvers constraints:
Allows for the protocol to redirect a requesting ITR to another Map-Resolver when some events occur, such as an overload of the initially targeted Map-Resolver or when Map-Resolvers are optimized to service a set of destination EIDs, etc.
Faster Recovery of mapping entries:
Whenever an ITR fails for some reason, the faulty ITR needs to recover at least the list of mappings for the most popular prefixes in a timely manner, in particular. Policies for mapping entries (to be recovered) are deployment-specific.
Receive push notifications:
For LISP leaf networks that would need to maintain an up-to-date mapping table for a set of destination EIDs (or even the global mapping table) to avoid issues such as the loss of a first packet or to optimize LISP forwarding delay (and therefore the overall forwarding efficiency), a dynamic push mechanism would be helpful.

1.2. Assumptions

This document makes the following assumptions:

1.3. Improving LISP Mapping Services

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.

2. Map-Subscribe Message Format

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  |A|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:

3. Map-Subscribe-Ack Message Format

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

  • Type is to be defined. The same code is used for both Map-Subscribe and Map-Subscribe-Ack.
  • A (Ack-bit): this bit MUST be set to 1 for Map-Subscribe-Ack responses.
  • U (unsolicited-map-reply bit): When set, this flag indicates that the Map-Resolver can issue unsolicited Map-Reply messages.
  • B (bulk-support bit): When set, this flag indicates that the Map-Resolver supports mapping bulk retrieval method (e.g., [I-D.boucadair-lisp-bulk]).
  • I (immediate-retrieval bit): When set, this flag indicates that the Map-Resolver will initiate an immediate retrieval cycle of the portion of the mapping table that matches the filters included in the request.
  • R (Redirect bit): When set, this flag indicates that a redirect Map-Resolver is enclosed in the message.
  • Reserved: reserved bits, MUST be set to 0 and MUST be ignored when received.
  • Result: indicates the result code of the processing of the Map-Subscribe request. The following codes are defined:
    0:
    SUCCESS. This code is used to indicate the request is successfully processed.
    1:
    PARTIAL-FILTERS-INSTALLED-LIMIT. This code is used to indicate a request is successfully processed but some filters were not installed because the number of filters carried in the initial Map-Subscribe message exceeds the filter limit.
    2:
    PARTIAL-FILTERS-INSTALLED-BAD. This code is used to indicate a request is successfully processed but some filters were not installed because they were malformed.
    3:
    PARTIAL-FILTERS-INSTALLED-LOCAL. This code is used to indicate a request is successfully processed but some filters were not installed because of local reasons. The ITR SHOULD, after a certain timer expires, send a Map-Subscribe request message for the set of filters that are not included in the Map-Subscribe-Ack message received by the ITR in response to its initial Map-Subscribe request message.
    4:
    FILTERS-PROHIBITED. This code is used to indicate a request is successfully processed but the installation of filters is prohibited.
  • Filter Len: This field indicates in bytes, the length of the filters included in the message. It is equal to (sum of "8+Length of Filter"), where Filter represents the filters included in the message.
  • Nonce, Key ID, Authentication Data Length, and Authentication Data are similar to those of a LISP Map-Request message ([RFC6830]).
  • Expiry Timer: This field indicates, in seconds, the validity timer for the subscription.
  • Length: This field indicates, in octets, the length of the filter that is encoded in the "Filter" field.
  • Filter: This field carries the set of filters that were successfully installed.
  • Redirect Map-Resolver IP Address (128 bits): When the R-bit is set, this field carries the IP address of the Map-Resolver where mapping requests should be redirected. An IPv4 address is encoded as an IPv4-mapped IPv6 address.

4. Generating a Map-Subscribe Message

The A-bit of a Map-Subscribe message MUST be set to 0.

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.

5. Processing a Map-Subscribe Message

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:

  • Set the A-bit to indicate this is a response to a Map-Subscribe request.
  • Set the U-bit if it supports the unsolicited Map-Reply capability, except if a redirect Map-Resolver is to be returned.
  • Set the B-bit if it supports a method for mapping bulk transfer, except if a redirect Map-Resolver is to be returned.
  • Set the R-bit if it wants to inform the requesting ITR about another Map-Resolver it should contact. The Map-Resolver MAY return a set of filters that are to be applied by the ITR to select the Map-Resolver (i.e., destination EID Map-Resolver address selection).
  • Echo the I-bit if the Map-Resolver accepts to initiate unsolicited mapping retrievals, except if a redirect Map-Resolver is to be returned.
  • If no redirect is enabled and the request includes one or several filters, the Map-Resolver MUST echo the filters it succeeds to install, and in the same order of appearance, in the Map-Subscribe-Ack message.
  • If the Map-Resolver is configured with maximum and minimum values for the expiry timer, the Map-Resolver MUST adjust the Expiry Timer enclosed in the request so that it does not exceed these boundary values.

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.

6. Processing a Map-Subscribe-Ack Message

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:

  • If the U-bit is set, it should expect that unsolicited Map-Reply messages will be received from this Map-Resolver. Appropriate security mechanisms (e.g., Access Control Lists) SHOULD be activated to allow the processing of these incoming unsolicited Map-Reply messages.
  • If the B-bit is set, it should expect that (unsolicited) mapping bulk transfer messages are supported by this Map-Resolver. Appropriate security mechanisms (e.g., Access Control Lists) SHOULD be activated to allow the processing of these incoming unsolicited bulk transfer messages.
  • If the R-bit is set and the 'Redirect Map-Resolver IP Address' field embeds a valid IP address, the ITR MUST update its Map-Resolver contact information with the new Map-Resolver's IP address. The ITR MUST use that IP address for subsequent exchanges. Optionally, if filters were included in the reply sent by the Map-Resolver, these filters are used for the destination EID Map-Resolver address selection.
  • If the message includes one or several filters, the ITR MUST check whether the same set of filters as those included in the Map-Subscribe request are carried in the Map-Subscribe-Ack message. Filters that are not returned in the Map-Subscribe-Ack message may not be valid or have exceeded a limit. The "Result" code indicates the reason for not installing these filters. In particular:
    • An ITR that receives the result code set to PARTIAL-FILTERS-INSTALLED-LIMIT MUST NOT try to install new filters unless it clears all the filters maintained by the Map-Resolver or it removes some of them.
    • An ITR that receives the result code set to PARTIAL-FILTERS-INSTALLED-BAD MUST NOT resend the same filters that were not returned in the Map-Subscribe-Ack message, in subsequent Map-Subscribe requests.
    • An ITR that receives the result code set to FILTERS-PROHIBITED MUST NOT include the filters that were not returned in the Map-Subscribe-Ack message, in a Map-Subscribe message sent to that Map-Resolver.
    • An ITR that receives the result code set to PARTIAL-FILTERS-INSTALLED-LOCAL SHOULD wait for at least 60 seconds before issuing another Map-Subscribe message to install the filters that were not returned in the Map-Subscribe-Ack message.
  • The ITR MUST adjust the Expiry Timer carried in the Map-Subscribe-Ack. Subscription should be renewed before the expiry of that timer.

7. Subscription to Multiple Resolvers

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.

8. Sample Examples

This section includes a set of examples to illustrate the usage of the methods defined in Section 2.

8.1. Map-Resolver Redirect

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

8.2. Mapping Cache Retrieval

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

8.3. Unsolicited Map-Reply

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

9. Security Considerations

This document does not introduce any additional security issues other than those discussed in [RFC6830] and [RFC6833].

10. IANA Considerations

To be completed.

11. Acknowledgments

This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-009.

Many thanks to Stefano Secci and Chi-Dung Phung for their review.

12. References

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

12.2. Informative references

[I-D.boucadair-lisp-bulk] Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk Retrieval", Internet-Draft draft-boucadair-lisp-bulk-01, 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