Internet Engineering Task Force (IETF) N. Sheth
Request for Comments: 6845 Contrail Systems
Updates: 2328, 5340 L. Wang
Category: Standards Track J. Zhang
ISSN: 2070-1721 Juniper Networks
January 2013
Internet Engineering Task Force (IETF) N. Sheth
Request for Comments: 6845 Contrail Systems
Updates: 2328, 5340 L. Wang
Category: Standards Track J. Zhang
ISSN: 2070-1721 Juniper Networks
January 2013
OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
OSPF混合广播和点对多点接口类型
Abstract
摘要
This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.
本文档描述了一种将广播网络建模为广播和点对多点网络混合的机制，用于OSPF操作。邻居发现和维护以及链路状态公告（LSA）数据库同步是使用广播模型执行的，但是网络是使用连接到它的路由器的路由器LSA中的点对多点模型来表示的。这允许准确表示网络上不同路由器之间的通信成本，同时保持广播操作的网络效率。这种方法相对简单，只需要对OSPF进行最小的更改。
This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340).
本文档更新了OSPFv2（RFC2328）和OSPFv3（RFC5340）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6845.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6845.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 4
4.2. Neighbor Data Structure . . . . . . . . . . . . . . . . . . 4
4.3. Neighbor Discovery and Maintenance . . . . . . . . . . . . 5
4.4. Database Synchronization . . . . . . . . . . . . . . . . . 5
4.5. Generating Network-LSAs . . . . . . . . . . . . . . . . . . 5
4.6. Generating Router and Intra-Area-Prefix-LSAs . . . . . . . 5
4.6.1. Stub Links in OSPFv2 Router-LSA . . . . . . . . . . . . 6
4.6.2. OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . . 6
4.7. Next-Hop Calculation . . . . . . . . . . . . . . . . . . . 6
4.8. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 6
5. Compatibility Considerations . . . . . . . . . . . . . . . . . 6
6. Scalability and Deployment Considerations . . . . . . . . . . . 7
7. Management Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 4
4.2. Neighbor Data Structure . . . . . . . . . . . . . . . . . . 4
4.3. Neighbor Discovery and Maintenance . . . . . . . . . . . . 5
4.4. Database Synchronization . . . . . . . . . . . . . . . . . 5
4.5. Generating Network-LSAs . . . . . . . . . . . . . . . . . . 5
4.6. Generating Router and Intra-Area-Prefix-LSAs . . . . . . . 5
4.6.1. Stub Links in OSPFv2 Router-LSA . . . . . . . . . . . . 6
4.6.2. OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . . 6
4.7. Next-Hop Calculation . . . . . . . . . . . . . . . . . . . 6
4.8. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 6
5. Compatibility Considerations . . . . . . . . . . . . . . . . . 6
6. Scalability and Deployment Considerations . . . . . . . . . . . 7
7. Management Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
OSPF [RFC2328] operation on broadcast interfaces takes advantage of the broadcast capabilities of the underlying medium for doing neighbor discovery and maintenance. Further, it uses a Designated Router (DR) and Backup Designated Router (BDR) to keep the Link State Advertisement (LSA) databases of the routers on the network synchronized in an efficient manner. However, it has the limitation that a router cannot advertise different costs to each of the neighboring routers on the network in its router-LSA.
广播接口上的OSPF[RFC2328]操作利用底层媒体的广播功能进行邻居发现和维护。此外，它使用指定路由器（DR）和备份指定路由器（BDR）以有效方式保持网络上路由器的链路状态公告（LSA）数据库的同步。然而，它有一个局限性，即路由器不能在其路由器LSA中向网络上的每个相邻路由器公布不同的成本。
Consider a radio network that supports true broadcast, yet the metrics between different pairs of terminals could be different for various reasons (e.g., different signal strength due to placement). When running OSPF over the radio network, for a router to advertise different costs to different neighbors, the interface must be treated as point-to-multipoint (P2MP), even though the network has true broadcast capability.
考虑支持真实广播的无线网络，但是不同终端对之间的度量由于各种原因（例如，由于放置而不同的信号强度）可能是不同的。在无线网络上运行OSPF时，为了让路由器向不同的邻居公布不同的成本，接口必须被视为点对多点（P2MP），即使网络具有真正的广播能力。
Operation on point-to-multipoint interfaces could require explicit configuration of the identity of neighboring routers. It also requires the router to send separate Hellos to each neighbor on the network. Further, it mandates establishment of adjacencies to all configured or discovered neighbors on the network. However, it gives the routers the flexibility to advertise different costs to each of the neighboring routers in their router-LSAs.
点对多点接口上的操作可能需要明确配置相邻路由器的标识。它还要求路由器向网络上的每个邻居发送单独的hello。此外，它还要求与网络上所有已配置或已发现的邻居建立邻接。然而，它使路由器能够灵活地在其路由器LSA中向每个相邻路由器公布不同的成本。
This document proposes a new interface type that can be used on networks that have broadcast capability. In this mode, neighbor discovery and maintenance, as well as database synchronization are performed using existing procedures for broadcast mode. The network is modeled as a collection of point-to-point links in the router-LSA, just as it would be in point-to-multipoint mode. This new interface type is referred to as hybrid-broadcast-and-P2MP in the rest of this document.
本文件提出了一种新的接口类型，可用于具有广播功能的网络。在此模式下，使用广播模式的现有过程执行邻居发现和维护以及数据库同步。网络被建模为路由器LSA中点对点链路的集合，就像它在点对多点模式中一样。在本文档的其余部分中，这种新的接口类型称为hybrid-broadcast-and-P2MP。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
There are some networks that are broadcast capable but have a potentially different cost associated with communication between any given pair of nodes. The cost could be based on the underlying
有些网络具有广播功能，但与任何给定节点对之间的通信相关的成本可能不同。成本可以基于基础成本
topology as well as various link quality metrics such as bandwidth, delay, and jitter, among others.
拓扑以及各种链路质量指标，如带宽、延迟和抖动等。
It is not accurate to treat such networks as OSPF broadcast networks since that does not allow a router to advertise a different cost to each of the other routers. Using OSPF point-to-multipoint mode would satisfy the requirement to correctly describe the cost to reach each router. However, it would be inefficient in the sense that it would require forming O(N^2) adjacencies when there are N routers on the network.
将此类网络视为OSPF广播网络是不准确的，因为这不允许路由器向每个其他路由器公布不同的成本。使用OSPF点对多点模式将满足正确描述到达每个路由器的成本的要求。然而，当网络上有N个路由器时，它需要形成O（N^2）邻接，这将是低效的。
It is advantageous to use the hybrid-broadcast-and-P2MP type for such networks. This combines the flexibility of point-to-multipoint type with the advantages and efficiencies of broadcast interface type.
对于这样的网络，使用混合广播和P2MP类型是有利的。这将点对多点类型的灵活性与广播接口类型的优势和效率结合起来。
OSPF routers supporting the capabilities described herein should have support for an additional hybrid-broadcast-and-P2MP type for the Type data item described in Section 9 of [RFC2328].
支持本文所述功能的OSPF路由器应支持[RFC2328]第9节所述类型数据项的额外混合广播和P2MP类型。
The following sub-sections describe salient aspects of OSPF operation on routers configured with a hybrid-broadcast-and-P2MP interface.
以下小节描述了OSPF在配置了混合广播和P2MP接口的路由器上运行的主要方面。
The "Router Priority" interface parameter as specified in OSPFv2 [RFC2328] and OSPFv3 [RFC5340] applies to a hybrid-broadcast-and-P2MP interface.
OSPFv2[RFC2328]和OSPFv3[RFC5340]中规定的“路由器优先级”接口参数适用于混合广播和P2MP接口。
The "LinkLSASuppression" interface parameter as specified in OSPFv3 [RFC5340] applies to a hybrid-broadcast-and-P2MP interface. The default value is "disabled". It may be set to "enabled" via configuration.
OSPFv3[RFC5340]中规定的“LinkLSASuppression”接口参数适用于混合广播和P2MP接口。默认值为“禁用”。可通过配置将其设置为“已启用”。
An additional field called the Neighbor Output Cost is added to the neighbor data structure. This is the cost of sending a data packet to the neighbor, expressed in the link state metric. The default value of this field is the Interface output cost. It may be set to a different value using mechanisms that are outside the scope of this document, like static per-neighbor configuration, or any dynamic discovery mechanism that is supported by the underlying network.
称为邻居输出成本的附加字段添加到邻居数据结构中。这是向邻居发送数据包的成本，用链路状态度量表示。此字段的默认值为接口输出成本。可以使用本文档范围之外的机制将其设置为不同的值，如静态每邻居配置或基础网络支持的任何动态发现机制。
Routers send and receive Hellos so as to perform neighbor discovery and maintenance on the interface using the procedures specified for broadcast interfaces in [RFC2328] and [RFC5340].
路由器发送和接收hello，以便使用[RFC2328]和[RFC5340]中为广播接口指定的程序在接口上执行邻居发现和维护。
Routers elect a DR and BDR for the interface and use them for initial and ongoing database synchronization using the procedures specified for broadcast interfaces in [RFC2328] and [RFC5340].
路由器为接口选择DR和BDR，并使用[RFC2328]和[RFC5340]中为广播接口指定的过程，将其用于初始和正在进行的数据库同步。
Since a hybrid-broadcast-and-P2MP interface is described in router-LSAs using a collection of point-to-point links, the DR MUST NOT generate a network-LSA for the interface.
由于混合广播和P2MP接口在路由器LSA中使用点到点链路集合进行描述，因此DR不得为该接口生成网络LSA。
Routers describe the interface in their router-LSA as specified for a point-to-multipoint interface in Section 12.4.1.4 of [RFC2328] and Section 4.4.3.2 of [RFC5340], with the following modifications for Type 1 links:
路由器在其路由器LSA中描述了[RFC2328]第12.4.1.4节和[RFC5340]第4.4.3.2节中为点对多点接口规定的接口，并对类型1链路进行了以下修改：
o If a router is not the DR and does not have a full adjacency to the DR, it MUST NOT add any Type 1 links.
o 如果路由器不是DR并且与DR没有完全邻接，则不得添加任何类型1链路。
o If a router is not the DR and has a full adjacency to the DR, and both the DR and this router agree on the DR role, it MUST add a Type 1 link corresponding to each neighbor that is in state 2-Way or higher and to which the DR's router-LSA includes a link.
o 如果路由器不是DR并且与DR完全相邻，并且DR和此路由器都同意DR角色，则必须添加一个类型1链路，该链路对应于处于双向或更高状态且DR路由器LSA包含链路的每个邻居。
o The cost for a Type 1 link corresponding to a neighbor SHOULD be set to the value of the Neighbor Output Cost field as defined in Section 4.2.
o 对应于邻居的1类链路的成本应设置为第4.2节中定义的邻居输出成本字段的值。
Routers MUST add a Type 3 link for their own IP address to the router-LSA as described in Section 12.4.1.4 of [RFC2328]. Further, they MUST also add a Type 3 link with the Link ID set to the IP subnet address, Link Data set to the IP subnet mask, and cost equal to the configured output cost of the interface.
如[RFC2328]第12.4.1.4节所述，路由器必须为其自身的IP地址向路由器LSA添加类型3链路。此外，他们还必须添加类型3链路，链路ID设置为IP子网地址，链路数据设置为IP子网掩码，成本等于接口的配置输出成本。
Routers MUST add globally scoped IPv6 addresses on the interface to the intra-area-prefix-LSA as described for point-to-multipoint interfaces in Section 4.4.3.9 of [RFC5340]. In addition, they MUST also add all globally scoped IPv6 prefixes on the interface to the LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the configured output cost of the interface.
路由器必须按照[RFC5340]第4.4.3.9节中关于点对多点接口的描述，在接口上将全局范围的IPv6地址添加到区域内前缀LSA。此外，他们还必须通过指定前缀长度、前缀选项和地址前缀字段，将接口上所有全局范围的IPv6前缀添加到LSA。每个前缀的度量字段都设置为接口的配置输出成本。
The DR MUST NOT generate an intra-area-prefix-LSA for the transit network for this interface since it does not generate a network-LSA for the interface. Note that the global prefixes associated with the interface are advertised in the intra-area-prefix-LSA for the router as described above.
DR不得为该接口的公交网络生成区域内前缀LSA，因为它不会为该接口生成网络LSA。注意，如上所述，与接口相关联的全局前缀在路由器的区域内前缀LSA中通告。
Next-hops to destinations that are directly connected to a router via the interface are calculated as specified for a point-to-multipoint interface in Section 16.1.1 of [RFC2328].
根据[RFC2328]第16.1.1节中针对点对多点接口的规定，计算通过接口直接连接到路由器的目的地的下一跳。
The following modifications to the procedures defined in Section 2.2, item 1, of [RFC3623] are required in order to ensure that the router correctly exits graceful restart.
需要对[RFC3623]第2.2节第1项中定义的程序进行以下修改，以确保路由器正确退出。
o If a router is the DR on the interface, the pre-restart network-LSA for the interface MUST NOT be used to determine the previous set of adjacencies.
o 如果路由器是接口上的DR，则接口的预重启网络LSA不得用于确定前一组邻接。
o If a router is in state DROther on the interface, an adjacency to a non-DR or non-BDR neighbor is considered as reestablished when the neighbor state reaches 2-Way.
o 如果路由器在接口上处于DROther状态，则当邻居状态达到双向时，非DR或非BDR邻居的邻接被视为重新建立。
All routers on the network must support the hybrid-broadcast-and-P2MP interface type for successful operation. Otherwise, the interface should be configured as a standard broadcast interface.
网络上的所有路由器必须支持混合广播和P2MP接口类型才能成功运行。否则，该接口应配置为标准广播接口。
If some routers on the network treat the interface as broadcast and others as hybrid-broadcast-and-P2MP, neighbors and adjacencies will still get formed as for a broadcast interface. However, due to the differences in how router and network-LSAs are built for these two
如果网络上的一些路由器将接口视为广播，而另一些路由器将接口视为混合广播和P2MP，那么对于广播接口，仍然会形成邻居和邻接。然而，由于路由器和网络LSA是如何为这两种类型构建的，因此
interface types, there will be no traffic traversing certain pairs of routers. Note that this will not cause any persistent loops or black-holing of traffic.
接口类型，将不会有流量通过某些路由器对。请注意，这不会导致任何持续循环或流量黑洞。
To detect and flag possible mismatched configurations, an implementation of this specification SHOULD log a message if a network-LSA is received for a locally configured hybrid interface.
为了检测和标记可能的不匹配配置，如果为本地配置的混合接口接收到网络LSA，则本规范的实现应记录一条消息。
Treating a broadcast interface as hybrid-broadcast-and-P2MP results in O(N^2) links to represent the network instead of O(N), when there are N routers on the network. This will increase memory usage and have a negative impact on route calculation performance on all the routers in the area. Network designers should carefully weigh the benefits of using the new interface type against the disadvantages mentioned here.
当网络上有N个路由器时，将广播接口视为混合广播和P2MP会导致O（N^2）个链路来表示网络，而不是O（N）。这将增加内存使用，并对该区域中所有路由器的路由计算性能产生负面影响。网络设计者应该仔细权衡使用新接口类型的好处和这里提到的缺点。
The following MIB variable/value should be added to the appropriate OSPFv2 and OSPFv3 MIBs ([RFC4750], [RFC5643]).
应将以下MIB变量/值添加到相应的OSPFv2和OSPFv3 MIB（[RFC4750]、[RFC5643]）。
o For ospfIfType/ospfv3IfType, a new value broadcast-P2MP-hybrid (X) for the hybrid interface type (X to be defined when the revised MIB documents are approved).
o 对于ospfIfType/ospfv3IfType，混合接口类型的新值broadcast-P2MP-hybrid（X）（X将在修订的MIB文件获得批准时定义）。
o For ospfNbrEntry/ospfv3NbrEntry, an ospfNbrMetricValue/ ospfv3NbrMetricValue attribute for per-neighbor metrics. In case of non-hybrid interfaces, the value is the same as the interface metric.
o 对于ospfNbrEntry/ospfv3NbrEntry，每邻居度量的ospfNbrMetricValue/ospfv3NbrMetricValue属性。对于非混合接口，该值与接口度量相同。
This section is not normative.
本节不规范。
This document raises no new security issues for OSPF. Security considerations for the base OSPF protocol are covered in [RFC2328], [RFC5340], and [RFC6506].
本文件没有对OSPF提出新的安全问题。[RFC2328]、[RFC5340]和[RFC6506]中介绍了基本OSPF协议的安全注意事项。
The authors would like to thank Acee Lindem and Richard Ogier for their comments and suggestions.
作者要感谢Acee Lindem和Richard Ogier的评论和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623]Moy，J.，Pillay Esnault，P.，和A.Lindem，“OSPF的优雅重启”，RFC 36232003年11月。
[RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006.
[RFC4750]Joyal，D.，Galecki，P.，Giacalone，S.，Coltun，R.，和F.Baker，“OSPF版本2管理信息库”，RFC 47502006年12月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC5643] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", RFC 5643, August 2009.
[RFC5643]Joyal，D.和V.Manral，“OSPFv3管理信息库”，RFC 5643，2009年8月。
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[RFC6506]Bhatia，M.，Manral，V.，和A.Lindem，“OSPFv3的支持认证拖车”，RFC 65062012年2月。
Authors' Addresses
作者地址
Nischal Sheth Contrail Systems 2350 Mission College Blvd, #1140 Santa Clara, CA 95054 US
美国加利福尼亚州圣克拉拉市教会学院大道2350号Nischal Sheth Tracil Systems，1140号，邮编95054
EMail: nsheth@contrailsystems.com
EMail: nsheth@contrailsystems.com
Lili Wang Juniper Networks 10 Technology Park Dr. Westford, MA 01886 US
Lili Wang Juniper Networks 10科技园美国马萨诸塞州韦斯特福德博士01886
EMail: liliw@juniper.net
EMail: liliw@juniper.net
Jeffrey Zhang Juniper Networks 10 Technology Park Dr. Westford, MA 01886 US
Jeffrey Zhang Juniper Networks 10科技园美国马萨诸塞州韦斯特福德博士01886
EMail: zzhang@juniper.net
EMail: zzhang@juniper.net