<?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="exp" docName="draft-boucadair-lisp-ms-assisted-forwarding-00"
     ipr="trust200902">
  <front>
    <title abbrev="MS-Assisted Forwarding">Mapping System-Assisted Forwarding
    for Inter-Domain LISP Deployments</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</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>France Telecom</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>One of the issues with current LISP operation is that some packets
      are likely to be lost when there is no matching mapping entry maintained
      by the Ingress Tunnel Router (ITR). This document proposes a solution to
      address this issue with a particular focus on LISP deployments at large
      scale.</t>

      <t>This document introduces the concept of Implicit Map-Request and
      Unsolicited Map-Reply messages. Also, it describes a solution to disable
      data gleaning for a given flow at the upstream Egress Tunnel Router
      (ETR).</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. It is commonly acknowledged that some packets are likely to be
      lost in some specific situations, such as the absence of a mapping entry
      in the mapping cache maintained by an ITR. This phenomenon is usually
      denoted as the "first packet loss" issue.</t>

      <t>This document suggests a solution that relies upon the assistance of
      the Mapping System for the forwarding of the first packet(s) of a flow,
      while corresponding mapping resolution is in progress.</t>

      <t>Deploying LISP at the scale of the Internet heavility relies upon the
      reliability of the LISP Mapping service. In particular, LISP deployments
      at large scale must not degrade the level of quality as currently
      provided by several decades of inter-domain routing practices. <?rfc subcompact="yes" ?></t>

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

          <t>ITRs are configured with a list of one or more Map-Resolvers
          locators. Whether the provisioning of MR-related information to ITRs
          is achieved using a configuration interface or a specific discovery
          mechanism is out of scope of this document.</t>

          <t>Like <xref target="RFC6830"></xref>, this document does not make
          any assumption of the Mapping Service other than it supports the
          primitives defined in <xref target="RFC6833"></xref>.</t>
        </list></t>

      <t><?rfc subcompact="no" ?>This document focuses on the sole LISP
      inter-domain use case. As such, it is out of scope of this document to
      discuss the applicability of the proposed solution to other LISP use
      cases (e.g., LISP-based data center networking) .</t>

      <t>Within this document, "Unsolicited Map-Reply" is used to refer to a
      Map-Reply that is not associated with an (explicit) Map-Request message.
      An unsolicited Map-Reply is sent to an ITR without receiving a
      Map-Request from that ITR.</t>
    </section>

    <section title="Proposed Solution">
      <t>The rationale adopted by this document is that, instead of dropping
      packets that do not match an existing mapping entry in a local cache
      maintained by an ITR, these packets are used as Implicit Map-Requests.
      In particular, the LISP-based forwarding of the first packet(s) can be
      delegated to the Mapping System (MS) that is supposed to maintain the
      required information to process the packet (preferably close to the LISP
      leaf network or at least without inducing severe path stretch). This
      mode is called MS-assisted LISP forwarding.</t>

      <t>Although this feature can be supported by an upstream transit
      provider, this document focuses on the deployment of the MS-assisted
      LISP forwarding solution at the Mapping System side.</t>

      <t>The detailed procedure that aims at minimizing the risk of the
      aforementioned "first packet loss" issue is specified hereafter (see
      <xref target="ex"></xref> for a typical flow example):<?rfc subcompact="yes" ?></t>

      <t><list style="format %d">
          <t>The Mapping System is configured with a list of networks that are
          allowed to invoke the MS-assisted forwarding service. The
          corresponding authorization procedure may rely upon the service
          subscription procedure itself (using static or dynamic means such as
          <xref
          target="I-D.boucadair-connectivity-provisioning-protocol"></xref>).
          <list style="symbols">
              <t>Also, the Mapping System provides a leaf LISP network with
              the appropriate RLOC (referred to as MS_RLOC) so that it can use
              the MS-assisted forwarding feature.</t>

              <t>MS_RLOC may be identical or distinct from the locator
              assigned to one of the Map-Resolvers that can be solicited by
              the leaf LISP network.</t>
            </list></t>

          <t>ITRs MUST support a configuration parameter to enable/disable
          this procedure. The default value of this parameter is
          "Disabled".</t>

          <t>ITRs MAY be configured with a dedicated RLOC for this feature.
          This RLOC MAY NOT be the same locator as the one used to contact a
          Map-Resolver. If no dedicated RLOC is explicitly configured on an
          ITR for which the MS-assisted forwarding procedure is enabled, the
          ITR MUST use the locator of its Map-Resolver (i.e.,
          MS_RLOC=ITR_Locator).</t>

          <t>When an ITR receives a packet to be forwarded outside a given
          LISP domain, it MUST proceed to a lookup of the local mapping cache
          to check whether an entry matches this packet.<list
              style="format 4.%d">
              <t>If a mapping entry is found, the ITR MUST proceed as in <xref
              target="RFC6830"></xref>.</t>

              <t>If no mapping entry is found and the MS-assisted forwarding
              feature is enabled, the ITR MUST use the MS_RLOC to forward the
              packet. That is, the origin packet is forwarded using a LISP
              encapsulation header; the destination IP address of the outer
              header is set to MS_RLOC (instead of the remote ETR's RLOC
              associated with the destination EID). <list
                  style="format 4.2.%d">
                  <t>The ITR MUST set the nonce-present and echo-nonce-request
                  bits.</t>

                  <t>Once forwarded, the ITR MUST listen, using port 4343, to
                  Unsolicited Map-Reply messages that will be received from
                  the Map-Resolver.</t>

                  <t>The ITR MUST follow the same behavior for packets that
                  belong to the same flow until a mapping is retrieved from
                  the Mapping System side. The packet will be used as an
                  "implicit Map-Request" from a downstream ITR.</t>
                </list></t>
            </list></t>

          <t>Upon receipt of the encapsulated packet, the Mapping System:<list
              style="format 5.%d">
              <t>MUST extract the destination EID and proceed to the lookup in
              its global mapping table to retrieve the corresponding entry. If
              a mapping entry is found, it MUST rewrite the source RLOC to be
              set to the destination RLOC of the encapsulated packet received
              from the leaf LISP network and the destination RLOC to the RLOC
              retrieved from the mapping table. Then, the packet is forwarded
              to the next hop. <list style="format 5.1.%d">
                  <t>Using the initial source RLOC to forward the packet might
                  be tempting, but this behavior is discouraged as upstream
                  networks implementing ingress filtering may consider this
                  packet as a spoofing attack.</t>

                  <t>The Mapping System may decide to reset the nonce-present
                  and echo-nonce-request bits. The setting of these bits can
                  be part of the service agreement contracted between the leaf
                  LISP network and the Mapping Service provider.</t>

                  <t>Because upstream ETRs may use the outer LISP header if it
                  implemented information "gleaning", the LISP packet may
                  provide an explicit indication to the ETR to not rely upon
                  the outer header to create a "gleaned" Map-Cache entry but
                  rather proceed with an explicit Map-Request. instead <xref
                  target="glean"></xref> proposes a solution for carrying such
                  indication in the LISP header.</t>
                </list></t>

              <t>In the meantime, an unsolicited Map-Reply message that
              carries records associated with the destination EID, MUST be
              sent to the ITR so that it can handle the packets locally
              without any assistance from the Mapping System. <list
                  style="format 5.2.%d">
                  <t>The Map-Reply message MUST use the same Nonce that was
                  included in the LISP-encapsulated packet received from the
                  downstream ITR.</t>

                  <t>A timer (or a maximum number of the packets) MAY be used
                  so that the assistance mode is deactivated at the Mapping
                  System side for this leaf LISP network/EID. Discarding
                  subsequent packets and associated settings are
                  deployment-specific. It is out of scope of this document to
                  elaborate on such design considerations.</t>
                </list></t>
            </list></t>

          <t>Upon receipt of the Unsolicited Map-Reply message, the ITR MUST
          proceed to Nonce validation checks. <list style="format 6.%d">
              <t>If no error is found, it MUST retrieve the record carried in
              the Map-Reply message.</t>

              <t>The ITR MUST stop using the MS-assisted mode (i.e., for
              forthcoming packets matching this mapping entry).</t>
            </list></t>

          <t>Subsequent packets that belong to the same flow are handled
          locally (i.e., normal LISP operation is in progress).</t>
        </list></t>

      <t><?rfc subcompact="no" ?><figure anchor="ex" title="Flow Example">
          <artwork align="center"><![CDATA[                                +-------+
                                |Mapping|
    +--------+                  |System |                 +--------+
    |  ITR   |                  +-------+                 |  ETR   |
    +--------+                      |                     +--------+
         |                          |                          |
src=s_EID|                          |                          |
-------->|src=RLOC_itr   dst=RLOC_ms|                          |
dst=d_EID|===Encapsulated Packet===>|src=RLOC_ms   dst=RLOC_etr|
         |   Unsolicited Map-Reply  |===Encapsulated Packet===>|
         |<-------------------------|                          |
         |                                                     |  
src=s_EID|                                                     |
-------->|src=RLOC_itr                             dst=RLOC_etr|src=s_EID
dst=d_EID|===================Encapsulated Packet==============>|-------->
         |                                                     |dst=d_EID
                                  ....
src=s_EID|                                                     |
-------->|src=RLOC_itr                             dst=RLOC_etr|src=s_EID
dst=d_EID|===================Encapsulated Packet==============>|-------->
         |                                                     |dst=d_EID

]]></artwork>
        </figure></t>
    </section>

    <section anchor="glean" title="Disable Data Gleaning">
      <t><xref target="RFC6830"></xref> indicates the following:</t>

      <t><list style="empty">
          <t>Section 4: "In order to defer the need for a mapping lookup in
          the reverse direction, an ETR MAY create a cache entry that maps the
          source EID (inner-header source IP address) to the source RLOC
          (outer-header source IP address) in a received LISP packet. Such a
          cache entry is termed a "gleaned" mapping and only contains a single
          RLOC for the EID in question."</t>

          <t>Section 6.2: "Either side (more likely the server-side ETR)
          decides not to send a Map-Request. For example, if the server-side
          ETR does not send Map-Requests, it gleans RLOCs from the client-side
          ITR, giving the client-side ITR responsibility for bidirectional
          RLOC reachability and preferability. Server-side ETR gleaning of the
          client-side ITR RLOC is done by caching the inner-header source EID
          and the outer-header source RLOC of received packets. The
          client-side ITR controls how traffic is returned and can alternate
          using an outer- header source RLOC, which then can be added to the
          list the server-side ETR uses to return traffic. Since no Priority
          or Weights are provided using this method, the server-side ETR MUST
          assume that each client-side ITR RLOC uses the same best Priority
          with a Weight of zero. In addition, since EID-Prefix encoding cannot
          be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers
          can grow to be very large."</t>
        </list></t>

      <t>But the LISP specification does not describe any means for an ITR to
      explicitly inform an ETR that it MUST NOT rely upon the data gleaning
      but, instead, privilege the sending of an explicit Map-request.</t>

      <t>For the particular case covered in this document, the lack of such
      capability may lead to the involvement of an intermediate node for both
      traffic directions. This behavior may not be suitable in some deployment
      situations (e.g., mis-use the relay in the MS domain to forward traffic,
      abuse, denial-of-service, etc.). In order to solve this issue, this
      document proposes to associate a meaning with one of the reserved flag
      bits (see Section 5.3 of <xref target="RFC6830"></xref>) to explicitly
      indicate that, when this bit is set, data gleaning must be deactivated.
      This bit is called the G-bit ("Gleaning" flag bit).</t>

      <t><xref target="gflag"></xref> shows the required change to the LISP
      header.</t>

      <t><figure anchor="gflag" title="G-bit in the LISP Header">
          <artwork><![CDATA[OLD:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|G|flg|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t>The "flg" bits are reserved bits for future assignment as additional
      flag bits. These additional flag bits MUST each be set to zero and MUST
      be ignored upon receipt.</t>

      <t>The description of the remaining fields is the same as in <xref
      target="RFC6830"></xref>.</t>
    </section>

    <section title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6833"></xref>
      and <xref target="RFC6830"></xref> should be taken into account.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not make any request to IANA.</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.6833'
?>

      <?rfc include='reference.RFC.2119'?>
    </references>

    <references title="Informative references">
      <?rfc include='reference.RFC.6830'?>

      <?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>
    </references>
  </back>
</rfc>
