Extensions to OSPF
facilitating the deployment of non-backward-compatible changes.Cisco Systems510 McCarthy Blvd.Milpitas95035CAUSAmdubrovs@cisco.comCisco Systems10 West Tasman DriveSan Jose95134CAUSArashi@cisco.comHuawei Technologies2330 Central ExpresswaySanta Clara95050CAUSAdean.cheng@huawei.comThis document specifies a generic mechanism that facilitates the
deployment of non-backward-compatible changes in OSPF protocol. This
mechanism allows the OSPF routers to advertise the capability of
non-backward-compatible functionality and to make the functionality
operational only when supported by all participating routers. Depending
on the functionality scope, capability advertisements must be propagated
across a link, area or autonomous system (AS). For link and area scope
functionality, Router Information Link State Advertisement (LSA) is
utilized to propagate the capability information. For the cases when
compatibility must be maintained across the whole OSPF autonomous
system, new Area Information (AI) LSA is introduced. The AI LSA is a
TLV-based analog of Indication-LSA that is used for demand circuit
functionality and described in RFC1793.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.The evolution of OSPF protocol brought up changes that are not
backward-compatible. Some of those changes (for example
RFC1583Compatibility flag) can cause a routing loop in mixed
environments. It therefore requires careful deployment planning, which
is difficult to achieve in complex multivendor topologies. Most
importantly, the lack of standard extendable mechanism that facilitates
the deployment of non-backward-compatible changes obstructs the
development of new protocol extensions.As a solution for the above described problems, this document
proposes an extendable mechanism, which guarantees that the
non-backward-compatible functionality is turned on only when supported
by all participating routers.The proposed mechanism is not new; the existing demand circuit
functionality uses the same approach. This
document simply makes the solution generic.Each participating router advertises the capability of functionality
that it supports in the Router Information LSA as described in RFC 4970
. Routers only turn on a new functionality when
it is supported by every router within the functionality scope. The
routers revert back to their original behavior as soon as one
incompatible device is detected.The scope of functionality could be link, area or AS wide. For link
and area wide, the router accordingly originates a link or area scope RI
LSA. For AS functionality, an area scope RI LSA is used. To propagate
compatibility information across area borders, a new LSA type Area
Information is introduced.The Area Border Router inserts a particular capability TLV into an
Area Information (AI) LSA to signal that at least one router in the
attached areas does not support the functionality. Therefore, the
presence of a particular TLV in AI LSA signals the opposite case to the
presence of the same TLV in RI LSA. The AI LSA origination algorithm is
very similar to the algorithm of Indication-LSA origination and outlined below in .
The AI LSA format is very similar to RI LSA .
In OSPFv2, the AI LSA will be implemented with a new opaque LSA type ID.
In OSPFv3, the AI LSA will be implemented with a new LSA type function
code. In both protocols, the AI LSA will have an area flooding scope.
The exact format of AI LSA is outlined in the sections 3.1 and 3.2.OSPFv2 routers will advertise an area-scoped Opaque-LSA . The OSPFv2 Area Information LSA has a Link-State
type of 10 indicating that the flooding scope is area-local, an Opaque
type of TBD and Opaque ID of 0.The format of the TLVs within the body of an AI LSA is
defined in .The OSPFv3 Area Information LSA has a function code of TBD while
the S1/S2 bits are set to 1/0, indicating the area flooding scope for
the LSA.The U bit is set indicating that the OSPFv3 AI LSA should be
flooded even if it is not understood. The Link State ID (LSID) value
for this LSA is 0. This is unambiguous since an OSPFv3 router will
only advertise a single AI LSA per flooding scope.The format of the TLVs within the body of an AI LSA is defined in
.The format of the TLVs within the body of an AI LSA is exactly the
same as the corresponding RI LSA TLV format, which in turn is the same
as the format used by the Traffic Engineering Extensions to OSPF [TE].
The LSA payload consists of one or more nested Type/Length/Value (TLV)
triplets. The format of each TLV is:The Length field defines the length of the value portion in
octets (thus a TLV with no value portion would have a length of 0).
The TLV is padded to a 4-octet alignment; padding is not included in
the length field (so a 3-octet value would have a length of 3, but the
total size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned. For example, a 1-byte value would have the length field set
to 1, and 3 octets of padding would be added to the end of the value
portion of the TLV. Unrecognized types are ignored.When new Area Information LSA TLV is defined, the specification
MUST explicitly state whether the TLV is applicable to OSPFv2 only,
OSPFv3 only, or both OSPFv2 and OSPFv3.Through the origination of AI LSAs, information about the existence
of incapable routers propagates from non-backbone areas, to the
backbone area and from there to all other areas. The following two
cases summarize the requirements for an area border router to
originate AI LSAs:1. Suppose an area border router (Router X) is connected to a
non-backbone OSPF area (Area A). Furthermore, assume that Area A has
an incapable router i.e. a router LSA without corresponding RI LSA
TLV. Then Router X should originate the AI LSAs into all other
directly connected areas, including the backbone area, in accordance
with the guidelines of .2. Suppose an area border router (Router X) is connected to the
backbone OSPF area (Area 0.0.0.0). Furthermore, assume that the
backbone has an indication of an existing incapable device via
eithera) the existence of a router LSA without corresponding RI LSA
TLVorb) AI LSAs that have been originated by routers other than Router
X. Then Router X should originate AI LSAs into all other directly
connected non-backbone areas, keeping the guidelines of in mind.The following guidelines should be observed by an area border
router (Router X) when originating AI LSAs in order to limit their
number. First, AI LSAs with corresponding TLV are not originated
into an Area A when A has incapable routers; i.e. router LSAs
without corresponding RI LSA TLV. Secondly, if another area border
router has originated an AI LSA with corresponding TLV into Area A,
and that area border router has a higher OSPF Router ID than Router
X (same tie-breaker as for forwarding the address origination; see
Section 12.4.4.1 of ), then Router X should not
originate an AI LSA with corresponding TLV into Area A.For negotiating link scope capability before adjacency is fully
formed, link local signaling should be used instead
of RI LSA. An example of such a functionality would be a modification to
OSPF adjacency formation FSM.The mechanism is backward compatible with the existing OSPF
specification. Setting the U bit in OSPFv3 AI LSA allows LSA propagation
even if some routers in the area can not decode the LSA content. The
Opaque LSA specification also guarantees the
propagation of OSPFv2 AI LSA, even if the content is not understood by
some of the transit routers.The following IANA assignments are to be made from existing
registries:The OSPFv2 opaque LSA option type TBD will need to be reserved for
the OSPFv2 AI opaque LSA via IETF Consensus.OSPFv3 LSA Function Codes TBD will need to be reserved for the OSPFv3
Area Information (AI) LSA via Standards Action.Both Standards Action and IETF Consensus registration procedures are
described in the update of RFC 2434
[I-D.narten-iana-considerations-rfc2434bis].This document describes a generic mechanism for deployment of
non-backward-compatible changes and it introduces Area-Information LSA
for AS scope compatibility. The security considerations for those
entities are as critical as the topology information currently
advertised by the base OSPF protocol. Security considerations for the
base OSPF protocol are covered in [OSPF] and [OSPFV3].The author would like to acknowledge the helpful comments of Cisco
OSPF Development team.This memo is a product of the OSPF Working Group.Traffic Engineering (TE) Extensions to OSPF Version 2This document describes extensions to the OSPF protocol version
2 to support intra-area Traffic Engineering (TE), using Opaque
Link State Advertisements.The OSPF Opaque LSA Option
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology. This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]
OSPF Version 2Ascend Communications, Inc.1 Robbins RoadWestfordMA01886978-952-1367978-392-2075jmoy@casc.com
Routing
open shortest-path first protocolroutingOSPFThis memo documents version 2 of the OSPF protocol. OSPF is a
link-state routing protocol. It is designed to be run internal to
a single Autonomous System. Each OSPF router maintains an
identical database describing the Autonomous System's topology.
From this database, a routing table is calculated by constructing
a shortest- path tree.OSPF recalculates routes quickly in the face of topological
changes, utilizing a minimum of routing protocol traffic. OSPF
provides support for equal-cost multipath. An area routing
capability is provided, enabling an additional level of routing
protection and a reduction in routing protocol traffic. In
addition, all OSPF routing protocol exchanges are
authenticated.The differences between this memo and RFC 2178 are explained in
Appendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFCs 2178, 1583, and 1247 will
interoperate.Please send comments to ospf@gated.cornell.edu.Extensions to OSPF for Advertising Optional Router
CapabilitiesIt is useful for routers in an OSPFv2 or OSPFv3 routing domain
to know the capabilities of their neighbors and other routers in
the routing domain. This document proposes extensions to OSPFv2
and OSPFv3 for advertising optional router capabilities. A new
Router Information (RI) Link State Advertisement (LSA) is proposed
for this purpose. In OSPFv2, the RI LSA will be implemented with a
new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented
with a new LSA type function code. In both protocols, the RI LSA
can be advertised at any of the defined flooding scopes (link,
area, or autonomous system (AS)). [STANDARDS-TRACK]OSPF for IPv6This document describes the modifications to OSPF to support
version 6 of the Internet Protocol (IPv6). The fundamental
mechanisms of OSPF (flooding, Designated Router (DR) election,
area support, Short Path First (SPF) calculations, etc.) remain
unchanged. However, some changes have been necessary, either due
to changes in protocol semantics between IPv4 and IPv6, or simply
to handle the increased address size of IPv6. These modifications
will necessitate incrementing the protocol version from version 2
to version 3. OSPF for IPv6 is also referred to as OSPF version 3
(OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for
IPv6 as described herein include the following. Addressing
semantics have been removed from OSPF packets and the basic Link
State Advertisements (LSAs). New LSAs have been created to carry
IPv6 addresses and prefixes. OSPF now runs on a per-link basis
rather than on a per-IP-subnet basis. Flooding scope for LSAs has
been generalized. Authentication has been removed from the OSPF
protocol and instead relies on IPv6's Authentication Header and
Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6
are almost as compact as those in OSPF for IPv4. Most fields and
packet- size limitations present in OSPF for IPv4 have been
relaxed. In addition, option handling has been made more
flexible.All of OSPF for IPv4's optional capabilities, including demand
circuit support and Not-So-Stubby Areas (NSSAs), are also
supported in OSPF for IPv6. [STANDARDS-TRACK]OSPF Link-Local SignalingOSPF is a link-state intra-domain routing protocol. OSPF
routers exchange information on a link using packets that follow a
well-defined fixed format. The format is not flexible enough to
enable new features that need to exchange arbitrary data. This
document describes a backward-compatible technique to perform
link-local signaling, i.e., exchange arbitrary data on a link.
This document replaces the experimental specification published in
RFC 4813 to bring it on the Standards Track.Extending OSPF to Support
Demand CircuitsCascade Communications Corp.5 Carlisle RoadWestfordMA01886US+1 508 692 2600 x394+1 508 692 9214jmoy@casc.comThis memo defines enhancements to the OSPF protocol that allow
efficient operation over "demand circuits". Demand circuits are
network segments whose costs vary with usage; charges can be based
both on connect time and on bytes/packets transmitted. Examples of
demand circuits include ISDN circuits, X.25 SVCs, and dial-up
lines. The periodic nature of OSPF routing traffic has until now
required a demand circuit's underlying data-link connection to be
constantly open, resulting in unwanted usage charges. With the
modifications described herein, OSPF Hellos and the refresh of
OSPF routing information are suppressed on demand circuits,
allowing the underlying data-link connections to be closed when
not carrying application traffic.Demand circuits and regular network segments (e.g., leased
lines) are allowed to be combined in any manner. In other words,
there are no topological restrictions on the demand circuit
support. However, while any OSPF network segment can be defined as
a demand circuit, only point-to-point networks receive the full
benefit. When broadcast and NBMA networks are declared demand
circuits, routing update traffic is reduced but the periodic
sending of Hellos is not, which in effect still requires that the
data-link connections remain constantly open.While mainly intended for use with cost-conscious network links
such as ISDN, X.25 and dial-up, the modifications in this memo may
also prove useful over bandwidth-limited network links such as
slow-speed leased lines and packet radio.The enhancements defined in this memo are backward-compatible
with the OSPF specification defined in, and with the OSPF
extensions defined in(OSPF NSSA areas),(MOSPF) and(OSPF
Point-to-MultiPoint Interface).This memo provides functionality similar to that specified for
RIP in, with the main difference being the way the two proposals
handle oversubscription (see Sections 4.3 and 7 below). However,
because OSPF employs link-state routing technology as opposed to
RIP's Distance Vector base, the mechanisms used to achieve the
demand circuit functionality are quite different.Please send comments to ospf@gated.cornell.edu.