idnits 2.17.1 draft-jiang-pwe3-mc-pon-01.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 2 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 (January 18, 2014) is 3750 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 355, but not defined == Unused Reference: 'IEEE-802' is defined on line 547, 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 7 Expires: July 2014 January 18, 2014 9 Multi-chassis PON Protection in MPLS 10 draft-jiang-pwe3-mc-pon-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on July 18, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 MPLS is being deployed deeper into operator networks, often to or 52 past the access network node. Separately network access nodes such as 53 PON OLTs have evolved to support first-mile access protection, where 54 one or more physical OLTs provide first-mile diversity to the 55 customer edge. Multi-homing support is needed on the MPLS-enabled PON 56 OLT to provide resiliency for provided services. This document 57 describes the multi-chassis PON protection architecture in MPLS and 58 also proposes the ICCP extension to support it. 60 Table of Contents 62 1. Conventions used in this document ......................... 2 63 2. Terminology ............................................... 3 64 3. Introduction .............................................. 3 65 3.1. Multi-chassis PON Application TLVs ..................... 5 66 3.1.1. PON Connect TLV ..................................... 5 67 3.1.2. PON Disconnect TLV .................................. 6 68 3.1.3. PON Configuration TLV ............................... 6 69 3.1.4. PON State TLV ....................................... 7 70 3.1.5. PON ONU Database Sync TLV ........................... 8 71 4. PON ONU Database Synchronization .......................... 9 72 5. Multi-chassis PON application procedures .................. 9 73 5.1. Protection procedure upon PON link failures ........... 11 74 5.2. Protection procedure upon PW failures ................. 11 75 5.3. Protection procedure upon the working OLT failure ..... 11 76 6. Security Considerations .................................. 12 77 7. IANA Considerations ...................................... 12 78 8. References ............................................... 12 79 8.1. Normative References .................................. 12 80 8.2. Informative References ................................ 12 81 9. Acknowledgments .......................................... 13 82 Authors' Addresses ............................................ 14 84 1. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Terminology 92 FTTx Fiber-to-the-x (FTTx, x = H for home, P for premises, C for curb) 94 ICCP Inter-Chassis Communication Protocol 96 OLT Optical Line Termination 98 ONU Optical Network Unit 100 MPLS Multi-Protocol Label Switching 102 PON Passive Optical Network 104 3. Introduction 106 MPLS is being extended to the edge of operator networks, as is 107 described in the seamless MPLS use cases [SEAMLESS], and the MS-PW 108 with PON access use case [RFC6456]. 110 Tens of millions of FTTx lines have been deployed over the last five 111 years, with many of those lines being some PON variant. PON provides 112 operators a cost-effective solution for delivering high bandwidth 113 (1Gbps or even 10Gbps) to a dozen or more subscribers simultaneously. 115 With the rapid growth of mobile data traffic, more and more LTE small 116 cells and Wi-Fi hotspots will be deployed in the future. Unlike 117 typical residential service where a single or handful of end-users 118 hang off of a single PON OLT port and physical optical distribution 119 network, a PON that supports a dozen LTE small cells or Wi-Fi 120 hotspots could be providing service to hundreds of simultaneous 121 subscribers. Deployment requirements for small cells often demand the 122 economics of a PON first-mile and yet expect first-mile protection 123 commonly available in point-to-point access portfolio. 125 PON also provides synchronization features, e.g., SyncE and IEEE1588 126 functionality, which can fulfill synchronization needs of mobile 127 backhaul services. Some optical layer of protection mechanisms, such 128 as Type B protection and Type C protection are specified [G983.1] to 129 avoid single point of failure in the access. [IEEE-1904.1] refers to 130 Type B and Type C protection as PON Trunk and Tree protection, 131 respectively. 133 Therefore, PON may play a greater role in the access end for the 134 mobile backhaul networks. Providing OLTs with some MPLS functionality 135 further facilitates multi-service convergence. 137 Type B protection architecture is an economical PON resiliency 138 mechanism, where the working OLT and the working link between the 139 working splitter port and the working OLT (i.e., the working trunk 140 fiber) is protected by a redundant protection OLT and a redundant 141 trunk fiber between the protection splitter port and the protection 142 OLT, however it only protects a portion of the optical path from OLT 143 to ONUs. This is different from the more complex and costly Type C 144 protection architecture where there is a working optical distribution 145 network path from the working OLT and a complete protected optical 146 distribution network path from the protection OLT to the ONUs. Figure 147 1 demonstrates a typical scenario of Type B PON protection. 149 | | 150 |<--Optical Distribution Network->| 151 | | 152 | branch trunk +-----+ 153 +-----+ fibers fibers | | 154 Base ------| | | . OLT | 155 Stations ------| ONU |\ | ,'`| A | 156 ------| | \ V _-` +-----+ 157 +-----+ \ .' 158 . \ +----------+ ,-` 159 +-----+ . \| -` Working 160 Base ------| | . | Optical | 161 Stations ------| ONU |---------| Splitter | 162 ------| | . /| -, Protection 163 +-----+ . / +----------+ `'., 164 / `-, +-----+ 165 +-----+ / `'.,| | 166 Base ------| |/ | OLT | 167 Stations ------| ONU | | B | 168 ------| | +-----+ 169 +-----+ 170 Figure 1 Type B PON protection Architecture 172 Though the PON architecture depicted in Figure 1 provides redundancy 173 in its physical topology, some standard mechanisms are needed to 174 exchange PON link status, registered ONU information, and network 175 status between OLTs in a Redundancy Group (RG) so that protection and 176 restoration can be done both rapidly and reliably, especially when 177 the OLTs also support MPLS. 179 ICCP [ICCP] provides a framework for inter-chassis synchronization of 180 state and configuration data between a set of two or more PEs. 181 Currently ICCP only defines application specific messages for PW 182 redundancy and mLACP, but it can be easily extended to support Type B 183 PON as an Attachment Circuit (AC) redundancy. 185 This document proposes the extension of ICCP to support Multi-chassis 186 PON protection in MPLS. 188 3.1. Multi-chassis PON Application TLVs 190 A set of multi-chassis PON application TLVs are defined in the 191 following sub-sections. 193 3.1.1. PON Connect TLV 195 This TLV is included in the RG Connect message to signal the 196 establishment of PON application connection. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |U|F| Type=0x00XX | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Protocol Version |A| Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Optional Sub-TLVs | 206 ~ ~ 207 | | 208 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | ... | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 - U and F Bits, both are set to 0. 213 - Type, set to 0x00XX for "PON Connect TLV". 215 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 216 Type, and Length fields. 218 - Protocol Version, the version of this PON specific protocol for the 219 purposes of inter-chassis communication. This is set to 0x0001. 221 - A Bit, Acknowledgement Bit. Set to 1 if the sender has received a 222 PON Connect TLV from the recipient. Otherwise, set to 0. 224 - Reserved, Reserved for future use. 226 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 227 version of the protocol. 229 3.1.2. PON Disconnect TLV 231 This TLV is included in the RG Disconnect message to indicate that 232 the connection for the PON application is to be terminated. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |U|F| Type=0x00XX | Length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Optional Sub-TLVs | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 - U and F Bits, both are set to 0. 244 - Type, set to 0x00XX for "PON Disconnect TLV". 246 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 247 Type, and Length fields. 249 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 250 version of the protocol. 252 3.1.3. PON Configuration TLV 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |U|F| Type=0x00XX | Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | System ID | 260 | | 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | System Priority | Port ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 - U and F Bits, both are set to 0. 268 - Type, set to 0x00XX for "PON Configuration TLV". 270 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 271 Type, and Length fields. 273 - System ID, 8 octets encoding the System ID used by the OLT, which 274 is the Chassis MAC address. If a 6 octet System ID is used, the least 275 significant 2 octets of the 8 octet field will be encoded as 0000. 277 - System Priority, 2 octets encoding the System Priority. 279 - Port ID, 2 octets PON Port ID. 281 Further configuration considerations such as multicast table and ARP 282 table for static MAC addresses will be added in a next version. 284 3.1.4.PON State TLV 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |U|F| Type=0x00XX | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | ROID | 292 | | 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Local PON Port state | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Remote PON Port state | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 - U and F Bits, both are set to 0. 302 - Type, set to 0x00XX for "PON State TLV" 304 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 305 Type, and Length fields. 307 - ROID, as defined in the ROID section of [ICCP]. 309 - Local PON Port State, the status of the local PON port as 310 determined by the sending OLT (PE). The last bit is defined as Fault 311 indication of the PON Port associated with this PW (1 - in fault). 313 - Remote PON Port State, the status of the remote PON port as 314 determined by the remote peer of the sending OLT (PE). The last bit 315 is defined as Fault indication of the PON Port associated with this 316 PW (1 - in fault). 318 3.1.5.PON ONU Database Sync TLV 320 This TLV is used to communicate the registered ONU database 321 associated with a PON port between the active and standby OLT. This 322 message is used to both transmit the PON ONU Database from working 323 OLT to protect OLT and to communicate the PON ONU database status 324 between protect OLT and working OLT. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |U|F| Type=0x00XX | Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | ROID | 332 | | 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |A| Reserved | OUI | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 337 | ONU Database Entry1 | 338 ~ ~ 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 - U and F Bits, both are set to 0. 343 - Type, set to 0x00XX for "PON ONU Database Sync TLV" 345 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 346 Type, and Length fields. 348 - ROID, defined in the ROID section of [ICCP]. 350 - A bit, Acknowledgement bit. Set to 1 if the receiver has received a 351 PON ONU Database Sync. Otherwise, set to 0. 353 - Reserved, reserved for future use. 355 - OUI, the 3-byte [IEEE-802.3] organization unique identifier that 356 uniquely identifies the format for describing the registered ONU 357 database information. There are multiple PON standards and are 358 varying implementations within a given PON standard which likely have 359 different required information, format, etc., related to the ONU 360 Database Entry. 362 - ONU Database Entry, there may be one or more ONU Database Entries 363 transmitted in the PON ONU Database Sync TLV, each of which would 364 describe a registered ONU. The format of the ONU Database Entry is 365 outside the scope of this document and will be defined by the 366 relevant PON standard organization. 368 4. PON ONU Database Synchronization 370 Without an effective mechanism to communicate the registered ONUs 371 between the work and protect OLT, all registered ONUs would be de- 372 registered and go through re-registration during a switchover, which 373 would significantly increase protection time. To enable faster 374 switchover capability, the work OLT must be able to communicate the 375 registered ONUs associated with an ROID to the protection OLT. 377 The PON ONU Database Synchronization would begin once the ICCP PON 378 Application enters OPERATIONAL state. The work OLT, the one with the 379 working link member for the ROID, would begin transmitting the 380 database of actively registered ONUs to the protection OLT for the 381 same ROID. Each instance of the PON ONU Database Sync TLV describes a 382 set of ONU Database Entries. Each ONU Database Entry would describe a 383 registered ONU. 385 The transmission of PON ONU Database Descriptors for a given ROID is 386 only unidirectional - from the work OLT to the protect OLT. The 387 protect OLT would only be responsible for acknowledging the received 388 message to provide a reliable database synchronization mechanism. As 389 ONUs register and deregister from the working OLT, the working OLT 390 would transmit PON ONU Database Synchronization TLV including only 391 the updated ONU Database Entries. 393 5. Multi-chassis PON application procedures 395 Two typical MPLS protection network architectures for PON access are 396 depicted in Fig.2 and Fig.3 (PON access segment is the same as in 397 Fig.1 and thus omitted for simplification). OLTs with MPLS 398 functionality are connected to a single PE (Fig.2) or dual home PEs 399 (Fig.3) respectively, thus these devices constitute an MPLS network 400 which provides PW transport services between ONUs and a CE. 402 +-----+ 403 | | 404 |OLT1 -, 405 | | `., 406 +-----+ ', PW1 407 `', 408 `., +-----+ +-----+ 409 ', | | | | 410 `. PE1 ------------ CE | 411 .'`| | | | 412 ,-` +-----+ +-----+ 413 .` 414 +-----+ .'` PW2 415 | | ,-` 416 |OLT2 -` 417 | | 418 +-----+ 419 Figure 2 An MPLS network with a single PE 421 +-----+ +-----+ 422 | | PW1 | | 423 |OLT1 ----------------- PE1 -, 424 | | | | ', 425 +-----+ +--/--+ ', 426 | `. 427 | `. +-----+ 428 | `' | 429 | | CE | 430 | . | 431 | ,'+-----+ 432 | ,-` 433 +-----+ +--\--+ ,' 434 | | PW2 | | .` 435 |OLT2 ----------------- PE2 -` 436 | | | | 437 +-----+ +-----+ 438 Figure 3 An MPLS network with dual home PEs 440 Faults may be encountered in PON access links, or in the MPLS network 441 (including the working OLT). Procedures for these cases are described 442 in this section (it is assumed that both OLTs and PEs are working in 443 independent mode of PW redundancy [RFC6870]). 445 5.1. Protection procedure upon PON link failures 447 When a fault is detected on a working PON link, a working OLT MUST 448 turn off its associated PON interface so that the protection trunk 449 link to the protection OLT can be activated, then it MUST send an LDP 450 fault notification message (i.e., with the status bit "Local AC 451 (ingress) Receive Fault " being set) to its peer PE on the remote end 452 of the PW. At the same time, the working OLT MUST send an ICCP 453 message with PON State TLV with local PON Port State being set to 454 notify the protection OLT of the PON fault. 456 Upon receiving a PON state TLV where Local PON Port state is set, a 457 protection OLT MUST activate the protection PON link in the 458 protection group, and advertise a notification message for the 459 protection PW with the Preferential Forwarding status bit of active 460 to the remote PE. 462 According to [RFC6870], the remote PE(s) can match the local and 463 remote Preferential Forwarding status and select PW2 as the new 464 active PW to which to send traffic. 466 5.2. Protection procedure upon PW failures 468 Usually MPLS networks have its own protection mechanism such as LSP 469 protection or Fast Reroute (FRR). But in a link sparse access or 470 aggregation network where protection for a PW is impossible in its 471 LSP layer, the following PW layer protection procedures can be 472 enabled. 474 When a fault is detected on its working PW (e.g., by VCCV BFD), a 475 working OLT SHOULD turn off its associated PON interface and then 476 send an ICCP message with PON State TLV with local PON Port State 477 being set to notify the backup OLT of the PON fault. 479 Upon receiving a PON state TLV where Local PON Port state is set, the 480 backup OLT MUST activate its PON interface to the protection trunk 481 fiber. At the same time, the backup OLT MUST send a notification 482 message for the protection PW with the Preferential Forwarding status 483 bit of active to the remote PE, so that traffic can be switched to 484 the protection PW. 486 5.3. Protection procedure upon the working OLT failure 488 As depicted in Fig. 2, a service is provisioned with a working PW and 489 a protection PW, both PW terminated on PE1. If PE1 lost its 490 connection to the working OLT, it SHOULD send a LDP notification 491 message on the protection PW with the Request Switchover bit set. 493 Upon receiving a LDP notification message from its remote PE with the 494 Request Switchover bit set, a protection OLT MUST activate its 495 optical interface to the protection trunk fiber and activate the 496 associated protection PW, so that traffic can be reliably switched to 497 the protection trunk PON link and the protection PW. 499 In the case of Fig.3, PW-RED State TLV [ICCP] can be used by PE1 to 500 notify PE2 the faults in all the scenarios, and PE2 operates the same 501 as described in Section 5.1 to 5.3. 503 6. Security Considerations 505 Security considerations as described in [ICCP] apply. 507 7. IANA Considerations 509 These values are requested from the registry of "ICC RG parameter 510 type": 511 0x00X0 PON Connect TLV 512 0x00X1 PON Disconnect TLV 513 0x00X2 PON Configuration TLV 514 0x00X3 PON State TLV 515 0x00X4 PON ONU Database Sync TLV 517 8. References 519 8.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997 524 [RFC6870] Muley, P., Aissaoui, M., "Pseudowire Preferential 525 Forwarding Status Bit", RFC 6870, February 2013 527 8.2. Informative References 529 [RFC6456] Li, H., Zheng, R., and Farrel, A., "Multi-Segment 530 Pseudowires in Passive Optical Networks", RFC 6456, 531 November 2011 533 [SEAMLESS] Leymann, N., and et al, "Seamless MPLS Architecture", 534 draft-ietf-mpls-seamless-mpls-04, Work in progress 536 [ICCP] Martini, L. and et al, "Inter-Chassis Communication Protocol 537 for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-11, Work in 538 progress 540 [G983.1] ITU-T, "Broadband optical access systems based on Passive 541 Optical Networks (PON)", ITU-T G.983.1, January, 2005 543 [IEEE-1904.1] IEEE Std. 1904.1, "Standard for Service 544 Interoperability in Ethernet Passive Optical Networks 545 (SIEPON)", IEEE Computer Society, June, 2013 547 [IEEE-802] IEEE Std. 802, "IEEE Standard for Local and Metropolitan 548 Area Networks: Overview and Architecture", IEEE Computer 549 Society, December, 2001 with amendments 551 9. Acknowledgments 553 The authors would like to thank Min Ye, Hongyu Li, Wei Lin and Xifeng 554 Wan for their valuable discussions. 556 Authors' Addresses 558 Yuanlong Jiang 559 Huawei Technologies Co., Ltd. 560 Bantian, Longgang district 561 Shenzhen 518129, China 562 Email: jiangyuanlong@huawei.com 564 Yong Luo 565 Huawei Technologies Co., Ltd. 566 Bantian, Longgang district 567 Shenzhen 518129, China 568 Email: dennis.luoyong@huawei.com 570 Edwin Mallette 571 Bright House Networks 572 4145 S. Falkenburg Road 573 Tampa, FL 33578 USA 574 Email: edwin.mallette@gmail.com