OSPF working group M.Thomas Internet Draft M.J.Reed Intended status: Experimental University of Essex Expires: November 6, 2010 May 6, 2010 ospf-lite draft-thomas-reed-ospf-lite-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 6, 2010. Thomas Reed Expires November 6, 2010 [Page 1] Internet-Draft ospf-lite May 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo documents what needs to be removed and added to OSPF [RFC2328] to create a working implementation of the experimental protocol ospf- lite. ospf-lite runs over TCP and UDP ports 8899. ospf-lite has been designed to provide a simpler version of the OSPF protocol. A router running ospf-lite requires little configuration. Many of the Protocol complexities have been removed. Areas are not implemented and Designated Router functionality has been removed from the protocol. In almost every case with these removals the protocol is made more scalable. ospf-lite will run over non fully meshed NBMA clouds without explicit configuration. ospf-lite contains support for External LSA's and opaque LSA's. The protocol removes the support of LSA's type 2,3,4,7 and the DR function. Promiscuous hellos are introduced and a unified interface link type replaces existing link types. This work is intended to keep pace with the vast increases in processor performance, memory size and link capacity since OSPF was originally conceived. Where further details are required the authors refer the reader to [RFC 2328]. Please send comments to mrthom@essex.ac.uk Thomas Reed Expires November 6, 2010 [Page 2] Internet-Draft ospf-lite May 2010 Table of Contents 1. ACKNOWLEGEMENTS.............................................4 2. Introduction................................................4 3. TCP/UDP port numbers.........................................5 3.1. IP ADDRESSING..........................................5 4. NEIGHBOR ADJACENCIES.........................................6 5. HELLO PROTOCOL differences...................................6 5.1. Introduction...........................................6 5.2. Difference 1: Promiscuous Hellos (new event 'helloReferenced')..........................................6 5.3. Difference 2: Change to IP Unicast addressing on receipt of event: 'helloReceived' [ref2328] or 'helloReferenced'.........7 5.4. Observation 1: TWO-WAY always leads to EXSTART...........8 5.5. Observation 2: Router LSA 1 rebuilt to reflect 'helloReceived'.............................................8 6. Unified link types..........................................8 6.1. EXAMPLE ospf-lite-stub /ospf-lite-transit link types.....9 7. LSA STUCTURE...............................................11 8. OSPF-lite operation on non-broadcast multi-access networks...13 8.1. NBMA NETWORK EXAMPLE with LSA's........................13 9. MANUAL NEIGHBOR /IPSEC MODE.................................16 10. EXAMPLE Router LSA's.......................................17 10.1. Router RT3's LSA......................................17 11. Security Considerations....................................19 12. IANA Considerations........................................19 13. References................................................19 13.1. Normative References..................................19 13.2. Informative References................................19 Appendix A. OSPF V2 Packets....................................20 A.1. Encapsulation of OSPF-lite packets.....................20 A.2. The Options field......................................20 A.3. OSPF-lite Packet Formats...............................20 A.3.1. The OSPF-lite packet header: As OSPF V2 except:....21 A.3.2. The Hello packet: Differences listed below.........21 A.3.3. The Database Description packet below: As OSPF V2..22 A.3.4. The Link State Request packet: As OSPF V2..........23 A.3.5. The Link State Update packet: As OSPF V2..........24 A.3.6. The Link State Acknowledgments are not supported...24 A.4. LSA formats...........................................24 A.4.1. The LSA header: As OSPF V2 with restricted LSA types24 A.4.2. Router-LSAs : As OSPF V2 with restricted Link-Types.25 A.4.3. N/A..............................................26 A.4.4. N/A..............................................26 A.4.5. AS-external-LSAs: As OSPF V2......................26 Appendix B. Note on [RFC2328] Database Description.............28 Thomas Reed Expires November 6, 2010 [Page 3] Internet-Draft ospf-lite May 2010 1. ACKNOWLEGEMENTS Thanks to the original authors of OSPF V2. The extra 'OSPF-lite-stub' host route induced by a NBMA Network Type in OSPF-lite is based in principle and operation on work done on the OSPF Version 2, Point-to-MultiPoint interface by Fred Baker. The OSPF-lite Cryptographic Authentication option is reused from RFC2328 and RFC5709 in entirety and all credit goes to the original authors. 2. Introduction 1.) ospf-lite runs over tcp / udp port 8899. 2.) The Hello protocol has been re-worked, in order to overcome non fully meshed NBMA networks (see Section 3.0) 3.) Removal of Designated Router /BDR LSA type 2 and all associated functions. 4.) A Unified way to handle today's differing Network Types. This decouples the underlying technology from the protocol. ospf-lite-stub (Type 8) and ospf-lite-transit (Type 9) replace all of the previously defined network linkTypes. This has meant that point- to-point interfaces have been completely re-worked and simplified along with all of the other Interface types. 5.) Removal of areas and associated LSA's, types 3,4, and 7. LSA-3,4 and 7 have been removed from the protocol. Modern routers are able to process much larger graphs than today's networks can build. ospf-lite allows the router to 'roam' throughout the AS without needing reconfiguring. Shielding an AS from Internet routes can be accomplished by running multiple smaller AS's of the protocol and redistributing selected routes. OSPF-lite fully supports the use of external LSAs. 6.) Automatic NBMA support is achieved 7.) Manual neighbors neighbor configuration /IPSEC mode. Thomas Reed Expires November 6, 2010 [Page 4] Internet-Draft ospf-lite May 2010 8.) LS Acknowlegements and associated processing and state removed. 3. TCP/UDP port numbers The OSPF-lite protocol runs over both tcp and udp port 8899. IANA has reserved these ports for the exclusive use of ospf-lite. The Hello protocol: UDP port 8899. Database Description: TCP port 8899 Link State Updates: TCP port 8899 Link State Requests: TCP port 8899 Link State Acknowledgements: packet type not supported 3.1. IP ADDRESSING ALLSPFRouters; (224.0.0.5) is used initially by the hello protocol. On receipt of a hello on the network, the destination IP address of hello packets migrates to the received or referenced neighbors IP unicast address(see section 5). The majority of OSPF-lite packets are sent as IP unicasts. i.e., sent directly to the neighbors IP addres. This is true for Database Description packets, LSRequests, and LS Updates. PACKET STRUCTURE Inside the TCP port ospf-lite packets follow much of the same structure and design as OSPF V2 packets. COMMON HEADER: All OSPF-lite protocol packets share a common OSPF v2 protocol header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version 2 | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID (must be 0.0.0.0 for OSPF-lite) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thomas Reed Expires November 6, 2010 [Page 5] Internet-Draft ospf-lite May 2010 | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a.) Version number 2 is used with ospf-lite b.) Area id field must be zero for ospf-lite The OSPF-lite supported packet types are listed below in Table 1. Type Packet name Protocol 1 Hello UDP 2 Database Description TCP 3 Link State Request TCP 4 Link State Update TCP Note: type 5 (Link State Acknowledgment )is not supported Table 1: OSPF-lite supported packet types. For a comparison of ospf-lite and OSPF V2 packet details see appendix A of this memo. 4. NEIGHBOR ADJACENCIES ALL directly connected neighboring routers (those that have interfaces to a common network) in OSPF-lite should achieve full adjacency. This is due to the removal of the DR function LSA and associated operations. 5. HELLO PROTOCOL differences 5.1. Introduction ospf-lite Hellos start by using the multicast address AllSPFRouters and UDP port 8899. All local neighbors are always listed in the packet. Note: IPSEC mode uses manual configured IP unicast neighbor address for all hello packets and does not make use of promiscuous hellos. 5.2. Difference 1: Promiscuous Hellos (new event 'helloReferenced') Imagine RouterA receives a hello from router B. Inside Router B's hello is information about a third RouterC (clearly on the same local network). This is referred to as a new event 'helloReferenced' Thomas Reed Expires November 6, 2010 [Page 6] Internet-Draft ospf-lite May 2010 With ospf-lite RouterA will now consider RouterC a neighbor in 'init' state [RFC2328], and unicast directly to RouterC to try and achieve two way communication. This occurs even if RouterA has not received the hello directly from RouterC. The operation of 'helloReferenced' in ospf-lite is referred to as promiscuous hellos and helps to overcome NBMA issues. 5.3. Difference 2: Change to IP Unicast addressing on receipt of event: 'helloReceived' [ref2328] or 'helloReferenced'. This occurs for both directly received hellos and 'helloReferenced' routers. ie RouterA changes the Hello's ALLSPFRouters dest address for router B and router C's unicast IP address continuing to use UDP 8899. EXAMPLE STATE CHANGES: +----+ |Down| NEIGHBOR INITIAL STATE +----+ | | EVENT: HelloRecieved | OR | NEW EVENT: HelloReferenced: | (neighbor referenced | in a received Hello) | +----+ |Init| NEIGHBOR STATE AFTER EVENT +----+ figure 1.0 State(s): Down Event: HelloReceived OR HelloReferenced New state: Init *New Action: 1.) Create new neighbour structure for any new referenced or received neighbour. The initial state of a newly created neighbor is this scenario is Init. *New Action: 2.) Hello packets are now unicast to all neighbours listed in an effort to achieve two-way communication, and list ALL neighbours (for the specific attached network) in each Hello packet sent out of the interface. Thomas Reed Expires November 6, 2010 [Page 7] Internet-Draft ospf-lite May 2010 Action: 3.) Start the Inactivity Timer for the neighbor from which the Hello was received. If it fires later, it will indicate that the neighbor is dead. 5.4. Observation 1: TWO-WAY always leads to EXSTART. It can be noted that with the removal of the Designated Router function, the neighbour state of TWO-WAY will always lead to EXSTART. 5.5. Observation 2: Router LSA 1 rebuilt to reflect 'helloReceived' Finally it is worth noting that as a neighbour achieves TWO- WAY/EXSTART the Router will rebuild the Router LSA to reflect the change in the new ospf-lite link types. 6. Unified link types The operation of OSPF-lite-stub and OSPF-lite-transit All networks begin being advertised with a link type of ospf-lite- stub (8) in the router type 1 LSA, and migrate to OSPF-lite-transit (9) if another OSPF-lite router is operating and advertising on the same network. REASON: With the new mechanism: If Router1 has advertised a connected network as a stub network, and a second remote router2 has been misconfigured to advertise that it is attached to the same network as Router1, then Router1 will not receive the Hello directly from Router2. Router1 will then not migrate the network type in the Router LSA from type stub to type transit. A third remote router3 can see that both routers 1 and 2 are advertising the same stub network, and know that there is a misconfiguration. If Router1 and Router2 were on the same network and functioning properly then the link type would be reflected in their router LSA's as ospf-lite-transit. The other routers in the AS therefore do not connect the routers 1 and 2 together in the database. If two PAIRS of routers are BOTH independently misconfigured with the same error it is possible to break this safety mechanism. Point-to-point networks Thomas Reed Expires November 6, 2010 [Page 8] Internet-Draft ospf-lite May 2010 These operate as stated above. Firstly a point-to-point network will being advertised as an ospf-lite-stub network in the router LSA, and migrate to an ospf-lite-transit network on receipt of a successful hello from the router on the other end of the point-to-point link. In this way a P2P line is handled in the same way as 2 routers on a broadcast network. This is significantly different to the way OSPF [RFC2328] describes P2P networks. 6.1. EXAMPLE ospf-lite-stub /ospf-lite-transit link types Both OSPF-lite-stub and OSPF-lite-transit are depicted below in figure 1.1 to figure 1.4 Thomas Reed Expires November 6, 2010 [Page 9] Internet-Draft ospf-lite May 2010 +---+ N1 |RT1|------ RT1 Router LSA: +---+ cost3 N1, cost 3 type 8 Physical point-to-point networks (type 8 ospf-lite-stub) figure 1.1 3 4 RT1 Router LSA: +---+ N1 +---+ N1, cost 3 type 9 |RT1|------|RT2| +---+ +---+ RT2 Router LSA: N1, cost 4 type Physical point-to-point networks (type 9 OSPF-lite-transit) figure 1.2 +---+ |RT7| RT1 Router LSA: +---+ N1, cost 4 type 8 | 4 +----------+ N1 Single Router on Ethernet (type 8 OSPF-lite-stub) figure 1.3 +---+ +---+ RT3 Router LSA: |RT3| |RT4| N1, cost 5 type 9 +---+ +---+ 5 | N1 5 | RT4 Router LSA: +----------------------+ N1, cost 5 type 9 5 | 5 | +---+ +---+ RT5 Router LSA: |RT5| |RT6| N1, cost 5 type 9 +---+ +---+ RT6 Router LSA: N1, cost 5 type 9 Broadcast or NBMA networks figure 1.4 OSPF-lite-stub example Figures 1.1 and 1.3 show an example of an OSPF-lite-stub network. This is a network with only one attached router. In this case, the network appears on the end of a stub connection in the link-state Thomas Reed Expires November 6, 2010 [Page 10] Internet-Draft ospf-lite May 2010 database's graph. If a directly connected router appears sending a router LSA 1 with this network advertised, then this link type would change immediately to OSPF-lite-transit (Link type 9). 7. LSA STUCTURE Each LSA begins with the standard OSPF V2 20-byte header [RCF2328], which is repeated for convenience below and in Appendix A of this memo. 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 | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valid LSA types include: 1 (router), 5 (Eternal LSA), 9,10,11 (Opaque) LSA 1 Router-LSA Thomas Reed Expires November 6, 2010 [Page 11] Internet-Draft ospf-lite May 2010 LSA Cont.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | bit-V: Virtual links not supported in ospf-lite MUST be set to 0 bit-E: When set, the router is sending LSA 5 External LSA's bit-B: Not supported in ospf-lite. Must be set to zero. Type: In OSPF-lite this can be OSPF-lite-stub (type 8), or OSPF-lite- transit (type 9). Note: If the original underlying type was NBMA. Then the router adds an EXTRA link into the Router LSA of type OSPF-lite-stub. This is a link to the specific 32-bit IP address of the NBMA interface. See section 8 NBMA. Link ID: In OSPF-lite this is ALWAYS set to the IP address of the Interface connected. Link Data: This value with OSPF-lite no longer depends on the link's Type field. The value of this field is the Mask of the Interface IP address. The exception to this rule is for the additional link added to the Router LSA for NBMA networks. This link has a full 32-bit mask in the Link Data field Note: IP Unnumbered is not supported with ospf-lite Thomas Reed Expires November 6, 2010 [Page 12] Internet-Draft ospf-lite May 2010 SUMMARY OF ROUTER LSA FIELDS Physical Type Link type Description Link ID / Link Data Point-to-point: 8 or 9 OSPF-lite-stub/transit Intf IP / net mask Broadcast: 8 or 9 OSPF-lite-stub/transit Intf IP / net mask NBMA: Main link 8 or 9 OSPF-lite-stub/transit Intf IP / net mask ADD link 8 OSPF-lite-stub Intf IP / HOST mask Table 2: Link ID and descriptions in the OSPF-lite router-LSA. 8. OSPF-lite operation on non-broadcast multi-access networks As outlined in table 2, NBMA networks are a slight exception: In addition to the standard ospf-lite-stub/transit mechanism: 1.) OSPF-lite sees that the network is NBMA, from inspection of the MIB If database: 2.) An EXTRA link of type OSPF-lite-stub is introduced into the router LSA. This link includes the full 32-bit IP address of the interface on the network, with a full 32 bit mask. The additional 32-bit link introduced into the Router LSA ensures that non fully meshed NBMA neighbor routers can communicate on a shared network via routing. As the packets are sourced from and destined to the same network, the neighbor relationships can be formed even if the packets are forwarded via a third party router. Comment: Preloading these 32 bit routes to the routing table during processing would predispose fast resolution to the problem of non fuly meshed NBMA networks. 8.1. NBMA NETWORK EXAMPLE with LSA's Figure 2.0 shows an example Frame Relay network with three attached routers. The routers are not fully meshed. There is no PVC between RT102 and RT103. All of the routers are on the same IP subnetwork. For data to be passed between RT102 and RT103, there should be 32-bit host routes in RT101, RT102 and RT103. OSPF-lite adds an extra link to each Routers LSA 1, of type OSPF-lite-stub. This link contains the 32-bit IP address of the connected interface. Thomas Reed Expires November 6, 2010 [Page 13] Internet-Draft ospf-lite May 2010 +-----+ +-----+ |RT101| |RT102| +-----+ +-----+ 3 *|* * /3 Interface 1.1.1.1 /24 *|* * /Interface 1.1.1.2 /24 link N21 1.1.1.1 /32 *|* * / link N22 1.1.1.2 /32 *|* * / PVC1 *|* PVC2 * / *|* * / *|* * / *|* * / * | * * / * | * * * / * __|______ /___ * ------------- * | (NBMA) | * | 1.1.1.0 /24 | * -------------_ * | * | * | * | * | link N23 1.1.1.3 /32 * 3| Interface 1.1.1.3 /24 +-----+ |RT103| +-----+ Figure 2.0 All routers will become fully adjacent with each other. ; RT101's router-LSA for AS LS age = 0 ;always true on origination Options = (E-bit set) ;Mandatory with OSPF-lite LS type = 1 ;indicates router-LSA Link State ID = 1.1.1.0 ;RT101's Router ID Advertising Router = 1.1.1.1 ;RT101's Router ID bit B = 0 ;Unsupported options set to zero #links = 2 Link ID = 1.1.1.1 ;Interface IP address. Link Data = 0xffffff00 ;Network Mask Type = 9 ;OSPF-lite-transit Thomas Reed Expires November 6, 2010 [Page 14] Internet-Draft ospf-lite May 2010 # TOS metrics = 0 metric = 3 ;cost = 3 >> Link ID = 1.1.1.1 ;Interface IP address << >> Link Data = 0xffffffff ;32 bit HOST mask << Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 3 Figure 2.1 RT101s router LSA Link extracted from RT101s Router LSA (on same 1.1.1.0 network): >> Link ID = 1.1.1.1 ;Interface IP address << >> Link Data = 0xffffffff ;32 bit HOST mask << Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 3 Link extracted from RT102s Router LSA (on same 1.1.1.0 network): >> Link ID = 1.1.1.2 ;Interface IP address << >> Link Data = 0xffffffff ;32 bit HOST mask << Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 3 Link extracted from RT103s Router LSA (on same 1.1.1.0 network): >> Link ID = 1.1.1.3 ;Interface IP address << >> Link Data = 0xffffffff ;32 bit HOST mask << Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 3 Figure 2.2 Extracted 32 bit host routes These stub networks will lead to 32bit hosts routes in each router. It is recommended during SPF processing that these routes are preloaded to the routers main routing table at the start of processing. RT101s ospf-lite Routing table: Thomas Reed Expires November 6, 2010 [Page 15] Internet-Draft ospf-lite May 2010 Dest network 1.1.1.0 255.255.255.0 next hop 1.1.1.1 Dest network 1.1.1.1 255.255.255.255 next hop 1.1.1.1 Dest network 1.1.1.2 255.255.255.255 next hop 1.1.1.2 Dest network 1.1.1.3 255.255.255.255 next hop 1.1.1.3 Although not essential for these routes to be preloaded, this will increase response time for neighbor discovery on non fully meshed networks. 9. MANUAL NEIGHBOR /IPSEC MODE If neighbors are configured manually the Hello protocol uses the configured neighbor address exclusively and does not use ALLSPFRouters (224.0.0.5). ALL neighbors on an interface must be configured. In this mode ospf-lite hellos are not promiscuous and do not respond to the ospf-lite event 'helloReferenced'. This allows the protocol to be tunneled over IPSEC tunnels without alteration. Thomas Reed Expires November 6, 2010 [Page 16] Internet-Draft ospf-lite May 2010 10. EXAMPLE Router LSA's 192.1.2.0/24 + | | 3+---+ 1 N1 |--|RT1|-----+ | +---+ \ 192.1.1.0 /24 | \ -----_______ + \/ \ 1+---+ * N3 *-----|RT4| + /\_______/ +---+ | / ------ | 3+---+ 1 / | N2 |--|RT2|-----+ 1| | +---+ 3 +---+ 8 | /|RT3| + 19.10.1.0/24/ +---+ 192.1.3.0/24 / | 2 +------+ / | | RT14 | / +------+ | |/ 192.1.4.0/24 (N4) +------+ Figure 3: Example LSA Generation (RT=Router, N=Network) 10.1. Router RT3's LSA Consider the router-LSAs generated by Router RT3, as shown in Figure 12. Assume that the last byte of all of RTx's interface addresses is x, giving it the interface addresses 192.1.1.x and 192.1.4.x, and the router ID is selected by using the smallest ip address. RT3's router-LSA for AS LS age = 0 ;always true on origination Options = (E-bit) ;Mandatory with OSPF-lite LS type = 1 ;indicates router-LSA Link State ID = 192.1.1.3 ;RT3's Router ID Advertising Router = 192.1.1.3 ;RT3's Router ID bit E = 0 ;not an AS boundary (ie; RT3 isn't generating LSA type 5) #links = 3 Link ID = 192.1.1.3 ;Interface IP address. Link Data = 0xffffff00 ;Network Mask Thomas Reed Expires November 6, 2010 [Page 17] Internet-Draft ospf-lite May 2010 Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 1 Link ID = 192.1.4.3 ;Interface IP address Link Data = 0xffffff00 ;Network mask Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 2 Link ID = 19.10.1.3 ;Interface IP address Link Data = 0xffffff00 ;Network Mask Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 3 After state 2WAY is reached with neighbors R3's Router-LSA changes: RT3's router-LSA for AS (updated after 2WAY) LS age = xyz ; Options = (E-bit) ;Mandatory with OSPF-lite LS type = 1 ;indicates router-LSA Link State ID = 192.1.1.3 ;RT3's Router ID Advertising Router = 192.1.1.3 ;RT3's Router ID bit E = 0 ;not an AS boundary (ie; RT3 isn't generating LSA type 5) #links = 3 Link ID = 192.1.1.3 ;Interface IP address. Link Data = 0xffffff00 ;Network Mask Type = 9 ;OSPF-lite-transit # TOS metrics = 0 metric = 1 Link ID = 192.1.4.3 ;Interface IP address Link Data = 0xffffff00 ;Network mask Type = 8 ;OSPF-lite-stub # TOS metrics = 0 metric = 2 Link ID = 19.10.1.3 ;Interface IP address Link Data = 0xffffff00 ;Network Mask Type = 9 ;OSPF-lite-transit # TOS metrics = 0 metric = 3 Thomas Reed Expires November 6, 2010 [Page 18] Internet-Draft ospf-lite May 2010 11. Security Considerations Ospf-lite is able to use the authentication modes outlined in Appendix D of [RFC2328]. This memo introduces the use of IPSEC over ospf-lite. This memo does not introduce any new security concerns. 12. IANA Considerations Ospf-lite uses TCP and UDP port 8899. IANA has assigned this port exclusively for the use of ospf-lite. Code points within the packets are as OSPF [RFC2328]. 13. References 13.1. Normative References [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, STD 54, April 1998. [RFC5709] Bhatia, M., "OSPFv2 HMAC-SHA Cryptographic Authentication" October 2009 13.2. Informative References [RFC3630]Katz, D., Kompella, K., and Yeung, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. Thomas Reed Expires November 6, 2010 [Page 19] Internet-Draft ospf-lite May 2010 Appendix A. OSPF V2 Packets A.1. Encapsulation of OSPF-lite packets AllSPFRouters /Neighbor Unicast IP address This multicast IP address has been assigned the value 224.0.0.5. Hello packets are initially sent to this destination although migrate to the neighbors unicast IP address on event 'helloReceived' and or 'helloReferenced'. Note: In Manual/IPSEC mode hellos always use neighbor unicast IP addresses. All other packet types in ospf-lite are sent directly to the neighbors unicast IP address. A.2. The Options field The Options field operates as OSPF V2 including Opaque LSA support. +------------------------------------+ | * | O | DC | L | N/P | MC | E | * | +------------------------------------+ 0 0/1 0 0 0 0 1 0 The Options field O-bit: Support for Opaque LSAs. E-bit: Was used in OSPF V2 (when set to zero) to indicate the router was in a Stub area. Stub areas are not supported in ospf-lite and this bit must be set to 1. A.3. OSPF-lite Packet Formats There are FOUR supported packet types. All OSPF-lite packet types begin with a standard 24-byte header. Thomas Reed Expires November 6, 2010 [Page 20] Internet-Draft ospf-lite May 2010 Type Description TCP/UDP ________________________________ 1 OSPF-lite Hello UDP 2 Database Description TCP 3 Link State Request TCP 4 Link State Update TCP Note: type 5 (Link State Acknowledgment)is not supported A.3.1. The OSPF-lite packet header: As OSPF V2 except: a.) Version number 2 is used with ospf-lite b.) OSPF-lite Area id field MUST be set to 0.0.0.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version 2 | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID (must be 0.0.0.0 for OSPF-lite) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.3.2. The Hello packet: Differences listed below a.) Uses UDP 8899 b.) Hello Packets destination address are initially multicast but revert to unicast once neighbours on the network are seen in received hello packets. c.) RtrPri: Not supported. This field should be set to zero in OSPF- lite. d.) Designated Router = 0.0.0.0 Not supported. This Field is legacy from OSPF Version 2, and must be set to zero. Thomas Reed Expires November 6, 2010 [Page 21] Internet-Draft ospf-lite May 2010 e.) Backup Designated Router = 0.0.0.0 Not supported. This Field is legacy from OSPF Version 2, and must be set to zero. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF-lite | 1 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area (set to 0.0.0.0 for OSPF-lite) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | Options | RtrPri = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RouterDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DR = 0.0.0.0 for OSPF-lite | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BDR = 0.0.0.0 for OSPF-lite | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | A.3.3. The Database Description packet below: As OSPF V2 a.) Uses TCP 8899 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF-lite | 2 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID = 0.0.0.0 for OSPF-lite | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thomas Reed Expires November 6, 2010 [Page 22] Internet-Draft ospf-lite May 2010 | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface MTU | Options |0|0|0|0|0|I|M|MS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- An LSA Header -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | A.3.4. The Link State Request packet: As OSPF V2 a.) Uses TCP 8899 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF-lite | 3 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID 0.0.0.0 in OSPF-lite | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | Thomas Reed Expires November 6, 2010 [Page 23] Internet-Draft ospf-lite May 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | A.3.5. The Link State Update packet: As OSPF V2 a.) Uses TCP 8899 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF-lite | 4 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID 0.0.0.0 in OSPF-lite | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # LSAs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | LSAs | +- +-+ | ... | A.3.6. The Link State Acknowledgments are not supported. A.4. LSA formats ospf-lite supports LSA types 1, and 5 and opaque 9,10, and 11 A.4.1. The LSA header: As OSPF V2 with restricted LSA types The LSA types allowed in ospf-lite are: 1 Router-LSAs 5 AS-external-LSAs 9 Opaque LSA Link Local 10 Opaque LSA Area (AS with ospf-lite) wide 11 Opaque LSA AS Wide Thomas Reed Expires November 6, 2010 [Page 24] Internet-Draft ospf-lite May 2010 Note: LSA types 2, 3, 4 and 7 are not supported in OSPF-lite. 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 | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.4.2. Router-LSAs : As OSPF V2 with restricted Link-Types. 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 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | Thomas Reed Expires November 6, 2010 [Page 25] Internet-Draft ospf-lite May 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | bit-V: Virtual links not supported Must be set to 0 bit-E: When set, the router is sending LSA 5 External LSA's bit-B: Not supported. MUST be set to zero. Type In OSPF-lite this can be OSPF-lite-stub (type 8), or OSPF-lite- transit (type 9). The only exception arises if the underlying type is NBMA. If so then another link is also added into the Router LSA, namely an OSPF-lite- stub link to the 32-bit IP address of the NBMA interface. Link ID Identifies the object to which this router link connects, and is set in OSPF-lite to the IP address of the Interface connected. Link Data This value with OSPF-lite no longer depends on the link's Type field. The value of this field is the Mask of the Interface IP address. The exceptions to this rule is for the additional link added to the Router LSA for NBMA networks. This link has a full 32-bit mask in the Link Data field IP Unnumbered is not supported in ospf-lite A.4.3. N/A A.4.4. N/A A.4.5. AS-external-LSAs: As OSPF V2 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 | Thomas Reed Expires November 6, 2010 [Page 26] Internet-Draft ospf-lite May 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | bit-E The type of external metric. If bit-E is set, the metric specified is a Type 2 external metric. If bit-E is zero, the specified metric is a Type 1 external metric. Thomas Reed Expires November 6, 2010 [Page 27] Internet-Draft ospf-lite May 2010 Appendix B. Note on [RFC2328] Database Description Although ospf-lite does not implement Link state Acknowledgement packets, LSAcks [RFC2328], the OSPF [RFC2328] Database Description process does implement acknowledgements of a sort. These are described in the excerpt below from [RFC2328] and supported in ospf- lite. This support is to prevent onerous changes to the OSPF state machine. Ospf-lite uses TCP 8899 for these Database Description packets. RFC2328 Section 7.2 Synchronisation of Databases "Each router describes its database by sending a sequence of Database Description packets to its neighbor. When the neighbor sees an LSA that is more recent than its own database copy, it makes a note that this newer LSA should be requested. This sending and receiving of Database Description packets is called the "Database Exchange Process". During this process, the two routers form a master/slave relationship. Each Database Description Packet has a sequence number. Database Description Packets sent by the master (polls) are acknowledged by the slave through echoing of the sequence number. Both polls and their responses contain summaries of link state data. The master is the only one allowed to retransmit Database Description Packets. It does so only at fixed intervals, the length of which is the configured per-interface constant RxmtInterval. Each Database Description contains an indication that there are more packets to follow --- the M-bit. The Database Exchange Process is over when a router has received and sent Database Description Packets with the M-bit off." Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Thomas Reed Expires November 6, 2010 [Page 28] Internet-Draft ospf-lite May 2010 Authors' Addresses Matthew R Thomas University of Essex, School of Computing and Electronic Systems, Wivenhoe Park, Colchester CO4 3SQ, UK Telephone (+44) 7940 585456 E-Mail mrthom@essex.ac.uk Dr. M.J. Reed Room 4 SB 6.15 School of Computing and Electronic Systems University of Essex Wivenhoe Park Colchester Essex CO4 3SQ Telephone (+44) 1206 872479 E-mail mjreed@essex.ac.uk Thomas Reed Expires November 6, 2010 [Page 29]