draft-ietf-ospf-rfc2370bis-00.txt   draft-ietf-ospf-rfc2370bis-01.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Obsoletes: 2370 Igor Bryskin (Adva) Obsoletes: 2370 Igor Bryskin (Adva)
Category: Standards Track Alex Zinin (Alcatel) Category: Standards Track Alex Zinin (Alcatel)
Expiration Date: June 2007 Original Author: Expiration Date: December 2007 Original Author:
Rob Coltun (Acoustra Productions) Rob Coltun (Acoustra Productions)
December 2006
The OSPF Opaque LSA Option The OSPF Opaque LSA Option
draft-ietf-ospf-rfc2370bis-00.txt draft-ietf-ospf-rfc2370bis-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 36
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This memo defines enhancements to the OSPF protocol to support a new This document defines enhancements to the OSPF protocol to support a
class of link-state advertisements (LSA) called Opaque LSAs. Opaque new class of link-state advertisements (LSA) called Opaque LSAs.
LSAs provide a generalized mechanism to allow for the future Opaque LSAs provide a generalized mechanism to allow for the future
extensibility of OSPF. Opaque LSAs consist of a standard LSA header extensibility of OSPF. Opaque LSAs consist of a standard LSA header
followed by application-specific information. The information field followed by application-specific information. The information field
may be used directly by OSPF or by other applications. Standard OSPF may be used directly by OSPF or by other applications. Standard OSPF
link-state database flooding mechanisms are used to distribute Opaque link-state database flooding mechanisms are used to distribute Opaque
LSAs to all or some limited portion of the OSPF topology. LSAs to all or some limited portion of the OSPF topology.
This document replaces [RFC2370], and adds to it a mechanism to This document replaces RFC 2370 and adds to it a mechanism to enable
enable an OSPF router to validate AS-scope opaque LSAs originated an OSPF router to validate AS-scope opaque LSAs originated outside of
outside of the router's OSPF area. the router's OSPF area.
Contents Contents
1 Conventions used in this document ......................... 3 1 Conventions used in this document ......................... 3
2 Overview .................................................. 3 2 Introduction .............................................. 3
2.1 Organization Of This Document ............................. 3 2.1 Organization Of This Document ............................. 3
2.2 Acknowledgments ........................................... 4 2.2 Acknowledgments ........................................... 4
3 The Opaque LSA ............................................ 4 3 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 Protocol Data Structures .................................. 7 4 Protocol Data Structures .................................. 7
4.1 Additions To The OSPF Neighbor Structure .................. 8 4.1 Additions To The OSPF Neighbor Structure .................. 8
5 Inter-Area Considerations ................................. 8 5 Inter-Area Considerations ................................. 8
6 Management Considerations ................................. 9 6 Management Considerations ................................. 9
7 Backward Compatibility .................................... 9 7 Backward Compatibility .................................... 9
skipping to change at page 3, line 11 skipping to change at page 3, line 11
12.2 The Opaque LSA ............................................ 14 12.2 The Opaque LSA ............................................ 14
13 Full Copyright Statement .................................. 16 13 Full Copyright Statement .................................. 16
14 Intellectual Property ..................................... 16 14 Intellectual Property ..................................... 16
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Overview 2. Introduction
Over the last several years the OSPF routing protocol [OSPF] has been Over the last several years the OSPF routing protocol [OSPF] has been
widely deployed throughout the Internet. As a result of this widely deployed throughout the Internet. As a result of this
deployment and the evolution of networking technology, OSPF has been deployment and the evolution of networking technology, OSPF has been
extended to support many options; this evolution will obviously extended to support many options; this evolution will obviously
continue. continue.
This memo defines enhancements to the OSPF protocol to support a new This document defines enhancements to the OSPF protocol to support a
class of link-state advertisements (LSA) called Opaque LSAs. Opaque new class of link-state advertisements (LSA) called Opaque LSAs.
LSAs provide a generalized mechanism to allow for the future Opaque LSAs provide a generalized mechanism to allow for the future
extensibility of OSPF. The information contained in Opaque LSAs may extensibility of OSPF. The information contained in Opaque LSAs may
be used directly by OSPF or indirectly by some application wishing to be used directly by OSPF or indirectly by some application wishing to
distribute information throughout the OSPF domain. The exact use of distribute information throughout the OSPF domain. The exact use of
Opaque LSAs is beyond the scope of this memo. Opaque LSAs is beyond the scope of this document.
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 the Opaque LSA uses the link-state database distribution mechanism
for flooding this information throughout the topology. The link- for flooding this information throughout the topology. The link-
state type field of the Opaque LSA identifies the LSA's range of state type field of the Opaque LSA identifies the LSA's range of
topological distribution. This range is referred to as the Flooding topological distribution. This range is referred to as the Flooding
Scope. Scope.
It is envisioned that an implementation of the Opaque option provides It is envisioned that an implementation of the Opaque option provides
skipping to change at page 4, line 7 skipping to change at page 4, line 7
2.1. Organization Of This Document 2.1. Organization Of This Document
This document first defines the three types of Opaque LSAs followed This document first defines the three types of Opaque LSAs followed
by a description of OSPF packet processing. The packet processing by a description of OSPF packet processing. The packet processing
sections include modifications to the flooding procedure and to the sections 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
We would like to thank Acee Lindem for his review and useful We would like to thank Acee Lindem for his detailed review and useful
feedback. The handling of AS-scope opaque LSAs described in this feedback. The handling of AS-scope opaque LSAs described in this
document is taken from draft-bryskin-ospf-lsa- document is taken from draft-bryskin-ospf-lsa-
type11-validation-00.txt. type11-validation-00.txt.
3. The Opaque LSA 3. The Opaque LSA
Opaque LSAs are types 9, 10 and 11 link-state advertisements. Opaque Opaque LSAs are types 9, 10, and 11 link-state advertisements.
LSAs consist of a standard LSA header followed by a 32-bit aligned Opaque LSAs consist of a standard LSA header followed by a 32-bit
application-specific information field. Standard link-state database aligned application-specific information field. Standard link-state
flooding mechanisms are used for distribution of Opaque LSAs. The database flooding mechanisms are used for distribution of Opaque
range of topological distribution (i.e., the flooding scope) of an LSAs. The range of topological distribution (i.e., the flooding
Opaque LSA is identified by its link-state type. This section scope) of an Opaque LSA is identified by its link-state type. This
documents the flooding of Opaque LSAs. section documents 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 the Autonomous System (AS). The flooding scope of type-11
LSAs are equivalent to the flooding scope of AS-external (type-5) LSAs 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
all transit areas, 2) not flooded into stub areas or NSSAs from throughout all transit areas, 2) not flooded into stub areas or
the backbone and 3) not originated by routers into their NSSAs from the backbone and 3) not originated by routers into
connected stub areas or NSSAs. As with type-5 LSAs, if a type-11 their connected stub areas or NSSAs. As with type-5 LSAs, if a
Opaque LSA is received in a stub area or NSSA from a neighboring type-11 Opaque LSA is received in a stub area or NSSA from a
router within the stub area or NSSA the LSA is rejected. neighboring router within the stub area or NSSA the LSA is
rejected.
The link-state ID of the Opaque LSA is divided into an Opaque type 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 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. bits). The packet format of the Opaque LSA is given in Appendix A.
Section 7 describes Opaque type allocation and assignment. Section 7 describes Opaque type allocation and assignment.
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 state database. The receiver must not accept Opaque LSAs that
skipping to change at page 6, line 7 skipping to change at page 6, line 8
mixed together in a routing domain, the Opaque LSAs are typically not mixed together in a routing domain, the Opaque LSAs are typically not
flooded to the non-opaque-capable routers. As a general design flooded to the non-opaque-capable routers. As a general design
principle, optional OSPF advertisements are only flooded to those principle, optional OSPF advertisements are only flooded to those
routers that understand them. routers that understand them.
An opaque-capable router learns of its neighbor's opaque capability An opaque-capable router learns of its neighbor's opaque capability
at the beginning of the "Database Exchange Process" (see Section 10.6 at the beginning of the "Database Exchange Process" (see Section 10.6
of [OSPF], receiving Database Description packets from a neighbor in of [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;
the O-bit MUST NOT be set in packets other than Database Description the O-bit SHOULD NOT be set and SHOULD be ignored when received in
packets. Then, in the next step of the Database Exchange process, packets other than Database Description packets. Then, in the next
Opaque LSAs are included in the Database summary list that is sent to step of the Database Exchange process, Opaque LSAs are included in
the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) when the the Database summary list that is sent to the neighbor (see Sections
neighbor is opaque capable. 3.2 below and 10.3 of [OSPF]) when the neighbor is opaque capable.
When flooding Opaque-LSAs to adjacent neighbors, an opaque-capable When flooding Opaque-LSAs to adjacent neighbors, an 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 only flooded to opaque-capable neighbors. To be more precise, in
Section 13.3 of [OSPF], Opaque LSAs MUST placed on the link-state Section 13.3 of [OSPF], Opaque LSAs MUST be placed on the link-state
retransmission lists of opaque-capable neighbors, and MUST NOT be retransmission lists of opaque-capable neighbors and MUST NOT be
placed on the link-state retransmission lists of non-opaque-capable placed on the link-state retransmission lists of non-opaque-capable
neighbors. However, when sending Link State Update packets as neighbors. However, when sending Link State Update packets as
multicasts, a non-opaque-capable neighbor may (inadvertently) receive multicasts, a non-opaque-capable neighbor may (inadvertently) receive
Opaque LSAs. The non-opaque-capable router will then simply discard Opaque LSAs. The non-opaque-capable router will then simply discard
the LSA (see Section 13 of [OSPF], receiving LSAs having unknown LS the LSA (see Section 13 of [OSPF], receiving LSAs having unknown LS
types). types).
Information contained in received opaque LSAs SHOULD only be used Information contained in received opaque LSAs SHOULD only be used
when the router originating the LSA is reachable. As mentioned in when the router originating the LSA is reachable. As mentioned in
[OSPFv3], reachability validation MAY be done less frequently than [OSPFv3], reachability validation MAY be done less frequently than
skipping to change at page 6, line 49 skipping to change at page 6, line 50
State(s): ExStart State(s): ExStart
Event: NegotiationDone Event: NegotiationDone
New state: Exchange New state: Exchange
Action: The router MUST list the contents of its entire area Action: The router MUST list the contents of its entire area
link-state database in the neighbor Database summary link-state database in the neighbor Database summary
list. The area link-state database consists of the list. The area link-state database consists of the
Router LSAs, Network LSAs, Summary LSAs and types 9 and Router LSAs, Network LSAs, Summary LSAs, type-9 opaque
10 Opaque LSAs contained in the area structure, along LSAs, and type-10 opaque LSAs contained in the area
with AS External and type-11 Opaque LSAs contained in structure, along with AS External and type-11 Opaque
the global structure. AS External and type-11 Opaque LSAs contained in the global structure. AS External
LSAs MUST be omitted from a virtual neighbor's Database and type-11 Opaque LSAs MUST be omitted from a
summary list. AS External LSAs and type-11 Opaque LSAs virtual neighbor's Database summary list. AS External
MUST be omitted from the Database summary list if the LSAs and type-11 Opaque LSAs MUST be omitted from the
area has been configured as a stub area or NSSA (see Database summary list if the area has been configured
Section 3.6 of [OSPF]). as a stub area or NSSA (see Section 3.6 of [OSPF]).
Type-9 Opaque LSAs MUST be omitted from the Database Type-9 Opaque LSAs MUST be omitted from the Database
summary list if the interface associated with the summary list if the interface associated with the
neighbor is not the interface associated with the Opaque neighbor is not the interface associated with the Opaque
LSA (as noted upon reception). LSA (as noted upon reception).
Any advertisement whose age is equal to MaxAge MUST be Any advertisement whose age is equal to MaxAge MUST be
omitted from the Database summary list. It MUST instead omitted from the Database summary list. It MUST instead
be added to the neighbor's link-state retransmission be added to the neighbor's link-state retransmission
list. A summary of the Database summary list will be list. A summary of the Database summary list will be
sent to the neighbor in Database Description packets. sent to the neighbor in Database Description packets.
Each Database Description Packet MUST have a DD sequence Only one Database Description Packet is allowed to be
number, and MUST be explicitly acknowledged. Only one outstanding at any one time. For more detail on the
Database Description Packet is allowed to be outstanding sending and receiving of Database Description packets,
at any one time. For more detail on the sending and see Sections 10.6 and 10.8 of [OSPF].
receiving of Database Description packets, see Sections
10.6 and 10.8 of [OSPF].
4. Protocol Data Structures 4. Protocol Data Structures
The Opaque option is described herein in terms of its operation on The Opaque option is described herein in terms of its operation on
various protocol data structures. These data structures are included various protocol data structures. These data structures are included
for explanatory uses only, and are not intended to constrain an for explanatory uses only. They are not intended to constrain an
implementation. In addition to the data structures listed below, this implementation. In addition to the data structures listed below, this
specification references the various data structures (e.g., OSPF specification references the various data structures (e.g., OSPF
neighbors) defined in [OSPF]. neighbors) defined in [OSPF].
In an OSPF router, the following item is added to the list of global In an OSPF router, the following item is added to the list of global
OSPF data structures described in Section 5 of [OSPF]: OSPF data structures described in Section 5 of [OSPF]:
o Opaque capability. Indicates whether the router is running the o Opaque capability. Indicates whether the router is running the
Opaque option (i.e., capable of storing Opaque LSAs). Such a Opaque option (i.e., capable of storing Opaque LSAs). Such a
router will continue to inter-operate with non-opaque-capable router will continue to inter-operate with non-opaque-capable
skipping to change at page 8, line 15 skipping to change at page 8, line 15
4.1. Additions To The OSPF Neighbor Structure 4.1. Additions To The OSPF Neighbor Structure
The OSPF neighbor structure is defined in Section 10 of [OSPF]. In The OSPF neighbor structure is defined in Section 10 of [OSPF]. In
an opaque-capable router, the following items are added to the OSPF an opaque-capable router, the following items are added to the OSPF
neighbor structure: neighbor structure:
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 option is learned in the Database Exchange process through
reception of the neighbor's Database Description packets, and reception of the neighbor's Database Description packets and
determines whether Opaque LSAs are flooded to the neighbor. For a determines whether Opaque LSAs are flooded to the neighbor. For a
more detailed explanation of the flooding of the Opaque LSA see more detailed explanation of the flooding of the Opaque LSA see
section 3 of this document. section 3 of this document.
5. Inter-Area Considerations 5. Inter-Area Considerations
As defined above, link-state type-11 opaque LSAs are flooded As defined above, link-state type-11 opaque LSAs are flooded
throughout the Autonomous System (AS). One issue related to such AS throughout the Autonomous System (AS). One issue related to such AS
scoped Opaque LSAs is that there must be a way for OSPF routers in scoped Opaque LSAs is that there must be a way for OSPF routers in
remote areas to check availability of the LSA originator. remote areas to check availability of the LSA originator.
Specifically, if an OSPF router originates a type-11 LSA and, after Specifically, if an OSPF router originates a type-11 LSA and, after
that, goes out of service, OSPF routers located outside of the that, goes out of service, OSPF routers located outside of the
originator's OSPF area have no way of detecting this fact and may use originator's OSPF area have no way of detecting this fact and may use
the stale information for a considerable period of time (up to 60 the stale information for a considerable period of time (up to 60
minutes). This could prove to be suboptimal for some applications, minutes). This could prove to be suboptimal for some applications and
and may result in others not functioning. may result in others not functioning.
Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem
as a receiving router can detect an out of service router via the as a receiving router can detect if the advertising router is
loss of an OSPF adjacency, in the case of type-9 LSAs, or the loss of reachable within the LSA's respective flooding scope. In the case of
the sequence of OSPF adjacencies, in the case of type-10 LSAs, type-9 LSAs, the originating router must be an OSPF neighbor in
connecting the LSA receiving and originating routers. Exchange state or greater. In the case of type-10 Opaque LSAs, the
intra-area SPF calculation will determine the advertising router's
reachability.
There is a parallel issue in OSPF for the AS scoped AS-external-LSAs There is a parallel issue in OSPF for the AS scoped AS-external-LSAs
(type-5 LSAs). OSPF addresses this by using AS border information (type-5 LSAs). OSPF addresses this by using AS border information
advertised in ASBR-summary-LSAs (type-4 LSAs), see [OSPF] Section advertised in ASBR-summary-LSAs (type-4 LSAs), see [OSPF] Section
16.4. This same mechanism is reused by this document for type-11 16.4. This same mechanism is reused by this document for type-11
opaque LSAs. opaque LSAs.
To enable OSPF routers in remote areas to check availability of the To enable OSPF routers in remote areas to check availability of the
originator of link-state type-11 opaque LSAs, the originators originator of link-state type-11 opaque LSAs, the originators
advertise themselves as ASBRs. This will enable routers to track the advertise themselves as ASBRs. This will enable routers to track the
reachability of the LSA originator either directly via the SPF reachability of the LSA originator either directly via the SPF
calculation (for routers in the same area) or indirectly via type-4 calculation (for routers in the same area) or indirectly via type-4
LSAs originated by ABRs (for routers in other areas). It is important LSAs originated by ABRs (for routers in other areas). It is important
to note that per [OSPF] this solution does not apply to OSPF stub to note that per [OSPF] this solution does not apply to OSPF stub
areas or NSSAs as neither are AS scoped Opaque LSAs flooded nor are areas or NSSAs as AS scoped opaque LSAs are not flooded into these
ASBR-summary-LSAs originated into such areas. area types.
The procedures related to inter-area opaque LSAs are as follows: The procedures related to inter-area opaque LSAs are as follows:
(1) An OSPF router that is configured to originate AS-scope opaque (1) An OSPF router that is configured to originate AS-scope opaque
LSAs advertise themselves as ASBRs and MUST follow the related LSAs will advertise itself as an ASBR and MUST follow the
requirements related to setting of the Options field E-bit in requirements related to setting of the Options field E-bit in
OSPF LSA headers as specified in [OSPF]. OSPF LSA headers as specified in [OSPF].
(2) When processing a received type-11 Opaque LSA, the router MUST (2) When processing a received type-11 Opaque LSA, the router MUST
lookup the routing table entries (potentially one per attached lookup the routing table entries (potentially one per attached
area) for the AS boundary router (ASBR) that originated the LSA. area) for the AS boundary router (ASBR) that originated the LSA.
If no entries exist for router ASBR (i.e., ASBR is unreachable), If no entries exist for router ASBR (i.e., the ASBR is
the router MUST do nothing with this LSA. It also MUST unreachable), the router MUST do nothing with this LSA. It also
discontinue using all Opaque LSAs injected into the network by MUST discontinue using all Opaque LSAs injected into the network
the same originator whenever it is detected that the originator by the same originator whenever it is detected that the
is unreachable. originator is unreachable.
6. Management Considerations 6. Management Considerations
The updated OSPF MIB provides explicit support for opaque LSAs and The updated OSPF MIB, [RFC4750], provides explicit support for opaque
SHOULD be used to support implementations of this document. See LSAs and SHOULD be used to support implementations of this document.
Section 12.3 of [MIB-UPDATE] for details. In addition to this See Section 12.3 of [RFC4750] for details. In addition to that
section, implementation supporting [MIB-UPDATE] will include opaque section, implementations supporting [RFC4750] will also include
LSAs in all appropriate generic LSA objects, e.g., opaque LSAs in all appropriate generic LSA objects, e.g.,
ospfOriginateNewLsas, ospfOriginateNewLsas and ospfLsdbTable. ospfOriginateNewLsas, and ospfLsdbTable.
7. Backward Compatibility 7. Backward Compatibility
The solution proposed in this memo introduces no interoperability The solution proposed in this document introduces no interoperability
issues. In the case that a non-opaque-capable neighbor receives issues. In the case that a non-opaque-capable neighbor receives
Opaque LSAs, per [OSPF], the non-opaque-capable router will simply Opaque LSAs, per [OSPF], the non-opaque-capable router will simply
discard the LSA. discard the LSA.
Note, that OSPF routers that implement [RFC2370] will continue using Note that OSPF routers that implement [RFC2370] will continue using
stale type-11 LSAs even when the LSA originator implements the Inter- stale type-11 LSAs even when the LSA originator implements the Inter-
area procedures, see Section 6, of this document. area procedures described in Section 6 of this document.
8. Security Considerations 8. 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 protocol information. The second is denial of service attacks
resulting from repetitive origination of the same router resulting from repetitive origination of the same router
advertisement or origination a large number of distinct advertisement or origination a large number of distinct
advertisements resulting in database overflow. Note that both of advertisements resulting in database overflow. Note that both of
skipping to change at page 11, line 17 skipping to change at page 11, line 17
details a way of gracefully handling unanticipated database details a way of gracefully handling unanticipated database
overflows. overflows.
In the case of type-11 Opaque LSAs, this document reuses an ASBR In the case of type-11 Opaque LSAs, this document reuses an ASBR
tracking mechanism that is already employed in basic OSPF for type-5 tracking mechanism that is already employed in basic OSPF for type-5
LSAs. Therefore, applying it to type-11 Opaque LSAs does not create LSAs. Therefore, applying it to type-11 Opaque LSAs does not create
any threats that are not already known for type-5 LSAs. any threats that are not already known for type-5 LSAs.
9. IANA Considerations 9. IANA Considerations
There are no changes to the IANA number assignment requirements from
[RFC2370].
Opaque types are maintained by the IANA. Extensions to OSPF which Opaque types are maintained by the IANA. Extensions to OSPF which
require a new Opaque type must be reviewed by the OSPF working group. require a new Opaque type must be reviewed by the OSPF working group.
In the event that the OSPF working group has disbanded the review In the event that the OSPF working group has disbanded the review
shall be performed by a recommended Designated Expert. shall be performed by a recommended Designated Expert.
Following the policies outlined in [IANA], Opaque type values in the Following the policies outlined in [IANA], Opaque type values in the
range of 0-127 are allocated through an IETF Consensus action and range of 0-127 are allocated through an IETF Consensus action and
Opaque type values in the range of 128-255 are reserved for private Opaque type values in the range of 128-255 are reserved for private
and experimental use. and experimental use.
10. References 10. References
10.1. Normative References 10.1. Normative References
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995. 1793, April 1995.
[IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, October 1998. Considerations Section in RFCs", BCP 26, October 1998.
[MIB-UPDATE] Joyal, D., et. al., "OSPF Version 2 Management
Information Base", draft-ietf-ospf-mib-update-, May
2006.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997. requirements levels", RFC 2119, March 1997.
[RFC4750] Joyal, D., et. al., "OSPF Version 2 Management Information
Base", RFC 4750, November 2006.
10.2. Informative References 10.2. Informative References
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994. 1994.
[NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", [NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, January 2003.
[OSPF-MT] Psenak, P., et al., "Multi-Topology (MT) Routing in OSPF", [OSPF-MT] Psenak, P., et al., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-, February 2006. draft-ietf-ospf-mt-, January 2007.
[OSPFv3] Coltun, R., et al. "OSPF for IPv6", [OSPFv3] Coltun, R., et al. "OSPF for IPv6",
draft-ietf-ospf-ospfv3-update-, November 2006. draft-ietf-ospf-ospfv3-update-, May 2007.
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998. July 1998.
[RFC4576] Rosen, E., et. al., "Using a Link State Advertisement [RFC4576] Rosen, E., et. al., "Using a Link State Advertisement
(LSA) Options Bit to Prevent Looping in BGP/MPLS IP (LSA) Options Bit to Prevent Looping in BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4576, June 2006. Virtual Private Networks (VPNs)", RFC 4576, June 2006.
skipping to change at page 13, line 22 skipping to change at page 13, line 22
The OSPF Options field is present in OSPF Hello packets, Database The OSPF Options field is present in OSPF Hello packets, Database
Description packets and all link-state advertisements. The Options Description packets and all link-state advertisements. The Options
field enables OSPF routers to support (or not support) optional field enables OSPF routers to support (or not support) optional
capabilities, and to communicate their capability level to other OSPF capabilities, and to communicate their capability level to other OSPF
routers. Through this mechanism routers of differing capabilities can routers. Through this mechanism routers of differing capabilities can
be mixed within an OSPF routing domain. be mixed within an OSPF routing domain.
When used in Hello packets, the Options field allows a router to When used in Hello packets, the Options field allows a router to
reject a neighbor because of a capability mismatch. Alternatively, reject a neighbor because of a capability mismatch. Alternatively,
when capabilities are exchanged in Database Description packets a when capabilities are exchanged in Database Description packets a
router can choose not to forward certain link-state advertisements to router can choose not to flood certain link-state advertisements to a
a neighbor because of its reduced functionality. Lastly, listing neighbor because of its reduced functionality. Lastly, listing
capabilities in link-state advertisements allows routers to forward capabilities in link-state advertisements allows routers to forward
traffic around reduced functionality routers by excluding them from traffic around reduced functionality routers by excluding them from
parts of the routing table calculation. parts of the routing table calculation.
All eight bits of the OSPF Options field have been assigned, although All eight bits of the OSPF Options field have been assigned, although
only the O-bit is described completely by this memo. Each bit is only the O-bit is described completely by this document. Each bit is
described briefly below. Routers SHOULD reset (i.e., clear) described briefly below. Routers SHOULD reset (i.e., clear)
unrecognized bits in the Options field when sending Hello packets or unrecognized bits in the Options field when sending Hello packets or
Database Description packets and when originating link-state Database Description packets and when originating link-state
advertisements. Conversely, routers encountering unrecognized Option advertisements. Conversely, routers encountering unrecognized Option
bits in received Hello Packets, Database Description packets or link- bits in received Hello Packets, Database Description packets or link-
state advertisements SHOULD ignore the capability and process the state advertisements SHOULD ignore the capability and process the
packet/advertisement normally. packet/advertisement normally.
+--------------------------------------+ +--------------------------------------+
| DN | O | DC | EA | N/P | MC | E | MT | | DN | O | DC | EA | N/P | MC | E | MT |
skipping to change at page 14, line 33 skipping to change at page 14, line 33
O-bit O-bit
This bit describes the router's willingness to receive and This bit describes the router's willingness to receive and
forward Opaque-LSAs as specified in this document. forward Opaque-LSAs as specified in this document.
DN-bit DN-bit
This bit is used to prevent looping in BGP/MPLS IP VPNs, This bit is used to prevent looping in BGP/MPLS IP VPNs,
as specified in [RFC4576]. as specified in [RFC4576].
12.2. The Opaque LSA 12.2. The Opaque LSA
Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These Opaque LSAs are Type 9, 10, and 11 link-state advertisements. These
advertisements MAY be used directly by OSPF or indirectly by some advertisements MAY be used directly by OSPF or indirectly by some
application wishing to distribute information throughout the OSPF application wishing to distribute information throughout the OSPF
domain. The function of the Opaque LSA option is to provide for domain. The function of the Opaque LSA option is to provide for
future extensibility of OSPF. future OSPF extensibility.
Opaque LSAs contain some number of octets (of application-specific Opaque LSAs contain some number of octets (of application-specific
data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA
uses the link-state database distribution mechanism for flooding this uses the link-state database distribution mechanism for flooding this
information throughout the topology. However, the Opaque LSA has a information throughout the topology. However, the Opaque LSA has a
flooding scope associated with it so that the scope of flooding may 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 be link-local (type-9), area-local (type-10) or the entire OSPF
routing domain (type-11). Section 3 of this document describes the routing domain (type-11). Section 3 of this document describes the
flooding procedures for the Opaque LSA. flooding procedures for the Opaque LSA.
0 1 2 3 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 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 | | LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID | | Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 15, line 31 skipping to change at page 15, line 36
The link-state type of the Opaque LSA identifies the LSA's range of The link-state type of the Opaque LSA identifies the LSA's range of
topological distribution. This range is referred to as the Flooding topological distribution. This range is referred to as the Flooding
Scope. The following explains the flooding scope of each of the Scope. The following explains the flooding scope of each of the
link-state types. link-state types.
o A value of 9 denotes a link-local scope. Opaque LSAs with a o A value of 9 denotes a link-local scope. Opaque LSAs with a
link-local scope MUST NOT be flooded beyond the local link-local scope MUST NOT be flooded beyond the local
(sub)network. (sub)network.
o A value of 10 denotes an area-local scope. Opaque LSAs with a o A value of 10 denotes an area-local scope. Opaque LSAs with a
area-local scope MUST NOT be flooded beyond the area that they area-local scope MUST NOT be flooded beyond their area of
are originated into. origin.
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 MUST NOTE be flooded into stub Opaque LSAs with AS-wide scope MUST NOT be flooded into stub
areas or NSSAs. areas or NSSAs.
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 Type 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). field (the first 8 bits) and an Opaque ID (the remaining 24 bits).
See section 7 of this document for a description of Opaque type See section 7 of this document for a description of Opaque type
allocation and assignment. allocation and assignment.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Intellectual Property 14. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at line 698 skipping to change at page 16, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Generated on: Mon Dec 4 12:09:53 EST 2006 Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Generated on: Mon Jun 4 13:52:53 EDT 2007
 End of changes. 42 change blocks. 
100 lines changed or deleted 102 lines changed or added

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