!!!!
`!!
`!!!
`
`Network Working Group J. Moy!
`Request for Comments: 1583 Proteon, Inc.!
`Obsoletes: 1247 March 1994!
`Category: Standards Track!
`
` OSPF Version 2!
`
`!
`
`Status of this Memo!
`
` This document specifies an Internet standards track protocol for the!
` Internet community, and requests discussion and suggestions for!
` improvements. Please refer to the current edition of the "Internet!
` Official Protocol Standards" (STD 1) for the standardization state!
` and status of this protocol. Distribution of this memo is!
` unlimited.!
`
`!A
`
`bstract!
`
`!
`
` This memo documents version 2 of the OSPF protocol. OSPF is a!
` link-state routing protocol. It is designed to be run internal to a!
` single Autonomous System. Each OSPF router maintains an identical!
` database describing the Autonomous System's topology. From this!
` database, a routing table is calculated by constructing a shortest-!
` path tree.!
`
`!
`
` OSPF recalculates routes quickly in the face of topological changes,!
` utilizing a minimum of routing protocol traffic. OSPF provides!
` support for equal-cost multipath. Separate routes can be calculated!
` for each IP Type of Service. An area routing capability is!
` provided, enabling an additional level of routing protection and a!
` reduction in routing protocol traffic. In addition, all OSPF!
` routing protocol exchanges are authenticated.!
`
`!
`
` OSPF Version 2 was originally documented in RFC 1247. The!
` differences between RFC 1247 and this memo are explained in Appendix!
` E. The differences consist of bug fixes and clarifications, and are!
` backward-compatible in nature. Implementations of RFC 1247 and of!
` this memo will interoperate.!
`
` Please send comments to ospf@gated.cornell.edu.!
`
`Moy [Page 1]!
`
`!
`
`!!!!!!!!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 1
`
`

`

`!R
`
`!!
`
`!
`
`Table of Contents!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 1 Introduction ........................................... 5!
` 1.1 Protocol Overview ...................................... 5!
` 1.2 Definitions of commonly used terms ..................... 6!
` 1.3 Brief history of link-state routing technology ......... 9!
` 1.4 Organization of this document .......................... 9!
` 2 The Topological Database .............................. 10!
` 2.1 The shortest-path tree ................................ 13!
` 2.2 Use of external routing information ................... 16!
` 2.3 Equal-cost multipath .................................. 20!
` 2.4 TOS-based routing ..................................... 20!
` 3 Splitting the AS into Areas ........................... 21!
` 3.1 The backbone of the Autonomous System ................. 22!
` 3.2 Inter-area routing .................................... 22!
` 3.3 Classification of routers ............................. 23!
` 3.4 A sample area configuration ........................... 24!
` 3.5 IP subnetting support ................................. 30!
` 3.6 Supporting stub areas ................................. 31!
` 3.7 Partitions of areas ................................... 32!
` 4 Functional Summary .................................... 34!
` 4.1 Inter-area routing .................................... 35!
` 4.2 AS external routes .................................... 35!
` 4.3 Routing protocol packets .............................. 35!
` 4.4 Basic implementation requirements ..................... 38!
` 4.5 Optional OSPF capabilities ............................ 39!
` 5 Protocol data structures .............................. 41!
` 6 The Area Data Structure ............................... 42!
` 7 Bringing Up Adjacencies ............................... 45!
` 7.1 The Hello Protocol .................................... 45!
` 7.2 The Synchronization of Databases ...................... 46!
` 7.3 The Designated Router ................................. 47!
` 7.4 The Backup Designated Router .......................... 48!
` 7.5 The graph of adjacencies .............................. 49!
` 8 Protocol Packet Processing ............................ 50!
` 8.1 Sending protocol packets .............................. 51!
` 8.2 Receiving protocol packets ............................ 53!
` 9 The Interface Data Structure .......................... 55!
` 9.1 Interface states ...................................... 58!
` 9.2 Events causing interface state changes ................ 61!
` 9.3 The Interface state machine ........................... 62!
` 9.4 Electing the Designated Router ........................ 65!
` 9.5 Sending Hello packets ................................. 67!
` 9.5.1 Sending Hello packets on non-broadcast networks ....... 68!
` 10 The Neighbor Data Structure ........................... 69!
` 10.1 Neighbor states ....................................... 72!
` 10.2 Events causing neighbor state changes ................. 75!
` 10.3 The Neighbor state machine ............................ 77!
`
`!!!
`
`Moy [Page 2]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 2
`
`

`

`!R
`
`!!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 10.4 Whether to become adjacent ............................ 83!
` 10.5 Receiving Hello Packets ............................... 83!
` 10.6 Receiving Database Description Packets ................ 86!
` 10.7 Receiving Link State Request Packets .................. 89!
` 10.8 Sending Database Description Packets .................. 89!
` 10.9 Sending Link State Request Packets .................... 90!
` 10.10 An Example ............................................ 91!
` 11 The Routing Table Structure ........................... 93!
` 11.1 Routing table lookup .................................. 96!
` 11.2 Sample routing table, without areas ................... 97!
` 11.3 Sample routing table, with areas ...................... 98!
` 12 Link State Advertisements ............................ 100!
` 12.1 The Link State Advertisement Header .................. 101!
` 12.1.1 LS age ............................................... 102!
` 12.1.2 Options .............................................. 102!
` 12.1.3 LS type .............................................. 103!
` 12.1.4 Link State ID ........................................ 103!
` 12.1.5 Advertising Router ................................... 105!
` 12.1.6 LS sequence number ................................... 105!
` 12.1.7 LS checksum .......................................... 106!
` 12.2 The link state database .............................. 107!
` 12.3 Representation of TOS ................................ 108!
` 12.4 Originating link state advertisements ................ 109!
` 12.4.1 Router links ......................................... 112!
` 12.4.2 Network links ........................................ 118!
` 12.4.3 Summary links ........................................ 120!
` 12.4.4 Originating summary links into stub areas ............ 123!
` 12.4.5 AS external links .................................... 124!
` 13 The Flooding Procedure ............................... 126!
` 13.1 Determining which link state is newer ................ 130!
` 13.2 Installing link state advertisements in the database . 130!
` 13.3 Next step in the flooding procedure .................. 131!
` 13.4 Receiving self-originated link state ................. 134!
` 13.5 Sending Link State Acknowledgment packets ............ 135!
` 13.6 Retransmitting link state advertisements ............. 136!
` 13.7 Receiving link state acknowledgments ................. 138!
` 14 Aging The Link State Database ........................ 139!
` 14.1 Premature aging of advertisements .................... 139!
` 15 Virtual Links ........................................ 140!
` 16 Calculation Of The Routing Table ..................... 142!
` 16.1 Calculating the shortest-path tree for an area ....... 143!
` 16.1.1 The next hop calculation ............................. 149!
` 16.2 Calculating the inter-area routes .................... 150!
` 16.3 Examining transit areas' summary links ............... 152!
` 16.4 Calculating AS external routes ....................... 154!
` 16.5 Incremental updates -- summary link advertisements ... 156!
` 16.6 Incremental updates -- AS external link advertisements 157!
` 16.7 Events generated as a result of routing table changes 157!
`
`!!!
`
`Moy [Page 3]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 3
`
`

`

`!R
`
`!!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 16.8 Equal-cost multipath ................................. 158!
` 16.9 Building the non-zero-TOS portion of the routing table 158!
` Footnotes ............................................ 161!
` References ........................................... 164!
` A OSPF data formats .................................... 166!
` A.1 Encapsulation of OSPF packets ........................ 166!
` A.2 The Options field .................................... 168!
` A.3 OSPF Packet Formats .................................. 170!
` A.3.1 The OSPF packet header ............................... 171!
` A.3.2 The Hello packet ..................................... 173!
` A.3.3 The Database Description packet ...................... 175!
` A.3.4 The Link State Request packet ........................ 177!
` A.3.5 The Link State Update packet ......................... 179!
` A.3.6 The Link State Acknowledgment packet ................. 181!
` A.4 Link state advertisement formats ..................... 183!
` A.4.1 The Link State Advertisement header .................. 184!
` A.4.2 Router links advertisements .......................... 186!
` A.4.3 Network links advertisements ......................... 190!
` A.4.4 Summary link advertisements .......................... 192!
` A.4.5 AS external link advertisements ...................... 194!
` B Architectural Constants .............................. 196!
` C Configurable Constants ............................... 198!
` C.1 Global parameters .................................... 198!
` C.2 Area parameters ...................................... 198!
` C.3 Router interface parameters .......................... 200!
` C.4 Virtual link parameters .............................. 202!
` C.5 Non-broadcast, multi-access network parameters ....... 203!
` C.6 Host route parameters ................................ 203!
` D Authentication ....................................... 205!
` D.1 AuType 0 -- No authentication ........................ 205!
` D.2 AuType 1 -- Simple password .......................... 205!
` E Differences from RFC 1247 ............................ 207!
` E.1 A fix for a problem with OSPF Virtual links .......... 207!
` E.2 Supporting supernetting and subnet 0 ................. 208!
` E.3 Obsoleting LSInfinity in router links advertisements . 209!
` E.4 TOS encoding updated ................................. 209!
` E.5 Summarizing routes into transit areas ................ 210!
` E.6 Summarizing routes into stub areas ................... 210!
` E.7 Flushing anomalous network links advertisements ...... 210!
` E.8 Required Statistics appendix deleted ................. 211!
` E.9 Other changes ........................................ 211!
` F. An algorithm for assigning Link State IDs ............ 213!
` Security Considerations .............................. 216!
` Author's Address ..................................... 216!
`
`!!!!!!!
`
`Moy [Page 4]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 4
`
`

`

`!R
`
`!!
`
`!
`
`1. Introduction!
`
`FC 1583 OSPF Version 2 March 1994!
`
` This document is a specification of the Open Shortest Path First!
` (OSPF) TCP/IP internet routing protocol. OSPF is classified as an!
` Interior Gateway Protocol (IGP). This means that it distributes!
` routing information between routers belonging to a single Autonomous!
` System. The OSPF protocol is based on link-state or SPF technology.!
` This is a departure from the Bellman-Ford base used by traditional!
` TCP/IP 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 TCP/IP 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 Fred Baker, Jeffrey Burgan, Rob!
` Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo!
` Medin, Kannan Varadhan 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 a link-state 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!
`
`Moy [Page 5]!
`
`!!!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 5
`
`

`

`!R
`
`!!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 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 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 subnetting. 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!
`
` This section provides definitions for terms that have a specific!
` meaning to the OSPF 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.!
`
`!!!!
`
`Moy [Page 6]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 6
`
`

`

`!R
`
`!!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 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.!
`
`!
`
`!
`
` Interior Gateway Protocol!
` The routing protocol spoken by the routers belonging to an!
` Autonomous system. Abbreviated as IGP. Each Autonomous!
` System has a single IGP. Separate 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 memo, an IP network/subnet/supernet. 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/supernet. 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 255.255.255.0.!
`
`!
`
` 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!
`
`!!!
`
`Moy [Page 7]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 7
`
`

`

`!R
`
`!!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 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.!
`
`!
`
` Link state advertisement!
` Describes 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 X.25 PDNs, and the ethernet data link layer for!
` ethernets.!
`
`!!!!!
`
`Moy [Page 8]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 8
`
`

`

`!R
`
`FC 1583 OSPF Version 2 March 1994!
`
` 1.3. Brief history of link-state routing technology!
`
`!!
`
`!
`
` OSPF is a link state routing protocol. Such protocols are also!
` referred to in the literature as SPF-based or distributed-!
` database protocols. This section gives a brief description of!
` the developments in link-state technology that have influenced!
` the OSPF protocol.!
`
`!
`
` The first link-state 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 link-state 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 state advertisements (thereby detecting!
` database corruption). The paper also included means for!
` reducing the routing traffic overhead in a link-state protocol.!
` This was accomplished by introducing mechanisms which enabled!
` the interval between link state advertisement originations to be!
` increased by an order of magnitude.!
`
`!
`
` A link-state 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 TCP/IP internets.!
`
`!!
`!!!
`
`!
`
` 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!
`
`Moy [Page 9]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 9
`
`

`

`!R
`
`!!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 4-16 explain the protocol's mechanisms in detail. Packet!
` formats, protocol constants and configuration items 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 memo.!
`
`!!
`
`!
`
`2. The Topological Database!
`
` The Autonomous System's topological database 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 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.!
`
`Moy [Page 10]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 10
`
`

`

`!R
`
`!!
`
`FC 1583 OSPF Version 2 March 1994!
`
` 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.!
`
`!!
`
` 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 the letter N. Router interface names are!
` prefixed by the letter 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!
`
`!!!
`
`Moy [Page 11]!
`
`CISCO Exhibit 1013
`Cisco v. Bockstar
`Trial IPR2014 - 11
`
`

`

`!R
`
`FC 1583 OSPF Version 2 March 1994!
`
` **FROM**!
` +---+ +---+!
` |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 |!
` +---+ +---+ * ------------------------!
` | N2 | * RT3| | | | | X |!
` +----------------------+ T RT4| | | | | X |!
` | | O RT5| | | | | X |!
` +---+ +---+ * RT6| | | | | X |!
` |RT5| |RT6| * N2| X | X | X | X | |!
` +---+ +---+!
`
`!
`
` Multi-access networks!
`
`!
`
` **FROM**!
` +---+ *!
` |RT7|