LISP Mapping Service Functions Discovery (LMSFD) using OSPF
draft-boucadair-lisp-function-discovery-01

Abstract

This document specifies extensions to the Open Shortest Path First (OSPF) protocol for the discovery of Locator/ID Separation Protocol (LISP) Mapping Service functions, especially the Map-Resolver (MR) and Map-Server (MS) LISP components.

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 9, 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
• 2. Overview
• 3. Mapping Service Function Discovery (MSFD) TLV
• 3.1. MSF-TYPE sub-TLV
• 3.2. MSF-LOCATOR sub-TLV
• 3.3. MSF-DESCRIPTION sub-TLV
• 3.4. MSF-EPOCH sub-TLV
• 3.5. MSF-UNAVAILABILITY-TIMER sub-TLV
• 3.6. MSF-REBOOT-TIMER sub-TLV
• 3.7. MSF-DIAGNOSIS sub-TLV
• 3.8. MS-STATUS sub-TLV
• 3.9. MSF-STATUS sub-TLV
• 4. Mapping Service Reachability Information
• 5. OSPF Operation
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.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. The ability of dynamically discovering the Map-Resolver (MR) and Map-Server (MS) entities that provide such mapping services is meant to facilitate global LISP operation (automatic discovery of Map-Resolvers and Map-Servers).

The dynamically-acquired information will not only be used by xTR routers but also by management platforms (e.g., a service controller, a network manager, etc.) to forward traffic over the LISP network or to get an up-to-date view of the global LISP network topology, including the location of the resolvers and servers. For example, ETRs will register in all instances that are reachable in a given domain.

The ability to dynamically discover LISP mapping component information and update such information as appropriate is also useful to ease state synchronization among the various Mapping Service Functions that can be solicited in the LISP network, especially whenever a new MS joins the LISP Mapping System. This specification allows the following:

1. Ease the introduction of new MS servers: Additional MS instances may be added to a Mapping Service domain. New MSes need to build an updated mapping database to avoid service disruption. Owing to the mechanism defined in this document,
   • Peer MSes can be discovered by a new MS, thereby triggering a state synchronisation procedure. How state synchronisation is achieved is out of scope of this document.
   • xTRs can immediately send registration messages to the new MS.
2. Minimize service disruption when multiple MS/MRs are available: this specification allows to disseminate information that will drive the selection process undertaken by an xTR to select an MS/MR and solicit it. For example, MRs with empty databases will be avoided; "ready-to-serve" MRs will be solicited instead. Map-Register requests can thus be sent to multiple MSes whenever needed. When a Mapping Service function loses its state, an explicit message can be generated accordingly so that xTRs (and also management platforms) can trigger appropriate actions.

This document specifies a means to dynamically discover Map-Resolver and Map-Server components of a LISP network.

The reader should be familiar with the terms defined in [RFC6833].

2. Overview

This document defines extensions to OSPFv2 [RFC2328] and OSPFv3 [RFC5340] so that routers of the OSPF routing domain (a single area or the entire routing domain) can advertise a Mapping Service Function within the domain, along with some other useful information. To do so, a new TLV (named the LISP Mapping Service Function Discovery TLV (LMSFD TLV)) is used to announce LISP MR and MS information. This TLV is carried by the OSPF Router Information LSA [RFC7770].

The location of each Mapping Service Function is then flooded into an OSPF area or the whole OSPF routing domain (in the case the LSA is AS-scoped). The xTR routers deployed within the OSPF domain must listen to the flooding messages sent by active Mapping Service Function instances. Such messages are referred to "Mapping Service Discovery" messages in this document.

The information to be announced by means of the LMSFD TLV carried in the Router Information LSA during the LISP Mapping Service Function Discovery procedure includes (but is not necessarily limited to):

• Mapping Service Function type: Indicates whether the MSF acts as Map-Resolver (MR), Map-Server (MS), or both.
• Mapping Service Function Service locator(s): Includes one or several IPv4 addresses, one or several IPv6 addresses or a combination thereof. This information lists the set of locators that unambiguously indicate where the Mapping Service Function can be reached. The locator information must be included in the Mapping Service Function Discovery messages.
• Mapping Service Function unavailability timer: Indicates the time when the Mapping Service Function will be unavailable. This parameter can be used for planned maintenance operations, for instance. This parameter does not provide any indication about when the Mapping Service Function instance will be available again. This information is optional and may therefore be included in the Mapping Service Function Discovery messages.
• Mapping Service Function reboot timer: Operational teams often proceed with a reboot of the devices deployed in the network, within the context of major software upgrade campaigns, for example. This timer is used to indicate that a Mapping Service Function will be unavailable during the reboot of the device that supports the function. Unlike the previous timer, this timer is used to indicate that the Mapping Service Function will be available immediately after the reboot of the device that supports this function is completed. This information is optional and may therefore be included in the Mapping Service Function Discovery messages.
• Mapping Service Function Diagnosis: Indicates whether this Mapping Service Function instance supports a diagnostic mechanism. This information is optional and may therefore be included in the Mapping Service Function Discovery messages.
• Mapping Service Status: Provides information about the status of the mapping database. In particular, it indicates whether the database is empty, synchronized with other MS servers located in the same OSPF domain, etc. This information is optional and may therefore be included in the Mapping Service Function Discovery messages.
• Mapping Service Function Status: Indicates the status of the Mapping Service Function Instance (enabled, disabled). This information is optional and may therefore be included in the LMSFD messages.
• Additional capabilities such as the support of mapping bulk retrieval [I-D.boucadair-lisp-bulk] or notifications [I-D.boucadair-lisp-subscribe] may be advertised.

3. Mapping Service Function Discovery (MSFD) TLV

The format of the OSPF Mapping Service Function Discovery TLV (LMSFD TLV, Figure 1) and its sub-TLVs use the same TLV format as in the Traffic Engineering Extensions to OSPF [RFC3630].

                        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             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                            sub-TLVs                           :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sub-TLV type  Length               Name
      1         1      MSF-TYPE sub-TLV
      2      variable  MSF-LOCATOR sub-TLV
      3      variable  MSF-DESCRIPTION sub-TLV
      4        4       MSF-EPOCH sub-TLV
      5        4       MSF-UNAVAILABILITY-TIMER sub-TLV
      6        4       MSF-REBOOT-TIMER sub-TLV
      7        1       MSF-DIAGNOSIS sub-TLV
      8        4       MS-STATUS sub-TLV
      9        4       MSF-STATUS sub-TLV

                        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 = 1         |        Length=4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type                |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The current type values are defined: 
   0: Map-Server
   1: Map-Resolver
   2: Both

                        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 = 2         |        Length=Variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         IPv4 or IPv6 address                  :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        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 = 3         |        Length=Variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         Description                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        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 = 4         |             Length=4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Value (seconds)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        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 = 5         |             Length=4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Timer (seconds)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        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 = 6         |             Length=4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Timer (seconds)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        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 = 7         |             Length=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 = 8         |        Length=4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Status              |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The current Status values are defined: 
      0: Reset
      1: Partial
      2: Synchronized

                    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 = 9         |        Length=4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Status              |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The current Status values are defined: 
       0: Enabled
       1: Disabled