Network Working Group A. Retana
Internet-Draft Hewlett-Packard Co.
Updates: RFC5820 (if approved) S. Ratliff
Intended status: Experimental Cisco Systems, Inc.
Expires: October 30, 2011 April 28, 2011
Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks
draft-retana-ospf-manet-single-hop-01
Abstract
This document describes the use of the OSPF-MANET interface in
single-hop broadcast networks. It includes a mechanism to
deterministically reduce the number of adjacencies using Smart
Peering and other considerations due to the nature of the network.
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 October 30, 2011.
Copyright Notice
Copyright (c) 2011 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 October 30, 2011 [Page 1]
Internet-Draft MANET Single-Hop Broadcast Networks April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . . 3
1.2. MANET Interface Considerations . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
3. Use of Router Priority . . . . . . . . . . . . . . . . . . . . 4
4. Unsynchronized Adjacencies . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Changes from version -00 . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Retana & Ratliff Expires October 30, 2011 [Page 2]
Internet-Draft MANET Single-Hop Broadcast Networks April 2011
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 fixed 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 October 30, 2011 [Page 3]
Internet-Draft MANET Single-Hop Broadcast Networks April 2011
1.2. MANET Interface Considerations
The operation of the MANET interface doesn't change when implemented
on a single-hop broadcast interface. However, some of the proposed
enhancements are not needed; explicitly, Incremental Hellos and
Overlapping Relays are not required due to the connectivity model.
If Overlapping Relays are used, then the A-bit SHOULD NOT be set by
any of the nodes: the result is an empty set of Active Overlapping
Relays.
Smart Peering 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
STP. 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. Section 3
explains the use of Router Priority to create a deterministic
mechanism to select which nodes to form FULL adjacencies with.
Section 4 explains the operation with unsynchronized adjacencies.
The operation described in this document uses already defined
mechanisms and requires no additional on-the-wire changes.
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. Use of Router Priority
The Smart Peering state machine [RFC5820] 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.
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:
Retana & Ratliff Expires October 30, 2011 [Page 4]
Internet-Draft MANET Single-Hop Broadcast Networks April 2011
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
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 Wait Time [RFC2328] 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.
4. 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.
Retana & Ratliff Expires October 30, 2011 [Page 5]
Internet-Draft MANET Single-Hop Broadcast Networks April 2011
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.
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. In fact, due to the application in
fixed networks, some of the concerns may actually be reduced.
7. Acknowledgements
The authors would like to thank Anton Smirnov, Jeffrey Zhang and Alia
Atlas for their comments.
8. References
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.
Appendix A. Changes from version -00
Retana & Ratliff Expires October 30, 2011 [Page 6]
Internet-Draft MANET Single-Hop Broadcast Networks April 2011
o Updated author information.
o Explicitly recommended the maximum number of adjacencies to be set
to 2.
o Updated ack section.
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 October 30, 2011 [Page 7]