Internet Engineering Task Force (IETF)                       A. Roy, Ed.
Request for Comments: 5820                                 Cisco Systems
Category: Experimental                                   M. Chandra, Ed.
ISSN: 2070-1721                                               March 2010
        
Internet Engineering Task Force (IETF)                       A. Roy, Ed.
Request for Comments: 5820                                 Cisco Systems
Category: Experimental                                   M. Chandra, Ed.
ISSN: 2070-1721                                               March 2010
        

Extensions to OSPF to Support Mobile Ad Hoc Networking

OSPF的扩展以支持移动自组织网络

Abstract

摘要

This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs.

本文档描述了支持移动自组织网络(MANET)的OSPF扩展。这些扩展称为OSPF-OR(OSPF重叠中继),包括链路本地信令(LLS)机制、OSPF-MANET接口、一种仅通过传输增量状态更改来减小Hello数据包大小的简单技术,以及一种优化路由更新泛洪的方法。OSPF-OR还提供了一种减少不必要邻接的方法,以支持更大的MANET。

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.

本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

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/rfc5820.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc5820.

Copyright Notice

版权公告

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2010 IETF信托基金和确定为文件作者的人员。版权所有。

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.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下,不得在IETF标准流程之外修改本文件,也不得在IETF标准流程之外创建其衍生作品,除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。

Table of Contents

目录

   1. Introduction ....................................................4
      1.1. Problem Statement ..........................................4
      1.2. Motivation for Extending OSPF to Support MANETs ............5
   2. Requirements Notation ...........................................5
   3. Proposed Enhancements ...........................................5
      3.1. OSPF-MANET Interface .......................................7
           3.1.1. Interface Operation .................................8
           3.1.2. LSA Formats and Examples ............................8
      3.2. Incremental OSPF-MANET Hellos .............................12
           3.2.1. The I Option Bit ...................................12
           3.2.2. State Check Sequence TLV (SCS TLV) .................12
           3.2.3. Neighbor Drop TLV ..................................13
           3.2.4. Request From TLV (RF TLV) ..........................14
           3.2.5. Full State For TLV (FSF TLV) .......................14
           3.2.6. Neighbor Adjacencies ...............................15
           3.2.7. Sending Hellos .....................................16
           3.2.8. Receiving Hellos ...................................17
           3.2.9. Interoperability ...................................19
           3.2.10. Support for OSPF Graceful Restart .................19
      3.3. Optimized Flooding (Overlapping Relays) ...................20
           3.3.1. Operation Overview .................................20
           3.3.2. Determination of Overlapping Relays ................21
           3.3.3. Terminology ........................................21
           3.3.4. Overlapping Relay Discovery Process ................22
           3.3.5. The F Option Bit ...................................23
           3.3.6. Active Overlapping Relay TLV (AOR TLV) .............23
           3.3.7. Willingness TLV ....................................24
           3.3.8. Flooding and Relay Decisions .......................25
           3.3.9. Intelligent Transmission of Link State
                  Acknowledgments ....................................26
           3.3.10. Important Timers ..................................27
           3.3.11. Miscellaneous Protocol Considerations .............28
           3.3.12. Interoperability ..................................28
      3.4. New Bits in LLS Type 1 Extended Options and Flags .........29
      3.5. Smart Peering .............................................29
           3.5.1. Rationale for Smart Peering ........................29
           3.5.2. Previous Related Work ..............................30
           3.5.3. Smart Peering Solution .............................30
           3.5.4. Advertising 2-Way Links in Router-LSAs .............33
   4. Security Considerations ........................................36
   5. IANA Considerations ............................................38
   6. Contributors ...................................................39
   7. Acknowledgments ................................................39
   8. References .....................................................39
      8.1. Normative References ......................................39
      8.2. Informative References ....................................40
        
   1. Introduction ....................................................4
      1.1. Problem Statement ..........................................4
      1.2. Motivation for Extending OSPF to Support MANETs ............5
   2. Requirements Notation ...........................................5
   3. Proposed Enhancements ...........................................5
      3.1. OSPF-MANET Interface .......................................7
           3.1.1. Interface Operation .................................8
           3.1.2. LSA Formats and Examples ............................8
      3.2. Incremental OSPF-MANET Hellos .............................12
           3.2.1. The I Option Bit ...................................12
           3.2.2. State Check Sequence TLV (SCS TLV) .................12
           3.2.3. Neighbor Drop TLV ..................................13
           3.2.4. Request From TLV (RF TLV) ..........................14
           3.2.5. Full State For TLV (FSF TLV) .......................14
           3.2.6. Neighbor Adjacencies ...............................15
           3.2.7. Sending Hellos .....................................16
           3.2.8. Receiving Hellos ...................................17
           3.2.9. Interoperability ...................................19
           3.2.10. Support for OSPF Graceful Restart .................19
      3.3. Optimized Flooding (Overlapping Relays) ...................20
           3.3.1. Operation Overview .................................20
           3.3.2. Determination of Overlapping Relays ................21
           3.3.3. Terminology ........................................21
           3.3.4. Overlapping Relay Discovery Process ................22
           3.3.5. The F Option Bit ...................................23
           3.3.6. Active Overlapping Relay TLV (AOR TLV) .............23
           3.3.7. Willingness TLV ....................................24
           3.3.8. Flooding and Relay Decisions .......................25
           3.3.9. Intelligent Transmission of Link State
                  Acknowledgments ....................................26
           3.3.10. Important Timers ..................................27
           3.3.11. Miscellaneous Protocol Considerations .............28
           3.3.12. Interoperability ..................................28
      3.4. New Bits in LLS Type 1 Extended Options and Flags .........29
      3.5. Smart Peering .............................................29
           3.5.1. Rationale for Smart Peering ........................29
           3.5.2. Previous Related Work ..............................30
           3.5.3. Smart Peering Solution .............................30
           3.5.4. Advertising 2-Way Links in Router-LSAs .............33
   4. Security Considerations ........................................36
   5. IANA Considerations ............................................38
   6. Contributors ...................................................39
   7. Acknowledgments ................................................39
   8. References .....................................................39
      8.1. Normative References ......................................39
      8.2. Informative References ....................................40
        
1. Introduction
1. 介绍

Mobile ad hoc networks (MANETs) have been an area of study for some time within various working groups and areas within the IETF, various military branches, and various government agencies. Recently, networks with mobile ad hoc requirements have been proposed and are being seriously considered for deployment in the near term, which means the concepts and research now need to be applied to deployed networks. Towards that end, this document applies many of the principles and concepts learned through prior work to [OSPFv3], along with new concepts based on current requirements.

一段时间以来,移动自组织网络(MANET)一直是IETF、各军事部门和各政府机构内各工作组和领域的研究领域。最近,人们提出了具有移动自组织需求的网络,并正在认真考虑在近期部署,这意味着现在需要将这些概念和研究应用于部署的网络。为此,本文件应用了[OSPFv3]之前工作中学习到的许多原则和概念,以及基于当前需求的新概念。

1.1. Problem Statement
1.1. 问题陈述

MANETs are synonymous with packet radio networks, which have been around since the 1960s in a limited military capacity. With the boom in mobile devices and wireless communications, MANETs are finding scope in commercial and military environments. The aim of these networks is to support robust and efficient communication in a mobile wireless network by incorporating routing functionality into mobile nodes.

移动自组网是分组无线网络的同义词,自20世纪60年代以来,分组无线网络的军事容量有限。随着移动设备和无线通信的蓬勃发展,移动自组网在商业和军事环境中的应用越来越广泛。这些网络的目的是通过将路由功能合并到移动节点中来支持移动无线网络中的健壮和高效通信。

A MANET is an autonomous set of nodes distributed over a wide geographical area that communicate over bandwidth-constrained wireless links. Each node may represent a transmitter, receiver, or relay station with varying physical capabilities. Packets may traverse through several intermediate (relay) nodes before reaching their destination. These networks typically lack infrastructure: nodes are mobile, and there is no central hub or controller; thus, there is no fixed network topology. Moreover, MANETs must contend with a difficult and variable communication environment. Packet transmissions are plagued by the usual problems of radio communication, which include propagation path loss, signal multipath and fading, and thermal noise. These effects vary with terminal movement, which also induces Doppler spreading in the frequency of the transmitted signal. Finally, transmissions from neighboring terminals, known as multi-access interference, hostile jammers, and impulsive interference, e.g., ignition systems, generators, and other non-similar in-band communications, may contribute additional interference.

MANET是一组分布在广泛地理区域的自治节点,通过带宽受限的无线链路进行通信。每个节点可以表示具有不同物理能力的发射机、接收机或中继站。在到达目的地之前,数据包可以穿过几个中间(中继)节点。这些网络通常缺乏基础设施:节点是移动的,没有中央集线器或控制器;因此,没有固定的网络拓扑。此外,移动自组网必须应对复杂多变的通信环境。无线通信的常见问题困扰着分组传输,包括传播路径损耗、信号多径和衰落以及热噪声。这些效应随终端移动而变化,这也会导致发射信号频率中的多普勒扩展。最后,来自相邻终端的传输(称为多址干扰、敌对干扰机和脉冲干扰,例如点火系统、发电机和其他非类似的带内通信)可能造成额外干扰。

Given this nature of MANETs, the existence of a communication link between a pair of nodes is a function of their variable link quality, including signal strength and bandwidth. Thus, routing paths vary, based on environment and the resulting network topology. In such networks, the topology may be stable for periods of time and then suddenly become unpredictable. Since MANETs are typically decentralized systems, there are no central controllers or specially

鉴于移动自组网的这种性质,一对节点之间通信链路的存在是其可变链路质量的函数,包括信号强度和带宽。因此,路由路径根据环境和产生的网络拓扑而变化。在这种网络中,拓扑可能会在一段时间内保持稳定,然后突然变得不可预测。由于移动自组网是典型的分散系统,因此没有中央控制器或专用控制器

designated routers to determine the routing paths as the topology changes. All of the routing decisions and forwarding (relaying) of packets must be done by the nodes themselves, and communication is on a peer-to-peer basis.

指定路由器,以确定拓扑更改时的路由路径。所有的路由决定和数据包的转发(中继)必须由节点自己完成,并且通信是在对等的基础上进行的。

1.2. Motivation for Extending OSPF to Support MANETs
1.2. 扩展OSPF以支持移动自组网的动机

The motivation to extend a standard protocol, OSPF (described in [OSPF] and [OSPFv3]), to operate on MANETs is twofold. The primary reason is for interoperability -- MANET devices need to be able to work when plugged into a wireline network in as many cases as possible. The junction point between a MANET and wire-line network should also be as fluid as possible, allowing a MANET to "plug in" to just about any location within a wire-line network, and also find connectivity, etc., as needed.

扩展标准协议OSPF(在[OSPF]和[OSPFv3]中描述)以在MANET上运行的动机是双重的。主要原因是互操作性——MANET设备在尽可能多的情况下插入有线网络时需要能够工作。MANET和有线网络之间的连接点也应尽可能流动,允许MANET“插入”到有线网络内的任何位置,并根据需要找到连接等。

While routes could be redistributed between two routing protocols, one designed just for wire-line networks, and the other just for MANETs, this adds complexity and overhead to the MANET/wireline interface, increases the odds of an error being introduced between the two domains, and decreases flexibility.

虽然路由可以在两个路由协议之间重新分配,一个路由协议专为有线网络设计,另一个路由协议专为MANET设计,但这增加了MANET/有线接口的复杂性和开销,增加了两个域之间引入错误的几率,并降低了灵活性。

The second motivation is that OSPF is a well-understood and widely deployed routing protocol. This provides a strong basis of experience and skills from which to work. A protocol that is known to work can be extended, rather than developing a new protocol that must then be completely troubleshot, tested, and modified over a number of years. Working with a well-known protocol allows development effort to be placed in a narrowly focused area, rather than rebuilding, from scratch, many things that are already known to work.

第二个动机是,OSPF是一个被广泛理解和部署的路由协议。这为工作提供了坚实的经验和技能基础。一个已知有效的协议可以扩展,而不是开发一个新的协议,该协议必须在若干年内进行彻底的故障诊断、测试和修改。使用一个众所周知的协议可以将开发工作放在一个狭隘的领域,而不是从头开始重建许多已知的工作。

2. Requirements Notation
2. 需求符号

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 RFC 2119 [KEY].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键]中的说明进行解释。

3. Proposed Enhancements
3. 拟议的增强措施

This document proposes modifications to [OSPFv3] to support mobile ad hoc networks (MANETs). Note that it is possible to use the mechanisms defined in Sections 3.2 and 3.3 independently of one another.

本文件建议对[OSPFv3]进行修改,以支持移动自组网(MANET)。请注意,可以相互独立地使用第3.2节和第3.3节中定义的机构。

The challenges with deploying standard [OSPFv3] in a MANET environment fit into two categories. First, traditional link-state routing protocols are designed for a statically configured

在MANET环境中部署标准[OSPFv3]的挑战分为两类。首先,传统的链路状态路由协议是为静态配置的网络设计的

environment. As a result, most of the configuration is done manually when a new router is placed in the network. Thus, OSPF will not function in an environment where routers interconnect and disconnect in somewhat random topologies and combinations. There are modifications that must be made in order for routers running the same protocol to communicate in a heterogeneous and dynamic environment.

环境因此,在网络中放置新路由器时,大部分配置都是手动完成的。因此,OSPF将无法在路由器以某种随机的拓扑和组合进行互连和断开的环境中运行。为了使运行相同协议的路由器在异构和动态环境中通信,必须进行一些修改。

Currently there is no defined interface type that describes a wireless network. Wireless links have characteristics of both multi-access and point-to-multipoint links. Treating wireless links as multi-access does not take into account that not all nodes on the same Layer 2 link have bi-directional connectivity. However, any transmission on a link will reach nodes that are within transmission range. In this way, the link is multi-access due to the fact that two simultaneous transmissions may collide. A new interface type needs to be defined in order to accurately describe this behavior.

目前没有定义描述无线网络的接口类型。无线链路具有多址和点对多点链路的特点。将无线链路视为多址接入并没有考虑到并非同一第2层链路上的所有节点都具有双向连接。但是,链路上的任何传输都将到达传输范围内的节点。这样,由于两个同时传输可能发生冲突,因此链路是多址的。为了准确地描述这种行为,需要定义一种新的接口类型。

The second category of challenges involves scalability. A MANET must transmit more state information to maintain reachability. Therefore, OSPF will need scalability enhancements to support MANETs. While some flooding optimizations are present in OSPF, such as designated router (DR) election, many of these were built under the assumption of a true multi-access network. Wireless networks are not true multi-access networks, because it cannot be assumed that there is 2-way connectivity between everyone on the same Layer 2 link. Therefore, optimizations such as DR election will not perform correctly in MANET networks. Without any further optimizations in link-state flooding, current OSPF would not be able to operate in a highly dynamic environment in which links are constantly being formed and broken. The amount of information that would need to be flooded would overload the network.

第二类挑战涉及可伸缩性。MANET必须传输更多的状态信息以保持可达性。因此,OSPF需要增强可扩展性以支持MANET。虽然OSPF中存在一些洪泛优化,例如指定路由器(DR)选择,但其中许多都是在真正的多址网络的假设下构建的。无线网络不是真正的多址网络,因为不能假设同一层2链路上的每个人之间都存在双向连接。因此,诸如DR选举之类的优化在MANET网络中无法正确执行。如果不进一步优化链路状态洪泛,当前的OSPF将无法在链路不断形成和断开的高度动态环境中运行。需要被淹没的信息量会使网络过载。

Another scalability issue is the periodic transmission of Hello messages. Currently, even if there are no changes in a router's neighbor list, the Hello messages still list all the neighbors on a particular link. For a MANET router, where saving bandwidth and transmission power is a critical issue, the transmission of potentially large Hello messages is particularly wasteful.

另一个可伸缩性问题是Hello消息的定期传输。目前,即使路由器的邻居列表没有变化,Hello消息仍然会列出特定链路上的所有邻居。对于MANET路由器来说,节省带宽和传输功率是一个关键问题,传输潜在的大型Hello消息尤其浪费。

Finally, current routing protocols will form a neighbor relationship with any router on a Layer 2 link that is correctly configured. For MANET routers in a wireless network, this may lead to an excessive number of parallel links between two routers if communication is achieved via multiple interfaces. In a statically configured network, this is not a problem, since the physical topology can be built to prevent excessive redundancy. However, in a dynamic network, there must exist additional mechanisms to prevent too many redundant links. (Note that links between two nodes on different

最后,当前路由协议将与正确配置的第2层链路上的任何路由器形成邻居关系。对于无线网络中的MANET路由器,如果通过多个接口实现通信,则这可能导致两个路由器之间的并行链路过多。在静态配置的网络中,这不是问题,因为可以构建物理拓扑以防止过度冗余。然而,在动态网络中,必须存在额外的机制来防止过多的冗余链路。(请注意,不同节点上的两个节点之间的链接

radio types, different antennae, different channels, etc., are considered different links and not redundant links.) In scalability tests, it has been demonstrated that the presence of too many redundant links will both increase the size of routing updates and cause extra flooding, resulting in even relatively small networks not converging.

无线电类型、不同天线、不同信道等被视为不同链路而非冗余链路。)在可伸缩性测试中,已证明过多冗余链路的存在既会增加路由更新的大小,也会导致额外的泛洪,从而导致即使是相对较小的网络也无法聚合。

3.1. OSPF-MANET Interface
3.1. OSPF-MANET接口

Interfaces are defined as the connection between a router and one of its attached networks [OSPF]. Four types of interfaces have been defined and supported in [OSPF] and [OSPFv3]: broadcast, Non-Broadcast Multi-Access (NBMA), point-to-point, and point-to-multipoint.

接口定义为路由器与其连接的网络之一[OSPF]之间的连接。[OSPF]和[OSPFv3]定义并支持四种类型的接口:广播、非广播多址(NBMA)、点对点和点对多点。

The point-to-multipoint model has been chosen to represent MANET interfaces. (The features designed in this document MAY be included on other interface types as appropriate.) The MANET interface allows the following:

选择点对多点模型来表示MANET接口。(本文件中设计的功能可酌情包括在其他接口类型中。)MANET接口允许以下功能:

o OSPF treats all router-to-router connections over the MANET interface as if they were point-to-point links.

o OSPF将MANET接口上的所有路由器到路由器连接视为点到点链路。

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

o 链路度量可以按每个邻居设置。

o Broadcast and multicast can be accomplished through Layer 2 broadcast or Layer 2 pseudo-broadcast.

o 广播和多播可以通过第二层广播或第二层伪广播来实现。

* The MANET interface supports Layer 2 broadcast if it is able to address a single physical message to all of the attached neighbors. One such example is 802.11.

* 如果MANET接口能够向所有连接的邻居发送单个物理消息,则它支持第2层广播。802.11就是这样一个例子。

* The MANET interface supports Layer 2 pseudo-broadcast if it is able to pick up a packet from the broadcast queue, replicate the packet, and send a copy over each point-to-point link. One such example is Frame Relay.

* 如果MANET接口能够从广播队列中拾取数据包,复制数据包,并通过每个点到点链路发送副本,则MANET接口支持第2层伪广播。一个这样的例子是帧中继。

o An API must be provided for Layer 3 to determine the Layer 2 broadcast capability. Based on the return of the API, OSPF classifies the MANET interfaces into the following three types: MANET broadcast, MANET pseudo-broadcast, and MANET non-broadcast.

o 必须为第3层提供API,以确定第2层的广播能力。OSPF根据API的返回将MANET接口分为以下三种类型:MANET广播、MANET伪广播和MANET非广播。

o Multicast SHOULD be used for OSPF packets. When the MANET interface supports Layer 2 broadcast or pseudo-broadcast, the multicast process is transparent to OSPF. Otherwise, OSPF MUST replicate multicast packets by itself.

o 多播应用于OSPF数据包。当MANET接口支持第二层广播或伪广播时,组播过程对OSPF是透明的。否则,OSPF必须自己复制多播数据包。

3.1.1. Interface Operation
3.1.1. 接口操作

A MANET node has at least one MANET interface. MANET nodes can communicate with each other through MANET interfaces. MANET nodes can communicate with non-MANET routers only through normal interfaces, such as Ethernet, ATM, etc.

MANET节点具有至少一个MANET接口。MANET节点可以通过MANET接口相互通信。MANET节点只能通过以太网、ATM等普通接口与非MANET路由器进行通信。

For scalability reasons, it is not required to configure IPv6 global unicast addresses on MANET interfaces. Instead, a management loopback interface with an IPv6 global unicast address MAY be configured on each MANET node.

出于可扩展性原因,不需要在MANET接口上配置IPv6全局单播地址。相反,可以在每个MANET节点上配置具有IPv6全局单播地址的管理环回接口。

The link state advertisements (LSAs) associated with a MANET interface SHOULD have the DC-bit set in the OSPFv3 Options Field and the DoNotAge bit set in the LS Age field as described in [OSPFv3]. Demand Circuits are an optional feature; hence, the DC-bit setting recommendation level is SHOULD.

与MANET接口相关联的链路状态公告(LSA)应在OSPFv3选项字段中设置DC位,在LS年龄字段中设置DoNotAge位,如[OSPFv3]所述。需求电路是可选功能;因此,DC位设置建议级别应为。

3.1.2. LSA Formats and Examples
3.1.2. LSA格式和示例

LSA formats are specified in [OSPFv3].

LSA格式在[OSPFv3]中有规定。

In order to display example LSAs, a network map is included below. Router names are prefixed with the letters RT, network names with the letter N, and router interface names with the letter I.

为了显示示例LSA,下面包括一个网络图。路由器名称的前缀为字母RT,网络名称的前缀为字母N,路由器接口名称的前缀为字母I。

o Four MANET nodes, RT1, RT2, RT3, and RT4, reside in area 2.

o 四个MANET节点RT1、RT2、RT3和RT4驻留在区域2中。

o RT1 has one MANET interface, I11. Through the interface, RT1 is full-adjacent to RT2, RT3, and RT4.

o RT1有一个MANET接口I11。通过接口,RT1与RT2、RT3和RT4完全相邻。

o RT2 has two MANET interfaces, I21 and I22, and one Ethernet interface, I23. RT2 is full-adjacent to RT1 and RT4 through the interface I21, and full-adjacent to RT4 through the interface I22. Stub network N1 is attached with RT2 through the interface I23.

o RT2有两个MANET接口I21和I22,以及一个以太网接口I23。RT2通过接口I21与RT1和RT4完全相邻,通过接口I22与RT4完全相邻。存根网络N1通过接口I23与RT2相连。

o RT3 has one MANET interface, I31, and is full-adjacent to RT1 through the interface.

o RT3有一个MANET接口I31,通过该接口与RT1完全相邻。

o RT4 has two MANET interfaces, I41 and I42. It is full-adjacent to RT2 through the interface I41, and full-adjacent to RT1 and RT2 through the interface I42.

o RT4有两个MANET接口,I41和I42。它通过接口I41与RT2完全相邻,通过接口I42与RT1和RT2完全相邻。

o Moreover, each MANET node is configured with a management loopback interface.

o 此外,每个MANET节点配置有管理环回接口。

      +---+I11        I21+---+I23   |
      |RT1|-+----------+-|RT2|------|N1
      +---+ |          | +---+      |
      |                |   VI22
      |                |   +
      |                |   |
      |                |   |
      |                |   |
      |                |   |
      |                |   +
      |                |   ^I41
      +---+ |          +---+
      |RT3|-+        +-|RT4|
      +---+I31      I42+---+
        
      +---+I11        I21+---+I23   |
      |RT1|-+----------+-|RT2|------|N1
      +---+ |          | +---+      |
      |                |   VI22
      |                |   +
      |                |   |
      |                |   |
      |                |   |
      |                |   |
      |                |   +
      |                |   ^I41
      +---+ |          +---+
      |RT3|-+        +-|RT4|
      +---+I31      I42+---+
        

The assignment of IPv6 global unicast prefixes to network links is shown below. (Note: No IPv6 global unicast addresses are configured on the MANET interfaces).

将IPv6全局单播前缀分配给网络链路如下所示。(注意:MANET接口上未配置IPv6全局单播地址)。

      -----------------------------------------------------------
      RT1      LOOPBACK      2001:DB8:0001::/64
               I11           n/a
      RT2      LOOPBACK      2001:DB8:0002::/64
               I21           n/a
               I22           n/a
               I23           2001:DB8:0012::/60
      RT3      LOOPBACK      2001:DB8:0003::/64
               I31           n/a
      RT4      LOOPBACK      2001:DB8:0004::/64
               I41           n/a
               I42           n/a
        
      -----------------------------------------------------------
      RT1      LOOPBACK      2001:DB8:0001::/64
               I11           n/a
      RT2      LOOPBACK      2001:DB8:0002::/64
               I21           n/a
               I22           n/a
               I23           2001:DB8:0012::/60
      RT3      LOOPBACK      2001:DB8:0003::/64
               I31           n/a
      RT4      LOOPBACK      2001:DB8:0004::/64
               I41           n/a
               I42           n/a
        

The OSPF interface IDs and the link-local addresses for the router interfaces in the network are shown below. EUIxy represents the 64-bit interface identifier of the interface Ixy, in Modified EUI-64 format [IPV6ADD].

网络中路由器接口的OSPF接口ID和链路本地地址如下所示。EUIxy表示接口Ixy的64位接口标识符,采用修改的EUI-64格式[IPV6ADD]。

      Node    Interface    Interface ID    Link-Local address
      -----------------------------------------------------------
      RT1     LOOPBACK     1               n/a
              I11          2               fe80:0002::EUI11
      RT2     LOOPBACK     1               n/a
              I21          2               fe80:0002::EUI21
              I22          3               fe80:0003::EUI22
              I23          4               fe80:0004::EUI23
      RT3     LOOPBACK     1               n/a
              I31          2               fe80:0002::EUI31
      RT4     LOOPBACK     1               n/a
              I41          2               fe80:0002::EUI41
              I42          3               fe80:0003::EUI42
        
      Node    Interface    Interface ID    Link-Local address
      -----------------------------------------------------------
      RT1     LOOPBACK     1               n/a
              I11          2               fe80:0002::EUI11
      RT2     LOOPBACK     1               n/a
              I21          2               fe80:0002::EUI21
              I22          3               fe80:0003::EUI22
              I23          4               fe80:0004::EUI23
      RT3     LOOPBACK     1               n/a
              I31          2               fe80:0002::EUI31
      RT4     LOOPBACK     1               n/a
              I41          2               fe80:0002::EUI41
              I42          3               fe80:0003::EUI42
        
3.1.2.1. Router-LSAs
3.1.2.1. 路由器LSA

As an example, consider the router-LSAs that node RT2 would originate. Two MANET interfaces, consisting of 3 point-to-point links, are presented.

作为一个例子,考虑节点RT2将起源的路由器LSA。提出了两个由3个点到点链路组成的MANET接口。

RT2's router-LSA

RT2的路由器LSA

      LS age = DoNotAge+0              ;newly originated
      LS type = 0x2001                 ;router-LSA
      Link State ID = 0                ;first fragment
      Advertising Router = 192.0.2.2   ;RT2's Router ID
      bit E = 0                        ;not an AS boundary router
      bit B = 0                        ;not an area border router
      Options = (V6-bit|E-bit|R-bit)
       Type = 1                        ;p2p link to RT1 over I21
       Metric = 10                     ;cost to RT1
       Interface ID = 2                ;Interface ID of I21
       Neighbor Interface ID = 2       ;Interface ID of I11
       Neighbor Router ID = 192.0.2.1  ;RT1's Router ID
       Type = 1                        ;p2p link to RT4 over I21
       Metric = 25                     ;cost to RT4
       Interface ID = 2                ;Interface ID of I21
       Neighbor Interface ID = 3       ;Interface ID of I42
       Neighbor Router ID = 192.0.2.4  ;RT4's Router ID
       Type = 1                        ;p2p link to RT4 over I22
       Metric = 15                     ;cost to RT4
       Interface ID = 3                ;Interface ID of I22
       Neighbor Interface ID = 2       ;Interface ID of I41
       Neighbor Router ID = 192.0.2.4  ;RT4's Router ID
        
      LS age = DoNotAge+0              ;newly originated
      LS type = 0x2001                 ;router-LSA
      Link State ID = 0                ;first fragment
      Advertising Router = 192.0.2.2   ;RT2's Router ID
      bit E = 0                        ;not an AS boundary router
      bit B = 0                        ;not an area border router
      Options = (V6-bit|E-bit|R-bit)
       Type = 1                        ;p2p link to RT1 over I21
       Metric = 10                     ;cost to RT1
       Interface ID = 2                ;Interface ID of I21
       Neighbor Interface ID = 2       ;Interface ID of I11
       Neighbor Router ID = 192.0.2.1  ;RT1's Router ID
       Type = 1                        ;p2p link to RT4 over I21
       Metric = 25                     ;cost to RT4
       Interface ID = 2                ;Interface ID of I21
       Neighbor Interface ID = 3       ;Interface ID of I42
       Neighbor Router ID = 192.0.2.4  ;RT4's Router ID
       Type = 1                        ;p2p link to RT4 over I22
       Metric = 15                     ;cost to RT4
       Interface ID = 3                ;Interface ID of I22
       Neighbor Interface ID = 2       ;Interface ID of I41
       Neighbor Router ID = 192.0.2.4  ;RT4's Router ID
        
3.1.2.2. Link-LSAs
3.1.2.2. 链路LSA

A MANET node originates a separate link-LSA for each attached interface. As an example, consider the link-LSA that RT3 will build for its MANET interface I31.

MANET节点为每个连接的接口发起单独的链路LSA。作为一个例子,考虑RT3将为其MANET接口I31构建的链路LSA。

RT3's link-LSA for MANET interface I31

用于MANET接口I31的RT3链路LSA

      LS age = DoNotAge+0              ;newly originated
      LS type = 0x0008                 ;link-LSA
      Link State ID = 2                ;Interface ID of I31
      Advertising Router = 192.0.2.3   ;RT3's Router ID
      Rtr Pri = 1                      ;default priority
      Options = (V6-bit|E-bit|R-bit)
      Link-local Interface Address = fe80:0002::EUI31
      # prefixes = 0                   ;no global unicast address
        
      LS age = DoNotAge+0              ;newly originated
      LS type = 0x0008                 ;link-LSA
      Link State ID = 2                ;Interface ID of I31
      Advertising Router = 192.0.2.3   ;RT3's Router ID
      Rtr Pri = 1                      ;default priority
      Options = (V6-bit|E-bit|R-bit)
      Link-local Interface Address = fe80:0002::EUI31
      # prefixes = 0                   ;no global unicast address
        
3.1.2.3. Intra-Area-Prefix-LSAs
3.1.2.3. 区域内前缀LSA

A MANET node originates an intra-area-prefix-LSA to advertise its own prefixes and those of its attached stub links. As an example, consider the intra-area-prefix-LSA that RT2 will build.

MANET节点发起一个区域内前缀LSA,以公布其自身的前缀及其连接的存根链路的前缀。作为一个例子,考虑RT2将构建的区域内前缀LSA。

RT2's intra-area-prefix-LSA for its own prefixes

RT2自身前缀的区域内前缀LSA

LS age = DoNotAge+0 ;newly originated LS type = 0x2009 ;intra-area-prefix-LSA Link State ID = 177 ;or something else Advertising Router = 192.0.2.2 ;RT2's Router ID # prefixes = 2 Referenced LS type = 0x2001 ;router-LSA reference Referenced Link State ID = 0 ;always 0 for router-LSA ;reference Referenced Advertising Router = 192.0.2.2 ;RT2's Router ID PrefixLength = 64 ;prefix on RT2's LOOPBACK PrefixOptions = 0 Metric = 0 ;cost of RT2's LOOPBACK Address Prefix = 2001:DB8:0002:: PrefixLength = 60 ;prefix on I23 PrefixOptions = 0 Metric = 10 ;cost of I23 Address Prefix = 2001:DB8:0012::

LS年龄=DoNotAge+0;新生成的LS类型=0x2009;区域内前缀LSA链路状态ID=177;或者其他一些广告路由器=192.0.2.2;RT2的路由器ID#前缀=2引用的LS类型=0x2001;路由器LSA参考链路状态ID=0;路由器LSA始终为0;参考广告路由器=192.0.2.2;RT2的路由器ID前缀长度=64;RT2的环回PrefixOptions上的前缀=0 Metric=0;RT2的环回地址前缀成本=2001:DB8:0002::PrefixLength=60;I23 PrefixOptions上的前缀=0公制=10;I23地址前缀的成本=2001:DB8:0012::

Note: MANET nodes may originate intra-area-prefix-LSAs for attached transit (broadcast/NBMA) networks. This is normal behavior (defined in [OSPFv3]), which is irrelevant to MANET interfaces. Please consult [OSPFv3] for details.

注意:MANET节点可以为连接的传输(广播/NBMA)网络发起区域内前缀LSA。这是正常行为(定义见[OSPFv3]),与MANET接口无关。有关详细信息,请咨询[OSPFv3]。

3.2. Incremental OSPF-MANET Hellos
3.2. 增量OSPF-MANET Hellos

In MANETs, reducing the size of periodically transmitted packets can be very important in decreasing the total amount of overhead associated with routing. Towards this end, removing the list of neighbors from Hello packets, unless that information changes, can reduce routing protocol overhead. While the reduction for each Hello packet is small, over time it will be significant.

在MANET中,减少周期性传输的数据包的大小对于减少与路由相关的总开销非常重要。为此,除非信息发生变化,否则从Hello数据包中删除邻居列表可以减少路由协议开销。虽然每个Hello数据包的减少量很小,但随着时间的推移,它将是显著的。

A new option bit is defined in this document to facilitate the operation of incremental Hello packets. A new State Check Sequence TLV (SCS TLV) and Neighbor Drop TLV are also defined, transmitted using LLS [LLS].

本文档中定义了一个新的选项位,以方便增量Hello数据包的操作。还定义了新的状态检查序列TLV(SCS-TLV)和邻居丢弃TLV,并使用LLS[LLS]进行传输。

3.2.1. The I Option Bit
3.2.1. I选项位

A new I-bit is defined in the LLS Type 1 Extended Options and Flags field. The bit is defined for Hello packets and indicates that only incremental information is present. See Section 5 for placement of the I-bit.

在LLS类型1扩展选项和标志字段中定义了一个新的I位。该位是为Hello数据包定义的,表示只存在增量信息。有关I位的放置,请参见第5节。

3.2.2. State Check Sequence TLV (SCS TLV)
3.2.2. 状态检查序列TLV(SCS TLV)

A new TLV is defined that indicates the current state, which is represented by a State Check Sequence (SCS) number of the transmitting router.

定义了一个新的TLV来指示当前状态,该状态由发送路由器的状态检查序列(SCS)号表示。

    0                   1                     2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7  8  9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SCS Number            |R|FS|N |   Reserved              |
   +-----------------------------------------------------------------+
        
    0                   1                     2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7  8  9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         SCS Number            |R|FS|N |   Reserved              |
   +-----------------------------------------------------------------+
        

o Type: 6

o 类型:6

o Length: Set to 4.

o 长度:设置为4。

o SCS Number: A circular two-octet unsigned integer indicating the current state of the transmitting device. Note that when the incremental Hello mechanism is invoked (or re-started), an initial SCS value of '1' SHOULD be used for the first incremental Hello packet. This sequence number is referred to as InitialSCS. Note that InitialSCS also implies a full state.

o SCS编号:一个圆形的两个八位无符号整数,表示发送设备的当前状态。请注意,当调用(或重新启动)增量Hello机制时,第一个增量Hello数据包应使用初始SCS值“1”。此序列号称为InitialSCS。请注意,InitialSCS还表示完整状态。

o R: Request bit. If set, this is a request for current state. The list of routers that should respond to this request is indicated in the Request From TLV (RF TLV) (defined below). If the RF TLV is not present, it is assumed that the request is meant for all nodes.

o R:请求位。如果设置,则这是对当前状态的请求。应响应此请求的路由器列表在TLV(RF TLV)(定义如下)的请求中指明。如果RF TLV不存在,则假定该请求适用于所有节点。

o FS: Full State bit. If set, the Hello packet contains full state as far as the neighbor(s) in the Full State For TLV (FSF TLV) (defined below) are concerned. If the FSF TLV is not present, the Hello packet contains full state for all neighbors.

o FS:全状态位。如果设置,Hello数据包包含完整状态,就TLV(FSF TLV)(定义如下)处于完整状态的邻居而言。如果FSF TLV不存在,则Hello数据包包含所有邻居的完整状态。

o N: Incomplete bit. If NOT set, the complete state associated with the SCS number is included in the Hello packet. If set, this indicates that the appended TLVs are being sent 'persistently', and that there is more state associated with the SCS number that was sent originally, but is not included in this Hello packet. This bit allows any desired TLVs to be sent 'persistently' for a number of Hellos with the same SCS number without requiring all of the TLVs associated with that SCS number to be transmitted. The first time an SCS number is sent, the entire state associated with that SCS number is transmitted, and the N-bit MUST NOT be set.

o N:不完整位。如果未设置,则与SCS号码关联的完整状态将包含在Hello数据包中。如果设置,则表示附加的TLV正在“持续”发送,并且有更多状态与最初发送的SCS号相关,但未包含在此Hello数据包中。该位允许为多个具有相同SCS编号的HELLO“持续”发送任何所需TLV,而无需传输与该SCS编号相关的所有TLV。第一次发送SCS号时,将传输与该SCS号相关的整个状态,且不得设置N位。

o Reserved: Set to 0. Reserved for future use.

o 保留:设置为0。保留供将来使用。

A Hello with the SCS TLV appended and with the R-bit set will be referred to as a Hello request.

附加了SCS TLV和R位集的Hello将被称为Hello请求。

3.2.3. Neighbor Drop TLV
3.2.3. 邻滴TLV

A new TLV is defined in this document that indicates neighbor(s) that have been removed from the list of known neighbors.

本文档中定义了一个新的TLV,表示已从已知邻居列表中删除的邻居。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Dropped Neighbor(s)                                           |
   +---------------------------------------------------------------+
   | ....
   +--------------------
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Dropped Neighbor(s)                                           |
   +---------------------------------------------------------------+
   | ....
   +--------------------
        

o Type: 7 o Length: Set to the number of dropped neighbors included in the TLV multiplied by 4.

o 类型:7 o长度:设置为TLV中包含的丢弃邻居数乘以4。

o Dropped Neighbor(s) - Router ID of the neighbor being dropped.

o 丢弃的邻居-正在丢弃的邻居的路由器ID。

3.2.4. Request From TLV (RF TLV)
3.2.4. 来自TLV(RF TLV)的请求

A new TLV is defined in this document that indicates neighbor(s) from which the latest Hello state is being requested.

本文档中定义了一个新的TLV,该TLV指示请求最新Hello状态的邻居。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Request From Neighbor(s)                    |
   +---------------------------------------------------------------+
   | ....
   +--------------------
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Request From Neighbor(s)                    |
   +---------------------------------------------------------------+
   | ....
   +--------------------
        

o Type: 8

o 类型:8

o Length: Set to the number of neighbors included in the TLV multiplied by 4.

o 长度:设置为TLV中包含的邻居数乘以4。

o Request From Neighbor(s) - Router ID of the neighbor(s) from which Hello state is being requested.

o Requestfrom Neighbor(s)-请求Hello状态的邻居的路由器ID。

3.2.5. Full State For TLV (FSF TLV)
3.2.5. TLV(FSF TLV)的完全状态

A new TLV is defined in this document that indicates neighbor(s) to which the transmitting node is responding with full state.

本文档中定义了一个新的TLV,该TLV指示发送节点以完全状态响应的邻居。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Full State For Neighbor(s)                  |
   +---------------------------------------------------------------+
   | ....
   +--------------------
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Full State For Neighbor(s)                  |
   +---------------------------------------------------------------+
   | ....
   +--------------------
        

o Type: 9

o 类型:9

o Length: Set to the number of neighbors included in the TLV multiplied by 4.

o 长度:设置为TLV中包含的邻居数乘以4。

o Full State For Neighbor(s) - Router ID of the neighbor(s) should process this packet.

o 邻居的完整状态-邻居的路由器ID应处理此数据包。

3.2.6. Neighbor Adjacencies
3.2.6. 邻接

This section describes building neighbor adjacencies and the failure of such adjacencies using the incremental Hello signaling.

本节描述了使用增量Hello信令构建邻居邻接以及此类邻接的故障。

3.2.6.1. Building Neighbor Adjacencies
3.2.6.1. 建筑邻接

Hello packets are sent periodically in accordance with [OSPF] and [OSPFv3]. An OSPF implementation that supports sending only partial neighbor information in Hello packets SHOULD always set the I-bit in its transmitted Hello packets, except as described elsewhere in this document. Hello packets MAY be suppressed from being transmitted every HelloInterval if other packet transmissions are sent by the router during that time.

Hello数据包根据[OSPF]和[OSPFv3]定期发送。支持在Hello数据包中仅发送部分邻居信息的OSPF实现应始终在其传输的Hello数据包中设置I位,本文档其他地方描述的情况除外。如果路由器在此期间发送其他数据包传输,则Hello数据包可能被禁止在每个HelloInterval传输。

On receiving a Hello packet from a new neighbor (in this context, a new neighbor is a neighbor in less than Init state as defined in Section 10.1 [OSPF]), if the Hello has the I-bit set, a router will:

在从新邻居(在此上下文中,新邻居是第10.1节[OSPF]中定义的处于Init以下状态的邻居)接收Hello数据包时,如果Hello设置了I位,路由器将:

o Place the new neighbor in the neighbor list described in [OSPFv3], Appendix A.3.2.

o 将新邻居放入附录A.3.2中[OSPFv3]所述的邻居列表中。

o Increment the router's SCS number that it will use in its next Hello (indicated in the SCS TLV).

o 增加路由器的SCS编号,该编号将在其下一次Hello中使用(在SCS TLV中指示)。

o Remove the neighbor from the neighbor list described in [OSPFv3], Appendix A.3.2, when the neighbor has reached the Exchange state (as described in [OSPF], Section 10.1).

o 当邻居达到交换状态时(如[OSPF]第10.1节所述),从附录A.3.2[OSPFv3]中所述的邻居列表中删除该邻居。

o Remove the neighbor from the neighbor list described in [OSPFv3], Appendix A.3.2, if the neighbor is not a DR or backup designated router (BDR) on an OSPF broadcast link, and if the neighbor is advertised as connected in the network-LSA advertised by the DR.

o 如果邻居不是OSPF广播链路上的DR或备份指定路由器(BDR),并且如果邻居在DR播发的网络LSA中被播发为已连接,则从[OSPFv3]附录A.3.2中所述的邻居列表中删除该邻居。

3.2.6.2. Adjacency Failure
3.2.6.2. 邻接失效

On discovering an adjacency failure (going to state less than Exchange), a router using I-bit signaling SHOULD:

在发现邻接故障(状态小于交换)时,使用I位信令的路由器应:

o Remove the adjacent router from local tables, and take the appropriate actions for a failed adjacency described in [OSPF] and [OSPFv3].

o 从本地表中删除相邻路由器,并对[OSPF]和[OSPFv3]中所述的故障邻接采取适当的措施。

o Add the formerly adjacent router to a Neighbor Drop TLV.

o 将以前相邻的路由器添加到邻居放置TLV。

o Increment the router's SCS number that it will transmit in its next Hello.

o 增加路由器的SCS号,它将在下一个Hello中传输。

o Transmit Hellos with this Neighbor Drop TLV. It may be desirable to send the Neighbor Drop TLV in three consecutive Hellos to increase the probability of reception. In this case, 'persistent' Hello packets would be sent with the same SCS number, the Neighbor Drop TLV, and the N-bit set. Thus, the receiver knows that the Neighbor Drop TLV is being sent persistently, and there is more state associated with the SCS in case it must request missing state presumably transmitted in a previous Hello.

o 用这个邻居的下降TLV传送他。可能希望在三个连续hello中发送邻居丢弃TLV以增加接收概率。在这种情况下,“持久”Hello数据包将使用相同的SCS号、邻居丢弃TLV和N位集发送。因此,接收机知道邻居Drop TLV正在被持续发送,并且存在更多与SCS相关联的状态,以防它必须请求可能在先前Hello中发送的缺失状态。

3.2.7. Sending Hellos
3.2.7. 打招呼

When a device is first attached to a network (whether by being brought within range of another device, powering the device on, enabling the device's radio interface, etc.), it will need to obtain complete neighbor state from each of its neighbors before it can utilize the incremental Hello mechanism. Thus, upon initialization, a device MAY send a multicast Hello request (and omit the Request From TLV). Neighbors will receive the request and respond with a Hello with their complete neighbor state.

当一个设备第一次连接到网络时(无论是通过进入另一个设备的范围、打开设备电源、启用设备的无线电接口等),它都需要从每个邻居处获得完整的邻居状态,然后才能使用增量Hello机制。因此,在初始化时,设备可以发送多播Hello请求(并且省略来自TLV的请求)。邻居将收到请求,并使用其完整的邻居状态回复Hello。

If a device is in INIT state with a neighbor and receives a Hello from the neighbor without its router ID listed in the neighbor list, the device SHOULD request the current state from the neighbor. Note that this is to avoid a "race" condition, since the received Hello can either mean that the device is NOT SEEN by the neighbor, or that the device is adjacent and not listed in the incremental list. Thus, by receiving a Hello request, the neighbor will respond with its neighbor state for the neighbor.

如果设备与邻居处于INIT状态,并且从邻居处收到Hello,但邻居列表中没有列出其路由器ID,则设备应向邻居请求当前状态。请注意,这是为了避免“竞争”情况,因为接收到的Hello可能意味着邻居看不到该设备,或者该设备相邻且未在增量列表中列出。因此,通过接收Hello请求,邻居将使用其邻居状态响应邻居。

The first Hello packet with a particular SCS number MUST contain the full state associated with that SCS number, i.e., all state changes since the last SCS number. The N-bit MUST NOT be set in the State Check Sequence TLV.

具有特定SCS编号的第一个Hello数据包必须包含与该SCS编号关联的完整状态,即自最后一个SCS编号以来的所有状态更改。不得在状态检查序列TLV中设置N位。

Incremental Hello packets can be sent persistently (sent in k successive Hello packets), with flexibility in the actual amount of information being sent. The three options include:

增量Hello数据包可以持续发送(在k个连续Hello数据包中发送),在实际发送的信息量上具有灵活性。这三个选项包括:

o The entire incremental Hello packet is sent persistently. This is accomplished by simply sending the entire state associated with a SCS number for k successive Hellos. Since the SCS number remains the same, the N-bit is not set in these incremental Hello packets.

o 整个增量Hello数据包将持续发送。这是通过简单地发送与k个连续hello的SCS号码相关联的整个状态来实现的。由于SCS编号保持不变,因此在这些增量Hello数据包中未设置N位。

o Partial information for a particular SCS number is sent persistently. After the first Hello packet with a particular SCS number is sent, only the TLVs that are desired to be sent

o 持续发送特定SCS编号的部分信息。在发送具有特定SCS编号的第一个Hello数据包后,仅发送希望发送的TLV

persistently are sent in subsequent Hellos with the same SCS number and the N-bit set.

以相同的SCS编号和N位集在后续Hello中持续发送。

o No information is sent persistently. This is simply the default behavior where an incremental Hello packet with a particular SCS number is only sent once.

o 没有持续发送任何信息。这只是默认行为,其中带有特定SCS编号的增量Hello数据包只发送一次。

3.2.8. Receiving Hellos
3.2.8. 接受问候

Each OSPF device supporting incremental Hello signaling, as described in this document, MUST keep the last known SCS number from each neighbor it has received Hellos from as long as the neighbor adjacency structure is maintained.

如本文档所述,每个支持增量Hello信令的OSPF设备必须保持其从每个邻居接收Hello的最后一个已知SCS号码,只要邻居邻接结构保持不变。

If a device receives a Hello from an adjacent neighbor with an SCS number less than the last known SCS number from that neighbor, it MUST first check if the SCS number is a wrap around. "Wrap around" is a condition when the last known SCS number is MAX_SCS (65535) and the new SCS number is 1. If it is not a wrap around, then the device MUST send a Hello request to the neighbor.

如果设备接收到来自相邻邻居的Hello,且SCS编号小于该邻居最后已知的SCS编号,则必须首先检查SCS编号是否为环绕编号。“环绕”是最后一个已知SCS编号为MAX_SCS(65535)且新SCS编号为1时的一种情况。如果不是环绕,则设备必须向邻居发送Hello请求。

If it is a wrap around, or if a device receives a Hello from an adjacent neighbor with an SCS number one greater than the last known SCS number from that neighbor, it MUST:

如果是环绕,或者如果设备接收到来自相邻邻居的Hello,且SCS编号大于来自该邻居的最后一个已知SCS编号,则必须:

o Examine the neighbor list described in [OSPFv3], Appendix A.3.2. If any neighbors are contained in this list, increment the SCS number contained in the adjacent neighbor's data structure.

o 检查附录A.3.2中[OSPFv3]所述的邻居列表。如果此列表中包含任何邻居,则增加相邻邻居数据结构中包含的SCS编号。

o Examine the Neighbor Drop TLV as described in Section 3.2.6.2. If this list contains a neighbor other than the local router, increment the SCS number contained in the adjacent neighbor's data structure.

o 如第3.2.6.2节所述,检查相邻下降TLV。如果此列表包含本地路由器以外的邻居,则增加相邻邻居数据结构中包含的SCS编号。

o Examine the Neighbor Drop TLV as described in Section 3.2.6.2. If the local router identifier is contained in this list, destroy the transmitting adjacent neighbor's data structures.

o 如第3.2.6.2节所述,检查相邻下降TLV。如果本地路由器标识符包含在此列表中,请销毁传输相邻邻居的数据结构。

o Examine any other TLVs incrementally signaled, as described in documents referring to this RFC. If there are other state changes indicated, increment the SCS number contained in the adjacent neighbor's data structure.

o 按照参考本RFC的文件中所述,检查增量发出信号的任何其他TLV。如果指示了其他状态更改,则增加相邻邻居数据结构中包含的SCS编号。

o If no state change information is contained in the received Hello, send a request for current state (by setting the 'R'-bit) in the next Hello.

o 如果收到的Hello中不包含状态更改信息,则在下一个Hello中发送当前状态请求(通过设置“R”位)。

If a device receives a Hello from an adjacent neighbor with an SCS number greater than the last known SCS number + 1 from that neighbor, it MUST send a Hello request to the neighbor, since it may be missing some neighbor state.

如果设备接收到来自相邻邻居的Hello,且该邻居的SCS编号大于最近已知的SCS编号+1,则必须向该邻居发送Hello请求,因为该设备可能缺少某个邻居状态。

3.2.8.1. Receiving Hellos with the N-bit Set
3.2.8.1. 使用N位集接收Hello

If a device receives a Hello with the SCS TLV included and the N-bit set in this TLV, it MUST verify that it has already received the SCS number with the N-bit NOT set from the neighbor. If the device determines that this is the first receipt of the SCS number from this neighbor, then it MUST send a Hello request to the neighbor, since it missed the initial Hello packet with the SCS number and thus is missing state.

如果设备接收到包含SCS TLV且在该TLV中设置了N位的Hello,则必须验证其已从邻居接收到未设置N位的SCS编号。如果设备确定这是第一次收到来自该邻居的SCS号码,那么它必须向该邻居发送Hello请求,因为它错过了带有SCS号码的初始Hello数据包,因此处于missing状态。

3.2.8.2. Receiving Hellos with the R-bit Set
3.2.8.2. 用R位集接收hello

If a device receives a Hello with the SCS TLV included and the R-bit set, it looks for the RF TLV. If its router ID is listed in the RF TLV or the TLV is not found, it includes its full state in the next Hello. This MUST include:

如果设备接收到包含SCS TLV和R位设置的Hello,则会查找RF TLV。如果其路由器ID在RF TLV中列出或未找到TLV,则在下一个Hello中包含其完整状态。这必须包括:

o The neighbor ID of the requesting neighbor(s) in the list of neighbors described in [OSPFv3], Appendix A.3.2.

o [OSPFv3]附录A.3.2中所述邻居列表中请求邻居的邻居ID。

o An SCS TLV with the transmitter's current SCS number and the FS-bit set. Note that the transmitter's SCS number is NOT incremented.

o 带有变送器当前SCS编号和FS位设置的SCS TLV。请注意,变送器的SCS编号不会增加。

o Any other TLVs, defined in other documents referencing this RFC, indicating the current state of the local system.

o 任何其他TLV,在引用此RFC的其他文档中定义,指示本地系统的当前状态。

o The neighbor ID of all the neighbors who have requested current state, in the FSF TLV.

o FSF TLV中请求当前状态的所有邻居的邻居ID。

If the full state is being sent to a large number of existing neighbors, an implementation could choose to instead generate a full state for all neighbors and omit the FSF TLV.

如果将完整状态发送给大量现有邻居,则实现可以选择为所有邻居生成完整状态,并忽略FSF TLV。

3.2.8.3. Receiving Hellos with the FS-bit Set
3.2.8.3. 使用FS位集接收Hellos

When a device receives a Hello with the SCS TLV included and the FS-bit set, the Hello packet contains the neighbor's full state for the device. The packet SHOULD be processed as follows:

当设备接收到包含SCS TLV且设置了FS位的Hello时,Hello数据包包含设备的邻居的完整状态。数据包应按如下方式处理:

o If the received SCS number is equal to the last known SCS number, the packet SHOULD be ignored, since the device already has the latest state information.

o 如果接收到的SCS编号等于最后一个已知的SCS编号,则应忽略该数据包,因为该设备已经具有最新的状态信息。

o If the received SCS number is different than the last known SCS number, this Hello has new information and MUST be parsed.

o 如果收到的SCS号码与上次已知的SCS号码不同,则此Hello具有新信息,必须对其进行解析。

o If it is listed in the FSF TLV, or if the FSF TLV is not present, the device MUST save the SCS number, process the Hello as described in Section 3.2.8, and process any other appended TLVs.

o 如果在FSF TLV中列出,或者如果FSF TLV不存在,则设备必须保存SCS号码,按照第3.2.8节中的说明处理Hello,并处理任何其他附加的TLV。

3.2.9. Interoperability
3.2.9. 互操作性

On receiving a Hello packet from a new neighbor without the I-bit set, the local router will continue to place that router's identifier in transmitted Hellos on this link as described in [OSPFv3], Appendix A.3.2.

当从没有I位设置的新邻居处接收到Hello数据包时,本地路由器将继续将该路由器的标识符放入该链路上传输的Hello中,如[OSPFv3]附录a.3.2所述。

3.2.10. Support for OSPF Graceful Restart
3.2.10. 支持OSPF优雅重启

OSPF graceful restart, as described in [OSPFREST] and [OSPFGR], relies on the lack of neighbors in the list of neighbors described in [OSPFv3], Appendix A.3.2, to determine that an adjacent router has restarted, and other signaling to determine that the adjacency should not be torn down. If all Hello packets transmitted by a given router have an empty Hello list, reliance on an empty Hello packet to signal a restart (or to reliably tear down an OSPF adjacency) is no longer possible. Hence, this signaling must be slightly altered. When a router would like to tear down all adjacencies, or signal that it has restarted:

OSPF优雅重启,如[OSPFREST]和[OSPFGR]所述,依赖于[OSPFv3]附录A.3.2中所述的邻居列表中缺少邻居来确定相邻路由器已重启,以及其他信令来确定不应拆除相邻。如果给定路由器传输的所有Hello数据包都有一个空的Hello列表,则不再可能依赖一个空的Hello数据包来发出重启信号(或可靠地中断OSPF邻接)。因此,必须稍微改变这种信号。当路由器想要拆除所有邻接,或发出其已重新启动的信号时:

o On initially restarting, during the first RouterDeadInterval after restart, the router will transmit Hello packets with an empty neighbor list and the I-bit cleared. Any normal restart or other signaling may be included in these initial Hello packets.

o 在最初重新启动时,在重新启动后的第一个RouterDeadInterval期间,路由器将发送邻居列表为空且I位已清除的Hello数据包。任何正常重启或其他信令都可以包含在这些初始Hello数据包中。

o As adjacencies are learned, these newly learned adjacent routers are included in the multicast Hellos transmitted on the link.

o 当邻接被学习时,这些新学习的相邻路由器被包括在链路上传输的多播hello中。

o After one RouterDeadInterval has passed, the incremental Hello mechanism is invoked. An incremental Hello packet with full state is sent with the I-bit set, the SCS TLV included with the FS-bit set, and the InitialSCS value (e.g., SCS of '1'). Subsequent Hello packets will include only incremental state.

o 传递一个RouterReadInterval后,将调用增量Hello机制。带有完整状态的增量Hello数据包随I位集、FS位集包含的SCS TLV和初始SCS值(例如,SCS为“1”)一起发送。后续Hello数据包将只包括增量状态。

Routers that are neighboring with a restarting router MUST continue sending their Hello packets with the I-bit set.

与重新启动的路由器相邻的路由器必须继续发送其具有I位集的Hello数据包。

3.3. Optimized Flooding (Overlapping Relays)
3.3. 优化泛洪(重叠继电器)

A component that may influence the scalability and convergence characteristics of OSPF ([OSPF], [OSPFv3]) in a MANET environment is how much information needs to be flooded. The ideal solution is that a router will receive a particular routing update only once. However, there must be a trade-off between protocol complexity and ensuring that every speaker in the network receives all of the information. Note that a speaker refers to any node in the network that is running the routing protocol and transmitting routing updates and Hello messages.

在MANET环境中,可能影响OSPF([OSPF]、[OSPFv3])的可伸缩性和收敛特性的一个组件是需要淹没多少信息。理想的解决方案是路由器只接收一次特定的路由更新。然而,必须在协议复杂性和确保网络中的每个说话人都接收所有信息之间进行权衡。请注意,说话人是指网络中运行路由协议并传输路由更新和Hello消息的任何节点。

Controlling the amount of information on the link has increased importance in a MANET environment due to the potential transmission costs and resource availability in general.

由于潜在的传输成本和资源可用性,控制链路上的信息量在MANET环境中变得越来越重要。

In some environments, a group of speakers that share the same logical segment may not be directly visible to each other; some of the possible causes are the following: low signal strength, long distance separation, environmental disruptions, partial VC (virtual circuit) meshing, etc. In these networks, a logical segment refers to the local flooding domain dynamically determined by transmission radius. In these situations, some speakers (the ones not able to directly reach the sender) may never be able to synchronize their databases. To solve the synchronization issues encountered in these environments, a mechanism is needed through which all the nodes on the same logical segment can receive the routing information, regardless of the state of their adjacency to the source.

在某些环境中,共享同一逻辑段的一组扬声器可能彼此不直接可见;一些可能的原因如下:低信号强度、长距离分离、环境干扰、部分VC(虚拟电路)啮合等。在这些网络中,逻辑段指由传输半径动态确定的局部泛洪域。在这些情况下,某些发言者(无法直接联系发件人的发言者)可能永远无法同步其数据库。为了解决这些环境中遇到的同步问题,需要一种机制,通过该机制,同一逻辑段上的所有节点都可以接收路由信息,而不管它们与源的邻接状态如何。

3.3.1. Operation Overview
3.3.1. 操作概述

The optimized flooding operation relies on the ability of a speaker to advertise all of its locally connected neighbors. In OSPF, this ability is realized through the use of link state advertisements (LSA)s ([OSPF], [OSPFv3]).

优化的泛洪操作依赖于说话人播发其所有本地连接邻居的能力。在OSPF中,这种能力是通过使用链路状态播发(LSA)来实现的([OSPF],[OSPFv3])。

A speaker receives router-LSAs from its adjacent neighbors. A speaker's router-LSA conveys the list of the adjacent speakers of the originator ("neighbor list"). The local speaker can compare the neighbor list reported by each speaker to its own neighbor list. If the local neighbor list contains adjacent speakers that the originator cannot reach directly (i.e., those speakers that are not in the originator's neighbor list), then these speakers are locally known as non-overlapping neighbors for the originator.

扬声器从相邻的邻居接收路由器LSA。说话人的路由器LSA传送发起者的相邻说话人的列表(“邻居列表”)。本地说话人可以将每个说话人报告的邻居列表与其自己的邻居列表进行比较。如果本地邻居列表包含发端人无法直接联系到的相邻说话人(即,不在发端人邻居列表中的那些说话人),则这些说话人在本地称为发端人的非重叠邻居。

The local speaker should relay any routing information to non-overlapping neighbors of the sender based on the algorithm outlined in Section 3.3.8. Because more than one such speaker may exist, the

本地说话人应根据第3.3.8节中概述的算法,将任何路由信息转发给发送者的非重叠邻居。因为可能存在不止一个这样的演讲者

mechanism is called "overlapping relays". The algorithm, however, does select the set of overlapping relays that should transmit first. This set is known as the active set of overlapping relays for a speaker.

这种机制被称为“重叠继电器”。然而,该算法确实选择了应首先传输的一组重叠继电器。这一组被称为扬声器重叠继电器的激活组。

3.3.2. Determination of Overlapping Relays
3.3.2. 重叠继电器的确定

The first step in the process is for each speaker to build and propagate their neighbor lists in router-LSA packets. Every speaker is then in a position to determine their 2-hop neighborhood, i.e., those nodes that are neighbors of the speaker's 1-hop neighbors.

这个过程的第一步是让每个说话者在路由器LSA数据包中建立和传播他们的邻居列表。然后,每个说话人都可以确定他们的2跳邻居,即说话人的1跳邻居的邻居节点。

A bidirectional neighbor is considered an overlapping relay for a speaker if it can reach a node in the 2-hop neighborhood of the speaker, i.e., if it has 1-hop neighbors (excluding the speaker itself).

如果双向邻居可以到达说话人的2跳邻居中的节点,即,如果它有1跳邻居(不包括说话人本身),则它被视为说话人的重叠中继。

The set of Active Overlapping Relays for a speaker is the minimum set of direct neighbors such that every node in the 2-hop neighborhood of the speaker is a neighbor of at least one overlapping relay in the active set.

扬声器的主动重叠继电器集是直接邻居的最小集,使得扬声器的2跳邻居中的每个节点是主动集中至少一个重叠继电器的邻居。

Each speaker SHOULD select a set of Active Overlapping Relays based on a selection algorithm (one such algorithm is suggested in Section 3.3.4 and is based on the multipoint relay (MPR) selection algorithm described in [OLSR]). The behavior of the overlapping relays MUST follow that specified in Section 3.3.8.

每个扬声器应根据选择算法选择一组有源重叠继电器(第3.3.4节中建议了一种此类算法,并基于[OLSR]中描述的多点继电器(MPR)选择算法)。重叠继电器的行为必须符合第3.3.8节的规定。

Note that a speaker MUST NOT choose a neighbor to serve as an Active Overlapping Relay if that neighbor set the N-bit in its Active Overlapping Relay TLV as defined in Section 3.3.6, unless the neighbor is the only neighbor to reach a 2-hop neighbor.

请注意,如果某个邻居按照第3.3.6节的定义在其活动重叠中继TLV中设置了N位,则扬声器不得选择该邻居作为活动重叠中继,除非该邻居是唯一到达2跳邻居的邻居。

Election of Active Overlapping Relays is done across interfaces, and thus, it is node-based and not link-based.

主动重叠继电器的选择是跨接口进行的,因此,它是基于节点的,而不是基于链路的。

3.3.3. Terminology
3.3.3. 术语

The following heuristic and terminology for Active Overlapping Relay selection is largely taken from [OLSR]:

以下主动重叠继电器选择的启发式和术语主要取自[OLSR]:

o FULL: Neighbor state FULL as defined in [OSPF] and [OSPFv3]. Note that all neighbor references in this document are assumed to be FULL neighbors.

o 完全:邻居状态完全,如[OSPF]和[OSPFv3]中所定义。请注意,本文档中的所有邻居引用都假定为完全邻居。

o N: N is the set of FULL neighbors of the node.

o N:N是节点的完整邻居集。

o 2-hop FULL neighbors (N2): The list of 2-hop neighbors of the node that are FULL and that can be reached from direct neighbors, excluding any directly connected neighbors.

o 2-hop FULL neighbories(N2):节点的2-hop邻居列表,这些邻居已满并且可以通过直接邻居访问,不包括任何直接连接的邻居。

o Active Set: A (sub)set of the neighbors selected, such that through these selected nodes, all 2-hop FULL neighbors are reachable.

o 活动集:选定邻居的(子)集,通过这些选定节点,可以访问所有2跳完整邻居。

o D(y): The degree of a 1-hop neighbor node y (where y is a member of N) is defined as the number of FULL neighbors of node y, EXCLUDING all the members of N and EXCLUDING the node performing the computation.

o D(y):1跳邻居节点y(其中y是N的成员)的度定义为节点y的完整邻居的数量,不包括N的所有成员,也不包括执行计算的节点。

3.3.4. Overlapping Relay Discovery Process
3.3.4. 重叠中继发现过程

A possible algorithm for discovering overlapping relays is the following:

发现重叠继电器的可能算法如下:

1. Start with an active set made of all members of N that have set the A-bit in their Active Overlapping Relay TLV (AOR TLV) as defined in Section 3.3.6.

1. 从一个由N的所有成员组成的活动集开始,这些成员在其活动重叠继电器TLV(AOR TLV)中设置了A位,如第3.3.6节所定义。

2. Calculate D(y), where y is a member of N, for all nodes in N.

2. 计算N中所有节点的D(y),其中y是N的成员。

3. Add to the active set those nodes in N, which are the *only* nodes to provide reachability to a node in N2, i.e., if node b in N2 can be reached only through a symmetric link to node a in N, then add node a to the active set. Remove the nodes from N2 that are now covered by a node in the active set.

3. 将N中的节点添加到活动集中,这些节点是为N2中的节点提供可达性的*唯一*节点,即,如果N2中的节点b只能通过与N中的节点a的对称链路到达,则将节点a添加到活动集中。从N2中删除当前由活动集中的节点覆盖的节点。

4. While there exist nodes in N2 that are not covered by at least one node in the active set:

4. 当N2中存在活动集中至少一个节点未覆盖的节点时:

A. For each node in N, calculate the reachability, i.e., the number of nodes in N2 that are not yet covered by at least one node in the active set and that are reachable through this 1-hop neighbor.

A.对于N中的每个节点,计算可达性,即N2中尚未被活动集中至少一个节点覆盖且可通过该1跳邻居到达的节点数。

B. Select as an Active Overlapping Relay the node with the highest Willingness value (Section 3.3.7) among the nodes in N with non-zero reachability. In the case of multiple choices, select the node that provides reachability to the maximum number of nodes in N2. In the case of multiple nodes providing the same amount of reachability, select as active the node whose D(y) is greater. As a final tie breaker, the node with the highest router ID should be chosen. Remove the nodes from N2 that are now covered by a node in the active set.

B.在N个具有非零可达性的节点中,选择意愿值最高的节点(第3.3.7节)作为主动重叠中继。在多选的情况下,选择可到达N2中最大数量节点的节点。在多个节点提供相同数量的可达性的情况下,选择D(y)较大的节点作为活动节点。作为最后一个断开连接的节点,应该选择路由器ID最高的节点。从N2中删除当前由活动集中的节点覆盖的节点。

5. As an optimization, process each node, y, in the active set in increasing order of Willingness value. If all nodes in N2 are still covered by at least one node in the active set, excluding node y, and if Willingness of node y is smaller than MAX_WILLINGNESS, then node y should be removed from the active set.

5. 作为优化,按意愿值的递增顺序处理活动集中的每个节点y。如果N2中的所有节点仍被活动集中的至少一个节点(不包括节点y)覆盖,并且如果节点y的意愿小于最大意愿,则应从活动集中移除节点y。

3.3.5. The F Option Bit
3.3.5. F选项位

A single new option bit, the F-bit, is defined in the LLS Type 1 Extended Options and Flags field. The F-bit indicates that the node supports the optimized flooding mechanism as specified in this document. See Section 5 for placement of the F-bit.

在LLS Type 1扩展选项和标志字段中定义了一个新选项位,即F位。F位表示节点支持本文档中指定的优化泛洪机制。有关F位的放置,请参见第5节。

3.3.6. Active Overlapping Relay TLV (AOR TLV)
3.3.6. 有源重叠继电器TLV(AOR TLV)

A new TLV is defined so that each speaker can convey its set of Active Overlapping Relays in the Hello messages. The TLV is transmitted using LLS [LLS].

定义了一种新的TLV,使得每个说话人都可以在Hello消息中传递其一组活动重叠中继。TLV使用LLS[LLS]传输。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type                  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Relays Added |A|N|           Reserved                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Router ID(s) of Active Overlapping Relay(s)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type                  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Relays Added |A|N|           Reserved                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Router ID(s) of Active Overlapping Relay(s)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

o Type: 10

o 类型:10

o Length - variable. Length of TLV in bytes, NOT including Type and Length.

o 长度变量。TLV的长度(字节),不包括类型和长度。

o Relays Added - variable. Number of Active Overlapping Relays that are being added. Note that the number of Active Overlapping Relays that are being dropped is then given by [(Length - 4)/4 - Relays Added].

o 继电器增加-可变。正在添加的活动重叠继电器的数量。注意,被丢弃的活动重叠继电器的数量由[(长度-4)/4-添加的继电器]给出。

o A-bit - If this bit is set, the node is specifying that it will always flood routing updates that it receives, regardless of whether it is selected as an Active Overlapping Relay.

o A位-如果设置了该位,则节点将指定它将始终对接收到的路由更新进行泛洪,而不管它是否被选为活动重叠中继。

o N-bit - If this bit is set, the node is specifying that it most likely will not flood routing updates. The node SHOULD NOT be

o N位-如果设置了此位,则节点指定它很可能不会泛洪路由更新。不应删除该节点

chosen to be an Active Overlapping Relay unless it is the *only* neighbor that can reach 2-hop neighbor(s). Note that if the node is selected as an Active Overlapping Relay and the node cannot perform the required duties, network behavior is not compromised, since it results in the same behavior as if the node was not chosen as an Active Overlapping Relay.

选择为活动重叠中继,除非它是可到达2跳邻居的*唯一*邻居。请注意,如果节点被选为活动重叠中继,并且节点无法执行所需的职责,则不会影响网络行为,因为它会导致与节点未被选为活动重叠中继时相同的行为。

o Reserved - Reserved for future use. MUST be set to zero by the sender, and MUST be ignored upon receipt.

o 保留-保留供将来使用。发件人必须将其设置为零,并且在收到时必须忽略。

o Router ID(s) of Active Overlapping Relay(s) - The router ID(s) of neighbor(s) that are either chosen to serve as an Active Overlapping Relay or removed from serving as an Active Overlapping Relay. The Active Overlapping Relays that are being added MUST be listed first, and the number of such relays MUST equal Add Length. The remaining listed relays are being dropped as Active Overlapping Relays, and the number of such relays MUST equal [(Length - 4)/4 - Relays Added].

o 活动重叠中继的路由器ID-选择用作活动重叠中继或从用作活动重叠中继中移除的邻居的路由器ID。必须首先列出正在添加的有源重叠继电器,且此类继电器的数量必须等于添加长度。其余列出的继电器作为活动重叠继电器被丢弃,此类继电器的数量必须等于[(长度-4)/4-添加的继电器]。

Note that the A-bit and N-bit are independent of any particular selection algorithm to determine the set of Active Overlapping Relays. However, the bits SHOULD be considered as input into the selection algorithm.

注意,A位和N位独立于任何特定的选择算法,以确定活动重叠继电器集。但是,应将这些位视为选择算法的输入。

If a node is selected as an Active Overlapping Relay and it does not support the Incremental Hello mechanism defined in Section 3.2, then it SHOULD always be included as an Active Overlapping Relay in the TLV. Note that while a node needs to know whether it is an Active Overlapping Relay, it does not necessarily have to know the identities of the other Active Overlapping Relays.

如果一个节点被选为活动重叠中继,并且它不支持第3.2节中定义的增量Hello机制,那么它应始终作为活动重叠中继包含在TLV中。注意,虽然节点需要知道它是否是活动重叠中继,但它不一定必须知道其他活动重叠中继的标识。

3.3.7. Willingness TLV
3.3.7. 意愿TLV

A new TLV is defined so that each speaker can convey its willingness to serve as an Active Overlapping Relay in the Hello message. The TLV is transmitted using the LLS [LLS].

定义了一种新的TLV,使每个说话人都能表达其愿意在Hello消息中充当主动重叠中继的意愿。TLV使用LLS[LLS]传输。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type                  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Willingness |                       Reserved                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type                  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Willingness |                       Reserved                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

o Type: 11

o 类型:11

o Length - 4 bytes. It does not include the Type and Length fields.

o 长度-4字节。它不包括类型和长度字段。

o Willingness - 1 byte to indicate the willingness of the node to serve as an Active Overlapping Relay for its neighbors. * 0: MIN_WILLINGNESS * 128: DEFAULT_WILLINGNESS * 255: MAX_WILLINGNESS

o 意愿-1字节,表示节点愿意充当其邻居的活动重叠中继。*0:最小意愿*128:默认意愿*255:最大意愿

The TLV is optional and MUST be silently ignored if not understood. If the Willingness TLV is not included in the Hello packet, the Willingness value SHOULD be taken as DEFAULT_WILLINGNESS.

TLV是可选的,如果不理解,必须默默忽略。如果意愿TLV未包含在Hello数据包中,则意愿值应作为默认意愿。

3.3.8. Flooding and Relay Decisions
3.3.8. 洪水和接力决策

The decision whether to relay any received LSAs, and when to relay such information, is made depending on the topology and whether the node is part of the set of Active Overlapping Relays.

是否中继任何接收到的lsa以及何时中继此类信息的决定取决于拓扑以及节点是否是活动重叠中继集合的一部分。

Upon receiving an LSA from a bi-directional neighbor, a node makes flooding decisions based on the following algorithm:

在接收到来自双向邻居的LSA后,节点根据以下算法做出泛洪决策:

1. If the node is an Active Overlapping Relay for the adjacent speaker, then the router SHOULD immediately relay any information received from the adjacent speaker.

1. 如果节点是相邻扬声器的活动重叠中继,则路由器应立即中继从相邻扬声器接收的任何信息。

2. If the node is a non-Active Overlapping Relay for the adjacent speaker, then the router SHOULD wait a specified amount of time (PushbackInterval plus jitter (see Section 3.3.10)) to decide whether to transmit. [Jitter is used to try to avoid several non-Active Overlapping Relays from propagating redundant information.] Note that a node with the N-bit set in the 'Active Overlapping Relays' extension will not be chosen as an Active Overlapping Relay unless it is the only node to provide reachability to a 2-hop neighbor. However, it MUST perform the duties of a non-Active Overlapping Relay as required. Non-Active Overlapping Relays MUST follow the acknowledgment mechanism outlined in Section 3.3.9.

2. 如果节点是相邻扬声器的非活动重叠中继,则路由器应等待指定的时间量(回推间隔加上抖动(见第3.3.10节))以决定是否发送。[抖动用于避免多个非活动重叠中继传播冗余信息。]请注意,在“活动重叠中继”扩展中设置了N位的节点将不会被选择为活动重叠中继,除非它是唯一一个向2跳邻居提供可达性的节点。但是,它必须根据需要执行非活动重叠继电器的职责。非活动重叠继电器必须遵循第3.3.9节中概述的确认机制。

A. During this time, if the node determines that flooding the LSA will only result in a redundant transmission, the node MUST suppress its transmission. Otherwise, it MUST transmit upon expiration of PushbackInterval plus jitter.

A.在这段时间内,如果节点确定淹没LSA只会导致冗余传输,则节点必须抑制其传输。否则,它必须在PushbackInterval加上抖动过期时进行传输。

B. If a non-Active Overlapping Relay hears a re-flood from another node that covers its non-overlapping neighbors before its timer to transmit expires, it SHOULD reset its PushbackInterval plus jitter timer. (Note that the implementation should take care to avoid resetting the PushbackInterval timer based on transmissions from Active Overlapping Relays.) During this time, if the node determines that flooding the update will only

B.如果非活动重叠继电器在其发送计时器到期之前听到来自覆盖其非重叠邻居的另一个节点的重新泛洪,则应重置其回推间隔加上抖动计时器。(请注意,实现应注意避免根据活动重叠继电器的传输重置PushbackInterval计时器。)在此期间,如果节点确定泛洪更新只会

result in a redundant transmission, the node MUST suppress its transmission. Otherwise, it MUST transmit upon expiration of PushbackInterval plus jitter.

如果导致冗余传输,则节点必须抑制其传输。否则,它必须在PushbackInterval加上抖动过期时进行传输。

C. If a non-Active Overlapping Relay hears an old instance of the LSA during this time, it SHOULD ignore the LSA, and it SHOULD NOT send a unicast packet to the neighbor with the most recent LSA as specified in [OSPFv3].

C.如果非活动重叠中继在此期间听到LSA的旧实例,则应忽略LSA,并且不应向具有[OSPFv3]中规定的最新LSA的邻居发送单播数据包。

3. For LSAs that are received unicast because of retransmission by the originator, the node MUST determine whether it has already received the LSA from another speaker. If it already has the current instance of the LSA in its database, it MUST do nothing further in terms of flooding the LSA (since it would have taken appropriate action when it initially received the LSA). However, if it does not have the current instance of the LSA in its database, it MUST take action according to the rules above, just as if it received the multicast LSA. The acknowledgment mechanism outlined in Section 3.3.9 MUST be followed, and any timeout mechanism for unicast LSAs MAY be followed.

3. 对于由于发起者的重新传输而被单播接收的LSA,节点必须确定它是否已经从另一个说话人接收到LSA。如果它的数据库中已经有LSA的当前实例,那么它就不能在淹没LSA方面做任何进一步的事情(因为它在最初收到LSA时会采取适当的措施)。但是,如果它的数据库中没有LSA的当前实例,它必须按照上面的规则采取行动,就像它收到多播LSA一样。必须遵循第3.3.9节中概述的确认机制,并且可以遵循单播LSA的任何超时机制。

Note that a node can determine whether further flooding an LSA will only result in a redundant transmission by already having heard link state acknowledgments (ACKs) or floods for the LSA from all of its neighbors.

注意,节点可以通过已经听到来自其所有邻居的链路状态确认(ack)或LSA的泛洪来确定进一步泛洪是否只会导致冗余传输。

Due to the dynamic nature of a network, the set of Active Overlapping Relays may not be up to date at the time the relay decision is made or may not be able to perform the flooding duties, e.g., due to poor link quality. The non-Active Overlapping Relays prevent this situation from causing database synchronization issues and, thus, packet loss.

由于网络的动态特性,在做出中继决定时,主动重叠中继集可能不是最新的,或者可能无法执行泛洪任务,例如,由于链路质量差。非活动重叠中继可防止这种情况导致数据库同步问题,从而导致数据包丢失。

Since the originator of the information, the relay, and the receiver are all in the same dynamically determined local flooding domain, the relay MUST NOT change the routing update information. In general, LSAs SHOULD be sent to a well-known multicast address. In some cases, routing updates MAY be sent using unicast packets.

由于信息的发起者、中继器和接收器都在相同的动态确定的本地泛洪域中,因此中继器不得更改路由更新信息。通常,LSA应该发送到众所周知的多播地址。在某些情况下,可以使用单播数据包发送路由更新。

3.3.9. Intelligent Transmission of Link State Acknowledgments
3.3.9. 链路状态确认的智能传输

In order to optimize the bandwidth utilization on the link, a speaker MUST follow these recommendations related to ACK transmissions:

为了优化链路上的带宽利用率,扬声器必须遵循以下与ACK传输相关的建议:

1. All ACKs MUST be sent via multicast.

1. 所有ACK必须通过多播发送。

2. Typically, LSAs are acknowledged by all of the adjacent speakers. In the case of relayed information, the relay MUST only expect

2. 通常,LSA由所有相邻的扬声器确认。对于中继信息,中继必须仅预期

either explicit or implicit acknowledgments from neighbors that have not previously acknowledged this LSA.

来自之前未确认此LSA的邻居的显式或隐式确认。

3. Because routing updates are sent via multicast, the set of overlapping speakers will usually receive the same update more than once. A speaker SHOULD only acknowledge the first update received on the link.

3. 因为路由更新是通过多播发送的,所以重叠的扬声器组通常会多次接收相同的更新。演讲者只应确认在链接上收到的第一次更新。

4. An Active Overlapping Relay SHOULD NOT explicitly acknowledge information that it is relaying. The relayed information will serve as an acknowledgment to the sender. If no information is being relayed, then an explicit ACK MUST be sent.

4. 主动重叠继电器不应明确确认其正在中继的信息。中继信息将作为对发送方的确认。如果未中继任何信息,则必须发送明确的ACK。

5. Several ACKs MAY be bundled into a single packet. The wait (AckInterval) before sending one such packet reduces the number of packet transmissions required in acknowledging multiple LSAs.

5. 可以将多个ack捆绑到单个数据包中。发送一个这样的分组之前的等待(确认间隔)减少了确认多个lsa所需的分组传输的数量。

6. All ACK packets SHOULD reset the RouterDeadInterval at the receiver. If there is no state waiting to be transmitted in a Hello packet at the sender, then the HelloInterval at the sender SHOULD be reset. Note that an ACK serves as a Hello packet with no state change.

6. 所有ACK数据包应在接收器处重置RouterDeadInterval。如果在发送方没有等待在Hello数据包中传输的状态,则应重置发送方的HelloInterval。请注意,ACK充当Hello数据包,状态不变。

7. Any LSA received via unicast MUST be acknowledged. (Note that acknowledgment is via multicast as specified in rule (1) above.)

7. 必须确认通过单播接收到的任何LSA。(请注意,按照上述规则(1)的规定,通过多播进行确认。)

An ACK received from a non-overlapping neighbor should prevent redundant transmission of the information to it by another overlapping relay.

从非重叠邻居接收的ACK应防止另一个重叠中继向其冗余传输信息。

3.3.10. Important Timers
3.3.10. 重要计时器

This section details the timers that were introduced in Sections 3.3.8 and 3.3.9.

本节详细介绍了第3.3.8节和第3.3.9节中介绍的计时器。

o PushbackInterval: The length of time in seconds that a non-Active Overlapping Relay SHOULD wait before further flooding an LSA if needed. This timer MUST be less than 1/2 of the RxmtInterval ([OSPF], [OSPFv3]) minus propagation delays, i.e., (PushbackInterval + propagation delay) < RxmtInterval/2. The PushbackInterval is set by a non-Active Overlapping Relay upon receipt of an LSA.

o PushbackInterval:如果需要,非活动重叠继电器在进一步淹没LSA之前应等待的时间长度(以秒为单位)。该计时器必须小于RxmtInterval([OSPF],[OSPFv3])减去传播延迟的1/2,即(回推间隔+传播延迟)<RxmtInterval/2。接收到LSA后,由非活动重叠继电器设置回推间隔。

o AckInterval: After a node determines that it must transmit an ACK and the AckInterval timer is not already set, the node SHOULD set the AckInterval timer. The AckInterval is the length of time in seconds that a node should wait in order to transmit many ACKs in the acknowledgment packet. This wait reduces the number of packet

o AckInterval:在节点确定它必须发送ACK且尚未设置AckInterval计时器后,该节点应设置AckInterval计时器。确认间隔是节点为在确认数据包中传输多个确认而应等待的时间长度(以秒为单位)。这种等待减少了数据包的数量

transmissions required in acknowledging multiple LSAs. The AckInterval MUST be less than the PushbackInterval minus propagation delays, i.e., (AckInterval + propagation delay) < PushbackInterval.

确认多个LSA所需的传输。AckInterval必须小于PushbackInterval减去传播延迟,即(AckInterval+传播延迟)<PushbackInterval。

3.3.11. Miscellaneous Protocol Considerations
3.3.11. 杂项议定书考虑事项

The mechanism described refers to the operation of relays on a common media segment. In other words, an LSA is only relayed out the same interface through which it was received. However, the concept of information relay may be extended to the flooding of all link state advertisements received on any interface (and forwarded on any other interface). OSPF works on the premise that all of the nodes in a flooding domain will receive all of the routing information. Note that one of the important properties is that the routing information is not altered when relayed.

所述机制是指公共媒体段上继电器的操作。换言之,LSA仅通过接收它的同一接口中继出去。然而,信息中继的概念可以扩展到在任何接口上接收(并在任何其他接口上转发)的所有链路状态广告的泛洪。OSPF的工作前提是泛洪域中的所有节点都将接收所有路由信息。请注意,其中一个重要属性是,中继时路由信息不会改变。

If each speaker advertised all of its adjacent neighbors on all interfaces, then the overlap check would result in the determination of which speakers are adjacent to both speakers. As a result, link state information should only be flooded to non-overlapping neighbors (taking all of the interfaces into account).

如果每个扬声器在所有接口上通告其所有相邻的相邻扬声器,则重叠检查将导致确定哪些扬声器与两个扬声器相邻。因此,链路状态信息应该只被淹没到非重叠的邻居(考虑到所有接口)。

The flooding mechanism in OSPF relies on a designated router to guarantee that any new LSA received by one router attached to the broadcast network will be re-flooded properly to all the other routers attached to the broadcast network. Such designated routers must be able to reach all of the other speakers on the same subnet. A designated router SHOULD NOT be elected if overlapping relays are used.

OSPF中的泛洪机制依赖于指定的路由器,以确保连接到广播网络的一个路由器接收到的任何新LSA将正确地重新泛洪到连接到广播网络的所有其他路由器。此类指定路由器必须能够连接到同一子网上的所有其他扬声器。如果使用重叠继电器,则不应选择指定的路由器。

If such designated routers already exist, then the relays MUST be capable of differentiating them and then making the relaying decisions based on the OSPF's normal operation. As a result, there may be groups of neighbors to which some information should not be relayed. This mode of operation is NOT RECOMMENDED, as it adds to the complexity of the system.

如果已经存在此类指定路由器,则中继必须能够区分它们,然后根据OSPF的正常操作做出中继决策。因此,可能存在一些信息不应中继到的邻居组。不建议使用这种操作模式,因为它会增加系统的复杂性。

The intent of the overlapping relay mechanism is to optimize flooding of routing control information. However, other information (such as data) may also be relayed in some networks using the same mechanism.

重叠中继机制的目的是优化路由控制信息的泛滥。然而,其他信息(例如数据)也可以使用相同的机制在一些网络中中继。

3.3.12. Interoperability
3.3.12. 互操作性

On receiving a Hello packet from a new neighbor without the F-bit set, the local router will assume that the new neighbor will flood normally as described in [OSPFv3]. Thus, the local router SHOULD include the neighbor in its overlapping relay set since the neighbor

当从没有F位集的新邻居接收到Hello数据包时,本地路由器将假设新邻居将正常泛洪,如[OSPFv3]中所述。因此,本地路由器应该在其重叠中继集中包括邻居,因为邻居

will flood by default. This will allow the local router to more optimally select its entire overlapping relay set.

默认情况下将泛滥。这将允许本地路由器更优化地选择其整个重叠中继集。

If the F-bit is set and the I-bit as defined in Section 3.2 is not set in the neighbor's Hello, and the neighbor is selected as an overlapping relay by the local router, the local router will continue to include the neighbor's identifier in its active relay set.

如果在邻居的Hello中设置了F位而没有设置第3.2节中定义的I位,并且本地路由器将邻居选择为重叠中继,则本地路由器将继续在其活动中继集中包括邻居的标识符。

3.4. New Bits in LLS Type 1 Extended Options and Flags
3.4. LLS类型1扩展选项和标志中的新位

Two new option bits are defined in the "LLS Type 1 Extended Options and Flags" Field [LLS] as follows:

“LLS类型1扩展选项和标志”字段[LLS]中定义了两个新选项位,如下所示:

o I-bit - defined in Section 3.2.1: The I-bit is only defined for Hello packets and indicates that only incremental information is present.

o I位-在第3.2.1节中定义:I位仅为Hello数据包定义,表示仅存在增量信息。

o F-bit - defined in Section 3.3.5: The F-bit indicates that the node supports the optimized flooding mechanism as specified in this document.

o F-bit——定义见第3.3.5节:F-bit表示节点支持本文件规定的优化泛洪机制。

3.5. Smart Peering
3.5. 聪明的窥视

There is significant overhead in OSPF when a router has to establish adjacencies with every peer with whom it can verify 2-way connectivity. OSPF supports the broadcast network type for these scenarios, where you only have to peer with the designated router (DR). However, a full mesh of connectivity is required for proper operation, and this doesn't help in networks with overlapping partial meshes of connectivity. This document proposes a technique to reduce the number of adjacencies based on shortest path tree (SPT) reachability information.

当路由器必须与每一个能够验证双向连接的对等方建立邻接时,OSPF会有很大的开销。OSPF支持这些场景中的广播网络类型,您只需与指定的路由器(DR)对等。但是,正确的操作需要完整的连通网格,而这对具有重叠的部分连通网格的网络没有帮助。本文提出了一种基于最短路径树(SPT)可达性信息减少邻接数的技术。

3.5.1. Rationale for Smart Peering
3.5.1. 智能对等的基本原理

In OSPF ([OSPF], [OSPFv3]), nodes establish an adjacency by first verifying 2-way connectivity between them and then synchronizing their link state databases. Once the peering relationship is complete and the adjacency is established, the nodes will continue to advertise each other in their LSAs. As a result, the peers are maintained in the link state database and are included in all SPF (Shortest Path First) calculations. During the reliable flooding process, a node must ensure that each peer has indeed received the flooded routing update via an acknowledgment and retransmission mechanism.

在OSPF([OSPF],[OSPFv3])中,节点通过首先验证它们之间的双向连接,然后同步它们的链路状态数据库来建立邻接关系。一旦对等关系完成并且邻接关系建立,节点将继续在其lsa中相互通告。因此,对等点被保存在链路状态数据库中,并包含在所有SPF(最短路径优先)计算中。在可靠泛洪过程中,节点必须确保每个对等方确实通过确认和重传机制接收到泛洪路由更新。

Consequently, maintaining an adjacency for a particular peer is a trade-off between the added redundancy in routing paths and network

因此,维持特定对等点的邻接是路由路径和网络中增加的冗余之间的权衡

reachability versus the associated overhead (memory consumption, SPF computations, routing overhead, and network convergence).

可达性与相关开销(内存消耗、SPF计算、路由开销和网络收敛)的对比。

Consider the possibility of reducing the number of adjacencies that a node maintains without compromising reachability and redundancy. This will have direct implications on network scalability and is especially attractive in environments where the network topology is dynamic. For example, in a mobile ad hoc network (MANET), where nodes are mobile and the topology is constantly changing, it seems highly desirable to 'intelligently' become adjacent with only selected peers and not establish a peering session with every node that comes within transmission range. Selective peering can be particularly useful in avoiding the peering process for unstable nodes, i.e., nodes that come in and out of transmission range.

考虑在不损害可达性和冗余的情况下减少节点保持的邻接数的可能性。这将对网络可伸缩性产生直接影响,在网络拓扑是动态的环境中尤其具有吸引力。例如,在移动自组织网络(MANET)中,节点是移动的,拓扑结构不断变化,因此非常希望“智能地”与选定的对等节点相邻,而不是与传输范围内的每个节点建立对等会话。选择性对等在避免不稳定节点(即进出传输范围的节点)的对等过程中特别有用。

3.5.2. Previous Related Work
3.5.2. 以前的相关工作

The formation of a FULL adjacency requires discovery (2-way relationship) and database synchronization. To prevent achieving the FULL state, others have taken the approach of modifying link state protocols to use periodic advertisements (instead of a database exchange). The result is that neighbor discovery is still required, but routing information is learned over time. An example of this approach is:

完全邻接的形成需要发现(双向关系)和数据库同步。为了防止达到完全状态,其他人采取了修改链路状态协议的方法,以使用定期播发(而不是数据库交换)。结果是仍然需要邻居发现,但路由信息会随着时间的推移而学习。这种方法的一个例子是:

o OSPFv2 Wireless Interface Type [WINTF]

o OSPFv2无线接口类型[WINTF]

* where the use of periodic advertisements "eliminates the formation of full adjacencies on wireless interfaces; all neighbor states beyond 2-Way are not reached,and no database synchronization is performed".

* 其中,使用周期性广告“消除了无线接口上完全邻接的形成;未达到双向以外的所有邻居状态,且未执行数据库同步”。

What we propose in this specification goes a step further by not requiring the formation and maintenance of neighbor state (2-way, or other) *and* without changing the route distribution mechanisms in the link state protocols. In other words, the mechanism described is completely backward compatible.

我们在本规范中提出的建议更进一步,在不改变链路状态协议中的路由分配机制的情况下,不需要形成和维护邻居状态(双向或其他)*和*。换句话说,所描述的机制是完全向后兼容的。

3.5.3. Smart Peering Solution
3.5.3. 智能对等解决方案

Two routers are defined as synchronized when they have identical link state databases. To limit the number of neighbors that are formed, an algorithm is needed to select which neighbors with whom to peer.

当两个路由器具有相同的链路状态数据库时,它们被定义为已同步。为了限制形成的邻居的数量,需要一种算法来选择与哪些邻居进行对等。

The algorithm MUST provide reachability to every possible destination in the network, just as when normal adjacency formation processes are used. We should always peer with a neighbor if it provides our only path to currently unreachable destinations.

该算法必须提供对网络中每个可能目的地的可达性,就像使用正常的邻接形成过程一样。如果邻居为我们提供了通往当前无法到达的目的地的唯一路径,那么我们应该始终与邻居进行对等。

3.5.3.1. SPT Reachability Heuristics
3.5.3.1. SPT可达性启发式算法

The peering decision is really a local matter to a router. If a router can ensure that reachability to other nodes is available without bringing up a new adjacency, it can choose not to bring up the new adjacency.

对等决定实际上是路由器的局部问题。如果一个路由器可以确保对其他节点的可达性是可用的,而不产生新的邻接,那么它可以选择不产生新的邻接。

We propose an algorithm that uses the existing information about a new neighbor's reachability in the SPT. If the two routers can already reach each other in the SPT, it is not necessary to form an adjacency between them.

我们提出了一种利用SPT中新邻居可达性的现有信息的算法。如果两个路由器已经可以在SPT中相互连接,则不必在它们之间形成邻接。

The decision to peer or not is made when a Hello is received. When a Hello is received from a new neighbor or a neighbor in a state lower than Exchange:

当收到Hello时,决定是否对等。当从新邻居或状态低于Exchange的邻居收到Hello时:

o A check is made in the link state database to see if the peer is already reachable in the SPT.

o 在链接状态数据库中进行检查,以查看对等方是否已经可以在SPT中访问。

* If the peer is either not known in the SPT or is not reachable, we start the Exchange process.

* 如果对等方在SPT中未知或无法访问,则启动交换过程。

* If the peer is reachable, then bringing up adjacency with this neighbor does not provide reachability to any new destinations.

* 如果对等方是可访问的,则与该邻居建立邻接关系不会提供到任何新目的地的可访问性。

Let's take an example of a single OSPF area. This check would look for the neighbor's router-LSA. If the LSA is present in the database and is reachable in the SPT, we have a chance to suppress adjacency formation.

让我们以单个OSPF区域为例。此检查将查找邻居的路由器LSA。如果LSA存在于数据库中并且可以在SPT中访问,则我们有机会抑制邻接形成。

It's worth noting that as the number of links and redundancy in the network is reduced, the likelihood of suboptimal routing increases.

值得注意的是,随着网络中链路和冗余数量的减少,次优路由的可能性增加。

3.5.3.2. State Machine
3.5.3.2. 状态机

The state machine of a basic implementation of this algorithm is provided below. An implementation MAY use some heuristics (Step (3) below), beyond the SPT reachability, to decide whether or not it considers a new adjacency to be of value.

下面提供了该算法的基本实现的状态机。在SPT可达性之外,实现可以使用一些启发式(下面的步骤(3))来决定它是否认为新的邻接有价值。

                        ......................
                        |Receive a Hello     |
                    (1) |from a new potential|
                        |neighbor            |
                        '`''''''''''''''''''''
                                  |
                                  |
                                  |
                        ,''''''''''''''''''''''|
                        |Check to see if there |
                    (2) |is a router-LSA from  |----no--(4)form a
                        |the new potential     |          new
                        |neighbor in the link  |          neighbor
                        |state database, which |
                        |is reachable in SPT   |
                        '`''''''''''''''''''''''
                                  |
                                  |yes
         (3)                      |
      ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
      |                            (3b)........................ |
      |(3a),______________________     |Determine if the      | |
      |    |Determine if the new |     |number of redundant   | |
      |    |link cost is better  |     |paths to the potential| |
      |    |than the current path|     |neighbor is < the     | |
      |    |cost by a configured |     |maximum configured    | |
      |    |amount               |     |value                 | |
      |    '`'''''''''''''''''''''     '`'''''''''''''''''''''' |
      |                       \             /                   |
      |                   .....\.........../....                |
      |                   |User configurable   |                |
      |                   |selection algorithm |                |
      |                   '`'''/'''''''\''''''''                |
      |                       /         \                       |
      '`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
                            /             \
                     requirements     requirements
                        met              not met
                        /                    \
                       /                      \
           (4) form a new neighbor      (5) do not become
                                            neighbors
        
                        ......................
                        |Receive a Hello     |
                    (1) |from a new potential|
                        |neighbor            |
                        '`''''''''''''''''''''
                                  |
                                  |
                                  |
                        ,''''''''''''''''''''''|
                        |Check to see if there |
                    (2) |is a router-LSA from  |----no--(4)form a
                        |the new potential     |          new
                        |neighbor in the link  |          neighbor
                        |state database, which |
                        |is reachable in SPT   |
                        '`''''''''''''''''''''''
                                  |
                                  |yes
         (3)                      |
      ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
      |                            (3b)........................ |
      |(3a),______________________     |Determine if the      | |
      |    |Determine if the new |     |number of redundant   | |
      |    |link cost is better  |     |paths to the potential| |
      |    |than the current path|     |neighbor is < the     | |
      |    |cost by a configured |     |maximum configured    | |
      |    |amount               |     |value                 | |
      |    '`'''''''''''''''''''''     '`'''''''''''''''''''''' |
      |                       \             /                   |
      |                   .....\.........../....                |
      |                   |User configurable   |                |
      |                   |selection algorithm |                |
      |                   '`'''/'''''''\''''''''                |
      |                       /         \                       |
      '`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
                            /             \
                     requirements     requirements
                        met              not met
                        /                    \
                       /                      \
           (4) form a new neighbor      (5) do not become
                                            neighbors
        
3.5.4. Advertising 2-Way Links in Router-LSAs
3.5.4. 路由器LSA中的双向链路广告

The technique described in Section 3.5.3 minimizes the number of adjacencies in highly meshed environments. This is especially useful when the network is in motion and the average adjacency lifetime is small.

第3.5.3节中描述的技术将高度网格化环境中的邻接数量降至最低。当网络处于运动状态且平均邻接寿命较小时,这一点尤其有用。

However, it suffers from an undesirable side effect of limiting the number of transit links available to forward traffic.

但是,它会受到限制可用于转发流量的中转链路数量的不良副作用的影响。

An implementation may choose to allow some (or even all) of these 2-way state neighbors to be announced in the router-LSA. Since the state remains 2-way, we don't incur control plane (database sync and flooding) overhead. However, advertising the link in the router-LSA makes the link available to the data plane.

实现可以选择允许在路由器LSA中宣布这些双向状态邻居中的一些(甚至全部)。由于状态仍然是双向的,因此不会产生控制平面(数据库同步和泛洪)开销。然而,在路由器LSA中公布链路使得链路可用于数据平面。

This can be safely done if the neighbor is reachable in a special SPT constructed by ignoring any other 2-way links in the network. This optional optimization is described below.

如果邻居可以通过忽略网络中任何其他双向链路而构造的特殊SPT访问,则可以安全地完成此操作。此可选优化如下所述。

3.5.4.1. Unsynchronized Adjacencies
3.5.4.1. 非同步邻接

If the new neighbor is already reachable in the SPT, there is no urgency in doing a full database sync with it. These are the steps we need to perform when a neighbor has reached 2-way state.

如果新邻居在SPT中已经可以访问,那么与它进行完全数据库同步就没有什么紧迫性。当邻居达到双向状态时,我们需要执行以下步骤。

Note that when we say "SPT" in this section, we mean the special SPT constructed based on rules in Section 3.5.4.2.

请注意,当我们在本节中说“SPT”时,我们指的是根据第3.5.4.2节中的规则构建的特殊SPT。

o After a 2-WayReceived event, check if the neighbor is reachable in the SPT. If yes, mark the neighbor as FULL with respect to link advertisement.

o 在双向接收事件后,检查SPT中是否可以到达邻居。如果是,就链接广告将邻居标记为已满。

o This means that the router-LSA or network-LSA link corresponding to the neighbor is advertised as if the neighbor is FULL.

o 这意味着与邻居对应的路由器LSA或网络LSA链路被通告,就好像邻居已满一样。

o The adjacency information is constructed with the U-bit (see below).

o 邻接信息由U位构成(见下文)。

o Database synchronization is postponed:

o 数据库同步被推迟:

* By a configured amount of time -OR-

* 按配置的时间量-或-

* Until the time it's absolutely "necessary"

* 直到绝对“必要”的时候

In either case, if a database sync is currently pending, it is started as soon as we detect that the neighbor is no longer reachable in the SPT. The database sync can be done by Out-of-Band Sync [OOB],

在任何一种情况下,如果数据库同步当前处于挂起状态,则在我们检测到SPT中的邻居不再可访问时,将立即启动同步。数据库同步可以通过带外同步[OOB]完成,

which maintains the current adjacency and does the sync in the background. A normal resync can alternately be done with the drawback of adjacency flap.

它保持当前的邻接并在后台进行同步。一个正常的再同步可以交替地完成与邻近皮瓣的缺点。

In standard OSPF, we first bring up adjacency and then announce a transit link. The approach described above allows the link to be used as a forwarding path very quickly and still allows the database to be synchronized in a timely fashion when the alternate flooding path has recently been broken.

在标准OSPF中,我们首先提出邻接,然后宣布一个中转链路。上述方法允许非常快速地将链路用作转发路径,并且当备用泛洪路径最近被破坏时,仍然允许及时同步数据库。

There is a circular dependency issue that also needs to be resolved. Once you start announcing the link, the shortest path will likely be via this very link. So it's non-trivial to detect when the alternate dependent path is gone. We would like to be able to detect that the neighbor is reachable via a path that doesn't traverse an unsynchronized path.

还有一个循环依赖性问题也需要解决。一旦你开始宣布链接,最短的路径很可能就是通过这个链接。因此,检测替代依赖路径何时消失是非常重要的。我们希望能够通过一条不经过非同步路径的路径来检测邻居是否可以到达。

We have generally solved this class of problems by running an SPF and pretending that the link in question doesn't exist. It doesn't require a full SPF, but just enough to see if ANY other path is available to reach the neighbor. The worst case is when the alternate path is really gone, which we find that out by building a full SPT. This needs to be done every time the link state database changes, and for EACH link that has SPT dependence for its viability. This approach has scalability concerns and is not considered further here.

我们通常通过运行SPF并假装相关链接不存在来解决这类问题。它不需要一个完整的SPF,只需要看看是否有其他路径可以到达邻居。最坏的情况是当备用路径真的消失时,我们通过构建一个完整的SPT来发现这一点。这需要在每次链接状态数据库更改时进行,并且对于每个对其生存能力具有SPT依赖性的链接。这种方法存在可伸缩性问题,此处不再进一步讨论。

We can achieve the same results with just ONE additional SPF that is capable of ignoring these Unsynchronized links. The result from this SPT can be used to satisfy the reachability condition for ANY number of Unsynchronized Adjacencies. This basically requires that we can actually tell the difference between a normal FULL adjacency and this new Unsynchronized Adjacency. We can do this in one of two ways:

我们只需使用一个能够忽略这些不同步链路的附加SPF即可获得相同的结果。该SPT的结果可用于满足任意数量的非同步邻接的可达性条件。这基本上要求我们能够区分正常的完全邻接和新的非同步邻接。我们可以通过以下两种方式之一实现:

(A) Defining LD Options and using a bit in it, as shown below:

(A) 定义LD选项并在其中使用位,如下所示:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   LD Options  |          Metric               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Neighbor Interface ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Neighbor Router ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   LD Options  |          Metric               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Neighbor Interface ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Neighbor Router ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Link Description in a Router-LSA

路由器LSA中的链路描述

LD Options Link Description options. Used to specify some special capability or state of a link.

LD选项链接描述选项。用于指定链接的某些特殊功能或状态。

                               +-+-+-+-+-+-+-+-+
                               | | | | | | | |U|
                               +-+-+-+-+-+-+-+-+
        
                               +-+-+-+-+-+-+-+-+
                               | | | | | | | |U|
                               +-+-+-+-+-+-+-+-+
        

LD Options

LD选项

U-bit The "Unsynchronized" bit. This is set if the adjacency is being announced before databases are fully synchronized.

U位“未同步”位。如果在数据库完全同步之前宣布相邻关系,则会设置此选项。

This approach is backward compatible, because the only routers looking at this bit are those that support the mechanisms specified in this document.

这种方法是向后兼容的,因为查看此位的路由器只有那些支持本文档中指定的机制的路由器。

(B) Introducing a new link type in router-LSA.

(B) 在路由器LSA中引入一种新的链路类型。

This is a much more complex solution, with backward compatibility concerns, due to the fact that unknown link type handling is not defined in the OSPF standard [OSPF]. Hence, this solution isn't considered further.

由于OSPF标准[OSPF]中未定义未知链路类型处理,这是一个更复杂的解决方案,具有向后兼容性问题。因此,不再进一步考虑此解决方案。

3.5.4.2. Unsynchronized SPT
3.5.4.2. 非同步SPT

Whenever link state changes happen, we need to run ONE additional SPF by ignoring all links with the U-bit set. This SPT is then consulted to see if any of our Unsynchronized Adjacencies need to start database sync. This SPT is also consulted when a new neighbor goes into 2-way state to decide if we should form the adjacency immediately or defer it for later.

无论何时发生链接状态更改,我们都需要通过忽略U位集的所有链接来运行一个额外的SPF。然后咨询此SPT,查看是否有任何未同步的邻接需要启动数据库同步。当一个新邻居进入双向状态时,也会参考该SPT来决定是立即形成邻接还是推迟形成邻接。

3.5.4.3. Flooding Considerations
3.5.4.3. 洪水考虑

One of the main goals in trying to delay the database synchronization is to be able to reduce unnecessary OSPF packets traversing these links. Since the unsynchronized Adjacencies remain in 2-way state, OSPF updates will not be flooded over the corresponding interfaces, resulting in additional savings.

尝试延迟数据库同步的主要目标之一是能够减少通过这些链路的不必要的OSPF数据包。由于未同步的邻接保持在双向状态,OSPF更新将不会淹没在相应的接口上,从而带来额外的节省。

An option is provided to enable or disable flooding over these Unsynchronized Adjacencies. The advantage of allowing flooding is being able to use more links for control plane purposes. We will still have the savings of not having to form the adjacency.

提供了一个选项来启用或禁用这些非同步邻接上的泛洪。允许泛洪的优点是能够为控制平面目的使用更多链接。我们仍然可以节省不必形成邻接的费用。

3.5.4.4. Overlapping Relay (OR) Election Impact
3.5.4.4. 重叠接力(或)选举影响

The overlapping relay election algorithm uses the 2-hop neighborhood it gleans from our neighbor's router-LSAs. The introduction of Unsynchronized Adjacencies needs to be considered in the relay election algorithm.

重叠中继选举算法使用它从邻居的路由器LSA收集的2跳邻居。在中继选举算法中需要考虑引入非同步邻接。

If flooding is enabled on unsynchronized Adjacencies, no change is needed in the relay election algorithm. If flooding is disabled, then the relay election algorithm needs to prune neighbors that are connected via an Unsynchronized Adjacency from our 1-hop and 2-hop neighbor lists.

如果在未同步的邻接上启用泛洪,则不需要更改中继选择算法。如果禁用泛洪,则中继选举算法需要从1-hop和2-hop邻居列表中修剪通过非同步邻接连接的邻居。

4. Security Considerations
4. 安全考虑

In a MANET, security is both more difficult and important, due to the wireless nature of the medium. Controlling the ability of devices to connect to a MANET at Layer 2 will be relegated to Layer 2 security mechanisms, such as 802.1x, and others. Controlling the ability of attached devices to transmit traffic will require some type of security system (outside the scope of this document) that can authenticate, and provide authorization for, individual members of the routing domain.

在MANET中,由于介质的无线性质,安全性更为困难和重要。控制设备在第2层连接到MANET的能力将被降级到第2层安全机制,如802.1x和其他。控制连接设备传输流量的能力需要某种类型的安全系统(不在本文档范围内),该系统可以对路由域的各个成员进行身份验证并提供授权。

Additional security considerations are similar to any MANET protocol extension. The following text is from [MDR]:

附加的安全注意事项类似于任何MANET协议扩展。以下文本来自[MDR]:

As with OSPFv3 [OSPFv3], OSPF-OR can use the IPv6 Authentication Header (AH) [AH] and/or the IPv6 Encapsulation Security Payload (ESP) [ESP] to provide authentication, integrity, and/or confidentiality. The use of AH and ESP for OSPFv3 is described in [OSPFv3-SEC].

与OSPFv3[OSPFv3]一样,OSPF-OR可以使用IPv6身份验证头(AH)[AH]和/或IPv6封装安全负载(ESP)[ESP]来提供身份验证、完整性和/或机密性。[OSPFv3 SEC]中描述了AH和ESP在OSPFv3中的使用。

Generic threats to routing protocols are described and categorized in [THREATS]. The mechanisms described in [OSPFv3-SEC] provide protection against many of these threats, but not all of them. In particular, as mentioned in [OSPFv3], these mechanisms do not provide protection against compromised, malfunctioning, or misconfigured routers (also called Byzantine routers); this is true for both OSPFv3 and OSPF-OR.

对路由协议的一般威胁在[威胁]中进行了描述和分类。[OSPFv3 SEC]中描述的机制可针对许多此类威胁提供保护,但并非所有威胁。特别是,如[OSPFv3]中所述,这些机制不提供针对受损、故障或配置错误的路由器(也称为拜占庭路由器)的保护;OSPFv3和OSPF-OR都是如此。

The extension of OSPFv3 to include MANET routers does not introduce any new security threats. However, the use of a wireless medium and lack of infrastructure, inherent with MANET routers, may render some of the attacks described in [THREATS] easier to mount. Depending on the network context, these increased vulnerabilities may increase the need to provide authentication, integrity, and/or confidentiality, as well as anti-replay service.

将OSPFv3扩展到包括MANET路由器不会引入任何新的安全威胁。然而,由于MANET路由器固有的无线介质的使用和基础设施的缺乏,可能使[威胁]中描述的一些攻击更容易实施。根据网络环境,这些增加的漏洞可能会增加提供身份验证、完整性和/或机密性以及反重播服务的需要。

For example, sniffing of routing information and traffic analysis are easier tasks with wireless routers than with wired routers, since the attacker only needs to be within the radio range of a router. The use of confidentiality (encryption) provides protection against sniffing but not traffic analysis.

例如,无线路由器比有线路由器更容易嗅探路由信息和流量分析,因为攻击者只需要在路由器的无线电范围内。使用保密性(加密)可以防止嗅探,但不能防止流量分析。

Similarly, interference attacks are also easier to mount against MANET routers due to their wireless nature. Such attacks can be mounted even if OSPF packets are protected by authentication and confidentiality, e.g., by transmitting noise or replaying outdated OSPF packets. As discussed below, an anti-replay service (provided by both ESP and AH) can be used to protect against the latter attack.

同样,由于MANET路由器的无线特性,干扰攻击也更容易针对其进行。即使OSPF数据包受到身份验证和机密性的保护,例如通过传输噪声或重放过时的OSPF数据包,也可以发起此类攻击。如下文所述,反重播服务(由ESP和AH提供)可用于防范后一种攻击。

The following threat actions are also easier with MANET routers: spoofing (assuming the identity of a legitimate router), falsification (sending false routing information), and overloading (sending or triggering an excessive amount of routing updates). These attacks are only possible if authentication is not used, or the attacker takes control of a router or is able to forge legitimacy (e.g., by discovering the cryptographic key).

对于MANET路由器,以下威胁操作也更容易:欺骗(假设合法路由器的身份)、伪造(发送虚假路由信息)和过载(发送或触发过多的路由更新)。只有在未使用身份验证、攻击者控制路由器或能够伪造合法性(例如,通过发现加密密钥)的情况下,这些攻击才可能发生。

[OSPFv3-SEC] mandates the use of manual keying when current IPsec protocols are used with OSPFv3. Routers are required to use manually configured keys with the same security association (SA) parameters for both inbound and outbound traffic. For MANET routers, this implies that all routers attached to the same MANET must use the same key for multicasting packets. This is required in order to achieve scalability and feasibility, as explained in [OSPFv3-SEC]. Future specifications can explore the use of automated key management protocols that may be suitable for MANETs.

当当前IPsec协议与OSPFv3一起使用时,[OSPFv3 SEC]强制使用手动键控。路由器需要为入站和出站流量使用具有相同安全关联(SA)参数的手动配置密钥。对于MANET路由器,这意味着连接到同一MANET的所有路由器必须使用相同的密钥进行多播数据包。这是实现可扩展性和可行性所必需的,如[OSPFv3 SEC]中所述。未来的规范可以探索适用于MANET的自动密钥管理协议的使用。

As discussed in [OSPFv3-SEC], the use of manual keys can increase vulnerability. For example, manual keys are usually long lived, thus giving an attacker more time to discover the keys. In addition, the use of the same key on all routers attached to the same MANET leaves all routers insecure against impersonation attacks if any one of the routers is compromised.

如[OSPFv3节]所述,使用手动密钥会增加漏洞。例如,手动密钥通常寿命较长,因此攻击者有更多的时间发现密钥。此外,在连接到同一MANET的所有路由器上使用相同的密钥会使所有路由器在任何一个路由器受到攻击时都不安全。

Although [AH] and [ESP] state that implementations of AH and ESP SHOULD NOT provide anti-replay service in conjunction with SAs that are manually keyed, it is important to note that such service is allowed if the sequence number counter at the sender is correctly maintained across local reboots until the key is replaced. Therefore, it may be possible for MANET routers to make use of the anti-replay service provided by AH and ESP.

尽管[AH]和[ESP]指出AH和ESP的实现不应与手动键入的SAs一起提供反重放服务,但需要注意的是,如果发送方的序列号计数器在本地重新启动过程中得到正确维护,直到密钥被替换,则允许提供此类服务。因此,MANET路由器可以利用AH和ESP提供的反重放服务。

When an OSPF routing domain includes both MANETs and fixed networks, the frequency of OSPF updates either due to actual topology changes or malfeasance could result in instability in the fixed networks. In situations where this is a concern, it is recommended that the border routers segregate the MANETs from the fixed networks with either separate OSPF areas or, in cases where legacy routers are very sensitive to OSPF update frequency, separate OSPF instances. With separate OSPF areas, the 5-second MinLSInterval will dampen the frequency of changes originated in the MANETs. Additionally, OSPF ranges can be configured to aggregate prefixes for the areas supporting MANETs. With separate OSPF instances, more conservative local policies can be employed to limit the volume of updates emanating from the MANETs.

当OSPF路由域同时包括MANET和固定网络时,由于实际拓扑变化或故障导致的OSPF更新频率可能会导致固定网络不稳定。在这种情况下,建议边界路由器使用单独的OSPF区域或在传统路由器对OSPF更新频率非常敏感的情况下,使用单独的OSPF实例将MANET与固定网络隔离。对于单独的OSPF区域,5秒的MinlInterval将降低源自MANET的变化频率。此外,OSPF范围可配置为聚合支持MANET的区域的前缀。对于单独的OSPF实例,可以采用更保守的本地策略来限制从MANET发出的更新量。

5. IANA Considerations
5. IANA考虑

IANA has made the assignments as explained below using the policies outlined in [IANA].

IANA使用[IANA]中概述的政策完成了如下所述的任务。

o I-bit and F-bit from "LLS Type 1 Extended Options and Flags" registry as defined below:

o “LLS类型1扩展选项和标志”注册表中的I位和F位定义如下:

   +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
   | * | * | * | * | * | * | * |...| * | * | * | * | F | I | RS| LR|
   +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
        
   +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
   | * | * | * | * | * | * | * |...| * | * | * | * | F | I | RS| LR|
   +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
        

Bits in Extended Options and Flags TLV

扩展选项和标志TLV中的位

o New TLV types from the "Link Local Signalling TLV Identifiers (LLS Types)" registry as defined below:

o “链路本地信令TLV标识符(LLS类型)”注册表中的新TLV类型定义如下:

      TLV Name                      TLV Type
      --------                      --------
      State Check Sequence TLV          6
      Neighbor Drop TLV                 7
      Request From TLV                  8
      Full State For TLV                9
      Active Overlapping Relay TLV      10
      Willingness TLV                   11
        
      TLV Name                      TLV Type
      --------                      --------
      State Check Sequence TLV          6
      Neighbor Drop TLV                 7
      Request From TLV                  8
      Full State For TLV                9
      Active Overlapping Relay TLV      10
      Willingness TLV                   11
        

o A new registry has been defined for LD Options as defined in Section 3.5.4.1. The U-bit is allocated by this document.

o 已为第3.5.4.1节中定义的LD选项定义了一个新注册表。U位由本文档分配。

All future additions to LD Options are subject to OSPF WG review and require IETF Review.

LD选项的所有未来新增内容均需经过OSPF工作组审查,并需要IETF审查。

6. Contributors
6. 贡献者

The following persons are contributing authors to the document:

以下人员是该文件的撰稿人:

Fred Baker Dave Cook Cisco Systems Cisco Systems 1121 Via Del Rey 7025-4 Kit Creek Road Santa Barbara, CA 93117 Research Triangle Park, NC 27709 USA USA EMail: fred@cisco.com EMail: dacook@cisco.com

Fred Baker Dave Cook Cisco Systems Cisco Systems 1121经加利福尼亚州圣巴巴拉Kit Creek路4号Del Rey 7025-4邮编:93117美国北卡罗来纳州三角研究公园邮编:27709电子邮件:fred@cisco.com电邮:dacook@cisco.com

Alvaro Retana Yi Yang Cisco Systems Cisco Systems 7025-4 Kit Creek Road 7025-4 Kit Creek Road Research Triangle Park, NC 27709 Research Triangle Park, NC 27709 USA USA EMail: aretana@cisco.com EMail: yiya@cisco.com

Alvaro Retana Yi Yang Cisco Systems Cisco Systems 7025-4 Kit Creek Road 7025-4 Kit Creek Road Research Triangle Park,NC 27709 Research Triangle Park,NC 27709美国电子邮件:aretana@cisco.com电邮:yiya@cisco.com

Russ White Cisco Systems 7025-4 Kit Creek Road Research Triangle Park, NC 27709 USA EMail: riw@cisco.com

Russ White Cisco Systems 7025-4 Kit Creek Road Research Triangle Park,NC 27709美国电子邮件:riw@cisco.com

7. Acknowledgments
7. 致谢

The authors and contributors would like to thank Pratap Pellakuru and Stan Ratliff for their feedback and implementation of the document. Thanks to Richard Ogier and John Avery for doing a final review.

作者和撰稿人感谢Pratap Pellakuru和Stan Ratliff对本文件的反馈和实施。感谢Richard Ogier和John Avery做了最后的回顾。

8. References
8. 工具书类
8.1. Normative References
8.1. 规范性引用文件

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

[OSPF]Moy,J.,“OSPF版本2”,STD 54,RFC 23281998年4月。

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

[OSPFv3]Coltun,R.,Ferguson,D.,Moy,J.,和A.Lindem,“IPv6的OSPF”,RFC 53402008年7月。

[LLS] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.

[LLS]Zinin,A.,Roy,A.,Nguyen,L.,Friedman,B.,和D.Yeung,“OSPF链路本地信令”,RFC 56132009年8月。

[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[IANA]Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 5226,2008年5月。

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

[关键词]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

8.2. Informative References
8.2. 资料性引用

[IPV6ADD] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[IPV6ADD]Hinden,R.和S.Deering,“IP版本6寻址体系结构”,RFC 42912006年2月。

[OSPFGR] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.

[OSPFGR]Moy,J.,Pillay Esnault,P.,和A.Lindem,“优雅的OSPF重启”,RFC 36232003年11月。

[OSPFREST] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, March 2007.

[OSPFREST]Nguyen,L.,Roy,A.,和A.Zinin,“OSPF重启信号”,RFC 4812,2007年3月。

[OOB] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link State Database (LSDB) Resynchronization", RFC 4811, March 2007.

[OOB]Nguyen,L.,Roy,A.,和A.Zinin,“OSPF带外链路状态数据库(LSDB)再同步”,RFC 48112007年3月。

[OLSR] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.

[OLSR]Clausen,T.,Ed.,和P.Jacquet,Ed.,“优化链路状态路由协议(OLSR)”,RFC 3626,2003年10月。

[WINTF] Ahrenholz J., et al., "OSPFv2 Wireless Interface Type", Work in Progress, May 2004.

[WINTF]Ahrenholz J.等人,“OSPFv2无线接口类型”,正在进行的工作,2004年5月。

[MDR] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, August 2009.

[MDR]Ogier,R.和P.Spagnolo,“使用连接支配集(CDS)泛洪对OSPF的移动自组织网络(MANET)扩展”,RFC 5614,2009年8月。

[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[AH]Kent,S.,“IP认证头”,RFC 4302,2005年12月。

[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[ESP]Kent,S.,“IP封装安全有效负载(ESP)”,RFC 4303,2005年12月。

[OSPFv3-SEC] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.

[OSPFv3 SEC]Gupta,M.和N.Melam,“OSPFv3的认证/保密”,RFC 45522006年6月。

[THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.

[威胁]Barbir,A.,Murphy,S.,和Y.Yang,“路由协议的一般威胁”,RFC 4593,2006年10月。

Authors' Addresses

作者地址

Abhay Roy (Editor) Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA EMail: akr@cisco.com

Abhay Roy(编辑)Cisco Systems 170 W.Tasman Drive San Jose,CA 95134美国电子邮件:akr@cisco.com

Madhavi W. Chandra (Editor) 113 Holmhurst Court Cary, NC 27519

Madhavi W.Chandra(编辑)113 Holmhurst Court Cary,北卡罗来纳州27519

   EMail: mw.chandra@gmail.com
        
   EMail: mw.chandra@gmail.com