idnits 2.17.1 draft-jiang-pwe3-mc-pon-00.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 21, 2013) is 3839 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) == 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 (~~), 3 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 5 Intended status: Standards Track 7 Expires: April 2014 October 21, 2013 9 Multi-chassis PON Protection in MPLS 10 draft-jiang-pwe3-mc-pon-00.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 April 21, 2013. 34 Copyright Notice 36 Copyright (c) 2013 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 While MPLS is deployed further and further to the access network, a 52 converging network edge point which provides both MPLS and PON access 53 capability appears. To provide resiliency for its services, multi- 54 homing is needed to support PON access in MPLS. This document 55 describes the multi-chassis PON protection architecture in MPLS and 56 also proposes the ICCP extension to support it. 58 Table of Contents 60 1. Conventions used in this document ......................... 2 61 2. Terminology ............................................... 3 62 3. Introduction .............................................. 3 63 3.1. Multi-chassis PON Application TLVs ..................... 5 64 3.1.1. PON Connect TLV ..................................... 5 65 3.1.2. PON Disconnect TLV .................................. 6 66 3.1.3. PON Configuration TLV ............................... 6 67 3.1.4. PON State TLV ....................................... 7 68 4. Dual Homing protection procedures ......................... 8 69 4.1. Protection procedure upon PON interface failures ....... 9 70 4.2. Protection procedure upon PW failures .................. 9 71 4.3. Protection procedure upon the working OLT failure ...... 9 72 5. Security Considerations .................................. 10 73 6. IANA Considerations ...................................... 10 74 7. References ............................................... 10 75 7.1. Normative References .................................. 10 76 7.2. Informative References ................................ 10 77 8. Acknowledgments .......................................... 10 78 Authors' Addresses ............................................ 11 80 1. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Terminology 88 FTTx Fiber-to-the-x (FTTx, x = H for home, P for premises, C for curb) 90 ICCP Inter-Chassis Communication Protocol 92 OLT Optical Line Termination 94 ONU Optical Network Unit 96 MPLS Multi-Protocol Label Switching 98 PON Passive Optical Network 100 3. Introduction 102 MPLS is extending further and further to the edge of networks, for 103 example, the seamless MPLS use cases as described in [SEAMLESS], and 104 the MS-PW with PON access use case as described in [RFC6456], all 105 show that MPLS is approaching the access networks. 107 Passive Optical Network (PON) can provide high bandwidth of 1Gbps or 108 even 10Gbps, and provide support of access for dozens to more than 109 one hundred subscribers at the same time. A huge number of PON access 110 networks have been deployed over the last few years with the wide 111 spread of FTTx technology. 113 With the fast growth of mobile data traffic, more and more LTE small 114 cells and Wi-Fi hotspots will be deployed in the future. How to 115 backhaul a large number of small cells or hotspots will pose a great 116 challenge to mobile service providers. 118 PON access technology has the following advantages: 120 -saving trunk fibers with its point-to-multipoint physical topology; 122 -High bandwidth capability up to 10Gbps; 124 -Low Total Cost of Ownership (TCO). 126 PON also provides synchronization features, e.g., SyncE and IEEE1588 127 functionality, which can fulfill synchronization needs of mobile 128 backhaul services. Some optical layer of protection mechanisms, such 129 as Type B protection and Type C protection are also specified [G983.1] 130 to avoid single point of failure in the access. 132 Therefore, PON may play a greater role in the access end for the 133 mobile backhaul networks. Providing OLTs with MPLS functionality 134 further facilitates multi-service convergence. 136 Type B protection architecture is an economical PON resiliency 137 mechanism, where the working OLT and the working link between the 138 working splitter and the working OLT (i.e., the working fiber) is 139 protected by a redundant protection OLT and a redundant fiber between 140 the working splitter and the protection OLT. This is different from 141 the more complex and costly Type C protection architecture where 142 working splitter and the working fibers from ONUs to the working 143 splitter are further protected. Figure 1 demonstrates a typical 144 scenario of Type B PON protection. 146 | | 147 |<--Optical Distribution Network->| 148 | | 149 | branch trunk +-----+ 150 +-----+ fibers fibers | | 151 Base ------| | | . OLT | 152 Stations ------| ONU |\ | ,'`| A | 153 ------| | \ 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 Type B PON protection Architecture 169 Though the above PON architecture provides redundancy in its physical 170 topology, some standard mechanisms are needed to exchange PON link 171 status and network status between OLTs in a Redundancy Group (RG) so 172 that protection and restoration can be done reliably, especially when 173 the OLTs also support MPLS. Thus there is a need for Multi-chassis 174 PON protection protocol in MPLS. 176 ICCP [ICCP] provides a framework for inter-chassis synchronization of 177 state and configuration data between a set of two or more PEs. 178 Currently ICCP only defines application specific messages for PW 179 redundancy and mLACP, but it can be easily extended to support Type B 180 PON as an Attachment Circuit (AC) redundancy. 182 This document proposes the extension of ICCP to support Multi-chassis 183 PON protection in MPLS. 185 3.1. Multi-chassis PON Application TLVs 187 A set of multi-chassis PON application TLVs are defined in the 188 following sub-sections. 190 3.1.1. PON Connect TLV 192 This TLV is included in the RG Connect message to signal the 193 establishment of PON application connection. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |U|F| Type=0x00XX | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Protocol Version |A| Reserved | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Optional Sub-TLVs | 203 ~ ~ 204 | | 205 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | ... | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 - U and F Bits, both are set to 0. 210 - Type, set to 0x00XX for "PON Connect TLV". 212 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 213 Type, and Length fields. 215 - Protocol Version, the version of this PON specific protocol for the 216 purposes of inter-chassis communication. This is set to 0x0001. 218 - A Bit, Acknowledgement Bit. Set to 1 if the sender has received a 219 PON Connect TLV from the recipient. Otherwise, set to 0. 221 - Reserved, Reserved for future use. 223 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 224 version of the protocol. 226 3.1.2. PON Disconnect TLV 228 This TLV is included in the RG Disconnect message to indicate that 229 the connection for the PON application is to be terminated. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |U|F| Type=0x00XX | Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Optional Sub-TLVs | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 - U and F Bits, both are set to 0. 241 - Type, set to 0x00XX for "PON Disconnect TLV". 243 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 244 Type, and Length fields. 246 - Optional Sub-TLVs, there are no optional Sub-TLVs defined for this 247 version of the protocol. 249 3.1.3. PON Configuration TLV 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |U|F| Type=0x00XX | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | System ID | 257 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | System Priority | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Port ID | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 - U and F Bits, both are set to 0. 265 - Type, set to 0x00XX for "PON Configuration TLV". 267 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 268 Type, and Length fields. 270 - System ID, 6 octets encoding the System ID used by the OLT, which 271 is a MAC address. 273 - System Priority, 2 octets encoding the System Priority. 275 - Port ID, 2 octets PON Port ID. 277 Further configuration considerations such as multicast table and ARP 278 table for static MAC addresses will be added in a next version. 280 3.1.4.PON State TLV 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |U|F| Type=0x00XX | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | ROID | 288 | | 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Local PON Port state | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Remote PON Port state | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 - U and F Bits, both are set to 0. 298 - Type, set to 0x00XX for "PON State TLV" 300 - Length, Length of the TLV in octets excluding the U-bit, F-bit, 301 Type, and Length fields. 303 - ROID, as defined in the ROID section of [ICCP]. 305 - Local PON Port State, the status of the local PON port as 306 determined by the sending OLT (PE). The last bit is defined as Fault 307 indication of the PON Port associated with this PW. 309 - Remote PON Port State, the status of the remote PON port as 310 determined by the remote peer of the sending OLT (PE). The last bit 311 is defined as Fault indication of the PON Port associated with this 312 PW. 314 4. Dual Homing protection procedures 316 Two typical MPLS protection network architectures for PON access are 317 depicted in Fig.2 and Fig.3 (PON access segment is the same as in 318 Fig.1 and thus omitted for simplification). OLTs with MPLS 319 functionality are connected to a single PE (Fig.2) or dual home PEs 320 (Fig.3) respectively, thus these devices constitute an MPLS network 321 which provides PW transport services between ONUs and a CE. 322 +-----+ 323 | | 324 | OLT -, 325 | | `., 326 +-----+ ', 327 `', 328 `., +-----+ +-----+ 329 ', | | | | 330 `. PE ------------ CE | 331 .'`| | | | 332 ,-` +-----+ +-----+ 333 .` 334 +-----+ .'` 335 | | ,-` 336 | OLT -` 337 | | 338 +-----+ 339 Figure 2 An MPLS network with a single PE 341 +-----+ +-----+ 342 | | | | 343 | OLT ----------------- PE -, 344 | | | | ', 345 +-----+ +--/--+ ', 346 | `. 347 | `. +-----+ 348 | `' | 349 | | CE | 350 | . | 351 | ,'+-----+ 352 | ,-` 353 +-----+ +--\--+ ,' 354 | | | | .` 355 | OLT ----------------- PE -` 356 | | | | 357 +-----+ +-----+ 358 Figure 3 An MPLS network with dual home PEs 360 Faults may be encountered in PON access, or in the MPLS network 361 (including the working OLT). Procedures for these cases are described 362 in this section (it is assumed that both OLTs and PEs are working in 363 independent mode of PW redundancy [RFC6870]). 365 4.1. Protection procedure upon PON interface failures 367 When a fault is detected on a working PON link, a working OLT MUST 368 turn off its associated PON interface and MUST send an LDP 369 notification message with a forward defect indication and with the 370 Request Switchover bit being set to its peer PE on the remote end of 371 the PW. At the same time, the working OLT MUST send an ICCP message 372 with PON State TLV to notify the backup OLT of the PON fault. 373 Upon receiving a PON state TLV where Local PON Port state is False, 374 an OLT in the protection mode MUST activate the protection PON link 375 in the protection group. 377 4.2. Protection procedure upon PW failures 379 Usually MPLS networks have its own protection mechanism such as LSP 380 protection or Fast Reroute (FRR). But in a link sparse access or 381 aggregation network where protection is impossible in LSP layer, the 382 following PW layer protection procedures can be enabled. 384 When a fault is detected on its working PW (e.g., by VCCV BFD), a 385 working OLT MUST turn off its associated PON interface and MUST send 386 an ICCP message with PON State TLV to notify the backup OLT of the 387 PON fault. 389 Upon receiving a PON state TLV where Local PON Port state is False, 390 the backup OLT MUST activate its optical interface to the backup 391 fiber. At the same time, the backup OLT MUST send a PW redundancy 392 message to the remote PE, so that traffic can be switched to the 393 backup PW. 395 4.3. Protection procedure upon the working OLT failure 397 If the backup OLT lost connection to the working OLT, it MUST 398 activate its optical interface to the back fiber and activate the 399 specific backup PW upon receiving a PW redundancy message from its 400 remote PE with the Request Switchover bit being set, so that traffic 401 can be reliably switched to the protection link and the backup PW. 403 5. Security Considerations 405 Security considerations as described in [ICCP] apply. 407 6. IANA Considerations 409 These values are requested from the registry of "ICC RG parameter 410 type": 411 0x00X0 PON Connect TLV 412 0x00X1 PON Disconnect TLV 413 0x00X2 PON Configuration TLV 414 0x00X3 PON State TLV 416 7. References 418 7.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997 423 [RFC6870] Muley, P., Aissaoui, M., "Pseudowire Preferential 424 Forwarding Status Bit", RFC 6870, February 2013 426 7.2. Informative References 428 [RFC6456] Li, H., Zheng, R., and Farrel, A., "Multi-Segment 429 Pseudowires in Passive Optical Networks", RFC 6456, 430 November 2011 432 [SEAMLESS] Leymann, N., and et al, "Seamless MPLS Architecture", 433 draft-ietf-mpls-seamless-mpls-04, Work in progress 435 [ICCP] Martini, L. and et al, "Inter-Chassis Communication Protocol 436 for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-11, Work in 437 progress 439 [G983.1] ITU-T, "Broadband optical access systems based on Passive 440 Optical Networks (PON)", ITU-T G.983.1, January, 2005 442 8. Acknowledgments 444 TBD. 446 Authors' Addresses 448 Yuanlong Jiang 449 Huawei Technologies Co., Ltd. 450 Bantian, Longgang district 451 Shenzhen 518129, China 452 Email: jiangyuanlong@huawei.com 454 Yong Luo 455 Huawei Technologies Co., Ltd. 456 Bantian, Longgang district 457 Shenzhen 518129, China 458 Email: dennis.luoyong@huawei.com