draft-ietf-ospf-manet-single-hop-or-02.txt   draft-ietf-ospf-manet-single-hop-or-03.txt 
Network Working Group A. Retana Network Working Group A. Retana
Internet-Draft S. Ratliff Internet-Draft S. Ratliff
Updates: 5820 (if approved) Cisco Systems, Inc. Updates: 5820 (if approved) Cisco Systems, Inc.
Intended status: Experimental May 13, 2013 Intended status: Experimental November 6, 2013
Expires: November 14, 2013 Expires: May 10, 2014
Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks
draft-ietf-ospf-manet-single-hop-or-02 draft-ietf-ospf-manet-single-hop-or-03
Abstract Abstract
This document describes the use of the OSPF-MANET interface in This document describes the use of the OSPF-MANET interface in
single-hop broadcast networks. It includes a mechanism to single-hop broadcast networks. It includes a mechanism to
dynamically determine the presence of such a network and specific dynamically determine the presence of such a network and specific
operational considerations due to its nature. operational considerations due to its nature.
This document updates [RFC5820]. This document updates RFC5820.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 14, 2013. This Internet-Draft will expire on May 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . 2 1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
3. Single-Hop Network Operation . . . . . . . . . . . . . . . . 3 3. Single-Hop Network Operation . . . . . . . . . . . . . . . . . 4
3.1. Use of Router Priority . . . . . . . . . . . . . . . . . 4 3.1. Use of Router Priority . . . . . . . . . . . . . . . . . . 4
3.2. Unsynchronized Adjacencies . . . . . . . . . . . . . . . 5 3.2. Unsynchronized Adjacencies . . . . . . . . . . . . . . . . 5
4. Single-Hop Network Detection . . . . . . . . . . . . . . . . 5 4. Single-Hop Network Detection . . . . . . . . . . . . . . . . . 6
4.1. Transition from multi-hop to single-hop mode . . . . . . 6 4.1. Transition from multi-hop to single-hop mode . . . . . . . 6
4.2. Transition from single-hop to multi-hop mode . . . . . . 6 4.2. Transition from single-hop to multi-hop mode . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8
A.1. Changes between the -00 and -01 versions. . . . . . . . . 8 A.1. Changes between the -00 and -01 versions. . . . . . . . . . 8
A.2. Changes between the -01 and -02 versions. . . . . . . . . 8 A.2. Changes between the -01 and -02 versions. . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 A.3. Changes between the -02 and -03 versions. . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The OSPF-MANET interface [RFC5820] uses the point-to-multipoint The OSPF-MANET interface [RFC5820] uses the point-to-multipoint
adjacency model over a broadcast media to allow the following: adjacency model over a broadcast media to allow the following:
o all router-to-router connections are treated as if they were o all router-to-router connections are treated as if they were
point-to-point links. point-to-point links.
o Link metric can be set on a per-neighbor basis. o Link metric can be set on a per-neighbor basis.
skipping to change at page 4, line 11 skipping to change at page 4, line 29
This document describes the use of already defined mechanisms and This document describes the use of already defined mechanisms and
requires no additional on-the-wire changes. requires no additional on-the-wire changes.
3.1. Use of Router Priority 3.1. Use of Router Priority
Smart Peering [RFC5820] can be used to reduce the burden of requiring Smart Peering [RFC5820] can be used to reduce the burden of requiring
a full mesh of adjacencies. In short, a new adjacency is not a full mesh of adjacencies. In short, a new adjacency is not
required if reachability to the node is already available through the required if reachability to the node is already available through the
existing SPT. In general, the reachability is verified on a first- existing SPT. In general, the reachability is verified on a first-
come-first-served basis; i.e. in a typical network, the neighbors 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 with which a FULL adjacency is set up depend on the order of
discovery. discovery.
The Smart Peering state machine allows for the definition of The Smart Peering state machine allows for the definition of
heuristics, beyond the SPT reachability, to decide whether or not it heuristics, beyond the SPT reachability, to decide whether or not it
considers a new adjacency to be of value. This section describes one 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 such heuristic to be used in Step (3) of the state machine, in place
of the original one. of the original one.
The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3 The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3
skipping to change at page 5, line 5 skipping to change at page 5, line 9
Router Priority Router Priority
An 8-bit unsigned integer. Used to determine the precedence of An 8-bit unsigned integer. Used to determine the precedence of
which router(s) to establish a FULL adjacency with during the which router(s) to establish a FULL adjacency with during the
Smart Peering selection process. When more than one router Smart Peering selection process. When more than one router
attached to a network is present, the one with the highest attached to a network is present, the one with the highest
Router Priority takes precedence. If there is still a tie, the Router Priority takes precedence. If there is still a tie, the
router with the highest Router ID takes precedence. router with the highest Router ID takes precedence.
The heuristic for the smart peering state machine is described as: The heuristic for the smart peering state machine is described as:
(3) | (3) |
,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''| ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
| ............................ | | ............................ |
| |Determine if the number of| | | |Determine if the number of| |
| |existing adjacencies is < | | | |existing adjacencies is < | |
| |the maximum configured | | | |the maximum configured | |
| |value | | | |value | |
| '`'''''''\'''''''''''''''/'' | | '`'''''''\'''''''''''''''/'' |
| \ / | | \ / |
| ................\.........../.............. | | ................\.........../.............. |
| |Determine if the neighbor has the highest| | | |Determine if the neighbor has the highest| |
| |(Router Priority, Router ID) combination | | | |(Router Priority, Router ID) combination | |
| ''''''''''''`'''/'''''''\'''''''''''''''''' | | ''''''''''''`'''/'''''''\'''''''''''''''''' |
| / \ | | / \ |
'`'''''''''''''''''''''/'''''''''''\''''''''''''''''''''''' '`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
Smart Peering Algorithm Smart Peering Algorithm
In order to avoid churn in the selection and establishment of the In order to avoid churn in the selection and establishment of the
adjacencies, every router SHOULD wait until the ModeChange timer adjacencies, every router SHOULD wait until the ModeChange timer
(Section 4) expires before running the Smart Peering state machine. (Section 4) expires before running the Smart Peering state machine.
Note that this wait should cause the selection process to consider Note that this wait should cause the selection process to consider
all the nodes on the link, instead of being triggered based on all the nodes on the link, instead of being triggered based on
receiving a Hello message from a potential neighbor. The nodes receiving a Hello message from a potential neighbor. The nodes
selected using this process are referred to simply as Smart Peers. selected using this process are referred to simply as Smart Peers.
skipping to change at page 8, line 22 skipping to change at page 8, line 33
o Updated contact information. o Updated contact information.
A.2. Changes between the -01 and -02 versions. A.2. Changes between the -01 and -02 versions.
o Indicated the nature of the RFC5820 update. o Indicated the nature of the RFC5820 update.
o Clarified the Single-Hop Condition and the SingleHop flag. o Clarified the Single-Hop Condition and the SingleHop flag.
o Reshuffled the references. o Reshuffled the references.
A.3. Changes between the -02 and -03 versions.
No changes..just a refresh.
Authors' Addresses Authors' Addresses
Alvaro Retana Alvaro Retana
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: aretana@cisco.com Email: aretana@cisco.com
Stan Ratliff Stan Ratliff
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: sratliff@cisco.com Email: sratliff@cisco.com
 End of changes. 10 change blocks. 
42 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/