idnits 2.17.1 draft-hao-pwe3-iccp-extension-for-msp-04.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 (October 22, 2012) is 4196 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: 'I-D:ietf-pwe3-iccp' is mentioned on line 642, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-iccp-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Pseudowire Emulation Edge to Edge H. Hao 3 Internet-Draft Y. Ma 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 25, 2013 W. Cheng 6 China Mobile 7 D. Cohn 9 M. Daikoku 10 KDDI Corporation 11 October 22, 2012 13 ICCP extension for the MSP application 14 draft-hao-pwe3-iccp-extension-for-msp-04 16 Abstract 18 This document specifies extensions to the Inter-Chassis Communication 19 Protocol (ICCP) to support inter-chassis linear multiplex section 20 protection (MSP) as described in G.841 and automatic protection 21 switching as defined in ANSI T1.105.01. This document considers an 22 application where a CE device or access network is attached to two 23 PEs through Synchronous Digital Hierarchy (SDH) circuits, and MSP or 24 APS is used to protect the attachment circuits. ICCP is used to 25 support configuration and state synchronization between two chassis. 26 CE device or access network attached to more than two PEs is out of 27 the scope of this document. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions used in this document . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. ICCP extension requirements . . . . . . . . . . . . . . . . . 5 67 3.1. Multi-chassis MSP Protection Model . . . . . . . . . . . . 5 68 3.2. ICCP aspects . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. ICCP TLV extensions for MSP . . . . . . . . . . . . . . . . . 6 70 4.1. MSP connect TLV . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. MSP disconnect TLV . . . . . . . . . . . . . . . . . . . . 7 72 4.2.1. MSP disconnect cause TLV . . . . . . . . . . . . . . . 8 73 4.3. MSP group config TLV . . . . . . . . . . . . . . . . . . . 8 74 4.4. MSP port config TLV . . . . . . . . . . . . . . . . . . . 10 75 4.5. MSP section state TLV . . . . . . . . . . . . . . . . . . 11 76 4.6. MSP switch command TLV . . . . . . . . . . . . . . . . . . 12 77 4.7. MSP group state TLV . . . . . . . . . . . . . . . . . . . 13 78 4.8. MSP Synchronization Request TLV . . . . . . . . . . . . . 14 79 4.9. MSP Synchronization Data TLV . . . . . . . . . . . . . . . 15 80 5. PE Node Failure . . . . . . . . . . . . . . . . . . . . . . . 16 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 [I-D:ietf-pwe3-iccp] has specified an inter-chassis communication 91 protocol that enables Provider Edge (PE) device redundancy for 92 Virtual Private Wire Service (VPWS) and Virtual Private LAN Service 93 (VPLS) applications. The protocol runs within a set of two or more 94 PEs, forming a redundancy group (RG), for the purpose of 95 synchronizing data amongst the systems. In the ICCP draft, it 96 specifies the ICCP TLVs for the Pseudowire Redundancy application and 97 the multi-chassis LACP(mLACP) application. This document extends the 98 ICCP TLVs for SDH attachment circuit redundancy using inter-chassis 99 linear multiplex section protection (MSP) application. The 100 application also supports SONET attachment circuits using automatic 101 protection switching (APS). Unless otherwise stated, all 102 requirements in this document are also applicable to SONET/APS, and 103 all references to MSP equally apply to APS. 105 Inter-chassis linear multiplex section protection (MSP) application 106 also adopts the topology described in Figure 1 of [I-D:ietf-pwe3- 107 iccp]. In other words, the redundancy mechanism employed towards the 108 access node/network is inter-chassis linear MSP which is commonly 109 used in mobile backhaul networks. Packet transport technology is 110 widely used in mobile backhaul networks, with either Ethernet or SDH 111 as attachment circuit technology. 113 In packet transport mobile backhaul networks, 3G access nodes that 114 typically connect to the network using Ethernet interfaces coexist 115 with 2G access nodes that typically connect to the network using SDH 116 interfaces. In Figure 1, the attachment circuit can be Ethernet or 117 SDH. Ethernet access interfaces are typically protected using LAG, 118 while SDH access interfaces are typically protected using MSP. 120 Linear MSP is a protection mechanism which protects the multiplex 121 section layer. There are different implementations that extend this 122 mechanism to support SDH sections that are terminated in different 123 chassis. This document proposes using a new ICCP application to 124 synchronize state and configuration data between two chassis to 125 support multi-chassis MSP in the scenario shown in figure 1. 127 Mutli-homed +----+ +----+ +----+ 128 Node ------------> | CE |-------| PE1|............| PEn| 129 | |--+ -| | | | 130 +----+ | / +----+ +----+ 131 | / | | 132 |/ | Packet | 133 +-------------+ / | Network | 134 | | /| | | 135 | Access |/ | | | 136 | Network | | +----+ +----+ 137 | | +----| PE2|............| PE3| 138 | |-------| | | | 139 +-------------+ ^ +----+ +----+ 140 ^ | 141 | Ethernet or SDH 142 | 143 Multi-homed Network 145 Figure 1: Attachment circuit multi-homed to Packet Network 147 1.1. Conventions used in this document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 2. Terminology 155 o AC: Attachment Circuit 157 o AN: Access Network 159 o CE: Customer Edge 161 o ICCP:Inter-Chassis Communication Protocol 163 o LACP: Link Aggregation Control Protocol 165 o MSP: Multiplex Section Protection 167 o PW: Pseudowire 169 o RG: redundancy group 171 o SDH: Synchronous Digital Hierarchy 173 3. ICCP extension requirements 175 3.1. Multi-chassis MSP Protection Model 177 +-------+ +----+ 178 | | |PE1 | 179 | |-------------------| | 180 | CE | ^ +----+ 181 | | | | 182 | or | | ICCP 183 | | Inter-chassis MSP | 184 | AN | | 185 | | | +----+ 186 | | v |PE2 | 187 | |-------------------| | 188 +-------+ +----+ 190 Figure 2: Generic Multi-chassis MSP Protection Model 192 Figure 2 describes the model where inter-chassis MSP is used as the 193 AC redundancy mechanism. The SDH sections between CE/AN and PE1/PE2 194 form an inter-chassis protection group where one acts as the working 195 section and the other as a protection section. 197 The PE that terminates the protection section SHALL process the MSP 198 requests and calculate the bridge and selector states and the K1/K2 199 byte values to be transmitted, following MSP logic as specified in 200 [G.841]. 202 Whenever the output of the MSP logic changes, and when the MSP 203 application initializes, the PE that terminates the protection 204 section SHALL send the MSP group state to the other PE. 206 Each PE shall use the MSP group state to decide whether the PE is 207 active or standby from an ICCP perspective. 209 For example, when the section between CE/AN and PE1 fails, the MSP 210 group state at PE1 will change and PE1 will send a state update to 211 PE2. After receiving and processing the information, the MSP group 212 state at PE2 will change (assuming no other MSP requests exist) and 213 PE2 will send an MSP group state update to PE1. As a result of this, 214 PE2 will become the active PE and will act according to the 215 procedures set out in [I-D.ietf-pwe3-iccp]. 217 The same will occur as a result of external commands being applied to 218 any of the PEs. 220 The ICCP application described in this document is responsible for 221 the state synchronization between different chassis forming a RG. 223 3.2. ICCP aspects 225 ICCP is specified in the [I-D:ietf-pwe3-iccp]. It allows 226 synchronization of state and configuration data between a set of two 227 or more PEs forming a RG. ICCP provides reliable message transport 228 and in-order delivery between nodes in a RG with secure 229 authentication mechanisms built into the protocol. Furthermore, it 230 provides a common set of procedures by which applications on one PE 231 can connect to their counterparts on another PE, for purpose of 232 inter-chassis communication in the context of a given RG. The 233 prerequisite for establishing an application connection is to have an 234 operational ICCP RG connection between the two endpoints. When an 235 application has information to transfer over ICCP, it triggers the 236 transmission of an Application Data message. Currently, the ICCP 237 draft has specified the ICCP's TLVs for the Pseudowire Redundancy 238 application and the multi-chassis LACP (mLACP) application. 240 This draft extends ICCP TLVs to support MSP as an AC redundancy 241 mechanism. 243 4. ICCP TLV extensions for MSP 245 The following sections specify the format of MSP application TLVs. 247 4.1. MSP connect TLV 249 This TLV is included in the RG Connect message to signal the 250 establishment of MSP application connection. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |U|F| Type=0x3E00 | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Protocol Version |A| Reserved | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Optional Sub-TLVs | 260 ~ ~ 261 | | 262 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | ... ... | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 266 Figure 3: MSP connect TLV 268 - U and F Bits 269 Both are set to 0. 271 - Type 272 Set temporarily to 0x3E00 for "MSP connect TLV" 274 - Length 275 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 276 fields. 278 - Protocol Version 279 The version of this particular protocol for the purposes of ICCP. 280 This is set to 0x0001. 282 - A Bit 283 Acknowledgement Bit. Set to 1 if the sender has received a MSP 284 Connect TLV from the recipient. Otherwise, set to 0. 286 - Reserved 287 Reserved for future use. 289 - Optional Sub-TLVs 290 There are no optional Sub-TLVs defined for this version of the 291 Protocol. 293 4.2. MSP disconnect TLV 295 This TLV is used in an RG Disconnect Message to indicate that the 296 connection for the MSP application is to be terminated. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |U|F| Type=0x3E01 | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Optional Sub-TLVs | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 4: MSP disconnect TLV 308 - U and F Bits 309 Both are set to 0. 311 - Type 312 Set temporarily to 0x3E01 for "MSP disconnect TLV" 313 - Length 314 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 315 fields. 317 - Optional Sub-TLVs 318 There are no optional Sub-TLVs defined for this version of the 319 Protocol. 321 4.2.1. MSP disconnect cause TLV 323 This TLV is used in an RG Disconnect Message to indicate the cause of 324 disconnect message. 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=0x3E09 | Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Disconnect Cause String | 332 ~ ~ 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 5: MSP disconnect TLV 337 - U and F Bits 338 Both are set to 0. 340 - Type 341 Set temporarily to 0x3E09 for "MSP disconnect cause TLV" 343 - Length 344 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 345 fields. 347 - Disconnect Cause String 348 Variable length string specifying the reason for the disconnect 349 message. Used for network management. 351 4.3. MSP group config TLV 353 The MSP configuration TLV is sent in the RG application data message. 354 This TLV is used to notify RG peers about the local configuration of 355 protect group. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |U|F| Type=0x3E02 | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 + ROID + 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Protect Type | Direction | Protect Mode | Flags | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | WTR Time | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 6: MSP group config TLV 373 - U and F Bits 374 Both are set to 0. 376 - Type 377 Set temporarily to 0x3E02 for "MSP group config TLV" 379 - Length 380 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 381 fields. 383 - ROID 384 Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely identifies 385 the Redundant Object. 387 - Protect Type 388 One octet encoding the protect type of the MSP protect group as 389 follows: 390 0x00 1+1 391 0x01 1:1 392 0x02-0xFF reserved 394 - Direction 395 One octet encoding the architecture of the network as follows: 396 0x00 unidirectional 397 0x01 bidirectional 399 - Reversion Mode 400 One octet encoding the mode of operation as follows: 401 0x00 non-revertive operation 402 0x01 revertive operation 403 - Flags 404 One octet. Valid values are: 405 -i Synchronized (0x01) 406 Indicates that the sender has concluded transmitting all group 407 configuration information. 408 -ii Purge Configuration (0x02) 409 Indicates that the group is no longer configured for MSP operation. 411 - WTR Time 412 Four octets. The time of waiting to restore, is used in the 413 revertive mode of operation. 415 4.4. MSP port config TLV 417 The MSP port configuration TLV is sent in the RG application data 418 message. This TLV is used to notify RG peers about the local port 419 configuration. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |U|F| Type=0x3E03 | Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 + ROID + 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Role | Flags | Port Name Len | Flags | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Port Name | 433 + + 434 ~ ~ 435 | ... | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 7: MSP port config TLV 440 - U and F Bits 441 Both are set to 0. 443 - Type 444 Set temporarily to 0x3E03 for "MSP group config TLV" 446 - Length 447 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 448 fields. 450 - ROID 451 Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely identifies 452 the Redundant Object. 454 - Role 455 One octet encoding the role of the section as follows: 456 0x00 working 457 0x01 protection 459 - Flags 460 One octet. Valid values are: 461 -i Synchronized (0x01) 462 Indicates that the sender has concluded transmitting all group 463 configuration information. 464 -ii Purge Configuration (0x02) 465 Indicates that the group is no longer configured for MSP operation. 467 - Port Name Len 468 One octet, length of the "Port Name" field in octets. 470 - Port Name 471 Port name encoded in UTF-8 format, up to a maximum of 32 characters. 473 4.5. MSP section state TLV 475 The MSP section state TLV is sent in the RG application data message. 476 This TLV announces the local section state to the RG peers. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |U|F| Type=0x3E04 | Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Section State | | | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 8: MSP section state TLV 488 - U and F Bits 489 Both are set to 0. 491 - Type 492 Set temporarily to 0x3E04 for "MSP section state TLV" 494 - Length 495 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 496 fields. 498 - Section State 499 One octet encoding the section state as follows: 500 0x00 the signal is ok 501 0x01 Signal fail high priority 502 0x02 Signal fail low priority 503 0x03 Signal degrade high priority 504 0x04 Signal degrade low priority 506 4.6. MSP switch command TLV 508 The MSP configuration TLV is sent in the RG application data message. 509 This TLV is used to notify RG peers about the local configuration of 510 protect group. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |U|F| Type=0x3E05 | Length | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Request Cmd | | | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 9: MSP switch command TLV 522 - U and F Bits 523 Both are set to 0. 525 - Type 526 Set temporarily to 0x3E05 for "MSP switch command TLV" 528 - Length 529 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 530 fields. 532 - Request Cmd 533 One octet.The switch command issued at the MSP APS controller 534 interface. The following are the possible values, in order of 535 priority from highest to lowest: 536 (1111) Clear 537 (1101) Lockout of protection(LP) 538 (1011) Forced Switch working-to-protection 539 (1001) Forced Switch protection-to-working 540 (0111) Manual switch working-to-protection 541 (0101) Manual switch protection-to-working 542 (0100) Exercise 544 4.7. MSP group state TLV 546 The MSP group state TLV is sent in the RG application data message. 547 This TLV is used by the PE terminating the protection section to 548 report the state of the MSP group to the other PE in the same RG. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |U|F| Type=0x3E06 | Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Group State | Path | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 10: MSP group state TLV 560 - U and F Bits 561 Both are set to 0. 563 - Type 564 Set temporarily to 0x3E06 for "MSP group state TLV" 566 - Length 567 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 568 fields. 570 - Group State 571 One octet encoding the current state of the MSP protect group as 572 follows: 573 0x00 No request 574 0x01 Do not revert 575 0x02 Reverse request 576 0x03 Unused 577 0x04 Exercise 578 0x05 Unused 579 0x06 Wait-to restore 580 0x07 Unused 581 0x08 Manual switch 582 0x09 Unused 583 0x0A Signal degrade low priority 584 0x0B Signal degrade high priority 585 0x0C Signal fail low priority 586 0x0D Signal fail high priority 587 0x0E Forced switch 588 0x0F Lockout of protection 589 - Path 590 One octet encoding the active path of the MSP protect group as 591 follows: 592 0x00 the active path is the working section 593 0x01 the active path is the protection section 595 4.8. MSP Synchronization Request TLV 597 The MSP synchronization request TLV is used in the RG application 598 data message. This TLV is used by a device to request from its peer 599 to re-transmit configuration or operational state. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 |U|F| Type=0x3E07 | Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Request Number |C|S| Request Type | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Figure 11: MSP Synchronization Request TLV 611 - U and F Bits 612 Both are set to 0. 614 - Type 615 Set temporarily to 0x3E07 for "MSP Synchronization Request TLV" 617 - Length 618 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 619 fields. 621 - Request Number 622 Two octets. Unsigned integer uniquely identifying the request. Be 623 used to match the request with a response. The value of 0 is 624 reserved for unsolicited synchronization, and MUST NOT be used in the 625 MSP synchronization request TLV. 627 - C Bit 628 Set to 1 if request is for configuration data. Otherwise, set to 0. 630 - S Bit 631 Set to 1 if request is for running state data. Otherwise, set to 0. 633 - Request Type 634 14-bits specifying the request type, encoded as follows: 636 0x00 Request Data for specified protect group 637 0x01 Request Data for all groups in specified service(s) 639 4.9. MSP Synchronization Data TLV 641 The purpose of MSP Synchronization Data TLV is similar to the PW-RED 642 Synchronization Data TLV defined in the [I-D:ietf-pwe3-iccp].It is 643 used in the RG Application Data message. A pair of these TLVs is 644 used by a device to delimit a set of TLVs that are sent in response 645 to a MSP Synchronization Request TLV. The delimiting TLVs signal the 646 start and end of the synchronization data, and associate the response 647 with its corresponding request via the Request Number field. 649 The MSP Synchronization Data TLVs are also used for unsolicited 650 advertisements of complete MSP configuration and operational state 651 data. In this case, the Request Number field MUST be set to 0. 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |U|F| Type=0x3E08 | Length | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Request Number | Flags | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Figure 12: MSP group notify TLV 663 - U and F Bits 664 Both are set to 0. 666 - Type 667 Set temporarily to 0x3E08 for "MSP Synchronization Data TLV" 669 - Length 670 Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length 671 fields. 673 - Request Number 674 Two octets. Unsigned integer is identifying the Request Number from 675 the "MSP Synchronization Request TLV" which solicited this 676 synchronization data response. 678 - Flags 679 Two octets, response flags encoded as follows: 680 0x00 Synchronization Data Start 681 0x01 Synchronization Data End 683 5. PE Node Failure 685 Section 9.2.3 of [I-D.ietf-pwe3-iccp] specifies the behavior in the 686 event of PE node failure. Additionally. if the PE node detecting the 687 remote PE failure is the one that terminates the protection section, 688 it SHOULD transmit a signal fail request for the working section 689 (SF-W) over the K1 byte and follow normal MSP procedure for this 690 condition. 692 6. Security Considerations 694 The extensions of this document are based on ICCP and only some TLVs 695 are added which will not change the security of existing network. 697 7. IANA Consideration 699 TBD. 701 8. References 703 8.1. Normative References 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, March 1997. 708 8.2. Informative References 710 [G.841] ITU-T Recommendation G.841, "Types and characteristics of 711 SDH network protection architectures", 1998. 713 [I-D.ietf-pwe3-iccp] 714 Luca Martini,Samer Salam,Ali Sajassi, "Inter-Chassis 715 Communication Protocol for L2VPN PE Redundancy", 716 draft-ietf-pwe3-iccp-07 . 718 Authors' Addresses 720 Hongjie Hao 721 ZTE Corporation 723 Email: hao.hongjie@zte.com.cn 724 Yuxia Ma 725 ZTE Corporation 727 Email: ma.yuxia@zte.com.cn 729 Weiqiang Cheng 730 China Mobile 732 Email: chengweiqiang@chinamobile.com 734 Daniel Cohn 736 Email: daniel.cohn.ietf@gmail.com 738 Masahiro Daikoku 739 KDDI Corporation 741 Email: ms-daikoku@kddi.com 743 Wanming Cao 744 ZTE Corporation 746 Email: cao.wanming@zte.com.cn 748 Jinghai Yu 749 ZTE Corporation 751 Email: yu.jinghai@zte.com.cn