📄 rfc2370.txt
字号:
[NSSA] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587,
March 1994.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFMIB] Baker, F., and R. Coltun, "OSPF Version 2 Management
Information Base", RFC 1850, November 1995.
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765,
March 1995.
9.0 Author's Information
Rob Coltun
FORE Systems
Phone: (703) 245-4543
EMail: rcoltun@fore.com
Coltun Standards Track [Page 11]
RFC 2370 The OSPF Opaque LSA Option July 1998
Appendix A: OSPF Data formats
This appendix describes the format of the Options Field followed by
the packet format of the Opaque LSA.
A.1 The Options Field
The OSPF Options field is present in OSPF Hello packets, Database
Description packets and all link-state advertisements. The Options
field enables OSPF routers to support (or not support) optional
capabilities, and to communicate their capability level to other OSPF
routers. Through this mechanism routers of differing capabilities can
be mixed within an OSPF routing domain.
When used in Hello packets, the Options field allows a router to
reject a neighbor because of a capability mismatch. Alternatively,
when capabilities are exchanged in Database Description packets a
router can choose not to forward certain link-state advertisements to
a neighbor because of its reduced functionality. Lastly, listing
capabilities in link-state advertisements allows routers to forward
traffic around reduced functionality routers by excluding them from
parts of the routing table calculation.
Six bits of the OSPF Options field have been assigned, although only
the O-bit is described completely by this memo. Each bit is
described briefly below. Routers should reset (i.e., clear)
unrecognized bits in the Options field when sending Hello packets or
Database Description packets and when originating link-state
advertisements. Conversely, routers encountering unrecognized Option
bits in received Hello Packets, Database Description packets or
link-state advertisements should ignore the capability and process
the packet/advertisement normally.
+------------------------------------+
| * | O | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options Field
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [MOSPF].
Coltun Standards Track [Page 12]
RFC 2370 The OSPF Opaque LSA Option July 1998
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[NSSA].
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [DEMD].
EA-bit
This bit describes the router's willingness to receive and
forward External-Attributes-LSAs, as specified in [EAL].
O-bit
This bit describes the router's willingness to receive and
forward Opaque-LSAs as specified in this document.
A.2 The Opaque LSA
Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These
advertisements may be used directly by OSPF or indirectly by some
application wishing to distribute information throughout the OSPF
domain. The function of the Opaque LSA option is to provide for
future extensibility of OSPF.
Opaque LSAs contain some number of octets (of application-specific
data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA
uses the link-state database distribution mechanism for flooding this
information throughout the topology. However, the Opaque LSA has a
flooding scope associated with it so that the scope of flooding may
be link-local (type 9), area-local (type 10) or the entire OSPF
routing domain (type 11). Section 3 of this document describes the
flooding procedures for the Opaque LSA.
Coltun Standards Track [Page 13]
RFC 2370 The OSPF Opaque LSA Option July 1998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10 or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
Link-State Type
The link-state type of the Opaque LSA identifies the LSA's range of
topological distribution. This range is referred to as the Flooding
Scope. The following explains the flooding scope of each of the
link-state types.
o A value of 9 denotes a link-local scope. Opaque LSAs with a
link-local scope are not flooded beyond the local (sub)network.
o A value of 10 denotes an area-local scope. Opaque LSAs with a
area-local scope are not flooded beyond the area that they are
originated into.
o A value of 11 denotes that the LSA is flooded throughout the
Autonomous System (e.g., has the same scope as type-5 LSAs).
Opaque LSAs with AS-wide scope are not flooded into stub areas.
Syntax Of The Opaque LSA's Link-State ID
The link-state ID of the Opaque LSA is divided into an Opaque Type
field (the first 8 bits) and an Opaque ID (the remaining 24 bits).
See section 7.0 of this document for a description of Opaque type
allocation and assignment.
Coltun Standards Track [Page 14]
RFC 2370 The OSPF Opaque LSA Option July 1998
Appendix B. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Coltun Standards Track [Page 15]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -