Internet DRAFT - draft-hao-pwe3-iccp-extension-for-msp
draft-hao-pwe3-iccp-extension-for-msp
Pseudowire Emulation Edge to Edge H. Hao
Internet-Draft Y. Ma
Intended status: Standards Track ZTE Corporation
Expires: April 25, 2013 W. Cheng
China Mobile
D. Cohn
M. Daikoku
KDDI Corporation
October 22, 2012
ICCP extension for the MSP application
draft-hao-pwe3-iccp-extension-for-msp-04
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 April 25, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Hao, et al. Expires April 25, 2013 [Page 1]
Internet-Draft ICCP extension for the MSP application October 2012
document authors. All rights reserved.
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 April 25, 2013 [Page 2]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 3]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 4]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 5]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 6]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 7]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 8]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 9]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 10]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 11]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 12]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 13]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 14]
Internet-Draft ICCP extension for the MSP application October 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 April 25, 2013 [Page 15]
Internet-Draft ICCP extension for the MSP application October 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. if the PE node detecting the
remote PE failure is the one that terminates the protection section,
it SHOULD transmit a signal fail request for the working section
(SF-W) over the K1 byte and 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 April 25, 2013 [Page 16]
Internet-Draft ICCP extension for the MSP application October 2012
Yuxia Ma
ZTE Corporation
Email: ma.yuxia@zte.com.cn
Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com
Daniel Cohn
Email: daniel.cohn.ietf@gmail.com
Masahiro Daikoku
KDDI Corporation
Email: ms-daikoku@kddi.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 April 25, 2013 [Page 17]
