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
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) Y. Weingarten
Request for Comments: 7412
Category: Informational S. Aldrin
ISSN: 2070-1721 Huawei Technologies
P. Pan
Infinera
J. Ryoo
ETRI
G. Mirsky
Ericsson
December 2014
<span class="h1">Requirements for MPLS Transport Profile (MPLS-TP)</span>
<span class="h1">Shared Mesh Protection</span>
Abstract
This document presents the basic network objectives for the behavior
of Shared Mesh Protection (SMP) that are not based on control-plane
support. This document provides an expansion of the basic
requirements presented in <a href="./rfc5654">RFC 5654</a> ("Requirements of an MPLS
Transport Profile") and <a href="./rfc6372">RFC 6372</a> ("MPLS Transport Profile (MPLS-TP)
Survivability Framework"). This document provides requirements for
any mechanism that would be used to implement SMP for MPLS-TP data
paths, in networks that delegate protection switch coordination to
the data plane.
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/rfc7412">http://www.rfc-editor.org/info/rfc7412</a>.
<span class="grey">Weingarten, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 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-2">2</a>. Terminology and Notation ........................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Acronyms and Terminology ...................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Shared Mesh Protection Reference Model ..........................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Protection or Restoration ..................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Scope of Document ..........................................<a href="#page-5">5</a>
<a href="#section-3.2.1">3.2.1</a>. Relationship to MPLS ................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. SMP Architecture ................................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Coordination of Resources ..................................<a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Control Plane or Data Plane ................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. SMP Network Objectives ..........................................<a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Resource Reservation and Coordination ......................<a href="#page-9">9</a>
5.1.1. Checking Resource Availability for Multiple
Protection Paths ....................................<a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Multiple Triggers .........................................<a href="#page-10">10</a>
<a href="#section-5.2.1">5.2.1</a>. Soft Preemption ....................................<a href="#page-10">10</a>
<a href="#section-5.2.2">5.2.2</a>. Hard Preemption ....................................<a href="#page-10">10</a>
<a href="#section-5.3">5.3</a>. Notification ..............................................<a href="#page-11">11</a>
<a href="#section-5.4">5.4</a>. Reversion .................................................<a href="#page-11">11</a>
<a href="#section-5.5">5.5</a>. Protection Switching Time .................................<a href="#page-11">11</a>
<a href="#section-5.6">5.6</a>. Timers ....................................................<a href="#page-12">12</a>
<a href="#section-5.7">5.7</a>. Communication Channel and Fate-Sharing ....................<a href="#page-12">12</a>
<a href="#section-6">6</a>. Manageability Considerations ...................................<a href="#page-13">13</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-13">13</a>
<a href="#section-8">8</a>. Normative References ...........................................<a href="#page-13">13</a>
Acknowledgements ..................................................<a href="#page-15">15</a>
Contributors ......................................................<a href="#page-15">15</a>
Authors' Addresses ................................................<a href="#page-16">16</a>
<span class="grey">Weingarten, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The MPLS Transport Profile (MPLS-TP) is described in [<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>].
[<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>] provides a survivability framework for MPLS-TP and is the
foundation for this document.
Terminology for recovery of connectivity in networks is provided in
[<a href="./rfc4427" title=""Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4427</a>] and includes the concept of surviving network faults
(survivability) through the use of re-established connections
(restoration) and switching of traffic to pre-established backup
paths (protection). MPLS provides control-plane tools to support
various survivability schemes, some of which are identified in
[<a href="./rfc4426" title=""Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification"">RFC4426</a>]. In addition, recent efforts in the IETF have started
providing for data-plane tools to address aspects of data protection.
In particular, [<a href="./rfc6378" title=""MPLS Transport Profile (MPLS-TP) Linear Protection"">RFC6378</a>] and [<a href="./rfc7271" title=""MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators"">RFC7271</a>] define a set of triggers and
coordination protocols for 1:1 and 1+1 linear protection of point-to-
point paths.
When considering a full-mesh network and the protection of different
paths that traverse the mesh, it is possible to provide an acceptable
level of protection while conserving the amount of protection
resources needed to protect the different data paths. As pointed out
in [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>] and [<a href="./rfc4427" title=""Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4427</a>], applying 1+1 protection requires that
resources are allocated for use by both the working and protection
paths. Applying 1:1 protection requires that the same resources are
allocated but allows the resources of the protection path to be
utilized for preemptible extra traffic. Extending this to 1:n or m:n
protection allows the resources of the protection path to be shared
in the protection of several working paths. However, 1:n or m:n
protection architecture is limited by the restriction that all of the
n+1 or m+n paths must have the same endpoints. m:n protection
architecture provides m protection paths to protect n working paths,
where m or n can be 1.
This document provides requirements for any mechanism that would be
used to implement SMP for MPLS-TP data paths, in networks that
delegate protection switch coordination to the data plane.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology and Notation</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>].
Although this document is not a protocol specification, the use of
this language clarifies the instructions to protocol designers
producing solutions that satisfy the requirements set out in this
document.
<span class="grey">Weingarten, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
The terminology used in this document is based on the terminology
defined in the MPLS-TP Survivability Framework document [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>],
which in turn is based on [<a href="./rfc4427" title=""Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4427</a>].
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Acronyms and Terminology</span>
This document uses the following acronyms:
LSP Label Switched Path
SLA Service Level Agreement
SMP Shared Mesh Protection
SRLG Shared Risk Link Group
This document defines the following term:
SMP Protection Group: the set of different protection paths that
share a common segment.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Shared Mesh Protection Reference Model</span>
As described in [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>], SMP supports the sharing of protection
resources, while providing protection for multiple working paths that
need not have common endpoints and do not share common points of
failure. Note that some protection resources may be shared, while
some others may not be. An example of data paths that employ SMP is
shown in Figure 1. It shows two working paths -- <ABCDE> and <VWXYZ>
-- that are protected employing 1:1 linear protection by protection
paths <APQRE> and <VPQRZ>, respectively. The two protection paths
that traverse segment <PQR> share the protection resources on this
segment.
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
Figure 1: Basic SMP Architecture
<span class="grey">Weingarten, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Protection or Restoration</span>
[<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>], based upon the definitions in [<a href="./rfc4427" title=""Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4427</a>], differentiates
between "protection" and "restoration", depending on the dynamism of
the resource allocation. The same distinction is used in [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>],
[<a href="./rfc4426" title=""Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification"">RFC4426</a>], and [<a href="./rfc4428" title=""Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)"">RFC4428</a>].
This document also uses the same distinction between protection and
restoration as the distinction stated in [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Scope of Document</span>
[<a id="ref-RFC5654">RFC5654</a>] establishes that MPLS-TP SHOULD support shared protection
(Requirement 68) and that MPLS-TP MUST support sharing of protection
resources (Requirement 69). This document presents the network
objectives and a framework for applying SMP within an MPLS network,
without the use of control-plane protocols. Although there are
existing control-plane solutions for SMP within MPLS, a data-plane
solution is required for networks that do not employ a full control-
plane operation for some reason (e.g., service provider preferences
or limitations) or require service restoration faster than is
achievable with control-plane mechanisms.
The network objectives will also address possible additional
restrictions on the behavior of SMP in networks that delegate
protection switching for resiliency to the data plane. Definitions
of logic and specific protocol messaging are out of scope for this
document.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Relationship to MPLS</span>
While some of the restrictions presented by this document originate
from the properties of transport networks, nothing prevents the
information presented here from being applied to MPLS networks
outside the scope of the Transport Profile of MPLS.
<span class="grey">Weingarten, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. SMP Architecture</span>
Figure 1 shows a very basic configuration of working and protection
paths that may employ SMP. We may consider a slightly more complex
configuration, such as the one in Figure 2 in order to illustrate
characteristics of a mesh network that implements SMP.
A----B----C----D----E---N
\ / / \
\ M ---/-- \
\ / \ \
P-----Q-----R-----S----T
/| \ \ \ \
/ F---G---H J--K---L \
/ \
V------W-------X-------Y-------Z
Figure 2: Example of a Larger SMP Architecture
Consider the network presented in Figure 2. There are five working
paths:
- <ABCDE>
- <MDEN>
- <FGH>
- <JKL>
- <VWXYZ>
Each of these has a corresponding protection path:
- <APQRE> (p1)
- <MSTN> (p2)
- <FPQH> (p3)
- <JRSL> (p4)
- <VPQRSTZ> (p5)
<span class="grey">Weingarten, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
The following segments are shared by two or more of the protection
paths -- <PQ> is shared by p1, p3, and p5; <QR> is shared by p1 and
p5; <RS> is shared by p4 and p5; and <ST> is shared by p2 and p5. In
Figure 2, we have the following SMP Protection Groups -- {p1, p3, p5}
for <PQ>, {p1, p5} for <QR>, {p4, p5} for <RS>, and {p2, p5}
for <ST>.
We assume that the available protection resources for these shared
segments are not sufficient to support the complete traffic capacity
of the respective working paths that may use the protection paths.
We can further observe that with a method of coordinating sharing and
preemption, there are no co-routing constraints on shared components
at the segment level.
The use of preemption in the network is typically a business or
policy decision such that when protection resources are contested,
priority can be applied to determine which parties utilize the
protection resources.
As opposed to the case of simple linear protection, where the
relationship between the working and protection paths is defined and
the resources for the protection path are fully dedicated, the
protection path in the case of SMP consists of segments that are used
for the protection of the related working path and also segments that
are shared with other protection paths such that typically the
protection resources are oversubscribed to support working paths that
do not share common points of failure. What is required is a
preemption mechanism to implement business priority when multiple
failure scenarios occur. As such, the protection resources may be
allocated but would not be utilized until requested and resolved in
relation to other members of the SMP Protection Group as part of a
protection switchover.
[<a id="ref-RFC6372">RFC6372</a>] defines two types of preemption that can be considered for
how the resources of SMP Protection Groups are shared: "soft
preemption", where traffic of lower-priority paths is degraded; and
"hard preemption", where traffic of lower-priority paths is
completely blocked. The traffic of lower-priority paths in this
document can be viewed as the extra traffic being preempted, as
described in [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>]. "Hard preemption" requires the programming
of selectors at the ingress of each shared segment to specify the
priorities of backup paths, so that traffic of lower-priority paths
can be preempted. When any protection mechanism where the protection
endpoint may have a choice of protection paths (e.g., m:n or m:1) is
deployed, the shared segment selectors require coordination with the
protection endpoints as well.
<span class="grey">Weingarten, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
Typical deployment of services that use SMP requires various network
planning activities. These include the following:
o Determining the number of working and protection paths required to
achieve resiliency targets for the service.
o Reviewing network topology to determine which working or
protection paths are required to be disjoint from each other, and
excluding specified resources such as links, nodes, or shared risk
link groups (SRLGs).
o Determining the size (bandwidth) of the shared resource.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Coordination of Resources</span>
When a protection switch is triggered, the SMP network performs two
operations -- switching data traffic over to a protection path and
coordinating the utilization of the associated shared resources.
Both operations should occur at the same time, or as close together
as possible, to provide fast protection. The resource utilization
coordination is dependent upon their availability at each of the
shared segments.
When the reserved resources of the shared segments are utilized by a
particular protection path, there may not be sufficient resources
available for an additional protection path. This then implies that
if another working path of the SMP domain triggers a protection
switch, the resource utilization coordination may fail. The
different working paths in the SMP network are involved in the
resource utilization coordination, which is a part of a whole SMP
protection switching coordination.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Control Plane or Data Plane</span>
As stated in both [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>] and [<a href="./rfc4428" title=""Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)"">RFC4428</a>], full control of SMP,
including both configuration and the coordination of the protection
switching, is potentially very complex. Therefore, it is suggested
that this be carried out under the control of a dynamic control plane
based on Generalized MPLS (GMPLS) [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>]. Implementations for SMP
with GMPLS exist, and the general principles of its operation are
well known, if not fully documented.
However, there are operators, in particular in the transport sector,
that do not operate their MPLS-TP networks under the control of a
control plane or for other reasons have delegated executive action
for resilience to the data plane, and require the ability to utilize
<span class="grey">Weingarten, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
SMP protection. For such networks, it is imperative that it be
possible to perform all required coordination of selectors and
endpoints for SMP via data-plane operations.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SMP Network Objectives</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Resource Reservation and Coordination</span>
SMP is based on pre-configuration of the working paths and the
corresponding protection paths. This configuration may be based on
either a control protocol or static configuration by the management
system. However, even when the configuration is performed by a
control protocol, e.g., GMPLS, the control protocol SHALL NOT be used
as the primary mechanism for detecting or reporting network failures,
or for initiating or coordinating protection switchover. That is, it
SHALL NOT be used as the primary resilience mechanism.
The protection relationship between the working and protection paths
SHOULD be configured, and the shared segments of the protection path
MUST be identified prior to use of the protection paths. Relative
priority for working paths to be used to resolve contention for
protection path usage by multiple working paths MAY also be specified
ahead of time.
When a protection switch is triggered by any fault condition or
operator command, the SMP network MUST perform two operations --
switch data traffic over to a protection path, and coordinate the
utilization of the associated shared resources. To provide fast
protection, both operations MUST occur at the same time or as close
to the same time as possible.
In the case of multiple working paths failing, the shared resource
utilization coordination SHALL be between the different working paths
in the SMP network.
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Checking Resource Availability for Multiple Protection Paths</span>
In a hard-preemption scenario, when an endpoint identifies a
protection switching trigger and has more than one potential action
(e.g., m:1 protection), it MUST verify that the necessary protection
resources are available on the selected protection path. The
resources may not be available because they have already been
utilized for the protection of, for example, one or more higher-
priority working paths.
<span class="grey">Weingarten, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Multiple Triggers</span>
If more than one working path is triggering a protection switch such
that a protection segment is oversubscribed, there are two different
actions that the SMP network can choose -- soft preemption and hard
preemption [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>].
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Soft Preemption</span>
For networks that support multiplexing packets over the shared
segments, the requirement is as follows:
o All of the protection paths MAY be allowed to share the resources
of the shared segments.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Hard Preemption</span>
There are networks that require the exclusive use of the protection
resources when a protection segment is oversubscribed. Traffic of
lower-priority paths is completely blocked. These include networks
that support the requirements in [<a href="./rfc5654" title=""Requirements of an MPLS Transport Profile"">RFC5654</a>], and in particular support
Requirement 58. For such networks, the following requirements apply:
1. Relative priority MAY be assigned to each of the working paths of
an SMP domain. If the priority is not assigned, the working paths
are assumed to have equal priority.
2. Resources of the shared segments SHALL be utilized by the
protection path according to the highest priority amongst those
requesting use of the resources.
3. If multiple protection paths of equal priority are requesting the
shared resources, the resources SHALL be utilized on a first come
first served basis. Traffic of the protection paths that request
the shared resources late SHALL be preempted. In order to cover
the situation where the first come first served principle cannot
resolve the contention among multiple equal-priority requests,
i.e., when the requests occur simultaneously, tie-breaking rules
SHALL be defined in the scope of an SMP domain.
4. If a higher-priority path requires the protection resources that
are being utilized by a lower-priority path, the resources SHALL
be utilized by the higher-priority path. Traffic with the lower
priority SHALL be preempted.
<span class="grey">Weingarten, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
5. Once resources of shared segments have been successfully utilized
by a protection path, the traffic on that protection path SHALL
NOT be interrupted by any protection traffic whose priority is
equal to or lower than the protecting path currently in use.
6. During preemption, shared segment resources MAY be used by both
existing traffic (that is being preempted) and higher-priority
traffic.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Notification</span>
When a working path endpoint has a protection switch triggered, it
SHOULD attempt to switch the traffic to the protection path and
request the coordination of the shared resource utilization. If the
necessary shared resources are unavailable, the endpoints of the
requesting working path SHALL be notified of protection switchover
failure, and switchover will not be completed.
Similarly, if preemption is supported and the resources currently
utilized by a particular working path are being preempted, then the
endpoints of the affected working path whose traffic is being
preempted SHALL be notified that the resources are being preempted.
As described in [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>], the event of preemption may be detected by
Operations, Administration, and Maintenance (OAM) and reported as a
fault or a degradation of traffic delivery.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Reversion</span>
When the condition that triggered the protection switch is cleared,
it is possible to either revert to using the working path resources
or continue to utilize the protection resources. Continuing the use
of protection resources allows the operator to delay the disruption
of service caused by the switchover until periods of lighter traffic.
The switchover would need to be performed via an explicit operator
command, unless the protection resources are preempted by a higher-
priority fault. Hence, both automatic and manual revertive behaviors
MUST be supported for hard preemption in an SMP domain. Normally,
the network should revert to use of the working path resources in
order to clear the protection resources for protection of other path
triggers. However, the protocol MUST support non-revertive
configurations.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Protection Switching Time</span>
Protection switching time refers to the transfer time (Tt) defined in
[<a href="#ref-G.808.1" title=""Generic Protection Switching - Linear trail and subnetwork protection"">G.808.1</a>] and recovery switching time defined in [<a href="./rfc4427" title=""Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4427</a>], and is
defined as the interval after a switching trigger is identified until
the traffic begins to be transmitted on the protection path. This
<span class="grey">Weingarten, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
time does not include the time needed to initiate the protection
switching process after a failure occurred, and the time needed to
complete preemption of existing traffic on the shared segments as
described in <a href="#section-4.2">Section 4.2</a>. The time needed to initiate the protection
switching process, which is known as detection time or correlation
time in [<a href="./rfc4427" title=""Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4427</a>], is related to the OAM or management process, but
the time needed to complete preemption is related to the actions
within an SMP domain. Support for a protection switching time of
50 ms is dependent upon the initial switchover to the protection
path, but the preemption time SHOULD also be taken into account to
minimize total service interruption time.
When triggered, protection switching action SHOULD be initiated
immediately to minimize service interruption time.
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Timers</span>
In order to prevent multiple switching actions for a single switching
trigger, when there are multiple layers of networks, SMP SHOULD be
controlled by a hold-off timer that would allow lower-layer
mechanisms to complete their switching actions before invoking SMP
protection actions as described in [<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>].
In order to prevent an unstable recovering working path from invoking
intermittent switching operations, SMP SHOULD employ a
Wait-To-Restore timer during any reversion switching, as described in
[<a href="./rfc6372" title=""MPLS Transport Profile (MPLS-TP) Survivability Framework"">RFC6372</a>].
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>. Communication Channel and Fate-Sharing</span>
SMP SHOULD provide a communication channel, along the protection
path, between the endpoints of the protection path, to support fast
protection switching.
SMP in hard-preemption mode SHOULD include support for communicating
information to coordinate the use of the shared protection resources
among multiple working paths. The message encoding and communication
channel between the nodes of the shared protection resource and the
endpoints of the protection path are out of the scope of this
document.
Bidirectional protection switching SHOULD be supported in SMP.
<span class="grey">Weingarten, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Manageability Considerations</span>
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.
This document does not introduce any new manageability requirements
beyond those covered in those documents.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</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>].
The security considerations for the generic associated control
channel are described in [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>].
Security considerations for any proposed solution should consider
exhaustion of resources related to preemption, especially by a
malicious actor as a threat vector against which the resources should
be protected. Protections should also be considered to prevent a
malicious actor from attempting to create an alternate path on which
to force traffic from a sensor/device, thereby enabling pervasive
monitoring [<a href="./rfc7258" title=""Pervasive Monitoring Is an Attack"">RFC7258</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</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 href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3945">RFC3945</a>] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", <a href="./rfc3945">RFC 3945</a>, October 2004,
<<a href="http://www.rfc-editor.org/info/rfc3945">http://www.rfc-editor.org/info/rfc3945</a>>.
[<a id="ref-RFC4426">RFC4426</a>] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", <a href="./rfc4426">RFC 4426</a>, March 2006,
<<a href="http://www.rfc-editor.org/info/rfc4426">http://www.rfc-editor.org/info/rfc4426</a>>.
[<a id="ref-RFC4427">RFC4427</a>] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", <a href="./rfc4427">RFC 4427</a>,
March 2006, <<a href="http://www.rfc-editor.org/info/rfc4427">http://www.rfc-editor.org/info/rfc4427</a>>.
[<a id="ref-RFC4428">RFC4428</a>] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis of
Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and
Restoration)", <a href="./rfc4428">RFC 4428</a>, March 2006,
<<a href="http://www.rfc-editor.org/info/rfc4428">http://www.rfc-editor.org/info/rfc4428</a>>.
<span class="grey">Weingarten, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
[<a id="ref-RFC5586">RFC5586</a>] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", <a href="./rfc5586">RFC 5586</a>, June 2009,
<<a href="http://www.rfc-editor.org/info/rfc5586">http://www.rfc-editor.org/info/rfc5586</a>>.
[<a id="ref-RFC5654">RFC5654</a>] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", <a href="./rfc5654">RFC 5654</a>, September 2009,
<<a href="http://www.rfc-editor.org/info/rfc5654">http://www.rfc-editor.org/info/rfc5654</a>>.
[<a id="ref-RFC5921">RFC5921</a>] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", <a href="./rfc5921">RFC 5921</a>, July 2010,
<<a href="http://www.rfc-editor.org/info/rfc5921">http://www.rfc-editor.org/info/rfc5921</a>>.
[<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 href="http://www.rfc-editor.org/info/rfc5951">http://www.rfc-editor.org/info/rfc5951</a>>.
[<a id="ref-RFC6372">RFC6372</a>] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", <a href="./rfc6372">RFC 6372</a>,
September 2011, <<a href="http://www.rfc-editor.org/info/rfc6372">http://www.rfc-editor.org/info/rfc6372</a>>.
[<a id="ref-RFC6378">RFC6378</a>] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile
(MPLS-TP) Linear Protection", <a href="./rfc6378">RFC 6378</a>, October 2011,
<<a href="http://www.rfc-editor.org/info/rfc6378">http://www.rfc-editor.org/info/rfc6378</a>>.
[<a id="ref-RFC7258">RFC7258</a>] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", <a href="https://www.rfc-editor.org/bcp/bcp188">BCP 188</a>, <a href="./rfc7258">RFC 7258</a>, May 2014,
<<a href="http://www.rfc-editor.org/info/rfc7258">http://www.rfc-editor.org/info/rfc7258</a>>.
[<a id="ref-RFC7271">RFC7271</a>] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", <a href="./rfc7271">RFC 7271</a>, June 2014,
<<a href="http://www.rfc-editor.org/info/rfc7271">http://www.rfc-editor.org/info/rfc7271</a>>.
[<a id="ref-G.7710">G.7710</a>] International Telecommunication Union, "Common equipment
management function requirements", ITU-T Recommendation
G.7710/Y.1701, February 2012.
[<a id="ref-G.808.1">G.808.1</a>] International Telecommunication Union, "Generic Protection
Switching - Linear trail and subnetwork protection", ITU-T
Recommendation G.808.1, May 2014.
<span class="grey">Weingarten, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
Acknowledgements
This document is the outcome of discussions on Shared Mesh Protection
for MPLS-TP. The authors would like to thank all contributors to
these discussions, and especially Eric Osborne for facilitating them.
We would also like to thank Matt Hartley for working on the English
review and Lou Berger for his valuable comments and suggestions on
this document.
Contributors
David Allan
Ericsson
EMail: david.i.allan@ericsson.com
Daniel King
Old Dog Consulting
EMail: daniel@olddog.co.uk
Taesik Cheung
ETRI
EMail: cts@etri.re.kr
<span class="grey">Weingarten, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7412">RFC 7412</a> MPLS SMP Requirements December 2014</span>
Authors' Addresses
Yaacov Weingarten
34 Hagefen St.
Karnei Shomron, 4485500
Israel
EMail: wyaacov@gmail.com
Sam Aldrin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
United States
EMail: aldrin.ietf@gmail.com
Ping Pan
Infinera
EMail: ppan@infinera.com
Jeong-dong Ryoo
ETRI
218 Gajeongno
Yuseong, Daejeon 305-700
South Korea
EMail: ryoo@etri.re.kr
Greg Mirsky
Ericsson
EMail: gregory.mirsky@ericsson.com
Weingarten, et al. Informational [Page 16]
</pre>
|
