Internet DRAFT - draft-coltun-ospf-opaque
draft-coltun-ospf-opaque
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:20:02 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 02 Mar 1996 13:56:35 GMT
ETag: "304b57-5f36-31385393"
Accept-Ranges: bytes
Content-Length: 24374
Connection: close
Content-Type: text/plain
Internet-Draft Opaque February 1996
Expiration Date: August 1996 FORE Systems
File name: draft-ietf-ospf-opaque-01.txt
The OSPF Opaque LSA Option
Rob Coltun
FORE Systems
(301) 571-2521
rcoltun@fore.com
Status Of This Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Coltun [Page 1]
Internet-Draft Opaque February 1996
Table Of Contents
1.0 Abstract ................................................. 3
2.0 Overview ................................................. 3
2.1 Organization Of This Document ............................ 3
2.2 Acknowledgments .......................................... 3
3.0 The Opaque LSA ........................................... 4
3.1 Flooding Opaque LSAs ..................................... 5
3.2 Modifications To The Neighbor State Machine .............. 6
4.0 Protocol Data Structures ................................. 8
4.1 Additions To The OSPF Interface Structure ................ 8
4.2 Additions To The OSPF Neighbor Structure ................. 8
5.0 References ............................................... 9
Appendix A: OSPF Data Formats ................................ 10
A.1 The Options Field ........................................ 10
A.2 Opaque LSA ............................................... 12
Coltun [Page 2]
Internet-Draft Opaque February 1996
1.0 Abstract
This memo documents enhancements to the OSPF protocol to support a new
type of link-state advertisement (LSA) called the Opaque LSA. The
Opaque LSA option defines a general mechanism to allow for future
extensibility of OSPF. The information contained in Opaque LSAs may be
used directly by OSPF or by other protocols. Opaque LSAs contain some
number of octets padded to 32-bit alignment. The standard OSPF link-
state database flooding mechanisms are use for distribution of Opaque
LSAs. Opaque LSAs are flooded throughout all or some limited portion
of the OSPF topology.
2.0 Overview
Over the last few years the OSPF routing protocol [OSPF] has been
widely deployed throughout the Internet. As a result of this deploy-
ment and the evolution of networking technology, OSPF has been
extended to support many options; this evolution will obviously con-
tinue.
This memo documents enhancements to the OSPF protocol to support a new
type of link-state advertisement (LSA) called the Opaque LSA which
defines an optional generalized mechanism to allow for future extensi-
bility of OSPF. The information contained in Opaque LSAs may be used
directly by OSPF or by other protocols. For example, the OSPF LSA may
be used to distribute BGP AS Path information (as documented in The
OSPF External Attributes LSA [EAL]) which is then used by BGP route-
leaking mechanisms. The option may also be used to distribute IP QoS
information which may be used directly by an OSPF path computation.
The exact use of the Opaque LSA is beyond the scope of this draft.
The data contained in the Opaque LSA is some number of 32-bit aligned
octets. Like any other LSA, the Opaque LSA uses the link-state data-
base distribution mechanism for flooding this information throughout
the topology. The Flooding Scope identifies the range of the topology
to which this LSA may be distributed to.
2.1 Organization Of This Document
This document first defines the Opaque LSA followed by a description
of OSPF packet processing which includes modifications to the flooding
procedure and the neighbor state machine needed to support the Opaque
LSA. Appendix A then gives the packet formats.
2.2 Acknowledgments
Coltun [Page 3]
Internet-Draft Opaque February 1996
The author would like to thank Dennis Ferguson, John Moy, Zhaohui
"Jeffrey" Zhang and the rest of the OSPF Working Group for the ideas
and support they have given to this project.
3.0 The Opaque LSA
Opaque LSAs are the Type 15 link-state advertisements. These adver-
tisements are originated by any router. The data contained in the
Opaque LSA consists of some number of octets aligned to a 32-bit boun-
dary. Like any other LSA, the Opaque LSA uses the link-state database
distribution mechanism for flooding this information throughout the
topology. The Flooding Scope field in the Opaque LSA identifies the
range of the topology to which this LSA may be distributed to. This
section documents the flooding of Opaque LSAs.
The following are possible values of the Flooding Scope field.
o A value of 0 denotes a link-local scope. Opaque LSAs with a
Flooding Scope of 0 are not flooded beyond the local
(sub)network.
o A value of 1 denotes an area-local scope. Opaque LSAs with a
flooding scope of 1 are not flooded beyond the area that they are
originated into.
o A value of 2 denotes that the LSA is flooded throughout the
Autonomous System.
Origination of Opaque LSAs are unique to the application using it.
The link-state ID of the Opaque LSA is divided into a type field (the
first 8 bits) a type-specific ID (the remaining 24 bits). The packet
format of the Opaque LSA is given in Appendix A.
The responsibility for proper handling of the Opaque LSA's Flooding
Scope field is placed on the sender of the LSA. The receiver must
always store a valid received Opaque LSA in its link-state database.
Flooding scope effects both the building of the Database summary list
during the initial synchronization of the link-state database and the
flooding procedure.
In order to make the use of the Opaque LSAs predictable, it is recom-
mended that all routers within the scope of use have the same Opaque
LSA capabilities. For example, if the Opaque LSA is to be used for
flooding Opaque information throughout a single area, all routers
within the area should support the Opaque option.
Coltun [Page 4]
Internet-Draft Opaque February 1996
The following describes the modifications to these procedures that are
necessary to insure proper use of the Opaque LSA's Scoping Rules.
3.1 Flooding Opaque LSAs
The flooding of Opaque LSAs must follow the rules of Flooding Scope as
specified in this section. The flooding mechanisms must suppress the
flooding of Opaque LSAs as described in the following.
o If the Flooding Scope is link-local and the interface that the
LSA was received on is not the same as the target interface
(e.g., the interface associated with a particular neighbor), the
Opaque LSA must not be flooded out that interface (or to that
neighbor). An implementation should therefore keep track of the
IP interface associated with each Opaque LSA that has a link-
local flooding scope.
o If the Flooding Scope is area-local and the area associated
with Opaque LSA is not the area associated with a particular
interface, the Opaque LSA must not be flooded out the interface.
An implementation should therefore keep track of the OSPF area
associated with each Opaque LSA that has an area-local flooding
scope.
When opaque-capable routers and non-opaque-capable OSPF routers are
mixed together in a routing domain, the Opaque LSAs are not flooded to
the non-opaque-capable routers. As a general design principle,
optional OSPF advertisements are only flooded to those routers that
understand them.
An opaque-capable router learns of its neighbor's opaque capability at
the beginning of the "Database Exchange Process" (see Section 10.6 of
[OSPF], receiving Database Description packets from a neighbor in
state ExStart). A neighbor is opaque-capable if and only if it sets
the O-bit in the Options field of its Database Description packets.
Then, in the next step of the Database Exchange process, Opaque LSAs
are included in the Database summary list sent to the neighbor (see
Sections 3.2 below and 10.3 of [OSPF]) if and only if the neighbor is
opaque-capable.
When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable
router looks at the neighbor's opaque capability. Opaque LSAs are
only flooded to opaque capable neighbors. To be more precise, in Sec-
tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state
retransmission lists of opaque-capable neighbors. Note however that
when sending Link State Update packets as multicasts, a non-opaque-
Coltun [Page 5]
Internet-Draft Opaque February 1996
capable neighbor may (inadvertently) receive Opaque LSAs. The non-
opaque-capable router will then simply discard the LSA (see Section 13
of [OSPF], receiving LSAs having unknown LS types).
3.2 Modifications To The Neighbor State Machine
The state machine as it exists in section 10.3 of [OSPF] remains
unchanged except for the action associated with State: ExStart, Event:
NegotiationDone which is where the Database summary list is built. To
incorporate the Opaque LSA in OSPF the action is changed to the fol-
lowing.
State(s): ExStart
Event: NegotiationDone
New state: Exchange
Action: The router must list the contents of its entire area
link-state database in the neighbor Database summary
list. The area link-state database consists of the
Router LSAs, Network LSAs and Summary LSAs
contained in the area structure, along with Opaque and
AS External LSAs contained in the global structure.
AS External LSAs are omitted from a
virtual neighbor's Database summary list. AS
External LSAs are omitted from the Database
summary list if the area has been configured
as a stub (see Section 3.6 of [OSPF]).
Opaque LSAs are omitted from the Database
summary list if the following conditions
are met: 1) the Flooding Scope is link-local
and the interface associated with the Opaque
LSA (upon reception) does not equal the
interface associated with the neighbor;
2) the Flooding Scope is area-local and the
area associated with Opaque LSA is not the
area associated with the neighbor's interface.
Any advertisement whose age is equal to MaxAge is
omitted from the Database summary list. It is
instead added to the neighbor's link-state
retransmission list. A summary of the Database
summary list will be sent to the neighbor in
Database Description packets. Each Database
Description Packet has a DD sequence number, and is
Coltun [Page 6]
Internet-Draft Opaque February 1996
explicitly acknowledged. Only one Database
Description Packet is allowed to be outstanding at
any one time. For more detail on the sending and
receiving of Database Description packets, see
Sections 10.8 and 10.6 of [OSPF].
Coltun [Page 7]
Internet-Draft Opaque February 1996
4.0 Protocol data structures
The Opaque option is described herein in terms of its operation on
various protocol data structures. These data structures are included
for explanatory uses only, and are not intended to constrain an OSPF
implementation. Besides the data structures listed below, this specif-
ication will also reference the various data structures (e.g., OSPF
interfaces and neighbors) defined in [OSPF].
In an OSPF router, the following item is added to the list of global
OSPF data structures described in Section 5 of [OSPF]:
o Opaque capability. Indicates whether the router is running the
Opaque option (i.e., capable of storing Opaque LSAs). Such a
router will continue to interoperate with non-opaque-capable OSPF
routers.
4.1 Additions To The OSPF Interface Structure
The OSPF interface structure is described in Section 9 of [OSPF]. In
an opaque-capable router, the following item is added to the OSPF
interface structure. Note that the Opaque capability parameter is
really a description of this router's view of the attached network.
As such, it should be configured identically on all routers attached
to a common network; otherwise incorrect or incomplete distribution of
Opaque LSAs may occur.
o OpaqueInterfaceOn. This configurable parameter indicates
whether Opaque LSAs should be flooded over the attached network.
The parameter can assume a value of disabled or enabled. When
set to disabled, Opaque LSAs will not be flooded out the inter-
face; when set to enabled Opaque LSAs will be flooded out the
interface. The default value for this parameter is enabled when
the router's Opaque capability is enabled. This parameter may
not be enabled if the router's Opaque capability is disabled.
The state of this parameter is reflected by setting (or reset-
ting) the O-bit in the option field as appropriate for all OSPF
packets sent out this interface.
4.2 Additions To The OSPF Neighbor Structure
The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an
opaque-capable router, the following items are added to the OSPF
neighbor structure:
o Neighbor Options. This field was already defined in the OSPF
specification. However, in opaque-capable routers there is a new
Coltun [Page 8]
Internet-Draft Opaque February 1996
option which indicates the neighbor's Opaque capability. This new
option is learned in the Database Exchange process through recep-
tion of the neighbor's Database Description packets, and deter-
mines whether Opaque LSAs are flooded to the neighbor. For a more
detailed explanation of the flooding of the Opaque LSA see 3 of
this document.
5.0 References
[OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft,
Cascade, November 1995.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
Inc., March 1994.
[NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
RainbowBridge Communications, Stanford University, March 1994.
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
Cascade, April 1995.
[EAL] Ferguson, D., "The OSPF External Attributes LSA", work in
progress.
Coltun [Page 9]
Internet-Draft Opaque February 1996
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 capa-
bilities, 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.
Seven 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 Pack-
ets, Database Description packets or link-state advertisements should
ignore the capability and process the packet/advertisement normally.
+------------------------------------+
| * | O | DC | EA | N/P | MC | E | T |
+------------------------------------+
The Options Field
T-bit
This bit describes the router's TOS-based routing capability, as
specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of [OSPF].
E-bit
Coltun [Page 10]
Internet-Draft Opaque February 1996
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].
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 for-
ward External-Attributes-LSAs, as specified in [EAL].
O-bit
This bit describes the router's willingness to receive and for-
ward Opaque-LSAs as specified in this document.
Coltun [Page 11]
Internet-Draft Opaque February 1996
A.2 Opaque LSA
Opaque LSAs are the Type 15 link-state advertisements. These adver-
tisements are originated by any router and may be used directly by
OSPF or indirectly by other protocols such as BGP wishing to distri-
bute information throughout the OSPF domain. The primary function of
the Opaque LSA is to provide for future extensibility to OSPF.
The data contained in the Opaque LSA consists of some number of octets
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, area-local or the entire OSPF routing domain.
Origination of Opaque LSAs are unique to the application using it.
Section 3 of this document describes the flooding procedures for the
Opaque LSA.
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 | 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flooding Scope | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
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).
Coltun [Page 12]
Internet-Draft Opaque February 1996
Flooding Scope
The flooding Scope identifies the range of the topology to which
this LSA may be distributed to. The following denotes the possi-
ble values of the Flooding Scope field.
o A value of 0 denotes a link-local scope. Opaque LSAs with a
Flooding Scope of 0 are not flooded beyond the local
(sub)network.
o A value of 1 denotes an area-local scope. Opaque LSAs with a
flooding scope of 1 are not flooded beyond the area that they are
originated into.
o A value of 2 denotes that the LSA is flooded throughout the
Autonomous System (e.g., has the same scope as type-5 LSAs).
Coltun [Page 13]
