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
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Internet Engineering Task Force (IETF) Y. Cai
Request for Comments: 6754 Microsoft
Category: Standards Track L. Wei
ISSN: 2070-1721 H. Ou
Cisco Systems, Inc.
V. Arya
S. Jethwani
DIRECTV Inc.
October 2012
<span class="h1">Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect</span>
Abstract
A Protocol Independent Multicast (PIM) router uses the Reverse Path
Forwarding (RPF) procedure to select an upstream interface and router
in order to build forwarding state. When there are equal-cost
multipaths (ECMPs), existing implementations often use hash
algorithms to select a path. Such algorithms do not allow the spread
of traffic among the ECMPs according to administrative metrics. This
usually leads to inefficient or ineffective use of network resources.
This document introduces the ECMP Redirect, a mechanism to improve
the RPF procedure over ECMPs. It allows ECMP selection to be based
on administratively selected metrics, such as data transmission
delays, path preferences, and routing metrics.
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/rfc6754">http://www.rfc-editor.org/info/rfc6754</a>.
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
Copyright Notice
Copyright (c) 2012 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>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Applicability . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Protocol Specification . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.3">5.3</a>. Transient State . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.4">5.4</a>. Interoperability . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.5">5.5</a>. Packet Format . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.5.1">5.5.1</a>. PIM ECMP Redirect Hello Option . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.5.2">5.5.2</a>. PIM ECMP Redirect Format . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
A PIM router uses the RPF procedure to select an upstream interface
and a PIM neighbor on that interface to build forwarding state. When
there are equal-cost multipaths (ECMPs) upstream, existing
implementations often use hash algorithms to select a path. Such
algorithms do not allow the spread of traffic among the ECMP
according to administrative metrics. This usually leads to
inefficient or ineffective use of network resources. This document
introduces the ECMP Redirect, a mechanism to improve the RPF
procedure over ECMP. It allows ECMP selection to be based on
administratively selected metrics, such as data transmission delays,
path preferences, and routing metrics, or a combination of metrics.
ECMPs are frequently used in networks to provide redundancy and to
increase available bandwidth. A PIM router selects a path in the
ECMP based on its own implementation-specific choice. The selection
is a local decision. One way is to choose the PIM neighbor with the
highest IP address; another is to pick the PIM neighbor with the best
hash value over the destination and source addresses.
While implementations supporting ECMP have been deployed widely, the
existing RPF selection methods have weaknesses. The lack of
administratively effective ways to allocate traffic over alternative
paths is a major issue. For example, there is no straightforward way
to tell two downstream routers to select either the same or different
RPF neighbor routers for the same traffic flows.
With the ECMP Redirect mechanism introduced here, the upstream
routers use a PIM ECMP Redirect message to instruct the downstream
routers on how to tiebreak among the upstream neighbors. The PIM
ECMP Redirect message conveys the tiebreak information based on
metrics selected administratively.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</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>].
This document uses terms defined in [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>] to describe actions
taken by PIM routers.
The following terms have special significance for ECMP Redirect:
o Equal-Cost Multipath (ECMP). In this document, the term "ECMP"
refers to parallel, single-hop, equal-cost links between adjacent
nodes.
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
o ECMP Bundle. An ECMP bundle is a set of PIM-enabled interfaces on
a router, where all interfaces belonging to the same bundle share
the same routing metric. The next hops for the ECMP are all one
hop away.
There can be one or more ECMP bundles on any router, while one
individual interface can only belong to a single bundle. ECMP
bundles are created on a router via configuration.
o RPF. RPF stands for Reverse Path Forwarding.
o Upstream. Towards the root of the multicast forwarding tree. An
upstream router refers to a router that is forwarding, or
potentially capable of forwarding, data packets onto interfaces in
an ECMP bundle.
When there are multiple routers forwarding packets onto interfaces
in the ECMP bundle, all these routers are called upstream routers.
o Downstream. Away from the root of the multicast forwarding tree.
A downstream router is a router that uses an interface in the ECMP
bundle as an RPF interface for a multicast forwarding entry.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overview</span>
The existing PIM Assert mechanism allows the upstream router to
detect the existence of multiple forwarders for the same multicast
flow onto the same downstream interface. The upstream router sends a
PIM Assert message containing a routing metric for the downstream
routers to use for tiebreaking among the multiple upstream forwarders
on the same RPF interface.
With ECMP interfaces between the downstream and upstream routers, the
PIM ECMP Redirect mechanism works in a similar way, but extends the
ability to resolve the selection of forwarders among different
interfaces in the ECMP.
When a PIM router downstream of the ECMP interfaces creates a new
(*,G) or (S,G) entry, it will populate the RPF interface and RPF
neighbor information according to the rules specified by [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>].
This router will send its initial PIM Joins to that RPF neighbor.
When the RPF neighbor router receives the Join message and finds that
the receiving interface is one of the ECMP interfaces, it will check
if the same flow is already being forwarded out of another ECMP
interface. If so, this RPF neighbor router will send a PIM ECMP
Redirect message onto the interface the Join was received on. The
PIM ECMP Redirect message contains the address of the desired RPF
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
neighbor, an Interface ID [<a href="./rfc6395" title=""An Interface Identifier (ID) Hello Option for PIM"">RFC6395</a>], and the other parameters used as
tiebreakers. In essence, a PIM ECMP Redirect message is sent by an
upstream router to notify downstream routers to redirect PIM Joins to
the new RPF neighbor via a different interface. When the downstream
routers receive this message, they SHOULD trigger PIM Joins toward
the new RPF neighbor specified in the packet.
This PIM ECMP Redirect message has similar functions as the existing
PIM Assert message:
1. It is sent by an upstream router.
2. It is used to influence the RPF selection by downstream routers.
3. A tiebreaker metric is used.
However, the existing Assert message is used to select an upstream
router within the same multi-access network (such as a LAN), while
the Redirect message is used to select both a network and an upstream
router.
One advantage of this design is that the control messages are only
sent when there is a need to "rebalance" the traffic. This reduces
the amount of control traffic.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Applicability</span>
The use of ECMP Redirect applies to shared trees or source trees
built with procedures described in [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>]. The use of ECMP
Redirect in PIM Dense Mode [<a href="./rfc3973" title=""Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)"">RFC3973</a>] or in Bidirectional PIM
[<a href="./rfc5015" title=""Bidirectional Protocol Independent Multicast (BIDIR- PIM)"">RFC5015</a>] is not considered in this document.
The enhancement described in this document can be applicable to a
number of scenarios. For example, it allows a network operator to
use ECMPs and have the ability to perform load splitting based on
bandwidth. To do this, the downstream routers perform RPF selection
with bandwidth, instead of IP addresses, as a tiebreaker. The ECMP
Redirect mechanism assures that all downstream routers select the
desired network link and upstream router whenever possible. Another
example is for a network operator to impose a transmission delay
limit on certain links. The ECMP Redirect mechanism provides a means
for an upstream router to instruct a downstream router to choose a
different RPF path.
This specification does not dictate the scope of applications of this
mechanism.
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Protocol Specification</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Sending ECMP Redirect</span>
ECMP Redirects are sent by an upstream router in a rate-limited
fashion, under either of the following conditions:
o It detects a PIM Join on a non-desired outgoing interface.
o It detects multicast traffic on a non-desired outgoing interface.
In both cases, an ECMP Redirect is sent to the non-desired interface.
An outgoing interface is considered "non-desired" when:
o The upstream router is already forwarding the same flow out of
another interface belonging to the same ECMP bundle.
o The upstream router is not yet forwarding the flow out any
interfaces of the ECMP bundle, but there is another interface with
more desired attributes.
An upstream router MAY choose not to send ECMP Redirects if it
becomes aware that some of the downstream routers are unreachable via
some links in ECMP bundle.
An upstream router uses the Neighbor Address or the Interface ID
field in the ECMP Redirect message to indicate the interface it wants
traffic to be directed to. This Neighbor Address MUST be associated
with an interface in the same ECMP bundle as the ECMP Redirect
message's outgoing interface. If the Interface ID field is ignored,
this Neighbor Address field uniquely identifies a LAN and an upstream
router to which a downstream router SHOULD redirect its Join
messages, and an ECMP Redirect message MUST be discarded if the
Neighbor Address field in the message does not match the cached
neighbor address.
The Interface ID field is used in IPv4 when one or more RPF neighbors
in the ECMP bundle are unnumbered, or in IPv6 where link-local
addresses are in use. For other IPv4 usage, this field is zeroed
when sent, and ignored when received. If the Router ID part of the
Interface ID is zero, the field MUST be ignored. See [<a href="./rfc6395" title=""An Interface Identifier (ID) Hello Option for PIM"">RFC6395</a>] for
details of its assignment and usage in PIM Hellos. If the Interface
ID is not ignored, the receiving router of this message MUST use the
Interface ID, instead of Neighbor Address, to identify the new RPF
neighbor. Additionally, an ECMP Redirect message MUST be discarded
if the Interface ID field in the message does not match the cached
Interface ID.
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Receiving ECMP Redirect</span>
When a downstream router receives an ECMP Redirect, and detects that
the desired RPF path from its upstream router's point of view is
different from its current one, it should choose to join the newly
suggested path and prune from the current path. The exact order of
such actions is implementation specific.
If a downstream router receives multiple ECMP Redirects sent by
different upstream routers, it SHOULD use the Preference, Metric, or
other fields as specified below as the tiebreakers to choose the most
preferred RPF interface and neighbor. The tiebreak procedure is the
same as that used in PIM Assert processing described by [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>].
If an upstream router receives an ECMP Redirect, it SHOULD NOT change
its forwarding behavior even if the ECMP Redirect makes it a less
preferred RPF neighbor on the receiving interface.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Transient State</span>
During a transient network outage with a single link cut in an ECMP
bundle, a downstream router may lose connection to its RPF neighbor
and the normal ECMP Redirect operation may be interrupted
temporarily. In such an event, the following actions are
RECOMMENDED.
The downstream router SHOULD select a new RPF neighbor. Among all
ECMP upstream routers, the preferred selection is the one on the LAN
that the previous RPF neighbor resided on.
If there is no upstream router reachable on the LAN that the previous
RPF neighbor resided on, the downstream router will select a new RPF
neighbor on a different LAN. Among all ECMP upstream routers, the
one that served as RPF neighbor before the link failure is preferred.
Such a router can be identified by the Router ID, which is part of
the Interface ID in the PIM ECMP Redirect Hello option.
During normal ECMP Redirect operations, when PIM Joins for the same
(*,G) or (S,G) are received on a different LAN, an upstream router
will send ECMP Redirect to prune the non-preferred LAN. Such ECMP
Redirects during partial network outage can be suppressed if the
upstream router decides that the non-preferred PIM Join is from a
router that is not reachable via the preferred LAN. This check can
be performed by retrieving the downstream router's Router ID, using
the source address in the PIM Join, and searching neighbors on the
preferred LAN for one with the same Router ID.
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Interoperability</span>
If a PIM router supports this specification, it MUST send the PIM
ECMP Redirect Hello Option in its PIM Hello messages.
A PIM router sends ECMP Redirects on an interface only when it
detects that all neighbors on that interface have sent this Hello
option. If a PIM router detects that any of its neighbors on an ECMP
bundle does not support this Hello option, it SHOULD NOT send ECMP
Redirects to interfaces in that bundle; however, it SHOULD still
process any ECMP Redirects received from interfaces in that same
bundle.
If a PIM router does not support this specification, it will ignore
the PIM ECMP Redirect Hello Options and ECMP Redirects in the PIM
packets that it receives.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Packet Format</span>
<span class="h4"><a class="selflink" id="section-5.5.1" href="#section-5.5.1">5.5.1</a>. PIM ECMP Redirect Hello Option</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ECMP Redirect Hello Option
Type: 32
Length: 0
<span class="grey">Cai, 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="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
<span class="h4"><a class="selflink" id="section-5.5.2" href="#section-5.5.2">5.5.2</a>. PIM ECMP Redirect Format</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+- ............ Interface ID ........... -+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+
| |
+- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 2: ECMP Redirect Message Format
PIM Ver: See <a href="./rfc4601#section-4.9">Section 4.9 in [RFC4601]</a>.
Type: 11
Reserved: See <a href="./rfc4601#section-4.9">Section 4.9 in [RFC4601]</a>.
Checksum: See <a href="./rfc4601#section-4.9">Section 4.9 in [RFC4601]</a>.
Group Address (64 or 160 bits): Encoded-Group address as specified
in <a href="./rfc4601#section-4.9.1">Section 4.9.1 of [RFC4601]</a>.
Source Address (48 or 144 bits): Encoded-Unicast address as
specified in <a href="./rfc4601#section-4.9.1">Section 4.9.1 of [RFC4601]</a>.
Neighbor Address (32 or 128 bits): Address of desired upstream
neighbor where the downstream receiver redirects PIM Joins.
Interface ID (64 bits): See [<a href="./rfc6395" title=""An Interface Identifier (ID) Hello Option for PIM"">RFC6395</a>] for details.
<span class="grey">Cai, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
Preference (8 bits): The first tiebreaker when ECMP Redirects from
multiple upstream routers are compared against each other. A
numerically smaller value is preferred. A reserved value (15) is
used to indicate the metric value following the Preference field
is a Network Time Protocol (NTP) timestamp, encoded in the format
specified in [<a href="./rfc5905" title=""Network Time Protocol Version 4: Protocol and Algorithms Specification"">RFC5905</a>], taken at the moment the sending router
started to forward out of this interface.
Metric (64 bits): The second tiebreaker if the Preference values are
the same. A numerically smaller value is preferred. This Metric
can contain path parameters defined by users. When the Preference
and Metric values are the same, the Neighbor Address or Interface
ID field is used as the third tiebreaker, depending on which field
is used to identify the RPF neighbor; the bigger value wins.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
A PIM-Hello Option Type (32) has been assigned to the PIM ECMP
Redirect Hello Option.
In the PIM Message Types registry created by [<a href="./rfc6166" title=""A Registry for PIM Message Types"">RFC6166</a>], a PIM Message
Type (11) has been assigned to the ECMP Redirect message.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Security of the ECMP Redirect is only guaranteed by the security of
the PIM packet; the security considerations for PIM Assert packets as
described in [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>] apply here. Spoofed ECMP Redirect packets may
cause the downstream routers to send PIM Joins to an undesired
upstream router and trigger more ECMP Redirect messages. Security
considerations for PIM packets described in [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>] also apply to
the new Hello option defined here.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
The authors would like to thank Apoorva Karan for helping with the
original idea, and Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig
Venaas, Jeffrey Zhang, Bill Atwood, and Adrian Farrel for their
review comments.
<span class="grey">Cai, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</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-RFC4601">RFC4601</a>] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", <a href="./rfc4601">RFC 4601</a>, August 2006.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC3973">RFC3973</a>] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", <a href="./rfc3973">RFC 3973</a>, January 2005.
[<a id="ref-RFC5015">RFC5015</a>] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", <a href="./rfc5015">RFC 5015</a>, October 2007.
[<a id="ref-RFC5905">RFC5905</a>] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", <a href="./rfc5905">RFC 5905</a>, June 2010.
[<a id="ref-RFC6166">RFC6166</a>] Venaas, S., "A Registry for PIM Message Types", <a href="./rfc6166">RFC 6166</a>,
April 2011.
[<a id="ref-RFC6395">RFC6395</a>] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
Hello Option for PIM", <a href="./rfc6395">RFC 6395</a>, October 2011.
<span class="grey">Cai, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6754">RFC 6754</a> PIMv2 ECMP Redirect October 2012</span>
Authors' Addresses
Yiqun Cai
Microsoft
1065 La Avenida
Mountain View, CA 94043
USA
EMail: yiqunc@microsoft.com
Liming Wei
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
USA
EMail: lwei@cisco.com
Heidi Ou
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
USA
EMail: hou@cisco.com
Vishal Arya
DIRECTV Inc.
2230 E Imperial Hwy
El Segundo, CA 90245
USA
EMail: varya@directv.com
Sunil Jethwani
DIRECTV Inc.
2230 E Imperial Hwy
El Segundo, CA 90245
USA
EMail: sjethwani@directv.com
Cai, et al. Standards Track [Page 12]
</pre>
|
