RFC 5340
OSPF for IPv6
Pages: 94
Proposed Standard
→ Errata
Obsoletes: 2740
Updated by: 6845 6860 7503 8362 9454
Proposed Standard
→ Errata
Obsoletes: 2740
Updated by: 6845 6860 7503 8362 9454
Part 4 of 4 – Pages 68 to 94
A.4. LSA Formats
This document defines eight distinct types of LSAs. Each LSA begins with a standard 20-byte LSA header. This header is explained in Appendix A.4.2. Succeeding sections describe each LSA type individually. Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS- external-LSAs, and NSSA-LSAs. Location of specific routers can be advertised across area boundaries in inter-area-router-LSAs. All LSAs are then flooded throughout the OSPF routing domain. The
flooding algorithm is reliable, ensuring that all routers common to a flooding scope have the same collection of LSAs associated with that flooding scope. (See Section 4.5 for more information concerning the flooding algorithm.) This collection of LSAs is called the link- state database. From the link-state database, each router constructs a shortest-path tree with itself as root. This yields a routing table (see Section 11 of [OSPFV2]). For details on the routing table build process, see Section 4.8.A.4.1. IPv6 Prefix Representation
IPv6 addresses are bit strings of length 128. IPv6 routing protocols, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive). Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Appendix A.4.1.1). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words. The default route is represented by a prefix of length 0. Examples of IPv6 Prefix representation in OSPF can be found in Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and Appendix A.4.10.A.4.1.1. Prefix Options
Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations. For example, they can indicate that prefixes are to be ignored in some cases or are to be marked as not readvertisable in others. 0 1 2 3 4 5 6 7 +--+--+--+--+--+-+--+--+ | | | |DN| P|x|LA|NU| +--+--+--+--+--+-+--+--+ The PrefixOptions Field
NU-bit
The "no unicast" capability bit. If set, the prefix should be
excluded from IPv6 unicast calculations. If not set, it should be
included.
LA-bit
The "local address" capability bit. If set, the prefix is
actually an IPv6 interface address of the Advertising Router.
Advertisement of local interface addresses is described in
Section 4.4.3.9. An implementation MAY also set the LA-bit for
prefixes advertised with a host PrefixLength (128).
x-bit
This bit was previously defined as a "multicast" capability bit.
However, the use was never adequately specified and has been
deprecated for OSPFv3. The bit should be set to 0 and ignored
when received. It may be reassigned in the future.
P-bit
The "propagate" bit. Set on NSSA area prefixes that should be
readvertised by the translating NSSA area border [NSSA].
DN-bit
This bit controls an inter-area-prefix-LSAs or AS-external-LSAs
re-advertisement in a VPN environment as specified in [DN-BIT].
A.4.2. The LSA Header
All LSAs begin with a common 20-byte header. This header contains
enough information to uniquely identify the LSA (LS type, Link State
ID, and Advertising Router). Multiple instances of the LSA may exist
in the routing domain at the same time. It is then necessary to
determine which instance is more recent. This is accomplished by
examining the LS age, LS sequence number, and LS checksum fields that
are also contained in the LSA header.
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 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSA Header
LS Age
The time in seconds since the LSA was originated.
LS Type
The LS type field indicates the function performed by the LSA.
The high-order three bits of LS type encode generic properties of
the LSA, while the remainder (called LSA function code) indicate
the LSA's specific functionality. See Appendix A.4.2.1 for a
detailed description of LS type.
Link State ID
The originating router's identifier for the LSA. The combination
of the Link State ID, LS type, and Advertising Router uniquely
identify the LSA in the link-state database.
Advertising Router
The Router ID of the router that originated the LSA. For example,
in network-LSAs this field is equal to the Router ID of the
network's Designated Router.
LS sequence number
Successive instances of an LSA are given successive LS sequence
numbers. The sequence number can be used to detect old or
duplicate LSA instances. See Section 12.1.6 in [OSPFV2] for more
details.
LS checksum
The Fletcher checksum of the complete contents of the LSA,
including the LSA header but excluding the LS age field. See
Section 12.1.7 in [OSPFV2] for more details.
length
The length in bytes of the LSA. This includes the 20-byte LSA
header.
A.4.2.1. LSA Type
The LS type field indicates the function performed by the LSA. The
high-order three bits of LS type encode generic properties of the
LSA, while the remainder (called LSA function code) indicate the
LSA's specific functionality. The format of the LS type is as
follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LSA Type
The U-bit indicates how the LSA should be handled by a router that
does not recognize the LSA's function code. Its values are:
U-bit LSA Handling
-------------------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA as if the type is understood
U-Bit
The S1 and S2 bits indicate the flooding scope of the LSA. The
values are:
S2 S1 Flooding Scope
-------------------------------------------------------------
0 0 Link-Local Scoping - Flooded only on originating link
0 1 Area Scoping - Flooded only in originating area
1 0 AS Scoping - Flooded throughout AS
1 1 Reserved
Flooding Scope
The LSA function codes are defined as follows. The origination and
processing of these LSA function codes are defined elsewhere in this
document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which was
previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated
for OSPFv3. As shown below, each LSA function b code also implies a
specific setting for the U, S1, and S2 bits.
LSA Function Code LS Type Description
----------------------------------------------------
1 0x2001 Router-LSA
2 0x2002 Network-LSA
3 0x2003 Inter-Area-Prefix-LSA
4 0x2004 Inter-Area-Router-LSA
5 0x4005 AS-External-LSA
6 0x2006 Deprecated (may be reassigned)
7 0x2007 NSSA-LSA
8 0x0008 Link-LSA
9 0x2009 Intra-Area-Prefix-LSA
LSA Function Code
A.4.3. Router-LSAs
Router-LSAs have LS type equal to 0x2001. Each router in an area
originates one or more router-LSAs. The complete collection of
router-LSAs originated by the router describe the state and cost of
the router's interfaces to the area. For details concerning the
construction of router-LSAs, see Section 4.4.3.2. Router-LSAs are
only flooded throughout a single area.
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 |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Router-LSA Format
A single router may originate one or more router-LSAs, distinguished
by their Link State IDs (which are chosen arbitrarily by the
originating router). The Options field and V, E, and B bits should
be the same in all router-LSAs from a single originator. However, in
the case of a mismatch, the values in the LSA with the lowest Link
State ID take precedence. When more than one router-LSA is received
from a single router, the links are processed as if concatenated into
a single LSA.
Bit V
When set, the router is an endpoint of one or more fully adjacent
virtual links having the described area as transit area (V is for
virtual link endpoint).
Bit E
When set, the router is an AS boundary router (E is for external).
Bit B
When set, the router is an area border router (B is for border).
Bit x
This bit was previously used by MOSPF (see [MOSPF]) and has been
deprecated for OSPFv3. The bit should be set to 0 and ignored
when received. It may be reassigned in the future.
Bit Nt
When set, the router is an NSSA border router that is
unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt
stands for NSSA translation). Note that such routers have their
NSSATranslatorRole area configuration parameter set to Always.
(See [NSSA].)
Options
The optional capabilities supported by the router, as documented
in Appendix A.2.
The following fields are used to describe each router interface. The
Type field indicates the kind of interface being described. It may
be an interface to a transit network, a point-to-point connection to
another router, or a virtual link. The values of all the other
fields describing a router interface depend on the interface's Type
field.
Type
The kind of interface being described. One of the following:
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
Router Link Types
Metric
The cost of using this router interface for outbound traffic.
Interface ID
The Interface ID assigned to the interface being described. See
Section 4.1.2 and Appendix C.3.
Neighbor Interface ID
The Interface ID the neighbor router has associated with the link,
as advertised in the neighbor's Hello packets. For transit (type
2) links, the link's Designated Router is the neighbor described.
For other link types, the sole adjacent neighbor is described.
Neighbor Router ID
The Router ID the of the neighbor router. For transit (type 2)
links, the link's Designated Router is the neighbor described.
For other link types, the sole adjacent neighbor is described.
For transit (Type 2) links, the combination of Neighbor Interface ID
and Neighbor Router ID allows the network-LSA for the attached link
to be found in the link-state database.
A.4.4. Network-LSAs
Network-LSAs have LS type equal to 0x2002. A network-LSA is
originated for each broadcast and NBMA link in the area that includes
two or more adjacent routers. The network-LSA is originated by the
link's Designated Router. The LSA describes all routers attached to
the link including the Designated Router itself. The LSA's Link
State ID field is set to the Interface ID that the Designated Router
has been advertising in Hello packets on the link.
The distance from the network to all attached routers is zero. This
is why the Metric fields need not be specified in the network-LSA.
For details concerning the construction of network-LSAs, see
Section 4.4.3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network-LSA Format
Attached Router
The Router IDs of each of the routers attached to the link.
Actually, only those routers that are fully adjacent to the
Designated Router are listed. The Designated Router includes
itself in this list. The number of routers included can be
deduced from the LSA header's length field.
A.4.5. Inter-Area-Prefix-LSAs
Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are
the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see
Section 12.4.3 of [OSPFV2]). Originated by area border routers, they
describe routes to IPv6 address prefixes that belong to other areas.
A separate inter-area-prefix-LSA is originated for each IPv6 address
prefix. For details concerning the construction of inter-area-
prefix-LSAs, see Section 4.4.3.4.
For stub areas, inter-area-prefix-LSAs can also be used to describe a
(per-area) default route. Default summary routes are used in stub
areas instead of flooding a complete set of external routes. When
describing a default summary route, the inter-area-prefix-LSA's
PrefixLength is set to 0.
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 |0|0|1| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Prefix-LSA Format
Metric
The cost of this route. Expressed in the same units as the
interface costs in router-LSAs. When the inter-area-prefix-LSA is
describing a route to a range of addresses (see Appendix C.2), the
cost is set to the maximum cost to any reachable component of the
address range.
PrefixLength, PrefixOptions, and Address Prefix
Representation of the IPv6 address prefix, as described in
Appendix A.4.1.
A.4.6. Inter-Area-Router-LSAs
Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are
the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see
Section 12.4.3 of [OSPFV2]). Originated by area border routers, they
describe routes to AS boundary routers in other areas. To see why it
is necessary to advertise the location of each ASBR, consult Section
16.4 in [OSPFV2]. Each LSA describes a route to a single router.
For details concerning the construction of inter-area-router-LSAs,
see Section 4.4.3.5.
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 |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Router-LSA Format
Options
The optional capabilities supported by the router, as documented
in Appendix A.2.
Metric
The cost of this route. Expressed in the same units as the
interface costs in router-LSAs.
Destination Router ID
The Router ID of the router being described by the LSA.
A.4.7. AS-External-LSAs
AS-external-LSAs have LS type equal to 0x4005. These LSAs are
originated by AS boundary routers and describe destinations external
to the AS. Each LSA describes a route to a single IPv6 address
prefix. For details concerning the construction of AS-external-LSAs,
see Section 4.4.3.6.
AS-external-LSAs can be used to describe a default route. Default
routes are used when no specific route exists to the destination.
When describing a default route, the AS-external-LSA's PrefixLength
is set to 0.
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 |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-external-LSA Format
bit E
The type of external metric. If bit E is set, the metric
specified is a Type 2 external metric. This means the metric is
considered larger than any intra-AS path. If bit E is zero, the
specified metric is a Type 1 external metric. This means that it
is expressed in the same units as other LSAs (i.e., the same units
as the interface costs in router-LSAs).
bit F
If set, a Forwarding Address has been included in the LSA.
bit T
If set, an External Route Tag has been included in the LSA.
Metric
The cost of this route. Interpretation depends on the external
type indication (bit E above).
PrefixLength, PrefixOptions, and Address Prefix
Representation of the IPv6 address prefix, as described in
Appendix A.4.1.
Referenced LS Type
If non-zero, an LSA with this LS type is to be associated with
this LSA (see Referenced Link State ID below).
Forwarding address
A fully qualified IPv6 address (128 bits). Included in the LSA if
and only if bit F has been set. If included, data traffic for the
advertised destination will be forwarded to this address. It MUST
NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an
IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are
normally installed with link-local addresses, an OSPFv3
implementation advertising a forwarding address MUST advertise a
global IPv6 address. This global IPv6 address may be the next-hop
gateway for an external prefix or may be obtained through some
other method (e.g., configuration).
External Route Tag
A 32-bit field that MAY be used to communicate additional
information between AS boundary routers. Included in the LSA if
and only if bit T has been set.
Referenced Link State ID
Included if and only if Reference LS Type is non-zero. If
included, additional information concerning the advertised
external route can be found in the LSA having LS type equal to
"Referenced LS Type", Link State ID equal to "Referenced Link
State ID", and Advertising Router the same as that specified in
the AS-external-LSA's link-state header. This additional
information is not used by the OSPF protocol itself. It may be
used to communicate information between AS boundary routers. The
precise nature of such information is outside the scope of this
specification.
All, none, or some of the fields labeled Forwarding address, External
Route Tag, and Referenced Link State ID MAY be present in the AS-
external-LSA (as indicated by the setting of bit F, bit T, and
Referenced LS Type respectively). When present, Forwarding Address
always comes first, External Route Tag next, and the Referenced Link
State ID last.
A.4.8. NSSA-LSAs
NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by AS boundary routers within an NSSA and describe destinations external to the AS that may or may not be propagated outside the NSSA (refer to [NSSA]). Other than the LS type, their format is exactly the same as AS-external LSAs as described in Appendix A.4.7. A global IPv6 address MUST be selected as forwarding address for NSSA-LSAs that are to be propagated by NSSA area border routers. The selection should proceed the same as OSPFv2 NSSA support [NSSA] with additional checking to ensure IPv6 link-local address are not selected.A.4.9. Link-LSAs
Link-LSAs have LS type equal to 0x0008. A router originates a separate link-LSA for each attached physical link. These LSAs have link-local flooding scope; they are never flooded beyond the associated link. Link-LSAs have three purposes: 1. They provide the router's link-local address to all other routers attached to the link. 2. They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link. 3. They allow the router to advertise a collection of Options bits in the network-LSA originated by the Designated Router on a broadcast or NBMA link. For details concerning the construction of links-LSAs, see Section 4.4.3.8. A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link.
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 |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link-LSA Format
Rtr Priority
The Router Priority of the interface attaching the originating
router to the link.
Options
The set of Options bits that the router would like set in the
network-LSA that will be originated by the Designated Router on
broadcast or NBMA links.
Link-local Interface Address
The originating router's link-local interface address on the link.
# prefixes
The number of IPv6 address prefixes contained in the LSA.
The rest of the link-LSA contains a list of IPv6 prefixes to be
associated with the link.
PrefixLength, PrefixOptions, and Address Prefix
Representation of an IPv6 address prefix, as described in
Appendix A.4.1.
A.4.10. Intra-Area-Prefix-LSAs
Intra-area-prefix-LSAs have LS type equal to 0x2009. A router uses
intra-area-prefix-LSAs to advertise one or more IPv6 address prefixes
that are associated with a local router address, an attached stub
network segment, or an attached transit network segment. In IPv4,
the first two were accomplished via the router's router-LSA and the
last via a network-LSA. In OSPF for IPv6, all addressing information
that was advertised in router-LSAs and network-LSAs has been removed
and is now advertised in intra-area-prefix-LSAs. For details
concerning the construction of intra-area-prefix-LSA, see
Section 4.4.3.9.
A router can originate multiple intra-area-prefix-LSAs for each
router or transit network. Each such LSA is distinguished by its
unique Link State ID.
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 |0|0|1| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Prefixes | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Intra-Area-Prefix LSA Format
# prefixes
The number of IPv6 address prefixes contained in the LSA.
Referenced LS Type, Referenced Link State ID, and Referenced
Advertising Router
Identifies the router-LSA or network-LSA with which the IPv6
address prefixes should be associated. If Referenced LS Type is
0x2001, the prefixes are associated with a router-LSA, Referenced
Link State ID should be 0, and Referenced Advertising Router
should be the originating router's Router ID. If Referenced LS
Type is 0x2002, the prefixes are associated with a network-LSA,
Referenced Link State ID should be the Interface ID of the link's
Designated Router, and Referenced Advertising Router should be the
Designated Router's Router ID.
The rest of the intra-area-prefix-LSA contains a list of IPv6
prefixes to be associated with the router or transit link, as well as
their associated costs.
PrefixLength, PrefixOptions, and Address Prefix
Representation of an IPv6 address prefix, as described in
Appendix A.4.1.
Metric
The cost of this prefix. Expressed in the same units as the
interface costs in router-LSAs.
Appendix B. Architectural Constants
Architectural constants for the OSPF protocol are defined in Appendix
B of [OSPFV2]. The only difference for OSPF for IPv6 is that
DefaultDestination is encoded as a prefix with length 0 (see
Appendix A.4.1).
Appendix C. Configurable Constants
The OSPF protocol has quite a few configurable parameters. These
parameters are listed below. They are grouped into general
functional categories (area parameters, interface parameters, etc.).
Sample values are given for some of the parameters.
Some parameter settings need to be consistent among groups of
routers. For example, all routers in an area must agree on that
area's parameters. Similarly, all routers attached to a network must
agree on that network's HelloInterval and RouterDeadInterval.
Some parameters may be determined by router algorithms outside of
this specification (e.g., the address of a host connected to the
router via a SLIP line). From OSPF's point of view, these items are
still configurable.
C.1. Global Parameters
In general, a separate copy of the OSPF protocol is run for each
area. Because of this, most configuration parameters are defined on
a per-area basis. The few global configuration parameters are listed
below.
Router ID
This is a 32-bit number that uniquely identifies the router in the
Autonomous System. If a router's OSPF Router ID is changed, the
router's OSPF software should be restarted before the new Router
ID takes effect. Before restarting due to a Router ID change, the
router should flush its self-originated LSAs from the routing
domain (see Section 14.1 of [OSPFV2]). Otherwise, they will
persist for up to MaxAge seconds.
Because the size of the Router ID is smaller than an IPv6 address, it
cannot be set to one of the router's IPv6 addresses (as is commonly
done for IPv4). Possible Router ID assignment procedures for IPv6
include: a) assign the IPv6 Router ID as one of the router's IPv4
addresses or b) assign IPv6 Router IDs through some local
administrative procedure (similar to procedures used by manufacturers
to assign product serial numbers).
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
C.2. Area Parameters
All routers belonging to an area must agree on that area's
configuration. Disagreements between two routers will lead to an
inability for adjacencies to form between them, with a resulting
hindrance to the flow of both routing protocol information and data
traffic. The following items must be configured for an area:
Area ID
This is a 32-bit number that identifies the area. The Area ID of
0 is reserved for the backbone.
List of address ranges
Address ranges control the advertisement of routes across area
boundaries. Each address range consists of the following items:
[IPv6 prefix, prefix length]
Describes the collection of IPv6 addresses contained in the
address range.
Status
Set to either Advertise or DoNotAdvertise. Routing information
is condensed at area boundaries. External to the area, at most
a single route is advertised (via a inter-area-prefix-LSA) for
each address range. The route is advertised if and only if the
address range's Status is set to Advertise. Unadvertised
ranges allow the existence of certain networks to be
intentionally hidden from other areas. Status is set to
Advertise by default.
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the area.
If AS-external-LSAs are excluded from the area, the area is called
a stub area or NSSA. Internal to stub areas, routing to external
destinations will be based solely on a default inter-area route.
The backbone cannot be configured as a stub or NSSA area. Also,
virtual links cannot be configured through stub or NSSA areas.
For more information, see Section 3.6 of [OSPFV2] and [NSSA].
StubDefaultCost
If the area has been configured as a stub area, and the router
itself is an area border router, then the StubDefaultCost
indicates the cost of the default inter-area-prefix-LSA that the
router should advertise into the area. See Section 12.4.3.1 of
[OSPFV2] for more information.
NSSATranslatorRole and TranslatorStabilityInterval
These area parameters are described in Appendix D of [NSSA].
Additionally, an NSSA Area Border Router (ABR) is also required to
allow configuration of whether or not an NSSA default route is
advertised in an NSSA-LSA. If advertised, its metric and metric
type are configurable. These requirements are also described in
Appendix D of [NSSA].
ImportSummaries
When set to enabled, prefixes external to the area are imported
into the area via the advertisement of inter-area-prefix-LSAs.
When set to disabled, inter-area routes are not imported into the
area. The default setting is enabled. This parameter is only
valid for stub or NSSA areas.
C.3. Router Interface Parameters
Some of the configurable router interface parameters (such as Area
ID, HelloInterval, and RouterDeadInterval) actually imply properties
of the attached links. Therefore, these parameters must be
consistent across all the routers attached to that link. The
parameters that must be configured for a router interface are:
IPv6 link-local address
The IPv6 link-local address associated with this interface. May
be learned through auto-configuration.
Area ID
The OSPF area to which the attached link belongs.
Instance ID
The OSPF protocol instance associated with this OSPF interface.
Defaults to 0.
Interface ID
32-bit number uniquely identifying this interface among the
collection of this router's interfaces. For example, in some
implementations it may be possible to use the MIB-II IfIndex
([INTFMIB]).
IPv6 prefixes
The list of IPv6 prefixes to associate with the link. These will
be advertised in intra-area-prefix-LSAs.
Interface output cost(s)
The cost of sending a packet on the interface, expressed in the
link-state metric. This is advertised as the link cost for this
interface in the router's router-LSA. The interface output cost
MUST always be greater than 0.
RxmtInterval
The number of seconds between LSA retransmissions for adjacencies
belonging to this interface. Also used when retransmitting
Database Description and Link State Request packets. This should
be well over the expected round-trip delay between any two routers
on the attached link. The setting of this value should be
conservative or needless retransmissions will result. Sample
value for a local area network: 5 seconds.
InfTransDelay
The estimated number of seconds it takes to transmit a Link State
Update packet over this interface. LSAs contained in the update
packet must have their age incremented by this amount before
transmission. This value should take into account the
transmission and propagation delays of the interface. It MUST be
greater than 0. Sample value for a local area network: 1 second.
Router Priority
An 8-bit unsigned integer. When two routers attached to a network
both attempt to become the Designated Router, the one with the
highest Router Priority takes precedence. If there is still a
tie, the router with the highest Router ID takes precedence. A
router whose Router Priority is set to 0 is ineligible to become
the Designated Router on the attached link. Router Priority is
only configured for interfaces to broadcast and NBMA networks.
HelloInterval
The length of time, in seconds, between Hello packets that the
router sends on the interface. This value is advertised in the
router's Hello packets. It MUST be the same for all routers
attached to a common link. The smaller the HelloInterval, the
faster topological changes will be detected. However, more OSPF
routing protocol traffic will ensue. Sample value for a X.25 PDN:
30 seconds. Sample value for a local area network (LAN): 10
seconds.
RouterDeadInterval
After ceasing to hear a router's Hello packets, the number of
seconds before its neighbors declare the router down. This is
also advertised in the router's Hello packets in their
RouterDeadInterval field. This should be some multiple of the
HelloInterval (e.g., 4). This value again MUST be the same for
all routers attached to a common link.
LinkLSASuppression
Indicates whether or not origination of a link-LSA is suppressed.
If set to "enabled" and the interface type is not broadcast or
NBMA, the router will not originate a link-LSA for the link. This
implies that other routers on the link will ascertain the router's
next-hop address using a mechanism other than the link-LSA (see
Section 4.8.2). The default value is "disabled" for interface
types described in this specification. It is implicitly
"disabled" if the interface type is broadcast or NBMA. Future
interface types MAY specify a different default.
C.4. Virtual Link Parameters
Virtual links are used to restore/increase connectivity of the
backbone. Virtual links may be configured between any pair of area
border routers having interfaces to a common (non-backbone) area.
The virtual link appears as a point-to-point link with no global IPv6
addresses in the graph for the backbone. The virtual link must be
configured in both of the area border routers.
A virtual link appears in router-LSAs (for the backbone) as if it
were a separate router interface to the backbone. As such, it has
most of the parameters associated with a router interface (see
Appendix C.3). Virtual links do not have link-local addresses, but
instead use one of the router's global-scope IPv6 addresses as the IP
source in OSPF protocol packets it sends on the virtual link. Router
Priority is not used on virtual links. Interface output cost is not
configured on virtual links, but is dynamically set to be the cost of
the transit area intra-area path between the two endpoint routers.
The parameter RxmtInterval may be configured and should be well over
the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too long. A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint and the (non-backbone) area that the virtual link traverses (referred to as the virtual link's transit area). Virtual links cannot be configured through stub or NSSA areas. Additionally, an Instance ID may be configured for virtual links from different protocol instances in order to utilize the same transit area (without requiring different Router IDs for demultiplexing).C.5. NBMA Network Parameters
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA listing all routers attached to the NBMA network. However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become the Designated Router (i.e., those routers whose Router Priority for the network is non- zero), and then only if no automatic procedure for discovering neighbors exists: List of all other attached routers The list of all other routers attached to the NBMA network. Each router is configured with its Router ID and IPv6 link-local address on the network. Also, for each router listed, that router's eligibility to become the Designated Router must be defined. When an interface to an NBMA network first comes up, the router only sends Hello packets to those neighbors eligible to become the Designated Router until such time that a Designated Router is elected. PollInterval If a neighboring router has become inactive (Hello packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello packets to the dead neighbor. These Hello packets will be sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes.
C.6. Point-to-Multipoint Network Parameters
On point-to-multipoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the point-to- multipoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers are not elected on point-to-multipoint networks, so the Designated Router eligibility of configured neighbors is not defined.C.7. Host Route Parameters
Host prefixes are advertised in intra-area-prefix-LSAs. They indicate either local router addresses, router interfaces to point- to-point networks, looped router interfaces, or IPv6 hosts that are directly connected to the router (e.g., via a PPP connection). For each host directly connected to the router, the following items must be configured: Host IPv6 prefix An IPv6 prefix belonging to the directly connected host. This must not be a valid IPv6 global prefix. Cost of link to host The cost of sending a packet to the host, in terms of the link- state metric. However, since the host probably has only a single connection to the Internet, the actual configured cost(s) in many cases is unimportant (i.e., will have no effect on routing). Area ID The OSPF area to which the host's prefix belongs.
Authors' Addresses
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA Dennis Ferguson Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA EMail: dennis@juniper.net John Moy Sycamore Networks, Inc 10 Elizabeth Drive Chelmsford, MA 01824 USA EMail: jmoy@sycamorenet.com Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA EMail: acee@redback.com
Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.