One document matched: draft-boucadair-lisp-function-discovery-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-lisp-function-discovery-00"
ipr="trust200902">
<front>
<title abbrev="Service Function Discovery">LISP Mapping Service Functions
Discovery using OSPF</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<date />
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Locator/ID Separation Protocol (LISP, <xref target="RFC6830"></xref>
) 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 (automatic discovery of Map-Resolvers
and Map-Servers).</t>
<t>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.</t>
<t>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:</t>
<t><list style="numbers">
<t>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, <list style="symbols">
<t>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.</t>
<t>xTRs can immediately send registration messages to the new
MS.</t>
</list></t>
<t>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.</t>
</list>This document specifies a means to dynamically discover
Map-Resolver (MR) and Map-Server (MS) components of a LISP network.</t>
<t>The reader should be familiar with the terms defined in <xref
target="RFC6833"></xref>.</t>
</section>
<section title="Overview">
<t>This document defines extensions to OSPFv2 <xref
target="RFC2328"></xref> and OSPFv3 <xref target="RFC5340"></xref> 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 Mapping Service Function Discovery TLV (MSFD TLV)) is used to
announce LISP MR and MS information. This TLV is carried by the OSPF
Router Information LSA <xref target="RFC4970"></xref>.</t>
<t>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.</t>
<t>The information to be announced by means of the MSFD TLV carried in
the Router Information LSA during the LISP Mapping Service Function
Discovery procedure includes (but is not necessarily limited to):</t>
<t><list style="symbols">
<t>Mapping Service Function type: Indicates whether the MSF acts as
Map-Resolver (MR), Map-Server (MS), or both.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 Mapping
Service Function Discovery messages.</t>
<t>Additional capabilities such as the support of mapping bulk
retrieval <xref target="I-D.boucadair-lisp-bulk"></xref> or
notifications <xref target="I-D.boucadair-lisp-subscribe"></xref>
may be advertised.</t>
</list></t>
</section>
<section title="Mapping Service Function Discovery (MSFD) TLV">
<t>The format of the OSPF Mapping Service Function Discovery TLV (MSFD
TLV, <xref target="tlv"></xref>) and its sub-TLVs use the same TLV
format as in the Traffic Engineering Extensions to OSPF <xref
target="RFC3630"></xref>.</t>
<t><figure anchor="tlv">
<artwork><![CDATA[ 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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>The description of the fields is as follows:<list
style="symbols">
<t>Type: To be assigned by IANA.</t>
<t>Length: Variable (octets).</t>
<t>sub-TLVs: Includes the list of sub-TLVs. The following sub-TLVs
are defined in this document:</t>
</list></t>
<figure>
<artwork><![CDATA[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
]]></artwork>
</figure>
<t></t>
<t>The MSF-TYPE and MSF-LOCATOR sub-TLVs MUST always be present within
the MSFD TLV. Additional optional sub-TLVs MAY be included.</t>
<section title="MSF-TYPE sub-TLV">
<t>The format of MSF-TYPE sub-TLV is shown in <xref
target="ty"></xref>.</t>
<t><figure anchor="ty" title="MSF-TYPE sub-TLV">
<artwork><![CDATA[ 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
]]></artwork>
</figure></t>
</section>
<section title="MSF-LOCATOR sub-TLV">
<t>The format of MSF-LOCATOR sub-TLV is shown in <xref
target="loc"></xref>.</t>
<t><figure anchor="loc" title="MSF-LOCATOR sub-TLV">
<artwork><![CDATA[ 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>The MSF-LOCATOR sub-TLV MAY appear twice, especially when
the SF can be reached via either an IPv4 or an IPv6 address or both.
It MAY also appear more than once for the same address family if the
Service Function is assigned several addresses of the same family.</t>
</section>
<section title="MSF-DESCRIPTION sub-TLV">
<t>The format of MSF-DESCRIPTION sub-TLV is shown in <xref
target="des"></xref>.<figure anchor="des"
title="MSF-DESCRIPTION sub-TLV">
<artwork><![CDATA[ 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>When present, the MSF-DESCRIPTION sub-TLV MUST carry UTF-8 encoded
<xref target="RFC3629"></xref> description text. The description text
SHOULD NOT be null terminated.</t>
</section>
<section title="MSF-EPOCH sub-TLV">
<t>The format of MSF-EPOCH sub-TLV is shown in <xref
target="epo"></xref>.<figure anchor="epo" title="MSF-EPOCH sub-TLV">
<artwork><![CDATA[ 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>When a Mapping Service Function loses its state (e.g., power
failure, bug, reset by an administrator, etc.), it may use this
sub-TLV with a value set to 0. This value is then incremented by
one.</t>
<t>If the value field of the MSF-EPOCH sub-TLV is set to 0, it
indicates that the Mapping Service Function instance has been reset or
lost its state. This information is particularly important for ETRs so
that they can send their registration request immediately.</t>
<t>Receivers may maintain a record of transmitted values to detect
anomalies in the Mapping Service Function.</t>
</section>
<section title="MSF-UNAVAILABILITY-TIMER sub-TLV">
<t>The format of MSF-UNAVAILABILITY-TIMER sub-TLV is shown in <xref
target="un"></xref>.<figure anchor="un"
title="MSF-UNAVAILABILITY-TIMER sub-TLV">
<artwork><![CDATA[ 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The MSF-UNAVAILABILITY-TIMER sub-TLV indicates, in seconds, when
the Mapping Service Function instance will be unavailable.</t>
<t>If the value field of the MSF-UNAVAILABILITY-TIMER sub-TLV is set
to 0, it indicates the Mapping Service Function instance will be
unavailable immediately.</t>
</section>
<section title="MSF-REBOOT-TIMER sub-TLV">
<t>The format of MSF-REBOOT-TIMER sub-TLV is shown in <xref
target="reb"></xref>.<figure anchor="reb"
title="MSF-REBOOT-TIMER sub-TLV">
<artwork><![CDATA[ 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The MSF-REBOOT-TIMER sub-TLV indicates, in seconds, when the
Mapping Service Function instance will start to reboot. The function
will be operational right after the reboot is completed.</t>
</section>
<section title="MSF-DIAGNOSIS sub-TLV">
<t>The format of MSF-DIAGNOSIS sub-TLV is shown in <xref
target="diag"></xref>.</t>
<t><figure anchor="diag" title="MSF-DIAGNOSIS sub-TLV">
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>The presence of this sub-TLV indicates that the Mapping
Service Function supports diagnostic functions.</t>
</section>
<section title="MS-STATUS sub-TLV">
<t>The format of MS-STATUS sub-TLV is shown in <xref
target="stat"></xref></t>
<figure anchor="stat" title="MS-STATUS sub-TLV">
<artwork><![CDATA[ 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
]]></artwork>
</figure>
<t></t>
<t>The presence of this sub-TLV indicates the status of the Mapping
Service database. This is important for influencing the selection
process of Map-Resolvers, in particular.</t>
</section>
<section title="MSF-STATUS sub-TLV">
<t>The format of MSF-STATUS sub-TLV is shown in <xref
target="msfs"></xref></t>
<figure anchor="msfs" title="MSF-STATUS sub-TLV">
<artwork><![CDATA[ 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]]></artwork>
</figure>
<t>The presence of this sub-TLV indicates the status of Mapping
Service Function.</t>
<t>The presence of this sub-TLV is particularly useful to indicate
that a given instance is disabled.</t>
</section>
</section>
<section title="Mapping Service Reachability Information">
<t>This document assumes that Mapping Service Reachability information
can be injected into OSPF by a router that embeds a Mapping Service
Function instance, or which has been instructed (by means of specific
configuration tasks, for example) to advertise such information on
behalf of a third party Mapping Service Function.</t>
<t>The mechanism defined in this document may be used to advertise and
learn Mapping Service Functions that are available in the same
administrative domain than xTRs. Also, it can be used to dynamically
advertise related reachability information that is learned using other
means when the Mapping Service Functions and xTRs do not belong to the
same administrative entity.</t>
<t>Some of the information carried in the MSFD TLV may be automatically
set by an OSPF speaker while other may be explicitly configured.</t>
</section>
<section title="OSPF Operation">
<t>The MSFD TLV is advertised within OSPFv2 or OSPFv3 Router Information
LSAs <xref target="RFC4970"></xref>.</t>
<t>A change in the operational status of a Mapping Service Function
instance (e.g., enabled, disabled) MUST trigger the generation of a
Router Information LSA that carries the MSFD TLV with the updated
information.</t>
<t>The flooding scope is defined by the Opaque LSA type for OSPFv2 <xref
target="RFC5250"></xref>, and by the S1/S2 bits for OSPFv3 <xref
target="RFC5340"></xref>.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The extensions defined in this document do not introduce any
additional security threats than those already documented in the current
OSPF protocol specifications.</t>
<t>OSPF does not support any encryption mechanism for protecting the
integrity of Mapping Service Function discovery information. Means such
as <xref target="RFC2154"></xref> may be enabled.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>To be completed once the specification is stable.</t>
</section>
<section title="Acknowledgments">
<t>This work is partly funded by ANR LISP-Lab project
#ANR-13-INFR-009-X.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.3630'?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.4970'?>
<?rfc include='reference.RFC.3629'?>
<?rfc include='reference.RFC.5250'?>
<?rfc include='reference.RFC.6833'?>
<?rfc include='reference.RFC.6830'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2154'?>
<reference anchor="I-D.boucadair-lisp-bulk"
target="https://datatracker.ietf.org/doc/draft-boucadair-lisp-bulk/">
<front>
<title>LISP Mapping Bulk Retrieval</title>
<author>
<organization>Boucadair, M., and C. Jacquenet</organization>
</author>
<date month="September" year="2015" />
</front>
</reference>
<reference anchor="I-D.boucadair-lisp-subscribe"
target="https://datatracker.ietf.org/doc/draft-boucadair-lisp-subscribe/">
<front>
<title>Improving Mapping Services in LISP Networks</title>
<author>
<organization>Boucadair, M., and C. Jacquenet</organization>
</author>
<date month="September" year="2015" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:24:51 |