idnits 2.17.1 draft-jiang-pwe3-mc-pon-02.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 (April 2, 2014) is 3674 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 377, but not defined == Unused Reference: 'IEEE-802' is defined on line 577, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-04 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-iccp-11 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group Y. Jiang 2 Y. Luo 3 Internet Draft Huawei 4 E. Mallette 5 Intended status: Standards Track Bright House Networks 6 C. Shen 7 China Telecom 8 Y. Shen 9 Juniper Networks 10 Expires: October 2014 April 2, 2014 12 Multi-chassis PON Protection in MPLS 13 draft-jiang-pwe3-mc-pon-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on October 2, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Abstract 54 MPLS is being deployed deeper into operator networks, often to or 55 past the access network node. Separately network access nodes such as 56 PON OLTs have evolved to support first-mile access protection, where 57 one or more physical OLTs provide first-mile diversity to the 58 customer edge. Multi-homing support is needed on the MPLS-enabled PON 59 OLT to provide resiliency for provided services. This document 60 describes the multi-chassis PON protection architecture in MPLS and 61 also proposes the ICCP extension to support it. 63 Table of Contents 65 1. Conventions used in this document ...................... 2 66 2. Terminology ............................................ 3 67 3. Introduction ........................................... 3 68 4. ICCP Protocol Extensions................................ 5 69 4.1. Multi-chassis PON Application TLVs .................. 5 70 4.1.1. PON Connect TLV .................................. 5 71 4.1.2. PON Disconnect TLV................................ 6 72 4.1.3. PON Configuration TLV ............................ 7 73 4.1.4. PON State TLV .................................... 8 74 4.1.5. PON ONU Database Sync TLV ........................ 8 75 5. PON ONU Database Synchronization ...................... 10 76 6. Multi-chassis PON application procedures .............. 10 77 6.1. Protection procedure upon PON link failures ........ 12 78 6.2. Protection procedure upon PW failures .............. 12 79 6.3. Protection procedure upon the working OLT failure .. 12 80 7. Security Considerations ............................... 13 81 8. IANA Considerations ................................... 13 82 9. References ............................................ 13 83 9.1. Normative References ............................... 13 84 9.2. Informative References ............................. 13 85 10. Acknowledgments ....................................... 14 86 Authors' Addresses ......................................... 15 88 1. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Terminology 96 DSL Digital Subscriber Line 98 FTTx Fiber-to-the-x (FTTx, x = H for home, P for premises, C for curb) 100 ICCP Inter-Chassis Communication Protocol 102 OLT Optical Line Termination 104 ONU Optical Network Unit 106 MPLS Multi-Protocol Label Switching 108 PON Passive Optical Network 110 3. Introduction 112 MPLS is being extended to the edge of operator networks, as is 113 described in the seamless MPLS use cases [SEAMLESS], and the MS-PW 114 with PON access use case [RFC6456]. Combining MPLS with OLT access 115 further facilitates a low cost multi-service convergence. 117 Tens of millions of FTTx lines have been deployed over the years, 118 with many of those lines being some PON variant. PON provides 119 operators a cost-effective solution for delivering high bandwidth 120 (1Gbps or even 10Gbps) to a dozen or more subscribers simultaneously. 122 In the past, access technologies such as Passive Optical Network (PON) 123 and Digital Subscriber Line (DSL) are usually used for subscribers, 124 and no redundancy is provided in their deployment. 126 But with the rapid growth of mobile data traffic, more and more LTE 127 small cells and Wi-Fi hotspots are deployed. PON is considered as a 128 viable low cost backhaul solution for these mobile services. Besides 129 its high bandwidth and scalability, PON further provides 130 synchronization features, e.g., SyncE and IEEE1588 functionality, 131 which can fulfill synchronization needs of mobile backhaul services. 133 Unlike typical residential service where a single or handful of end- 134 users hangs off of a single PON OLT port in a physical optical 135 distribution network, a PON port that supports a dozen LTE small 136 cells or Wi-Fi hotspots could be providing service to hundreds of 137 simultaneous subscribers. Small cell backhaul often demands the 138 economics of a PON first-mile and yet expects first-mile protection 139 commonly available in point-to-point access portfolio. 141 Some optical layer of protection mechanisms, such as Trunk and Tree 142 protection, are specified in [IEEE-1904.1] to avoid single point of 143 failure in the access. They are called Type B and Type C protection 144 respectively in [G983.1]. 146 Trunk protection architecture is an economical PON resiliency 147 mechanism, where the working OLT and the working link between the 148 working splitter port and the working OLT (i.e., the working trunk 149 fiber) is protected by a redundant protection OLT and a redundant 150 trunk fiber between the protection splitter port and the protection 151 OLT, however it only protects a portion of the optical path from OLT 152 to ONUs. This is different from the more complex and costly Type C 153 protection architecture where there is a working optical distribution 154 network path from the working OLT and a complete protected optical 155 distribution network path from the protection OLT to the ONUs. Figure 156 1 demonstrates a typical scenario of Trunk protection. 158 | | 159 |<--Optical Distribution Network->| 160 | | 161 | branch trunk +-----+ 162 +-----+ fibers fibers | | 163 Base ------| | | . OLT | 164 Stations ------| ONU |\ | ,'`| A | 165 ------| | \ V _-` +-----+ 166 +-----+ \ .' 167 . \ +----------+ ,-` 168 +-----+ . \| -` Working 169 Base ------| | . | Optical | 170 Stations ------| ONU |---------| Splitter | 171 ------| | . /| -, Protection 172 +-----+ . / +----------+ `'., 173 / `-, +-----+ 174 +-----+ / `'.,| | 175 Base ------| |/ | OLT | 176 Stations ------| ONU | | B | 177 ------| | +-----+ 178 +-----+ 179 Figure 1 Trunk Protection Architecture in PON 181 Besides small cell backhaul, this protection architecture can also be 182 applicable to other services, for example, DSL and Multi-System 183 Operator (MSO) services. In that case, an ONU in Figure 1 can play 184 the similar role as a Digital Subscriber Line Access Multiplexer 185 (DSLAM) and dozens of Customer Premises Equipments (CPEs) or cable 186 modems may be attached to it. 188 In some deployments, it is also possible that only some ONUs are 189 needed to be protected. 191 The PON architecture depicted in Figure 1 can provide redundancy in 192 its physical topology, however, all traffic including link OAM are 193 blocked on the protection link. Therefore, some standard signaling 194 mechanisms are needed between OLTs to exchange information, for 195 example, PON link status, registered ONU information, and network 196 status, so that protection and restoration can be done both rapidly 197 and reliably, especially when the OLTs also support MPLS. 199 ICCP [ICCP] provides a framework for inter-chassis synchronization of 200 state and configuration data between a set of two or more PEs. 201 Currently ICCP only defines application specific messages for PW 202 redundancy and mLACP, but it can be easily extended to support PON as 203 an Attachment Circuit (AC) redundancy. 205 This document proposes the extension of ICCP to support Multi-chassis 206 PON protection in MPLS. 208 4. ICCP Protocol Extensions 210 4.1. Multi-chassis PON Application TLVs 212 A set of multi-chassis PON application TLVs are defined in the 213 following sub-sections. 215 4.1.1. PON Connect TLV 217 This TLV is included in the RG Connect message to signal the 218 establishment of PON application connection. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |U|F| Type=0x00XX | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Protocol Version |A| Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Optional Sub-TLVs | 228 ~ ~ 229 | | 230 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 - U and F Bits, both are set to 0. 235 - Type, set to 0x00XX for "PON Connect TLV". 237 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 238 Type, and Length fields. 240 - Protocol Version, the version of this PON specific protocol for the 241 purposes of inter-chassis communication. This is set to 0x0001. 243 - A Bit, Acknowledgement Bit. Set to 1 if the sender has received a 244 PON Connect TLV from the recipient. Otherwise, set to 0. 246 - Reserved, Reserved for future use. 248 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 249 version of the protocol. 251 4.1.2. PON Disconnect TLV 253 This TLV is included in the RG Disconnect message to indicate that 254 the connection for the PON application is to be terminated. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |U|F| Type=0x00XX | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Optional Sub-TLVs | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 - U and F Bits, both are set to 0. 266 - Type, set to 0x00XX for "PON Disconnect TLV". 268 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 269 Type, and Length fields. 271 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 272 version of the protocol. 274 4.1.3. PON Configuration TLV 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |U|F| Type=0x00XX | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | System ID | 282 | | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | System Priority | Port ID | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 - U and F Bits, both are set to 0. 290 - Type, set to 0x00XX for "PON Configuration TLV". 292 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 293 Type, and Length fields. 295 - System ID, 8 octets encoding the System ID used by the OLT, which 296 is the Chassis MAC address. If a 6 octet System ID is used, the least 297 significant 2 octets of the 8 octet field will be encoded as 0000. 299 - System Priority, 2 octets encoding the System Priority. 301 - Port ID, 2 octets PON Port ID. 303 Further configuration considerations such as multicast table and ARP 304 table for static MAC addresses will be added in a next version. 306 4.1.4.PON State TLV 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |U|F| Type=0x00XX | Length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | ROID | 314 | | 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Local PON Port state | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Remote PON Port state | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 - U and F Bits, both are set to 0. 324 - Type, set to 0x00XX for "PON State TLV" 326 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 327 Type, and Length fields. 329 - ROID, as defined in the ROID section of [ICCP]. 331 - Local PON Port State, the status of the local PON port as 332 determined by the sending OLT (PE). The last bit is defined as Fault 333 indication of the PON Port associated with this PW (1 - in fault). 335 - Remote PON Port State, the status of the remote PON port as 336 determined by the remote peer of the sending OLT (PE). The last bit 337 is defined as Fault indication of the PON Port associated with this 338 PW (1 - in fault). 340 4.1.5.PON ONU Database Sync TLV 342 This TLV is used to communicate the registered ONU database 343 associated with a PON port between the active and standby OLT. This 344 message is used to both transmit the PON ONU Database from working 345 OLT to protect OLT and to communicate the PON ONU database status 346 between protect OLT and working OLT. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |U|F| Type=0x00XX | Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | ROID | 354 | | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |A| Reserved | OUI | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 359 | ONU Database Entry1 | 360 ~ ~ 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 - U and F Bits, both are set to 0. 365 - Type, set to 0x00XX for "PON ONU Database Sync TLV" 367 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 368 Type, and Length fields. 370 - ROID, defined in the ROID section of [ICCP]. 372 - A bit, Acknowledgement bit. Set to 1 if the receiver has received a 373 PON ONU Database Sync. Otherwise, set to 0. 375 - Reserved, reserved for future use. 377 - OUI, the 3-byte [IEEE-802.3] organization unique identifier that 378 uniquely identifies the format for describing the registered ONU 379 database information. There are multiple PON standards and are 380 varying implementations within a given PON standard which likely have 381 different required information, format, etc., related to the ONU 382 Database Entry. 384 - ONU Database Entry, there may be one or more ONU Database Entries 385 transmitted in the PON ONU Database Sync TLV, each of which would 386 describe a registered ONU. The format of the ONU Database Entry is 387 outside the scope of this document and will be defined by the 388 relevant PON standard organization. 390 5. PON ONU Database Synchronization 392 Without an effective mechanism to communicate the registered ONUs 393 between the working and protect OLT, all registered ONUs would be de- 394 registered and go through re-registration during a switchover, which 395 would significantly increase protection time. To enable faster 396 switchover capability, the work OLT must be able to communicate the 397 registered ONUs associated with an ROID to the protection OLT. 399 The PON ONU Database Synchronization would begin once the ICCP PON 400 Application enters OPERATIONAL state. The work OLT, the one with the 401 working link member for the ROID, would begin transmitting the 402 database of actively registered ONUs to the protection OLT for the 403 same ROID. Each instance of the PON ONU Database Sync TLV describes a 404 set of ONU Database Entries. Each ONU Database Entry would describe a 405 registered ONU. 407 The transmission of PON ONU Database Descriptors for a given ROID is 408 only unidirectional - from the work OLT to the protect OLT. The 409 protect OLT would only be responsible for acknowledging the received 410 message to provide a reliable database synchronization mechanism. As 411 ONUs register and deregister from the working OLT, the working OLT 412 would transmit PON ONU Database Synchronization TLV including only 413 the updated ONU Database Entries. 415 If protected ONUs and unprotected ONUs are miscellaneously attached 416 to the same splitter, only the protected ONUs needs to be 417 synchronized. The specific ONUs which needs to be synchronized can be 418 policy driven and provisioned in the management plane, or by some 419 other signaling options. 421 6. Multi-chassis PON application procedures 423 Two typical MPLS protection network architectures for PON access are 424 depicted in Fig.2 and Fig.3 (their PON access segments are the same 425 as in Fig.1 and thus omitted for simplification). OLTs with MPLS 426 functionality are connected to a single PE (Fig.2) or dual home PEs 427 (Fig.3) respectively, i.e., the working OLT to PE1 by a working PW 428 and the protection OLT to PE1 or PE2 by a protection PW, thus these 429 devices constitute an MPLS network which provides PW transport 430 services between ONUs and a CE. 432 +-----+ 433 | | 434 |OLT1 -, 435 | | `., 436 +-----+ ', PW1 437 `', 438 `., +-----+ +-----+ 439 ', | | | | 440 `. PE1 ------------ CE | 441 .'`| | | | 442 ,-` +-----+ +-----+ 443 .` 444 +-----+ .'` PW2 445 | | ,-` 446 |OLT2 -` 447 | | 448 +-----+ 449 Figure 2 An MPLS Network with a Single PE 451 +-----+ +-----+ 452 | | PW1 | | 453 |OLT1 ----------------- PE1 -, 454 | | | | ', 455 +-----+ +--/--+ ', 456 | `. 457 | `. +-----+ 458 | `' | 459 | | CE | 460 | . | 461 | ,'+-----+ 462 | ,-` 463 +-----+ +--\--+ ,' 464 | | PW2 | | .` 465 |OLT2 ----------------- PE2 -` 466 | | | | 467 +-----+ +-----+ 468 Figure 3 An MPLS Network with Dual-homing PEs 470 Faults may be encountered in PON access links, or in the MPLS network 471 (including the working OLT). Procedures for these cases are described 472 in this section (it is assumed that both OLTs and PEs are working in 473 independent mode of PW redundancy [RFC6870]). 475 6.1. Protection procedure upon PON link failures 477 When a fault is detected on a working PON link, a working OLT MUST 478 turn off its associated PON interface so that the protection trunk 479 link to the protection OLT can be activated, then it MUST send an LDP 480 fault notification message (i.e., with the status bit "Local AC 481 (ingress) Receive Fault " being set) to its peer PE on the remote end 482 of the PW. At the same time, the working OLT MUST send an ICCP 483 message with PON State TLV with local PON Port State being set to 484 notify the protection OLT of the PON fault. 486 Upon receiving a PON state TLV where Local PON Port state is set, a 487 protection OLT MUST activate the protection PON link in the 488 protection group, and advertise a notification message for the 489 protection PW with the Preferential Forwarding status bit of active 490 to the remote PE. 492 According to [RFC6870], the remote PE(s) can match the local and 493 remote Preferential Forwarding status and select PW2 as the new 494 active PW to which to send traffic. 496 6.2. Protection procedure upon PW failures 498 Usually MPLS networks have its own protection mechanism such as LSP 499 protection or Fast Reroute (FRR). But in a link sparse access or 500 aggregation network where protection for a PW is impossible in its 501 LSP layer, the following PW layer protection procedures can be 502 enabled. 504 When a fault is detected on its working PW (e.g., by VCCV BFD), a 505 working OLT SHOULD turn off its associated PON interface and then 506 send an ICCP message with PON State TLV with local PON Port State 507 being set to notify the backup OLT of the PON fault. 509 Upon receiving a PON state TLV where Local PON Port state is set, the 510 backup OLT MUST activate its PON interface to the protection trunk 511 fiber. At the same time, the backup OLT MUST send a notification 512 message for the protection PW with the Preferential Forwarding status 513 bit of active to the remote PE, so that traffic can be switched to 514 the protection PW. 516 6.3. Protection procedure upon the working OLT failure 518 As depicted in Fig. 2, a service is provisioned with a working PW and 519 a protection PW, both PW terminated on PE1. If PE1 lost its 520 connection to the working OLT, it SHOULD send a LDP notification 521 message on the protection PW with the Request Switchover bit set. 523 Upon receiving a LDP notification message from its remote PE with the 524 Request Switchover bit set, a protection OLT MUST activate its 525 optical interface to the protection trunk fiber and activate the 526 associated protection PW, so that traffic can be reliably switched to 527 the protection trunk PON link and the protection PW. 529 In the case of Fig.3, PW-RED State TLV [ICCP] can be used by PE1 to 530 notify PE2 the faults in all the scenarios, and PE2 operates the same 531 as described in Section 5.1 to 5.3. 533 7. Security Considerations 535 Security considerations as described in [ICCP] apply. 537 8. IANA Considerations 539 These values are requested from the registry of "ICC RG parameter 540 type": 541 0x00X0 PON Connect TLV 542 0x00X1 PON Disconnect TLV 543 0x00X2 PON Configuration TLV 544 0x00X3 PON State TLV 545 0x00X4 PON ONU Database Sync TLV 547 9. References 549 9.1. Normative References 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997 554 [RFC6870] Muley, P., Aissaoui, M., "Pseudowire Preferential 555 Forwarding Status Bit", RFC 6870, February 2013 557 9.2. Informative References 559 [RFC6456] Li, H., Zheng, R., and Farrel, A., "Multi-Segment 560 Pseudowires in Passive Optical Networks", RFC 6456, 561 November 2011 563 [SEAMLESS] Leymann, N., and et al, "Seamless MPLS Architecture", 564 draft-ietf-mpls-seamless-mpls-04, Work in progress 566 [ICCP] Martini, L. and et al, "Inter-Chassis Communication Protocol 567 for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-11, Work in 568 progress 570 [G983.1] ITU-T, "Broadband optical access systems based on Passive 571 Optical Networks (PON)", ITU-T G.983.1, January, 2005 573 [IEEE-1904.1] IEEE Std. 1904.1, "Standard for Service 574 Interoperability in Ethernet Passive Optical Networks 575 (SIEPON)", IEEE Computer Society, June, 2013 577 [IEEE-802] IEEE Std. 802, "IEEE Standard for Local and Metropolitan 578 Area Networks: Overview and Architecture", IEEE Computer 579 Society, December, 2001 with amendments 581 10. Acknowledgments 583 The authors would like to thank Min Ye, Hongyu Li, Wei Lin and Xifeng 584 Wan for their valuable discussions. 586 Authors' Addresses 588 Yuanlong Jiang 589 Huawei Technologies Co., Ltd. 590 Bantian, Longgang district 591 Shenzhen 518129, China 592 Email: jiangyuanlong@huawei.com 594 Yong Luo 595 Huawei Technologies Co., Ltd. 596 Bantian, Longgang district 597 Shenzhen 518129, China 598 Email: dennis.luoyong@huawei.com 600 Edwin Mallette 601 Bright House Networks 602 4145 S. Falkenburg Road 603 Tampa, FL 33578 USA 604 Email: edwin.mallette@gmail.com 606 Chengbin Shen 607 China Telecom 608 Email: shencb@sttri.com.cn 610 Yimin Shen 611 Juniper Networks 612 10 Technology Park Drive 613 Westford, MA 01886, USA 614 Email: yshen@juniper.net