1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Network Working Group L. Nguyen
Request for Comments: 4811 A. Roy
Category: Informational Cisco Systems
A. Zinin
Alcatel-Lucent
March 2007
<span class="h1">OSPF Out-of-Band Link State Database (LSDB) Resynchronization</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
OSPF is a link-state intra-domain routing protocol used in IP
networks. Link State Database (LSDB) synchronization in OSPF is
achieved via two methods -- initial LSDB synchronization when an OSPF
router has just been connected to the network and asynchronous
flooding that ensures continuous LSDB synchronization in the presence
of topology changes after the initial procedure was completed. It
may sometime be necessary for OSPF routers to resynchronize their
LSDBs. The OSPF standard, however, does not allow routers to do so
without actually changing the topology view of the network.
This memo describes a vendor-specific mechanism to perform such a
form of out-of-band LSDB synchronization. The mechanism described in
this document was proposed before Graceful OSPF Restart, as described
in <a href="./rfc3623">RFC 3623</a>, came into existence. It is implemented/supported by at
least one major vendor and is currently deployed in the field. The
purpose of this document is to capture the details of this mechanism
for public use. This mechanism is not an IETF standard.
<span class="grey">Nguyen, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Proposed Solution ...............................................<a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. The LR-Bit .................................................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. OSPF Neighbor Data Structure ...............................<a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. Hello Packets ..............................................<a href="#page-4">4</a>
<a href="#section-2.4">2.4</a>. DBD Packets ................................................<a href="#page-4">4</a>
<a href="#section-2.5">2.5</a>. Neighbor State Treatment ...................................<a href="#page-7">7</a>
<a href="#section-2.6">2.6</a>. Initiating OOB LSDB Resynchronization ......................<a href="#page-7">7</a>
<a href="#section-3">3</a>. Backward Compatibility ..........................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. Informative References .....................................<a href="#page-8">8</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgements ......................................<a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
According to the OSPF standard [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>], after two OSPF routers have
established an adjacency (the neighbor Finite State Machines (FSMs)
have reached Full state), routers announce the adjacency states in
their router-Link State Advertisements (LSAs). Asynchronous flooding
algorithm ensures that routers' LSDBs stay in sync in the presence of
topology changes. However, if routers need (for some reason) to
resynchronize their LSDBs, they cannot do that without actually
putting the neighbor FSMs into the ExStart state. This effectively
causes the adjacencies to be removed from the router-LSAs, which may
not be acceptable if the desire is to prevent routing table flaps
during database resynchronization. In this document, we provide the
means for so-called out-of-band (OOB) LSDB resynchronization.
The described mechanism can be used in a number of situations
including those where the routers are picking up the adjacencies
after a reload. The process of adjacency preemption is outside the
scope of this document. Only the details related to LSDB
resynchronization are mentioned herein.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Proposed Solution</span>
With this Out-of-Band Resynchronization Solution, the format of the
OSPF Database Description (DBD) packet is changed to include a new
R-bit indicating OOB LSDB resynchronization. All DBD packets sent
during the OOB resynchronization procedure are sent with the R-bit
set.
<span class="grey">Nguyen, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
Also, two new fields are added to the neighbor data structure. The
first field indicates a neighbor's OOB resynchronization capability.
The second indicates that OOB LSDB resynchronization is in process.
The latter field allows OSPF implementations to utilize the existing
neighbor FSM code.
A bit is occupied in the Extended Options (EO) TLV (see [<a href="./rfc4813" title=""OSPF Link-Local Signaling"">RFC4813</a>]).
Routers set this bit to indicate their capability to support the
described technique.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. The LR-Bit</span>
A new bit, called LR (LR stands for LSDB Resynchronization), is
introduced to the LLS Extended Options TLV (see [<a href="./rfc4813" title=""OSPF Link-Local Signaling"">RFC4813</a>]). The
value of the bit is 0x00000001; see Figure 1. See the "IANA
Considerations" section of [<a href="./rfc4813" title=""OSPF Link-Local Signaling"">RFC4813</a>] for more information on the
Extended Options bit definitions. Routers set the LR-bit to announce
OOB LSDB resynchronization capability.
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
| * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | LR|
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
Figure 1. The Options Field
Routers supporting the OOB LSDB resynchronization technique set the
LR-bit in the EO-TLV in the LLS block attached to both Hello and DBD
packets. Note that no bit is set in the standard OSPF Options field,
neither in OSPF packets nor in LSAs.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. OSPF Neighbor Data Structure</span>
A field is introduced into OSPF neighbor data structure, as described
below. The name of the field is OOBResync, and it is a flag
indicating that the router is currently performing OOB LSDB
resynchronization with the neighbor.
The OOBResync flag is set when the router is initiating OOB LSDB
resynchronization (see <a href="#section-2.6">Section 2.6</a> for more details).
Routers clear the OOBResync flag on the following conditions:
o The neighbor data structure is first created.
o The neighbor FSM transitions to any state lower than ExStart.
o The neighbor FSM transitions to the ExStart state because a DBD
packet with the R-bit clear has been received.
<span class="grey">Nguyen, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
o The neighbor FSM reaches the state Full.
Note that the OOBResync flag may have a TRUE value only if the
neighbor FSM is in states ExStart, Exchange, or Loading. As
indicated above, if the FSM transitions to any other state, the
OOBResync flag should be cleared.
It is important to mention that operation of the OSPF neighbor FSM is
not changed by this document. However, depending on the state of the
OOBResync flag, the router sends either normal DBD packets or DBD
packets with the R-bit set.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Hello Packets</span>
Routers capable of performing OOB LSDB resynchronization should
always set the LR-bit in their Hello packets.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. DBD Packets</span>
Routers supporting the described technique should always set the LR-
bit in the DBD packets. Since the Options field of the initial DBD
packet is stored in corresponding neighbor data structure, the LR-bit
may be used later to check if a neighbor is capable of performing OOB
LSDB resynchronization.
The format of type 2 (DBD) OSPF packets is changed to include a flag
indicating the OOB LSDB resynchronization procedure. Figure 2
illustrates the new packet format.
<span class="grey">Nguyen, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
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 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|R|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Figure 2. Modified DBD Packet
The R-bit in OSPF type 2 packets is set when the OOBResync flag for
the specific neighbor is set to TRUE. If a DBD packets with the R-
bit clear is received for a neighbor with active OOBResync flag, the
OOB LSDB resynchronization process is canceled and normal LSDB
synchronization procedure is initiated.
When a DBD packet is received with the R-bit set and the sender is
known to be OOB-incapable, the packet should be dropped and a
SeqNumber-Mismatch event should be generated for the neighbor.
<span class="grey">Nguyen, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
Processing of DBD packets is modified as follows:
1. If the OOBResync flag for the neighbor is set (the LSDB
resynchronization process has been started) and the received DBD
packet does not have the R-bit set, ignore the packet and
generate a SeqNumberMismatch event for the neighbor FSM.
2. Otherwise, if the OOBResync flag for the neighbor is clear and
the received DBD packet has the R-bit set, perform the following
steps:
* If the neighbor FSM is in state Full and bits I, M, and MS
are set in the DBD packet, set the OOBResync flag for the
neighbor, put the FSM in ExStart state, and continue
processing the DBD packet as described in [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>].
* Otherwise, ignore received DBD packet (no OOB DBD packets are
allowed with OOBResync flag clear and FSM in state other than
Full). Also, if the state of the FSM is Exchange or higher,
generate a SeqNumberMismatch event for the neighbor FSM.
3. Otherwise, process the DBD packet as described in [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>].
During normal processing of the initial OOB DBD packet (with bits R,
I, M, and MS set), if the receiving router is selected to be the
Master, it may speed up the resynchronization process by immediately
replying to the received packet.
It is also necessary to limit the time an adjacency can spend in
ExStart, Exchange, and Loading states with OOBResync flag set to a
finite period of time (e.g., by limiting the number of times DBD and
link state request packets can be retransmitted). If the adjacency
does not proceed to Full state before the timeout, it is indicative
that the neighboring router cannot resynchronize its LSDB with the
local router. The requesting router may decide to stop trying to
resynchronize the LSDB over this adjacency (if, for example, it can
be resynchronized via another neighbor on the same segment) or to
resynchronize using the legacy method by clearing the OOBResync flag
and leaving the FSM in ExStart state. The neighboring router may
decide to cancel the OOB procedure for the neighbor.
<span class="grey">Nguyen, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Neighbor State Treatment</span>
An OSPF implementation supporting the described technique should
modify the logic consulting the state of a neighbor FSM as described
below.
o FSM state transitioning from and to the Full state with the
OOBResync flag set should not cause origination of a new version
of router-LSA or network-LSA.
o Any explicit checks for the Full state of a neighbor FSM for the
purposes other than LSDB synchronization and flooding should
treat states ExStart, Exchange, and Loading as state Full,
provided that OOBResync flag is set for the neighbor. (Flooding
and MaxAge-LSA-specific procedures should not check the state of
the OOBResync flag, but should continue consulting only the FSM
state.)
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Initiating OOB LSDB Resynchronization</span>
To initiate out-of-band LSDB resynchronization, the router must first
make sure that the corresponding neighbor supports this technology
(by checking the LR-bit in the Options field of the neighbor data
structure). If the neighboring router is capable, the OOBResync flag
for the neighbor should be set to TRUE and the FSM state should be
forced to ExStart.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Backward Compatibility</span>
Because OOB-capable routers explicitly indicate their capability by
setting the corresponding bit in the Options field, no DBD packets
with the R-bit set are sent to OOB-incapable routers.
The LR-bit itself is transparent for OSPF implementations and does
not affect communication between routers.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
The described technique does not introduce any new security issues
into the OSPF protocol.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
Please refer to the "IANA Considerations" section of [<a href="./rfc4813" title=""OSPF Link-Local Signaling"">RFC4813</a>] for
more information on the Extended Options bit definitions.
<span class="grey">Nguyen, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC2328">RFC2328</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.
[<a id="ref-RFC3623">RFC3623</a>] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", <a href="./rfc3623">RFC 3623</a>, November 2003.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC4813">RFC4813</a>] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A.
Zinin, "OSPF Link-Local Signaling", <a href="./rfc4813">RFC 4813</a>, March 2007.
<span class="grey">Nguyen, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acknowledgments</span>
The authors would like to thank Acee Lindem, Russ White, Don Slice,
and Alvaro Retana for their valuable comments.
Authors' Addresses
Liem Nguyen
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
EMail: lhnguyen@cisco.com
Abhay Roy
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
EMail: akr@cisco.com
Alex Zinin
Alcatel-Lucent
Mountain View, CA
USA
EMail: alex.zinin@alcatel-lucent.com
<span class="grey">Nguyen, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4811">RFC 4811</a> OSPF Out-of-Band LSDB Resynchronization March 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nguyen, et al. Informational [Page 10]
</pre>
|
