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
|
<pre>Network Working Group L. Nguyen
Request for Comments: 4812 A. Roy
Category: Informational Cisco Systems
A. Zinin
Alcatel-Lucent
March 2007
<span class="h1">OSPF Restart Signaling</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. Routers find new and detect unreachable neighbors via the
Hello subprotocol. Hello OSPF packets are also used to ensure two-
way connectivity within time. When a router restarts its OSPF
software, it may not know its neighbors. If such a router sends a
Hello packet on an interface, its neighbors are going to reset the
adjacency, which may not be desirable in certain conditions.
This memo describes a vendor-specific mechanism that allows OSPF
routers to inform their neighbors about the restart process. Note
that this mechanism requires support from neighboring routers. 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. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4812">RFC 4812</a> OSPF Restart Signaling 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>. Sending Hello Packets with the RS-bit Set ..................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Receiving Hello Packets with the RS-Bit Set ................<a href="#page-3">3</a>
<a href="#section-2.3">2.3</a>. Ensuring Topology Stability ................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Backward Compatibility ..........................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-4">4</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-4">4</a>
<a href="#section-6">6</a>. References ......................................................<a href="#page-5">5</a>
<a href="#section-6.1">6.1</a>. Normative References .......................................<a href="#page-5">5</a>
<a href="#section-6.2">6.2</a>. Informative References .....................................<a href="#page-5">5</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgements ......................................<a href="#page-6">6</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
While performing a graceful restart of OSPF software [<a href="./rfc3623" title=""Graceful OSPF Restart"">RFC3623</a>],
routers need to prevent their neighbors from resetting their
adjacencies. However, after a reload, routers may not be aware of
the neighbors they had adjacencies with in their previous
incarnations. If such a router sends a Hello packet on an interface
and this packet does not list some neighbors, those neighbors will
reset the adjacency with the restarting router.
This document describes a technique that allows restarting routers to
inform their neighbors that they may not know about some neighbors
yet and the absence of some router IDs in the Hello packets should be
ignored.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Proposed Solution</span>
With this Restart Signaling Solution, a new bit, called RS (restart
signal), is introduced into the Extended Options (EO) TLV in the
Link-Local Signaling (LLS) block (see [<a href="./rfc4813" title=""OSPF Link-Local Signaling"">RFC4813</a>]). The value of this
bit is 0x00000002; see Figure 1 below.
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
| * | * | * | * | * | * | * |...| * | * | * | * | * | * | RS| LR|
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
Figure 1. Bits in Extended Options TLV
For a definition of the LR-bit, see [<a href="./rfc4811" title=""OSPF Out-of-Band Link State Database (LSDB) Resynchronization"">RFC4811</a>].
<span class="grey">Nguyen, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4812">RFC 4812</a> OSPF Restart Signaling March 2007</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Sending Hello Packets with the RS-bit Set</span>
OSPF routers should set the RS-bit in the EO-TLV attached to a Hello
packet when it is not known that all neighbors are listed in this
packet, but the restarting router wants them to preserve their
adjacencies. The RS-bit must not be set in Hello packets longer than
RouterDeadInterval seconds.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Receiving Hello Packets with the RS-Bit Set</span>
When an OSPF router receives a Hello packet containing the LLS block
with the EO-TLV that has the RS-bit set, the router should skip the
two-way connectivity check with the announcing neighbor (i.e., the
router should not generate a 1-WayReceived event for the neighbor if
it does not find its own router ID in the list of neighbors as
described in <a href="./rfc2328#section-10.5">Section 10.5 of [RFC2328]</a>), provided that the neighbor
Finite State Machine (FSM) for this neighbor is in the Full state.
The router should also send a unicast Hello back to the sender in
reply to a Hello packet with RS-bit set. This is to speed up
learning of previously known neighbors. When sending such a reply
packet, care must be taken to ensure that the RS-bit is clear in it.
Two additional fields are introduced in the neighbor data structure:
RestartState flag and ResyncTimeout timer. RestartState flag
indicates that a Hello packet with the RS-bit set has been received
and the local router expects its neighbor to go through the Link
State Database (LSDB) resynchronization procedure using [<a href="./rfc4811" title=""OSPF Out-of-Band Link State Database (LSDB) Resynchronization"">RFC4811</a>].
ResyncTimeout is a single-shot timer limiting the delay between the
first seen Hello packet with the RS-bit set and initialization of the
LSDB resynchronization procedure. The length of ResyncTimeout timer
is RouterDeadInterval seconds.
When a Hello packet with the RS-bit set is received and RestartState
flag is not set for the neighbor, the router sets RestartState flag
and starts ResyncTimeout timer. If ResyncTimeout expires,
RestartState flag is cleared and a 1-WayReceived event is generated
for the neighbor. If, while ResyncTimeout timer is running, the
neighbor starts LSDB resynchronization procedure using [<a href="./rfc4811" title=""OSPF Out-of-Band Link State Database (LSDB) Resynchronization"">RFC4811</a>],
ResyncTimeout timer is canceled. The router also clears RestartState
flag on completion of the LSDB resynchronization process.
Two or more routers on the same segment cannot have Hello packets
with the RS-bit set at the same time, as can be the case when two or
more routers restart at about the same time. In such a scenario, the
routers should clear the RestartState flag, cancel the ResyncTimeout
timer, and generate a 1-WayReceived event.
<span class="grey">Nguyen, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4812">RFC 4812</a> OSPF Restart Signaling March 2007</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Ensuring Topology Stability</span>
Under certain circumstances, it might be desirable to stop announcing
the restarting router as fully adjacent if this may lead to possible
routing loops. In order to provide this functionality, a
configurable option is provided on the neighboring routers that
instructs the OSPF process to follow the logics described below.
When an OSPF router schedules a routing table calculation due to a
change in the contents of its LSDB, it should also reset all
adjacencies with restarting routers (those with RestartState set to
TRUE) by clearing the RestartState neighbor flags, canceling
ResyncTimeout timers (if running), and generating the 1-WayReceived
events for the neighbor FSMs.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Backward Compatibility</span>
The described technique requires cooperation from neighboring
routers. However, if neighbors do not support this technique, they
will just reset the adjacency.
<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. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4812">RFC 4812</a> OSPF Restart Signaling 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.
[<a id="ref-RFC4811">RFC4811</a>] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link
State Database (LSDB) Resynchronization", <a href="./rfc4811">RFC 4811</a>, March
2007.
<span class="grey">Nguyen, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4812">RFC 4812</a> OSPF Restart Signaling 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 John Moy, 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. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4812">RFC 4812</a> OSPF Restart Signaling 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. Experimental [Page 7]
</pre>
|
