draft-ietf-ospf-version2-06.txt   draft-ietf-ospf-version2-07.txt 
Network Working Group J. Moy Network Working Group J. Moy
Internet Draft Cascade Internet Draft Cascade Communications Corp.
Expiration Date: May 1996 November 1995 Expiration Date: March 1997 September 1996
File name: draft-ietf-ospf-version2-06.txt File name: draft-ietf-ospf-version2-07.txt
OSPF Version 2 OSPF Version 2
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
OSPF recalculates routes quickly in the face of topological changes, OSPF recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic. OSPF provides utilizing a minimum of routing protocol traffic. OSPF provides
support for equal-cost multipath. Separate routes can be calculated support for equal-cost multipath. Separate routes can be calculated
for each IP Type of Service. An area routing capability is for each IP Type of Service. An area routing capability is
provided, enabling an additional level of routing protection and a provided, enabling an additional level of routing protection and a
reduction in routing protocol traffic. In addition, all OSPF reduction in routing protocol traffic. In addition, all OSPF
routing protocol exchanges are authenticated. routing protocol exchanges are authenticated.
The differences between this memo and RFC 1583 are explained in The differences between this memo and RFC 1583 are explained in
Appendix F. All differences are backward-compatible in nature. Appendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFC 1583 will interoperate. Implementations of this memo and of RFC 1583 will interoperate.
Please send comments to ospf@gated.cornell.edu. Please send comments to ospf@gated.cornell.edu.
Table of Contents Table of Contents
1 Introduction ........................................... 7 1 Introduction ........................................... 7
1.1 Protocol Overview ...................................... 7 1.1 Protocol Overview ...................................... 7
1.2 Definitions of commonly used terms ..................... 8 1.2 Definitions of commonly used terms ..................... 8
1.3 Brief history of link-state routing technology ........ 11 1.3 Brief history of link-state routing technology ........ 11
skipping to change at page 4, line 19 skipping to change at page 4, line 19
10.5 Receiving Hello Packets ............................... 87 10.5 Receiving Hello Packets ............................... 87
10.6 Receiving Database Description Packets ................ 89 10.6 Receiving Database Description Packets ................ 89
10.7 Receiving Link State Request Packets .................. 92 10.7 Receiving Link State Request Packets .................. 92
10.8 Sending Database Description Packets .................. 92 10.8 Sending Database Description Packets .................. 92
10.9 Sending Link State Request Packets .................... 94 10.9 Sending Link State Request Packets .................... 94
10.10 An Example ............................................ 94 10.10 An Example ............................................ 94
11 The Routing Table Structure ........................... 96 11 The Routing Table Structure ........................... 96
11.1 Routing table lookup .................................. 99 11.1 Routing table lookup .................................. 99
11.2 Sample routing table, without areas .................. 101 11.2 Sample routing table, without areas .................. 101
11.3 Sample routing table, with areas ..................... 101 11.3 Sample routing table, with areas ..................... 101
12 Link State Advertisements (LSAs) ..................... 104 12 Link State Advertisements (LSAs) ..................... 103
12.1 The LSA Header ....................................... 104 12.1 The LSA Header ....................................... 104
12.1.1 LS age ............................................... 105 12.1.1 LS age ............................................... 105
12.1.2 Options .............................................. 105 12.1.2 Options .............................................. 105
12.1.3 LS type .............................................. 106 12.1.3 LS type .............................................. 106
12.1.4 Link State ID ........................................ 106 12.1.4 Link State ID ........................................ 106
12.1.5 Advertising Router ................................... 108 12.1.5 Advertising Router ................................... 108
12.1.6 LS sequence number ................................... 108 12.1.6 LS sequence number ................................... 108
12.1.7 LS checksum .......................................... 109 12.1.7 LS checksum .......................................... 109
12.2 The link state database .............................. 110 12.2 The link state database .............................. 110
12.3 Representation of TOS ................................ 111 12.3 Representation of TOS ................................ 110
12.4 Originating LSAs ..................................... 112 12.4 Originating LSAs ..................................... 111
12.4.1 Router-LSAs .......................................... 115 12.4.1 Router-LSAs .......................................... 114
12.4.1.1 Describing point-to-point interfaces ................. 117 12.4.1.1 Describing point-to-point interfaces ................. 117
12.4.1.2 Describing broadcast and NBMA interfaces ............. 118 12.4.1.2 Describing broadcast and NBMA interfaces ............. 118
12.4.1.3 Describing virtual links ............................. 119 12.4.1.3 Describing virtual links ............................. 118
12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 119 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 119
12.4.1.5 Examples of router-LSAs .............................. 119 12.4.1.5 Examples of router-LSAs .............................. 119
12.4.2 Network-LSAs ......................................... 122 12.4.2 Network-LSAs ......................................... 121
12.4.2.1 Examples of network-LSAs ............................. 122 12.4.2.1 Examples of network-LSAs ............................. 122
12.4.3 Summary-LSAs ......................................... 123 12.4.3 Summary-LSAs ......................................... 123
12.4.3.1 Originating summary-LSAs into stub areas ............. 125 12.4.3.1 Originating summary-LSAs into stub areas ............. 125
12.4.3.2 Examples of summary-LSAs ............................. 126 12.4.3.2 Examples of summary-LSAs ............................. 126
12.4.4 AS-external-LSAs ..................................... 127 12.4.4 AS-external-LSAs ..................................... 127
12.4.4.1 Examples of AS-external-LSAs ......................... 128 12.4.4.1 Examples of AS-external-LSAs ......................... 128
13 The Flooding Procedure ............................... 130 13 The Flooding Procedure ............................... 129
13.1 Determining which LSA is newer ....................... 133 13.1 Determining which LSA is newer ....................... 133
13.2 Installing LSAs in the database ...................... 134 13.2 Installing LSAs in the database ...................... 133
13.3 Next step in the flooding procedure .................. 135 13.3 Next step in the flooding procedure .................. 135
13.4 Receiving self-originated LSAs ....................... 137 13.4 Receiving self-originated LSAs ....................... 137
13.5 Sending Link State Acknowledgment packets ............ 138 13.5 Sending Link State Acknowledgment packets ............ 138
13.6 Retransmitting LSAs .................................. 139 13.6 Retransmitting LSAs .................................. 139
13.7 Receiving link state acknowledgments ................. 141 13.7 Receiving link state acknowledgments ................. 141
14 Aging The Link State Database ........................ 142 14 Aging The Link State Database ........................ 141
14.1 Premature aging of LSAs .............................. 142 14.1 Premature aging of LSAs .............................. 142
15 Virtual Links ........................................ 143 15 Virtual Links ........................................ 143
16 Calculation of the routing table ..................... 145 16 Calculation of the routing table ..................... 145
16.1 Calculating the shortest-path tree for an area ....... 146 16.1 Calculating the shortest-path tree for an area ....... 146
16.1.1 The next hop calculation ............................. 152 16.1.1 The next hop calculation ............................. 151
16.2 Calculating the inter-area routes .................... 153 16.2 Calculating the inter-area routes .................... 153
16.3 Examining transit areas' summary-LSAs ................ 154 16.3 Examining transit areas' summary-LSAs ................ 154
16.4 Calculating AS external routes ....................... 157 16.4 Calculating AS external routes ....................... 156
16.5 Incremental updates -- summary-LSAs .................. 158 16.4.1 External path preferences ............................ 158
16.6 Incremental updates -- AS-external-LSAs .............. 159 16.5 Incremental updates -- summary-LSAs .................. 159
16.6 Incremental updates -- AS-external-LSAs .............. 160
16.7 Events generated as a result of routing table changes 160 16.7 Events generated as a result of routing table changes 160
16.8 Equal-cost multipath ................................. 160 16.8 Equal-cost multipath ................................. 161
16.9 Building the non-zero-TOS portion of the routing table 161 16.9 Building the non-zero-TOS portion of the routing table 162
Footnotes ............................................ 163 Footnotes ............................................ 164
References ........................................... 167 References ........................................... 168
A OSPF data formats .................................... 169 A OSPF data formats .................................... 170
A.1 Encapsulation of OSPF packets ........................ 169 A.1 Encapsulation of OSPF packets ........................ 170
A.2 The Options field .................................... 171 A.2 The Options field .................................... 172
A.3 OSPF Packet Formats .................................. 173 A.3 OSPF Packet Formats .................................. 174
A.3.1 The OSPF packet header ............................... 174 A.3.1 The OSPF packet header ............................... 175
A.3.2 The Hello packet ..................................... 176 A.3.2 The Hello packet ..................................... 177
A.3.3 The Database Description packet ...................... 178 A.3.3 The Database Description packet ...................... 179
A.3.4 The Link State Request packet ........................ 180 A.3.4 The Link State Request packet ........................ 181
A.3.5 The Link State Update packet ......................... 182 A.3.5 The Link State Update packet ......................... 183
A.3.6 The Link State Acknowledgment packet ................. 184 A.3.6 The Link State Acknowledgment packet ................. 185
A.4 LSA formats .......................................... 186 A.4 LSA formats .......................................... 187
A.4.1 The LSA header ....................................... 187 A.4.1 The LSA header ....................................... 188
A.4.2 Router-LSAs .......................................... 189 A.4.2 Router-LSAs .......................................... 190
A.4.3 Network-LSAs ......................................... 193 A.4.3 Network-LSAs ......................................... 194
A.4.4 Summary-LSAs ......................................... 194 A.4.4 Summary-LSAs ......................................... 195
A.4.5 AS-external-LSAs ..................................... 296 A.4.5 AS-external-LSAs ..................................... 197
B Architectural Constants .............................. 198 B Architectural Constants .............................. 199
C Configurable Constants ............................... 200 C Configurable Constants ............................... 201
C.1 Global parameters .................................... 200 C.1 Global parameters .................................... 201
C.2 Area parameters ...................................... 200 C.2 Area parameters ...................................... 202
C.3 Router interface parameters .......................... 202 C.3 Router interface parameters .......................... 203
C.4 Virtual link parameters .............................. 204 C.4 Virtual link parameters .............................. 205
C.5 NBMA network parameters .............................. 204 C.5 NBMA network parameters .............................. 206
C.6 Point-to-MultiPoint network parameters ............... 205 C.6 Point-to-MultiPoint network parameters ............... 207
C.7 Host route parameters ................................ 205 C.7 Host route parameters ................................ 207
D Authentication ....................................... 207 D Authentication ....................................... 208
D.1 Null authentication .................................. 207 D.1 Null authentication .................................. 208
D.2 Simple password authentication ....................... 207 D.2 Simple password authentication ....................... 208
D.3 Cryptographic authentication ......................... 208 D.3 Cryptographic authentication ......................... 209
D.4 Message generation ................................... 210 D.4 Message generation ................................... 211
D.4.1 Generating Null authentication ....................... 210 D.4.1 Generating Null authentication ....................... 212
D.4.2 Generating Simple password authentication ............ 211 D.4.2 Generating Simple password authentication ............ 212
D.4.3 Generating Cryptographic authentication .............. 211 D.4.3 Generating Cryptographic authentication .............. 212
D.5 Message verification ................................. 212 D.5 Message verification ................................. 214
D.5.1 Verifying Null authentication ........................ 213 D.5.1 Verifying Null authentication ........................ 214
D.5.2 Verifying Simple password authentication ............. 213 D.5.2 Verifying Simple password authentication ............. 214
D.5.3 Verifying Cryptographic authentication ............... 213 D.5.3 Verifying Cryptographic authentication ............... 214
E An algorithm for assigning Link State IDs ............ 215 E An algorithm for assigning Link State IDs ............ 216
F Differences from RFC 1583 ............................ 217 F Multiple interfaces to the same network/subnet ....... 218
F.1 Enhancements to OSPF authentication .................. 217 G Differences from RFC 1583 ............................ 219
F.2 Addition of Point-to-MultiPoint interface ............ 217 G.1 Enhancements to OSPF authentication .................. 219
F.3 Support for overlapping area ranges .................. 218 G.2 Addition of Point-to-MultiPoint interface ............ 219
F.4 A modification to the flooding algorithm ............. 219 G.3 Support for overlapping area ranges .................. 220
F.5 Introduction of the MinLSArrival constant ............ 219 G.4 A modification to the flooding algorithm ............. 221
F.6 Optionally advertising point-to-point links as subnets 220 G.5 Introduction of the MinLSArrival constant ............ 221
Security Considerations .............................. 221 G.6 Optionally advertising point-to-point links as subnets 222
Author's Address ..................................... 221 G.7 Advertising same external route from multiple areas .. 222
Security Considerations .............................. 225
Author's Address ..................................... 225
1. Introduction 1. Introduction
This document is a specification of the Open Shortest Path First This document is a specification of the Open Shortest Path First
(OSPF) TCP/IP internet routing protocol. OSPF is classified as an (OSPF) TCP/IP internet routing protocol. OSPF is classified as an
Interior Gateway Protocol (IGP). This means that it distributes Interior Gateway Protocol (IGP). This means that it distributes
routing information between routers belonging to a single Autonomous routing information between routers belonging to a single Autonomous
System. The OSPF protocol is based on link-state or SPF technology. System. The OSPF protocol is based on link-state or SPF technology.
This is a departure from the Bellman-Ford base used by traditional This is a departure from the Bellman-Ford base used by traditional
TCP/IP internet routing protocols. TCP/IP internet routing protocols.
skipping to change at page 28, line 18 skipping to change at page 28, line 18
A router that has an interface to the backbone area. This A router that has an interface to the backbone area. This
includes all routers that interface to more than one area includes all routers that interface to more than one area
(i.e., area border routers). However, backbone routers do (i.e., area border routers). However, backbone routers do
not have to be area border routers. Routers with all not have to be area border routers. Routers with all
interfaces connecting to the backbone area are supported. interfaces connecting to the backbone area are supported.
AS boundary routers AS boundary routers
A router that exchanges routing information with routers A router that exchanges routing information with routers
belonging to other Autonomous Systems. Such a router belonging to other Autonomous Systems. Such a router
advertises AS external routing information throughout the advertises AS external routing information throughout the
Autonomous System. The path to each AS boundary router is Autonomous System. The paths to each AS boundary router are
known by every router in the AS. This classification is known by every router in the AS. This classification is
completely independent of the previous classifications: AS completely independent of the previous classifications: AS
boundary routers may be internal or area border routers, and boundary routers may be internal or area border routers, and
may or may not participate in the backbone. may or may not participate in the backbone.
3.4. A sample area configuration 3.4. A sample area configuration
Figure 6 shows a sample area configuration. The first area Figure 6 shows a sample area configuration. The first area
consists of networks N1-N4, along with their attached routers consists of networks N1-N4, along with their attached routers
RT1-RT4. The second area consists of networks N6-N8, along with RT1-RT4. The second area consists of networks N6-N8, along with
skipping to change at page 30, line 37 skipping to change at page 30, line 37
the graph in Figure 8 as stubs. the graph in Figure 8 as stubs.
The backbone enables the exchange of summary information between The backbone enables the exchange of summary information between
area border routers. Every area border router hears the area area border routers. Every area border router hears the area
summaries from all other area border routers. It then forms a summaries from all other area border routers. It then forms a
picture of the distance to all networks outside of its area by picture of the distance to all networks outside of its area by
examining the collected LSAs, and adding in the backbone examining the collected LSAs, and adding in the backbone
distance to each advertising router. distance to each advertising router.
Again using Routers RT3 and RT4 as an example, the procedure Again using Routers RT3 and RT4 as an example, the procedure
goes as follows: They first calculate the SPF tree for the
Network RT3 adv. RT4 adv. Network RT3 adv. RT4 adv.
_____________________________ _____________________________
N1 4 4 N1 4 4
N2 4 4 N2 4 4
N3 1 1 N3 1 1
N4 2 3 N4 2 3
Table 4: Networks advertised to the backbone Table 4: Networks advertised to the backbone
by Routers RT3 and RT4. by Routers RT3 and RT4.
skipping to change at page 31, line 20 skipping to change at page 31, line 20
RT1| | | | | | |0 | RT1| | | | | | |0 |
RT2| | | | | | |0 | RT2| | | | | | |0 |
RT3| | | | | | |0 | RT3| | | | | | |0 |
* RT4| | | | | | |0 | * RT4| | | | | | |0 |
* RT5| | |14|8 | | | | * RT5| | |14|8 | | | |
T RT7| | |20|14| | | | T RT7| | |20|14| | | |
O N1|3 | | | | | | | O N1|3 | | | | | | |
* N2| |3 | | | | | | * N2| |3 | | | | | |
* N3|1 |1 |1 |1 | | | | * N3|1 |1 |1 |1 | | | |
N4| | |2 | | | | | N4| | |2 | | | | |
Ia,Ib| | |15|22| | | | Ia,Ib| | |20|27| | | |
N6| | |16|15| | | | N6| | |16|15| | | |
N7| | |20|19| | | | N7| | |20|19| | | |
N8| | |18|18| | | | N8| | |18|18| | | |
N9-N11,H1| | |19|16| | | | N9-N11,H1| | |29|36| | | |
N12| | | | |8 |2 | | N12| | | | |8 |2 | |
N13| | | | |8 | | | N13| | | | |8 | | |
N14| | | | |8 | | | N14| | | | |8 | | |
N15| | | | | |9 | | N15| | | | | |9 | |
Figure 7: Area 1's Database. Figure 7: Area 1's Database.
Networks and routers are represented by vertices. Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked the intersection of Column A and Row B is marked
skipping to change at page 32, line 26 skipping to change at page 32, line 26
* RT11| | | | | |3 | | * RT11| | | | | |3 | |
T N1|4 |4 | | | | | | T N1|4 |4 | | | | | |
O N2|4 |4 | | | | | | O N2|4 |4 | | | | | |
* N3|1 |1 | | | | | | * N3|1 |1 | | | | | |
* N4|2 |3 | | | | | | * N4|2 |3 | | | | | |
Ia| | | | | |5 | | Ia| | | | | |5 | |
Ib| | | |7 | | | | Ib| | | |7 | | | |
N6| | | | |1 |1 |3 | N6| | | | |1 |1 |3 |
N7| | | | |5 |5 |7 | N7| | | | |5 |5 |7 |
N8| | | | |4 |3 |2 | N8| | | | |4 |3 |2 |
N9-N11,H1| | | | | | |1 | N9-N11,H1| | | | | | |11|
N12| | |8 | |2 | | | N12| | |8 | |2 | | |
N13| | |8 | | | | | N13| | |8 | | | | |
N14| | |8 | | | | | N14| | |8 | | | | |
N15| | | | |9 | | | N15| | | | |9 | | |
Figure 8: The backbone's database. Figure 8: The backbone's database.
Networks and routers are represented by vertices. Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked the intersection of Column A and Row B is marked
with an X. with an X.
goes as follows: They first calculate the SPF tree for the
backbone. This gives the distances to all other area border backbone. This gives the distances to all other area border
routers. Also noted are the distances to networks (Ia and Ib) routers. Also noted are the distances to networks (Ia and Ib)
and AS boundary routers (RT5 and RT7) that belong to the and AS boundary routers (RT5 and RT7) that belong to the
backbone. This calculation is shown in Table 5. backbone. This calculation is shown in Table 5.
Next, by looking at the area summaries from these area border Next, by looking at the area summaries from these area border
routers, RT3 and RT4 can determine the distance to all networks routers, RT3 and RT4 can determine the distance to all networks
outside their area. These distances are then advertised outside their area. These distances are then advertised
internally to the area by RT3 and RT4. The advertisements that internally to the area by RT3 and RT4. The advertisements that
Router RT3 and RT4 will make into Area 1 are shown in Table 6. Router RT3 and RT4 will make into Area 1 are shown in Table 6.
Note that Table 6 assumes that an area range has been configured Note that Table 6 assumes that an area range has been configured
Area border dist from dist from for the backbone which groups Ia and Ib into a single LSA.
router RT3 RT4
______________________________________ dist from dist from
RT3 RT4
__________________________________
to RT3 * 21 to RT3 * 21
to RT4 22 * to RT4 22 *
to RT7 20 14 to RT7 20 14
to RT10 15 22 to RT10 15 22
to RT11 18 25 to RT11 18 25
______________________________________ __________________________________
to Ia 20 27 to Ia 20 27
to Ib 15 22 to Ib 15 22
______________________________________ __________________________________
to RT5 14 8 to RT5 14 8
to RT7 20 14 to RT7 20 14
Table 5: Backbone distances calculated Table 5: Backbone distances calculated
by Routers RT3 and RT4. by Routers RT3 and RT4.
for the backbone which groups Ia and Ib into a single LSA.
The information imported into Area 1 by Routers RT3 and RT4 The information imported into Area 1 by Routers RT3 and RT4
enables an internal router, such as RT1, to choose an area enables an internal router, such as RT1, to choose an area
border router intelligently. Router RT1 would use RT4 for border router intelligently. Router RT1 would use RT4 for
traffic to Network N6, RT3 for traffic to Network N10, and would traffic to Network N6, RT3 for traffic to Network N10, and would
load share between the two for traffic to Network N8. load share between the two for traffic to Network N8.
Router RT1 can also determine in this manner the shortest path
to the AS boundary routers RT5 and RT7. Then, by looking at RT5
and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or
RT7 when sending to a destination in another Autonomous System
(one of the networks N12-N15).
Destination RT3 adv. RT4 adv. Destination RT3 adv. RT4 adv.
_________________________________ _________________________________
Ia,Ib 15 22 Ia,Ib 20 27
N6 16 15 N6 16 15
N7 20 19 N7 20 19
N8 18 18 N8 18 18
N9-N11,H1 19 26 N9-N11,H1 29 36
_________________________________ _________________________________
RT5 14 8 RT5 14 8
RT7 20 14 RT7 20 14
Table 6: Destinations advertised into Area 1 Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4. by Routers RT3 and RT4.
Router RT1 can also determine in this manner the shortest path
to the AS boundary routers RT5 and RT7. Then, by looking at RT5
and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or
RT7 when sending to a destination in another Autonomous System
(one of the networks N12-N15).
Note that a failure of the line between Routers RT6 and RT10 Note that a failure of the line between Routers RT6 and RT10
will cause the backbone to become disconnected. Configuring a will cause the backbone to become disconnected. Configuring a
virtual link between Routers RT7 and RT10 will give the backbone virtual link between Routers RT7 and RT10 will give the backbone
more connectivity and more resistance to such failures. more connectivity and more resistance to such failures.
3.5. IP subnetting support 3.5. IP subnetting support
OSPF attaches an IP address mask to each advertised route. The OSPF attaches an IP address mask to each advertised route. The
mask indicates the range of addresses being described by the mask indicates the range of addresses being described by the
particular route. For example, a summary-LSA for the particular route. For example, a summary-LSA for the
skipping to change at page 35, line 30 skipping to change at page 35, line 24
now becoming commonplace with the advent of CIDR (see [Ref10]). now becoming commonplace with the advent of CIDR (see [Ref10]).
In order to get better aggregation at area boundaries, area In order to get better aggregation at area boundaries, area
address ranges can be employed (see Section C.2 for more address ranges can be employed (see Section C.2 for more
details). Each address range is defined as an [address,mask] details). Each address range is defined as an [address,mask]
pair. Many separate networks may then be contained in a single pair. Many separate networks may then be contained in a single
address range, just as a subnetted network is composed of many address range, just as a subnetted network is composed of many
separate subnets. Area border routers then summarize the area separate subnets. Area border routers then summarize the area
contents (for distribution to the backbone) by advertising a contents (for distribution to the backbone) by advertising a
single route for each address range. The cost of the route is single route for each address range. The cost of the route is
the minimum cost to any of the networks falling in the specified the maximum cost to any of the networks falling in the specified
range. range.
For example, an IP subnetted network might be configured as a For example, an IP subnetted network might be configured as a
single OSPF area. In that case, a single address range could be single OSPF area. In that case, a single address range could be
configured: a class A, B, or C network number along with its configured: a class A, B, or C network number along with its
natural IP mask. Inside the area, any number of variable sized natural IP mask. Inside the area, any number of variable sized
subnets could be defined. However, external to the area a subnets could be defined. However, external to the area a
single route for the entire subnetted network would be single route for the entire subnetted network would be
distributed, hiding even the fact that the network is subnetted distributed, hiding even the fact that the network is subnetted
at all. The cost of this route is the minimum of the set of at all. The cost of this route is the maximum of the set of
costs to the component subnets. costs to the component subnets.
3.6. Supporting stub areas 3.6. Supporting stub areas
In some Autonomous Systems, the majority of the link-state In some Autonomous Systems, the majority of the link-state
database may consist of AS-external-LSAs. An OSPF AS-external- database may consist of AS-external-LSAs. An OSPF AS-external-
LSA is usually flooded throughout the entire AS. However, OSPF LSA is usually flooded throughout the entire AS. However, OSPF
allows certain areas to be configured as "stub areas". AS- allows certain areas to be configured as "stub areas". AS-
external-LSAs are not flooded into/throughout stub areas; external-LSAs are not flooded into/throughout stub areas;
routing to AS external destinations in these areas is based on a routing to AS external destinations in these areas is based on a
skipping to change at page 59, line 8 skipping to change at page 59, line 8
2 Database description Section 10.6 2 Database description Section 10.6
3 Link state request Section 10.7 3 Link state request Section 10.7
4 Link state update Section 13 4 Link state update Section 13
5 Link state ack Section 13.7 5 Link state ack Section 13.7
Table 11: Sections describing OSPF protocol packet reception. Table 11: Sections describing OSPF protocol packet reception.
9. The Interface Data Structure 9. The Interface Data Structure
An OSPF interface is the connection between a router and a network. An OSPF interface is the connection between a router and a network.
There is a single OSPF interface structure for each attached We assume a single OSPF interface to each attached network/subnet,
network; each interface structure has at most one IP interface although supporting multiple interfaces on a single network is
address (see below). The support for multiple addresses on a single considered in Appendix F. Each interface structure has at most one
network is a matter for future consideration. IP interface address.
An OSPF interface can be considered to belong to the area that An OSPF interface can be considered to belong to the area that
contains the attached network. All routing protocol packets contains the attached network. All routing protocol packets
originated by the router over this interface are labelled with the originated by the router over this interface are labelled with the
interface's Area ID. One or more router adjacencies may develop interface's Area ID. One or more router adjacencies may develop
over an interface. A router's LSAs reflect the state of its over an interface. A router's LSAs reflect the state of its
interfaces and their associated adjacencies. interfaces and their associated adjacencies.
The following data items are associated with an interface. Note The following data items are associated with an interface. Note
that a number of these items are actually configuration for the that a number of these items are actually configuration for the
skipping to change at page 76, line 23 skipping to change at page 76, line 23
10.4). The adjacency starts to form when the neighbor is in 10.4). The adjacency starts to form when the neighbor is in
state ExStart. After the two routers discover their state ExStart. After the two routers discover their
master/slave status, the state transitions to Exchange. At this master/slave status, the state transitions to Exchange. At this
point the neighbor starts to be used in the flooding procedure, point the neighbor starts to be used in the flooding procedure,
and the two neighboring routers begin synchronizing their and the two neighboring routers begin synchronizing their
databases. When this synchronization is finished, the neighbor databases. When this synchronization is finished, the neighbor
is in state Full and we say that the two routers are fully is in state Full and we say that the two routers are fully
adjacent. At this point the adjacency is listed in LSAs. adjacent. At this point the adjacency is listed in LSAs.
For a more detailed description of neighbor state changes, For a more detailed description of neighbor state changes,
together with the additional actions involved in each change,
+----+ +----+
|Down| |Down|
+----+ +----+
| | rt |\
| +-------+ | \Start
| \ +-------+
Hello | +---->|Attempt| Hello | +---->|Attempt|
Received | +-------+ Received | +-------+
| | | |
+----+<-+ |HelloReceived +----+<-+ |HelloReceived
|Init|<---------------+ |Init|<---------------+
+----+<--------+ +----+<--------+
| | | |
|2-Way |1-Way |2-Way |1-Way
|Received |Received |Received |Received
| | | |
skipping to change at page 77, line 32 skipping to change at page 77, line 32
In addition to the state transitions pictured, In addition to the state transitions pictured,
Event SeqNumberMismatch forces ExStart state, Event SeqNumberMismatch forces ExStart state,
Event BadLSReq forces ExStart state, Event BadLSReq forces ExStart state,
Event 1-Way forces Init state, Event 1-Way forces Init state,
Event KillNbr always forces Down State, Event KillNbr always forces Down State,
Event InactivityTimer always forces Down State, Event InactivityTimer always forces Down State,
Event LLDown always forces Down State, Event LLDown always forces Down State,
Event AdjOK? leads to adjacency forming/breaking Event AdjOK? leads to adjacency forming/breaking
together with the additional actions involved in each change,
see Section 10.3. see Section 10.3.
Down Down
This is the initial state of a neighbor conversation. It This is the initial state of a neighbor conversation. It
indicates that there has been no recent information received indicates that there has been no recent information received
from the neighbor. On NBMA networks, Hello packets may from the neighbor. On NBMA networks, Hello packets may
still be sent to "Down" neighbors, although at a reduced still be sent to "Down" neighbors, although at a reduced
frequency (see Section 9.5.1). frequency (see Section 9.5.1).
Attempt Attempt
skipping to change at page 96, line 44 skipping to change at page 96, line 44
There is a single routing table in each router. Two sample routing There is a single routing table in each router. Two sample routing
tables are described in Sections 11.2 and 11.3. The building of the tables are described in Sections 11.2 and 11.3. The building of the
routing table is discussed in Section 16. routing table is discussed in Section 16.
The rest of this section defines the fields found in a routing table The rest of this section defines the fields found in a routing table
entry. The first set of fields describes the routing table entry's entry. The first set of fields describes the routing table entry's
destination. destination.
Destination Type Destination Type
The destination can be one of three types. Only the first type, Destination type is either "network" or "router". Only network
Network, is actually used when forwarding IP data traffic. The entries are actually used when forwarding IP data traffic.
other destinations are used solely as intermediate steps in the Router routing table entries are used solely as intermediate
routing table build process. steps in the routing table build process.
Network
A range of IP addresses, to which IP data traffic may be
forwarded. This includes IP networks (class A, B, or C), IP
subnets, IP supernets and single IP hosts. The default
route also falls in this category.
Area border router A network is a range of IP addresses, to which IP data traffic
Routers that are connected to multiple OSPF areas. Such may be forwarded. This includes IP networks (class A, B, or C),
routers originate summary-LSAs. These routing table entries IP subnets, IP supernets and single IP hosts. The default route
are used when calculating the inter-area routes (see Section also falls into this category.
16.2). These routing table entries may also be associated
with configured virtual links.
AS boundary router Router entries are kept for area border routers and AS boundary
Routers that originate AS-external-LSAs. These routing routers. Routing table entries for area border routers are used
table entries are used when calculating the AS external when calculating the inter-area routes (see Section 16.2), and
routes (see Section 16.4). when maintaining configured virtual links (see Section 15).
Routing table entries for AS boundary routers are used when
calculating the AS external routes (see Section 16.4).
Destination ID Destination ID
The destination's identifier or name. This depends on the The destination's identifier or name. This depends on the
Destination Type. For networks, the identifier is their Destination Type. For networks, the identifier is their
associated IP address. For all other types, the identifier is associated IP address. For routers, the identifier is the OSPF
the OSPF Router ID.[9] Router ID.[9]
Address Mask Address Mask
Only defined for networks. The network's IP address together Only defined for networks. The network's IP address together
with its address mask defines a range of IP addresses. For IP with its address mask defines a range of IP addresses. For IP
subnets, the address mask is referred to as the subnet mask. subnets, the address mask is referred to as the subnet mask.
For host routes, the mask is "all ones" (0xffffffff). For host routes, the mask is "all ones" (0xffffffff).
Optional Capabilities Optional Capabilities
When the destination is a router (either an area border router When the destination is a router this field indicates the
or an AS boundary router) this field indicates the optional OSPF optional OSPF capabilities supported by the destination router.
capabilities supported by the destination router. The two The two optional capabilities currently defined by this
optional capabilities currently defined by this specification specification are the ability to route based on IP TOS and the
are the ability to route based on IP TOS and the ability to ability to process AS-external-LSAs. For a further discussion
process AS-external-LSAs. For a further discussion of OSPF's of OSPF's optional capabilities, see Section 4.5.
optional capabilities, see Section 4.5.
The set of paths to use for a destination may vary based on IP Type The set of paths to use for a destination may vary based on IP Type
of Service and the OSPF area to which the paths belong. This means of Service and the OSPF area to which the paths belong. This means
that there may be multiple routing table entries for the same that there may be multiple routing table entries for the same
destination, depending on the values of the next two fields. destination, depending on the values of the next two fields.
Type of Service Type of Service
There can be a separate set of routes for each IP Type of There can be a separate set of routes for each IP Type of
Service. The encoding of TOS in OSPF LSAs is described in Service. The encoding of TOS in OSPF LSAs is described in
Section 12.3. Section 12.3.
Area Area
This field indicates the area whose link state information has This field indicates the area whose link state information has
led to the routing table entry's collection of paths. This is led to the routing table entry's collection of paths. This is
called the entry's associated area. For sets of AS external called the entry's associated area. For sets of AS external
paths, this field is not defined. For destinations of type paths, this field is not defined. For destinations of type
"area border router", there may be separate sets of paths (and "router", there may be separate sets of paths (and therefore
therefore separate routing table entries) associated with each separate routing table entries) associated with each of several
of several areas. This will happen when two area border routers areas. For example, this will happen when two area border
share multiple areas in common. For all other destination routers share multiple areas in common. For destinations of
types, only the set of paths associated with the best area (the type "network", only the set of paths associated with the best
one providing the shortest route) is kept. area (the one providing the preferred route) is kept.
The rest of the routing table entry describes the set of paths to The rest of the routing table entry describes the set of paths to
the destination. The following fields pertain to the set of paths the destination. The following fields pertain to the set of paths
as a whole. In other words, each one of the paths contained in a as a whole. In other words, each one of the paths contained in a
routing table entry is of the same path-type and cost (see below). routing table entry is of the same path-type and cost (see below).
Path-type Path-type
There are four possible types of paths used to route traffic to There are four possible types of paths used to route traffic to
the destination, listed here in order of preference: intra-area, the destination, listed here in order of preference: intra-area,
inter-area, type 1 external or type 2 external. Intra-area inter-area, type 1 external or type 2 external. Intra-area
skipping to change at page 99, line 29 skipping to change at page 99, line 22
When multiple paths of equal path-type and cost exist to a When multiple paths of equal path-type and cost exist to a
destination (called elsewhere "equal-cost" paths), they are stored destination (called elsewhere "equal-cost" paths), they are stored
in a single routing table entry. Each one of the "equal-cost" paths in a single routing table entry. Each one of the "equal-cost" paths
is distinguished by the following fields: is distinguished by the following fields:
Next hop Next hop
The outgoing router interface to use when forwarding traffic to The outgoing router interface to use when forwarding traffic to
the destination. On broadcast, Point-to-MultiPoint and NBMA the destination. On broadcast, Point-to-MultiPoint and NBMA
networks, the next hop also includes the IP address of the next networks, the next hop also includes the IP address of the next
router (if any) in the path towards the destination. This next router (if any) in the path towards the destination.
router will always be one of the adjacent neighbors.
Advertising router Advertising router
Valid only for inter-area and AS external paths. This field Valid only for inter-area and AS external paths. This field
indicates the Router ID of the router advertising the summary- indicates the Router ID of the router advertising the summary-
LSA or AS-external-LSA that led to this path. LSA or AS-external-LSA that led to this path.
11.1. Routing table lookup 11.1. Routing table lookup
When an IP data packet is received, an OSPF router finds the When an IP data packet is received, an OSPF router finds the
routing table entry that best matches the packet's destination. routing table entry that best matches the packet's destination.
skipping to change at page 101, line 17 skipping to change at page 101, line 13
the TOS 0 path if a TOS X path does not exist. the TOS 0 path if a TOS X path does not exist.
11.2. Sample routing table, without areas 11.2. Sample routing table, without areas
Consider the Autonomous System pictured in Figure 2. No OSPF Consider the Autonomous System pictured in Figure 2. No OSPF
areas have been configured. A single metric is shown per areas have been configured. A single metric is shown per
outbound interface, indicating that routes will not vary based outbound interface, indicating that routes will not vary based
on TOS. The calculation of Router RT6's routing table proceeds on TOS. The calculation of Router RT6's routing table proceeds
as described in Section 2.2. The resulting routing table is as described in Section 2.2. The resulting routing table is
shown in Table 12. Destination types are abbreviated: Network shown in Table 12. Destination types are abbreviated: Network
as "N", area border router as "BR" and AS boundary router as as "N", Router as "R".
"ASBR".
There are no instances of multiple equal-cost shortest paths in There are no instances of multiple equal-cost shortest paths in
this example. Also, since there are no areas, there are no this example. Also, since there are no areas, there are no
inter-area paths. inter-area paths.
Routers RT5 and RT7 are AS boundary routers. Intra-area routes Routers RT5 and RT7 are AS boundary routers. Intra-area routes
have been calculated to Routers RT5 and RT7. This allows have been calculated to Routers RT5 and RT7. This allows
external routes to be calculated to the destinations advertised external routes to be calculated to the destinations advertised
by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is
assumed all AS-external-LSAs originated by RT5 and RT7 are assumed all AS-external-LSAs originated by RT5 and RT7 are
skipping to change at page 101, line 44 skipping to change at page 101, line 39
Consider the previous example, this time split into OSPF areas. Consider the previous example, this time split into OSPF areas.
An OSPF area configuration is pictured in Figure 6. Router An OSPF area configuration is pictured in Figure 6. Router
RT4's routing table will be described for this area RT4's routing table will be described for this area
configuration. Router RT4 has a connection to Area 1 and a configuration. Router RT4 has a connection to Area 1 and a
backbone connection. This causes Router RT4 to view the AS as backbone connection. This causes Router RT4 to view the AS as
the concatenation of the two graphs shown in Figures 7 and 8. the concatenation of the two graphs shown in Figures 7 and 8.
The resulting routing table is displayed in Table 13. The resulting routing table is displayed in Table 13.
Again, Routers RT5 and RT7 are AS boundary routers. Routers Again, Routers RT5 and RT7 are AS boundary routers. Routers
RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that
there are two routing table entries (in this case having
identical paths) for Router RT7, in its dual capacities as an
area border router and an AS boundary router. Note also that
there are two routing entries for the area border router RT3, there are two routing entries for the area border router RT3,
since it has two areas in common with RT4 (Area 1 and the since it has two areas in common with RT4 (Area 1 and the
backbone).
Backbone paths have been calculated to all area border routers.
These are used when determining the inter-area routes. Note
that all of the inter-area routes are associated with the
backbone; this is always the case when the calculating router is
itself an area border router. Routing information is condensed
at area boundaries. In this example, we assume that Area 3 has
been defined so that networks N9-N11 and the host route to H1
are all condensed to a single route when advertised into the
Type Dest Area Path Type Cost Next Adv. Type Dest Area Path Type Cost Next Adv.
Hop(s) Router(s) Hop(s) Router(s)
____________________________________________________________ ____________________________________________________________
N N1 0 intra-area 10 RT3 * N N1 0 intra-area 10 RT3 *
N N2 0 intra-area 10 RT3 * N N2 0 intra-area 10 RT3 *
N N3 0 intra-area 7 RT3 * N N3 0 intra-area 7 RT3 *
N N4 0 intra-area 8 RT3 * N N4 0 intra-area 8 RT3 *
N Ib 0 intra-area 7 * * N Ib 0 intra-area 7 * *
N Ia 0 intra-area 12 RT10 * N Ia 0 intra-area 12 RT10 *
N N6 0 intra-area 8 RT10 * N N6 0 intra-area 8 RT10 *
N N7 0 intra-area 12 RT10 * N N7 0 intra-area 12 RT10 *
N N8 0 intra-area 10 RT10 * N N8 0 intra-area 10 RT10 *
N N9 0 intra-area 11 RT10 * N N9 0 intra-area 11 RT10 *
N N10 0 intra-area 13 RT10 * N N10 0 intra-area 13 RT10 *
N N11 0 intra-area 14 RT10 * N N11 0 intra-area 14 RT10 *
N H1 0 intra-area 21 RT10 * N H1 0 intra-area 21 RT10 *
ASBR RT5 0 intra-area 6 RT5 * R RT5 0 intra-area 6 RT5 *
ASBR RT7 0 intra-area 8 RT10 * R RT7 0 intra-area 8 RT10 *
____________________________________________________________ ____________________________________________________________
N N12 * type 1 ext. 10 RT10 RT7 N N12 * type 1 ext. 10 RT10 RT7
N N13 * type 1 ext. 14 RT5 RT5 N N13 * type 1 ext. 14 RT5 RT5
N N14 * type 1 ext. 14 RT5 RT5 N N14 * type 1 ext. 14 RT5 RT5
N N15 * type 1 ext. 17 RT10 RT7 N N15 * type 1 ext. 17 RT10 RT7
Table 12: The routing table for Router RT6 Table 12: The routing table for Router RT6
(no configured areas). (no configured areas).
backbone).
Backbone paths have been calculated to all area border routers
(BR). These are used when determining the inter-area routes.
Note that all of the inter-area routes are associated with the
backbone; this is always the case when the calculating router is
itself an area border router. Routing information is condensed
at area boundaries. In this example, we assume that Area 3 has
been defined so that networks N9-N11 and the host route to H1
are all condensed to a single route when advertised into the
backbone (by Router RT11). Note that the cost of this route is backbone (by Router RT11). Note that the cost of this route is
the minimum of the set of costs to its individual components. the maximum of the set of costs to its individual components.
There is a virtual link configured between Routers RT10 and There is a virtual link configured between Routers RT10 and
RT11. Without this configured virtual link, RT11 would be RT11. Without this configured virtual link, RT11 would be
unable to advertise a route for networks N9-N11 and Host H1 into unable to advertise a route for networks N9-N11 and Host H1 into
the backbone, and there would not be an entry for these networks the backbone, and there would not be an entry for these networks
in Router RT4's routing table. in Router RT4's routing table.
In this example there are two equal-cost paths to Network N12. In this example there are two equal-cost paths to Network N12.
However, they both use the same next hop (Router RT5). However, they both use the same next hop (Router RT5).
Router RT4's routing table would improve (i.e., some of the Router RT4's routing table would improve (i.e., some of the
paths in the routing table would become shorter) if an paths in the routing table would become shorter) if an
additional virtual link were configured between Router RT4 and additional virtual link were configured between Router RT4 and
Router RT3. The new virtual link would itself be associated Router RT3. The new virtual link would itself be associated
with the first entry for area border router RT3 in Table 13 (an
intra-area path through Area 1). This would yield a cost of 1
for the virtual link. The routing table entries changes that
would be caused by the addition of this virtual link are shown
Type Dest Area Path Type Cost Next Adv. Type Dest Area Path Type Cost Next Adv.
Hops(s) Router(s) Hops(s) Router(s)
__________________________________________________________________ __________________________________________________________________
N N1 1 intra-area 4 RT1 * N N1 1 intra-area 4 RT1 *
N N2 1 intra-area 4 RT2 * N N2 1 intra-area 4 RT2 *
N N3 1 intra-area 1 * * N N3 1 intra-area 1 * *
N N4 1 intra-area 3 RT3 * N N4 1 intra-area 3 RT3 *
BR RT3 1 intra-area 1 * * R RT3 1 intra-area 1 * *
__________________________________________________________________ __________________________________________________________________
N Ib 0 intra-area 22 RT5 * N Ib 0 intra-area 22 RT5 *
N Ia 0 intra-area 27 RT5 * N Ia 0 intra-area 27 RT5 *
BR RT3 0 intra-area 21 RT5 * R RT3 0 intra-area 21 RT5 *
BR RT7 0 intra-area 14 RT5 * R RT5 0 intra-area 8 * *
BR RT10 0 intra-area 22 RT5 * R RT7 0 intra-area 14 RT5 *
BR RT11 0 intra-area 25 RT5 * R RT10 0 intra-area 22 RT5 *
ASBR RT5 0 intra-area 8 * * R RT11 0 intra-area 25 RT5 *
ASBR RT7 0 intra-area 14 RT5 *
__________________________________________________________________ __________________________________________________________________
N N6 0 inter-area 15 RT5 RT7 N N6 0 inter-area 15 RT5 RT7
N N7 0 inter-area 19 RT5 RT7 N N7 0 inter-area 19 RT5 RT7
N N8 0 inter-area 18 RT5 RT7 N N8 0 inter-area 18 RT5 RT7
N N9-N11,H1 0 inter-area 26 RT5 RT11 N N9-N11,H1 0 inter-area 36 RT5 RT11
__________________________________________________________________ __________________________________________________________________
N N12 * type 1 ext. 16 RT5 RT5,RT7 N N12 * type 1 ext. 16 RT5 RT5,RT7
N N13 * type 1 ext. 16 RT5 RT5 N N13 * type 1 ext. 16 RT5 RT5
N N14 * type 1 ext. 16 RT5 RT5 N N14 * type 1 ext. 16 RT5 RT5
N N15 * type 1 ext. 23 RT5 RT7 N N15 * type 1 ext. 23 RT5 RT7
Table 13: Router RT4's routing table Table 13: Router RT4's routing table
in the presence of areas. in the presence of areas.
with the first entry for area border router RT3 in Table 13 (an
intra-area path through Area 1). This would yield a cost of 1
for the virtual link. The routing table entries changes that
would be caused by the addition of this virtual link are shown
in Table 14. in Table 14.
12. Link State Advertisements (LSAs) 12. Link State Advertisements (LSAs)
Each router in the Autonomous System originates one or more link Each router in the Autonomous System originates one or more link
state advertisements (LSAs). This memo defines five distinct types state advertisements (LSAs). This memo defines five distinct types
of LSAs, which are described in Section 4.3. The collection of LSAs of LSAs, which are described in Section 4.3. The collection of LSAs
forms the link-state database. Each separate type of LSA has a forms the link-state database. Each separate type of LSA has a
separate function. Router-LSAs and network-LSAs describe how an separate function. Router-LSAs and network-LSAs describe how an
Type Dest Area Path Type Cost Next Adv.
Hop(s) Router(s)
________________________________________________________________
N Ib 0 intra-area 16 RT3 *
N Ia 0 intra-area 21 RT3 *
R RT3 0 intra-area 1 * *
R RT10 0 intra-area 16 RT3 *
R RT11 0 intra-area 19 RT3 *
________________________________________________________________
N N9-N11,H1 0 inter-area 30 RT3 RT11
Table 14: Changes resulting from an
additional virtual link.
area's routers and networks are interconnected. Summary-LSAs area's routers and networks are interconnected. Summary-LSAs
provide a way of condensing an area's routing information. AS- provide a way of condensing an area's routing information. AS-
external-LSAs provide a way of transparently advertising external-LSAs provide a way of transparently advertising
externally-derived routing information throughout the Autonomous externally-derived routing information throughout the Autonomous
System. System.
Each LSA begins with a standard 20-byte header. This LSA header is Each LSA begins with a standard 20-byte header. This LSA header is
discussed below. discussed below.
12.1. The LSA Header 12.1. The LSA Header
The LSA header contains the LS type, Link State ID and The LSA header contains the LS type, Link State ID and
Advertising Router fields. The combination of these three Advertising Router fields. The combination of these three
fields uniquely identifies the LSA. fields uniquely identifies the LSA.
There may be several instances of an LSA present in the There may be several instances of an LSA present in the
Autonomous System, all at the same time. It must then be Autonomous System, all at the same time. It must then be
determined which instance is more recent. This determination is determined which instance is more recent. This determination is
Type Dest Area Path Type Cost Next Adv.
Hop(s) Router(s)
________________________________________________________________
N Ib 0 intra-area 16 RT3 *
N Ia 0 intra-area 21 RT3 *
BR RT3 0 intra-area 1 * *
BR RT10 0 intra-area 16 RT3 *
BR RT11 0 intra-area 19 RT3 *
________________________________________________________________
N N9-N11,H1 0 inter-area 20 RT3 RT11
Table 14: Changes resulting from an
additional virtual link.
made by examining the LS sequence, LS checksum and LS age made by examining the LS sequence, LS checksum and LS age
fields. These fields are also contained in the 20-byte LSA fields. These fields are also contained in the 20-byte LSA
header. header.
Several of the OSPF packet types list LSAs. When the instance Several of the OSPF packet types list LSAs. When the instance
is not important, an LSA is referred to by its LS type, Link is not important, an LSA is referred to by its LS type, Link
State ID and Advertising Router (see Link State Request State ID and Advertising Router (see Link State Request
Packets). Otherwise, the LS sequence number, LS age and LS Packets). Otherwise, the LS sequence number, LS age and LS
checksum fields must also be referenced. checksum fields must also be referenced.
skipping to change at page 107, line 4 skipping to change at page 106, line 37
is being described by the LSA. Depending on the LSA's LS is being described by the LSA. Depending on the LSA's LS
type, the Link State ID takes on the values listed in Table type, the Link State ID takes on the values listed in Table
16. 16.
Actually, for Type 3 summary-LSAs (LS type = 3) and AS- Actually, for Type 3 summary-LSAs (LS type = 3) and AS-
external-LSAs (LS type = 5), the Link State ID may external-LSAs (LS type = 5), the Link State ID may
additionally have one or more of the destination network's additionally have one or more of the destination network's
"host" bits set. For example, when originating an AS- "host" bits set. For example, when originating an AS-
external-LSA for the network 10.0.0.0 with mask of external-LSA for the network 10.0.0.0 with mask of
255.0.0.0, the Link State ID can be set to anything in the 255.0.0.0, the Link State ID can be set to anything in the
range 10.0.0.0 through 10.255.255.255 inclusive (although
10.0.0.0 should be used whenever possible). The freedom to
set certain host bits allows a router to originate separate
LSAs for two networks having the same address but different
masks. See Appendix E for details.
When the LSA is describing a network (LS type = 2, 3 or 5),
the network's IP address is easily derived by masking the
Link State ID with the network/subnet mask contained in the
body of the LSA. When the LSA is describing a router (LS
type = 1 or 4), the Link State ID is always the described
router's OSPF Router ID.
LS Type LSA description LS Type LSA description
________________________________________________ ________________________________________________
1 These are the router-LSAs. 1 These are the router-LSAs.
They describe the collected They describe the collected
states of the router's states of the router's
interfaces. For more information, interfaces. For more information,
consult Section 12.4.1. consult Section 12.4.1.
________________________________________________ ________________________________________________
2 These are the network-LSAs. 2 These are the network-LSAs.
They describe the set of routers They describe the set of routers
skipping to change at page 108, line 17 skipping to change at page 108, line 17
1 The originating router's Router ID. 1 The originating router's Router ID.
2 The IP interface address of the 2 The IP interface address of the
network's Designated Router. network's Designated Router.
3 The destination network's IP address. 3 The destination network's IP address.
4 The Router ID of the described AS 4 The Router ID of the described AS
boundary router. boundary router.
5 The destination network's IP address. 5 The destination network's IP address.
Table 16: The LSA's Link State ID. Table 16: The LSA's Link State ID.
range 10.0.0.0 through 10.255.255.255 inclusive (although
10.0.0.0 should be used whenever possible). The freedom to
set certain host bits allows a router to originate separate
LSAs for two networks having the same address but different
masks. See Appendix E for details.
When the LSA is describing a network (LS type = 2, 3 or 5),
the network's IP address is easily derived by masking the
Link State ID with the network/subnet mask contained in the
body of the LSA. When the LSA is describing a router (LS
type = 1 or 4), the Link State ID is always the described
router's OSPF Router ID.
When an AS-external-LSA (LS Type = 5) is describing a When an AS-external-LSA (LS Type = 5) is describing a
default route, its Link State ID is set to default route, its Link State ID is set to
DefaultDestination (0.0.0.0). DefaultDestination (0.0.0.0).
12.1.5. Advertising Router 12.1.5. Advertising Router
This field specifies the OSPF Router ID of the LSA's This field specifies the OSPF Router ID of the LSA's
originator. For router-LSAs, this field is identical to the originator. For router-LSAs, this field is identical to the
Link State ID field. Network-LSAs are originated by the Link State ID field. Network-LSAs are originated by the
network's Designated Router. Summary-LSAs originated by network's Designated Router. Summary-LSAs originated by
skipping to change at page 115, line 5 skipping to change at page 114, line 38
AS-external-LSAs that it had previously originated. These AS-external-LSAs that it had previously originated. These
LSAs can be flushed via the premature aging procedure LSAs can be flushed via the premature aging procedure
specified in Section 14.1. specified in Section 14.1.
The construction of each type of LSA is explained in detail The construction of each type of LSA is explained in detail
below. In general, these sections describe the contents of the below. In general, these sections describe the contents of the
LSA body (i.e., the part coming after the 20-byte LSA header). LSA body (i.e., the part coming after the 20-byte LSA header).
For information concerning the building of the LSA header, see For information concerning the building of the LSA header, see
Section 12.1. Section 12.1.
12.4.1. Router-LSAs
A router originates a router-LSA for each area that it
belongs to. Such an LSA describes the collected states of
the router's links to the area. The LSA is flooded
throughout the particular area, and no further.
The format of a router-LSA is shown in Appendix A (Section
A.4.2). The first 20 bytes of the LSA consist of the
generic LSA header that was discussed in Section 12.1.
router-LSAs have LS type = 1. The router indicates whether
it is willing to calculate separate routes for each IP TOS
.................................... ....................................
. 192.1.2 Area 1 . . 192.1.2 Area 1 .
. + . . + .
. | . . | .
. | 3+---+1 . . | 3+---+1 .
. N1 |--|RT1|-----+ . . N1 |--|RT1|-----+ .
. | +---+ . . | +---+ \ .
. | _______N3 . . | \ _______N3 .
. + / . 1+---+ . + \/ \ . 1+---+
. * 192.1.1 *------|RT4| . * 192.1.1 *------|RT4|
. + /_______/ . +---+ . + /\_______/ . +---+
. | / | . . | / | .
. | 3+---+1 / | . . | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| . . N2 |--|RT2|-----+ 1| .
. | +---+ +---+8 . 6+---+ . | +---+ +---+8 . 6+---+
. | |RT3|----------------|RT6| . | |RT3|----------------|RT6|
. + +---+ . +---+ . + +---+ . +---+
. 192.1.3 |2 . 18.10.0.6|7 . 192.1.3 |2 . 18.10.0.6|7
. | . | . | . |
. +------------+ . . +------------+ .
. 192.1.4 (N4) . . 192.1.4 (N4) .
.................................... ....................................
Figure 15: Area 1 with IP addresses shown Figure 15: Area 1 with IP addresses shown
12.4.1. Router-LSAs
A router originates a router-LSA for each area that it
belongs to. Such an LSA describes the collected states of
the router's links to the area. The LSA is flooded
throughout the particular area, and no further.
The format of a router-LSA is shown in Appendix A (Section
A.4.2). The first 20 bytes of the LSA consist of the
generic LSA header that was discussed in Section 12.1.
router-LSAs have LS type = 1. The router indicates whether
it is willing to calculate separate routes for each IP TOS
by setting (or resetting) the T-bit of the LSA's Options by setting (or resetting) the T-bit of the LSA's Options
field. field.
A router also indicates whether it is an area border router, A router also indicates whether it is an area border router,
or an AS boundary router, by setting the appropriate bits or an AS boundary router, by setting the appropriate bits
(bit B and bit E, respectively) in its router-LSAs. This (bit B and bit E, respectively) in its router-LSAs. This
enables paths to those types of routers to be saved in the enables paths to those types of routers to be saved in the
routing table, for later processing of summary-LSAs and AS- routing table, for later processing of summary-LSAs and AS-
external-LSAs. Bit B should be set whenever the router is external-LSAs. Bit B should be set whenever the router is
actively attached to two or more areas, even if the router actively attached to two or more areas, even if the router
skipping to change at page 124, line 19 skipping to change at page 124, line 7
o Else, if the next hops associated with this set of paths o Else, if the next hops associated with this set of paths
belong to Area A itself, do not generate a summary-LSA belong to Area A itself, do not generate a summary-LSA
for the route.[18] This is the logical equivalent of a for the route.[18] This is the logical equivalent of a
Distance Vector protocol's split horizon logic. Distance Vector protocol's split horizon logic.
o Else, if the routing table cost equals or exceeds the o Else, if the routing table cost equals or exceeds the
value LSInfinity, a summary-LSA cannot be generated for value LSInfinity, a summary-LSA cannot be generated for
this route. this route.
o Else, if the destination of this route is an AS boundary o Else, if the destination of this route is an AS boundary
router, generate a Type 4 summary-LSA for the router, a summary-LSA should be originated if and only
if the routing table entry describes the preferred path
to the AS boundary router (see Step 3 of Section 16.4).
If so, a Type 4 summary-LSA is originated for the
destination, with Link State ID equal to the AS boundary destination, with Link State ID equal to the AS boundary
router's Router ID and metric equal to the routing table router's Router ID and metric equal to the routing table
entry's cost. These LSAs should not be generated if entry's cost. Note: these LSAs should not be generated
Area A has been configured as a stub area. if Area A has been configured as a stub area.
o Else, the Destination type is network. If this is an o Else, the Destination type is network. If this is an
inter-area route, generate a Type 3 summary-LSA for the inter-area route, generate a Type 3 summary-LSA for the
destination, with Link State ID equal to the network's destination, with Link State ID equal to the network's
address (if necessary, the Link State ID can also have address (if necessary, the Link State ID can also have
one or more of the network's host bits set; see Appendix one or more of the network's host bits set; see Appendix
E for details) and metric equal to the routing table E for details) and metric equal to the routing table
cost. cost.
o The one remaining case is an intra-area route to a o The one remaining case is an intra-area route to a
skipping to change at page 124, line 47 skipping to change at page 124, line 38
appearing in summary-LSAs. Remember that an area has a appearing in summary-LSAs. Remember that an area has a
configured list of address ranges, each range consisting configured list of address ranges, each range consisting
of an [address,mask] pair and a status indication of of an [address,mask] pair and a status indication of
either Advertise or DoNotAdvertise. At most a single either Advertise or DoNotAdvertise. At most a single
Type 3 summary-LSA is originated for each range. When Type 3 summary-LSA is originated for each range. When
the range's status indicates Advertise, a Type 3 the range's status indicates Advertise, a Type 3
summary-LSA is generated with Link State ID equal to the summary-LSA is generated with Link State ID equal to the
range's address (if necessary, the Link State ID can range's address (if necessary, the Link State ID can
also have one or more of the range's "host" bits set; also have one or more of the range's "host" bits set;
see Appendix E for details) and cost equal to the see Appendix E for details) and cost equal to the
smallest cost of any of the component networks. When the largest cost of any of the component networks. When the
range's status indicates DoNotAdvertise, the Type 3 range's status indicates DoNotAdvertise, the Type 3
summary-LSA is suppressed and the component networks summary-LSA is suppressed and the component networks
remain hidden from other areas. remain hidden from other areas.
By default, if a network is not contained in any By default, if a network is not contained in any
explicitly configured address range, a Type 3 summary- explicitly configured address range, a Type 3 summary-
LSA is generated with Link State ID equal to the LSA is generated with Link State ID equal to the
network's address (if necessary, the Link State ID can network's address (if necessary, the Link State ID can
also have one or more of the network's "host" bits set; also have one or more of the network's "host" bits set;
see Appendix E for details) and metric equal to the see Appendix E for details) and metric equal to the
skipping to change at page 130, line 12 skipping to change at page 130, line 4
ID is used. The router having the lower OSPF Router ID ID is used. The router having the lower OSPF Router ID
can then flush its LSA. Flushing an LSA is discussed in can then flush its LSA. Flushing an LSA is discussed in
Section 14.1. Section 14.1.
13. The Flooding Procedure 13. The Flooding Procedure
Link State Update packets provide the mechanism for flooding LSAs. Link State Update packets provide the mechanism for flooding LSAs.
A Link State Update packet may contain several distinct LSAs, and A Link State Update packet may contain several distinct LSAs, and
floods each LSA one hop further from its point of origination. To floods each LSA one hop further from its point of origination. To
make the flooding procedure reliable, each LSA must be acknowledged make the flooding procedure reliable, each LSA must be acknowledged
+
|
+---+.....|.BGP
|RTA|-----|.....+---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+
Figure 16: Forwarding address example
separately. Acknowledgments are transmitted in Link State separately. Acknowledgments are transmitted in Link State
Acknowledgment packets. Many separate acknowledgments can also be Acknowledgment packets. Many separate acknowledgments can also be
grouped together into a single packet. grouped together into a single packet.
The flooding procedure starts when a Link State Update packet has The flooding procedure starts when a Link State Update packet has
been received. Many consistency checks have been made on the been received. Many consistency checks have been made on the
received packet before being handed to the flooding procedure (see received packet before being handed to the flooding procedure (see
Section 8.2). In particular, the Link State Update packet has been Section 8.2). In particular, the Link State Update packet has been
associated with a particular neighbor, and a particular area. If associated with a particular neighbor, and a particular area. If
the neighbor is in a lesser state than Exchange, the packet should the neighbor is in a lesser state than Exchange, the packet should
be dropped without further processing. be dropped without further processing.
All types of LSAs, other than AS-external-LSAs, are associated with All types of LSAs, other than AS-external-LSAs, are associated with
a specific area. However, LSAs do not contain an area field. An a specific area. However, LSAs do not contain an area field. An
LSA's area must be deduced from the Link State Update packet header. LSA's area must be deduced from the Link State Update packet header.
For each LSA contained in a Link State Update packet, the following For each LSA contained in a Link State Update packet, the following
steps are taken: steps are taken:
+
|
+---+.....|.BGP
|RTA|-----|.....+---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+
Figure 16: Forwarding address example
(1) Validate the LSA's LS checksum. If the checksum turns out to be (1) Validate the LSA's LS checksum. If the checksum turns out to be
invalid, discard the LSA and get the next one from the Link invalid, discard the LSA and get the next one from the Link
State Update packet. State Update packet.
(2) Examine the LSA's LS type. If the LS type is unknown, discard (2) Examine the LSA's LS type. If the LS type is unknown, discard
the LSA and get the next one from the Link State Update Packet. the LSA and get the next one from the Link State Update Packet.
This specification defines LS types 1-5 (see Section 4.3). This specification defines LS types 1-5 (see Section 4.3).
(3) Else if this is an AS-external-LSA (LS type = 5), and the area (3) Else if this is an AS-external-LSA (LS type = 5), and the area
has been configured as a stub area, discard the LSA and get the has been configured as a stub area, discard the LSA and get the
skipping to change at page 140, line 4 skipping to change at page 139, line 42
The reason that the acknowledgment logic for Backup DRs is The reason that the acknowledgment logic for Backup DRs is
slightly different is because they perform differently during slightly different is because they perform differently during
the flooding of LSAs (see Section 13.3, step 4). the flooding of LSAs (see Section 13.3, step 4).
13.6. Retransmitting LSAs 13.6. Retransmitting LSAs
LSAs flooded out an adjacency are placed on the adjacency's Link LSAs flooded out an adjacency are placed on the adjacency's Link
state retransmission list. In order to ensure that flooding is state retransmission list. In order to ensure that flooding is
reliable, these LSAs are retransmitted until they are reliable, these LSAs are retransmitted until they are
acknowledged. The length of time between retransmissions is a acknowledged. The length of time between retransmissions is a
configurable per-interface value, RxmtInterval. If this is set
too low for an interface, needless retransmissions will ensue.
If the value is set too high, the speed of the flooding, in the
face of lost packets, may be affected.
Several retransmitted LSAs may fit into a single Link State
Update packet. When LSAs are to be retransmitted, only the
number fitting in a single Link State Update packet should be
Action taken in state Action taken in state
Circumstances Backup All other states Circumstances Backup All other states
_______________________________________________________________ _______________________________________________________________
LSA has No acknowledgment No acknowledgment LSA has No acknowledgment No acknowledgment
been flooded back sent. sent. been flooded back sent. sent.
out receiving in- out receiving in-
terface (see Sec- terface (see Sec-
tion 13, step 5b). tion 13, step 5b).
_______________________________________________________________ _______________________________________________________________
LSA is Delayed acknowledg- Delayed ack- LSA is Delayed acknowledg- Delayed ack-
skipping to change at page 141, line 5 skipping to change at page 141, line 5
age is equal to ment sent. ment sent. age is equal to ment sent. ment sent.
MaxAge, and there is MaxAge, and there is
no current instance no current instance
of the LSA of the LSA
in the link state in the link state
database (see database (see
Section 13, step 4). Section 13, step 4).
Table 19: Sending link state acknowledgements. Table 19: Sending link state acknowledgements.
configurable per-interface value, RxmtInterval. If this is set
too low for an interface, needless retransmissions will ensue.
If the value is set too high, the speed of the flooding, in the
face of lost packets, may be affected.
Several retransmitted LSAs may fit into a single Link State
Update packet. When LSAs are to be retransmitted, only the
number fitting in a single Link State Update packet should be
sent. Another packet of retransmissions can be sent whenever sent. Another packet of retransmissions can be sent whenever
some of the LSAs are acknowledged, or on the next firing of the some of the LSAs are acknowledged, or on the next firing of the
retransmission timer. retransmission timer.
Link State Update Packets carrying retransmissions are always Link State Update Packets carrying retransmissions are always
sent as unicasts (directly to the physical address of the sent as unicasts (directly to the physical address of the
neighbor). They are never sent as multicasts. Each LSA's LS neighbor). They are never sent as multicasts. Each LSA's LS
age must be incremented by InfTransDelay (which must be > 0) age must be incremented by InfTransDelay (which must be > 0)
when it is copied into the outgoing Link State Update packet when it is copied into the outgoing Link State Update packet
(until the LS age field reaches the maximum value of MaxAge). (until the LS age field reaches the maximum value of MaxAge).
skipping to change at page 149, line 44 skipping to change at page 149, line 34
consistent with the tie-breakers that were introduced in the consistent with the tie-breakers that were introduced in the
modified Dijkstra algorithm used by OSPF's Multicast routing modified Dijkstra algorithm used by OSPF's Multicast routing
extensions (MOSPF). extensions (MOSPF).
(4) Possibly modify the routing table. For those routing table (4) Possibly modify the routing table. For those routing table
entries modified, the associated area will be set to Area A, entries modified, the associated area will be set to Area A,
the path type will be set to intra-area, and the cost will the path type will be set to intra-area, and the cost will
be set to the newly discovered shortest path's calculated be set to the newly discovered shortest path's calculated
distance. distance.
If the newly added vertex is an area border router (call it If the newly added vertex is an area border router or AS
ABR), a routing table entry is added whose destination type boundary router, a routing table entry is added whose
is "area border router". The Options field found in the destination type is "router". The Options field found in
associated router-LSA is copied into the routing table the associated router-LSA is copied into the routing table
entry's Optional capabilities field. If in addition ABR is entry's Optional capabilities field. Call the newly added
the endpoint of one of the calculating router's configured vertex Router X. If Router X is the endpoint of one of the
virtual links that uses Area A as its Transit area: the calculating router's virtual links, and the virtual link
virtual link is declared up, the IP address of the virtual uses Area A as Transit area: the virtual link is declared
interface is set to the IP address of the outgoing interface up, the IP address of the virtual interface is set to the IP
calculated above for ABR, and the virtual neighbor's IP address of the outgoing interface calculated above for
address is set to the ABR interface address (contained in Router X, and the virtual neighbor's IP address is set to
ABR's router-LSA) that points back to the root of the Router X's interface address (contained in Router X's
shortest-path tree; equivalently, this is the interface that router-LSA) that points back to the root of the shortest-
points back to ABR's parent vertex on the shortest-path tree path tree; equivalently, this is the interface that points
back to Router X's parent vertex on the shortest-path tree
(similar to the calculation in Section 16.1.1). (similar to the calculation in Section 16.1.1).
If the newly added vertex is an AS boundary router, the
routing table entry of type "AS boundary router" for the
destination is located. Since routers can belong to more
than one area, it is possible that several sets of intra-
area paths exist to the AS boundary router, each set using a
different area. However, the AS boundary router's routing
table entry must indicate a set of paths which utilize a
single area. The area leading to the routing table entry is
selected as follows: The area providing the shortest path
is always chosen; if more than one area provides paths with
the same minimum cost, the area with the largest OSPF Area
ID (when considered as an unsigned 32-bit integer) is
chosen. Note that whenever an AS boundary router's routing
table entry is added/modified, the Options found in the
associated router-LSA is copied into the routing table
entry's Optional capabilities field.
If the newly added vertex is a transit network, the routing If the newly added vertex is a transit network, the routing
table entry for the network is located. The entry's table entry for the network is located. The entry's
Destination ID is the IP network number, which can be Destination ID is the IP network number, which can be
obtained by masking the Vertex ID (Link State ID) with its obtained by masking the Vertex ID (Link State ID) with its
associated subnet mask (found in the body of the associated associated subnet mask (found in the body of the associated
network-LSA). If the routing table entry already exists network-LSA). If the routing table entry already exists
(i.e., there is already an intra-area route to the (i.e., there is already an intra-area route to the
destination installed in the routing table), multiple destination installed in the routing table), multiple
vertices have mapped to the same IP network. For example, vertices have mapped to the same IP network. For example,
this can occur when a new Designated Router is being this can occur when a new Designated Router is being
skipping to change at page 154, line 26 skipping to change at page 153, line 48
body of the LSA), and the area border originating the LSA body of the LSA), and the area border originating the LSA
BR. Look up the routing table entry for BR having Area A as BR. Look up the routing table entry for BR having Area A as
its associated area. If no such entry exists for router BR its associated area. If no such entry exists for router BR
(i.e., BR is unreachable in Area A), do nothing with this (i.e., BR is unreachable in Area A), do nothing with this
LSA and consider the next in the list. Else, this LSA LSA and consider the next in the list. Else, this LSA
describes an inter-area path to destination N, whose cost is describes an inter-area path to destination N, whose cost is
the distance to BR plus the cost specified in the LSA. Call the distance to BR plus the cost specified in the LSA. Call
the cost of this inter-area path IAC. the cost of this inter-area path IAC.
(5) Next, look up the routing table entry for the destination N. (5) Next, look up the routing table entry for the destination N.
(The entry's Destination Type is either Network or AS (If N is an AS boundary router, look up the "router" routing
boundary router.) If no entry exists for N or if the table entry associated with Area A). If no entry exists for
entry's path type is "type 1 external" or "type 2 external", N or if the entry's path type is "type 1 external" or "type
then install the inter-area path to N, with associated area 2 external", then install the inter-area path to N, with
Area A, cost IAC, next hop equal to the list of next hops to associated area Area A, cost IAC, next hop equal to the list
router BR, and Advertising router equal to BR. of next hops to router BR, and Advertising router equal to
BR.
(6) Else, if the paths present in the table are intra-area (6) Else, if the paths present in the table are intra-area
paths, do nothing with the LSA (intra-area paths are always paths, do nothing with the LSA (intra-area paths are always
preferred). preferred).
(7) Else, the paths present in the routing table are also (7) Else, the paths present in the routing table are also
inter-area paths. Install the new path through BR if it is inter-area paths. Install the new path through BR if it is
cheaper, overriding the paths in the routing table. cheaper, overriding the paths in the routing table.
Otherwise, if the new path is the same cost, add it to the Otherwise, if the new path is the same cost, add it to the
list of paths that appear in the routing table entry. list of paths that appear in the routing table entry.
skipping to change at page 155, line 27 skipping to change at page 154, line 48
Suppose also that the summary-LSA was originated by an area Suppose also that the summary-LSA was originated by an area
border router BR. border router BR.
(1) If the cost advertised by the summary-LSA is LSInfinity, or (1) If the cost advertised by the summary-LSA is LSInfinity, or
if the LSA's LS age is equal to MaxAge, then examine the if the LSA's LS age is equal to MaxAge, then examine the
next LSA. next LSA.
(2) If the summary-LSA was originated by the calculating router (2) If the summary-LSA was originated by the calculating router
itself, examine the next LSA. itself, examine the next LSA.
(3) Look up the routing table entry for N. If it does not exist, (3) Look up the routing table entry for N. (If N is an AS
or if the route type is other than intra-area or inter-area, boundary router, look up the "router" routing table entry
or if the area associated with the routing table entry is associated with the backbone area). If it does not exist, or
not the backbone area, then examine the next LSA. In other if the route type is other than intra-area or inter-area, or
if the area associated with the routing table entry is not
the backbone area, then examine the next LSA. In other
words, this calculation only updates backbone intra-area words, this calculation only updates backbone intra-area
routes found in Section 16.1 and inter-area routes found in routes found in Section 16.1 and inter-area routes found in
Section 16.2. Section 16.2.
(4) Look up the routing table entry for the advertising router (4) Look up the routing table entry for the advertising router
BR associated with the Area A. If it is unreachable, examine BR associated with the Area A. If it is unreachable, examine
the next LSA. Otherwise, the cost to destination N is the the next LSA. Otherwise, the cost to destination N is the
sum of the cost in BR's Area A routing table entry and the sum of the cost in BR's Area A routing table entry and the
cost advertised in the LSA. Call this cost IAC. cost advertised in the LSA. Call this cost IAC.
skipping to change at page 155, line 52 skipping to change at page 155, line 28
table entry, overwrite N's list of next hops with those used table entry, overwrite N's list of next hops with those used
for BR, and set N's routing table cost to IAC. Else, if IAC for BR, and set N's routing table cost to IAC. Else, if IAC
is the same as N's current cost, add BR's list of next hops is the same as N's current cost, add BR's list of next hops
to N's list of next hops. In any case, the area associated to N's list of next hops. In any case, the area associated
with N's routing table entry must remain the backbone area, with N's routing table entry must remain the backbone area,
and the path type (either intra-area or inter-area) must and the path type (either intra-area or inter-area) must
also remain the same. also remain the same.
It is important to note that the above calculation never makes It is important to note that the above calculation never makes
unreachable destinations reachable, but instead just potentially unreachable destinations reachable, but instead just potentially
finds better paths to already reachable destinations. The
........................ ........................
. Area 1 (transit) . + . Area 1 (transit) . +
. . | . . |
. +---+1 1+---+100 | . +---+1 1+---+100 |
. |RT2|----------|RT4|=========| . |RT2|----------|RT4|=========|
. 1/+---+********* +---+ | . 1/+---+********* +---+ |
. /******* . | . /******* . |
. 1/*Virtual . | . 1/*Virtual . |
1+---+/* Link . Net|work 1+---+/* Link . Net|work
=======|RT1|* . | N1 =======|RT1|* . | N1
+---+\ . | +---+\ . |
. \ . | . \ . |
. \ . | . \ . |
. 1\+---+1 1+---+20 | . 1\+---+1 1+---+20 |
. |RT3|----------|RT5|=========| . |RT3|----------|RT5|=========|
. +---+ +---+ | . +---+ +---+ |
. . | . . |
........................ + ........................ +
Figure 17: Routing through transit areas Figure 17: Routing through transit areas
finds better paths to already reachable destinations. The
calculation installs any better cost found into the routing calculation installs any better cost found into the routing
table entry, from which it may be readvertised in summary-LSAs table entry, from which it may be readvertised in summary-LSAs
to other areas. to other areas.
As an example of the calculation, consider the Autonomous System As an example of the calculation, consider the Autonomous System
pictured in Figure 17. There is a single non-backbone area pictured in Figure 17. There is a single non-backbone area
(Area 1) that physically divides the backbone into two separate (Area 1) that physically divides the backbone into two separate
pieces. To maintain connectivity of the backbone, a virtual link pieces. To maintain connectivity of the backbone, a virtual link
has been configured between routers RT1 and RT4. On the right has been configured between routers RT1 and RT4. On the right
side of the figure, Network N1 belongs to the backbone. The side of the figure, Network N1 belongs to the backbone. The
skipping to change at page 157, line 29 skipping to change at page 157, line 8
(1) If the cost specified by the LSA is LSInfinity, or if the (1) If the cost specified by the LSA is LSInfinity, or if the
LSA's LS age is equal to MaxAge, then examine the next LSA. LSA's LS age is equal to MaxAge, then examine the next LSA.
(2) If the LSA was originated by the calculating router itself, (2) If the LSA was originated by the calculating router itself,
examine the next LSA. examine the next LSA.
(3) Call the destination described by the LSA N. N's address is (3) Call the destination described by the LSA N. N's address is
obtained by masking the LSA's Link State ID with the obtained by masking the LSA's Link State ID with the
network/subnet mask contained in the body of the LSA. Look network/subnet mask contained in the body of the LSA. Look
up the routing table entry for the AS boundary router (ASBR) up the routing table entries (potentially one per attached
that originated the LSA. If no entry exists for router ASBR area) for the AS boundary router (ASBR) that originated the
(i.e., ASBR is unreachable), do nothing with this LSA and LSA. If no entries exist for router ASBR (i.e., ASBR is
consider the next in the list. unreachable), do nothing with this LSA and consider the next
in the list.
Else, this LSA describes an AS external path to destination Else, this LSA describes an AS external path to destination
N. Examine the forwarding address specified in the AS- N. Examine the forwarding address specified in the AS-
external-LSA. This indicates the IP address to which external-LSA. This indicates the IP address to which
packets for the destination should be forwarded. If the packets for the destination should be forwarded.
forwarding address is set to 0.0.0.0, packets should be sent
to the ASBR itself. Otherwise, look up the forwarding
address in the routing table.[26] An intra-area or inter-
area path must exist to the forwarding address. If no such
path exists, do nothing with the LSA and consider the next
in the list.
Call the routing table distance to the forwarding address X If the forwarding address is set to 0.0.0.0, packets should
(when the forwarding address is set to 0.0.0.0, this is the be sent to the ASBR itself. Among the multiple routing table
distance to the ASBR itself), and the cost specified in the entries for the ASBR, select the preferred entry as follows.
LSA Y. X is in terms of the link state metric, and Y is a If RFC1583Compatibility is set to "disabled", prune the set
type 1 or 2 external metric. of routing table entries for the ASBR as described in
Section 16.4.1. In any case, among the remaining routing
table entries, select the routing table entry with the least
cost; when there are multiple least cost routing table
entries the entry whose associated area has the largest OSPF
Area ID (when considered as an unsigned 32-bit integer) is
chosen.
(4) Next, look up the routing table entry for the destination N. If the forwarding address is non-zero, look up the
If no entry exists for N, install the AS external path to N, forwarding address in the routing table.[26] The matching
routing table entry must specify an intra-area or inter-area
path; if no such path exists, do nothing with the LSA and
consider the next in the list.
(4) Let X be the cost specified by the preferred routing table
entry for the ASBR/forwarding address, and Y the cost
specified in the LSA. X is in terms of the link state
metric, and Y is a type 1 or 2 external metric.
(5) Look up the routing table entry for the destination N. If
no entry exists for N, install the AS external path to N,
with next hop equal to the list of next hops to the with next hop equal to the list of next hops to the
forwarding address, and advertising router equal to ASBR. forwarding address, and advertising router equal to ASBR.
If the external metric type is 1, then the path-type is set If the external metric type is 1, then the path-type is set
to type 1 external and the cost is equal to X+Y. If the to type 1 external and the cost is equal to X+Y. If the
external metric type is 2, the path-type is set to type 2 external metric type is 2, the path-type is set to type 2
external, the link state component of the route's cost is X, external, the link state component of the route's cost is X,
and the type 2 cost is Y. and the type 2 cost is Y.
(5) Else, if the paths present in the table are not type 1 or (6) Compare the AS external path described by the LSA with the
type 2 external paths, do nothing (AS external paths have existing paths in N's routing table entry, as follows. If
the lowest priority). the new path is preferred, it replaces the present paths in
N's routing table entry. If the new path is of equal
preference, it is added to N's routing table entry's list of
paths.
(6) Otherwise, compare the cost of this new AS external path to (a) Intra-area and inter-area paths are always preferred
the ones present in the table. Type 1 external paths are over AS external paths.
always shorter than type 2 external paths. Type 1 external
paths are compared by looking at the sum of the distance to
the forwarding address and the advertised type 1 metric
(X+Y). Type 2 external paths are compared by looking at the
advertised type 2 metrics, and then if necessary, the
distance to the forwarding addresses.
If the new path is shorter, it replaces the present paths in (b) Type 1 external paths are always preferred over type 2
the routing table entry. If the new path is the same cost, external paths. When all paths are type 2 external
it is added to the routing table entry's list of paths. paths, the paths with the smallest advertised type 2
metric are always preferred.
(c) If the new AS external path is still indistinguishable
from the current paths in the N's routing table entry,
and RFC1583Compatibility is set to "disabled", select
the preferred paths based on the intra-AS paths to the
ASBR/forwarding addresses, as specified in Section
16.4.1.
(d) If the new AS external path is still indistinguishable
from the current paths in the N's routing table entry,
select the preferred path based on a least cost
comparison. Type 1 external paths are compared by
looking at the sum of the distance to the forwarding
address and the advertised type 1 metric (X+Y). Type 2
external paths advertising equal type 2 metrics are
compared by looking at the distance to the forwarding
addresses.
16.4.1. External path preferences
When multiple intra-AS paths are available to
ASBRs/forwarding addresses, the following rules indicate
which paths are preferred. These rules apply when the same
ASBR is reachable through multiple areas, or when trying to
decide which of several AS-external-LSAs should be
preferred. In the former case the paths all terminate at the
same ASBR, while in the latter the paths terminate at
separate ASBRs/forwarding addresses. In either case, each
path is represented by a separate routing table entry as
defined in Section 11.
This section only applies when RFC1583Compatibility is set
to "disabled".
The path preference rules, stated from highest to lowest
preference, are as follows. Note that as a result of these
rules, there may still be multiple paths of the highest
preference. In this case, the path to use must be determined
based on cost, as described in Section 16.4.
o Intra-area paths using non-backbone areas are always the
most preferred.
o Otherwise, intra-area backbone paths are preferred.
o Inter-area paths are the least preferred.
16.5. Incremental updates -- summary-LSAs 16.5. Incremental updates -- summary-LSAs
When a new summary-LSA is received, it is not necessary to When a new summary-LSA is received, it is not necessary to
recalculate the entire routing table. Call the destination recalculate the entire routing table. Call the destination
described by the summary-LSA N (N's address is obtained by described by the summary-LSA N (N's address is obtained by
masking the LSA's Link State ID with the network/subnet mask masking the LSA's Link State ID with the network/subnet mask
contained in the body of the LSA), and let Area A be the area to contained in the body of the LSA), and let Area A be the area to
which the LSA belongs. There are then two separate cases: which the LSA belongs. There are then two separate cases:
skipping to change at page 162, line 10 skipping to change at page 162, line 44
The following lists the modifications needed when running the The following lists the modifications needed when running the
routing table calculation for a non-zero TOS value (called TOS routing table calculation for a non-zero TOS value (called TOS
X). In general, routers and LSAs that do not support TOS are X). In general, routers and LSAs that do not support TOS are
omitted from the calculation. omitted from the calculation.
Calculating the shortest-path tree (Section 16.1). Calculating the shortest-path tree (Section 16.1).
Routers that do not support TOS-based routing should be Routers that do not support TOS-based routing should be
omitted from the shortest-path tree calculation. These omitted from the shortest-path tree calculation. These
routers are identified as those having the T-bit reset in routers are identified as those having the T-bit reset in
the Options field of their router-LSAs. Such routers should the Options field of their router-LSAs. Such routers should
never be added to the Dijktra algorithm's candidate list, never be added to the Dijkstra algorithm's candidate list,
nor should their router-LSAs be examined when adding the nor should their router-LSAs be examined when adding the
stub networks to the tree. In particular, if the T-bit is stub networks to the tree. In particular, if the T-bit is
reset in the calculating router's own router-LSA, it does reset in the calculating router's own router-LSA, it does
not run the shortest-path tree calculation for non-zero TOS not run the shortest-path tree calculation for non-zero TOS
values. values.
Calculating the inter-area routes (Section 16.2). Calculating the inter-area routes (Section 16.2).
Inter-area paths are the concatenation of a path to an area Inter-area paths are the concatenation of a path to an area
border router with a summary link. When calculating TOS X border router with a summary link. When calculating TOS X
routes, both path components must also specify TOS X. In routes, both path components must also specify TOS X. In
skipping to change at page 200, line 45 skipping to change at page 201, line 45
before the new Router ID takes effect. Before restarting in before the new Router ID takes effect. Before restarting in
order to change its Router ID, the router should flush its order to change its Router ID, the router should flush its
self-originated LSAs from the routing domain (see Section self-originated LSAs from the routing domain (see Section
14.1), or they will persist for up to MaxAge minutes. 14.1), or they will persist for up to MaxAge minutes.
TOS capability TOS capability
This item indicates whether the router will calculate This item indicates whether the router will calculate
separate routes based on TOS. For more information, see separate routes based on TOS. For more information, see
Sections 4.5 and 16.9. Sections 4.5 and 16.9.
RFC1583Compatibility
Controls the preference rules used in Section 16.4 when
choosing among multiple AS-external-LSAs advertising the
same destination. When set to "enabled", the preference
rules remain those specified by RFC 1583 ([Ref9]). When set
to "disabled", the preference rules are those stated in
Section 16.4.1, which prevent routing loops when AS-
external-LSAs for the same destination have been originated
from different areas (see Section G.7). Set to "enabled" by
default.
In order to minimize the chance of routing loops, all OSPF
routers in an OSPF routing domain should have
RFC1583Compatibility set identically. When there are routers
present that have not been updated with the functionality
specified in Section 16.4.1 of this memo, all routers should
have RFC1583Compatibility set to "enabled". Otherwise, all
routers should have RFC1583Compatibility set to "disabled",
preventing all routing loops.
C.2 Area parameters C.2 Area parameters
All routers belonging to an area must agree on that area's All routers belonging to an area must agree on that area's
configuration. Disagreements between two routers will lead to configuration. Disagreements between two routers will lead to
an inability for adjacencies to form between them, with a an inability for adjacencies to form between them, with a
resulting hindrance to the flow of routing protocol and data resulting hindrance to the flow of routing protocol and data
traffic. The following items must be configured for an area: traffic. The following items must be configured for an area:
Area ID Area ID
This is a 32-bit number that identifies the area. The Area This is a 32-bit number that identifies the area. The Area
skipping to change at page 209, line 10 skipping to change at page 210, line 10
Figure 18: Usage of the Authentication field Figure 18: Usage of the Authentication field
in the OSPF packet header when Cryptographic in the OSPF packet header when Cryptographic
Authentication is employed Authentication is employed
contains a new field called the "cryptographic sequence number". contains a new field called the "cryptographic sequence number".
This field is initialized to zero, and is also set to zero This field is initialized to zero, and is also set to zero
whenever the neighbor's state transitions to "Down". Whenever an whenever the neighbor's state transitions to "Down". Whenever an
OSPF packet is accepted as authentic, the cryptographic sequence OSPF packet is accepted as authentic, the cryptographic sequence
number is set to the received packet's sequence number. number is set to the received packet's sequence number.
This specification does not provide a rollover procedure for the
cryptographic sequence number. When the cryptographic sequence
number that the router is sending hits the maximum value, the
router should reset the cryptographic sequence number that it is
sending back to 0. After this is done, the router's neighbors
will reject the router's OSPF packets for a period of
RouterDeadInterval, and then the router will be forced to
reestablish all adjacencies over the interface. However, it is
expected that many implementations will use "seconds since
reboot" (or "seconds since 1960", etc.) as the cryptographic
sequence number. Such a choice will essentially prevent
rollover, since the cryptographic sequence number field is 32
bits in length.
The OSPF Cryptographic authentication option does not provide The OSPF Cryptographic authentication option does not provide
confidentiality. confidentiality.
When cryptographic authentication is used, the 64-bit When cryptographic authentication is used, the 64-bit
Authentication field in the standard OSPF packet header is Authentication field in the standard OSPF packet header is
redefined as shown in Figure 18. The new field definitions are redefined as shown in Figure 18. The new field definitions are
as follows: as follows:
Key ID Key ID
This field identifies the algorithm and secret key used to This field identifies the algorithm and secret key used to
skipping to change at page 217, line 5 skipping to change at page 218, line 5
(a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
new Link State ID of 10.0.255.255. new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for (b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0]. [10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255. of 10.0.0.255.
F. Differences from RFC 1583 F. Multiple interfaces to the same network/subnet
There are at least two ways to support multiple physical interfaces
to the same IP subnet. Both methods will interoperate with
implementations of RFC 1583 (and of course this memo). The two
methods are sketched briefly below. An assumption has been made that
each interface has been assigned a separate IP address (otherwise,
support for multiple interfaces is more of a link-level or ARP issue
than an OSPF issue).
Method 1:
Run the entire OSPF functionality over both interfaces, sending
and receiving hellos, flooding, supporting separate interface
and neighbor FSMs for each interface, etc. When doing this all
other routers on the subnet will treat the two interfaces as
separate neighbors, since neighbors are identified (on broadcast
and NBMA networks) by their IP address.
Method 1 has the following disadvantages:
(1) You increase the total number of neighbors and adjacencies.
(2) You lose the bidirectionality test on both interfaces, since
bidirectionality is based on Router ID.
(3) You have to consider both interfaces together during the
Designated Router election, since if you declare both to be
DR simultaneously you can confuse the tie-breaker (which is
Router ID).
Method 2:
Run OSPF over only one interface (call it the primary
interface), but include both the primary and secondary
interfaces in your Router-LSA.
Method 2 has the following disadvantages:
(1) You lose the bidirectionality test on the secondary
interface.
(2) When the primary interface fails, you need to promote the
secondary interface to primary status.
G. Differences from RFC 1583
This section documents the differences between this memo and RFC This section documents the differences between this memo and RFC
1583. All differences are backward-compatible. Implementations of 1583. All differences are backward-compatible. Implementations of
this memo and of RFC 1583 will interoperate. this memo and of RFC 1583 will interoperate.
F.1 Enhancements to OSPF authentication G.1 Enhancements to OSPF authentication
An additional OSPF authentication type has been added: the An additional OSPF authentication type has been added: the
Cryptographic authentication type. This has been defined so that Cryptographic authentication type. This has been defined so that
any arbitrary "Keyed Message Digest" algorithm can be used for any arbitrary "Keyed Message Digest" algorithm can be used for
packet authentication. Operation using the MD5 algorithm is packet authentication. Operation using the MD5 algorithm is
completely specified (see Appendix D). completely specified (see Appendix D).
A number of other changes were also made to OSPF packet A number of other changes were also made to OSPF packet
authentication, affecting the following Sections: authentication, affecting the following Sections:
skipping to change at page 217, line 38 skipping to change at page 219, line 38
into the description of authentication types (Appendix D). into the description of authentication types (Appendix D).
o In Appendix D, sections detailing message generation and o In Appendix D, sections detailing message generation and
message verification have been added. message verification have been added.
o For the OSPF Cryptographic authentication type, a discussion o For the OSPF Cryptographic authentication type, a discussion
of key management, including the requirement for of key management, including the requirement for
simultaneous support of multiple keys, key lifetimes and simultaneous support of multiple keys, key lifetimes and
smooth key transition, has been added to Appendix D. smooth key transition, has been added to Appendix D.
F.2 Addition of Point-to-MultiPoint interface G.2 Addition of Point-to-MultiPoint interface
This memo adds an additional method for running OSPF over non- This memo adds an additional method for running OSPF over non-
broadcast networks: the Point-to-Multipoint network. To broadcast networks: the Point-to-Multipoint network. To
implement this addition, the language of RFC 1583 has been implement this addition, the language of RFC 1583 has been
altered slightly. References to "multi-access" networks have altered slightly. References to "multi-access" networks have
been deleted. The term "non-broadcast networks" is now used to been deleted. The term "non-broadcast networks" is now used to
describe networks which can connect many routers, but which do describe networks which can connect many routers, but which do
not natively support broadcast/multicast (such as a public Frame not natively support broadcast/multicast (such as a public Frame
relay network). Over non-broadcast networks, there are two relay network). Over non-broadcast networks, there are two
options for running OSPF: modelling them as "NBMA networks" or options for running OSPF: modelling them as "NBMA networks" or
skipping to change at page 218, line 47 skipping to change at page 220, line 47
links" to all of the interface's adjacent neighbors, links" to all of the interface's adjacent neighbors,
together with a single stub link advertising the interface's together with a single stub link advertising the interface's
IP address with a cost of 0 (Section 12.4.1.4). IP address with a cost of 0 (Section 12.4.1.4).
o When flooding out a non-broadcast interface (when either in o When flooding out a non-broadcast interface (when either in
NBMA or Point-to-MultiPoint mode) the Link State Update or NBMA or Point-to-MultiPoint mode) the Link State Update or
Link State Acknowledgment packet must be replicated in order Link State Acknowledgment packet must be replicated in order
to be sent to each of the interface's neighbors (see to be sent to each of the interface's neighbors (see
Sections 13.3 and 13.5). Sections 13.3 and 13.5).
F.3 Support for overlapping area ranges G.3 Support for overlapping area ranges
RFC 1583 requires that all networks falling into a given area RFC 1583 requires that all networks falling into a given area
range actually belong to a single area. This memo relaxes that range actually belong to a single area. This memo relaxes that
restriction. This is useful in the following example. Suppose restriction. This is useful in the following example. Suppose
that [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of that [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of
these subnets are assigned to a single OSPF area (call it Area these subnets are assigned to a single OSPF area (call it Area
X), while a few subnets are assigned to other areas. In order to X), while a few subnets are assigned to other areas. In order to
get this configuration to work with RFC 1583, you must not get this configuration to work with RFC 1583, you must not
summarize the subnets of Area X with the single range [10.0.0.0, summarize the subnets of Area X with the single range [10.0.0.0,
255.0.0.0], because then the subnets of 10.0.0.0 belonging to 255.0.0.0], because then the subnets of 10.0.0.0 belonging to
other areas would become unreachable. However, with this memo other areas would become unreachable. However, with this memo
you can summarize the subnets in Area X, provided that the you can summarize the subnets in Area X, provided that the
subnets belonging to other areas are not summarized. subnets belonging to other areas are not summarized.
Implementation details for this change can be found in Sections Implementation details for this change can be found in Sections
11.1 and 16.2. 11.1 and 16.2.
F.4 A modification to the flooding algorithm G.4 A modification to the flooding algorithm
The OSPF flooding algorithm has been modified as follows. When a The OSPF flooding algorithm has been modified as follows. When a
Link State Update Packet is received that contains an LSA Link State Update Packet is received that contains an LSA
instance which is actually less recent than the the router's instance which is actually less recent than the the router's
current database copy, the router will now in most cases respond current database copy, the router will now in most cases respond
by flooding back its database copy. This is in contrast to the by flooding back its database copy. This is in contrast to the
RFC 1583 behavior, which was to simply throw the received LSA RFC 1583 behavior, which was to simply throw the received LSA
away. away.
Detailed description of the change can be found in Step 8 of Detailed description of the change can be found in Step 8 of
skipping to change at page 219, line 45 skipping to change at page 221, line 45
MaxAge LSAs can inhibit the flooding of new instances of the MaxAge LSAs can inhibit the flooding of new instances of the
LSA. New instances typically start with LS sequence number equal LSA. New instances typically start with LS sequence number equal
to InitialSequenceNumber, and are treated as less recent (and to InitialSequenceNumber, and are treated as less recent (and
hence were discarded according to RFC 1583) by routers still hence were discarded according to RFC 1583) by routers still
holding MaxAge instances. However, with the above change to holding MaxAge instances. However, with the above change to
flooding, a router holding a MaxAge instance will flood back the flooding, a router holding a MaxAge instance will flood back the
MaxAge instance. When this flood reaches the LSA's originator, MaxAge instance. When this flood reaches the LSA's originator,
it will then pick the next highest LS sequence number and it will then pick the next highest LS sequence number and
reflood, overwriting the MaxAge instance. reflood, overwriting the MaxAge instance.
F.5 Introduction of the MinLSArrival constant G.5 Introduction of the MinLSArrival constant
OSPF limits the frequency that new instances of any particular OSPF limits the frequency that new instances of any particular
LSA can be accepted during flooding. This is extra protection, LSA can be accepted during flooding. This is extra protection,
just in case a neighboring router is violating the mandated just in case a neighboring router is violating the mandated
limit on LSA (re)originations (namely, one per LSA in any limit on LSA (re)originations (namely, one per LSA in any
MinLSInterval). MinLSInterval).
In RFC 1583, the frequency at which new LSA instances were In RFC 1583, the frequency at which new LSA instances were
accepted was also set equal to once every MinLSInterval seconds. accepted was also set equal to once every MinLSInterval seconds.
However, in some circumstances this led to unwanted link state However, in some circumstances this led to unwanted link state
skipping to change at page 220, line 19 skipping to change at page 222, line 19
MinLSInterval limit on originations. This was due to either 1) MinLSInterval limit on originations. This was due to either 1)
choice of clock granularity in some OSPF implementations or 2) choice of clock granularity in some OSPF implementations or 2)
differing clock speed in neighboring routers. differing clock speed in neighboring routers.
To alleviate this problem, the frequency at which new LSA To alleviate this problem, the frequency at which new LSA
instances are accepted during flooding has now been increased to instances are accepted during flooding has now been increased to
once every MinLSArrival seconds, whose value is set to 1. This once every MinLSArrival seconds, whose value is set to 1. This
change is reflected in Steps 5a and 5d of Section 13, and in change is reflected in Steps 5a and 5d of Section 13, and in
Appendix B. Appendix B.
F.6 Optionally advertising point-to-point links as subnets G.6 Optionally advertising point-to-point links as subnets
When describing a point-to-point interface in its router-LSA, a When describing a point-to-point interface in its router-LSA, a
router may now advertise a stub link to the point-to-point router may now advertise a stub link to the point-to-point
network's subnet. This is specified as an alternative to the RFC network's subnet. This is specified as an alternative to the RFC
1583 behavior, which is to advertise a stub link to the 1583 behavior, which is to advertise a stub link to the
neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for
details. details.
G.7 Advertising same external route from multiple areas
This document fixes routing loops which can occur in RFC 1583
when the same external destination is advertised by AS boundary
routers in separate areas. There are two manifestations of this
problem. The first, discovered by Dennis Ferguson, occurs when
an aggregated forwarding address is in use. In this case, the
desirability of the forwarding address can change for the worse
as a packet crosses an area aggregation boundary on the way to
the forwarding address, which in turn can cause the preference
of AS-external-LSAs to change, resulting in a routing loop.
The second manifestation was discovered by Richard Woundy. It is
caused by an incomplete application of OSPF's preference of
intra-area routes over inter-area routes: paths to any given
ASBR/forwarding address are selected first based on intra-area
preference, while the comparison between separate
ASBRs/forwarding addresses is driven only by cost, ignoring
intra-area preference. His example is replicated in Figure 19.
Both router A3 and router B3 are originating an AS-external-LSA
for 10.0.0.0/8, with the same type 2 metric. Router A1 selects
B1 as its next hop towards 10.0.0.0/8, based on shorter cost to
ASBR B3 (via B1->B2->B3). However, the shorter route to B3 is
not available to B1, due to B1's preference for the (higher
cost) intra-area route to B3 through Area A. This leads B1 to
select A1 as its next hop to 10.0.0.0/8, resulting in a routing
loop.
The following two changes have been made to prevent these
routing loops:
o When originating a type 3 summary-LSA for a configured area
address range, the cost of the summary-LSA is now set to the
maximum cost of the range's component networks (instead of
the previous algorithm which set the cost to the minimum
component cost). This change affects Sections 3.5 and
12.4.3, Figures 7 and 8, and Tables 6 and 13.
o The preference rules for choosing among multiple AS-
external-LSAs have been changed. Where previously cost was
the only determining factor, now the preference is driven
first by type of path (intra-area or inter-area, through
non-backbone area or through backbone) to the
ASBR/forwarding address, using cost only to break ties. This
change affects Sections 16.4 and 16.4.1.
After implementing this change, the example in Figure 19 is
modified as follows. Router A1 now chooses A3 as the next
10.0.0.0/8
----------
|
+----+
| XX |
+----+
RIP / \ RIP
--------------------- --------------------
! !
! !
+----+ +----+ 1 +----+......+----+....
| A3 |------| A1 |---------------| B1 |------| B3 | .
+----+ 6 +----+ +----+ 8 +----+ .
1| . / .
OSPF backbone | . / .
+----+ 2 / .
| B2 |------- Area A.
+----+................
Figure 19: Example routing loop when the
same external route is advertised from multiple
areas
hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The
reason for both choices is that ASBRs/forwarding addresses
are now chosen based first on intra-area preference, and
then by cost.
Unfortunately, this change is not backward compatible. While
the change prevents routing loops when all routers run the
new preference rules, it can actually create routing loops
when some routers are running the new preference rules and
other routers implement RFC 1583. For this reason, a new
configuration parameter has been added:
RFC1583Compatibility. Only when RFC1583Compatibility is set
to "disabled" will the new preference rules take effect. See
Appendix C for more details.
Security Considerations Security Considerations
All OSPF protocol exchanges are authenticated. OSPF supports All OSPF protocol exchanges are authenticated. OSPF supports
multiple types of authentication; the type of authentication in use multiple types of authentication; the type of authentication in use
can be configured on a per network segment basis. One of OSPF's can be configured on a per network segment basis. One of OSPF's
authentication types, namely the Cryptographic authentication authentication types, namely the Cryptographic authentication
option, is believed to be secure against active and passive attacks. option, is believed to be secure against passive attacks and provide
When using the Cryptographic authentication option, each router significant protection against active attacks. When using the
appends a "message digest" to its transmitted OSPF packets. Cryptographic authentication option, each router appends a "message
Receivers then use the shared secret key and received digest to digest" to its transmitted OSPF packets. Receivers then use the
verify that each received OSPF packet is authentic. shared secret key and received digest to verify that each received
OSPF packet is authentic.
The quality of the security provided by the Cryptographic The quality of the security provided by the Cryptographic
authentication option depends completely on the strength of the authentication option depends completely on the strength of the
message digest algorithm (MD5 is currently the only message digest message digest algorithm (MD5 is currently the only message digest
algorithm specified), the strength of the key being used, and the algorithm specified), the strength of the key being used, and the
correct implementation of the security mechanism in all correct implementation of the security mechanism in all
communicating OSPF implementations. It also requires that all communicating OSPF implementations. It also requires that all
parties maintain the secrecy of the shared secret key. parties maintain the secrecy of the shared secret key.
None of the OSPF authentication types provide confidentiality. Nor None of the OSPF authentication types provide confidentiality. Nor
skipping to change at page 221, line 42 skipping to change at page 225, line 43
John Moy John Moy
Cascade Communications Corp. Cascade Communications Corp.
5 Carlisle Road 5 Carlisle Road
Westford, MA 01886 Westford, MA 01886
Phone: 508-952-1367 Phone: 508-952-1367
Fax: 508-692-9214 Fax: 508-692-9214
Email: jmoy@casc.com Email: jmoy@casc.com
This document expires in May 1996. This document expires in March 1997.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/