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
|
<pre>Internet Engineering Task Force (IETF) N. Sheth
Request for Comments: 6845 Contrail Systems
Updates: <a href="./rfc2328">2328</a>, <a href="./rfc5340">5340</a> L. Wang
Category: Standards Track J. Zhang
ISSN: 2070-1721 Juniper Networks
January 2013
<span class="h1">OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type</span>
Abstract
This document describes a mechanism to model a broadcast network as a
hybrid of broadcast and point-to-multipoint networks for purposes of
OSPF operation. Neighbor discovery and maintenance as well as Link
State Advertisement (LSA) database synchronization are performed
using the broadcast model, but the network is represented using the
point-to-multipoint model in the router-LSAs of the routers connected
to it. This allows an accurate representation of the cost of
communication between different routers on the network, while
maintaining the network efficiency of broadcast operation. This
approach is relatively simple and requires minimal changes to OSPF.
This document updates both OSPFv2 (<a href="./rfc2328">RFC 2328</a>) and OSPFv3 (<a href="./rfc5340">RFC 5340</a>).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6845">http://www.rfc-editor.org/info/rfc6845</a>.
<span class="grey">Sheth, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Requirements Language . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Interface Parameters . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. Neighbor Data Structure . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.3">4.3</a>. Neighbor Discovery and Maintenance . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.4">4.4</a>. Database Synchronization . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.5">4.5</a>. Generating Network-LSAs . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.6">4.6</a>. Generating Router and Intra-Area-Prefix-LSAs . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.6.1">4.6.1</a>. Stub Links in OSPFv2 Router-LSA . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.6.2">4.6.2</a>. OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.7">4.7</a>. Next-Hop Calculation . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.8">4.8</a>. Graceful Restart . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Compatibility Considerations . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Scalability and Deployment Considerations . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7">7</a>. Management Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-9">9</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-10">10</a>. Normative References . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<span class="grey">Sheth, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
OSPF [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] operation on broadcast interfaces takes advantage of
the broadcast capabilities of the underlying medium for doing
neighbor discovery and maintenance. Further, it uses a Designated
Router (DR) and Backup Designated Router (BDR) to keep the Link State
Advertisement (LSA) databases of the routers on the network
synchronized in an efficient manner. However, it has the limitation
that a router cannot advertise different costs to each of the
neighboring routers on the network in its router-LSA.
Consider a radio network that supports true broadcast, yet the
metrics between different pairs of terminals could be different for
various reasons (e.g., different signal strength due to placement).
When running OSPF over the radio network, for a router to advertise
different costs to different neighbors, the interface must be treated
as point-to-multipoint (P2MP), even though the network has true
broadcast capability.
Operation on point-to-multipoint interfaces could require explicit
configuration of the identity of neighboring routers. It also
requires the router to send separate Hellos to each neighbor on the
network. Further, it mandates establishment of adjacencies to all
configured or discovered neighbors on the network. However, it gives
the routers the flexibility to advertise different costs to each of
the neighboring routers in their router-LSAs.
This document proposes a new interface type that can be used on
networks that have broadcast capability. In this mode, neighbor
discovery and maintenance, as well as database synchronization are
performed using existing procedures for broadcast mode. The network
is modeled as a collection of point-to-point links in the router-LSA,
just as it would be in point-to-multipoint mode. This new interface
type is referred to as hybrid-broadcast-and-P2MP in the rest of this
document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Motivation</span>
There are some networks that are broadcast capable but have a
potentially different cost associated with communication between any
given pair of nodes. The cost could be based on the underlying
<span class="grey">Sheth, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
topology as well as various link quality metrics such as bandwidth,
delay, and jitter, among others.
It is not accurate to treat such networks as OSPF broadcast networks
since that does not allow a router to advertise a different cost to
each of the other routers. Using OSPF point-to-multipoint mode would
satisfy the requirement to correctly describe the cost to reach each
router. However, it would be inefficient in the sense that it would
require forming O(N^2) adjacencies when there are N routers on the
network.
It is advantageous to use the hybrid-broadcast-and-P2MP type for such
networks. This combines the flexibility of point-to-multipoint type
with the advantages and efficiencies of broadcast interface type.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Operation</span>
OSPF routers supporting the capabilities described herein should have
support for an additional hybrid-broadcast-and-P2MP type for the Type
data item described in <a href="./rfc2328#section-9">Section 9 of [RFC2328]</a>.
The following sub-sections describe salient aspects of OSPF operation
on routers configured with a hybrid-broadcast-and-P2MP interface.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Interface Parameters</span>
The "Router Priority" interface parameter as specified in OSPFv2
[<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] and OSPFv3 [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] applies to a hybrid-broadcast-and-P2MP
interface.
The "LinkLSASuppression" interface parameter as specified in OSPFv3
[<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] applies to a hybrid-broadcast-and-P2MP interface. The
default value is "disabled". It may be set to "enabled" via
configuration.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Neighbor Data Structure</span>
An additional field called the Neighbor Output Cost is added to the
neighbor data structure. This is the cost of sending a data packet
to the neighbor, expressed in the link state metric. The default
value of this field is the Interface output cost. It may be set to a
different value using mechanisms that are outside the scope of this
document, like static per-neighbor configuration, or any dynamic
discovery mechanism that is supported by the underlying network.
<span class="grey">Sheth, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Neighbor Discovery and Maintenance</span>
Routers send and receive Hellos so as to perform neighbor discovery
and maintenance on the interface using the procedures specified for
broadcast interfaces in [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] and [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Database Synchronization</span>
Routers elect a DR and BDR for the interface and use them for initial
and ongoing database synchronization using the procedures specified
for broadcast interfaces in [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] and [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>].
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Generating Network-LSAs</span>
Since a hybrid-broadcast-and-P2MP interface is described in router-
LSAs using a collection of point-to-point links, the DR MUST NOT
generate a network-LSA for the interface.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Generating Router and Intra-Area-Prefix-LSAs</span>
Routers describe the interface in their router-LSA as specified for a
point-to-multipoint interface in <a href="./rfc2328#section-12.4.1.4">Section 12.4.1.4 of [RFC2328]</a> and
<a href="./rfc5340#section-4.4.3.2">Section 4.4.3.2 of [RFC5340]</a>, with the following modifications for
Type 1 links:
o If a router is not the DR and does not have a full adjacency to
the DR, it MUST NOT add any Type 1 links.
o If a router is not the DR and has a full adjacency to the DR, and
both the DR and this router agree on the DR role, it MUST add a
Type 1 link corresponding to each neighbor that is in state 2-Way
or higher and to which the DR's router-LSA includes a link.
o The cost for a Type 1 link corresponding to a neighbor SHOULD be
set to the value of the Neighbor Output Cost field as defined in
<a href="#section-4.2">Section 4.2</a>.
<span class="h4"><a class="selflink" id="section-4.6.1" href="#section-4.6.1">4.6.1</a>. Stub Links in OSPFv2 Router-LSA</span>
Routers MUST add a Type 3 link for their own IP address to the
router-LSA as described in <a href="./rfc2328#section-12.4.1.4">Section 12.4.1.4 of [RFC2328]</a>. Further,
they MUST also add a Type 3 link with the Link ID set to the IP
subnet address, Link Data set to the IP subnet mask, and cost equal
to the configured output cost of the interface.
<span class="grey">Sheth, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
<span class="h4"><a class="selflink" id="section-4.6.2" href="#section-4.6.2">4.6.2</a>. OSPFv3 Intra-Area-Prefix-LSA</span>
Routers MUST add globally scoped IPv6 addresses on the interface to
the intra-area-prefix-LSA as described for point-to-multipoint
interfaces in <a href="./rfc5340#section-4.4.3.9">Section 4.4.3.9 of [RFC5340]</a>. In addition, they MUST
also add all globally scoped IPv6 prefixes on the interface to the
LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix
fields. The Metric field for each of these prefixes is set to the
configured output cost of the interface.
The DR MUST NOT generate an intra-area-prefix-LSA for the transit
network for this interface since it does not generate a network-LSA
for the interface. Note that the global prefixes associated with the
interface are advertised in the intra-area-prefix-LSA for the router
as described above.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. Next-Hop Calculation</span>
Next-hops to destinations that are directly connected to a router via
the interface are calculated as specified for a point-to-multipoint
interface in <a href="./rfc2328#section-16.1.1">Section 16.1.1 of [RFC2328]</a>.
<span class="h3"><a class="selflink" id="section-4.8" href="#section-4.8">4.8</a>. Graceful Restart</span>
The following modifications to the procedures defined in <a href="#section-2.2">Section 2.2</a>,
item 1, of [<a href="./rfc3623" title=""Graceful OSPF Restart"">RFC3623</a>] are required in order to ensure that the router
correctly exits graceful restart.
o If a router is the DR on the interface, the pre-restart network-
LSA for the interface MUST NOT be used to determine the previous
set of adjacencies.
o If a router is in state DROther on the interface, an adjacency to
a non-DR or non-BDR neighbor is considered as reestablished when
the neighbor state reaches 2-Way.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Compatibility Considerations</span>
All routers on the network must support the hybrid-broadcast-and-P2MP
interface type for successful operation. Otherwise, the interface
should be configured as a standard broadcast interface.
If some routers on the network treat the interface as broadcast and
others as hybrid-broadcast-and-P2MP, neighbors and adjacencies will
still get formed as for a broadcast interface. However, due to the
differences in how router and network-LSAs are built for these two
<span class="grey">Sheth, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
interface types, there will be no traffic traversing certain pairs of
routers. Note that this will not cause any persistent loops or
black-holing of traffic.
To detect and flag possible mismatched configurations, an
implementation of this specification SHOULD log a message if a
network-LSA is received for a locally configured hybrid interface.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Scalability and Deployment Considerations</span>
Treating a broadcast interface as hybrid-broadcast-and-P2MP results
in O(N^2) links to represent the network instead of O(N), when there
are N routers on the network. This will increase memory usage and
have a negative impact on route calculation performance on all the
routers in the area. Network designers should carefully weigh the
benefits of using the new interface type against the disadvantages
mentioned here.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Management Considerations</span>
The following MIB variable/value should be added to the appropriate
OSPFv2 and OSPFv3 MIBs ([<a href="./rfc4750" title=""OSPF Version 2 Management Information Base"">RFC4750</a>], [<a href="./rfc5643" title=""Management Information Base for OSPFv3"">RFC5643</a>]).
o For ospfIfType/ospfv3IfType, a new value broadcast-P2MP-hybrid (X)
for the hybrid interface type (X to be defined when the revised
MIB documents are approved).
o For ospfNbrEntry/ospfv3NbrEntry, an ospfNbrMetricValue/
ospfv3NbrMetricValue attribute for per-neighbor metrics. In case
of non-hybrid interfaces, the value is the same as the interface
metric.
This section is not normative.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This document raises no new security issues for OSPF. Security
considerations for the base OSPF protocol are covered in [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>],
[<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>], and [<a href="./rfc6506" title=""Supporting Authentication Trailer for OSPFv3"">RFC6506</a>].
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors would like to thank Acee Lindem and Richard Ogier for
their comments and suggestions.
<span class="grey">Sheth, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<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.
[<a id="ref-RFC4750">RFC4750</a>] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F.
Baker, "OSPF Version 2 Management Information Base",
<a href="./rfc4750">RFC 4750</a>, December 2006.
[<a id="ref-RFC5340">RFC5340</a>] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", <a href="./rfc5340">RFC 5340</a>, July 2008.
[<a id="ref-RFC5643">RFC5643</a>] Joyal, D. and V. Manral, "Management Information Base for
OSPFv3", <a href="./rfc5643">RFC 5643</a>, August 2009.
[<a id="ref-RFC6506">RFC6506</a>] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", <a href="./rfc6506">RFC 6506</a>,
February 2012.
<span class="grey">Sheth, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6845">RFC 6845</a> OSPF Hybrid Broadcast and P2MP Intf Type January 2013</span>
Authors' Addresses
Nischal Sheth
Contrail Systems
2350 Mission College Blvd, #1140
Santa Clara, CA 95054
US
EMail: nsheth@contrailsystems.com
Lili Wang
Juniper Networks
10 Technology Park Dr.
Westford, MA 01886
US
EMail: liliw@juniper.net
Jeffrey Zhang
Juniper Networks
10 Technology Park Dr.
Westford, MA 01886
US
EMail: zzhang@juniper.net
Sheth, et al. Standards Track [Page 9]
</pre>
|
