Network Working Group                                          A. Retana
Internet-Draft                                       Hewlett-Packard Co.
Updates: RFC5820 (if approved)                                S. Ratliff
Intended status: Experimental                        Cisco Systems, Inc.
Expires: December 31, 2012                                 June 29, 2012


    Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks
                 draft-ietf-ospf-manet-single-hop-or-00

Abstract

   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.

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 December 31, 2012.

Copyright Notice

   Copyright (c) 2012 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.



Retana & Ratliff        Expires December 31, 2012               [Page 1]


Internet-Draft     MANET Single-Hop Broadcast Networks         June 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Single-Hop Broadcast Networks . . . . . . . . . . . . . . . 3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
   3.  Single-Hop Network Operation  . . . . . . . . . . . . . . . . . 4
     3.1.  Use of Router Priority  . . . . . . . . . . . . . . . . . . 4
     3.2.  Unsynchronized Adjacencies  . . . . . . . . . . . . . . . . 5
   4.  Single-Hop Network Detection  . . . . . . . . . . . . . . . . . 6
     4.1.  Transition from multi-hop to single-hop mode  . . . . . . . 6
     4.2.  Transition from single-hop to multi-hop mode  . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

































Retana & Ratliff        Expires December 31, 2012               [Page 2]


Internet-Draft     MANET Single-Hop Broadcast Networks         June 2012


1.  Introduction

   The OSPF-MANET interface [RFC5820] uses the point-to-multipoint
   adjacency model over a broadcast media to allow the following:

   o  all router-to-router connections are treated as if they were
      point-to-point links.

   o  Link metric can be set on a per-neighbor basis.

   o  Broadcast and multicast can be accomplished through the Layer 2
      broadcast capabilities of the media.

   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 which may have a different cost
   associated with any pair of nodes.

   This document describes the use of the MANET interface in single-hop
   broadcast networks.

1.1.  Single-Hop Broadcast Networks

   The OSPF extensions for MANET networks 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.

   Furthermore, the single-hop networks considered may have different
   link metrics associated to the connectivity between a specific pair
   of neighbors.  The OSPF broadcast model [RFC2328] can't accurately
   describe these differences.  A point-to-multipoint description is
   more appropriate given that each node can reach every other node
   directly.

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

   o  direct connectivity between all the nodes

   o  different link metrics may exist per-neighbor

   o  it has broadcast/multicast capabilities




Retana & Ratliff        Expires December 31, 2012               [Page 3]


Internet-Draft     MANET Single-Hop Broadcast Networks         June 2012


2.  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 [RFC2119].


3.  Single-Hop Network Operation

   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: the result is an empty
   set of Active Overlapping Relays.

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

3.1.  Use of Router Priority

   Smart Peering [RFC5820] 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 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.

   The Smart Peering state machine 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.

   The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3
   [RFC5340]) is used in the election of the (Backup) Designated Router,
   and can be configured only in broadcast and NBMA interfaces.  The
   MANET interface is a broadcast interface using the point-to-
   multipoint adjacency model, which means that no (Backup) Designated
   Router is elected.  For its use with the MANET interface, the Router
   Priority is defined as:

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



Retana & Ratliff        Expires December 31, 2012               [Page 4]


Internet-Draft     MANET Single-Hop Broadcast Networks         June 2012


         Router Priority takes precedence.  If there is still a tie, the
         router with the highest Router ID takes precedence.

   The heuristic for the smart peering state machine is described as:

               (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 |      |
             |        ''''''''''''`'''/'''''''\''''''''''''''''''      |
             |                       /         \                       |
             '`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''

                          Smart Peering Algorithm

   In order to avoid churn in the selection and establishment of the
   adjacencies, every router SHOULD wait until the ModeChange timer
   (Section 4) expires before running the Smart Peering state machine.
   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.

   It is RECOMMENDED that the maximum number of adjacencies be set to 2.

3.2.  Unsynchronized Adjacencies

   An unsynchronized adjacency [RFC5820] 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
   advertized as FULL by at least one Smart Peer.

   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



Retana & Ratliff        Expires December 31, 2012               [Page 5]


Internet-Draft     MANET Single-Hop Broadcast Networks         June 2012


   received.


4.  Single-Hop Network Detection

   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 corresponds to the set of the remaining 1-hop neighbors,
   then the interface is a single-hop network; this condition is called
   the Single-Hop Condition.

   A new field is introduced in the MANET interface data structure.  The
   name of the field is SingleHop, and it is a flag indicating that the
   interface MAY operate in single-hop mode (as described in Section 3).
   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.

   A new timer is introduced to guide the transition of the interface
   from/to multi-hop mode (which is the default mode described in
   [RFC5820]) to/from single-hop mode:

   o  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 Wait Time [RFC2328].

   The following sections describe the steps to be taken to transition
   between interface modes.

4.1.  Transition from multi-hop to single-hop mode

   Detection of the Single-Hop Condition triggers the transition into
   single-hop mode by setting both the SingleHop flag and the ModeChange
   timer.

   Once the ModeChange timer expires, the heuristic defined in
   Section 3.1 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 simplified reachabiity check (Section 3.2) can be
   verified.






Retana & Ratliff        Expires December 31, 2012               [Page 6]


Internet-Draft     MANET Single-Hop Broadcast Networks         June 2012


4.2.  Transition from single-hop to multi-hop mode

   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:

   o  an increase in the set of 1-hop neighbors, without the
      corresponding increase of the 2-hop neighborhood

   o  a decrease of the 2-hop neighborhood while maintaining all the
      previous 1-hop neighbors

   Once the ModeChange timer expires, the multi-hop operation described
   in [RFC5820] takes over.

   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 Section 3.1 MAY be executed to
   optimize the set of adjacencies on the interface.

   In the case that a node joins the interface, the Designated Router
   and Backup Designated Router fields in the Hello packet [RFC2328] MAY
   be used to inform the new node of the identity (Router ID) of the
   current Smart Peers (and avoid the optimization).


5.  IANA Considerations

   This document includes no request to IANA.


6.  Security Considerations

   No new security concerns beyond the ones expressed in [RFC5820] are
   introduced in this document.


7.  Acknowledgements

   The authors would like to thank Anton Smirnov, Jeffrey Zhang, Alia
   Atlas, Juan Antonio Cordero and Richard Ogier for their comments.


8.  References






Retana & Ratliff        Expires December 31, 2012               [Page 7]


Internet-Draft     MANET Single-Hop Broadcast Networks         June 2012


8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

8.2.  Informative References

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

   [RFC5820]  Roy, A. and M. Chandra, "Extensions to OSPF to Support
              Mobile Ad Hoc Networking", RFC 5820, March 2010.


Authors' Addresses

   Alvaro Retana
   Hewlett-Packard Co.
   2610 Wycliff Road
   Raleigh, NC  27607
   USA

   Email: alvaro.retana@hp.com


   Stan Ratliff
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC  27709
   USA

   Email: sratliff@cisco.com

















Retana & Ratliff        Expires December 31, 2012               [Page 8]