< draft-ietf-ospf-opaque-04.txt   draft-ietf-ospf-opaque-05.txt >
Internet-Draft Opaque February 1998 Internet-Draft Opaque May 1998
Expiration Date: August 1998 FORE Systems Expiration Date: November 1998 FORE Systems
File name: draft-ietf-ospf-opaque-04.txt File name: draft-ietf-ospf-opaque-05.txt
The OSPF Opaque LSA Option The OSPF Opaque LSA Option
Rob Coltun Rob Coltun
FORE Systems FORE Systems
(703) 245-4543 (703) 245-4543
rcoltun@fore.com rcoltun@fore.com
Status Of This Memo Status Of This Memo
skipping to change at page 2, line 13 skipping to change at page 2, line 13
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Table Of Contents Table Of Contents
1.0 Abstract ................................................. 3 1.0 Abstract ................................................. 3
2.0 Overview ................................................. 3 2.0 Overview ................................................. 3
2.1 Organization Of This Document ............................ 3 2.1 Organization Of This Document ............................ 3
2.2 Acknowledgments .......................................... 3 2.2 Acknowledgments .......................................... 4
3.0 The Opaque LSA ........................................... 4 3.0 The Opaque LSA ........................................... 4
3.1 Flooding Opaque LSAs ..................................... 5 3.1 Flooding Opaque LSAs ..................................... 5
3.2 Modifications To The Neighbor State Machine .............. 6 3.2 Modifications To The Neighbor State Machine .............. 6
4.0 Protocol Data Structures ................................. 8 4.0 Protocol Data Structures ................................. 8
4.1 Additions To The OSPF Neighbor Structure ................. 8 4.1 Additions To The OSPF Neighbor Structure ................. 8
5.0 Security Considerations .................................. 8 5.0 Management Considerations ................................ 8
6.0 References ............................................... 10 6.0 Security Considerations .................................. 10
Appendix A: OSPF Data Formats ................................ 11 7.0 References ............................................... 12
A.1 The Options Field ........................................ 11 Appendix A: OSPF Data Formats ................................ 13
A.2 Opaque LSA ............................................... 13 A.1 The Options Field ........................................ 13
A.2 Opaque LSA ............................................... 15
1.0 Abstract 1.0 Abstract
This memo defines enhancements to the OSPF protocol to support a new This memo defines enhancements to the OSPF protocol to support a new
class of link-state advertisements (LSA) called Opaque LSAs. Opaque class of link-state advertisements (LSA) called Opaque LSAs. Opaque
LSAs provide a generalized mechanism to allow for the future extensi- LSAs provide a generalized mechanism to allow for the future extensi-
bility of OSPF. Opaque LSAs consist of a standard LSA header followed bility of OSPF. Opaque LSAs consist of a standard LSA header followed
by application-specific information. The information field may be by application-specific information. The information field may be
used directly by OSPF or by other applications. Standard OSPF link- used directly by OSPF or by other applications. Standard OSPF link-
state database flooding mechanisms are used to distribute Opaque LSAs state database flooding mechanisms are used to distribute Opaque LSAs
skipping to change at page 3, line 41 skipping to change at page 3, line 41
resolution information (see [ARA] for more information). The exact resolution information (see [ARA] for more information). The exact
use of Opaque LSAs is beyond the scope of this draft. use of Opaque LSAs is beyond the scope of this draft.
Opaque LSAs consist of a standard LSA header followed by a 32-bit Opaque LSAs consist of a standard LSA header followed by a 32-bit
aligned application-specific information field. Like any other LSA, aligned application-specific information field. Like any other LSA,
the Opaque LSA uses the link-state database distribution mechanism for the Opaque LSA uses the link-state database distribution mechanism for
flooding this information throughout the topology. The link-state flooding this information throughout the topology. The link-state
type field of the Opaque LSA identifies the LSA's range of topological type field of the Opaque LSA identifies the LSA's range of topological
distribution. This range is referred to as the Flooding Scope. distribution. This range is referred to as the Flooding Scope.
It is envisioned that an implementation of the Opaque option provides
an application interface for 1) encapsulating application-specific
information in a specific Opaque type, 2) sending and receiving
application-specific information, and 3) if required, informing the
application of the change in validity of previously received informa-
tion when topological changes are detected.
2.1 Organization Of This Document 2.1 Organization Of This Document
This document first defines the three types of Opaque LSAs followed by This document first defines the three types of Opaque LSAs followed by
a description of OSPF packet processing. The packet processing sec- a description of OSPF packet processing. The packet processing sec-
tions include modifications to the flooding procedure and to the tions include modifications to the flooding procedure and to the
neighbor state machine. Appendix A then gives the packet formats. neighbor state machine. Appendix A then gives the packet formats.
2.2 Acknowledgments 2.2 Acknowledgments
The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, The author would like to thank Dennis Ferguson, Acee Lindem, John Moy,
Sandra Murphy, Zhaohui "Jeffrey" Zhang and the rest of the OSPF Work- Sandra Murphy, Man-Kit Yeung, Zhaohui "Jeffrey" Zhang and the rest of
ing Group for the ideas and support they have given to this project. the OSPF Working Group for the ideas and support they have given to
this project.
3.0 The Opaque LSA 3.0 The Opaque LSA
Opaque LSAs are types 9, 10 and 11 link-state advertisements. Each Opaque LSAs are types 9, 10 and 11 link-state advertisements. Opaque
type has a unique flooding scope. Opaque LSAs consist of a standard LSAs consist of a standard LSA header followed by a 32-bit aligned
LSA header followed by a 32-bit aligned application-specific informa- application-specific information field. Standard link-state database
tion field. Standard link-state database flooding mechanisms are used flooding mechanisms are used for distribution of Opaque LSAs. The
for distribution of Opaque LSAs. The range of topological distribu- range of topological distribution (i.e., the flooding scope) of an
tion (i.e., the flooding scope) of an Opaque LSA is identified by its Opaque LSA is identified by its link-state type. This section docu-
link-state type. This section documents the flooding of Opaque LSAs. ments the flooding of Opaque LSAs.
The flooding scope associated with each Opaque link-state type is The flooding scope associated with each Opaque link-state type is
defined as follows. defined as follows.
o Link-state type 9 denotes a link-local scope. Type-9 Opaque o Link-state type 9 denotes a link-local scope. Type-9 Opaque
LSAs are not flooded beyond the local (sub)network. LSAs are not flooded beyond the local (sub)network.
o Link-state type 10 denotes an area-local scope. Type-10 Opaque o Link-state type 10 denotes an area-local scope. Type-10 Opaque
LSAs are not flooded beyond the borders of their associated area. LSAs are not flooded beyond the borders of their associated area.
o Link-state type 11 denotes that the LSA is flooded throughout o Link-state type 11 denotes that the LSA is flooded throughout
the Autonomous System (AS). The flooding scope of type-11 LSAs the Autonomous System (AS). The flooding scope of type-11 LSAs
are equivalent to the flooding scope of AS-external (type-5) are equivalent to the flooding scope of AS-external (type-5)
LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout
all transit areas, 2) not flooded into stub areas from the back- all transit areas, 2) not flooded into stub areas from the back-
bone and 3) not originated by routers into their connected stub bone and 3) not originated by routers into their connected stub
areas. As with type-5 LSAs, if a type-11 Opaque LSA is received areas. As with type-5 LSAs, if a type-11 Opaque LSA is received
in a stub area from a neighboring router within the stub area the in a stub area from a neighboring router within the stub area the
LSA is rejected. LSA is rejected.
The link-state ID of the Opaque LSA is divided into a type field (the The link-state ID of the Opaque LSA is divided into an Opaque type
first 8 bits) and a type-specific ID (the remaining 24 bits). The field (the first 8 bits) and a type-specific ID (the remaining 24
packet format of the Opaque LSA is given in Appendix A. bits). Opaque type values in the range of 0-127 are reserved for
definition by the IANA (iana@ISI.EDU) whereas Opaque type values in
the range of 128-255 are reserved for private and experimental use.
The packet format of the Opaque LSA is given in Appendix A.
The responsibility for proper handling of the Opaque LSA's flooding The responsibility for proper handling of the Opaque LSA's flooding
scope is placed on both the sender and receiver of the LSA. The scope is placed on both the sender and receiver of the LSA. The
receiver must always store a valid received Opaque LSA in its link- receiver must always store a valid received Opaque LSA in its link-
state database. The receiver must not accept Opaque LSAs that violate state database. The receiver must not accept Opaque LSAs that violate
the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not
accepted in a stub area). The flooding scope effects both the build- accepted in a stub area). The flooding scope effects both the build-
ing of the Database Summary List during the initial synchronization of ing of the Database Summary List during the initial synchronization of
the link-state database and the flooding procedure. the link-state database and the flooding procedure.
skipping to change at page 5, line 47 skipping to change at page 6, line 11
When opaque-capable routers and non-opaque-capable OSPF routers are When opaque-capable routers and non-opaque-capable OSPF routers are
mixed together in a routing domain, the Opaque LSAs are not flooded to mixed together in a routing domain, the Opaque LSAs are not flooded to
the non-opaque-capable routers. As a general design principle, the non-opaque-capable routers. As a general design principle,
optional OSPF advertisements are only flooded to those routers that optional OSPF advertisements are only flooded to those routers that
understand them. understand them.
An opaque-capable router learns of its neighbor's opaque capability at An opaque-capable router learns of its neighbor's opaque capability at
the beginning of the "Database Exchange Process" (see Section 10.6 of the beginning of the "Database Exchange Process" (see Section 10.6 of
[OSPF], receiving Database Description packets from a neighbor in [OSPF], receiving Database Description packets from a neighbor in
state ExStart). A neighbor is opaque-capable if and only if it sets 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. the O-bit in the Options field of its Database Description packets;
Then, in the next step of the Database Exchange process, Opaque LSAs the O-bit is not set in packets other than Database Description pack-
are included in the Database summary list that is sent to the neighbor ets. Then, in the next step of the Database Exchange process, Opaque
(see Sections 3.2 below and 10.3 of [OSPF]) if and only if the LSAs are included in the Database summary list that is sent to the
neighbor is opaque capable. 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 When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable
router looks at the neighbor's opaque capability. Opaque LSAs are router looks at the neighbor's opaque capability. Opaque LSAs are
only flooded to opaque-capable neighbors. To be more precise, in Sec- 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 tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state
retransmission lists of opaque-capable neighbors. However, when send- retransmission lists of opaque-capable neighbors. However, when send-
ing Link State Update packets as multicasts, a non-opaque-capable ing Link State Update packets as multicasts, a non-opaque-capable
neighbor may (inadvertently) receive Opaque LSAs. The non-opaque- neighbor may (inadvertently) receive Opaque LSAs. The non-opaque-
capable router will then simply discard the LSA (see Section 13 of capable router will then simply discard the LSA (see Section 13 of
[OSPF], receiving LSAs having unknown LS types). [OSPF], receiving LSAs having unknown LS types).
skipping to change at page 6, line 43 skipping to change at page 7, line 8
Router LSAs, Network LSAs, Summary LSAs and types 9 Router LSAs, Network LSAs, Summary LSAs and types 9
and 10 Opaque LSAs contained in the area structure, and 10 Opaque LSAs contained in the area structure,
along with AS External and type-11 Opaque LSAs along with AS External and type-11 Opaque LSAs
contained in the global structure. AS External and contained in the global structure. AS External and
type-11 Opaque LSAs are omitted from a virtual type-11 Opaque LSAs are omitted from a virtual
neighbor's Database summary list. AS External LSAs neighbor's Database summary list. AS External LSAs
and type-11 Opaque LSAs are omitted from the and type-11 Opaque LSAs are omitted from the
Database summary list if the area has been Database summary list if the area has been
configured as a stub area (see Section 3.6 of [OSPF]). configured as a stub area (see Section 3.6 of [OSPF]).
Opaque LSAs are omitted from the Database Type-9 Opaque LSAs are omitted from the Database
summary list if the following conditions exist. summary list if the interface associated with the
1) the LSA type is type 9 (the flooding scope neighbor is not the interface associated with the
is link-local) and interface associated with the Opaque LSA (as noted upon reception).
neighbor is not the interface associated with
the Opaque LSA (as noted upon reception);
2) the LSA type is 10 (the flooding scope is
area-local) and the area associated with the
neighbor's interface is not the area associated
with the Opaque LSA (as noted upon reception).
Any advertisement whose age is equal to MaxAge is Any advertisement whose age is equal to MaxAge is
omitted from the Database summary list. It is omitted from the Database summary list. It is
instead added to the neighbor's link-state instead added to the neighbor's link-state
retransmission list. A summary of the Database retransmission list. A summary of the Database
summary list will be sent to the neighbor in summary list will be sent to the neighbor in
Database Description packets. Each Database Database Description packets. Each Database
Description Packet has a DD sequence number, and is Description Packet has a DD sequence number, and is
explicitly acknowledged. Only one Database explicitly acknowledged. Only one Database
Description Packet is allowed to be outstanding at Description Packet is allowed to be outstanding at
skipping to change at page 8, line 37 skipping to change at page 8, line 37
o Neighbor Options. This field was already defined in the OSPF o Neighbor Options. This field was already defined in the OSPF
specification. However, in opaque-capable routers there is a new specification. However, in opaque-capable routers there is a new
option which indicates the neighbor's Opaque capability. This new option which indicates the neighbor's Opaque capability. This new
option is learned in the Database Exchange process through recep- option is learned in the Database Exchange process through recep-
tion of the neighbor's Database Description packets, and deter- tion of the neighbor's Database Description packets, and deter-
mines whether Opaque LSAs are flooded to the neighbor. For a more mines whether Opaque LSAs are flooded to the neighbor. For a more
detailed explanation of the flooding of the Opaque LSA see sec- detailed explanation of the flooding of the Opaque LSA see sec-
tion 3 of this document. tion 3 of this document.
5.0 Security Considerations 5.0 Management Considerations
This section identifies the current OSPF MIB [OSPFMIB] capabilities
that are applicable to the Opaque option and lists the additional
management information which is required for its support.
Opaque LSAs are types 9, 10 and 11 link-state advertisements. The
link-state ID of the Opaque LSA is divided into an Opaque type field
(the first 8 bits) and a type-specific ID (the remaining 24 bits).
The packet format of the Opaque LSA is given in Appendix A. The range
of topological distribution (i.e., the flooding scope) of an Opaque
LSA is identified by its link-state type.
o Link-State type 9 Opaque LSAs have a link-local scope. Type-9
Opaque LSAs are flooded on a single local (sub)network but are
not flooded beyond the local (sub)network.
o Link-state type 10 Opaque LSAs have an area-local scope. Type-
10 Opaque LSAs are flooded throughout a single area but are not
flooded beyond the borders of the associated area.
o Link-state type 11 Opaque LSAs have an Autonomous-System-wide
scope. The flooding scope of type-11 LSAs are equivalent to the
flooding scope of AS-external (type-5) LSAs.
The OSPF MIB provides a number of objects that can be used to manage
and monitor an OSPF router's Link-State Database. The ones that are
relevant to the Opaque option are as follows.
The ospfGeneralGroup defines two objects for keeping track of
newly originated and newly received LSAs (ospfOriginateNewLsas
and ospfRxNewLsas respectively).
The OSPF MIB defines a set of optional traps. The ospfOrigina-
teLsa trap signifies that a new LSA has been originated by a
router and the ospfMaxAgeLsa trap signifies that one of the LSAs
in the router's link-state database has aged to MaxAge.
The ospfAreaTable describes the configured parameters and cumula-
tive statistics of the router's attached areas. This table
includes a count of the number of LSAs contained in the area's
link-state database (ospfAreaLsaCount), and a sum of the LSA's LS
checksums contained in this area (ospfAreaLsaCksumSum). This sum
can be used to determine if there has been a change in a router's
link-state database, and to compare the link-state database of
two routers.
The ospfLsdbTable describes the OSPF Process's link-state data-
base (excluding AS-external LSAs). Entries in this table are
indexed with an Area ID, a link-state type, a link-state ID and
the originating router's Router ID.
The management objects that are needed to support the Opaque option
are as follows.
An Opaque-option-enabled object is needed to indicate if the
Opaque option is enabled on the router.
The origination and reception of new Opaque LSAs should be
reflected in the counters ospfOriginateNewLsas and ospfRxNewLsas
(inclusive for types 9, 10 and 11 Opaque LSAs).
If the OSPF trap option is supported, the origination of new
Opaque LSAs and purging of MaxAge Opaque LSAs should be reflected
in the ospfOriginateLsa and ospfMaxAgeLsa traps (inclusive for
types 9, 10 and 11 Opaque LSAs).
The number of type-10 Opaque LSAs should be reflected in
ospfAreaLsaCount; the checksums of type-10 Opaque LSAs should be
included in ospfAreaLsaChksumSum.
Type-10 Opaque LSAs should be included in the ospfLsdbTable.
Note that this table does not include a method of examining the
Opaque type field (in the Opaque option this is a sub-field of
the link-state ID).
Up until now, LSAs have not had a link-local scope so there is no
method of requesting the number of, or examining the LSAs that
are associated with a specific OSPF interface. A new group of
management objects are required to support type-9 Opaque LSAs.
These objects should include a count of type-9 Opaque LSAs, a
checksum sum and a table for displaying the link-state database
for type-9 Opaque LSAs on a per-interface basis. Entries in this
table should be indexed with an Area ID, interface's IP address,
Opaque type, link-state ID and the originating router's Router
ID.
Prior to the introduction of type-11 Opaque LSAs, AS-External
(type-5) LSAs have been the only link-state types which have an
Autonomous-System-wide scope. A new group of objects are
required to support type-11 Opaque LSAs. These objects should
include a count of type-11 Opaque LSAs, a type-11 checksum sum
and a table for displaying the type-11 link-state database.
Entries in this table should be indexed with the Opaque type,
link-state ID and the originating router's Router ID. The type-
11 link-state database table will allow type-11 LSAs to be
displayed once for the router rather than once in each non-stub
area.
6.0 Security Considerations
There are two types of issues that need be addressed when looking at There are two types of issues that need be addressed when looking at
protecting routing protocols from misconfigurations and malicious protecting routing protocols from misconfigurations and malicious
attacks. The first is authentication and certification of routing attacks. The first is authentication and certification of routing
protocol information. The second is denial of service attacks result- protocol information. The second is denial of service attacks result-
ing from repetitive origination of the same router advertisement or ing from repetitive origination of the same router advertisement or
origination a large number of distinct advertisements resulting in origination a large number of distinct advertisements resulting in
database overflow. Note that both of these concerns exist indepen- database overflow. Note that both of these concerns exist indepen-
dently of a router's support for the Opaque option. dently of a router's support for the Opaque option.
skipping to change at page 10, line 5 skipping to change at page 12, line 6
Proper operation of the OSPF protocol requires that all OSPF routers Proper operation of the OSPF protocol requires that all OSPF routers
maintain an identical copy of the OSPF link-state database. However, maintain an identical copy of the OSPF link-state database. However,
when the size of the link-state database becomes very large, some when the size of the link-state database becomes very large, some
routers may be unable to keep the entire database due to resource routers may be unable to keep the entire database due to resource
shortages; we term this "database overflow". When database overflow shortages; we term this "database overflow". When database overflow
is anticipated, the routers with limited resources can be accommodated is anticipated, the routers with limited resources can be accommodated
by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of
gracefully handling unanticipated database overflows. gracefully handling unanticipated database overflows.
6.0 References 7.0 References
[ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution [ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution
Advertisement Option", draft-ietf-ospf-ara-01.txt, November 1997. Advertisement Option", work in progress.
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
Cascade, April 1995. Cascade, April 1995.
[DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital Signatures", [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital Signatures",
RFC 2154, Trusted Information Systems, June 1997. RFC 2154, Trusted Information Systems, June 1997.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
Inc., March 1994. Inc., March 1994.
[NSSA] Coltun, R., Fuller, V., Murphy, P., "The OSPF NSSA Option", [NSSA] Coltun, R., Fuller, V., "The OSPF NSSA Option", RFC 1587,
draft-ietf-ospf-nssa-update-02.txt, April 1997. March 1994.
[OSPF] Moy, J., "OSPF Version 2", RFC 2178 Cascade, July 1997. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade, April 1998.
[OSPFMIB] F. Baker, R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1850, November 1995.
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765,
Cascade, March 1995. Cascade, March 1995.
Appendix A: OSPF Data formats Appendix A: OSPF Data formats
This appendix describes the format of the Options Field followed by This appendix describes the format of the Options Field followed by
the packet format of the Opaque LSA. the packet format of the Opaque LSA.
A.1 The Options Field A.1 The Options Field
skipping to change at page 14, line 17 skipping to change at page 16, line 17
originated into. originated into.
o A value of 11 denotes that the LSA is flooded throughout the 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). Autonomous System (e.g., has the same scope as type-5 LSAs).
Opaque LSAs with AS-wide scope are not flooded into stub areas. Opaque LSAs with AS-wide scope are not flooded into stub areas.
Syntax Of The Opaque LSA's Link-State ID Syntax Of The Opaque LSA's Link-State ID
The link-state ID of the Opaque LSA is divided into an Opaque 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 Type field (the first 8 bits) and an Opaque ID (the remaining 24
bits). Opaque type values in the range of 128-255 are reserved bits). Opaque type values in the range of 0-127 are reserved for
for private and experimental use. definition by the IANA (iana@ISI.EDU) whereas Opaque type values
in the range of 128-255 are reserved for private and experimental
use.
 End of changes. 21 change blocks. 
42 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/