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) D. Frost
Request for Comments: 7167 Blue Sun
Category: Informational S. Bryant
ISSN: 2070-1721 Cisco Systems
M. Bocci
Alcatel-Lucent
L. Berger
LabN Consulting
April 2014
<span class="h1">A Framework for Point-to-Multipoint MPLS in Transport Networks</span>
Abstract
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the
common set of MPLS protocol functions defined to enable the
construction and operation of packet transport networks. The MPLS-TP
supports both point-to-point and point-to-multipoint transport paths.
This document defines the elements and functions of the MPLS-TP
architecture that are applicable specifically to supporting point-to-
multipoint transport paths.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <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/rfc7167">http://www.rfc-editor.org/info/rfc7167</a>.
<span class="grey">Frost, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
Copyright Notice
Copyright (c) 2014 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>. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Applicability . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. MPLS-TP P2MP Requirements . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Architecture . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Operations, Administration, and Maintenance . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. P2MP LSP Control Plane . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. P2MP PW Control Plane . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Survivability . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. Network Management . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<span class="grey">Frost, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the
common set of MPLS protocol functions defined to meet the
requirements specified in [<a href="./rfc5654" title=""Requirements of an MPLS Transport Profile"">RFC5654</a>]. The MPLS-TP Framework [<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>]
provides an overall introduction to the MPLS-TP and defines the
general architecture of the Transport Profile, as well as the aspects
specific to point-to-point transport paths. The purpose of this
document is to define the elements and functions of the MPLS-TP
architecture applicable specifically to supporting point-to-
multipoint transport paths.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Scope</span>
This document defines the elements and functions of the MPLS-TP
architecture related to supporting point-to-multipoint transport
paths. The reader is referred to [<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>] for the aspects of the
MPLS-TP architecture that are generic or are concerned specifically
with point-to-point transport paths.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
Term Definition
------- ---------------------------------------------------
CE Customer Edge
LSP Label Switched Path
LSR Label Switching Router
MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
MPLS-TE MPLS Traffic Engineering
MPLS-TP MPLS Transport Profile
OAM Operations, Administration, and Maintenance
OTN Optical Transport Network
P2MP Point-to-multipoint
PW Pseudowire
RSVP-TE Resource Reservation Protocol - Traffic Engineering
SDH Synchronous Digital Hierarchy
tLDP Targeted LDP
Detailed definitions and additional terminology may be found in
[<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>] and [<a href="./rfc5654" title=""Requirements of an MPLS Transport Profile"">RFC5654</a>].
<span class="grey">Frost, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Applicability</span>
The point-to-multipoint connectivity provided by an MPLS-TP network
is based on the point-to-multipoint connectivity provided by MPLS
networks. Traffic Engineered P2MP LSP support is discussed in
[<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>] and [<a href="./rfc5332" title=""MPLS Multicast Encapsulations"">RFC5332</a>], and P2MP PW support is being developed based
on [<a href="#ref-P2MP-PW-REQS">P2MP-PW-REQS</a>] and [<a href="#ref-VPMS-FRMWK-REQS">VPMS-FRMWK-REQS</a>]. MPLS-TP point-to-multipoint
connectivity is analogous to that provided by traditional transport
technologies such as Optical Transport Network point-to-multipoint
[<a href="#ref-G.798" title=""Characteristics of optical transport network hierarchy equipment functional blocks"">G.798</a>] and drop-and-continue [<a href="#ref-G.780" title=""Terms and definitions for synchronous digital hierarchy (SDH) networks"">G.780</a>], and thus supports the same
class of traditional applications, e.g., video distribution.
The scope of this document is limited to point-to-multipoint
functions and it does not discuss multipoint-to-multipoint support.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. MPLS-TP P2MP Requirements</span>
The requirements for MPLS-TP are specified in [<a href="./rfc5654" title=""Requirements of an MPLS Transport Profile"">RFC5654</a>], [<a href="./rfc5860" title=""Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks"">RFC5860</a>],
and [<a href="./rfc5951" title=""Network Management Requirements for MPLS-based Transport Networks"">RFC5951</a>]. This section provides a brief summary of point-to-
multipoint transport requirements as set out in those documents; the
reader is referred to the documents themselves for the definitive and
complete list of requirements. This summary does not include the <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> [<a href="#ref-BCP14" title=""Key words for use in RFCs to Indicate Requirement Levels"">BCP14</a>] conformance language used in the original documents as
this document is not authoritative.
From [<a href="./rfc5654" title=""Requirements of an MPLS Transport Profile"">RFC5654</a>]:
o MPLS-TP must support traffic-engineered point-to-multipoint
transport paths.
o MPLS-TP must support unidirectional point-to-multipoint transport
paths.
o MPLS-TP must be capable of using P2MP server (sub)layer
capabilities as well as P2P server (sub)layer capabilities when
supporting P2MP MPLS-TP transport paths.
o The MPLS-TP control plane must support establishing all the
connectivity patterns defined for the MPLS-TP data plane (i.e.,
unidirectional P2P, associated bidirectional P2P, co-routed
bidirectional P2P, unidirectional P2MP) including configuration of
protection functions and any associated maintenance functions.
o Recovery techniques used for P2P and P2MP should be identical to
simplify implementation and operation.
o Unidirectional 1+1 and 1:n protection for P2MP connectivity must
be supported.
<span class="grey">Frost, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
o MPLS-TP recovery in a ring must protect unidirectional P2MP
transport paths.
From [<a href="./rfc5860" title=""Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks"">RFC5860</a>]:
o The protocol solution(s) developed to perform the following OAM
functions must also apply to point-to-point associated
bidirectional LSPs, point-to-point unidirectional LSPs, and point-
to-multipoint LSPs:
* Continuity Check
* Connectivity Verification, proactive
* Lock Instruct
* Lock Reporting
* Alarm Reporting
* Client Failure Indication
* Packet Loss Measurement
* Packet Delay Measurement
o The protocol solution(s) developed to perform the following OAM
functions may also apply to point-to-point associated
bidirectional LSPs, point-to-point unidirectional LSPs, and point-
to-multipoint LSPs:
* Connectivity Verification, on-demand
* Route Tracing
* Diagnostic Tests
* Remote Defect Indication
From [<a href="./rfc5951" title=""Network Management Requirements for MPLS-based Transport Networks"">RFC5951</a>]:
o For unidirectional (P2P and point-to-multipoint (P2MP))
connection, proactive measurement of packet loss and loss ratio is
required.
o For a unidirectional (P2P and P2MP) connection, on-demand
measurement of delay measurement is required.
<span class="grey">Frost, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Architecture</span>
The overall architecture of the MPLS-TP is defined in [<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>]. The
architecture for point-to-multipoint MPLS-TP comprises the following
additional elements and functions:
o Unidirectional point-to-multipoint LSPs
o Unidirectional point-to-multipoint PWs
o Optional point-to-multipoint LSP and PW control planes
o Survivability, network management, and Operations, Administration,
and Maintenance functions for point-to-multipoint PWs and LSPs.
The following subsection summarises the encapsulation and forwarding
of point-to-multipoint traffic within an MPLS-TP network, and the
encapsulation options for delivery of traffic to and from MPLS-TP CE
devices when the network is providing a packet transport service.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. MPLS-TP Encapsulation and Forwarding</span>
Packet encapsulation and forwarding for MPLS-TP point-to-multipoint
LSPs is identical to that for MPLS-TE point-to-multipoint LSPs.
MPLS-TE point-to-multipoint LSPs were introduced in [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>] and the
related data-plane behaviour was further clarified in [<a href="./rfc5332" title=""MPLS Multicast Encapsulations"">RFC5332</a>].
MPLS-TP allows for both upstream-assigned and downstream-assigned
labels for use with point-to-multipoint LSPs.
Packet encapsulation and forwarding for point-to-multipoint PWs has
been discussed within the PWE3 Working Group [<a href="#ref-P2MP-PW-ENCAPS">P2MP-PW-ENCAPS</a>], but
such definition is for further study.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Operations, Administration, and Maintenance</span>
The requirements for MPLS-TP OAM are specified in [<a href="./rfc5860" title=""Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks"">RFC5860</a>]. The
overall OAM architecture for MPLS-TP is defined in [<a href="./rfc6371" title=""Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks"">RFC6371</a>], and
P2MP OAM design considerations are described in <a href="#section-3.7">Section 3.7</a> of that
RFC.
All the traffic sent over a P2MP transport path, including OAM
packets generated by a MEP, is sent (multicast) from the root towards
all the leaves, and thus may be processed by all the MIPs and MEPs
associated with a P2MP MEG. If an OAM packet is to be processed by
only a specific leaf, it requires information to indicate to all
other leaves that the packet must be discarded. To address a packet
to an intermediate node in the tree, Time-to-Live-based addressing is
used to set the radius and additional information in the OAM payload
<span class="grey">Frost, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
is used to identify the specific destination. It is worth noting
that a MIP and MEP may be instantiated on a single node when it is
both a branch and leaf node.
P2MP paths are unidirectional; therefore, any return path to an
originating MEP for on-demand transactions will be out of band. Out-
of-band return paths are discussed in <a href="./rfc5921#section-3.8">Section 3.8 of [RFC5921]</a>.
A more detailed discussion of P2MP OAM considerations can be found in
[<a href="#ref-MPLS-TP-P2MP-OAM">MPLS-TP-P2MP-OAM</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Control Plane</span>
The framework for the MPLS-TP control plane is provided in [<a href="./rfc6373" title=""MPLS Transport Profile (MPLS-TP) Control Plane Framework"">RFC6373</a>].
This document reviews MPLS-TP control-plane requirements as well as
provides details on how the MPLS-TP control plane satisfies these
requirements. Most of the requirements identified in [<a href="./rfc6373" title=""MPLS Transport Profile (MPLS-TP) Control Plane Framework"">RFC6373</a>] apply
equally to P2P and P2MP transport paths. The key P2MP-specific
control-plane requirements are:
o requirement 6 (P2MP transport paths),
o requirement 34 (use P2P sub-layers),
o requirement 49 (common recovery solutions for P2P and P2MP),
o requirement 59 (1+1 protection),
o requirement 62 (1:n protection), and
o requirement 65 (1:n shared mesh recovery).
[<a id="ref-RFC6373">RFC6373</a>] defines the control-plane approach used to support MPLS-TP
transport paths. It identifies GMPLS as the control plane for MPLS-
TP LSPs and tLDP as the control plane for PWs. MPLS-TP allows that
either, or both, LSPs and PWs to be provisioned statically or via a
control plane. Quoting from [<a href="./rfc6373" title=""MPLS Transport Profile (MPLS-TP) Control Plane Framework"">RFC6373</a>]:
The PW and LSP control planes, collectively, must satisfy the
MPLS-TP control-plane requirements. As with P2P services, when
P2MP client services are provided directly via LSPs, all
requirements must be satisfied by the LSP control plane. When
client services are provided via PWs, the PW and LSP control
planes can operate in combination, and some functions may be
satisfied via the PW control plane while others are provided to
PWs by the LSP control plane. This is particularly noteworthy for
P2MP recovery.
<span class="grey">Frost, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. P2MP LSP Control Plane</span>
The MPLS-TP control plane for P2MP LSPs uses GMPLS and is based on
RSVP-TE for P2MP LSPs as defined in [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]. A detailed listing of
how GMPLS satisfies MPLS-TP control-plane requirements is provided in
[<a href="./rfc6373" title=""MPLS Transport Profile (MPLS-TP) Control Plane Framework"">RFC6373</a>].
[<a id="ref-RFC6373">RFC6373</a>] notes that recovery techniques for traffic engineered P2MP
LSPs are not formally defined, and that such a definition is needed.
A formal definition will be based on existing RFCs and may not
require any new protocol mechanisms but, nonetheless, should be
documented. GMPLS recovery is defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>].
Protection of P2MP LSPs is also discussed in <a href="./rfc6372#section-4.7.3">[RFC6372] Section 4.7.3</a>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. P2MP PW Control Plane</span>
The MPLS-TP control plane for P2MP PWs should be based on the LDP
control protocol used for point-to-point PWs [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], with updates
as required for P2MP applications. A detailed specification of the
control plane for P2MP PWs is for further study.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Survivability</span>
The overall survivability architecture for MPLS-TP is defined in
[<a href="./rfc6372" title=""MPLS Transport Profile (MPLS- TP) Survivability Framework"">RFC6372</a>], and <a href="#section-4.7.3">Section 4.7.3</a> of that RFC in particular describes the
application of linear protection to unidirectional P2MP entities
using 1+1 and 1:1 protection architecture. For 1+1, the approach is
for the root of the P2MP tree to bridge the user traffic to both the
working and protection entities. Each sink/leaf MPLS-TP node selects
the traffic from one entity according to some predetermined criteria.
For 1:1, the source/root MPLS-TP node needs to identify the existence
of a fault condition impacting delivery to any of the leaves. Fault
notification happens from the node identifying the fault to the root
node via an out-of-band path. The root then selects the protection
transport path for traffic transfer. More sophisticated
survivability approaches such as partial tree protection and 1:n
protection are for further study.
The IETF has no experience with P2MP PW survivability as yet;
therefore, it is proposed that the P2MP PW survivability will
initially rely on the LSP survivability. Further work is needed on
this subject, particularly if a requirement emerges to provide
survivability for P2MP PWs in an MPLS-TP context.
<span class="grey">Frost, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Network Management</span>
An overview of network management considerations for MPLS-TP can be
found in <a href="./rfc5921#section-3.14">Section 3.14 of [RFC5921]</a>. The provided description applies
equally to P2MP transport paths.
The network management architecture and requirements for MPLS-TP are
specified in [<a href="./rfc5951" title=""Network Management Requirements for MPLS-based Transport Networks"">RFC5951</a>]. They derive from the generic specifications
described in ITU-T G.7710/Y.1701 [<a href="#ref-G.7710" title=""Common equipment management function requirements"">G.7710</a>] for transport technologies.
They also incorporate the OAM requirements for MPLS networks
[<a href="./rfc4377" title=""Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks"">RFC4377</a>] and MPLS-TP networks [<a href="./rfc5860" title=""Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks"">RFC5860</a>] and expand on those
requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network.
[<a href="./rfc5951" title=""Network Management Requirements for MPLS-based Transport Networks"">RFC5951</a>] covers all MPLS-TP connection types, including P2MP.
[<a id="ref-RFC6639">RFC6639</a>] provides the MIB-based architecture for MPLS-TP. It
reviews the interrelationships between different MIB modules that are
not MPLS-TP specific and that can be leveraged for MPLS-TP network
management, and identifies areas where additional MIB modules are
required. While the document does not consider P2MP transport paths,
it does provide a foundation for an analysis of areas where MIB-
module modification and addition may be needed to fully support P2MP
transport paths. There has also been work in the MPLS working group
on a P2MP specific MIB, [<a href="#ref-MPLS-TE-P2MP-MIB">MPLS-TE-P2MP-MIB</a>].
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
General security considerations for MPLS-TP are covered in [<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>].
Additional security considerations for P2MP LSPs are provided in
[<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]. This document introduces no new security considerations
beyond those covered in those documents.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC4872">RFC4872</a>] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", <a href="./rfc4872">RFC 4872</a>, May
2007.
[<a id="ref-RFC4873">RFC4873</a>] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", <a href="./rfc4873">RFC 4873</a>, May 2007.
[<a id="ref-RFC4875">RFC4875</a>] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", <a href="./rfc4875">RFC 4875</a>, May 2007.
<span class="grey">Frost, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
[<a id="ref-RFC5332">RFC5332</a>] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", <a href="./rfc5332">RFC 5332</a>, August 2008.
[<a id="ref-RFC5654">RFC5654</a>] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
<a href="./rfc5654">RFC 5654</a>, September 2009.
[<a id="ref-RFC5921">RFC5921</a>] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", <a href="./rfc5921">RFC</a>
<a href="./rfc5921">5921</a>, July 2010.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-BCP14">BCP14</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-G.7710">G.7710</a>] ITU-T, "Common equipment management function
requirements", ITU-T G.7710/Y.1701, July 2007.
[<a id="ref-G.780">G.780</a>] ITU-T, "Terms and definitions for synchronous digital
hierarchy (SDH) networks", ITU-T G.780/Y.1351, July 2010.
[<a id="ref-G.798">G.798</a>] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", ITU-T G.798,
December 2012.
[<a id="ref-MPLS-TE-P2MP-MIB">MPLS-TE-P2MP-MIB</a>]
Farrel, A., Yasukawa, S., and T. Nadeau, "Point-to-
Multipoint Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)
module", Work in Progress, April 2009.
[<a id="ref-MPLS-TP-P2MP-OAM">MPLS-TP-P2MP-OAM</a>]
Arai, K., Koike, Y., Hamano, T., and M. Namiki, "Framework
for Point-to-Multipoint MPLS-TP OAM", Work in Progress,
January 2014.
[<a id="ref-P2MP-PW-ENCAPS">P2MP-PW-ENCAPS</a>]
Aggarwal, R. and F. Jounay, "Point-to-Multipoint Pseudo-
Wire Encapsulation", Work in Progress, March 2010.
[<a id="ref-P2MP-PW-REQS">P2MP-PW-REQS</a>]
Jounay, F., Kamite, Y., Heron, G., and M. Bocci,
"Requirements and Framework for Point-to-Multipoint
Pseudowires over MPLS PSNs", Work in Progress, February
2014.
<span class="grey">Frost, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
[<a id="ref-RFC4377">RFC4377</a>] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks", <a href="./rfc4377">RFC</a>
<a href="./rfc4377">4377</a>, February 2006.
[<a id="ref-RFC4447">RFC4447</a>] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April 2006.
[<a id="ref-RFC5860">RFC5860</a>] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", <a href="./rfc5860">RFC 5860</a>, May 2010.
[<a id="ref-RFC5951">RFC5951</a>] Lam, K., Mansfield, S., and E. Gray, "Network Management
Requirements for MPLS-based Transport Networks", <a href="./rfc5951">RFC 5951</a>,
September 2010.
[<a id="ref-RFC6371">RFC6371</a>] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
<a href="./rfc6371">RFC 6371</a>, September 2011.
[<a id="ref-RFC6372">RFC6372</a>] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
TP) Survivability Framework", <a href="./rfc6372">RFC 6372</a>, September 2011.
[<a id="ref-RFC6373">RFC6373</a>] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
Framework", <a href="./rfc6373">RFC 6373</a>, September 2011.
[<a id="ref-RFC6639">RFC6639</a>] King, D. and M. Venkatesan, "Multiprotocol Label Switching
Transport Profile (MPLS-TP) MIB-Based Management
Overview", <a href="./rfc6639">RFC 6639</a>, June 2012.
[<a id="ref-VPMS-FRMWK-REQS">VPMS-FRMWK-REQS</a>]
Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", Work in Progress,
October 2012.
<span class="grey">Frost, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7167">RFC 7167</a> MPLS Transport Profile P2MP Framework April 2014</span>
Authors' Addresses
Dan Frost
Blue Sun
EMail: frost@mm.st
Stewart Bryant
Cisco Systems
EMail: stbryant@cisco.com
Matthew Bocci
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ
United Kingdom
EMail: matthew.bocci@alcatel-lucent.com
Lou Berger
LabN Consulting
Phone: +1-301-468-9228
EMail: lberger@labn.net
Frost, et al. Informational [Page 12]
</pre>
|
