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
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) P. Muley
Request for Comments: 6718 M. Aissaoui
Category: Informational M. Bocci
ISSN: 2070-1721 Alcatel-Lucent
August 2012
<span class="h1">Pseudowire Redundancy</span>
Abstract
This document describes a framework comprised of a number of
scenarios and associated requirements for pseudowire (PW) redundancy.
A set of redundant PWs is configured between provider edge (PE) nodes
in single-segment PW applications or between terminating PE (T-PE)
nodes in multi-segment PW applications. In order for the PE/T-PE
nodes to indicate the preferred PW to use for forwarding PW packets
to one another, a new PW status is required to indicate the
preferential forwarding status of active or standby for each PW in
the redundant set.
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/rfc6718">http://www.rfc-editor.org/info/rfc6718</a>.
<span class="grey">Muley, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Requirements Language ......................................<a href="#page-6">6</a>
<a href="#section-3">3</a>. Reference Models ................................................<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. PE Architecture ............................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. PW Redundancy Network Reference Scenarios ..................<a href="#page-7">7</a>
3.2.1. PW Redundancy for AC and PE Protection: One
Dual-Homed CE with Redundant SS-PWs .................<a href="#page-7">7</a>
3.2.2. PW Redundancy for AC and PE Protection: Two
Dual-Homed CEs with Redundant SS-PWs ................<a href="#page-8">8</a>
3.2.3. PW Redundancy for S-PE Protection:
Single-Homed CEs with Redundant MS-PWs .............<a href="#page-10">10</a>
3.2.4. PW Redundancy for PE-rs Protection in
H-VPLS Using SS-PWs ................................<a href="#page-11">11</a>
3.2.5. PW Redundancy for PE Protection in a VPLS
Ring Using SS-PWs ..................................<a href="#page-13">13</a>
3.2.6. PW Redundancy for VPLS n-PE Protection
Using SS-PWs .......................................<a href="#page-14">14</a>
<a href="#section-4">4</a>. Generic PW Redundancy Requirements .............................<a href="#page-15">15</a>
<a href="#section-4.1">4.1</a>. Protection Switching Requirements .........................<a href="#page-15">15</a>
<a href="#section-4.2">4.2</a>. Operational Requirements ..................................<a href="#page-15">15</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-16">16</a>
<a href="#section-6">6</a>. Contributors ...................................................<a href="#page-16">16</a>
<a href="#section-7">7</a>. Acknowledgements ...............................................<a href="#page-17">17</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-17">17</a>
<a href="#section-8.2">8.2</a>. Informative Reference .....................................<a href="#page-18">18</a>
<span class="grey">Muley, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The objective of pseudowire (PW) redundancy is to maintain
connectivity across the packet switched network (PSN) used by the
emulated service if a component in the path of the emulated service
fails or a backup component is activated. For example, PW redundancy
will enable the correct PW to be used for forwarding emulated service
packets when the connectivity of an attachment circuit (AC) changes
due to the failure of an AC or when a pseudowire (PW) or packet
switched network (PSN) tunnel fails due to the failure of a provider
edge (PE) node.
PW redundancy uses redundant ACs, PEs, and PWs to eliminate single
points of failure in the path of an emulated service. This is
achieved while ensuring that only one path between a pair of customer
edge (CE) nodes is active at any given time. Mechanisms that rely on
more than one active path between the CEs, e.g., 1+1 protection
switching, are out of the scope of this document because they may
require a permanent bridge to provide traffic replication as well as
support for a 1+1 protection switching protocol in the CEs.
Protection for a PW segment can be provided by the PSN layer. This
may be a Resource Reservation Protocol with Traffic Engineering
(RSVP-TE) label switched path (LSP) with a fast-reroute (FRR) backup
or an end-to-end backup LSP. These mechanisms can restore PSN
connectivity rapidly enough to avoid triggering protection by PW
redundancy. PSN protection mechanisms cannot protect against the
failure of a PE node or the failure of the remote AC. Typically,
this is supported by dual-homing a CE node to different PE nodes that
provide a pseudowire emulated service across the PSN. A set of PW
mechanisms that enables a primary and one or more backup PWs to
terminate on different PE nodes is therefore required. An important
requirement is that changes occurring on the dual-homed side of the
network due to the failure of an AC or PE are not propagated to the
ACs on the other side of the network. Furthermore, failures in the
PSN are not propagated to the attached CEs.
In cases where PSN protection mechanisms are not able to recover from
a PSN failure or where a failure of a switching PE (S-PE) may occur,
a set of mechanisms that supports the operation of a primary and one
or more backup PWs via a different set of S-PEs or diverse PSN
tunnels is therefore required. For multi-segment PWs (MS-PWs), the
paths of these PWs are diverse in that they are switched at different
S-PE nodes.
<span class="grey">Muley, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
In both of these cases, PW redundancy is important to maximize the
resiliency of the emulated service. It supplements PSN protection
techniques and can operate in addition to or instead of those
techniques when they are not available.
This document describes a framework for these applications and
associated operational requirements. The framework utilizes a new PW
status, called the 'Preferential Forwarding Status' of the PW. This
is separate from the operational states defined in <a href="./rfc5601">RFC 5601</a>
[<a href="./rfc5601" title=""Pseudowire (PW) Management Information Base (MIB)"">RFC5601</a>]. The mechanisms for PW redundancy are modeled on general
protection switching principles.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
o Up PW: A PW that has been configured (label mapping exchanged
between PEs) and is not in any of the PW or AC defect states
represented by the status codes specified in [<a href="./rfc4446" title=""IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"">RFC4446</a>]. Such a PW
is available for forwarding traffic.
o Down PW: A PW that either has not been fully configured or has
been configured and is in any one of the PW or AC defect states
specified in [<a href="./rfc4446" title=""IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"">RFC4446</a>]. Such a PW is not available for forwarding
traffic.
o Active PW: An up PW used for forwarding Operations,
Administration, and Maintenance (OAM) as well as user-plane and
control-plane traffic.
o Standby PW: An up PW that is not used for forwarding user traffic
but may forward OAM and specific control-plane traffic.
o PW Endpoint: A PE where a PW terminates on a point where native
service processing is performed, e.g., a single-segment PW (SS-PW)
PE, a multi-segment pseudowire (MS-PW) terminating PE (T-PE), or a
hierarchical Virtual Private LAN Service (VPLS) MTU-s or PE-rs.
o Primary PW: The PW that a PW endpoint activates (i.e., uses for
forwarding) in preference to any other PW when more than one PW
qualifies for the active state. When the primary PW comes back up
after a failure and qualifies for the active state, the PW
endpoint always reverts to it. The designation of primary is
performed by local configuration for the PW at the PE and is only
required when revertive behavior is used and is not applicable
when non-revertive protection switching is used.
<span class="grey">Muley, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
o Secondary PW: When it qualifies for the active state, a secondary
PW is only selected if no primary PW is configured or if the
configured primary PW does not qualify for active state (e.g., is
down). By default, a PW in a redundancy PW set is considered
secondary. There is no revertive mechanism among secondary PWs.
o Revertive protection switching: Traffic will be carried by the
primary PW if all of the following is true: it is up, a wait-to-
restore timer expires, and the primary PW is made the active PW.
o Non-revertive protection switching: Traffic will be carried by the
last PW selected as a result of a previous active PW entering the
operationally down state.
o Manual selection of a PW: The ability to manually select the
primary/secondary PWs.
o MTU-s: A hierarchical virtual private LAN service multi-tenant
unit switch, as defined in <a href="./rfc4762">RFC 4762</a> [<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>].
o PE-rs: A hierarchical virtual private LAN service switch, as
defined in <a href="./rfc4762">RFC 4762</a>.
o n-PE: A network-facing provider edge node, as defined in <a href="./rfc4026">RFC 4026</a>
[<a href="./rfc4026" title=""Provider Provisioned Virtual Private Network (VPN) Terminology"">RFC4026</a>].
o 1:1 protection: One specific subset of a path for an emulated
service, consisting of a standby PW and/or AC, protects another
specific subset of a path for the emulated service. User traffic
is transmitted over only one specific subset of the path at a
time.
o N:1 protection: N specific subsets of paths for an emulated
service, consisting of standby PWs and/or ACs, protect another
specific subset of the path for the emulated service. User
traffic is transmitted over only one specific subset of the path
at a time.
o 1+1 protection: One specific subset of a path for an emulated
service, consisting of a standby PW and/or AC, protects another
specific subset of a path for the emulated service. Traffic is
permanently duplicated at the ingress node on both the currently
active and standby subsets of the paths.
<span class="grey">Muley, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
This document uses the term 'PE' to be synonymous with both PEs as
per <a href="./rfc3985">RFC 3985</a> [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>] and T-PEs as per <a href="./rfc5659">RFC 5659</a> [<a href="./rfc5659" title=""An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge"">RFC5659</a>].
This document uses the term 'PW' to be synonymous with both PWs as
per <a href="./rfc3985">RFC 3985</a> and SS-PWs, MS-PWs, and PW segments as per <a href="./rfc5659">RFC 5659</a>.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">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-3" href="#section-3">3</a>. Reference Models</span>
The following sections show the reference architecture of the PE for
PW redundancy and the usage of the architecture in different
topologies and applications.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. PE Architecture</span>
Figure 1 shows the PE architecture for PW redundancy when more than
one PW in a redundant set is associated with a single AC. This is
based on the architecture in Figure 4b of <a href="./rfc3985">RFC 3985</a> [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>]. The
forwarder selects which of the redundant PWs to use based on the
criteria described in this document.
+----------------------------------------+
| PE Device |
+----------------------------------------+
Single | | Single | PW Instance
AC | + PW Instance X<===========>
| | |
| |----------------------|
<------>o | Single | PW Instance
| Forwarder + PW Instance X<===========>
| | |
| |----------------------|
| | Single | PW Instance
| + PW Instance X<===========>
| | |
+----------------------------------------+
Figure 1: PE Architecture for PW Redundancy
<span class="grey">Muley, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. PW Redundancy Network Reference Scenarios</span>
This section presents a set of reference scenarios for PW redundancy.
These reference scenarios represent example network topologies that
illustrate the use of PW redundancy. They can be combined together
to create more complex or comprehensive topologies, as required by a
particular application or deployment.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. PW Redundancy for AC and PE Protection: One Dual-Homed CE with</span>
<span class="h4"> Redundant SS-PWs</span>
Figure 2 illustrates an application of single-segment pseudowire
redundancy where one of the CEs is dual-homed. This scenario is
designed to protect the emulated service against a failure of one of
the PEs or ACs attached to the multi-homed CE. Protection against
failures of the PSN tunnels is provided using PSN mechanisms such as
MPLS fast reroute, so that these failures do not impact the PW.
CE1 is dual-homed to PE1 and PE3. A dual-homing control protocol,
the details of which are outside the scope of this document, enables
the PEs and CEs to determine which PE (PE1 or PE3) should forward
towards CE1 and therefore which AC CE1 should use to forward towards
the PSN.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnels-->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| | | +-----+
| |----------|....|...PW1.(active)...|....|----------| |
| | | |==================| | | CE2 |
| CE1 | +----+ |PE2 | | |
| | +----+ | | +-----+
| | | |==================| |
| |----------|....|...PW2.(standby)..| |
+-----+ | | PE3|==================| |
AC +----+ +----+
Figure 2: One Dual-Homed CE and Redundant SS-PWs
In this scenario, only one of the PWs should be used for forwarding
between PE1/PE3 and PE2. PW redundancy determines which PW to make
active based on the forwarding state of the ACs so that only one path
is available from CE1 to CE2. This requires an additional PW state
<span class="grey">Muley, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
that reflects this forwarding state, which is separate from the
operational status of the PW. This is the 'Preferential Forwarding
Status'.
Consider the example where the AC from CE1 to PE1 is initially active
and the AC from CE1 to PE3 is initially standby. PW1 is made active
and PW2 is made standby in order to complete the path to CE2.
On failure of the AC between CE1 and PE1, the forwarding state of the
AC on PE3 transitions to active. The preferential forwarding state
of PW2 therefore needs to become active, and PW1 standby, in order to
re-establish connectivity between CE1 and CE2. PE3 therefore uses
PW2 to forward towards CE2, and PE2 uses PW2 instead of PW1 to
forward towards CE1. PW redundancy in this scenario requires that
the forwarding status of the ACs at PE1 and PE3 be signaled to PE2 so
that PE2 can choose which PW to make active.
Changes occurring on the dual-homed side of the network due to a
failure of the AC or PE are not propagated to the ACs on the other
side of the network. Furthermore, failures in the PSN are not
propagated to the attached CEs.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. PW Redundancy for AC and PE Protection: Two Dual-Homed CEs with</span>
<span class="h4"> Redundant SS-PWs</span>
Figure 3 illustrates an application of single-segment pseudowire
redundancy where both of the CEs are dual-homed. This scenario is
also designed to protect the emulated service against failures of the
ACs and failures of the PEs. Both CE1 and CE2 are dual-homed to
their respective PEs, CE1 to PE1 and PE2, and CE2 to PE3 and PE4. A
dual-homing control protocol, the details of which are outside the
scope of this document, enables the PEs and CEs to determine which
PEs should forward towards the CEs and therefore which ACs the CEs
should use to forward towards the PSN.
Note that the PSN tunnels are not shown in this figure for clarity.
However, it can be assumed that each of the PWs shown is encapsulated
in a separate PSN tunnel. Protection against failures of the PSN
tunnels is provided using PSN mechanisms such as MPLS fast reroute,
so that these failures do not impact the PW.
<span class="grey">Muley, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnels-->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | |....|.......PW1........|....| | +-----+
| |----------| PE1|...... .........| PE3|----------| |
| CE1 | +----+ \ / PW3 +----+ | CE2 |
| | +----+ X +----+ | |
| | | |....../ \..PW4....| | | |
| |----------| PE2| | PE4|--------- | |
+-----+ | |....|.....PW2..........|....| | +-----+
AC +----+ +----+ AC
Figure 3: Two Dual-Homed CEs and Redundant SS-PWs
PW1 and PW4 connect PE1 to PE3 and PE4, respectively. Similarly, PW2
and PW3 connect PE2 to PE4 and PE3. PW1, PW2, PW3, and PW4 are all
up. In order to support protection for the emulated service, only
one PW MUST be selected to forward traffic.
If a PW has a preferential forwarding status of 'active', it can be
used for forwarding traffic. The actual up PW chosen by the combined
set of PEs connected to the CEs is determined by considering the
preferential forwarding status of each PW at each PE. The mechanisms
for communicating the preferential forwarding status are outside the
scope of this document. Only one PW is used for forwarding.
The following failure scenario illustrates the operation of PW
redundancy in Figure 3. In the initial steady state, when there are
no failures of the ACs, one of the PWs is chosen as the active PW,
and all others are chosen as standby. The dual-homing protocol
between CE1 and PE1/PE2 chooses to use the AC to PE2, while the
protocol between CE2 and PE3/PE4 chooses to use the AC to PE4.
Therefore, the PW between PE2 and PE4 is chosen as the active PW to
complete the path between CE1 and CE2.
On failure of the AC between the dual-homed CE1 and PE2, the
preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4
needs to change so as to re-establish a path from CE1 to CE2.
Different mechanisms can be used to achieve this and these are beyond
the scope of this document. After the change in status, the
algorithm needs to evaluate and select which PW to forward traffic
on. In this application, each dual-homing algorithm, i.e., {CE1,
PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently.
<span class="grey">Muley, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
There is therefore a need to signal the active status of each AC such
that the PEs can select a common active PW for forwarding between CE1
and CE2.
Changes occurring on one side of network due to a failure of the AC
or PE are not propagated to the ACs on the other side of the network.
Furthermore, failures in the PSN are not propagated to the attached
CEs. Note that end-to-end native service protection switching can
also be used to protect the emulated service in this scenario. In
this case, PW3 and PW4 are not necessary.
If the CEs do not perform native service protection switching, they
may instead use load balancing across the paths between the CEs.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. PW Redundancy for S-PE Protection: Single-Homed CEs with</span>
<span class="h4"> Redundant MS-PWs</span>
Figure 4 shows a scenario where both CEs are single-homed, and MS-PW
redundancy is used. The main objective is to protect the emulated
service against failures of the S-PEs.
Native |<----------- Pseudowires ----------->| Native
Service | | Service
(AC) | |<-PSN1-->| |<-PSN2-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+ |
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| |
| CE1| | |=========| |=========| | | CE2|
| | +-----+ +-----+ +-----+ | |
+----+ |.||.| |.||.| +----+
|.||.| +-----+ |.||.|
|.||.|=========| |========== .||.|
|.||...PW2-Seg1......|.PW2-Seg2...||.|
|.| ===========|S-PE2|============ |.|
|.| +-----+ |.|
|.|============+-----+============= .|
|.....PW3-Seg1.| | PW3-Seg2......|
==============|S-PE3|===============
| |
+-----+
Figure 4: Single-Homed CE with Redundant MS-PWs
<span class="grey">Muley, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
CE1 is connected to T-PE1, and CE2 is connected to T-PE2. There are
three multi-segment PWs. PW1 is switched at S-PE1, PW2 is switched
at S-PE2, and PW3 is switched at S-PE3. This scenario provides N:1
protection for the subset of the path of the emulated service from
T-PE1 to T-PE2.
Since there is no multi-homing running on the ACs, the T-PE nodes
advertise 'active' for the preferential forwarding status based on a
priority for the PW. The priority associates a meaning of 'primary
PW' and 'secondary PW' to a PW. These priorities MUST be used if
revertive mode is used and the active PW to use for forwarding is
determined accordingly. The priority can be derived via
configuration or based on the value of the PW forwarding equivalence
class (FEC). For example, a lower value of PWid FEC can be taken as
a higher priority. However, this does not guarantee selection of
same PW by the T-PEs because of, for example, a mismatch in the
configuration of the PW priority at each T-PE. The intent of this
application is for T-PE1 and T-PE2 to synchronize the transmit and
receive paths of the PW over the network. In other words, both T-PE
nodes are required to transmit over the PW segment that is switched
by the same S-PE. This is desirable for ease of operation and
troubleshooting.
<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>. PW Redundancy for PE-rs Protection in H-VPLS Using SS-PWs</span>
The following figure (based on the architecture shown in Figure 3 of
[<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>]) illustrates the application of PW redundancy to
hierarchical VPLS (H-VPLS). Note that the PSN tunnels are not shown
for clarity, and only one PW of a PW group is shown. A multi-tenant
unit switch (MTU-s) is dual-homed to two PE router switches. The
example here uses SS-PWs, and the objective is to protect the
emulated service against failures of a PE-rs.
<span class="grey">Muley, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
PE1-rs
+--------+
| VSI |
Active PW | -- |
Group..........|../ \..|.
CE-1 . | \ / | .
\ . | -- | .
\ . +--------+ .
\ MTU-s . . . PE3-rs
+--------+ . . . +--------+
| VSI | . . H-VPlS .| VSI |
| -- ..|.. . Core |.. -- |
| / \ | . PWs | / \ |
| \ /..|.. . | \ / |
| -- | . . .|.. -- |
+--------+ . . . +--------+
/ . . .
/ . +--------+ .
/ . | VSI | .
CE-2 . | -- | .
..........|../ \..|.
Standby PW | \ / |
Group | -- |
+--------+
PE2-rs
Figure 5: MTU-s Dual-Homing in H-VPLS Core
In Figure 5, the MTU-s is dual-homed to PE1-rs and PE2-rs and has
spoke PWs to each of them. The MTU-s needs to choose only one of the
spoke PWs (the active PW) to forward traffic to one of the PEs and
sets the other PW to standby. The MTU-s can derive the status of the
PWs based on local policy configuration. PE1-rs and PE2-rs are
connected to the H-VPLS core on the other side of network. The MTU-s
communicates the status of its member PWs for a set of virtual
switching instances (VSIs) that share a common status of active or
standby. Here, the MTU-s controls the selection of PWs used to
forward traffic. Signaling using PW grouping with a common group-id
in the PWid FEC Element, or a Grouping TLV in Generalized PWid FEC
Element as defined in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], to PE1-rs and PE2-rs, is recommended
for improved scaling.
Whenever an MTU-s performs a switchover of the active PW group, it
needs to communicate this status change to the PE2-rs. That is, it
informs PE2-rs that the status of the standby PW group has changed to
active.
<span class="grey">Muley, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
In this scenario, PE devices are aware of switchovers at the MTU-s
and could generate Media Access Control (MAC) Address Withdraw
messages to trigger MAC flushing within the H-VPLS full mesh. By
default, MTU-s devices should still trigger MAC Address Withdraw
messages as defined in [<a href="./rfc4762" title=""Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"">RFC4762</a>] to prevent two copies of MAC Address
Withdraw messages to be sent (one by the MTU-s and another one by the
PE-rs). Mechanisms to disable the MAC withdraw trigger in certain
devices are out of the scope of this document.
<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>. PW Redundancy for PE Protection in a VPLS Ring Using SS-PWs</span>
The following figure illustrates the use of PW redundancy for dual-
homed connectivity between PEs in a VPLS ring topology. As above,
PSN tunnels are not shown, and only one PW of a PW group is shown for
clarity. The example here uses SS-PWs, and the objective is to
protect the emulated service against failures of a PE on the ring.
PE1 PE2
+--------+ +--------+
| VSI | | VSI |
| -- | | -- |
......|../ \..|.....................|../ \..|.......
| \ / | PW Group 1 | \ / |
| -- | | -- |
+--------+ +--------+
. .
. .
VPLS Domain A . . VPLS Domain B
. .
. .
. .
+--------+ +--------+
| VSI | | VSI |
| -- | | -- |
......|../ \..|.....................|../ \..|........
| \ / | PW Group 2 | \ / |
| -- | | -- |
+--------+ +--------+
PE3 PE4
Figure 6: Redundancy in a VPLS Ring Topology
In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and
PE4 in VPLS domain B via PW group 1 and PW group 2. The PEs are
connected to each other in such a way as to form a ring topology.
Such scenarios may arise in inter-domain H-VPLS deployments where the
Rapid Spanning Tree Protocol (RSTP) or other mechanisms may be used
to maintain loop-free connectivity of the PW groups.
<span class="grey">Muley, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
[<a id="ref-RFC4762">RFC4762</a>] outlines multi-domain VPLS services without specifying how
multiple redundant border PEs per domain and per VPLS instance can be
supported. In the example above, PW group 1 may be blocked at PE1 by
RSTP, and it is desirable to block the group at PE2 by exchanging the
PW preferential forwarding status of standby. The details of how PW
grouping is achieved and used is deployment specific and is outside
the scope of this document.
<span class="h4"><a class="selflink" id="section-3.2.6" href="#section-3.2.6">3.2.6</a>. PW Redundancy for VPLS n-PE Protection Using SS-PWs</span>
|<----- Provider ----->|
Core
+------+ +------+
| n-PE |::::::::::::::::::::::| n-PE |
Provider | (P) |.......... .........| (P) | Provider
Access +------+ . . +------+ Access
Network X Network
(1) +------+ . . +------+ (2)
| n-PE |.......... .........| n-PE |
| (B) |......................| (B) |
+------+ +------+
Figure 7: Bridge Module Model
Figure 7 shows a scenario with two provider access networks. The
example here uses SS-PWs, and the objective is to protect the
emulated service against failures of a network-facing PE (n-PE).
Each network has two n-Pes. These n-PEs are connected via a full
mesh of PWs for a given VPLS instance. As shown in the figure, only
one n-PE in each access network serves as the primary PE (P) for that
VPLS instance, and the other n-PE serves as the backup PE (B). In
this figure, each primary PE has two active PWs originating from it.
Therefore, when a multicast, broadcast, or unknown unicast frame
arrives at the primary n-PE from the access network side, the n-PE
replicates the frame over both PWs in the core even though it only
needs to send the frames over a single PW (shown with :::: in the
figure) to the primary n-PE on the other side. This is an
unnecessary replication of the customer frames that consumes core-
network bandwidth (half of the frames get discarded at the receiving
n-PE). This issue gets aggravated when there are three or more n-PEs
per provider access network. For example, if there are three n-PEs
or four n-PEs per access network, then 67% or 75% of core bandwidth
for multicast, broadcast, and unknown unicast are wasted,
respectively.
<span class="grey">Muley, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
In this scenario, the n-PEs can communicate the active or standby
status of the PWs among them. This status can be derived from the
active or backup state of an n-PE for a given VPLS.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Generic PW Redundancy Requirements</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Protection Switching Requirements</span>
o Protection architectures such as N:1,1:1 or 1+1 are possible. 1:1
protection MUST be supported. The N:1 protection case is less
efficient in terms of the resources that must be allocated; hence,
this SHOULD be supported. 1+1 protection MAY be used in the
scenarios described in the document. However, the details of its
usage are outside the scope of this document, as it MAY require a
1+1 protection switching protocol between the CEs.
o Non-revertive behavior MUST be supported, while revertive behavior
is OPTIONAL. This avoids the need to designate one PW as primary
unless revertive behavior is explicitly required.
o Protection switchover can be initiated from a PE, e.g., using a
manual switchover or a forced switchover, or it may be triggered
by a signal failure, i.e., a defect in the PW or PSN. Manual
switchover may be necessary if it is required to disable one PW in
a redundant set. Both methods MUST be supported, and signal
failure triggers MUST be treated with a lower priority than any
local or far-end forced switch or manual trigger.
o A PE MAY be able to forward packets received from a PW with a
standby status in order to avoid black holing of in-flight packets
during switchover. However, in cases where VPLS is used, all VPLS
application packets received from standby PWs MUST be dropped,
except for OAM and control-plane packets.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Operational Requirements</span>
o (T-)PEs involved in protecting a PW SHOULD automatically discover
and attempt to resolve inconsistencies in the configuration of
primary/secondary PWs.
o (T-)PEs involved in protecting a PW SHOULD automatically discover
and attempt to resolve inconsistencies in the configuration of
revertive/non-revertive protection switching mode.
o (T-)PEs that do not automatically discover or resolve
inconsistencies in the configuration of primary/secondary,
revertive/non-revertive, or other parameters MUST generate an
alarm upon detection of an inconsistent configuration.
<span class="grey">Muley, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
o (T-)PEs participating in PW redundancy MUST support the
configuration of revertive or non-revertive protection switching
modes if both modes are supported.
o The MIB(s) MUST support inter-PSN monitoring of the PW redundancy
configuration, including the protection switching mode.
o (T-)PEs participating in PW redundancy SHOULD support the local
invocation of protection switching.
o (T-)PEs participating in PW redundancy SHOULD support the local
invocation of a lockout of protection switching.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The PW redundancy method described in this RFC will require an
extension to the PW setup and maintenance protocol [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], which
in turn is carried over the Label Distribution Protocol (LDP)
[<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>]. This PW redundancy method will therefore inherit the
security mechanisms of the version of LDP implemented in the PEs.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Contributors</span>
The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre,
Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles
Heron, and Thomas Nadeau, all of whom made a major contribution to
the development of this document.
Pranjal Dutta
Alcatel-Lucent
EMail: pranjal.dutta@alcatel-lucent.com
Marc Lasserre
Alcatel-Lucent
EMail: marc.lasserre@alcatel-lucent.com
Jonathan Newton
Cable & Wireless
EMail: Jonathan.Newton@cw.com
Hamid Ould-Brahim
EMail: ouldh@yahoo.com
Olen Stokes
Extreme Networks
EMail: ostokes@extremenetworks.com
<span class="grey">Muley, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
Dave McDysan
Verizon
EMail: dave.mcdysan@verizon.com
Giles Heron
Cisco Systems
EMail: giles.heron@gmail.com
Thomas Nadeau
Juniper Networks
EMail: tnadeau@lucidvision.com
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The authors would like to thank Vach Kompella, Kendall Harvey,
Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus, and Philippe
Niger for their valuable comments and suggestions.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3985">RFC3985</a>] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", <a href="./rfc3985">RFC 3985</a>, March 2005.
[<a id="ref-RFC4026">RFC4026</a>] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", <a href="./rfc4026">RFC 4026</a>, March 2005.
[<a id="ref-RFC4446">RFC4446</a>] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", <a href="https://www.rfc-editor.org/bcp/bcp116">BCP 116</a>, <a href="./rfc4446">RFC 4446</a>, April 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-RFC4762">RFC4762</a>] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
<a href="./rfc4762">RFC 4762</a>, January 2007.
[<a id="ref-RFC5036">RFC5036</a>] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", <a href="./rfc5036">RFC 5036</a>, October 2007.
[<a id="ref-RFC5659">RFC5659</a>] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", <a href="./rfc5659">RFC 5659</a>,
October 2009.
<span class="grey">Muley, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6718">RFC 6718</a> PW Redundancy August 2012</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative Reference</span>
[<a id="ref-RFC5601">RFC5601</a>] Nadeau, T. and D. Zelig, "Pseudowire (PW) Management
Information Base (MIB)", <a href="./rfc5601">RFC 5601</a>, July 2009.
Authors' Addresses
Praveen Muley
Alcatel-Lucent
EMail: praveen.muley@alcatel-lucent.com
Mustapha Aissaoui
Alcatel-Lucent
EMail: mustapha.aissaoui@alcatel-lucent.com
Matthew Bocci
Alcatel-Lucent
EMail: matthew.bocci@alcatel-lucent.com
Muley, et al. Informational [Page 18]
</pre>
|
