One document matched: draft-thomas-reed-ospf-lite-00.txt
OSPF working group M.Thomas
Internet Draft M.J.Reed
Intended status: Experimental University of Essex
Expires: November 5, 2010 May 5, 2010
ospf-lite
draft-thomas-reed-ospf-lite-00.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 5, 2010.
Thomas Reed Expires November 5, 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,5,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 5, 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...12
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 5, 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 5, 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 5, 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 5, 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. 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.
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.
Thomas Reed Expires November 5, 2010 [Page 7]
Internet-Draft ospf-lite May 2010
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
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
Thomas Reed Expires November 5, 2010 [Page 8]
Internet-Draft ospf-lite May 2010
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 5, 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
database's graph. If a directly connected router appears sending a
Thomas Reed Expires November 5, 2010 [Page 10]
Internet-Draft ospf-lite May 2010
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
LSA Cont..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Thomas Reed Expires November 5, 2010 [Page 11]
Internet-Draft ospf-lite May 2010
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
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:
Thomas Reed Expires November 5, 2010 [Page 12]
Internet-Draft ospf-lite May 2010
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 adddress of the connected interface.
Thomas Reed Expires November 5, 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 5, 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 17.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 17.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 5, 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 5, 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 5, 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 5, 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 5, 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 5, 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 5, 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 5, 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 5, 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 5, 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 5, 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 unsupported 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 5, 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 5, 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 5, 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
E-mail mjreed@essex.ac.uk
Thomas Reed Expires November 5, 2010 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-23 15:00:35 |