idnits 2.17.1 draft-jiang-pwe3-mc-pon-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-802.3' is mentioned on line 393, but not defined == Unused Reference: 'IEEE-802' is defined on line 592, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group Y. Jiang 2 Internet Draft Y. Luo 3 Intended status: Standards Track Huawei 4 E. Mallette 5 Bright House Networks 6 C. Shen Y. Shen 7 China Telecom Juniper Networks 8 W. Cheng G. Zhou 9 China Mobile China Unicom 11 Expires: April 2015 October 25, 2014 13 Multi-chassis PON Protection in MPLS 14 draft-jiang-pwe3-mc-pon-03.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on April 25, 2013. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 MPLS is being deployed deeper into operator networks, often to or 56 past the access network node. Separately network access nodes such as 57 PON OLTs have evolved to support first-mile access protection, where 58 one or more physical OLTs provide first-mile diversity to the 59 customer edge. Multi-homing support is needed on the MPLS-enabled PON 60 OLT to provide resiliency for provided services. This document 61 describes the multi-chassis PON protection architecture in MPLS and 62 also proposes the ICCP extension to support it. 64 Table of Contents 66 1. Conventions used in this document ......................... 3 67 2. Terminology ............................................... 3 68 3. Introduction .............................................. 3 69 4. ICCP Protocol Extensions .................................. 6 70 4.1. Multi-chassis PON Application TLVs ..................... 6 71 4.1.1. PON Connect TLV ..................................... 6 72 4.1.2. PON Disconnect TLV .................................. 7 73 4.1.3. PON Configuration TLV ............................... 7 74 4.1.4. PON State TLV ....................................... 8 75 4.1.5. PON ONU Database Sync TLV ........................... 9 76 5. PON ONU Database Synchronization ......................... 11 77 6. Multi-chassis PON application procedures ................. 11 78 6.1. Protection procedure upon PON link failures ........... 13 79 6.2. Protection procedure upon PW failures ................. 13 80 6.3. Protection procedure upon the working OLT failure ..... 13 81 7. Security Considerations .................................. 14 82 8. IANA Considerations ...................................... 14 83 9. References ............................................... 14 84 9.1. Normative References .................................. 14 85 9.2. Informative References ................................ 15 86 10. Acknowledgments .......................................... 15 87 Authors' Addresses ............................................ 16 89 1. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Terminology 97 DSL Digital Subscriber Line 99 FTTx Fiber-to-the-x (FTTx, x = H for home, P for premises, C for curb) 101 ICCP Inter-Chassis Communication Protocol 103 OLT Optical Line Termination 105 ONU Optical Network Unit 107 MPLS Multi-Protocol Label Switching 109 PON Passive Optical Network 111 RG Redundancy Group 113 3. Introduction 115 MPLS is being extended to the edge of operator networks, as is 116 described in the seamless MPLS use cases [SEAMLESS], and the MS-PW 117 with PON access use case [RFC6456]. Combining MPLS with OLT access 118 further facilitates a low cost multi-service convergence. 120 Tens of millions of FTTx lines have been deployed over the years, 121 with many of those lines being some PON variant. PON provides 122 operators a cost-effective solution for delivering high bandwidth 123 (1Gbps or even 10Gbps) to a dozen or more subscribers simultaneously. 125 In the past, access technologies such as Passive Optical Network (PON) 126 and Digital Subscriber Line (DSL) are usually used for subscribers, 127 and no redundancy is provided in their deployment. 129 But with the rapid growth of mobile data traffic, more and more LTE 130 small cells and Wi-Fi hotspots are deployed. PON is considered as a 131 viable low cost backhaul solution for these mobile services. Besides 132 its high bandwidth and scalability, PON further provides 133 synchronization features, e.g., SyncE and IEEE1588 functionality, 134 which can fulfill synchronization needs of mobile backhaul services. 136 The Broadband Forum specifies reference architecture for mobile 137 backhaul network using MPLS transport in [TR-221] where PON can be 138 the access technology, and is further working on PON-based mobile 139 backhaul network architecture in [SD-331]. 141 Unlike typical residential service where a single or handful of end- 142 users hangs off of a single PON OLT port in a physical optical 143 distribution network, a PON port that supports a dozen LTE small 144 cells or Wi-Fi hotspots could be providing service to hundreds of 145 simultaneous subscribers. Small cell backhaul often demands the 146 economics of a PON first-mile and yet expects first-mile protection 147 commonly available in point-to-point access portfolio. 149 Some optical layer of protection mechanisms, such as Trunk and Tree 150 protection, are specified in [IEEE-1904.1] to avoid single point of 151 failure in the access. They are called Type B and Type C protection 152 respectively in [G983.1]. 154 Trunk protection architecture is an economical PON resiliency 155 mechanism, where the working OLT and the working link between the 156 working splitter port and the working OLT (i.e., the working trunk 157 fiber) is protected by a redundant protection OLT and a redundant 158 trunk fiber between the protection splitter port and the protection 159 OLT, however it only protects a portion of the optical path from OLT 160 to ONUs. This is different from the more complex and costly Type C 161 protection architecture where there is a working optical distribution 162 network path from the working OLT and a complete protected optical 163 distribution network path from the protection OLT to the ONUs. Figure 164 1 demonstrates a typical scenario of Trunk protection. 166 | | 167 |<--Optical Distribution Network->| 168 | | 169 | branch trunk +-----+ 170 +-----+ fibers fibers | | 171 Base ------| | | . OLT | 172 Stations ------| ONU |\ | ,'`| A | 173 ------| | \ V _-` +-----+ 174 +-----+ \ .' 175 . \ +----------+ ,-` 176 +-----+ . \| -` Working 177 Base ------| | . | Optical | 178 Stations ------| ONU |---------| Splitter | 179 ------| | . /| -, Protection 180 +-----+ . / +----------+ `'., 181 / `-, +-----+ 182 +-----+ / `'.,| | 183 Base ------| |/ | OLT | 184 Stations ------| ONU | | B | 185 ------| | +-----+ 186 +-----+ 187 Figure 1 Trunk Protection Architecture in PON 189 Besides small cell backhaul, this protection architecture can also be 190 applicable to other services, for example, DSL and Multi-System 191 Operator (MSO) services. In that case, an ONU in Figure 1 can play 192 the similar role as a Digital Subscriber Line Access Multiplexer 193 (DSLAM) and dozens of Customer Premises Equipments (CPEs) or cable 194 modems may be attached to it. 196 In some deployments, it is also possible that only some ONUs are 197 needed to be protected. 199 The PON architecture depicted in Figure 1 can provide redundancy in 200 its physical topology, however, all traffic including link OAM are 201 blocked on the protection link which frustrates end to end protection 202 mechanisms such as ITU-T G.8031. Therefore, some standard signaling 203 mechanisms are needed between OLTs to exchange information, for 204 example, PON link status, registered ONU information, and network 205 status, so that protection and restoration can be done both rapidly 206 and reliably, especially when the OLTs also support MPLS. 208 ICCP [ICCP] provides a framework for inter-chassis synchronization of 209 state and configuration data between a set of two or more PEs. 210 Currently ICCP only defines application specific messages for PW 211 redundancy and mLACP, but it can be easily extended to support PON as 212 an Attachment Circuit (AC) redundancy. 214 This document proposes the extension of ICCP to support Multi-chassis 215 PON protection in MPLS. 217 4. ICCP Protocol Extensions 219 4.1. Multi-chassis PON Application TLVs 221 A set of multi-chassis PON application TLVs are defined in the 222 following sub-sections. 224 4.1.1. PON Connect TLV 226 This TLV is included in the RG Connect message to signal the 227 establishment of PON application connection. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |U|F| Type=0x00XX | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Protocol Version |A| Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Optional Sub-TLVs | 237 ~ ~ 238 | | 239 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | ... | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 - U and F Bits, both are set to 0. 244 - Type, set to 0x00XX for "PON Connect TLV". 246 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 247 Type, and Length fields. 249 - Protocol Version, the version of this PON specific protocol for the 250 purposes of inter-chassis communication. This is set to 0x0001. 252 - A Bit, Acknowledgement Bit. Set to 1 if the sender has received a 253 PON Connect TLV from the recipient. Otherwise, set to 0. 255 - Reserved, Reserved for future use. 257 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 258 version of the protocol. 260 4.1.2. PON Disconnect TLV 262 This TLV is included in the RG Disconnect message to indicate that 263 the connection for the PON application is to be terminated. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |U|F| Type=0x00XX | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Optional Sub-TLVs | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 - U and F Bits, both are set to 0. 275 - Type, set to 0x00XX for "PON Disconnect TLV". 277 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 278 Type, and Length fields. 280 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 281 version of the protocol. 283 4.1.3. PON Configuration TLV 285 The "PON Configuration TLV" is included in the "RG Application Data" 286 message, and announces an OLT's system parameters to other members in 287 the same RG. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |U|F| Type=0x00XX | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | System ID | 294 | | 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | System Priority | Port ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 - U and F Bits, both are set to 0. 302 - Type, set to 0x00XX for "PON Configuration TLV". 304 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 305 Type, and Length fields. 307 - System ID, 8 octets encoding the System ID used by the OLT, which 308 is the Chassis MAC address. If a 6 octet System ID is used, the least 309 significant 2 octets of the 8 octet field will be encoded as 0000. 311 - System Priority, 2 octets encoding the System Priority. 313 - Port ID, 2 octets PON Port ID. 315 Further configuration considerations such as multicast table and ARP 316 table for static MAC addresses will be added in a next version. 318 4.1.4.PON State TLV 320 The "PON State TLV" is included in the "RG Application Data" message, 321 and used by an OLT to report its PON states to other members in the 322 same RG. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |U|F| Type=0x00XX | Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | ROID | 330 | | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Local PON Port state | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Remote PON Port state | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 - U and F Bits, both are set to 0. 340 - Type, set to 0x00XX for "PON State TLV" 342 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 343 Type, and Length fields. 345 - ROID, as defined in the ROID section of [ICCP]. 347 - Local PON Port State, the status of the local PON port as 348 determined by the sending OLT (PE). The last bit is defined as Fault 349 indication of the PON Port associated with this PW (1 - in fault). 351 - Remote PON Port State, the status of the remote PON port as 352 determined by the remote peer of the sending OLT (PE). The last bit 353 is defined as Fault indication of the PON Port associated with this 354 PW (1 - in fault). 356 4.1.5.PON ONU Database Sync TLV 358 This TLV is used to communicate the registered ONU database 359 associated with a PON port between the active and standby OLT. This 360 message is used to both transmit the PON ONU Database from working 361 OLT to protect OLT and to communicate the PON ONU database status 362 between protect OLT and working OLT. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |U|F| Type=0x00XX | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | ROID | 370 | | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |A| Reserved | OUI | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 375 | ONU Database Entry1 | 376 ~ ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 - U and F Bits, both are set to 0. 381 - Type, set to 0x00XX for "PON ONU Database Sync TLV" 383 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 384 Type, and Length fields. 386 - ROID, defined in the ROID section of [ICCP]. 388 - A bit, Acknowledgement bit. Set to 1 if the receiver has received a 389 PON ONU Database Sync. Otherwise, set to 0. 391 - Reserved, reserved for future use. 393 - OUI, the 3-byte [IEEE-802.3] organization unique identifier that 394 uniquely identifies the format for describing the registered ONU 395 database information. There are multiple PON standards and are 396 varying implementations within a given PON standard which likely have 397 different required information, format, etc., related to the ONU 398 Database Entry. 400 - ONU Database Entry, there may be one or more ONU Database Entries 401 transmitted in the PON ONU Database Sync TLV, each of which would 402 describe a registered ONU. The format of the ONU Database Entry is 403 outside the scope of this document and will be defined by the 404 relevant PON standard organization. 406 5. PON ONU Database Synchronization 408 Without an effective mechanism to communicate the registered ONUs 409 between the working and protection OLT, all registered ONUs would be 410 de-registered and go through re-registration during a switchover, 411 which would significantly increase protection time. To enable faster 412 switchover capability, the work OLT must be able to communicate the 413 registered ONUs associated with an ROID to the protection OLT. 415 The PON ONU Database Synchronization would begin once the ICCP PON 416 Application enters OPERATIONAL state. The working OLT, the one with 417 the working link member for the ROID, would begin transmitting the 418 database of actively registered ONUs to the protection OLT for the 419 same ROID. Each instance of the PON ONU Database Sync TLV describes a 420 set of ONU Database Entries. Each ONU Database Entry would describe a 421 registered ONU. 423 The transmission of PON ONU Database Descriptors for a given ROID is 424 only unidirectional - from the working OLT to the protection OLT. The 425 protection OLT would only be responsible for acknowledging the 426 received message to provide a reliable database synchronization 427 mechanism. As ONUs register and deregister from the working OLT, the 428 working OLT would transmit PON ONU Database Synchronization TLV 429 including only the updated ONU Database Entries. 431 If protected ONUs and unprotected ONUs are miscellaneously attached 432 to the same splitter, only the protected ONUs needs to be 433 synchronized. The specific ONUs which needs to be synchronized can be 434 policy driven and provisioned in the management plane, or by some 435 other signaling options. 437 6. Multi-chassis PON application procedures 439 Two typical MPLS protection network architectures for PON access are 440 depicted in Fig.2 and Fig.3 (their PON access segments are the same 441 as in Fig.1 and thus omitted for simplification). OLTs with MPLS 442 functionality are connected to a single PE (Fig.2) or dual home PEs 443 (Fig.3) respectively, i.e., the working OLT to PE1 by a working PW 444 and the protection OLT to PE1 or PE2 by a protection PW, thus these 445 devices constitute an MPLS network which provides PW transport 446 services between ONUs and a CE. 448 +-----+ 449 | | 450 |OLT -, 451 | A | `., 452 +-----+ ', PW1 453 `', 454 `., +-----+ +-----+ 455 ', | | | | 456 `. PE1 ------------ CE | 457 .'`| | | | 458 ,-` +-----+ +-----+ 459 .` 460 +-----+ .'` PW2 461 | | ,-` 462 |OLT -` 463 | B | 464 +-----+ 465 Figure 2 An MPLS Network with a Single PE 467 +-----+ +-----+ 468 | | PW1 | | 469 |OLT ----------------- PE1 -, 470 | A | | | ', 471 +-----+ +--/--+ ', 472 | `. 473 | `. +-----+ 474 | `' | 475 | | CE | 476 | . | 477 | ,'+-----+ 478 | ,-` 479 +-----+ +--\--+ ,' 480 | | PW2 | | .` 481 |OLT ----------------- PE2 -` 482 | B | | | 483 +-----+ +-----+ 484 Figure 3 An MPLS Network with Dual-homing PEs 486 Faults may be encountered in PON access links, or in the MPLS network 487 (including the working OLT). Procedures for these cases are described 488 in this section (it is assumed that both OLTs and PEs are working in 489 independent mode of PW redundancy [RFC6870]). 491 6.1. Protection procedure upon PON link failures 493 When a fault is detected on a working PON link, a working OLT MUST 494 turn off its associated PON interface so that the protection trunk 495 link to the protection OLT can be activated, then it MUST send an LDP 496 fault notification message (i.e., with the status bit "Local AC 497 (ingress) Receive Fault " being set) to its peer PE on the remote end 498 of the PW. At the same time, the working OLT MUST send an ICCP 499 message with PON State TLV with local PON Port State being set to 500 notify the protection OLT of the PON fault. 502 Upon receiving a PON state TLV where Local PON Port state is set, a 503 protection OLT MUST activate the protection PON link in the 504 protection group, and advertise a notification message for the 505 protection PW with the Preferential Forwarding status bit of active 506 to the remote PE. 508 According to [RFC6870], the remote PE(s) can match the local and 509 remote Preferential Forwarding status and select PW2 as the new 510 active PW to which to send traffic. 512 6.2. Protection procedure upon PW failures 514 Usually MPLS networks have its own protection mechanism such as LSP 515 protection or Fast Reroute (FRR). But in a link sparse access or 516 aggregation network where protection for a PW is impossible in its 517 LSP layer, the following PW layer protection procedures can be 518 enabled. 520 When a fault is detected on its working PW (e.g., by VCCV BFD), a 521 working OLT SHOULD turn off its associated PON interface and then 522 send an ICCP message with PON State TLV with local PON Port State 523 being set to notify the protection OLT of the PON fault. 525 Upon receiving a PON state TLV where Local PON Port state is set, the 526 protection OLT MUST activate its PON interface to the protection 527 trunk fiber. At the same time, the protection OLT MUST send a 528 notification message for the protection PW with the Preferential 529 Forwarding status bit of active to the remote PE, so that traffic can 530 be switched to the protection PW. 532 6.3. Protection procedure upon the working OLT failure 534 As depicted in Fig. 2, a service is provisioned with a working PW and 535 a protection PW, both PW terminated on PE1. If PE1 lost its 536 connection to the working OLT, it SHOULD send a LDP notification 537 message on the protection PW with the Request Switchover bit set. 539 Upon receiving a LDP notification message from its remote PE with the 540 Request Switchover bit set, a protection OLT MUST activate its 541 optical interface to the protection trunk fiber and activate the 542 associated protection PW, so that traffic can be reliably switched to 543 the protection trunk PON link and the protection PW. 545 In the case of Fig.3, PW-RED State TLV [ICCP] can be used by PE1 to 546 notify PE2 the faults in all the scenarios, and PE2 operates the same 547 as described in Section 5.1 to 5.3. 549 7. Security Considerations 551 Security considerations as described in [ICCP] apply. 553 8. IANA Considerations 555 These values are requested from the registry of "ICC RG parameter 556 type": 557 0x00X0 PON Connect TLV 558 0x00X1 PON Disconnect TLV 559 0x00X2 PON Configuration TLV 560 0x00X3 PON State TLV 561 0x00X4 PON ONU Database Sync TLV 563 9. References 565 9.1. Normative References 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, March 1997 570 [RFC6870] Muley, P., Aissaoui, M., "Pseudowire Preferential 571 Forwarding Status Bit", RFC 6870, February 2013 573 [ICCP] Martini, L. and et al, "Inter-Chassis Communication Protocol 574 for L2VPN PE Redundancy", RFC 7275, June 2014 576 9.2. Informative References 578 [RFC6456] Li, H., Zheng, R., and Farrel, A., "Multi-Segment 579 Pseudowires in Passive Optical Networks", RFC 6456, 580 November 2011 582 [SEAMLESS] Leymann, N., and et al, "Seamless MPLS Architecture", 583 draft-ietf-mpls-seamless-mpls-04, Work in progress 585 [G983.1] ITU-T, "Broadband optical access systems based on Passive 586 Optical Networks (PON)", ITU-T G.983.1, January, 2005 588 [IEEE-1904.1] IEEE Std. 1904.1, "Standard for Service 589 Interoperability in Ethernet Passive Optical Networks 590 (SIEPON)", IEEE Computer Society, June, 2013 592 [IEEE-802] IEEE Std. 802, "IEEE Standard for Local and Metropolitan 593 Area Networks: Overview and Architecture", IEEE Computer 594 Society, December, 2001 with amendments 596 [TR-221] BBF TR-221, "Technical Specifications for MPLS in Mobile 597 Backhaul Networks", the Broadband Forum, October, 2011 599 [SD-331] BBF SD-331, "Architecture and Technical Requirements for 600 PON-Based Mobile Backhaul Networks", the Broadband Forum, 601 Work in progress 603 10. Acknowledgments 605 The authors would like to thank Min Ye, Hongyu Li, Wei Lin, Xifeng 606 Wan, Yannick Legoff and Shrinivas Joshi for their valuable 607 discussions and comments. 609 Authors' Addresses 611 Yuanlong Jiang 612 Huawei Technologies Co., Ltd. 613 Bantian, Longgang district 614 Shenzhen 518129, China 615 Email: jiangyuanlong@huawei.com 617 Yong Luo 618 Huawei Technologies Co., Ltd. 619 Bantian, Longgang district 620 Shenzhen 518129, China 621 Email: dennis.luoyong@huawei.com 623 Edwin Mallette 624 Bright House Networks 625 4145 S. Falkenburg Road 626 Tampa, FL 33578 USA 627 Email: edwin.mallette@gmail.com 629 Chengbin Shen 630 China Telecom 631 Email: shencb@sttri.com.cn 633 Yimin Shen 634 Juniper Networks 635 10 Technology Park Drive 636 Westford, MA 01886, USA 637 Email: yshen@juniper.net 639 Weiqiang Cheng 640 China Mobile 641 No.32 Xuanwumen West Street 642 Beijing 100053, China 643 Email: chengweiqiang@chinamobile.com 645 Guangtao Zhou 646 China Unicom 647 No.9 Shouti South Road 648 Beijing 100048, China 649 Email: zhouguangtao@chinaunicom.cn