From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7137.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc7137.txt (limited to 'doc/rfc/rfc7137.txt') diff --git a/doc/rfc/rfc7137.txt b/doc/rfc/rfc7137.txt new file mode 100644 index 0000000..d488201 --- /dev/null +++ b/doc/rfc/rfc7137.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Retana +Request for Comments: 7137 S. Ratliff +Updates: 5820 Cisco Systems, Inc. +Category: Experimental February 2014 +ISSN: 2070-1721 + + + Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks + +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. + + This document updates RFC 5820. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7137. + + + + + + + + + + + + + + + + +Retana & Ratliff Experimental [Page 1] + +RFC 7137 MANET Single-Hop Broadcast Networks February 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 + 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. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 7.2. Informative References . . . . . . . . . . . . . . . . . 8 + +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 The 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. + + + + + + + +Retana & Ratliff Experimental [Page 2] + +RFC 7137 MANET Single-Hop Broadcast Networks February 2014 + + + 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. + + This document updates [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. + +1.1. Single-Hop Broadcast Networks + + 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. + + 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 that may exist per-neighbor + + o broadcast/multicast capabilities + +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]. + + + + + + + + +Retana & Ratliff Experimental [Page 3] + +RFC 7137 MANET Single-Hop Broadcast Networks February 2014 + + +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, so that 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 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. + + 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 [RFC5820]. + + 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 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: + + 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. + + + + + + + + +Retana & Ratliff Experimental [Page 4] + +RFC 7137 MANET Single-Hop Broadcast Networks February 2014 + + + The heuristic for the state machine for smart peering 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 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". + + 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 + advertised 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 + received. + + + + +Retana & Ratliff Experimental [Page 5] + +RFC 7137 MANET Single-Hop Broadcast Networks February 2014 + + +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 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. + + 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 + 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 reachability check (Section 3.2) can be + verified. + + + + + + + + + +Retana & Ratliff Experimental [Page 6] + +RFC 7137 MANET Single-Hop Broadcast Networks February 2014 + + +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. Security Considerations + + No new security concerns beyond the ones expressed in [RFC5820] are + introduced in this document. + +6. Acknowledgements + + The authors would like to thank Anton Smirnov, Jeffrey Zhang, Alia + Atlas, Juan Antonio Cordero, Richard Ogier, and Christer Holmberg for + their comments. + +7. References + +7.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. + + [RFC5820] Roy, A. and M. Chandra, "Extensions to OSPF to Support + Mobile Ad Hoc Networking", RFC 5820, March 2010. + + + +Retana & Ratliff Experimental [Page 7] + +RFC 7137 MANET Single-Hop Broadcast Networks February 2014 + + +7.2. Informative References + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, July 2008. + +Authors' Addresses + + Alvaro Retana + Cisco Systems, Inc. + 7025 Kit Creek Rd. + Research Triangle Park, NC 27709 + USA + + EMail: aretana@cisco.com + + + Stan Ratliff + Cisco Systems, Inc. + 7025 Kit Creek Rd. + Research Triangle Park, NC 27709 + USA + + EMail: sratliff@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Retana & Ratliff Experimental [Page 8] + -- cgit v1.2.3