idnits 2.17.1 draft-ietf-pals-mc-pon-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2016) is 2767 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Jiang, Ed. 2 Internet-Draft Y. Luo 3 Intended status: Standards Track Huawei 4 E. Mallette, Ed. 5 Charter Communications 6 Y. Shen 7 Juniper Networks 8 W. Cheng 9 China Mobile 10 Expires: March 2017 September 28, 2016 12 Multi-chassis Passive Optical Network (PON) Protection in MPLS 13 draft-ietf-pals-mc-pon-05 15 Abstract 17 Multi-Protocol Label Switching (MPLS) is being extended to the edge 18 of operator networks including the network access nodes. Separately 19 network access nodes such as Passive Optical Network (PON) Optical 20 Line Terminations (OLTs) have evolved to support first-mile access 21 protection, where one or more physical OLTs provide first-mile 22 diversity to the customer edge. Multi-homing support is needed on 23 the MPLS-enabled PON OLT to provide resiliency for provided services. 24 This document describes the multi-chassis PON protection 25 architecture in MPLS and also specifies the Inter-Chassis 26 Communication Protocol (ICCP) extension to support it. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with 31 the provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on March 28, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction .............................................. 3 68 1.1. Conventions used in this document ...................... 5 69 1.2. Terminology ............................................ 5 70 2. ICCP Protocol Extensions .................................. 6 71 2.1. Multi-chassis PON Application TLVs ..................... 6 72 2.1.1. PON Connect TLV ..................................... 6 73 2.1.2. PON Disconnect TLV .................................. 7 74 2.1.3. PON System Configuration TLV ........................ 8 75 2.1.4. PON State TLV ....................................... 9 76 3. Considerations on PON ONU Database Synchronization ....... 10 77 4. Multi-chassis PON application procedures ................. 10 78 4.1. Protection procedure upon PON link failures ........... 12 79 4.2. Protection procedure upon PW failures ................. 12 80 4.3. Protection procedure upon the working OLT failure ..... 13 81 5. Security Considerations .................................. 13 82 6. IANA Considerations ...................................... 14 83 7. References ............................................... 14 84 7.1. Normative References .................................. 14 85 7.2. Informative References ................................ 14 86 8. Acknowledgments .......................................... 15 87 Contributors .................................................. 15 88 Authors' Addresses ............................................ 16 90 1. Introduction 92 Multi-Protocol Label Switching (MPLS) is being extended to the edge 93 of operator networks, as is described in the Multi-Segment 94 Pseudowires with Passive Optical Network (PON) access use case 95 [RFC6456]. Combining MPLS with Optical Line Termination (OLT) access 96 further facilitates a low cost multi-service convergence. 98 Tens of millions of Fiber-to-the-x (FTTx, x = H for home, P for 99 premises, C for curb) lines have been deployed over the years, with 100 many of those lines being some PON variant. PON provides operators a 101 cost-effective solution for delivering high bandwidth (1Gbps or even 102 10Gbps) to a dozen or more subscribers simultaneously. 104 In the past, access technologies such as PON and Digital Subscriber 105 Line (DSL) are usually used for subscribers, and no redundancy is 106 provided in their deployment. 108 But with the rapid growth of mobile data traffic, more and more Long 109 Term Evolution (LTE) small cells and Wi-Fi hotspots are deployed. 110 PON is considered a viable low cost backhaul solution for these 111 mobile services. Besides its high bandwidth and scalability, PON 112 further provides frequency and time synchronization features, e.g., 113 SyncE [G.8261] and IEEE 1588v2 [IEEE-1588] functionality, which can 114 fulfill synchronization needs of mobile backhaul services. 116 The Broadband Forum specifies reference architecture for mobile 117 backhaul network using MPLS transport in [TR-221] where PON can be 118 the access technology. 120 Unlike typical residential service where a single or handful of end- 121 users hangs off a single PON OLT port in a physical optical 122 distribution network, a PON port that supports a dozen LTE small 123 cells or Wi-Fi hotspots could be providing service to hundreds of 124 simultaneous subscribers. Small cell backhaul often demands the 125 economics of a PON first-mile and yet expects first-mile protection 126 commonly available in a point-to-point access portfolio. 128 Some optical layer protection mechanisms, such as Trunk and Tree 129 protection, are specified in [IEEE-1904.1] to avoid single point of 130 failure in the access. They are called Type B and Type C protection 131 respectively in [G.983.1]. 133 Trunk protection architecture is an economical PON resiliency 134 mechanism, where the working OLT and the working link between the 135 working splitter port and the working OLT (i.e., the working trunk 136 fiber) is protected by a redundant protection OLT and a redundant 137 trunk fiber between the protection splitter port and the protection 138 OLT, however it only protects a portion of the optical path from OLT 139 to Optical Network Units (ONUs). This is different from the more 140 complex and costly Tree protection architecture where there is a 141 working optical distribution network path from the working OLT and a 142 complete protected optical distribution network path from the 143 protection OLT to the ONUs. Figure 1 depicts a typical scenario of 144 Trunk protection. 146 | | 147 |<--Optical Distribution Network->| 148 | | 149 | branch trunk +-----+ 150 +-----+ fibers fibers | | 151 Base ------| | | | . OLT | 152 Stations ------| ONU |\ | | ,'`| A | 153 ------| | \ V V -` +-----+ 154 +-----+ \ .' 155 . \ +----------+ ,-` 156 +-----+ . \| -` Working 157 Base ------| | . | Optical | 158 Stations ------| ONU |---------| Splitter | 159 ------| | . /| -, Protection 160 +-----+ . / +----------+ `'., 161 / `-, +-----+ 162 +-----+ / `'.,| | 163 Base ------| |/ | OLT | 164 Stations ------| ONU | | B | 165 ------| | +-----+ 166 +-----+ 167 Figure 1 Trunk Protection Architecture in PON 169 Besides small cell backhaul, this protection architecture can also 170 be applicable to other services, for example, Digital Subscriber 171 Line (DSL) and Multi-System Operator (MSO) services. In that case, 172 an ONU in Figure 1 can play the similar role as a Digital Subscriber 173 Line Access Multiplexer (DSLAM) or a DOCSIS Remote PHY device 174 [remote-phy], and it may further be attached with dozens of Customer 175 Premise devices. 177 In some deployments, it is also possible that only some ONUs need to 178 be protected. 180 The PON architecture as depicted in Figure 1 can provide redundancy 181 in its physical topology, however, all traffic including link 182 Operation Administration and Maintenance (OAM) are blocked on the 183 protection link which frustrates end to end protection mechanisms 184 such as those specified in ITU-T G.8031 [G.8031]. Therefore, some 185 standard signaling mechanisms are needed between OLTs to exchange 186 information, for example, PON link status, registered ONU 187 information, and network status, so that protection and restoration 188 can be done rapidly and reliably, especially when the OLTs also 189 support MPLS. 191 Inter-Chassis Communication Protocol (ICCP) [RFC7275] provides a 192 framework for inter-chassis synchronization of state and 193 configuration data between a set of two or more Provider Edges (PEs). 194 Currently ICCP only defines application specific messages for 195 Pseudowire (PW) redundancy and Multi-Chassis LACP (mLACP), but it 196 can be easily extended to support PON as an Attachment Circuit (AC) 197 redundancy. 199 This document proposes the extension of ICCP to support Multi- 200 chassis PON protection in MPLS. 202 1.1. Conventions used in this document 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 1.2. Terminology 210 DSL Digital Subscriber Line 212 FTTx Fiber-to-the-x (FTTx, x = H for home, P for premises, C for 213 curb) 215 ICCP Inter-Chassis Communication Protocol 217 OLT Optical Line Termination 219 ONU Optical Network Unit 221 MPLS Multi-Protocol Label Switching 223 PON Passive Optical Network 225 RG Redundancy Group 227 2. ICCP Protocol Extensions 229 2.1. Multi-chassis PON Application TLVs 231 A set of multi-chassis PON application Type-Length-Values (TLVs) are 232 defined in the following sub-sections. 234 2.1.1. PON Connect TLV 236 This TLV is included in the Redundancy Group (RG) Connect message to 237 signal the establishment of PON application connection. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |U|F| Type=0xTBD1 | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Protocol Version |A| Reserved | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Optional Sub-TLVs | 247 ~ ~ 248 | | 249 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | ... | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 - U and F Bits, both are set to 0. 255 - Type, set to 0xTBD1 for "PON Connect TLV". 257 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 258 Type, and Length fields. 260 - Protocol Version, the version of this PON specific protocol for 261 the purposes of inter-chassis communication. This is set to 0x0001. 263 - A Bit, Acknowledgement Bit. It MUST be set to 1 if the sender has 264 received a PON Connect TLV from the recipient. Otherwise, set to 0. 266 - Reserved, Reserved for future use, and MUST be set to zero. 268 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 269 version of the protocol. The structure of Optional Sub-TLVs is 270 defined as follows: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Sub-TLV Type | Length | Variable Length Value | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Variable Length Value | 278 | " | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 - The Optional Sub-TLV Type values will be allocated by IANA in a 282 registry of name "TLV Type Name Space" for Label Distribution 283 Protocol (LDP) Parameters. Processing of the Sub-TLV Types should 284 continue when unknown Sub-TLV Type parameters are encountered, and 285 they MUST be silently ignored. 287 - The Length field is defined as the length of the Sub-TLV Type 288 including the Sub-TLV Type field and Length field itself. 290 2.1.2. PON Disconnect TLV 292 This TLV is included in the RG Disconnect message to indicate that 293 the connection for the PON application is to be terminated. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |U|F| Type=0xTBD2 | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Optional Sub-TLVs | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 - U and F Bits, both are set to 0. 305 - Type, set to 0xTBD2 for "PON Disconnect TLV". 307 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 308 Type, and Length fields. 310 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 311 version of the protocol. 313 2.1.3. PON System Configuration TLV 315 The "PON System Configuration TLV" is included in the "RG 316 Application Data" message, and announces an OLT's system parameters 317 to other members in the same RG. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |U|F| Type=0xTBD3 | Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | System ID | 324 | | 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | System Priority | Port ID | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 - U and F Bits, both are set to 0. 332 - Type, set to 0xTBD3 for "PON System Configuration TLV". 334 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 335 Type, and Length fields. 337 - System ID, 8 octets encoding the System ID used by the OLT, which 338 is the Chassis MAC address. If a 6 octet System ID is used, the 339 least significant 2 octets of the 8-octet field will be encoded as 340 0000. 342 - System Priority, a 2-octet value assigned by management or 343 administration policy, the OLT with the numerically lower value of 344 System Priority has the higher priority. 346 - Port ID, 2 octets PON Port ID. 348 2.1.4. PON State TLV 350 The "PON State TLV" is included in the "RG Application Data" message, 351 and used by an OLT to report its PON states to other members in the 352 same RG. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |U|F| Type=0xTBD4 | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | ROID | 360 | | 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Local PON Port state | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Remote PON Port state | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 - U and F Bits, both are set to 0. 370 - Type, set to 0xTBD4 for "PON State TLV" 372 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 373 Type, and Length fields. 375 - ROID, Redundant Object ID (ROID) as defined in Section 4.3 of 376 [RFC7275]. 378 - Local PON Port State, the status of the local PON port as 379 determined by the sending OLT (PE). The last bit is defined as Fault 380 indication of the PON Port associated with this PW (1 - in fault; 0 381 - in normal). 383 - Remote PON Port State, the status of the remote PON port as 384 determined by the remote peer of the sending OLT (i.e., the sending 385 PE). The last bit is defined as Fault indication of the PON Port 386 associated with this PW (1 - in fault; 0 - in normal). 388 3. Considerations on PON ONU Database Synchronization 390 Without an effective mechanism to communicate the registered ONUs 391 between the working and protection OLT, all registered ONUs would be 392 de-registered and go through re-registration during a switchover, 393 which would significantly increase protection time. To enable faster 394 switchover capability, the working and protection OLTs need to know 395 about the protected ONUs. To enable service continuity a mechanism 396 needs to be employed such that the operational state and significant 397 configuration data of both the protected ONU and the services 398 provisioned to it can be distributed to the working and protection 399 OLT. 401 The specific ONUs configuration and operational data can be 402 synchronized by some policy mechanism or provisioned in the 403 management plane. Alternatively said synchronization could occur by 404 some other signaling options. Describing how to synchronize the 405 configuration objects associated with both protected ONU as well as 406 the services constructed to the ONU (e.g. ONU MAC address, IPv4 407 addresses, IPv6 addresses, VLAN identifiers, etc.) is outside of the 408 scope of this document. 410 4. Multi-chassis PON application procedures 412 Two typical MPLS protection network architectures for PON access are 413 depicted in Fig.2 and Fig.3 (their PON access segments are the same 414 as in Fig.1 and thus omitted for simplification). OLTs with MPLS 415 functionality are connected to a single PE (Fig.2) or dual home PEs 416 (Fig.3) respectively, i.e., the working OLT to PE1 by a working PW 417 and the protection OLT to PE1 or PE2 by a protection PW, thus these 418 devices constitute an MPLS network which provides PW transport 419 services between ONUs and a Customer Edge (CE), and the PWs can 420 provide protection for each other. 422 +-----+ 423 | | 424 |OLT -, 425 | A | `., 426 +-----+ ', PW1 427 `', 428 `., +-----+ +-----+ 429 ', | | | | 430 `. PE1 ------------ CE | 431 .'`| | | | 432 ,-` +-----+ +-----+ 433 .` 434 +-----+ .'` PW2 435 | | ,-` 436 |OLT -` 437 | B | 438 +-----+ 439 Figure 2 An MPLS Network with a Single PE 441 +-----+ +-----+ 442 | | PW1 | | 443 |OLT ----------------- PE1 -, 444 | A | | | ', 445 +-----+ +--/--+ ', 446 | `. 447 | `. +-----+ 448 | `' | 449 | | CE | 450 | . | 451 | ,'+-----+ 452 | ,-` 453 +-----+ +--\--+ ,' 454 | | PW2 | | .` 455 |OLT ----------------- PE2 -` 456 | B | | | 457 +-----+ +-----+ 458 Figure 3 An MPLS Network with Dual-homing PEs 460 Faults may be encountered in PON access links, or in the MPLS 461 network (including the working OLT). Procedures for these cases are 462 described in this section (it is assumed that both OLTs and PEs are 463 working in the independent mode of PW redundancy [RFC6870]). 465 4.1. Protection procedure upon PON link failures 467 When a fault is detected on a working PON link, a working OLT 468 switches to the corresponding protection PON link attached with its 469 protection OLT, i.e., the working OLT turns off its faulty PON 470 interface so that the protection trunk link to its protection OLT 471 can be activated. The working OLT then MUST send an LDP fault 472 notification message (i.e., with the status bit "Local AC (ingress) 473 Receive Fault" being set) to its peer PE on the remote end of the PW. 474 At the same time, the working OLT MUST send an ICCP message with PON 475 State TLV with local PON Port State being set to notify the 476 protection OLT of the PON fault. 478 Upon receiving a PON state TLV where Local PON Port state is set, a 479 protection OLT MUST activate the protection PON link in the 480 protection group, and advertise a notification message for the 481 protection PW with the Preferential Forwarding status bit of active 482 to the remote PE. 484 According to [RFC6870], the remote PE(s) can match the local and 485 remote Preferential Forwarding status and select PW2 as the new 486 active PW over which data traffic is sent. 488 4.2. Protection procedure upon PW failures 490 Usually MPLS networks have its own protection mechanism such as LSP 491 protection or Fast Reroute (FRR). But in a link sparse access or 492 aggregation network where protection for a PW is impossible in its 493 LSP layer, the following PW layer protection procedures can be 494 enabled. 496 When a fault is detected on its working PW (e.g., by VCCV BFD), a 497 working OLT SHOULD turn off its associated PON interface and then 498 send an ICCP message with PON State TLV with local PON Port State 499 being set to notify the protection OLT of the PON fault. 501 Upon receiving a PON state TLV where Local PON Port state is set, 502 the protection OLT MUST activate its PON interface to the protection 503 trunk fiber. At the same time, the protection OLT MUST send a 504 notification message for the protection PW with the Preferential 505 Forwarding status bit of active to the remote PE, so that traffic 506 can be switched to the protection PW. 508 4.3. Protection procedure upon the working OLT failure 510 As depicted in Fig. 2, a service is provisioned with a working PW 511 and a protection PW, both PW terminated on PE1. If PE1 lost its 512 connection to the working OLT, it SHOULD send an LDP notification 513 message on the protection PW with the Request Switchover bit set. 515 Upon receiving an LDP notification message from its remote PE with 516 the Request Switchover bit set, a protection OLT MUST activate its 517 optical interface to the protection trunk fiber and activate the 518 associated protection PW, so that traffic can be reliably switched 519 to the protection trunk PON link and the protection PW. 521 In the case of Fig.3, PW-RED State TLV as described in Section 7.1 522 of [RFC7275] can be used by PE1 to notify PE2 the faults in all the 523 scenarios, and PE2 operates the same as described in Section 5.1 to 524 5.3. 526 5. Security Considerations 528 Similar to ICCP itself, this ICCP application SHOULD only be used in 529 well-managed and highly monitored service provider PON access 530 networks in a single administrative domain, including the 531 implementation of rogue ONU attachment detection and mitigation via 532 device authentication. Thus many of the security considerations as 533 described in [RFC7275] apply here as well. 535 Again, similar to ICCP, activity on the attachment circuits may 536 cause security threats or be exploited to create denial-of-service 537 attacks. In many passive optical networks, the optical paths between 538 OLT and ONUs traverse publicly accessible facilities including 539 public attachments (e.g. telephone poles), which opens up the risk 540 of excessive link bouncing by optical layer impairment. While ICCP 541 for MC-PON interconnects in the MPLS domain and does not traverse 542 the PON network, risks do include introduction of a malicious ONU 543 which could cause, for example, excessive link bouncing. This link 544 bouncing could result in increased ICCP exchanges similar to the 545 malicious CE case described in [RFC7275]. Operators of such networks 546 should take additional care to restrict unauthorized ONUs and to 547 limit the impact of link bouncing at the OLT, as these could result 548 in service impairment. 550 6. IANA Considerations 552 The IANA maintains a top-level registry called "Pseudowire Name 553 Spaces (PWE3)". It has a subregistry called "ICC RG Parameter 554 Types". The following values are requested from this subregistry: 555 0xTBD1 PON Connect TLV 556 0xTBD2 PON Disconnect TLV 557 0xTBD3 PON Configuration TLV 558 0xTBD4 PON State TLV 560 [Note to IANA, to be removed by the RFC Editor: consecutive values 561 in the IETF Review range are requested.] 563 7. References 565 7.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 [RFC7275] Martini, L. et al, "Inter-Chassis Communication Protocol 574 for L2VPN PE Redundancy", RFC 7275, June 2014 576 7.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 [G.983.1] ITU-T, "Broadband optical access systems based on Passive 583 Optical Networks (PON)", ITU-T G.983.1, January, 2005 585 [G.8031] ITU-T, "Ethernet Linear Protection Switching", ITU-T G.8031, 586 January, 2015 588 [G.8261] ITU-T, "Timing and synchronization aspects in packet 589 networks", ITU-T G.8261, August, 2013 591 [IEEE-1588] IEEE Std. 1588, "IEEE Standard for a Precision Clock 592 Synchronization Protocol for Networked Measurement and 593 Control Systems", IEEE Instrumentation and Measurement 594 Society, July, 2008 596 [IEEE-1904.1] IEEE Std. 1904.1, "Standard for Service 597 Interoperability in Ethernet Passive Optical Networks 598 (SIEPON)", IEEE Computer Society, June, 2013 600 [TR-221] BBF TR-221, "Technical Specifications for MPLS in Mobile 601 Backhaul Networks", https://www.broadband- 602 forum.org/technical/download/TR-221.pdf, the Broadband 603 Forum, October, 2011 605 [remote-phy] CableLabs, "Remote PHY Specification", 606 http://www.cablelabs.com/wp-content/uploads/specdocs/CM- 607 SP-R-PHY-I01_150615.pdf, June, 2015 609 8. Acknowledgments 611 The authors would like to thank Min Ye, Hongyu Li, Wei Lin, Xifeng 612 Wan, Yannick Legoff, Shrinivas Joshi, Alexey Melnikov and Stephen 613 Farrell for their valuable discussions and comments. 615 Contributors 617 The following people made significant contributions to this document: 619 Chengbin Shen 620 China Telecom 621 1835 South Pudong Road 622 Shanghai 200122, China 623 Email: shencb@sttri.com.cn 625 Guangtao Zhou 626 China Unicom 627 No.9 Shouti South Road 628 Beijing 100048, China 629 Email: zhouguangtao@chinaunicom.cn 631 Authors' Addresses 633 Yuanlong Jiang (Editor) 634 Huawei Technologies Co., Ltd. 635 Bantian, Longgang district 636 Shenzhen 518129, China 637 Email: jiangyuanlong@huawei.com 639 Yong Luo 640 Huawei Technologies Co., Ltd. 641 Bantian, Longgang district 642 Shenzhen 518129, China 643 Email: dennis.luoyong@huawei.com 645 Edwin Mallette (Editor) 646 Charter Communications 647 4145 S. Falkenburg Road 648 Tampa, FL 33578 USA 649 Email: edwin.mallette@gmail.com 651 Yimin Shen 652 Juniper Networks 653 10 Technology Park Drive 654 Westford, MA 01886, USA 655 Email: yshen@juniper.net 657 Weiqiang Cheng 658 China Mobile 659 No.32 Xuanwumen West Street 660 Beijing 100053, China 661 Email: chengweiqiang@chinamobile.com