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. Jiang, Ed.
Request for Comments: 8024 Y. Luo
Category: Standards Track Huawei
ISSN: 2070-1721 E. Mallette, Ed.
Charter Communications
Y. Shen
Juniper Networks
W. Cheng
China Mobile
November 2016
<span class="h1">Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS</span>
Abstract
Multiprotocol Label Switching (MPLS) is being extended to the edge of
operator networks including the network access nodes. Separately,
network access nodes such as Passive Optical Network (PON) Optical
Line Terminations (OLTs) have evolved to support first-mile access
protection, where one or more physical OLTs provide first-mile
diversity to the customer edge. Multihoming support is needed on the
MPLS-enabled PON OLT to provide resiliency for provided services.
This document describes the Multi-Chassis PON (MC-PON) protection
architecture in MPLS and also specifies the Inter-Chassis
Communication Protocol (ICCP) extension to support it.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</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/rfc8024">http://www.rfc-editor.org/info/rfc8024</a>.
<span class="grey">Jiang, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
Copyright Notice
Copyright (c) 2016 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>. Conventions Used in This Document . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-1.2">1.2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2">2</a>. ICCP Protocol Extensions . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.1">2.1</a>. Multi-Chassis PON Application TLVs . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.1.1">2.1.1</a>. PON Connect TLV . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.1.2">2.1.2</a>. PON Disconnect TLV . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.1.3">2.1.3</a>. PON Configuration TLV . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-2.1.4">2.1.4</a>. PON State TLV . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3">3</a>. Considerations on PON ONU Database Synchronization . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Multi-Chassis PON Application Procedures . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.1">4.1</a>. Protection Procedure upon PON Link Failures . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Protection Procedure upon PW Failures . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.3">4.3</a>. Protection Procedure upon the Working OLT Failure . . . . <a href="#page-12">12</a>
<a href="#section-4.4">4.4</a>. Protection Procedure for a Dual-Homing PE . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</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">Jiang, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Multiprotocol Label Switching (MPLS) is being extended to the edge of
operator networks, as is described in the multi-segment pseudowires
(PWs) with Passive Optical Network (PON) access use case [<a href="./rfc6456" title=""Multi-Segment Pseudowires in Passive Optical Networks"">RFC6456</a>].
Combining MPLS with Optical Line Termination (OLT) access further
facilitates a low-cost, multi-service convergence.
Tens of millions of Fiber-to-the-x (FTTx) (x = H for home, P for
premises, C for curb) lines have been deployed over the years, with
many of those lines being some PON variant. PON provides operators a
cost-effective solution for delivering high bandwidth (1 Gbps or even
10 Gbps) to a dozen or more subscribers simultaneously.
In the past, access technologies such as PON and Digital Subscriber
Line (DSL) are usually used for subscribers, and no redundancy is
provided in their deployment.
But, with the rapid growth of mobile data traffic, more and more Long
Term Evolution (LTE) small cells and Wi-Fi hotspots are deployed.
PON is considered a viable low-cost backhaul solution for these
mobile services. Besides its high bandwidth and scalability, PON
further provides frequency and time-synchronization features, e.g.,
SyncE [<a href="#ref-G.8261" title=""Timing and synchronization aspects in packet networks"">G.8261</a>] and IEEE 1588v2 [<a href="#ref-IEEE-1588">IEEE-1588</a>] functionality, which can
fulfill synchronization needs of mobile backhaul services.
The Broadband Forum specifies reference architecture for mobile
backhaul networks using MPLS transport in [<a href="#ref-TR-221" title=""Technical Specifications for MPLS in Mobile Backhaul Networks"">TR-221</a>] where PON can be
the access technology.
Unlike typical residential service where a single or handful of end-
users hang off a single PON OLT port in a physical optical
distribution network, a PON port that supports a dozen LTE small
cells or Wi-Fi hotspots could be providing service to hundreds of
simultaneous subscribers. Small-cell backhaul often demands the
economics of a PON first mile and yet expects first-mile protection
commonly available in a point-to-point access portfolio.
Some optical layer protection mechanisms, such as Trunk and Tree
protection, are specified in [<a href="#ref-IEEE-1904.1">IEEE-1904.1</a>] to avoid a single point of
failure in the access. They are called Type B and Type C protection,
respectively, in [<a href="#ref-G.983.1" title=""Broadband optical access systems based on Passive Optical Networks (PON)"">G.983.1</a>].
Trunk protection architecture is an economical PON resiliency
mechanism, where the working OLT and the working link between the
working splitter port and the working OLT (i.e., the working trunk
<span class="grey">Jiang, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
fiber) is protected by a redundant protection OLT and a redundant
trunk fiber between the protection splitter port and the protection
OLT; however, it only protects a portion of the optical path from OLT
to Optical Network Units (ONUs). This is different from the more
complex and costly Tree protection architecture where there is a
working optical distribution network path from the working OLT and a
complete protected optical distribution network path from the
protection OLT to the ONUs. Figure 1 depicts a typical scenario of
Trunk protection.
| |
|<--Optical Distribution Network->|
| |
| branch trunk +-----+
+-----+ fibers fibers | |
Base ------| | | | . OLT |
Stations ------| ONU |\ | | ,'`| A |
------| | \ V V -` +-----+
+-----+ \ .'
. \ +----------+ ,-`
+-----+ . \| -` Working
Base ------| | . | Optical |
Stations ------| ONU |---------| Splitter |
------| | . /| -, Protection
+-----+ . / +----------+ `'.,
/ `-, +-----+
+-----+ / `'.,| |
Base ------| |/ | OLT |
Stations ------| ONU | | B |
------| | +-----+
+-----+
Figure 1: Trunk Protection Architecture in PON
Besides small-cell backhaul, this protection architecture can also be
applicable to other services, for example, DSL and Multiple System
Operator (MSO) services. In that case, an ONU in Figure 1 can play
the similar role as a Digital Subscriber Line Access Multiplexer
(DSLAM) or a Data Over Cable Service Interface Specification (DOCSIS)
Remote Physical Layer (PHY) device [<a href="#ref-remote-phy">remote-phy</a>], and it may further
be attached with dozens of Customer Premises devices.
In some deployments, it is also possible that only some ONUs need to
be protected.
The PON architecture as depicted in Figure 1 can provide redundancy
in its physical topology; however, all traffic, including link
Operation Administration and Maintenance (OAM), is blocked on the
<span class="grey">Jiang, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
protection link, which frustrates end-to-end protection mechanisms
such as those specified in ITU-T G.8031 [<a href="#ref-G.8031" title=""Ethernet Linear Protection Switching"">G.8031</a>]. Therefore, some
standard signaling mechanisms are needed between OLTs to exchange
information, for example, PON link status, registered ONU
information, and network status, so that protection and restoration
can be done rapidly and reliably, especially when the OLTs also
support MPLS.
ICCP [<a href="./rfc7275" title=""Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy"">RFC7275</a>] provides a framework for inter-chassis synchronization
of state and configuration data between a set of two or more Provider
Edges (PEs). Currently, ICCP only defines application-specific
messages for Pseudowire Redundancy (PW-RED) and Multi-Chassis LACP
(mLACP), but it can be easily extended to support PON as an
Attachment Circuit (AC) redundancy.
This document proposes the extension of ICCP to support multi-
chassis PON protection in MPLS.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</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>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
DSL: Digital Subscriber Line
FTTx: Fiber-to-the-x (FTTx) (x = H for home, P for premises, C for
curb)
ICCP: Inter-Chassis Communication Protocol
OLT: Optical Line Termination
ONU: Optical Network Unit
MPLS: Multiprotocol Label Switching
PON: Passive Optical Network
RG: Redundancy Group
<span class="grey">Jiang, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. ICCP Protocol Extensions</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Multi-Chassis PON Application TLVs</span>
A set of MC-PON application Type-Length-Values (TLVs) are defined in
the following subsections.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. PON Connect TLV</span>
This TLV is included in the RG Connect message to signal the
establishment of PON application connection.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o U and F bits: both are set to 0.
o Type: set to 0x200D for "PON Connect TLV".
o Length: length of the TLV in octets excluding the U-bit, F-bit,
Type, and Length fields.
o Protocol Version: the version of this PON-specific protocol for
the purposes of inter-chassis communication. This is set to
0x0001.
o A bit: Acknowledgement bit. It MUST be set to 1 if the sender has
received a PON Connect TLV from the recipient. Otherwise, set to
0.
o Reserved: reserved for future use and MUST be set to zero.
<span class="grey">Jiang, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
o Optional Sub-TLVs: there are no optional Sub-TLVs defined for this
version of the protocol. The structure of optional Sub-TLVs is
defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o U bit: set to 1. The unknown Sub-TLV is silently ignored.
o F bit: set to 0.
o The optional Sub-TLV Type values will be allocated by IANA in a
registry named "ICC RG Parameter Types" for Pseudowire Name Spaces
(PWE3).
o Length: length of the TLV in octets, excluding the U-bit, F-bit,
Type, and Length fields.
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. PON Disconnect TLV</span>
This TLV is included in the RG Disconnect message to indicate that
the connection for the PON application is to be terminated.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o U and F bits: both are set to 0.
o Type: set to 0x200E for "PON Disconnect TLV".
o Length: length of the TLV in octets excluding the U-bit, F-bit,
Type, and Length fields.
o Optional Sub-TLVs: there are no optional Sub-TLVs defined for this
version of the protocol.
<span class="grey">Jiang, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>. PON Configuration TLV</span>
The "PON Configuration TLV" is included in the "RG Application Data"
message and announces an OLT's system parameters to other members in
the same RG.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200F | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System Priority | Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o U and F bits: both are set to 0.
o Type: set to 0x200F for "PON Configuration TLV".
o Length: length of the TLV in octets excluding the U-bit, F-bit,
Type, and Length fields.
o System ID: 8 octets encoding the System ID used by the OLT, which
is the chassis Media Access Control (MAC) address. If a 6-octet
System ID is used, the least significant 2 octets of the 8-octet
field will be encoded as 0000.
o System Priority: a 2-octet value assigned by management or
administration policy; the OLT with the numerically lower value of
System Priority has the higher priority.
o Port ID: 2-octet PON Port ID.
<span class="grey">Jiang, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
<span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>. PON State TLV</span>
The "PON State TLV" is included in the "RG Application Data" message
and used by an OLT to report its PON states to other members in the
same RG.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local PON Port State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PON Port State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o U and F bits: both are set to 0.
o Type: set to 0x2010 for "PON State TLV".
o Length: length of the TLV in octets excluding the U-bit, F-bit,
Type, and Length fields.
o ROID: Redundant Object ID (ROID) as defined in <a href="./rfc7275#section-4.3">Section 4.3 of
[RFC7275]</a>.
o Local PON Port State: the status of the local PON port as
determined by the sending OLT (PE). The last bit is defined as
Fault indication of the PON Port associated with this PW (1 - in
fault; 0 - in normal).
o Remote PON Port State: the status of the remote PON port as
determined by the remote peer of the sending OLT (i.e., the
sending PE). The last bit is defined as Fault indication of the
PON Port associated with this PW (1 - in fault; 0 - in normal).
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Considerations on PON ONU Database Synchronization</span>
Without an effective mechanism to communicate the registered ONUs
between the working and protection OLT, all registered ONUs would be
de-registered and go through re-registration during a switchover,
which would significantly increase protection time. To enable faster
switchover capability, the working and protection OLTs need to know
about the protected ONUs. To enable service continuity, a mechanism
<span class="grey">Jiang, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
needs to be employed such that the operational state and significant
configuration data of both the protected ONU and the services
provisioned to it can be distributed to the working and protection
OLT.
The specific ONU's configuration and operational data can be
synchronized by some policy mechanism or provisioned in the
management plane. Alternatively, said synchronization could occur by
some other signaling options. Describing how to synchronize the
configuration objects associated with both protected ONU as well as
the services constructed to the ONU (e.g., ONU MAC address, IPv4
addresses, IPv6 addresses, VLAN identifiers, etc.) is outside of the
scope of this document.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Multi-Chassis PON Application Procedures</span>
Two typical MPLS protection network architectures for PON access are
depicted in Figures 2 and 3 (their PON access segments are the same
as in Figure 1 and thus omitted for simplification). OLTs with MPLS
functionality are connected to a single PE (Figure 2) or dual-homing
PEs (Figure 3), respectively, i.e., the working OLT to PE1 by a
working PW and the protection OLT to PE1 or PE2 by a protection PW;
thus, these devices constitute an MPLS network that provides PW
transport services between ONUs and a Customer Edge (CE), and the PWs
can provide protection for each other.
+-----+
| |
|OLT -,
| A | `.,
+-----+ ', PW1
`',
`., +-----+ +-----+
', | | | |
`. PE1 ------------ CE |
.'`| | | |
,-` +-----+ +-----+
.`
+-----+ .'` PW2
| | ,-`
|OLT -`
| B |
+-----+
Figure 2: An MPLS Network with a Single PE
<span class="grey">Jiang, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
+-----+ +-----+
| | PW1 | |
|OLT ----------------- PE1 -,
| A | | | ',
+-----+ +--/--+ ',
| `.
| `. +-----+
| `' |
| | CE |
| . |
| ,'+-----+
| ,-`
+-----+ +--\--+ ,'
| | PW2 | | .`
|OLT ----------------- PE2 -`
| B | | |
+-----+ +-----+
Figure 3: An MPLS Network with Dual-Homing PEs
Faults may be encountered in PON access links or in the MPLS network
(including the working OLT). Procedures for these cases are
described in this section (it is assumed that both OLTs and PEs are
working in the independent mode of PW redundancy [<a href="./rfc6870" title=""Pseudowire Preferential Forwarding Status Bit"">RFC6870</a>]).
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Protection Procedure upon PON Link Failures</span>
When a fault is detected on a working PON link, a working OLT
switches to the corresponding protection PON link attached with its
protection OLT, i.e., the working OLT turns off its faulty PON
interface so that the protection trunk link to its protection OLT can
be activated. Then, the working OLT MUST send an LDP fault
notification message (i.e., with the status bit "Local AC (ingress)
Receive Fault" being set) to its peer PE on the remote end of the PW.
At the same time, the working OLT MUST send an ICCP message with PON
State TLV with Local PON Port State being set to notify the
protection OLT of the PON fault.
Upon receiving a PON state TLV where Local PON Port State is set, a
protection OLT MUST activate the protection PON link in the
protection group and advertise a notification message for the
protection PW with the Preferential Forwarding status bit of active
to the remote PE.
According to [<a href="./rfc6870" title=""Pseudowire Preferential Forwarding Status Bit"">RFC6870</a>], the remote PE(s) can match the local and
remote Preferential Forwarding status and select PW2 as the new
active PW over which data traffic is sent.
<span class="grey">Jiang, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Protection Procedure upon PW Failures</span>
Usually, MPLS networks have their own protection mechanism such as
Label Switched Path (LSP) protection or Fast Reroute (FRR). But, in
a link-sparse access or aggregation network where protection for a PW
is impossible in its LSP layer, the following PW layer protection
procedures can be enabled.
When a fault is detected on its working PW (e.g., by Virtual Circuit
Connectivity Verification (VCCV) Bidirectional Forwarding Detection
(BFD)), a working OLT SHOULD turn off its associated PON interface
and then send an ICCP message with PON State TLV with Local PON Port
State being set to notify the protection OLT of the PON fault.
Upon receiving a PON state TLV where Local PON Port State is set, the
protection OLT MUST activate its PON interface to the protection
trunk fiber. At the same time, the protection OLT MUST send a
notification message for the protection PW with the Preferential
Forwarding status bit of active to the remote PE, so that traffic can
be switched to the protection PW.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Protection Procedure upon the Working OLT Failure</span>
As depicted in Figure 2, a service is provisioned with a working PW
and a protection PW, and both PWs are terminated on PE1. If PE1 lost
its connection to the working OLT, it SHOULD send an LDP notification
message on the protection PW with the Request Switchover bit set.
Upon receiving an LDP notification message from its remote PE with
the Request Switchover bit set, a protection OLT MUST activate its
optical interface to the protection trunk fiber and activate the
associated protection PW, so that traffic can be reliably switched to
the protection trunk PON link and the protection PW.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Protection Procedure for a Dual-Homing PE</span>
In the case of Figure 3, the PW-RED State TLV as described in
<a href="./rfc7275#section-7.1">Section 7.1 of [RFC7275]</a> can be used by PE1 to notify PE2 of the
faults in all the scenarios, and PE2 operates the same as described
in Sections <a href="#section-4.1">4.1</a> to <a href="#section-4.3">4.3</a> of this document.
<span class="grey">Jiang, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Similar to ICCP itself, this ICCP application SHOULD only be used in
well-managed and highly monitored service provider PON access
networks in a single administrative domain, including the
implementation of rogue ONU attachment detection and mitigation via
device authentication. Thus, many of the security considerations as
described in [<a href="./rfc7275" title=""Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy"">RFC7275</a>] apply here as well.
Again, similar to ICCP, activity on the attachment circuits may cause
security threats or be exploited to create denial-of-service attacks.
In many passive optical networks, the optical paths between OLT and
ONUs traverse publicly accessible facilities including public
attachments (e.g., telephone poles), which opens up the risk of
excessive link bouncing by optical layer impairment. While ICCP for
MC-PON interconnects in the MPLS domain and does not traverse the PON
network, risks do include introduction of a malicious ONU that could
cause, for example, excessive link bouncing. This link bouncing
could result in increased ICCP exchanges similar to the malicious CE
case described in [<a href="./rfc7275" title=""Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy"">RFC7275</a>]. Operators of such networks should take
additional care to restrict unauthorized ONUs and to limit the impact
of link bouncing at the OLT, as these could result in service
impairment.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IANA maintains a top-level registry called "Pseudowire Name Spaces
(PWE3)". It has a subregistry called "ICC RG Parameter Types". The
following values have been allocated from this subregistry:
0x200D PON Connect TLV
0x200E PON Disconnect TLV
0x200F PON Configuration TLV
0x2010 PON State TLV
<span class="grey">Jiang, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.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>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC6870">RFC6870</a>] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", <a href="./rfc6870">RFC 6870</a>,
DOI 10.17487/RFC6870, February 2013,
<<a href="http://www.rfc-editor.org/info/rfc6870">http://www.rfc-editor.org/info/rfc6870</a>>.
[<a id="ref-RFC7275">RFC7275</a>] Martini, L., Salam, S., Sajassi, A., Bocci, M.,
Matsushima, S., and T. Nadeau, "Inter-Chassis
Communication Protocol for Layer 2 Virtual Private Network
(L2VPN) Provider Edge (PE) Redundancy", <a href="./rfc7275">RFC 7275</a>,
DOI 10.17487/RFC7275, June 2014,
<<a href="http://www.rfc-editor.org/info/rfc7275">http://www.rfc-editor.org/info/rfc7275</a>>.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-G.8031">G.8031</a>] International Telecommunications Union, "Ethernet Linear
Protection Switching", ITU-T Recommendation G.8031,
January 2015.
[<a id="ref-G.8261">G.8261</a>] International Telecommunications Union, "Timing and
synchronization aspects in packet networks", ITU-T
Recommendation G.8261, August 2013.
[<a id="ref-G.983.1">G.983.1</a>] International Telecommunications Union, "Broadband optical
access systems based on Passive Optical Networks (PON)",
ITU-T Recommendation G.983.1, January 2005.
[<a id="ref-IEEE-1588">IEEE-1588</a>]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July
2008.
[<a id="ref-IEEE-1904.1">IEEE-1904.1</a>]
IEEE, "Standard for Service Interoperability in Ethernet
Passive Optical Networks (SIEPON)", IEEE Std 1904.1-2013,
DOI 10.1109/IEEESTD.2013.6605490, June 2013.
<span class="grey">Jiang, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
[<a id="ref-remote-phy">remote-phy</a>]
CableLabs, "Remote PHY Specification", DCN: CM-SP-R-PHY-
I05-160923, September 2016.
[<a id="ref-RFC6456">RFC6456</a>] Li, H., Zheng, R., and A. Farrel, "Multi-Segment
Pseudowires in Passive Optical Networks", <a href="./rfc6456">RFC 6456</a>,
DOI 10.17487/RFC6456, November 2011,
<<a href="http://www.rfc-editor.org/info/rfc6456">http://www.rfc-editor.org/info/rfc6456</a>>.
[<a id="ref-TR-221">TR-221</a>] The Broadband Forum, "Technical Specifications for MPLS in
Mobile Backhaul Networks", BBF TR-221, October 2011.
Acknowledgements
The authors would like to thank Min Ye, Hongyu Li, Wei Lin, Xifeng
Wan, Yannick Legoff, Shrinivas Joshi, Alexey Melnikov, and Stephen
Farrell for their valuable discussions and comments.
Contributors
The following people made significant contributions to this document:
Chengbin Shen
China Telecom
1835 South Pudong Road
Shanghai 200122, China
Email: shencb@sttri.com.cn
Guangtao Zhou
China Unicom
No.9 Shouti South Road
Beijing 100048, China
Email: zhouguangtao@chinaunicom.cn
<span class="grey">Jiang, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8024">RFC 8024</a> MC-PON Protection November 2016</span>
Authors' Addresses
Yuanlong Jiang (editor)
Huawei
Bantian, Longgang district
Shenzhen 518129
China
Email: jiangyuanlong@huawei.com
Yong Luo
Huawei
Bantian, Longgang district
Shenzhen 518129
China
Email: dennis.luoyong@huawei.com
Edwin Mallette (editor)
Charter Communications
4145 S. Falkenburg Road
Tampa, FL 33578
United States of America
Email: edwin.mallette@gmail.com
Yimin Shen
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: yshen@juniper.net
Weiqiang Cheng
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: chengweiqiang@chinamobile.com
Jiang, et al. Standards Track [Page 16]
</pre>
|
