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
|
<pre>Internet Engineering Task Force (IETF) Y. Rekhter
Request for Comments: 7442 Juniper Networks
Category: Standards Track R. Aggarwal
ISSN: 2070-1721 Arktan
N. Leymann
Deutsche Telekom
W. Henderickx
Alcatel-Lucent
Q. Zhao
R. Li
Huawei
February 2015
<span class="h1">Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM)</span>
<span class="h1">in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)</span>
Abstract
When IP multicast trees created by Protocol Independent Multicast -
Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass
through an MPLS domain, it may be desirable to map such trees to
Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document
describes how to accomplish this in the case where such P2MP LSPs are
established using Label Distribution Protocol (LDP) Extensions for
P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).
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/rfc7442">http://www.rfc-editor.org/info/rfc7442</a>.
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
Copyright Notice
Copyright (c) 2015 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-1.1">1.1</a>. Specification of Requirements ..............................<a href="#page-4">4</a>
2. Mechanism 1 - Non-transitive Mapping of IP Multicast
Shared Trees ....................................................<a href="#page-4">4</a>
2.1. Originating Source Active Auto-discovery Routes
(Mechanism 1) ..............................................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Receiving Source Active Auto-discovery Routes by LSR .......<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Handling (S,G,RPT-bit) State ...............................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees ...<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. In-Band Signaling for IP Multicast Shared Trees ............<a href="#page-6">6</a>
3.2. Originating Source Active Auto-discovery Routes
(Mechanism 2) ..............................................<a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. Receiving Source Active Auto-discovery Routes ..............<a href="#page-8">8</a>
<a href="#section-3.4">3.4</a>. Pruning Sources Off the Shared Tree ........................<a href="#page-8">8</a>
<a href="#section-3.5">3.5</a>. More on Handling (S,G,RPT-bit) State .......................<a href="#page-9">9</a>
<a href="#section-4">4</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. References .....................................................<a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. Informative References ....................................<a href="#page-10">10</a>
Acknowledgements ..................................................<a href="#page-11">11</a>
Authors' Addresses ................................................<a href="#page-11">11</a>
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-RFC6826">RFC6826</a>] describes how to map Point-to-Multipoint Label Switched
Paths (P2MP LSPs) created by mLDP [<a href="./rfc6388" title=""Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6388</a>] to multicast trees
created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in
Source-Specific Multicast (SSM) mode [<a href="./rfc4607" title=""Source-Specific Multicast for IP"">RFC4607</a>]. This document
describes how to map mLDP P2MP trees to multicast trees created by
PIM-SM in Any-Source Multicast (ASM) mode. It describes two possible
mechanisms for doing this.
The first mechanism, described in <a href="#section-2">Section 2</a>, is OPTIONAL for
implementations, but the second mechanism, described in <a href="#section-3">Section 3</a>, is
REQUIRED for all implementations claiming conformance to this
specification.
Note that from a deployment point of view these two mechanisms are
mutually exclusive. That is, on the same network one could deploy
either one of the mechanisms, but not both.
The reader of this document is expected to be familiar with PIM-SM
[<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>] and mLDP [<a href="./rfc6388" title=""Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6388</a>].
This document relies on the procedures in [<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>] to support source
trees. For example, following these procedures a Label Switching
Router (LSR) may initiate an mLDP Label Map with the Transit
IPv4/IPv6 Source TLV for (S,G) when receiving a PIM (S,G) Join.
This document uses BGP Source Active auto-discovery routes, as
defined in [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>]. For the sake of brevity in the rest of this
document, we'll refer to these routes as just "Source Active
auto-discovery routes".
Consider a deployment scenario where the service provider has
provisioned the network in such a way that the Rendezvous Point (RP)
for a particular ASM group G is always between the receivers and the
sources. If the network is provisioned in this manner, the ingress
Provider Edge (PE) for (S,G) is always the same as the ingress PE for
the RP, and thus the Source Active auto-discovery (A-D) routes are
never needed. If it is known a priori that the network is
provisioned in this manner, mLDP in-band signaling can be supported
using a different set of procedures, as specified in [<a href="./rfc7438" title=""Multipoint LDP (mLDP) In-Band Signaling with Wildcards"">RFC7438</a>]. A
service provider will provision the PE routers to use either the
procedures in [<a href="./rfc7438" title=""Multipoint LDP (mLDP) In-Band Signaling with Wildcards"">RFC7438</a>] or those described in this document.
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
Like [<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>], each IP multicast tree is mapped one-to-one to a P2MP
LSP in the MPLS network. This type of service works well if the
number of LSPs that are created is under the control of the MPLS
network operator, or if the number of LSPs for a particular service
is known to be limited.
It is to be noted that the existing BGP Multicast VPN (MVPN)
procedures [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>] can be used to map Internet IP multicast trees
to P2MP LSPs. These procedures would accomplish this for IP
multicast trees created by PIM-SM in SSM mode, as well as for IP
multicast trees created by PIM-SM in ASM mode. Furthermore, these
procedures would also support the ability to aggregate multiple IP
multicast trees to one P2MP LSP in the MPLS network. The details of
this particular approach are out of scope for this document.
This document assumes that a given LSR may have some interfaces that
are IP multicast capable, while other interfaces would be MPLS
capable.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Specification of Requirements</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">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees</span>
This mechanism does not transit IP multicast shared trees over the
MPLS network. Therefore, when an LSR creates (*,G) state (as a
result of receiving PIM messages on one of its IP multicast
interfaces), the LSR does not propagate this state in mLDP.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Originating Source Active Auto-discovery Routes (Mechanism 1)</span>
Whenever (as a result of receiving either PIM Register or Multicast
Source Discovery Protocol (MSDP) messages) an RP discovers a new
multicast source, the RP SHOULD originate a Source Active
auto-discovery route. The route carries a single MCAST-VPN Network
Layer Reachability Information (NLRI) [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>], constructed as
follows:
+ The Route Distinguisher (RD) in this NLRI is set to 0.
+ The Multicast Source field is set to S. This could be either an
IPv4 or an IPv6 address. The Multicast Source Length field is set
appropriately to reflect the address type.
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
+ The Multicast Group field is set to G. This could be either an
IPv4 or an IPv6 address. The Multicast Group Length field is set
appropriately to reflect this address type.
To constrain distribution of the Source Active auto-discovery route
to the Autonomous System (AS) of the advertising RP, this route
SHOULD carry the NO_EXPORT Community ([<a href="./rfc1997" title=""BGP Communities Attribute"">RFC1997</a>]).
Using the normal BGP procedures, the Source Active auto-discovery
route is propagated to all other LSRs within the AS.
Whenever the RP discovers that the source is no longer active, the RP
MUST withdraw the Source Active auto-discovery route if such a route
was previously advertised by the RP.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Receiving Source Active Auto-discovery Routes by LSR</span>
Consider an LSR that has some of its interfaces capable of IP
multicast and some capable of MPLS multicast.
When, as a result of receiving PIM messages on one of its IP
multicast interfaces, an LSR creates in its Tree Information Base
(TIB) a new (*,G) entry with a non-empty outgoing interface list that
contains one or more IP multicast interfaces, the LSR MUST check to
see if it has any Source Active auto-discovery routes for that G. If
there is such a route, S of that route is reachable via an MPLS
interface, and the LSR does not have (S,G) state in its TIB for (S,G)
carried in the route, then the LSR originates the mLDP Label Map with
the Transit IPv4/IPv6 Source TLV carrying (S,G), as specified in
[<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>].
When an LSR receives a new Source Active auto-discovery route, the
LSR MUST check to see if its TIB contains a (*,G) entry with the same
G as that carried in the Source Active auto-discovery route. If such
an entry is found, S is reachable via an MPLS interface, and the LSR
does not have (S,G) state in its TIB for (S,G) carried in the route,
then the LSR originates an mLDP Label Map with the Transit IPv4/IPv6
Source TLV carrying (S,G), as specified in [<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>].
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Handling (S,G,RPT-bit) State</span>
The creation and deletion of (S,G,RPT-bit) PIM state ([<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>]) on
an LSR that resulted from receiving PIM messages on one of its IP
multicast interfaces do not result in any mLDP and/or BGP actions by
the LSR.
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees</span>
This mechanism enables transit of IP multicast shared trees over the
MPLS network. Therefore, when an LSR creates (*,G) state as a result
of receiving PIM messages on one of its IP multicast interfaces, the
LSR propagates this state in mLDP, as described below.
Note that in the deployment scenarios where, for a given G, none of
the PEs originate an (S,G) mLDP Label Map with the Transit IPv4/IPv6
Source TLV, no Source Active auto-discovery routes will be used. One
other scenario where no Source Active auto-discovery routes will be
used is described in <a href="#section-3.2">Section 3.2</a> ("Originating Source Active
Auto-discovery Routes (Mechanism 2)"). In all of these scenarios,
the only part of Mechanism 2 that is used is the in-band signaling
for IP Multicast Shared Trees, as described in the next section.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. In-Band Signaling for IP Multicast Shared Trees</span>
To provide support for in-band mLDP signaling of IP multicast shared
trees, this document defines two new mLDP TLVs: the Transit IPv4
Shared Tree TLV and the Transit IPv6 Shared Tree TLV.
These two TLVs have exactly the same encoding/format as the IPv4/IPv6
Source Tree TLVs defined in [<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>], except that instead of the
Source field they have an RP field that carries the address of the
RP, as follows:
Transit IPv4 Shared Tree TLV:
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 | Length | RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11
Length: 8
RP: IPv4 RP address, 4 octets.
Group: IPv4 multicast group address, 4 octets.
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
Transit IPv6 Shared Tree TLV:
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 | Length | RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 12
Length: 32
RP: IPv6 RP address, 16 octets.
Group: IPv6 multicast group address, 16 octets.
Procedures for in-band signaling for IP multicast shared trees with
mLDP follow the same procedures as those for in-band signaling for
IP multicast source trees, as specified in [<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>], except that
while the latter signals (S,G) state using Transit IPv4/IPv6 Source
TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared
Tree TLVs.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Originating Source Active Auto-discovery Routes (Mechanism 2)</span>
Consider an LSR that has some of its interfaces capable of IP
multicast and some capable of MPLS multicast.
Whenever such an LSR creates an (S,G) state as a result of receiving
an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G),
the LSR MUST originate a Source Active auto-discovery route if all of
the following are true:
+ S is reachable via one of the IP-multicast-capable interfaces,
+ the LSR determines that G is in the PIM-SM in ASM mode range, and
+ the LSR does not have a (*,G) state with one of the IP-multicast-
capable interfaces as an incoming interface (iif) for that state.
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
The route carries a single MCAST-VPN NLRI, constructed as follows:
+ The RD in this NLRI is set to 0.
+ The Multicast Source field is set to S. The Multicast Source
Length field is set appropriately to reflect this address type.
+ The Multicast Group field is set to G. The Multicast Group Length
field is set appropriately to reflect this address type.
To constrain distribution of the Source Active auto-discovery route
to the AS of the advertising LSR, this route SHOULD carry the
NO_EXPORT Community ([<a href="./rfc1997" title=""BGP Communities Attribute"">RFC1997</a>]).
Using the normal BGP procedures, the Source Active auto-discovery
route is propagated to all other LSRs within the AS.
Whenever the LSR receiving an mLDP Label Map with the Transit
IPv4/IPv6 Source TLV for (S,G) deletes the (S,G) state that was
previously created, the LSR that deletes the state MUST also withdraw
the Source Active auto-discovery route, if such a route was
advertised when the state was created.
Note that whenever an LSR creates an (S,G) state as a result of
receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for
(S,G) with S reachable via one of the IP-multicast-capable
interfaces, and the LSR already has a (*,G) state with the RP
reachable via one of the IP-multicast-capable interfaces as a result
of receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree
TLV for (*,G), the LSR does not originate a Source Active
auto-discovery route.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Receiving Source Active Auto-discovery Routes</span>
Procedures for receiving Source Active auto-discovery routes are the
same as those for Mechanism 1.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Pruning Sources Off the Shared Tree</span>
If, after receiving a new Source Active auto-discovery route for
(S,G), the LSR determines that (a) it has the (*,G) entry in its TIB,
(b) the incoming interface (iif) list for that entry contains one of
the IP interfaces, (c) at least one of the MPLS interfaces is in the
outgoing interface (oif) list for that entry, and (d) the LSR does
not originate an mLDP Label Mapping message for (S,G) with the
Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the
(S,G,RPT-bit) downstream state to the Prune state. (Conceptually,
the PIM state machine on the LSR will act "as if" it had received
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
Prune(S,G,rpt) on one of its MPLS interfaces, without actually having
received one.) Depending on the (S,G,RPT-bit) state on the iif, this
may result in the LSR using PIM procedures to prune S off the Shared
(*,G) tree.
The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the
Prune state for as long as (a) the outgoing interface (oif) list for
(*,G) contains one of the MPLS interfaces, (b) the LSR has at least
one Source Active auto-discovery route for (S,G), and (c) the LSR
does not originate the mLDP Label Mapping message for (S,G) with the
Transit IPv4/IPv6 Source TLV. Once one or more of these conditions
become no longer valid, the LSR MUST transition the (S,G,RPT-bit)
downstream state machine to the NoInfo state.
Note that except for the scenario described in the first paragraph of
this section, it is sufficient to rely solely on the PIM procedures
on the LSR to ensure the correct behavior when pruning sources off
the shared tree.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. More on Handling (S,G,RPT-bit) State</span>
The creation and deletion of (S,G,RPT-bit) state on an LSR that
resulted from receiving PIM messages on one of its IP multicast
interfaces do not result in any mLDP and/or BGP actions by the LSR.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
IANA maintains a registry called "Label Distribution Protocol (LDP)
Parameters" with a subregistry called "LDP MP Opaque Value Element
basic type". IANA has allocated two new values, as follows:
Value | Name | Reference
------+------------------------------+------------
11 | Transit IPv4 Shared Tree TLV | [<a href="./rfc7442">RFC7442</a>]
12 | Transit IPv6 Shared Tree TLV | [<a href="./rfc7442">RFC7442</a>]
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
All of the security considerations for mLDP ([<a href="./rfc6388" title=""Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6388</a>]) apply here.
From the security considerations point of view, the use of Shared
Tree TLVs is no different than the use of Source TLVs [<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>].
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</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-RFC1997">RFC1997</a>] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", <a href="./rfc1997">RFC 1997</a>, August 1996,
<<a href="http://www.rfc-editor.org/info/rfc1997">http://www.rfc-editor.org/info/rfc1997</a>>.
[<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 href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<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,
<<a href="http://www.rfc-editor.org/info/rfc4601">http://www.rfc-editor.org/info/rfc4601</a>>.
[<a id="ref-RFC6388">RFC6388</a>] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", <a href="./rfc6388">RFC 6388</a>, November 2011,
<<a href="http://www.rfc-editor.org/info/rfc6388">http://www.rfc-editor.org/info/rfc6388</a>>.
[<a id="ref-RFC6514">RFC6514</a>] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", <a href="./rfc6514">RFC 6514</a>, February 2012,
<<a href="http://www.rfc-editor.org/info/rfc6514">http://www.rfc-editor.org/info/rfc6514</a>>.
[<a id="ref-RFC6826">RFC6826</a>] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M.
Napierala, "Multipoint LDP In-Band Signaling for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", <a href="./rfc6826">RFC 6826</a>, January 2013,
<<a href="http://www.rfc-editor.org/info/rfc6826">http://www.rfc-editor.org/info/rfc6826</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC4607">RFC4607</a>] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", <a href="./rfc4607">RFC 4607</a>, August 2006, <<a href="http://www.rfc-editor.org/info/rfc4607">http://www.rfc-editor.org/</a>
<a href="http://www.rfc-editor.org/info/rfc4607">info/rfc4607</a>>.
[<a id="ref-RFC7438">RFC7438</a>] Wijnands, IJ., Ed., Rosen, E., Gulko, A., Joorde, U., and
J. Tantsura, "Multipoint LDP (mLDP) In-Band Signaling
with Wildcards", <a href="./rfc7438">RFC 7438</a>, January 2015,
<<a href="http://www.rfc-editor.org/info/rfc7438">http://www.rfc-editor.org/info/rfc7438</a>>.
<span class="grey">Rekhter, 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="./rfc7442">RFC 7442</a> PIM-SM over P2MP mLDP LSPs February 2015</span>
Acknowledgements
The use of Source Active auto-discovery routes was borrowed from
[<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>]. Some text in this document was borrowed from [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>].
Some of the text in this document was borrowed from [<a href="./rfc6826" title=""Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6826</a>].
We would like to acknowledge Arkadiy Gulko for his review and
comments.
We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati,
and Adrian Farrel for their review and comments.
Authors' Addresses
Yakov Rekhter
Juniper Networks, Inc.
EMail: yakov@juniper.net
Rahul Aggarwal
Arktan
EMail: raggarwa_1@yahoo.com
Nicolai Leymann
Deutsche Telekom
Winterfeldtstrasse 21
Berlin 10781
Germany
EMail: N.Leymann@telekom.de
Wim Henderickx
Alcatel-Lucent
EMail: wim.henderickx@alcatel-lucent.com
Quintin Zhao
Huawei
EMail: quintin.zhao@huawei.com
Richard Li
Huawei
EMail: renwei.li@huawei.com
Rekhter, et al. Standards Track [Page 11]
</pre>
|
