<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc rfcedstyle="yes" ?>

<rfc number="7137" category="exp" updates="5820"
     ipr="trust200902" submissionType="IETF" consensus="yes">

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="MANET Single-Hop Broadcast
Networks">Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks</title>

    <author fullname="Alvaro Retana" initials="A." surname="Retana">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>7025 Kit Creek Rd.</street>

          <!-- Reorder these if your country does things differently -->

          <city>Research Triangle Park</city>

          <region>NC</region>

          <code>27709</code>

          <country>USA</country>
        </postal>

        <email>aretana@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Stan Ratliff" initials="S." surname="Ratliff">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>7025 Kit Creek Rd.</street>

          <!-- Reorder these if your country does things differently -->

          <city>Research Triangle Park</city>

          <region>NC</region>

          <code>27709</code>

          <country>USA</country>
        </postal>

        <email>sratliff@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="February" year="2014"/>

    <!-- Meta-data Declarations -->

    <area>Routing</area>

    <keyword>OSPF, MANET, single-hop broadcast</keyword>

    <abstract>
      <t>This document describes the use of the 
     OSPF-MANET interface in
      single-hop broadcast networks. It includes a mechanism to dynamically
      determine the presence of such a network and specific operational
      considerations due to its nature.</t>

      <t>This document updates RFC 5820.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" toc="default">
      <t>The <xref format="default" pageno="false" target="RFC5820">OSPF-MANET
      interface</xref> uses the point-to-multipoint adjacency model over a
      broadcast media to allow the following:</t>

      <t><list style="symbols">
          <t>All router-to-router connections are treated as if they were
          point-to-point links.</t>

          <t>The link metric can be set on a per-neighbor basis.</t>

          <t>Broadcast and multicast can be accomplished through the Layer 2
          broadcast capabilities of the media.</t>
        </list></t>

      <t>It is clear that the characteristics of the MANET interface can also
      be beneficial in other types of network deployments -- specifically, in
      single-hop broadcast capable networks that may have a different cost
      associated with any pair of nodes.</t>

      <t>This document updates <xref target="RFC5820"/> by describing the use
      of the MANET interface in single-hop broadcast networks; this consists
      of its simplified operation by not requiring the use of overlapping
      relays as well as introducing a new heuristic for smart peering using
      the Router Priority.</t>

      <section title="Single-Hop Broadcast Networks" toc="default">
        <t>The OSPF extensions for MANETs assume the ad hoc formation
        of a network over bandwidth-constrained wireless links, where packets
        may traverse several intermediate nodes before reaching their
        destination (multi-hop paths on the interface). By contrast, a
        single-hop broadcast network (as considered in this document) is one
        that is structured in such a way that all the nodes in it are directly
        connected to each other. An Ethernet interface is a good example of
        the connectivity model.</t>

        <t>Furthermore, the single-hop networks considered may have different
        link metrics associated to the connectivity between a specific pair of
        neighbors. The <xref format="default" pageno="false"
        target="RFC2328">OSPF broadcast model</xref> can't accurately describe
        these differences. A point-to-multipoint description is more
        appropriate given that each node can reach every other node
        directly.</t>

        <t>In summary, the single-hop broadcast interfaces considered in this
        document have the following characteristics:</t>

        <t><list style="symbols">
            <t>direct connectivity between all the nodes</t>

            <t>different link metrics that may exist per-neighbor</t>

            <t>broadcast/multicast capabilities</t>
          </list></t>
      </section>
    </section>

    <section title="Requirements Language" toc="default">
      <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 format="default"
      pageno="false" target="RFC2119"/>.</t>
    </section>

    <section anchor="SingleHop" title="Single-Hop Network Operation"
             toc="default">
      <t>The operation of the MANET interface doesn't change when implemented
      on a single-hop broadcast interface. However, the operation of some of
      the proposed enhancements can be simplified. Explicitly, the Overlapping
      Relay Discovery Process SHOULD NOT be executed, and the A-bit SHOULD NOT
      be set by any of the nodes, so that the result is
   an empty set of Active Overlapping Relays.</t>

      <t>This document describes the use of already defined mechanisms and
      requires no additional on-the-wire changes.</t>

      <section anchor="RtrPri" title="Use of Router Priority" toc="default">
        <t><xref format="default" pageno="false" target="RFC5820">Smart
        peering</xref> can be used to reduce the burden of requiring a full
        mesh of adjacencies. In short, a new adjacency is not required if
        reachability to the node is already available through the existing
        shortest path tree (SPT). In general, the reachability is verified on a
        first-come-first-served basis; i.e., in a typical network, the
        neighbors with which a FULL adjacency is set up depend on the order of
        discovery.</t>

        <t>The state machine for smart peering allows for the definition of
        heuristics, beyond the SPT reachability, to decide whether or not it
        considers a new adjacency to be of value. This section describes one
        such heuristic to be used in Step (3) of the state machine, in place
        of the original one in Section 3.5.3.2 of <xref target="RFC5820"/>.</t>

        <t>The Router Priority (as defined in <xref format="default"
        pageno="false" target="RFC2328">OSPFv2</xref> and <xref
        format="default" pageno="false" target="RFC5340">OSPFv3</xref>) is
        used in the election of the (Backup) Designated Router, and can be
        configured only in broadcast and Non-Broadcast Multi-Access (NBMA) interfaces. The MANET interface
        is a broadcast interface using the point-to-multipoint adjacency
        model; this means that no (Backup) Designated Router is elected. For
        its use with the MANET interface, the Router Priority is defined
        as:

<list hangIndent="6" style="hanging">
            <t hangText="Router Priority"><vspace blankLines="0"/>

            An 8-bit
            unsigned integer. Used to determine the precedence of which
            router(s) to establish a FULL adjacency with during the Smart
            Peering selection process. When more than one router attached to a
            network is present, the one with the highest Router Priority takes
            precedence. If there is still a tie, the router with the highest
            Router ID takes precedence.</t>
          </list></t>

        <figure align="left" alt="" height="" suppress-title="false"
                title="Smart Peering Algorithm" width="">
          <preamble>The heuristic for the state machine for smart peering is
          described as:</preamble>

          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[
        (3)                      |
      ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
      |             ............................                |
      |             |Determine if the number of|                |
      |             |existing adjacencies is < |                |
      |             |the maximum configured    |                |
      |             |value                     |                |
      |             '`'''''''\'''''''''''''''/''                |
      |                       \             /                   |
      |        ................\.........../..............      |
      |        |Determine if the neighbor has the highest|      |
      |        |(Router Priority, Router ID) combination |      |
      |        ''''''''''''`'''/'''''''\''''''''''''''''''      |
      |                       /         \                       |
      '`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
]]></artwork>
        </figure>

        <t>In order to avoid churn in the selection and establishment of the
        adjacencies, every router SHOULD wait until the <xref format="default"
        pageno="false" target="Detect">ModeChange timer</xref> expires before
        running the state machine for smart peering. Note that this wait should
        cause the selection process to consider all the nodes on the link,
        instead of being triggered based on receiving a Hello message from a
        potential neighbor. The nodes selected using this process are referred
        to simply as "smart peers".</t>

        <t>It is RECOMMENDED that the maximum number of adjacencies be set to
        2.</t>
      </section>

      <section anchor="Unsync" title="Unsynchronized Adjacencies"
               toc="default">
        <t>An <xref format="default" pageno="false"
        target="RFC5820">unsynchronized adjacency</xref> is one for which the
        database synchronization is postponed, but that is announced as FULL
        because SPT reachability can be proven. A single-hop broadcast network
        has a connectivity model in which all the nodes are directly connected
        to each other. This connectivity results in a simplified reachability
        check through the SPT: the adjacency to a specific peer MUST be
        advertised as FULL by at least one smart peer.</t>

        <t>The single-hop nature of the interface allows then the
        advertisement of the reachable adjacencies as FULL without additional
        signaling. Flooding SHOULD be enabled for all the unsynchronized
        adjacencies to take advantage of the broadcast nature of the media. As
        a result, all the nodes in the interface will be able to use all the
        LSAs received.</t>
      </section>
    </section>

    <section anchor="Detect" title="Single-Hop Network Detection"
             toc="default">
      <t>A single-hop network is one in which all the nodes are directly
      connected. Detection of such an interface can be easily done at every
      node by comparing the speaker's 1-hop neighbors with its 2-hop
      neighborhood. If for every 1-hop neighbor, the set of 2-hop neighbors
      contains the whole set of the remaining 1-hop neighbors, then the
      interface is a single-hop network; this condition is called the
      Single-Hop Condition.</t>

      <t>A new field is introduced in the MANET interface data structure. The
      name of the field is SingleHop, and it is a flag indicating whether the
      interface is operating in single-hop mode (as described in <xref
      format="default" pageno="false" target="SingleHop"/>). The SingleHop
      flag is set when the node meets the Single-Hop Condition on the
      interface. If the Single-Hop Condition is no longer met, then the
      SingleHop flag MUST be cleared.</t>

      <t>A new timer is introduced to guide the transition of the interface
      from/to multi-hop mode (which is the default mode described in <xref
      format="default" pageno="false" target="RFC5820"/>) to/from single-hop
      mode:</t>

      <t><list style="symbols">
          <t>ModeChange: Every time a node changes the state of the SingleHop
          flag for the interface, the corresponding ModeChange timer MUST be
          set. The ModeChange timer represents the length of time in seconds
          that an interface SHOULD wait before changing between multi-hop and
          single-hop modes. It is RECOMMENDED that this timer be set to <xref
          format="default" pageno="false" target="RFC2328">Wait
          Time</xref>.</t>
        </list></t>

      <t>The following sections describe the steps to be taken to transition
      between interface modes.</t>

      <section title="Transition from Multi-Hop to Single-Hop Mode"
               toc="default">
        <t>Detection of the Single-Hop Condition triggers the transition into
        single-hop mode by setting both the SingleHop flag and the ModeChange
        timer.</t>

        <t>Once the ModeChange timer expires, the heuristic defined in <xref
        format="default" pageno="false" target="RtrPri"/> MAY be executed to
        optimize the set of adjacencies on the interface. Note that an
        adjacency MUST NOT transition from FULL to 2-Way unless the <xref
        format="default" pageno="false" target="Unsync">simplified reachability
        check</xref> can be verified.</t>
      </section>

      <section title="Transition from Single-Hop to Multi-Hop Mode"
               toc="default">
        <t>Not meeting the Single-Hop Condition triggers the transition into
        multi-hop mode by clearing the SingleHop flag and setting the
        ModeChange timer. The A-bit MUST be set if the Single-Hop condition is
        no longer met because of one of the following cases:</t>

        <t><list style="symbols">
            <t>an increase in the set of 1-hop neighbors, without the
            corresponding increase of the 2-hop neighborhood</t>

            <t>a decrease of the 2-hop neighborhood while maintaining all the
            previous 1-hop neighbors</t>
          </list></t>

        <t>Once the ModeChange timer expires, the multi-hop operation
        described in <xref format="default" pageno="false" target="RFC5820"/>
        takes over.</t>

        <t>Note that the cases listed above may result in the interface either
        gaining or losing a node before the ModeChange timer expires. In both
        cases, the heuristic defined in <xref format="default" pageno="false"
        target="RtrPri"/> MAY be executed to optimize the set of adjacencies
        on the interface.</t>

        <t>In the case that a node joins the interface, the Designated Router
        and Backup Designated Router fields in the Hello packet <xref
        format="default" pageno="false" target="RFC2328"/> MAY be used to
        inform the new node of the identity (Router ID) of the current smart
        peers (and avoid the optimization).</t>
      </section>
    </section>

    <section title="Security Considerations" toc="default">
      <t>No new security concerns beyond the ones expressed in <xref
      format="default" pageno="false" target="RFC5820"/> are introduced in
      this document.</t>
    </section>

    <section title="Acknowledgements" toc="default">
      <t>The authors would like to thank Anton Smirnov, Jeffrey Zhang, Alia
      Atlas, Juan Antonio Cordero, Richard Ogier, and Christer Holmberg for
      their comments.</t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Normative References">

      <?rfc include="reference.RFC.2328.xml"?>

      <?rfc include="reference.RFC.2119.xml"?>

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

    <references title="Informative References">
      <?rfc include="reference.RFC.5340.xml"?>
    </references>

  </back>
</rfc>
