One document matched: draft-boucadair-lisp-subscribe-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc rfcedstyle="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-boucadair-lisp-subscribe-03"
ipr="trust200902">
<front>
<title abbrev="LISP Subscribe">LISP Subscription</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<date day="" month="" year="" />
<area>Internet</area>
<keyword>IPv4 service continuity</keyword>
<keyword>IPv4 address exhaustion</keyword>
<keyword>Service Availability</keyword>
<keyword>Address sharing</keyword>
<keyword>IPv6</keyword>
<keyword>Reliability</keyword>
<keyword>IPv4 over IPv6</keyword>
<abstract>
<t>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.</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 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. 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.</t>
<section title="Issues">
<t>This section lists a set of issues that need further
investigation:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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).</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
</section>
<section title="Assumptions">
<t>This document makes the following assumptions:<list style="symbols">
<t>Various LISP players (network operators, service providers,
etc.) are likely to deploy and operate different 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.</t>
<t>Interconnection between these Mapping Systems is required for
the sake of global connectivity and also to minimize the risk of
fragmenting the Internet.</t>
<t>Mapping Services are supposed to be dimensioned to maintain a
global mapping database for the entire LISP-enabled Internet.</t>
<t>Mapping Service providers may offer advanced services to their
customers such as maintain local caches (a la CDN), or update ITR
mapping entries that match some criteria requested by a leaf LISP
network, redirect ITR requests to the closest Map-Resolvers,
structure the mapping resolution service so that the resolution
time is optimized, etc.</t>
<t>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.</t>
<t>A leaf LISP-enabled network subscribes to the Mapping Service
provided by one or several Mapping Service operators.</t>
<t>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.</t>
</list></t>
</section>
<section title="Improving LISP Mapping Services">
<t>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.</t>
<t>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 <xref target="subm"></xref> and <xref
target="suba"></xref>.</t>
</section>
</section>
<section anchor="subm" title="Map-Subscribe Message Format">
<t>The format of the Map-Subscribe message is shown in <xref
target="ms"></xref>.</t>
<t><figure anchor="ms" title="Map-Subscribe Message Format">
<artwork><![CDATA[ 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 Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ :
: Filter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ :
: Filter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The description of the fields is as follows:<list style="symbols">
<t>Type is to be defined.</t>
<t>A (Ack-bit): this bit MUST be set to 0 for Map-Subscribe
requests.</t>
<t>U (unsolicited-map-reply bit): When set, this flag indicates that
the originating ITR is ready to receive implicit Map-Reply
messages.</t>
<t>B (bulk-support bit): When set, this flag indicates that the
originating ITR supports mapping bulk retrieval method (e.g., <xref
target="I-D.boucadair-lisp-bulk"></xref>).</t>
<t>I (immediate-retrieval bit): When set, this flag indicates that
the originating ITR requests immediate retrieval of the portion of
the mapping table that matches the filters included in the
request.</t>
<t>Reserved: reserved bits, MUST be sent as 0 and MUST be ignored
when received.</t>
<t>Filter Count: This field indicates the number of the filters
included in the message.</t>
<t>Nonce, Key ID, Authentication Data Length, and Authentication
Data are similar to those of a LISP Map-Register message (<xref
target="RFC6830"></xref>).</t>
<t>Expiry Timer: This field indicates, in seconds, the validity
timer for the subscription.</t>
<t>Length: This field indicates, in octets, the length of the filter
that is encoded in the "Filter" field.</t>
<t>Filter: This field carries a destination EID (or a set thereof)
that is encoded as an UTF-8 string. This specification allows to
convey IP prefix literals, Names and/or AS numbers. One or multiple
filters may be present in a request. IPv4 prefixes are encoded as
IPv4-mapped IPv6 prefixes <xref target="RFC4291"></xref> (i.e.,
starting with ::ffff:0:0/96). A mix of names, IP prefixes and AS
numbers may be enclosed in the same request. The value 0 is used to
delete existing filters. Filters MUST be applied in the order they
appear in the request.</t>
</list></t>
</section>
<section anchor="suba" title="Map-Subscribe-Ack Message Format">
<t>The format of the Map-Subscribe-Ack message is shown in <xref
target="ack"></xref>.</t>
<t><figure anchor="ack" title="Map-Subscribe-Ack Message Format">
<artwork><![CDATA[ 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 Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ :
: Filter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ :
: Filter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Redirect Map-Resolver |
| IP Address (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>The description of the fields is as follows:</t>
<t><list style="symbols">
<t>Type is to be defined. The same code is used for both
Map-Subscribe and Map-Subscribe-Ack.</t>
<t>A (Ack-bit): this bit MUST be set to 1 for Map-Subscribe-Ack
responses.</t>
<t>U (unsolicited-map-reply bit): When set, this flag indicates that
the Map-Resolver can issue implicit Map-Reply messages.</t>
<t>B (bulk-support bit): When set, this flag indicates that the
Map-Resolver supports mapping bulk retrieval method (e.g., <xref
target="I-D.boucadair-lisp-bulk"></xref>).</t>
<t>I (immediate-retrieval bit): When set, this flag indicates that
the Map-Resolver will initiate an immediate push cycle of the
portion of the mapping table that matches the filters included in
the request.</t>
<t>R (Redirect bit): When set, this flag indicates that a redirect
Map-Resolver is enclosed in the message.</t>
<t>Reserved: reserved bits, MUST be set to 0 and MUST be ignored
when received.</t>
<t>Result: indicates the result code of the processing of the
Map-Subscribe request. The following codes are defined:<list
style="hanging">
<t hangText="0:">SUCCESS. This code is used to indicate the
request is successfully processed.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="4:">FILTERS-PROHIBITED. This code is used to
indicate a request is successfully processed but the
installation of filters is prohibited.</t>
</list></t>
<t>Filter Count: This field indicates the number of the filters
included in the message.</t>
<t>Nonce, Key ID, Authentication Data Length, and Authentication
Data are similar to those of a LISP Map-Register message (<xref
target="RFC6830"></xref>).</t>
<t>Expiry Timer: This field indicates, in seconds, the validity
timer for the subscription.</t>
<t>Length: This field indicates, in octets, the length of the filter
that is encoded in the "Filter" field.</t>
<t>Filter: This field carries the set of filters that were
successfully installed.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="gen" title="Generating a Map-Subscribe Message">
<t>The A-bit of a Map-Subscribe message MUST be set to 0.</t>
<t>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.</t>
<t>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., <xref
target="I-D.boucadair-lisp-bulk"></xref>).</t>
<t>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. Note, an ITR can indicate a Null filter using one of these
methods: <list style="numbers">
<t>Send a Map-Subscribe message with a "Filter Count" set to 0,
or</t>
<t>Include a Filter with a 'Filter" field set to zeros. </t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Processing a Map-Subscribe Message">
<t>A Map-Resolver that does not support the Map-Subscribe message MUST
silently ignore any Map-Subscribe message it receives.</t>
<t>Map-Resolvers MUST support a configurable parameter to enable/disable
the processing of Map-Subscribe messages. The default value is set to
"enabled".</t>
<t>A Map-Resolver SHOULD support a configuration parameter to limit the
number of filters per leaf LISP network, per ITR, etc.</t>
<t>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.</t>
<t>When building a Map-Subscribe-Ack message, the Map-Resolver
MUST:<list style="symbols">
<t>Set the A-bit to indicate this is a response to a Map-Subscribe
request.</t>
<t>Set the U-bit if it supports the unsolicited Map-Reply
capability, except if a redirect Map-Resolver is to be returned.</t>
<t>Set the B-bit if it supports a method for mapping bulk transfer,
except if a redirect Map-Resolver is to be returned.</t>
<t>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).</t>
<t>Echo the I-bit if the Map-Resolver accepts to initiate
unsolicited mapping retrievals, except if a redirect Map-Resolver is
to be returned.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>If filters are not allowed for a given ITR, the 'Result' field MUST
be set to FILTERS-PROHIBITED.</t>
<t>If all filters are successfully installed, the 'Result' field MUST be
set to SUCCESS.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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). </t>
<t>An ITR can replace an existing filter by a more specific one by
deleting all filters and install the new ones.</t>
<t>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.</t>
<t>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).</t>
<t>Upon expiry of the validity timer associated with a filter, the
Map-Resolver MUST delete that filter from its mapping subscription
system.</t>
</section>
<section title="Processing a Map-Subscribe-Ack Message">
<t>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:<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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:<list
style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>The ITR MUST adjust the Expiry Timer carried in the
Map-Subscribe-Ack. Subscription should be renewed before the expiry
of that timer.</t>
</list></t>
<t></t>
</section>
<section title="Subscription to Multiple Resolvers">
<t>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 <xref target="gen"></xref>.</t>
</section>
<section title="Sample Examples">
<t>This section includes a set of examples to illustrate the usage of
the methods defined in <xref target="subm"></xref>.</t>
<section title="Map-Resolver Redirect">
<t>The example shown in <xref target="redirect"></xref>, illustrates
an example of an ITR (ITR1) that is redirected to another Map-Resolver
(MR2).</t>
<t><figure anchor="redirect"
title="Example of Map-Resolver Redirection">
<artwork align="center"><![CDATA[
+--------+ +--------+ +--------+
| ITR1 | | MR1 | | MR2 |
+--------+ +--------+ +--------+
| | |
|Map-Subscribe | |
|-------------------------->| |
| Map-Subscribe-Ack (R, MR2)| |
|<--------------------------| |
|Map-Subscribe | |
|------------------------------------->|
| Map-Subscribe-Ack|
|<-------------------------------------|
| |
|Map-Request |
|------------------------------------->|
| Map-Reply|
|<-------------------------------------|
]]></artwork>
</figure></t>
</section>
<section title="Mapping Cache Retrieval">
<t>The examples shown in <xref target="retrieval"></xref> and <xref
target="retrievalb"></xref>, illustrate examples of an ITR (ITR1) that
restores its mapping tables upon reboot according to the filters
already present in the mapping system.</t>
<t>The example in <xref target="retrieval"></xref>, indicates how an
ITR retrieves the mappings that match the filters included in the
Map-Subscribe request using distinct Map-Reply messages.</t>
<t>The example in <xref target="retrievalb"></xref>, assumes that
multiple records bound to distinct EIDs are included in the same
Map-Reply message.</t>
<t>This procedure applies to ITRs which do not store the mapping table
in a permanent memory storage facility.</t>
<t>Owing to this procedure, the ITR is ready-to-serve as soon as
reboot is completed or right after a mapping cache clear event.</t>
<t><figure anchor="retrieval"
title="Example of Mapping Cache Retrieval: Matching the Filters Installed in the Mapping System">
<artwork align="center"><![CDATA[ +--------+ +--------+
| 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)|
|<---------------------------|
]]></artwork>
</figure></t>
<t></t>
<figure anchor="retrievalb"
title="Example of Bulk Mapping Cache Retrieval: Matching the Filters Installed in the Mapping System">
<artwork align="center"><![CDATA[ +--------+ +--------+
| 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,
| ..., )|
|<---------------------------|
]]></artwork>
</figure>
<t></t>
<t></t>
</section>
<section title="Unsolicited Map-Reply">
<t>The example shown in <xref target="unreply"></xref>, illustrates an
ITR (ITR1) that is notified with the new EID-RLOC mapping that it
subscribed to.</t>
<t><figure anchor="unreply" title="Example of Unsolicited Map-Reply">
<artwork align="center"><![CDATA[ +--------+ +--------+ +--------+
| 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
....
]]></artwork>
</figure></t>
</section>
</section>
<section title="Security Considerations">
<t>This document does not introduce any additional security issues other
than those discussed in <xref target="RFC6830"></xref> and <xref
target="RFC6833"></xref>.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document requests IANA to assign a new code from the LISP Packet
Types registry (<xref
target="I-D.boucadair-lisp-type-iana"></xref>):</t>
<t><figure>
<artwork><![CDATA[Message Code Reference
================================= ==== ===============
Map-Subscribe/Map-Subscribe-Ack TBD [This document]]]></artwork>
</figure></t>
</section>
<section title="Acknowledgments">
<t>This work is partly funded by ANR LISP-Lab project
#ANR-13-INFR-009.</t>
<t>Many thanks to Stefano Secci and Chi-Dung Phung for their review.</t>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc include='reference.RFC.6830'
?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4291'?>
<?rfc include='reference.RFC.6833'?>
<?rfc include='reference.I-D.boucadair-lisp-type-iana'?>
</references>
<references title="Informative references">
<?rfc include='reference.I-D.boucadair-lisp-bulk'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:39:33 |