RFCs in HTML Format

RFC 1247

Network Working Group                                             J. Moy
Request for Comments: 1247                                 Proteon, Inc.
Obsoletes: RFC 1131                                            July 1991

                             OSPF Version 2

1. Introduction

This document is a specification of the Open Shortest Path First (OSPF)
internet routing protocol.  OSPF is classified as an Internal Gateway
Protocol (IGP).  This means that it distributes routing information
between routers belonging to a single Autonomous System.  The OSPF
protocol is based on SPF or link-state technology.  This is a departure

[Moy]                                                           [Page 1]

RFC 1247 OSPF Version 2 July 1991 from the Bellman-Ford base used by traditional internet routing protocols. The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force. It has been designed expressly for the internet environment, including explicit support for IP subnetting, TOS-based routing and the tagging of externally-derived routing information. OSPF also provides for the authentication of routing updates, and utilizes IP multicast when sending/receiving the updates. In addition, much work has been done to produce a protocol that responds quickly to topology changes, yet involves small amounts of routing protocol traffic. The author would like to thank Rob Coltun, Milo Medin, Mike Petry and the rest of the OSPF working group for the ideas and support they have given to this project. 1.1 Protocol overview OSPF routes IP packets based solely on the destination IP address and IP Type of Service found in the IP packet header. IP packets are routed "as is" -- they are not encapsulated in any further protocol headers as they transit the Autonomous System. OSPF is a dynamic routing protocol. It quickly detects topological changes in the AS (such as router interface failures) and calculates new loop-free routes after a period of convergence. This period of convergence is short and involves a minimum of routing traffic. In an SPF-based routing protocol, each router maintains a database describing the Autonomous System's topology. Each participating router has an identical database. Each individual piece of this database is a particular router's local state (e.g., the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the Autonomous System by flooding. All routers run the exact same algorithm, in parallel. From the topological database, each router constructs a tree of shortest paths with itself as root. This shortest-path tree gives the route to each destination in the Autonomous System. Externally derived routing information appears on the tree as leaves. OSPF calculates separate routes for each Type of Service (TOS). When several equal-cost routes to a destination exist, traffic is distributed equally among them. The cost of a route is described by a single dimensionless metric. OSPF allows sets of networks to be grouped together. Such a grouping is [Moy] [Page 2]
RFC 1247 OSPF Version 2 July 1991 called an area. The topology of an area is hidden from the rest of the Autonomous System. This information hiding enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area's own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network. OSPF enables the flexible configuration of IP subnets. Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (i.e., different masks). This is commonly referred to as variable length subnets. A packet is routed to the best (i.e., longest or most specific) match. Host routes are considered to be subnets whose masks are "all ones" (0xffffffff). All OSPF protocol exchanges are authenticated. This means that only trusted routers can participate in the Autonomous System's routing. A variety of authentication schemes can be used; a single authentication scheme is configured for each area. This enables some areas to use much stricter authentication than others. Externally derived routing data (e.g., routes learned from the Exterior Gateway Protocol (EGP)) is passed transparently throughout the Autonomous System. This externally derived data is kept separate from the OSPF protocol's link state data. Each external route can also be tagged by the advertising router, enabling the passing of additional information between routers on the boundaries of the Autonomous System. 1.2 Definitions of commonly used terms Here is a collection of definitions for terms that have a specific meaning to the protocol and that are used throughout the text. The reader unfamiliar with the Internet Protocol Suite is referred to [RS- 85-153] for an introduction to IP. Router A level three Internet Protocol packet switch. Formerly called a gateway in much of the IP literature. Autonomous System A group of routers exchanging routing information via a common routing protocol. Abbreviated as AS. Internal Gateway Protocol The routing protocol spoken by the routers belonging to an Autonomous system. Abbreviated as IGP. Each Autonomous System has [Moy] [Page 3]
RFC 1247 OSPF Version 2 July 1991 a single IGP. Different Autonomous Systems may be running different IGPs. Router ID A 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within an Autonomous System. Network In this paper, an IP network or subnet. It is possible for one physical network to be assigned multiple IP network/subnet numbers. We consider these to be separate networks. Point-to-point physical networks are an exception - they are considered a single network no matter how many (if any at all) IP network/subnet numbers are assigned to them. Network mask A 32-bit number indicating the range of IP addresses residing on a single IP network/subnet. This specification displays network masks as hexadecimal numbers. For example, the network mask for a class C IP network is displayed as 0xffffff00. Such a mask is often displayed elsewhere in the literature as Multi-access networks Those physical networks that support the attachment of multiple (more than two) routers. Each pair of routers on such a network is assumed to be able to communicate directly (e.g., multi-drop networks are excluded). Interface The connection between a router and one of its attached networks. An interface has state information associated with it, which is obtained from the underlying lower level protocols and the routing protocol itself. An interface to a network has associated with it a single IP address and mask (unless the network is an unnumbered point-to-point network). An interface is sometimes also referred to as a link. Neighboring routers Two routers that have interfaces to a common network. On multi- access networks, neighbors are dynamically discovered by OSPF's Hello Protocol. Adjacency A relationship formed between selected neighboring routers for the purpose of exchanging routing information. Not every pair of neighboring routers become adjacent. [Moy] [Page 4]
RFC 1247 OSPF Version 2 July 1991 Link state advertisement Describes to the local state of a router or network. This includes the state of the router's interfaces and adjacencies. Each link state advertisement is flooded throughout the routing domain. The collected link state advertisements of all routers and networks forms the protocol's topological database. Hello protocol The part of the OSPF protocol used to establish and maintain neighbor relationships. On multi-access networks the Hello protocol can also dynamically discover neighboring routers. Designated Router Each multi-access network that has at least two attached routers has a Designated Router. The Designated Router generates a link state advertisement for the multi-access network and has other special responsibilities in the running of the protocol. The Designated Router is elected by the Hello Protocol. The Designated Router concept enables a reduction in the number of adjacencies required on a multi-access network. This in turn reduces the amount of routing protocol traffic and the size of the topological database. Lower-level protocols The underlying network access protocols that provide services to the Internet Protocol and in turn the OSPF protocol. Examples of these are the X.25 packet and frame levels for PDNs, and the ethernet data link layer for ethernets. 1.3 Brief history of SPF-based routing technology OSPF is an SPF-based routing protocol. Such protocols are also referred to in the literature as link-state or distributed-database protocols. This section gives a brief description of the developments in SPF-based technology that have influenced the OSPF protocol. The first SPF-based routing protocol was developed for use in the ARPANET packet switching network. This protocol is described in [McQuillan]. It has formed the starting point for all other SPF-based protocols. The homogeneous Arpanet environment, i.e., single-vendor packet switches connected by synchronous serial lines, simplified the design and implementation of the original protocol. Modifications to this protocol were proposed in [Perlman]. These modifications dealt with increasing the fault tolerance of the routing protocol through, among other things, adding a checksum to the link [Moy] [Page 5]
RFC 1247 OSPF Version 2 July 1991 state advertisements (thereby detecting database corruption). The paper also included means for reducing the routing traffic overhead in an SPF-based protocol. This was accomplished by introducing mechanisms which enabled the interval between link state advertisements to be increased by an order of magnitude. An SPF-based algorithm has also been proposed for use as an ISO IS-IS routing protocol. This protocol is described in [DEC]. The protocol includes methods for data and routing traffic reduction when operating over broadcast networks. This is accomplished by election of a Designated Router for each broadcast network, which then originates a link state advertisement for the network. The OSPF subcommittee of the IETF has extended this work in developing the OSPF protocol. The Designated Router concept has been greatly enhanced to further reduce the amount of routing traffic required. Multicast capabilities are utilized for additional routing bandwidth reduction. An area routing scheme has been developed enabling information hiding/protection/reduction. Finally, the algorithm has been modified for efficient operation in the internet environment. 1.4 Organization of this document The first three sections of this specification give a general overview of the protocol's capabilities and functions. Sections 4-16 explain the protocol's mechanisms in detail. Packet formats, protocol constants, configuration items and required management statistics are specified in the appendices. Labels such as HelloInterval encountered in the text refer to protocol constants. They may or may not be configurable. The architectural constants are explained in Appendix B. The configurable constants are explained in Appendix C. The detailed specification of the protocol is presented in terms of data structures. This is done in order to make the explanation more precise. Implementations of the protocol are required to support the functionality described, but need not use the precise data structures that appear in this paper. 2. The Topological Database The database of the Autonomous System's topology describes a directed graph. The vertices of the graph consist of routers and networks. A graph edge connects two routers when they are attached via a physical point-to-point network. An edge connecting a router to a network [Moy] [Page 6]
RFC 1247 OSPF Version 2 July 1991 indicates that the router has an interface on the network. The vertices of the graph can be further typed according to function. Only some of these types carry transit data traffic; that is, traffic that is neither locally originated nor locally destined. Vertices that can carry transit traffic are indicated on the graph by having both incoming and outgoing edges. Vertex type Vertex name Transit? _____________________________________ 1 Router yes 2 Network yes 3 Stub network no Table 1: OSPF vertex types. OSPF supports the following types of physical networks: Point-to-point networks A network that joins a single pair of routers. A 56Kb serial line is an example of a point-to-point network. Broadcast networks Networks supporting many (more than two) attached routers, together with the capability to address a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these nets using OSPF's Hello Protocol. The Hello Protocol itself takes advantage of the broadcast capability. The protocol makes further use of multicast capabilities, if they exist. An ethernet is an example of a broadcast network. Non-broadcast networks Networks supporting many (more than two) routers, but having no broadcast capability. Neighboring routers are also discovered on these nets using OSPF's Hello Protocol. However, due to the lack of broadcast capability, some configuration information is necessary for the correct operation of the Hello Protocol. On these networks, OSPF protocol packets that are normally multicast need to be sent to each neighboring router, in turn. An X.25 Public Data Network (PDN) is an example of a non-broadcast network. [Moy] [Page 7]
RFC 1247 OSPF Version 2 July 1991 The neighborhood of each network node in the graph depends on whether the network has multi-access capabilities (either broadcast or non- broadcast) and, if so, the number of routers having an interface to the network. The three cases are depicted in Figure 1. Rectangles indicate routers. Circles and oblongs indicate multi-access networks. Router names are prefixed with the letters RT and network names with N. Router interface names are prefixed by I. Lines between routers indicate point-to-point networks. The left side of the figure shows a network with its connected routers, with the resulting graph shown on the right. Two routers joined by a point-to-point network are represented in the directed graph as being directly connected by a pair of edges, one in each direction. Interfaces to physical point-to-point networks need not be assigned IP addresses. Such a point-to-point network is called unnumbered. The graphical representation of point-to-point networks is designed so that unnumbered networks can be supported naturally. When interface addresses exist, they are modelled as stub routes. Note that each router would then have a stub connection to the other router's interface address (see Figure 1). When multiple routers are attached to a multi-access network, the directed graph shows all routers bidirectionally connected to the network vertex (again, see Figure 1). If only a single router is attached to a multi-access network, the network will appear in the directed graph as a stub connection. Each network (stub or transit) in the graph has an IP address and associated network mask. The mask indicates the number of nodes on the network. Hosts attached directly to routers (referred to as host routes) appear on the graph as stub networks. The network mask for a host route is always 0xffffffff, which indicates the presence of a single node. Figure 2 shows a sample map of an Autonomous System. The rectangle labelled H1 indicates a host, which has a SLIP connection to router RT12. Router RT12 is therefore advertising a host route. Lines between ______________________________________ (Figure not included in text version.) Figure 1: Network map components ______________________________________ [Moy] [Page 8]
RFC 1247 OSPF Version 2 July 1991 routers indicate physical point-to-point networks. The only point-to- point network that has been assigned interface addresses is the one joining routers RT6 and RT10. Routers RT5 and RT7 have EGP connections to other Autonomous Systems. A set of EGP-learned routes have been displayed for both of these routers. A cost is associated with the output side of each router interface. This cost is configurable by the system administrator. The lower the cost, the more likely the interface is to be used to forward data traffic. Costs are also associated with the externally derived routing data (e.g., the EGP-learned routes). The directed graph resulting from the map in Figure 2 is depicted in Figure 3. Arcs are labelled with the cost of the corresponding router output interface. Arcs having no labelled cost have a cost of 0. Note that arcs leading from networks to routers always have cost 0; they are significant nonetheless. Note also that the externally derived routing data appears on the graph as stubs. The topological database (or what has been referred to above as the directed graph) is pieced together from link state advertisements generated by the routers. The neighborhood of each transit vertex is represented in a single, separate link state advertisement. Figure 4 shows graphically the link state representation of the two kinds of transit vertices: routers and multi-access networks. Router RT12 has an ______________________________________ (Figure not included in text version.) Figure 2: A sample Autonomous System ______________________________________ __________________________________________ (Figures not included in text version.) Figure 3: The resulting directed graph Figure 4: Individual link state components __________________________________________ [Moy] [Page 9]
RFC 1247 OSPF Version 2 July 1991 interface to two broadcast networks and a SLIP line to a host. Network N6 is a broadcast network with three attached routers. The cost of all links from network N6 to its attached routers is 0. Note that the link state advertisement for network N6 is actually generated by one of the attached routers: the router that has been elected Designated Router for the network. 2.1 The shortest-path tree When no OSPF areas are configured, each router in the Autonomous System has an identical topological database, leading to an identical graphical representation. A router generates its routing table from this graph by calculating a tree of shortest paths with the router itself as root. Obviously, the shortest-path tree depends on the router doing the calculation. The shortest-path tree for router RT6 in our example is depicted in Figure 5. The tree gives the entire route to any destination network or host. However, only the next hop to the destination is used in the forwarding process. Note also that the best route to any router has also been calculated. For the processing of external data, we note the next hop and distance to any router advertising external routes. The resulting routing table for router RT6 is pictured in Table 2. Note that there is a separate route for each end of a numbered serial line (in this case, the serial line between routers RT6 and RT10). Routes to networks belonging to other AS'es (such as N12) appear as dashed lines on the shortest path tree in Figure 5. Use of this externally derived routing information is considered in the next section. ______________________________________ (Figure not included in text version.) Figure 5: The SPF tree for router RT6 ______________________________________ [Moy] [Page 10]
RFC 1247 OSPF Version 2 July 1991 Destination Next Hop Distance __________________________________ N1 RT3 10 N2 RT3 10 N3 RT3 7 N4 RT3 8 Ib * 7 Ia RT10 12 N6 RT10 8 N7 RT10 12 N8 RT10 10 N9 RT10 11 N10 RT10 13 N11 RT10 14 H1 RT10 21 __________________________________ RT5 RT5 6 RT7 RT10 8 Table 2: The portion of router RT6's routing table listing local destinations. 2.2 Use of external routing information After the tree is created the external routing information is examined. This external routing information may originate from another routing protocol such as EGP, or be statically configured (static routes). Default routes can also be included as part of the Autonomous System's external routing information. External routing information is flooded unaltered throughout the AS. In our example, all the routers in the Autonomous System know that router RT7 has two external routes, with metrics 2 and 9. OSPF supports two types of external metrics. Type 1 external metrics are equivalent to the link state metric. Type 2 external metrics are greater than the cost of any path internal to the AS. Use of Type 2 external metrics assumes that routing between AS'es is the major cost of routing a packet, and eliminates the need for conversion of external costs to internal link state metrics. Here is an example of Type 1 external metric processing. Suppose that the routers RT7 and RT5 in Figure 2 are advertising Type 1 external metrics. For each external route, the distance from Router RT6 is calculated as the sum of the external route's cost and the distance from [Moy] [Page 11]
RFC 1247 OSPF Version 2 July 1991 Router RT6 to the advertising router. For every external destination, the router advertising the shortest route is discovered, and the next hop to the advertising router becomes the next hop to the destination. Both Router RT5 and RT7 are advertising an external route to destination network N12. Router RT7 is preferred since it is advertising N12 at a distance of 10 (8+2) to Router RT6, which is better than router RT5's 14 (6+8). Table 3 shows the entries that are added to the routing table when external routes are examined: Destination Next Hop Distance __________________________________ N12 RT10 10 N13 RT5 14 N14 RT5 14 N15 RT10 17 Table 3: The portion of router RT6's routing table listing external destinations. Processing of Type 2 external metrics is simpler. The AS boundary router advertising the smallest external metric is chosen, regardless of the internal distance to the AS boundary router. Suppose in our example both router RT5 and router RT7 were advertising Type 2 external routes. Then all traffic destined for network N12 would be forwarded to router RT7, since 2 < 8. When several equal-cost Type 2 routes exist, the internal distance to the advertising routers is used to break the tie. Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1 external metrics always take precedence. This section has assumed that packets destined for external destinations are always routed through the advertising AS boundary router. This is not always desirable. For example, suppose in Figure 2 there is an additional router attached to network N6, called Router RTX. Suppose further that RTX does not participate in OSPF routing, but does exchange EGP information with the AS boundary router RT7. Then, router RT7 would end up advertising OSPF external routes for all destinations that should be routed to RTX. An extra hop will sometimes be introduced if packets for these destinations need always be routed first to router RT7 (the advertising router). To deal with this situation, the OSPF protocol allows an AS boundary [Moy] [Page 12]
RFC 1247 OSPF Version 2 July 1991 router to specify a "forwarding address" in its external advertisements. In the above example, Router RT7 would specify RTX's IP address as the "forwarding address" for all those destinations whose packets should be routed directly to RTX. The "forwarding address" has one other application. It enables routers in the Autonomous System's interior to function as "route servers". For example, in Figure 2 the router RT6 could become a route server, gaining external routing information through a combination of static configuration and external routing protocols. RT6 would then start advertising itself as an AS boundary router, and would originate a collection of OSPF external advertisements. In each external advertisement, router RT6 would specify the correct Autonomous System exit point to use for the destination through appropriate setting of the advertisement's "forwarding address" field. 2.3 Equal-cost multipath The above discussion has been simplified by considering only a single route to any destination. In reality, if multiple equal-cost routes to a destination exist, they are all discovered and used. This requires no conceptual changes to the algorithm, and its discussion is postponed until we consider the tree-building process in more detail. With equal cost multipath, a router potentially has several available next hops towards any given destination. 2.4 TOS-based routing OSPF can calculate a separate set of routes for each IP Type of Service. The IP TOS values are represented in OSPF exactly as they appear in the IP packet header. This means that, for any destination, there can potentially be multiple routing table entries, one for each IP TOS. Up to this point, all examples shown have assumed that routes do not vary on TOS. In order to differentiate routes based on TOS, separate interface costs can be configured for each TOS. For example, in Figure 2 there could be multiple costs (one for each TOS) listed for each interface. A cost for TOS 0 must always be specified. When interface costs vary based on TOS, a separate shortest path tree is calculated for each TOS (see Section 2.1). In addition, external costs can vary based on TOS. For example, in Figure 2 router RT7 could advertise a separate type 1 external metric for each TOS. Then, when calculating the TOS X distance to network N15 the cost of the shortest TOS X path to RT7 would be added to the TOS X cost advertised by RT7 [Moy] [Page 13]
RFC 1247 OSPF Version 2 July 1991 (see Section 2.2). All OSPF implementations must be capable of calculating routes based on TOS. However, OSPF routers can be configured to route all packets on the TOS 0 path (see Appendix C), eliminating the need to calculate non- zero TOS paths. This can be used to conserve routing table space and processing resources in the router. These TOS-0-only routers can be mixed with routers that do route based on TOS. TOS-0-only routers will be avoided as much as possible when forwarding traffic requesting a non-zero TOS. It may be the case that no path exists for some non-zero TOS, even if the router is calculating non-zero TOS paths. In that case, packets requesting that non-zero TOS are routed along the TOS 0 path (see Section 11.1). 3. Splitting the AS into Areas OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group, together with the routers having interfaces to any one of the included networks, is called an area. Each area runs a separate copy of the basic SPF routing algorithm. This means that each area has its own topological database and corresponding graph, as explained in the previous section. The topology of an area is invisible from the outside of the area. Conversely, routers internal to a given area know nothing of the detailed topology external to the area. This isolation of knowledge enables the protocol to effect a marked reduction in routing traffic as compared to treating the entire Autonomous System as a single SPF domain. With the introduction of areas, it is no longer true that all routers in the AS have an identical topological database. A router actually has a separate topological database for each area it is connected to. (Routers connected to multiple areas are called area border routers). Two routers belonging to the same area have, for that area, identical area topological databases. Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information. We discuss inter-area routing in Section 3.2. [Moy] [Page 14]
RFC 1247 OSPF Version 2 July 1991 3.1 The backbone of the Autonomous System The backbone consists of those networks not contained in any area, their attached routers, and those routers that belong to multiple areas. The backbone must be contiguous. It is possible to define areas in such a way that the backbone is no longer contiguous. In this case the system administrator must restore backbone connectivity by configuring virtual links. Virtual links can be configured between any two backbone routers that have an interface to a common non-backbone area. Virtual links belong to the backbone. The protocol treats two routers joined by a virtual link as if they were connected by an unnumbered point-to-point network. On the graph of the backbone, two such routers are joined by arcs whose costs are the intra-area distances between the two routers. The routing protocol traffic that flows along the virtual link uses intra-area routing only. The backbone is responsible for distributing routing information between areas. The backbone itself has all of the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing of the topology of the areas. 3.2 Inter-area routing When routing a packet between two areas the backbone is used. The path that the packet will travel can be broken up into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. The algorithm finds the set of such paths that have the smallest cost. Looking at this another way, inter-area routing can be pictured as forcing a star configuration on the Autonomous System, with the backbone as hub and and each of the areas as spokes. The topology of the backbone dictates the backbone paths used between areas. The topology of the backbone can be enhanced by adding virtual links. This gives the system administrator some control over the routes taken by inter-area traffic. The correct area border router to use as the packet exits the source area is chosen in exactly the same way routers advertising external routes are chosen. Each area border router in an area summarizes for the area its cost to all networks external to the area. After the SPF tree is calculated for the area, routes to all other networks are [Moy] [Page 15]
RFC 1247 OSPF Version 2 July 1991 calculated by examining the summaries of the area border routers. 3.3 Classification of routers Before the introduction of areas, the only OSPF routers having a specialized function were those advertising external routing information, such as router RT5 in Figure 2. When the AS is split into OSPF areas, the routers are further divided according to function into the following four overlapping categories: Internal routers A router with all directly connected networks belonging to the same area. Routers with only backbone interfaces also belong to this category. These routers run a single copy of the basic routing algorithm. Area border routers A router that attaches to multiple areas. Area border routers run multiple copies of the basic algorithm, one copy for each attached area and an additional copy for the backbone. Area border routers condense the topological information of their attached areas for distribution to the backbone. The backbone in turn distributes the information to the other areas. Backbone routers A router that has an interface to the backbone. This includes all routers that interface to more than one area (i.e., area border routers). However, backbone routers do not have to be area border routers. Routers with all interfaces connected to the backbone are considered to be internal routers. AS boundary routers A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router has AS external routes that are advertised throughout the Autonomous System. The path to each AS boundary router is known by every router in the AS. This classification is completely independent of the previous classifications: AS boundary routers may be internal or area border routers, and may or may not participate in the backbone. 3.4 A sample area configuration Figure 6 shows a sample area configuration. The first area consists of networks N1-N4, along with their attached routers RT1-RT4. The second area consists of networks N6-N8, along with their attached routers RT7, [Moy] [Page 16]
RFC 1247 OSPF Version 2 July 1991 RT8, RT10, RT11. The third area consists of networks N9-N11 and host H1, along with their attached routers RT9, RT11, RT12. The third area has been configured so that networks N9-N11 and host H1 will all be grouped into a single route, when advertised external to the area (see Section 3.5 for more details). In Figure 6, routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Finally as before, routers RT5 and RT7 are AS boundary routers. Figure 7 shows the resulting topological database for the Area 1. The figure completely describes that area's intra-area routing. It also shows the complete view of the internet for the two internal routers RT1 and RT2. It is the job of the area border routers, RT3 and RT4, to advertise into Area 1 the distances to all destinations external to the area. These are indicated in Figure 7 by the dashed stub routes. Also, RT3 and RT4 must advertise into Area 1 the location of the AS boundary routers RT5 and RT7. Finally, external advertisements from RT5 and RT7 are flooded throughout the entire AS, and in particular throughout Area 1. These advertisements are included in Area 1's database, and yield routes to networks N12-N15. Routers RT3 and RT4 must also summarize Area 1's topology for distribution to the backbone. Their backbone advertisements are shown in Table 4. These summaries show which networks are contained in Area 1 (i.e., networks N1-N4), and the distance to these networks from the routers RT3 and RT4 respectively. The topological database for the backbone is shown in Figure 8. The set of routers pictured are the backbone routers. Router RT11 is a backbone router because it belongs to two areas. In order to make the backbone connected, a virtual link has been configured between routers R10 and R11. __________________________________________ (Figure not included in text version.) Figure 6: A sample OSPF area configuration __________________________________________ [Moy] [Page 17]
RFC 1247 OSPF Version 2 July 1991 Network RT3 adv. RT4 adv. _____________________________ N1 4 4 N2 4 4 N3 1 1 N4 2 3 Table 4: Networks advertised to the backbone by routers RT3 and RT4. ______________________________________ (Figure not included in text version.) Figure 7: Area 1's Database Figure 8: The backbone database ______________________________________ Again, routers RT3, RT4, RT7, RT10 and RT11 are area border routers. As routers RT3 and RT4 did above, they have condensed the routing information of their attached areas for distribution via the backbone; these are the dashed stubs that appear in Figure 8. Remember that the third area has been configured to condense networks N9-N11 and Host H1 into a single route. This yields a single dashed line for networks N9- N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers; their externally derived information also appears on the graph in Figure 8 as stubs. The backbone enables the exchange of summary information between area border routers. Every area border router hears the area summaries from all other area border routers. It then forms a picture of the distance to all networks outside of its area by examining the collected advertisements, and adding in the backbone distance to each advertising router. Again using routers RT3 and RT4 as an example, the procedure goes as follows: They first calculate the SPF tree for the backbone. This gives the distances to all other area border routers. Also noted are the distances to networks (Ia and Ib) and AS boundary routers (RT5 and RT7) that belong to the backbone. This calculation is shown in Table 5. Next, by looking at the area summaries from these area border routers, RT3 and RT4 can determine the distance to all networks outside their [Moy] [Page 18]
RFC 1247 OSPF Version 2 July 1991 Area border dist from dist from router RT3 RT4 ______________________________________ to RT3 * 21 to RT4 22 * to RT7 20 14 to RT10 15 22 to RT11 18 25 ______________________________________ to Ia 20 27 to Ib 15 22 ______________________________________ to RT5 14 8 to RT7 20 14 Table 5: Backbone distances calculated by routers RT3 and RT4. area. These distances are then advertised 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. Note that Table 6 assumes that an area range has been configured for the backbone which groups I5 and I6 into a single advertisement. The information imported into Area 1 by routers RT3 and RT4 enables an internal router, such as RT1, to choose an area border router intelligently. Router RT1 would use RT4 for traffic to network N6, RT3 for traffic to network N10, and would load share between the two for Destination RT3 adv. RT4 adv. _________________________________ Ia,Ib 15 22 N6 16 15 N7 20 19 N8 18 18 N9-N11,H1 19 26 _________________________________ RT5 14 8 RT7 20 14 Table 6: Destinations advertised into Area 1 by routers RT3 and RT4. [Moy] [Page 19]
RFC 1247 OSPF Version 2 July 1991 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 external advertisements, 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 will cause the backbone to become disconnected. Configuring another virtual link between routers RT7 and RT10 will give the backbone more connectivity and more resistance to such failures. Also, a virtual link between RT7 and RT10 would allow a much shorter path between the third area (containing N9) and the router RT7, which is advertising a good route to external network N12. 3.5 IP subnetting support OSPF attaches an IP address mask to each advertised route. The mask indicates the range of addresses being described by the particular route. For example, a summary advertisement for the destination with a mask of 0xffff0000 actually is describing a single route to the collection of destinations - Similarly, host routes are always advertised with a mask of 0xffffffff, indicating the presence of only a single destination. Including the mask with each advertised destination enables the implementation of what is commonly referred to as variable-length subnet masks. This means that a single IP class A, B, or C network number can be broken up into many subnets of various sizes. For example, the network could be broken up into 64 variable-sized subnets: 16 subnets of size 4K, 16 subnets of size 256, and 32 subnets of size 8. Table 7 shows some of the resulting network addresses together with their masks: Network address IP address mask Subnet size _______________________________________________ 0xfffff000 4K 0xffffff00 256 0xfffffff8 8 Table 7: Some sample subnet sizes. [Moy] [Page 20]
RFC 1247 OSPF Version 2 July 1991 There are many possible ways of dividing up a class A, B, and C network into variable sized subnets. The precise procedure for doing so is beyond the scope of this specification. The specification however establishes the following guideline: When an IP packet is forwarded, it is always forwarded to the network that is the best match for the packet's destination. Here best match is synonymous with the longest or most specific match. For example, the default route with destination of and mask 0x00000000 is always a match for every IP destination. Yet it is always less specific than any other match. Subnet masks must be assigned so that the best match for any IP destination is unambiguous. The OSPF area concept is modelled after an IP subnetted network. OSPF areas have been loosely defined to be a collection of networks. In actuality, an OSPF area is specified to be a list of address ranges (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Many separate networks may then be contained in a single address range, just as a subnetted network is composed of many separate subnets. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of the route is the minimum cost to any of the networks falling in the specified range. For example, an IP subnetted network can be configured as a single OSPF area. In that case, the area would be defined as a single address range: a class A, B, or C network number along with its natural IP mask. Inside the area, any number of variable sized subnets could be defined. External to the area, a single route for the entire subnetted network would be distributed, hiding even the fact that the network is subnetted at all. The cost of this route is the minimum of the set of costs to the component subnets. 3.6 Supporting stub areas In some Autonomous Systems, the majority of the topological database may consist of external advertisements. An OSPF external advertisement is usually flooded throughout the entire AS. However, OSPF allows certain areas to be configured as "stub areas". External advertisements are not flooded into/throughout stub areas; routing to AS external destinations in these areas is based on a (per-area) default only. This reduces the topological database size, and therefore the memory requirements, for a stub area's internal routers. In order to take advantage of the OSPF stub area support, default routing must be used in the stub area. This is accomplished as follows. One or more of the stub area's area border routers must advertise a default route into the stub area via summary advertisements. These [Moy] [Page 21]
RFC 1247 OSPF Version 2 July 1991 summary defaults are flooded throughout the stub area, but no further. (For this reason these defaults pertain only to the particular stub area). These summary default routes will match any destination that is not explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations). An area can be configured as stub when there is a single exit point from the area, or when the choice of exit point need not be made on a per- external-destination basis. For example, area 3 in Figure 6 could be configured as a stub area, because all external traffic must travel though its single area border router RT11. If area 3 were configured as a stub, router RT11 would advertise a default route for distribution inside area 3 (in a summary advertisement), instead of flooding the external advertisements for networks N12-N15 into/throughout the area. The OSPF protocol ensures that all routers belonging to an area agree on whether the area has been configured as a stub. This guarantees that no confusion will arise in the flooding of external advertisements. There are a couple of restrictions on the use of stub areas. Virtual links cannot be configured through stub areas. In addition, AS boundary routers cannot be placed internal to stub areas. 3.7 Partitions of areas OSPF does not actively attempt to repair area partitions. When an area becomes partitioned, each component simply becomes a separate area. The backbone then performs routing between the new areas. Some destinations reachable via intra-area routing before the partition will now require inter-area routing. In the previous section, an area was described as a list of address ranges. Any particular address range must still be completely contained in a single component of the area partition. This has to do with the way the area contents are summarized to the backbone. Also, the backbone itself must not partition. If it does, parts of the Autonomous System will become unreachable. Backbone partitions can be repaired by configuring virtual links (see Section 15). Another way to think about area partitions is to look at the Autonomous System graph that was introduced in Section 2. Area IDs can be viewed as colors for the graph's edges.[1] Each edge of the graph connects to a network, or is itself a point-to-point network. In either case, the edge is colored with the network's Area ID. A group of edges, all having the same color, and interconnected by vertices, represents an area. If the topology of the Autonomous System [Moy] [Page 22]
RFC 1247 OSPF Version 2 July 1991 is intact, the graph will have several regions of color, each color being a distinct Area ID. When the AS topology changes, one of the areas may become partitioned. The graph of the AS will then have multiple regions of the same color (Area ID). The routing in the Autonomous System will continue to function as long as these regions of same color are connected by the single backbone region. [Moy] [Page 23]
RFC 1247 OSPF Version 2 July 1991 4. Functional Summary A separate copy of OSPF's basic routing algorithm runs in each area. Routers having interfaces to multiple areas run multiple copies of the algorithm. A brief summary of the routing algorithm follows. When a router starts, it first initializes the routing protocol data structures. The router then waits for indications from the lower-level protocols that its interfaces are functional. A router then uses the OSPF's Hello Protocol to acquire neighbors. The router sends Hello packets to its neighbors, and in turn receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending its Hello packets to the multicast address AllSPFRouters. On non-broadcast networks, some configuration information is necessary in order to discover neighbors. On all multi-access networks (broadcast or non-broadcast), the Hello Protocol also elects a Designated router for the network. The router will attempt to form adjacencies with some of its newly acquired neighbors. Topological databases are synchronized between pairs of adjacent routers. On multi-access networks, the Designated Router determines which routers should become adjacent. Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies. In particular, distribution of topological database updates proceeds along adjacencies. A router periodically advertises its state, which is also called link state. Link state is also advertised when a router's state changes. A router's adjacencies are reflected in the contents of its link state advertisements. This relationship between adjacencies and link state allows the protocol to detect dead routers in a timely fashion. Link state advertisements are flooded throughout the area. The flooding algorithm is reliable, ensuring that all routers in an area have exactly the same topological database. This database consists of the collection of link state advertisements received from each router belonging to the area. From this database each router calculates a shortest-path tree, with itself as root. This shortest-path tree in turn yields a routing table for the protocol. 4.1 Inter-area routing The previous section described the operation of the protocol within a single area. For intra-area routing, no other routing information is [Moy] [Page 24]
RFC 1247 OSPF Version 2 July 1991 pertinent. In order to be able to route to destinations outside of the area, the area border routers inject additional routing information into the area. This additional information is a distillation of the rest of the Autonomous System's topology. This distillation is accomplished as follows: Each area border router is by definition connected to the backbone. Each area border router summarizes the topology of its attached areas for transmission on the backbone, and hence to all other area border routers. A area border router then has complete topological information concerning the backbone, and the area summaries from each of the other area border routers. From this information, the router calculates paths to all destinations not contained in its attached areas. The router then advertises these paths to its attached areas. This enables the area's internal routers to pick the best exit router when forwarding traffic to destinations in other areas. 4.2 AS external routes Routers that have information regarding other Autonomous Systems can flood this information throughout the AS. This external routing information is distributed verbatim to every participating router. There is one exception: external routing information is not flooded into "stub" areas (see Section 3.6). To utilize external routing information, the path to all routers advertising external information must be known throughout the AS (excepting the stub areas). For that reason, the locations of these AS boundary routers are summarized by the (non-stub) area border routers. 4.3 Routing protocol packets The OSPF protocol runs directly over IP, using IP protocol 89. OSPF does not provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly is used. OSPF protocol packets have been designed so that large protocol packets can generally be split into several smaller protocol packets. This practice is recommended; IP fragmentation should be avoided whenever possible. Routing protocol packets should always be sent with the IP TOS field set to 0. If at all possible, routing protocol packets should be given preference over regular IP data traffic, both when being sent and received. As an aid to accomplishing this, OSPF protocol packets should have their IP precedence field set to the value Internetwork Control (see [RFC 791]). [Moy] [Page 25]
RFC 1247 OSPF Version 2 July 1991
RFC 1247 OSPF Version 2 July 1991 destinations belonging to one of the router's attached areas. Inter-area paths are paths to destinations in other OSPF areas. These are discovered through the examination of received summary link advertisements. AS external paths are paths to destinations external to the AS. These are detected through the examination of received AS external link advertisements. Cost The link state cost of the path to the destination. For all paths except type 2 external paths this describes the entire path's cost. For Type 2 external paths, this field describes the cost of the portion of the path internal to the AS. This cost is calculated as the sum of the costs of the path's constituent links. Type 2 cost Only valid for type 2 external paths. For these paths, this field indicates the cost of the path's external portion. This cost has been advertised by an AS boundary router, and is the most significant part of the total path cost. For example, an external type 2 path with type 2 cost of 5 is always preferred over a path with type 2 cost of 10, regardless of the cost of the two paths' internal components. Link State Origin Valid only for intra-area paths, this field indicates the link state advertisement (router links or network links) that directly references the destination. For example, if the destination is a transit network, this is the transit network's network links advertisement. If the destination is a stub network, this is the router links advertisement for the attached router. The advertisement is discovered during the shortest-path tree calculation (see Section 16.1). Multiple advertisements may reference the destination, however a tie-breaking scheme always reduces the choice to a single advertisement. This field is for informational purposes only. The advertisement could be used as a root for an SPF calculation when building a reverse path forwarding tree. This is beyond the scope of this specification. When multiple paths of equal path-type and cost exist to a destination (called elsewhere "equal-cost" paths), they are stored in a single routing table entry. Each one of the "equal-cost" paths is distinguished by the following fields: [Moy] [Page 77]
RFC 1247 OSPF Version 2 July 1991 Next hop The outgoing router interface to use when forwarding traffic to the destination. On multi-access networks, the next hop also includes the IP address of the next router (if any) in the path towards the destination. This next router will always be one of the adjacent neighbors. Advertising router Valid only for inter-area and AS external paths. This field indicates the Router ID of the router advertising the summary link or AS external link that led to this path. 11.1 Routing table lookup When an IP data packet is received, an OSPF router finds the routing table entry that best matches the packet's destination. This routing table entry then provides the outgoing interface and next hop router to use in forwarding the packet. This section describes the process of finding the best matching routing table entry. The process consists of a number of steps, wherein the collection of routing table entries is progressively pruned. In the end, the single routing table entry remaining is the called best match. Note that the steps described below may fail to produce a best match routing table entry (i.e., all existing routing table entries are pruned for some reason or another). In this case, the packet's IP destination is considered unreachable. Instead of being forwarded, the packet should be dropped and an ICMP destination unreachable message should be returned to the packet's source. (1) Select the complete set of "matching" routing table entries from the routing table. Each routing table entry describes a (set of) path(s) to a range of IP addresses. If the data packet's IP destination falls into an entry's range of IP addresses, the routing table entry is called a match. (It is quite likely that multiple entries will match the data packet. For example, a default route will match all packets.) (2) Suppose that the packet's IP destination falls into one of the router's configured area address ranges (see Section 3.5), and that the particular area address range is active. This means that there are one or more reachable (by intra-area paths) networks contained in the area address range. The packet's IP destination is then required to belong to one of these constituent networks. For this reason, only matching routing table entries with path-type of intra-area are considered (all others are pruned). If no such [Moy] [Page 78]
RFC 1247 OSPF Version 2 July 1991 matching entries exist, the destination is unreachable (see above). Otherwise, skip to step 4. (3) Reduce the set of matching entries to those having the most preferential path-type (see Section 11). OSPF has a four level hierarchy of paths. Intra-area paths are the most preferred, followed in order by inter-area, Type 1 external and Type 2 external paths. (4) Select the remaining routing table entry that provides the longest (most specific) match. Another way of saying this is to choose the remaining entry that specifies the narrowest range of IP addresses.[10] For example, the entry for the address/mask pair of (, 0xffffff00) is more specific than an entry for the pair (, 0xffff0000). The default route is the least specific match, since it matches all destinations. (5) At this point, there may still be multiple routing table entries remaining. Each routing entry will specify the same range of IP addresses, but a different IP Type of Service. Select the routing table entry whose TOS value matches the TOS found in the packet header. If there is no routing table entry for this TOS, select the routing table entry for TOS 0. In other words, packets requesting TOS X are routed along the TOS 0 path if a TOS X path does not exist. 11.2 Sample routing table, without areas Consider the Autonomous System pictured in Figure 2. No OSPF areas have been configured. A single metric is shown per outbound interface, indicating that routes will not vary based on TOS. The calculation router RT6's routing table proceeds as described in Section 2.1. The resulting routing table is shown in Table 12. Destination types are abbreviated: Network as "N", area border router as "BR" and AS boundary router as "ASBR". There are no instances of multiple equal-cost shortest paths in this example. Also, since there are no areas, there are no inter-area paths. Routers RT5 and RT7 are AS boundary routers. Intra-area routes have been calculated to routers RT5 and RT7. This allows external routes to be calculated to the destinations advertised by RT5 and RT7 (i.e., networks N12, N13, N14 and N15). It is assumed all AS external advertisements originated by RT5 and RT7 are advertising type 1 external metrics. This results in type 1 external paths being calculated to destinations N12-N15. [Moy] [Page 79]
RFC 1247 OSPF Version 2 July 1991
RFC 1247 OSPF Version 2 July 1991 | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Network Mask For Type 3 link state advertisements, this indicates the destination's IP network mask. For example, when advertising the location of a class A network the value 0xff000000 would be used. This field is not meaningful and must be zero for Type 4 link state advertisements. For each specified type of service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified. TOS The Type of Service that the following cost concerns. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. metric The cost of this route. Expressed in the same units as the interface costs in the router links advertisements. [Moy] [Page 161]
RFC 1247 OSPF Version 2 July 1991 A.4.5 AS external link advertisements AS external link advertisements are the Type 5 link state advertisements. These advertisements are originated by AS boundary routers. A separate advertisement is made for each destination (known to the router) which is external to the AS. For details concerning the construction of AS external link advertisements, see Section 12.4.3. AS external link advertisements usually describe a particular external destination. For these advertisements the Link State ID field specifies an IP network number. AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination ( and the Network Mask is set to Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described; if a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | [Moy] [Page 162]
RFC 1247 OSPF Version 2 July 1991 Network Mask The IP network mask for the advertised destination. For example, when advertising a class A network the mask 0xff000000 would be used. For each specified type of service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified. bit E The type of external metric. If bit E is set, the metric specified is a Type 2 external metric. This means the metric is considered larger than any link state path. If bit E is zero, the specified metric is a Type 1 external metric. This means that is is comparable directly (without translation) to the link state metric. Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to, data traffic will be forwarded instead to the advertisement's originator (i.e., the responsible AS boundary router). TOS The Type of Service that the following cost concerns. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. metric The cost of this route. Interpretation depends on the external type indication (bit E above). External Route Tag A 32-bit field attached to each external route. This is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of this specification. [Moy] [Page 163]
RFC 1247 OSPF Version 2 July 1991
RFC 1247 OSPF Version 2 July 1991 D. Required Statistics An OSPF implementation must provide a minimum set of statistics indicating the operational state of the protocol. These statistics must be accessible to the user; this will probably be accomplished through some sort of network management interface. It is hoped that these statistics will aid in the debugging of the implementation, and in the analysis of the protocol's performance. The statistics can be broken into two broad categories. The first consists of what we will call logging messages. These are messages produced in real time, with generally a single message produced as the result of a single protocol event. Such messages are also commonly referred to as traps. The second category will be referred to as cumulative statistics. These are counters whose value have collected over time, such as the count of link state retransmissions over the last hour. Also falling into this category are dumps of the various routing data structures. D.1 Logging messages A logging message should be produced on every significant protocol event. The major events are listed below. Most of these events indicate a topological change in the routing domain. However, some number of logging messages can be expected even when the routing domain remains intact for long periods of time. For example, link state originations will still happen due to the link state refresh timer firing. Any of the messages that refer to link state advertisements should print the area associated with the advertisement. There is no area associated with AS external link advertisements. The following list of logging messages indicate topological changes in the routing domain: T1 The state of a router interface changes. Interface state changes are documented in Section 9.3. In general, they will cause new link state advertisements to be originated. The logging message produced should include the interface's IP address (or other name), interface type (virtual link, etc.) and old and new state values (as documented in Section 9.1). [Moy] [Page 172]
RFC 1247 OSPF Version 2 July 1991 T2 The state of a neighbor changes. Neighbor state changes are documented in Section 10.3. The logging message produced should include the neighbor IP address, and old and new state values. T3 The (Backup) Designated Router has changed on one of the attached networks. See Section 9.4. The logging message produced should include the network IP address, and the old and new (Backup) Designated Routers. T4 The router is originating a new instance of a link state advertisement. The logging message produced should indicate the LS type, Link State ID and Advertising Router associated with the advertisement (see Section 12.4). T5 The router has received a new instance of a link state advertisement. The router receives these in Link State Update packets. This will cause recalculation of the routing table. The logging message produced should indicate the advertisement's LS type, Link State ID and Advertising Router. The message should also include the neighbor from whom the advertisement was received. T6 An entry in the routing table has changed (see Section 11). The logging message produced should indicate the Destination type, Destination ID, and the old and new paths to the destination. The following logging messages may indicate that there is a network configuration error: C1 A received OSPF packet is rejected due to errors in its IP/OSPF header. The reasons for rejection are documented in Section 8.2. They include OSPF checksum failure, authentication failure, and inability to match the source with an active OSPF neighbor. The logging message produced should include the IP source and destination addresses, the router ID in the OSPF header, and the reason for the rejection. C2 An incoming Hello packet is rejected due to mismatches between the Hello's parameters and those configured for the receiving interface (see Section 10.5). This indicates a configuration problem on the attached network. The logging message should include the Hello's source, the receiving interface, and the non-matching parameters. C3 An incoming Database Description packet, Link State Request Packet, Link State Acknowledgment Packet or Link State Update packet is rejected due to the source neighbor being in the wrong state (see Sections 10.6, 10.7, 13.7 , and 13 respectively). This can be [Moy] [Page 173]
RFC 1247 OSPF Version 2 July 1991 normal when the identity of the network's Designated Router changes, causing momentary disagreements over the validity of adjacencies. The logging message should include the source neighbor, its state, and the packet's type. C4 A Database Description packet has been retransmitted. This may mean that the value of RxmtInterval that has been configured for the associated interface is too small. The logging message should include the neighbor to whom the packet is being sent. The following messages can be caused by packet transmission errors, or software errors in an OSPF implementation: E1 The checksum in a received link state advertisement is incorrect. The advertisement is discarded (see Section 13). The logging message should include the advertisement's LS type, Link State ID and Advertising Router (which may be incorrect). The message should also include the neighbor from whom the advertisement was received. E2 During the aging process, it is discovered that one of the link state advertisements in the database has an incorrect checksum. This indicates memory corruption or a software error in the router itself. The router should be dumped and restarted. The following messages are an indication that a router has restarted, losing track of its previous LS sequence number. Should these messages continue, it may indicate the presence of duplicate Router IDs: R1 Two link state advertisements have been seen, whose LS type, Link State ID, Advertising Router and LS sequence number are the same, yet with differing LS checksums. These are considered to be different instances of the same advertisement. The instance with the larger checksum is accepted as more recent (see Section 12.1.7, 13.1). The logging message should include the LS type, Link State ID, Advertising Router, LS sequence number and the two differing checksums. R2 Two link state advertisements have been seen, whose LS type, Link State ID, Advertising Router, LS sequence number and LS checksum are the same, yet can be distinguished by their LS age fields. This means that one of the advertisement's LS age is MaxAge, or the two LS age fields differ by more than MaxAgeDiff. The logging message should include the LS type, Link State ID, Advertising Router, LS sequence number and the two differing ages. [Moy] [Page 174]
RFC 1247 OSPF Version 2 July 1991 R3 The router has received an instance of one of its self-originated advertisements, that is considered to be more recent. This forces the router to originate a new advertisement (see Section 13.4). The logging message should include the advertisement's LS type, Link State ID, and Advertising Router along with the neighbor from whom the advertisement was received. R4 An acknowledgment has been received for an instance of an advertisement that is not currently contained in the router's database (see Section 13.7). The logging message should detail the instance being acknowledged and the database copy (if any), along with the neighbor from whom the acknowledgment was received. R5 An advertisement has been received through the flooding procedure that is LESS recent the the router's current database copy (see Section 13). The logging message should include the received advertisement's LS type, Link State ID, Advertising Router, LS sequence number, LS age and LS checksum. Also, the message should display the neighbor from whom the advertisement was received. The following messages are indication of normal, yet infrequent protocol events. These messages will help in the interpretation of some of the above messages: N1 The Link state refresh timer has fired for one of the router's self-originated advertisements (see Section 12.4). A new instance of the advertisement must be originated. The message should include the advertisement's LS type, Link State ID and Advertising Router. N2 One of the advertisements in the router's link state database has aged to MaxAge (see Section 14). At this point, the advertisement is no longer included in the routing table calculation, and is reflooded. The message should list the advertisement's LS type, Link State ID and Advertising Router. N3 An advertisement of age MaxAge has been flushed from the router's database. This occurs after the advertisement has been acknowledged by all adjacent neighbors. The message should list the advertisement's LS type, Link State ID and Advertising Router. D.2 Cumulative statistics These statistics display collections of the routing data structures. They should be able to be obtained interactively, through some kind of network management facility. [Moy] [Page 175]
RFC 1247 OSPF Version 2 July 1991 All the following statistics displays, with the exception of the area list, routing table and the AS external links, are specific to a single area. As noted in Section 4, most OSPF protocol mechanisms work on each area separately. The following statistics displays should be available: (1) A list of all the areas attached to the router, along with the authentication type to use for the area, the number of router interfaces attaching to the area, and the total number of nets and routers belonging to the area. For example, consider the router RT3 pictured in Figure 15. It has interfaces to two separate areas, Area 1 and the backbone (Area 0). Table 20 then indicates that the backbone is using a simple password for authentication, and that Area 1 is not using any authentication. The number of nets includes IP networks, subnets, and hosts (this is the reason for 2 backbone nets -- they are the host routes corresponding to the serial line between backbone routers RT6 and RT10). Area ID # ifcs AuType # nets # routers ______________________________________________ 0 1 1 2 7 1 2 0 4 4 Table 20: Sample OSPF area display. (2) A list of all the router's interfaces to an area, along with their addresses, output cost, current state, the (Backup) Designated Router for the attached network, and the number of neighbors currently associated with the interface. Some number of these neighbors will have become adjacent, the number of these is noted in the display also. Again consider router RT3 in Figure 15. Table 21 below indicates that RT4 has been selected as Designated Router for network N3, and router RT1 has been selected as Backup. Adjacencies have been established to both of these routers. There are no routers besides RT3 attached to network N4, so it becomes DR, yet still advertises the network as a stub in its router links advertisements. [Moy] [Page 176]
RFC 1247 OSPF Version 2 July 1991 Ifc IP address state cost DR Backup # nbrs # adjs __________________________________________________________________________ DR other 1 3 2 DR 2 none 0 0 Table 21: Sample OSPF interface display. (3) The list of neighbors associated with a particular interface. Each neighbor's IP address, router ID, state, and the length of the three link state advertisement queues (see Section 10) to the neighbor is displayed. Suppose router RT4 is the Designated Router for network N3, and router RT1 is the Backup Designated router. Suppose also that the adjacency between router RT3 and RT1 has not yet fully formed. The display of router RT3's neighbors (associated with its interface to network N3) may then look like Table 22. The display indicates that RT3 and RT1 are still in the database exchange procedure, Router RT3 has more Database Description packets to send to RT1, and RT1 has at least one link state advertisement that RT3 doesn't. Also, there is a single link state advertisement that has been flooded, but not acknowledged, to each neighbor that participates in the flooding procedure (state >= Exchng). (In the following examples we assume that a router's Router ID is assigned to be its smallest IP interface address). Nbr IP address Router ID state LS rxmt len DB summ len LS req len ____________________________________________________________________________ Exchng 1 10 1 2-Way 0 0 0 Full 1 0 0 Table 22: Sample OSPF neighbor display. (4) A list of the area's link state database. This is the same in all of the routers attached to the area. It is composed of that area's router links, network links, and summary links advertisements. Also, the AS external link advertisements are a part of all the areas' databases. [Moy] [Page 177]
RFC 1247 OSPF Version 2 July 1991 The link state database for Area 1 in Figure 15 might look like Table 23 (compare this with Figure 7). Assume the the Designated Router for network N3 is router RT4, as above. Both routers RT3 and RT4 are originating summary link advertisements into Area 1, since they are area border routers. Routers RT5 and RT7 are AS external routers. Their location must be described in summary links advertisements. Also, their AS external link advertisements are flooded throughout the entire AS. Router RT3 can locate its self-originated advertisements by looking for its own router ID ( in advertisements' Advertising Router fields. The LS sequence number, LS age, and LS checksum fields indicate the advertisement's instance. Their values are stored in the advertisement's link state header; we have not bothered to make up values for the example. LS type Link State ID Advertising Router LS seq no LS age LS checksum _______________________________________________________________________________ 1 * * * 1 * * * 1 * * * 1 * * * _______________________________________________________________________________ 2 * * * _______________________________________________________________________________ 3 Ia,Ib * * * 3 N6 * * * 3 N7 * * * 3 N8 * * * 3 N9-N11,H1 * * * 3 Ia,Ib * * * 3 N6 * * * 3 N7 * * * 3 N8 * * * 3 N9-N11,H1 * * * 4 RT5 * * * 4 RT7 * * * 4 RT5 * * * 4 RT7 * * * _______________________________________________________________________________ 4 N12 RT5's ID * * * 4 N13 RT5's ID * * * 4 N14 RT5's ID * * * 4 N12 RT7's ID * * * [Moy] [Page 178]
RFC 1247 OSPF Version 2 July 1991 LS type Link State ID Advertising Router LS seq no LS age LS checksum _______________________________________________________________________________ 4 N15 RT7's ID * * * Table 23: Sample OSPF link state database display. (5) The contents of any particular link state advertisement. For example, a listing of the router links advertisement for Area 1, with LS type = 1 and Link State ID = is shown in Section 12.4.1. (6) A listing of the entire routing table. Several examples are shown in Section 11. The routing table is calculated from the combined databases of each attached area (see Section 16). It may be desirable to sort the routing table by Type of Service, or by destination, or a combination of the two. [Moy] [Page 179]
RFC 1247 OSPF Version 2 July 1991 E. Authentication All OSPF protocol exchanges are authenticated. The OSPF packet header (see Section A.3.1) includes an authentication type field, and 64-bits of data for use by the appropriate authentication scheme (determined by the type field). The authentication type is configurable on a per-area basis. Additional authentication data is configurable on a per-interface basis. For example, if an area uses a simple password scheme for authentication, a separate password may be configured for each network contained in the area. Authentication types 0 and 1 are defined by this specification. All other authentication types are reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is described below in Table 24. AuType Description _______________________________________________________________ 0 No authentication 1 Simple password All others Reserved for assignment by the IANA (iana@ISI.EDU) Table 24: OSPF authentication types. E.1 Autype 0 -- No authentication Use of this authentication type means that routing exchanges in the area are not authenticated. The 64-bit field in the OSPF header can contain anything; it is not examined on packet reception. E.2 Autype 1 -- Simple password Using this authentication type, a 64-bit field is configured on a per- network basis. All packets sent on a particular network must have this configured value in their OSPF header 64-bit authentication field. This essentially serves as a "clear" 64-bit password. This guards against routers inadvertently coming up in the area. They must first be configured with their attached networks' passwords before they can join the routing domain. [Moy] [Page 180]
RFC 1247 OSPF Version 2 July 1991 F. Version 1 differences This section documents the changes between OSPF version 1 and OSPF version 2. The impetus for these changes derives from comments received on RFC 1131 and recent field experience with the OSPF protocol. Unfortunately, the changes are not backward-compatible. For that reason, OSPF version 1 will not interoperate with OSPF version 2. However, the changes are small in scope and should not greatly affect any existing implementations. In addition, some of the proposed changes should enable future protocol additions to be made in a backward- compatible manner (see Section F.4). F.1 Protocol Enhancements The following enhancements were made to the OSPF protocol. F.1.1 Stub area support In many Autonomous Systems, the majority of the OSPF link state database consists of AS external advertisements. In these Autonomous Systems, some OSPF areas may be organized in such a way that external advertisements can be safely ignored, enabling a reduction of the area's database size. This applies to OSPF areas where there is only a single exit/entry that is used by all externally addressed packets, or to cases where some sub-optimality of external routing is acceptable. Therefore, an OSPF area configuration option has been added (see Sections 3.6 and C.2) allowing the import of external advertisements to be disabled for an area. When this option is enabled, no AS external advertisements will be flooded into the area (Sections 13, 13.3 and 10.3). Instead, within the area all data traffic to external destinations will follow a (per-area) default route. These areas are called "stub" areas. To implement this, all area border routers attached to stub areas will originate a default summary link advertisement for the area (Section 12.4.3). This will direct all internal routers to an area border router when forwarding externally addressed packets. In addition, to ensure that stub areas are configured consistently, an Options field has been added to OSPF Hello packets (Sections A.2 and A.3.2). A bit is reset in the Options field indicating that the attached area is a stub area (Section 9.5). A router will not accept a neighbor's hellos unless they both agree on the area's ability to process AS external advertisements (Section 10.5). In this way, a system administrator will be able to discover incorrectly configured routers, and data traffic will be routed around them (in order to avoid potential looping situations) until their [Moy] [Page 181]
RFC 1247 OSPF Version 2 July 1991 configuration can be repaired. F.1.2 Optional TOS support In OSPF there is conceptually a separate routing table for each TOS; the calculations detailed in steps 1-5 of Section 16 must be done separately for each TOS. (Note however that link and summary costs need not be specified separately for each TOS; costs for unspecified TOS values default to the cost of TOS 0). In version 1 of the OSPF specification, all OSPF routers were required to route based on TOS. However, producing a separate routing table for each TOS may prove costly, both in terms of memory and processor resources. For this reason, version 2 allows the system administrator to configure routers to calculate/use only a single routing table (the TOS 0 table). When this is done, some traffic may take non-optimal routes. But all packets will still be delivered, and routing will remain loop free (see Section 2.4). In order to avoid routing loops, a router (router X) using a single table must communicate this information to its peers. This is done by resetting the new TOS-capable bit in the router X's router links advertisement (Section 12.4.1). Then, when its peers perform the Dijkstra calculation (Section 16.1) for non-zero TOS values, they will omit router X from the calculation. In effect, an attempt will be made to bypass router X when forwarding non-zero TOS traffic. Summary link and AS external link advertisements can also indicate their non- availability for non-zero TOS traffic (Sections 12.4.3 and 12.4.4). The result may be that no route can be found for some non-zero value of TOS. When this happens, the packet is routed along the TOS 0 route instead (Section 11.1). It is still mandatory for all OSPF implementations to be able to construct separate routing tables for each TOS value, if desired by the system administrator. F.1.3 Preventing external extra-hops In some cases, version 1 of the OSPF specification will introduce extra-hops when calculating routes to external destinations. This is because it is implicit in the format of AS external advertisements that packets should be forwarded through the advertising router. However, consider the situation where multiple OSPF routers share a LAN with an external router (call it router Y) , and only one OSPF router (call it router X) exchanges routing information with Y. The OSPF routers on the [Moy] [Page 182]
RFC 1247 OSPF Version 2 July 1991 LAN other than X will forward packets destined for Y and beyond through X, generating an extra hop (see Section 2.2). To fix this, a new field has been added to AS external advertisements. This field (called the forwarding address) will indicate the router address to which packets should be forwarded (Section 12.4.4). In the above example, router X will put Y's IP address into this field. If the field is 0, packets are (as before) forwarded to the originator of the advertisement. A different forwarding address can be specified for each TOS value. Whenever possible, this new field should be set to 0. This is because setting it to an actual router address incurs additional cost during the routing table build process (Section 16.4). Besides preventing extra-hops, there are two other applications for this field. The first is for use by "route servers". Using the forwarding address, a router in the middle of the Autonomous System can gather external routing information and originate AS external advertisements that specify the correct exit route to use for each external destination (Section 2.2). The other application possibly enables the reduction of the number of AS external advertisements that need be imported. Suppose in the example at the beginning of this section that there are two routers (X and Z) exchanging EGP information with the non-OSPF router Y. It is then likely that both X and Z will originate the same set of external routes. Two AS external advertisements that specify the same (non-zero) forwarding address, destination and cost are obviously functionally equivalent, regardless of their originators (advertising routers). The OSPF specification dictates that the advertisement originated by the router with the largest Router ID will always be used. This allows the other router to flush its equivalent advertisement (Section 12.4.4). F.2 Corrected problems The following problems in OSPF version 1 have been corrected in version 2 F.2.1 LS sequence number space changes The LS sequence number space has been changed from version 1's lollipop shape to a linear sequence space (Section 12.1.6). Sequence numbers will now be compared as signed 32-bit integers. Link state advertisements having larger sequence numbers will be considered more recent. The sequence number space will still begin at (-N+1) (where N = [Moy] [Page 183]
RFC 1247 OSPF Version 2 July 1991 2**31). The value of -N remains reserved. The LS sequence number of successive instances of an advertisement will continue to be incremented until it reaches the maximum possible value: N-1. At this point, when a new instance of the advertisement must be originated (due either to topological change of the expiration of the LS refresh timer) the current instance must first be "prematurely aged". There will be a new section discussing premature aging (Section 14.1). This is a method for flushing a link state advertisement from the routing domain: the advertisement's age is set to MaxAge and advertisement is reflooded just as if it were a newly received advertisement. As soon as the new flooding is acknowledged by all of the router's adjacent neighbors, the advertisement is flushed from the database. Premature aging can also be used when, for example, a previously advertised external route is no longer reachable. In this circumstance, premature aging is preferable to the alternative, which is to originate a new advertisement for the destination specifying a metric of LSInfinity. A router may only prematurely age its own (self-originated) link state advertisements. These are the link state advertisements having the router's own OSPF router ID in the Advertising Router field. F.2.2 Flooding of unexpected MaxAge advertisements Version 1 of the OSPF omitted the handling of a special case in the flooding procedure: the reception of a MaxAge advertisement that has no database instance. A paragraph has been added to Section 13 to deal with this occurrence. Without this paragraph, retransmissions of MaxAge advertisements could possibly delay their being flushed from the routing domain. F.2.3 Virtual links and address ranges When summarizing information into a virtual link's transit area, version 2 of the OSPF specification prohibits the collapsing of multiple backbone IP networks/subnets into a single summary link. This restriction has been added to deal with certain anomalous OSPF area configurations. See Sections 15 and 12.4.3 for more information. [Moy] [Page 184]
RFC 1247 OSPF Version 2 July 1991 F.2.4 Routing table lookup explained When forwarding an IP data packet, a router looks up the packet's IP destination in the routing table. This determines the packet's next hop. A new section (Section 11.1) has been added describing the routing table lookup (instead of just specifying a "best match"). This section clarifies OSPF's four level routing hierarchy (i.e., intra-area, inter- area, external type 1 and external type 2 routes). It also specifies the effect of TOS on routing. F.2.5 Sending Link State Request packets OSPF Version 2 eases the restrictions on the sending of Link State Request packets. Link State Request packets can now be sent to a neighboring router before a complete set of Database Description packets have been exchanged. This enables a more efficient use of a router's memory resources; an OSPF version 2 implementation may limit the size of the neighbor Link state request lists. See Sections 10.9, 10.7 and 10.3 for more details. F.2.6 Changes to the Database description process The specification has been modified to ensure that, when two routers are synchronizing their databases during the Database Description process, none of the component link state advertisements can have their sequence numbers decrease. A link state advertisement's sequence number decreases when it is flushed from the routing domain via premature- aging, and then reoriginated with the smallest sequence number 0x80000001 (see Section 14.1). So the specification now dictates that an advertisement cannot be flushed from a router's database until both a) it no longer appears on any neighbor Link State Retransmission lists and b) none of the router's neighbors are in states Exchange or Loading. See Sections 13 (step 4c) and 14.1 for more details. In addition, a new step has been added to the flooding procedure (Section 13) in order to make the Database Description process more robust. This step detects when a neighbor lists one instance of an advertisement in its Database Description packets, but responds to Link State Request packets by sending another (earlier) instance. This behavior now causes the event BadLSReq to be generated, which restarts the Database Description process with the neighbor. In OSPF version 1, the neighbor event BadLSReq erroneously did not restart the Database Description process. [Moy] [Page 185]
RFC 1247 OSPF Version 2 July 1991 F.2.7 Receiving OSPF Hello packets The section detailing the receive processing of OSPF Hello packets (Section 10.5) has been modified to include the generation of the neighbor Backup Seen event. In addition, the section detailing the Designated Router election algorithm (Section 9.4) has been modified to include the algorithm's initial state. F.2.8 Network mask defined for default route The network mask for the default route, when it appears as the destination in either an AS external link advertisement or in a summary link advertisement, has been set to See Sections A.4.4 and A.4.5 for more details. F.2.9 Rate limit imposed on flooding When an advertisement is installed in the link state database, it is timestamped. The flooding procedure is then not allowed to install a new instance of the advertisement until MinLSInterval seconds have elapsed. This enforces a rate limit on the flooding procedure; a new instance can be flooded only once every MinLSInterval seconds. This guards against routers that disregard the limit on self-originated advertisements (already present in OSPF version 1) of one origination every MinLSInterval seconds. For more information, see Section 13. F.3 Packet format changes The following changes have been made to the format of OSPF packets and link state advertisements. Some of these changes were required to support the added functionality listed above. Other changes were made to further simplify the parsing of OSPF packets. F.3.1 Adding a Capability bitfield To support the new "stub area" and "optional TOS" features, a bitfield listing protocol capabilities has been added to the Hello packet, Database Description packet and all link state advertisements. When used in Hello packets, this allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to forward certain link state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link state advertisements allows routers to route traffic around reduced [Moy] [Page 186]
RFC 1247 OSPF Version 2 July 1991 functionality router, by excluding them from parts of the routing table calculation. See Section A.2 for more details. F.3.2 Packet simplification To simplify the format of Database Description packets and Link State Acknowledgment packets, their description of link state advertisements has been modified. Each advertisement is now be described by its 20- byte link state header (see Section A.4). This does not consume any additional space in the packets. The one additional piece of information that will be present is the LS length. However, this field need not be used when processing the Database Description and Link State Acknowledgment packets. F.3.3 Adding forwarding addresses to AS external advertisements As discussed in Section F.1.3, a forwarding address field has been added to the AS external advertisement. F.3.4 Labelling of virtual links Virtual links will be labelled as such in router links advertisements. This separates virtual links from unnumbered point-to-point links, allowing all backbone routers to discover whether any virtual links are in use. See Section 12.4.1 for more details. F.3.5 TOS costs ordered When a link state advertisement specifies a separate cost depending on TOS, these costs must be ordered by increasing TOS value. For example, the cost for TOS 16 must always follow the cost for TOS 8. F.3.6 OSPF's TOS encoding redefined The way that OSPF encodes TOS in its link state advertisements has been redefined in version 2. OSPF's encoding of the Delay (D), Throughput (T) and Reliability (R) TOS flags defined by [RFC 791] is described in Section 12.3. [Moy] [Page 187]
RFC 1247 OSPF Version 2 July 1991 F.4 Backward-compatibility provisions Additional functionality will probably be added to OSPF in the future. One example of this is a multicast routing capability, which is currently under development. In order to be able to add such features in a backward-compatible manner, the following provisions have been made in the OSPF specification. New capabilities will probably involve the introduction of new link state advertisements. If a router receives a link state advertisement of unknown type during the flooding procedure, the advertisement is simply ignored (Section 13. The router should not attempt to further flood the advertisement, nor acknowledge it. The advertisement should not be installed into the link state database. If the router receives an advertisement of unknown type during the Database Description process, this is an error (see Sections 10.6 and 10.3). The Database Description process is then restarted. There is also an Options field in both the Hello packets, Database Description packets and the link state advertisement headers. Unrecognized capabilities found in these places should be ignored, and should not affect the normal processing of protocol packets/link state advertisements (see Sections 10.5 and 10.6). Routers will originate their Hello packets, Database Description packets and link state advertisements with unrecognized capabilities set to 0 (see Sections 9.5, 10.8 and 12.1.2). [Moy] [Page 188]
RFC 1247 OSPF Version 2 July 1991 Security Considerations All OSPF protocol exchanges are authenticated. This is accomplished through authentication fields contained in the OSPF packet header. For more information, see Sections 8.1, 8.2, and Appendix E. Author's Address John Moy Proteon, Inc. 2 Technology Drive Westborough, MA 01581 Phone: (508) 898-2800 EMail: jmoy@proteon.com

Back to RFC index




Register domain name and transfer | Cheap webhosting service | Domain name registration