Pseudowire Emulation Edge to Edge H. Hao Internet-Draft Y. Ma Intended status: Standards Track ZTE Corporation Expires: January 12, 2013 W. Cheng China Mobile D. Cohn Orckit-Corrigent July 11, 2012 ICCP extension for the MSP application draft-hao-pwe3-iccp-extension-for-msp-03 Abstract This document specifies extensions to the Inter-Chassis Communication Protocol (ICCP) to support inter-chassis linear multiplex section protection (MSP) as described in G.841 and automatic protection switching as defined in ANSI T1.105.01. This document considers an application where a CE device or access network is attached to two PEs through Synchronous Digital Hierarchy (SDH) circuits, and MSP or APS is used to protect the attachment circuits. ICCP is used to support configuration and state synchronization between two chassis. CE device or access network attached to more than two PEs is out of the scope of this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Hao, et al. Expires January 12, 2013 [Page 1] Internet-Draft ICCP extension for the MSP application July 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ICCP extension requirements . . . . . . . . . . . . . . . . . 5 3.1. Multi-chassis MSP Protection Model . . . . . . . . . . . . 5 3.2. ICCP aspects . . . . . . . . . . . . . . . . . . . . . . . 6 4. ICCP TLV extensions for MSP . . . . . . . . . . . . . . . . . 6 4.1. MSP connect TLV . . . . . . . . . . . . . . . . . . . . . 6 4.2. MSP disconnect TLV . . . . . . . . . . . . . . . . . . . . 7 4.2.1. MSP disconnect cause TLV . . . . . . . . . . . . . . . 8 4.3. MSP group config TLV . . . . . . . . . . . . . . . . . . . 8 4.4. MSP port config TLV . . . . . . . . . . . . . . . . . . . 10 4.5. MSP section state TLV . . . . . . . . . . . . . . . . . . 11 4.6. MSP switch command TLV . . . . . . . . . . . . . . . . . . 12 4.7. MSP group state TLV . . . . . . . . . . . . . . . . . . . 13 4.8. MSP Synchronization Request TLV . . . . . . . . . . . . . 14 4.9. MSP Synchronization Data TLV . . . . . . . . . . . . . . . 15 5. PE Node Failure . . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Hao, et al. Expires January 12, 2013 [Page 2] Internet-Draft ICCP extension for the MSP application July 2012 1. Introduction [I-D:ietf-pwe3-iccp] has specified an inter-chassis communication protocol that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group (RG), for the purpose of synchronizing data amongst the systems. In the ICCP draft, it specifies the ICCP TLVs for the Pseudowire Redundancy application and the multi-chassis LACP(mLACP) application. This document extends the ICCP TLVs for SDH attachment circuit redundancy using inter-chassis linear multiplex section protection (MSP) application. The application also supports SONET attachment circuits using automatic protection switching (APS). Unless otherwise stated, all requirements in this document are also applicable to SONET/APS, and all references to MSP equally apply to APS. Inter-chassis linear multiplex section protection (MSP) application also adopts the topology described in Figure 1 of [I-D:ietf-pwe3- iccp]. In other words, the redundancy mechanism employed towards the access node/network is inter-chassis linear MSP which is commonly used in mobile backhaul networks. Packet transport technology is widely used in mobile backhaul networks, with either Ethernet or SDH as attachment circuit technology. In packet transport mobile backhaul networks, 3G access nodes that typically connect to the network using Ethernet interfaces coexist with 2G access nodes that typically connect to the network using SDH interfaces. In Figure 1, the attachment circuit can be Ethernet or SDH. Ethernet access interfaces are typically protected using LAG, while SDH access interfaces are typically protected using MSP. Linear MSP is a protection mechanism which protects the multiplex section layer. There are different implementations that extend this mechanism to support SDH sections that are terminated in different chassis. This document proposes using a new ICCP application to synchronize state and configuration data between two chassis to support multi-chassis MSP in the scenario shown in figure 1. Hao, et al. Expires January 12, 2013 [Page 3] Internet-Draft ICCP extension for the MSP application July 2012 Mutli-homed +----+ +----+ +----+ Node ------------> | CE |-------| PE1|............| PEn| | |--+ -| | | | +----+ | / +----+ +----+ | / | | |/ | Packet | +-------------+ / | Network | | | /| | | | Access |/ | | | | Network | | +----+ +----+ | | +----| PE2|............| PE3| | |-------| | | | +-------------+ ^ +----+ +----+ ^ | | Ethernet or SDH | Multi-homed Network Figure 1: Attachment circuit multi-homed to Packet Network 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology o AC: Attachment Circuit o AN: Access Network o CE: Customer Edge o ICCP:Inter-Chassis Communication Protocol o LACP: Link Aggregation Control Protocol o MSP: Multiplex Section Protection o PW: Pseudowire o RG: redundancy group o SDH: Synchronous Digital Hierarchy Hao, et al. Expires January 12, 2013 [Page 4] Internet-Draft ICCP extension for the MSP application July 2012 3. ICCP extension requirements 3.1. Multi-chassis MSP Protection Model +-------+ +----+ | | |PE1 | | |-------------------| | | CE | ^ +----+ | | | | | or | | ICCP | | Inter-chassis MSP | | AN | | | | | +----+ | | v |PE2 | | |-------------------| | +-------+ +----+ Figure 2: Generic Multi-chassis MSP Protection Model Figure 2 describes the model where inter-chassis MSP is used as the AC redundancy mechanism. The SDH sections between CE/AN and PE1/PE2 form an inter-chassis protection group where one acts as the working section and the other as a protection section. The PE that terminates the protection section SHALL process the MSP requests and calculate the bridge and selector states and the K1/K2 byte values to be transmitted, following MSP logic as specified in [G.841]. Whenever the output of the MSP logic changes, and when the MSP application initializes, the PE that terminates the protection section SHALL send the MSP group state to the other PE. Each PE shall use the MSP group state to decide whether the PE is active or standby from an ICCP perspective. For example, when the section between CE/AN and PE1 fails, the MSP group state at PE1 will change and PE1 will send a state update to PE2. After receiving and processing the information, the MSP group state at PE2 will change (assuming no other MSP requests exist) and PE2 will send an MSP group state update to PE1. As a result of this, PE2 will become the active PE and will act according to the procedures set out in [I-D.ietf-pwe3-iccp]. The same will occur as a result of external commands being applied to any of the PEs. The ICCP application described in this document is responsible for Hao, et al. Expires January 12, 2013 [Page 5] Internet-Draft ICCP extension for the MSP application July 2012 the state synchronization between different chassis forming a RG. 3.2. ICCP aspects ICCP is specified in the [I-D:ietf-pwe3-iccp]. It allows synchronization of state and configuration data between a set of two or more PEs forming a RG. ICCP provides reliable message transport and in-order delivery between nodes in a RG with secure authentication mechanisms built into the protocol. Furthermore, it provides a common set of procedures by which applications on one PE can connect to their counterparts on another PE, for purpose of inter-chassis communication in the context of a given RG. The prerequisite for establishing an application connection is to have an operational ICCP RG connection between the two endpoints. When an application has information to transfer over ICCP, it triggers the transmission of an Application Data message. Currently, the ICCP draft has specified the ICCP's TLVs for the Pseudowire Redundancy application and the multi-chassis LACP (mLACP) application. This draft extends ICCP TLVs to support MSP as an AC redundancy mechanism. 4. ICCP TLV extensions for MSP The following sections specify the format of MSP application TLVs. 4.1. MSP connect TLV This TLV is included in the RG Connect message to signal the establishment of MSP application connection. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E00 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Sub-TLVs | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 3: MSP connect TLV Hao, et al. Expires January 12, 2013 [Page 6] Internet-Draft ICCP extension for the MSP application July 2012 - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E00 for "MSP connect TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - Protocol Version The version of this particular protocol for the purposes of ICCP. This is set to 0x0001. - A Bit Acknowledgement Bit. Set to 1 if the sender has received a MSP Connect TLV from the recipient. Otherwise, set to 0. - Reserved Reserved for future use. - Optional Sub-TLVs There are no optional Sub-TLVs defined for this version of the Protocol. 4.2. MSP disconnect TLV This TLV is used in an RG Disconnect Message to indicate that the connection for the MSP application is to be terminated. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E01 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: MSP disconnect TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E01 for "MSP disconnect TLV" Hao, et al. Expires January 12, 2013 [Page 7] Internet-Draft ICCP extension for the MSP application July 2012 - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - Optional Sub-TLVs There are no optional Sub-TLVs defined for this version of the Protocol. 4.2.1. MSP disconnect cause TLV This TLV is used in an RG Disconnect Message to indicate the cause of disconnect message. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E09 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Cause String | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: MSP disconnect TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E09 for "MSP disconnect cause TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - Disconnect Cause String Variable length string specifying the reason for the disconnect message. Used for network management. 4.3. MSP group config TLV The MSP configuration TLV is sent in the RG application data message. This TLV is used to notify RG peers about the local configuration of protect group. Hao, et al. Expires January 12, 2013 [Page 8] Internet-Draft ICCP extension for the MSP application July 2012 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E02 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ROID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protect Type | Direction | Protect Mode | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTR Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: MSP group config TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E02 for "MSP group config TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - ROID Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely identifies the Redundant Object. - Protect Type One octet encoding the protect type of the MSP protect group as follows: 0x00 1+1 0x01 1:1 0x02-0xFF reserved - Direction One octet encoding the architecture of the network as follows: 0x00 unidirectional 0x01 bidirectional - Reversion Mode One octet encoding the mode of operation as follows: 0x00 non-revertive operation 0x01 revertive operation Hao, et al. Expires January 12, 2013 [Page 9] Internet-Draft ICCP extension for the MSP application July 2012 - Flags One octet. Valid values are: -i Synchronized (0x01) Indicates that the sender has concluded transmitting all group configuration information. -ii Purge Configuration (0x02) Indicates that the group is no longer configured for MSP operation. - WTR Time Four octets. The time of waiting to restore, is used in the revertive mode of operation. 4.4. MSP port config TLV The MSP port configuration TLV is sent in the RG application data message. This TLV is used to notify RG peers about the local port configuration. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E03 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ROID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Role | Flags | Port Name Len | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Name | + + ~ ~ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: MSP port config TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E03 for "MSP group config TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. Hao, et al. Expires January 12, 2013 [Page 10] Internet-Draft ICCP extension for the MSP application July 2012 - ROID Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely identifies the Redundant Object. - Role One octet encoding the role of the section as follows: 0x00 working 0x01 protection - Flags One octet. Valid values are: -i Synchronized (0x01) Indicates that the sender has concluded transmitting all group configuration information. -ii Purge Configuration (0x02) Indicates that the group is no longer configured for MSP operation. - Port Name Len One octet, length of the "Port Name" field in octets. - Port Name Port name encoded in UTF-8 format, up to a maximum of 32 characters. 4.5. MSP section state TLV The MSP section state TLV is sent in the RG application data message. This TLV announces the local section state to the RG peers. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E04 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Section State | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: MSP section state TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E04 for "MSP section state TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length Hao, et al. Expires January 12, 2013 [Page 11] Internet-Draft ICCP extension for the MSP application July 2012 fields. - Section State One octet encoding the section state as follows: 0x00 the signal is ok 0x01 Signal fail high priority 0x02 Signal fail low priority 0x03 Signal degrade high priority 0x04 Signal degrade low priority 4.6. MSP switch command TLV The MSP configuration TLV is sent in the RG application data message. This TLV is used to notify RG peers about the local configuration of protect group. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E05 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Cmd | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: MSP switch command TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E05 for "MSP switch command TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - Request Cmd One octet.The switch command issued at the MSP APS controller interface. The following are the possible values, in order of priority from highest to lowest: (1111) Clear (1101) Lockout of protection(LP) (1011) Forced Switch working-to-protection (1001) Forced Switch protection-to-working (0111) Manual switch working-to-protection (0101) Manual switch protection-to-working (0100) Exercise Hao, et al. Expires January 12, 2013 [Page 12] Internet-Draft ICCP extension for the MSP application July 2012 4.7. MSP group state TLV The MSP group state TLV is sent in the RG application data message. This TLV is used by the PE terminating the protection section to report the state of the MSP group to the other PE in the same RG. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E06 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group State | Path | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: MSP group state TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E06 for "MSP group state TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - Group State One octet encoding the current state of the MSP protect group as follows: 0x00 No request 0x01 Do not revert 0x02 Reverse request 0x03 Unused 0x04 Exercise 0x05 Unused 0x06 Wait-to restore 0x07 Unused 0x08 Manual switch 0x09 Unused 0x0A Signal degrade low priority 0x0B Signal degrade high priority 0x0C Signal fail low priority 0x0D Signal fail high priority 0x0E Forced switch 0x0F Lockout of protection Hao, et al. Expires January 12, 2013 [Page 13] Internet-Draft ICCP extension for the MSP application July 2012 - Path One octet encoding the active path of the MSP protect group as follows: 0x00 the active path is the working section 0x01 the active path is the protection section 4.8. MSP Synchronization Request TLV The MSP synchronization request TLV is used in the RG application data message. This TLV is used by a device to request from its peer to re-transmit configuration or operational state. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E07 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Number |C|S| Request Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: MSP Synchronization Request TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E07 for "MSP Synchronization Request TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - Request Number Two octets. Unsigned integer uniquely identifying the request. Be used to match the request with a response. The value of 0 is reserved for unsolicited synchronization, and MUST NOT be used in the MSP synchronization request TLV. - C Bit Set to 1 if request is for configuration data. Otherwise, set to 0. - S Bit Set to 1 if request is for running state data. Otherwise, set to 0. - Request Type 14-bits specifying the request type, encoded as follows: Hao, et al. Expires January 12, 2013 [Page 14] Internet-Draft ICCP extension for the MSP application July 2012 0x00 Request Data for specified protect group 0x01 Request Data for all groups in specified service(s) 4.9. MSP Synchronization Data TLV The purpose of MSP Synchronization Data TLV is similar to the PW-RED Synchronization Data TLV defined in the [I-D:ietf-pwe3-iccp].It is used in the RG Application Data message. A pair of these TLVs is used by a device to delimit a set of TLVs that are sent in response to a MSP Synchronization Request TLV. The delimiting TLVs signal the start and end of the synchronization data, and associate the response with its corresponding request via the Request Number field. The MSP Synchronization Data TLVs are also used for unsolicited advertisements of complete MSP configuration and operational state data. In this case, the Request Number field MUST be set to 0. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x3E08 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Number | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: MSP group notify TLV - U and F Bits Both are set to 0. - Type Set temporarily to 0x3E08 for "MSP Synchronization Data TLV" - Length Length of the TLV in octets excluding the U-bit,F-bit,Type,and Length fields. - Request Number Two octets. Unsigned integer is identifying the Request Number from the "MSP Synchronization Request TLV" which solicited this synchronization data response. - Flags Two octets, response flags encoded as follows: 0x00 Synchronization Data Start 0x01 Synchronization Data End Hao, et al. Expires January 12, 2013 [Page 15] Internet-Draft ICCP extension for the MSP application July 2012 5. PE Node Failure Section 9.2.3 of [I-D.ietf-pwe3-iccp] specifies the behavior in the event of PE node failure. Additionally, a signal fail request for the working section (SF-W) over the K1 byte will be received by the PE node which terminates the protection section and then it will follow normal MSP procedure for this condition. 6. Security Considerations The extensions of this document are based on ICCP and only some TLVs are added which will not change the security of existing network. 7. IANA Consideration TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [G.841] ITU-T Recommendation G.841, "Types and characteristics of SDH network protection architectures", 1998. [I-D.ietf-pwe3-iccp] Luca Martini,Samer Salam,Ali Sajassi, "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-07 . Authors' Addresses Hongjie Hao ZTE Corporation Email: hao.hongjie@zte.com.cn Hao, et al. Expires January 12, 2013 [Page 16] Internet-Draft ICCP extension for the MSP application July 2012 Yuxia Ma ZTE Corporation Email: ma.yuxia@zte.com.cn Weiqiang Cheng China Mobile Email: chengweiqiang@cmcc.com.cn Daniel Cohn Orckit-Corrigent Email: daniel.cohn.ietf@gmail.com Wanming Cao ZTE Corporation Email: cao.wanming@zte.com.cn Jinghai Yu ZTE Corporation Email: yu.jinghai@zte.com.cn Hao, et al. Expires January 12, 2013 [Page 17]