ICCP extension for the MSP application
draft-hao-pwe3-iccp-extension-for-msp-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hongjie Hao , Wanming Cao , Yu jinghai | ||
| Last updated | 2011-11-14 (Latest revision 2011-05-11) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hao-pwe3-iccp-extension-for-msp-01
Pseudowire Emulation Edge to Edge H. Hao
Internet-Draft Y. Ma
Intended status: Standards Track W. Cao
Expires: May 15, 2012 J. Yu
ZTE Corporation
November 12, 2011
ICCP extension for the MSP application
draft-hao-pwe3-iccp-extension-for-msp-01
Abstract
This document presents some extensions on the Inter-Chassis
Communication Protocol(ICCP) to support the application of multiplex
section protection(MSP) that is described in the G.841. Linear
multiplex section protection(MSP) is used to protect the Synchronous
Digital Hierarchy (SDH) network. In the case of inter-chassis linear
MSP, it needs a mechanism to synchronize the state and configuration
data between the two chassis. The ICCP is appropriate for that.
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 May 15, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
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
Hao, et al. Expires May 15, 2012 [Page 1]
Internet-Draft ICCP extension for the MSP application November 2011
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 . . . . . . . . . . . . . . . . . 4
3.1. Multi-chassis MSP Protection Model . . . . . . . . . . . . 5
3.2. ICCP extension precondition . . . . . . . . . . . . . . . 5
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 link 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. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Hao, et al. Expires May 15, 2012 [Page 2]
Internet-Draft ICCP extension for the MSP application November 2011
1. Introduction
In the past, the SDH network was used very popular. With the
development of network, the network is transferring from SDH network
to Packet Transport/Switch network.The SDH network element is
replaced by packet transport/Switch network element, but the legacy
Service Router or Base Station Controller with SDH interface would be
reserved. Therefore, sometimes the SDH and Packet Transport/Switch
equipments are co-existed in the mobile backhaul network at the same
time, to achieve a smooth migration from SDH to Packet Transport/
Switch network that will be a long time. The figure 1 describes the
co-existed network.
The co-existed network needs a method to protect the SDH link.
Linear multiplex section protection switching is popular used in the
SDH network. It can be a dedicated or shared protection mechanism.
It protects the multiplex section layer, and applies to point-to-
point physical networks. One protection multiplex section can be
used to protect the normal traffic from a number(N) of working
multiplex sections. It can operate in a unidirectional or
bidirectional manner, and it can carry extra traffic on the
protection multiplex section in bidirectional operation. It is used
widely in the SDH networks.
MSP has been extended to support inter-chassis linear MSP. It means
that the MSP can be used for point-to-multipoint physical networks.
The two chassis form a inter-chassis protect group. They runs the
protocol to protect the work link and protect link as a chassis
running. So the state and configuration data need to be synchronized
between the two chassises.
As defined in the [I-D:ietf-pwe3-iccp], it specifies 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's TLVs for the Pseudowire Redundancy
application and the multi-chassis LACP(mLACP) application.
Hao, et al. Expires May 15, 2012 [Page 3]
Internet-Draft ICCP extension for the MSP application November 2011
+----+ +----+
/| PE |............| PE |\
SDH / +----+ +----+ \
/ | | \
+----+/ | packet | \+----+ +----+SDH+----+
| CE | |transport/switch| | PE |--|CSG |---| BS |
+----+\ | network | /+----+ +----+ +----+
\ | | /
SDH \ +----+ +----+ /
\| PE |............| PE |/
+----+ +----+
Figure 1: The Co-existed 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 BS:Base Station
o CSG:Cell Site Gateway
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
3. ICCP extension requirements
Hao, et al. Expires May 15, 2012 [Page 4]
Internet-Draft ICCP extension for the MSP application November 2011
3.1. Multi-chassis MSP Protection Model
+----+
<---Pseudowire--->|PE1 |
| |\
+----+ \
| \
| \+----+
| | CE |
| | |
| /+----+
| /
+----+ /
|PE2 |/
<---Pseudowire--->| |
+----+
Figure 2: Generic Multi-chassis MSP Protection Model
Figure 2 describes the co-existed network. It includes the SDH link
and PW. The SDH network is a point-to-multipoint physical
network.Figure 2 describes the multi-chassis MSP reference model.
The node PE1 and PE2 form an inter-chassis linear multiplex section
protection group A. The node CE established a multiplex section
protection group B. The links between PE1 and CE, PE2 and CE are SDH
links. The link PE1-CE is called work link and the link PE2-CE is
called protect link. When the node PE1 finds the link to CE is
failed, the node PE1 should transfer the state of link to the PE2 by
the synchronize link (PE1 to PE2) for running the protocol of MSP.
The node PE2 receives the link fault message, and then it will switch
services to the protect link and notify the result to the group B by
K value defined in G.841. After that, it send the result to the node
PE1 to synchronize the state of group A by the synchronize link.
When the node PE1 is configured the switch command,also transfer the
command to the PE2 by the synchronize link for running the protocol
of MSP. Therefore a mechanism is required to insure the
synchronization between the members of the protect group A.
3.2. ICCP extension precondition
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
Hao, et al. Expires May 15, 2012 [Page 5]
Internet-Draft ICCP extension for the MSP application November 2011
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.For the moment, the draft
has specified the ICCP's TLVs for the Pseudowire Redundancy
application and the multi-chassis LACP(mLACP) application.
The PEs in an RG offer multi-homed connectivity to either individual
devices or entire networks. The generic multi-chassis redundancy
model is depicted in the [I-D:ietf-pwe3-iccp]. When the access
network is SDH network, it is just the applied field of inter-chassis
linear MSP. But the ICCP draft does not specify ICCP's TLVs for the
MSP application.
As mentioned in the preceding part of this document, the ICCP is
appropriate for the inter-chassis linear MSP. The ICCP just need to
extend its TLVs for the MSP application. Then it will be achieved
the synchronization between the members of the protect group.
4. ICCP TLV extensions for MSP
The ICCP can achieve the synchronization of state and configuration
data between the members of the inter-chassis linear MSP group by
extending the TLVs.Now we will expatiate the detail of MSP
application TLV's format.
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 May 15, 2012 [Page 6]
Internet-Draft ICCP extension for the MSP application November 2011
- 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 May 15, 2012 [Page 7]
Internet-Draft ICCP extension for the MSP application November 2011
- 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.
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.
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 May 15, 2012 [Page 8]
Internet-Draft ICCP extension for the MSP application November 2011
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
identifying the protect group.
- 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
- Protect Mode
One octet encoding the mode of operation as follows:
0x00 non-revertive operation
0x01 revertive operation
Hao, et al. Expires May 15, 2012 [Page 9]
Internet-Draft ICCP extension for the MSP application November 2011
- 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 May 15, 2012 [Page 10]
Internet-Draft ICCP extension for the MSP application November 2011
- ROID
Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely
identifying the protect group.
- Role
One octet encoding the role of the node as follows:
0x00 master
0x01 backup
- 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 link state TLV
The MSP link state TLV is sent in the RG application data message.
This TLV announces the local node's link 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ROID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MSP link state TLV
- U and F Bits
Both are set to 0.
- Type
Hao, et al. Expires May 15, 2012 [Page 11]
Internet-Draft ICCP extension for the MSP application November 2011
Set temporarily to 0x3E04 for "MSP link state 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
identifying the protect group.
- Link State
One octet encoding the link state as follows:
0x00 the signal is ok
0x01 signal failure(SF)
0x02 signal degradation(SD)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ROID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
- ROID
Hao, et al. Expires May 15, 2012 [Page 12]
Internet-Draft ICCP extension for the MSP application November 2011
Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely
identifying the protect group.
- 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(FS)
(0111) Manual switch(MS)
(0100) Exercise
4.7. MSP group state TLV
The MSP group state TLV is sent in the RG application data message.
This TLV is used to report its state of protect group to the other
members in the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ROID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
- ROID
Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely
identifying the protect group.
Hao, et al. Expires May 15, 2012 [Page 13]
Internet-Draft ICCP extension for the MSP application November 2011
- 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
- Path
One octet encoding the active path of the MSP protect group as
follows:
0x00 the active path is the working link
0x01 the active path is the protection link
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ROID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: MSP Synchronization Request TLV
Hao, et al. Expires May 15, 2012 [Page 14]
Internet-Draft ICCP extension for the MSP application November 2011
- 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:
0x00 Request Data for specified protect group
0x01 Request Data for all groups in specified service(s)
- ROID
Defined in the [I-D:ietf-pwe3-iccp].Eight octets, uniquely
identifying the protect group. When Request Type field is set to
(0x00), this field encodes the group ID for the requested group.
When the Request Type field is set to (0x01), this field must be
empty.
4.9. MSP Synchronization Data TLV
The meaning of MSP Synchronization Data TLV is similar with 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.
Hao, et al. Expires May 15, 2012 [Page 15]
Internet-Draft ICCP extension for the MSP application November 2011
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
5. Security Considerations
The extensions of this document are based on ICCP, only some TLVs are
added which will not change the security of existing network.
6. IANA Consideration
TBD.
7. References
Hao, et al. Expires May 15, 2012 [Page 16]
Internet-Draft ICCP extension for the MSP application November 2011
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.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-05 .
Authors' Addresses
Hongjie Hao
ZTE Corporation
Building 2,No.50 Software Road,Yuhuatai District
Nanjing, Jiangsu 210012
P.R.China
Phone: +86-025-88014232
Email: hao.hongjie@zte.com.cn
URI: http://www.zte.com.cn/
Yuxia Ma
ZTE Corporation
ZTE Plaza,No.19 Huayuan Donglu Road,Haidian District
Beijing 100191
P.R.China
Phone: +86-010-89932478
Email: ma.yuxia@zte.com.cn
URI: http://www.zte.com.cn/
Hao, et al. Expires May 15, 2012 [Page 17]
Internet-Draft ICCP extension for the MSP application November 2011
Wanming Cao
ZTE Corporation
Building 2,No.50 Software Road,Yuhuatai District
Nanjing, Jiangsu 210012
P.R.China
Phone: +86-025-88014232
Email: cao.wanming@zte.com.cn
URI: http://www.zte.com.cn/
Jinghai Yu
ZTE Corporation
Building 2,No.50 Software Road,Yuhuatai District
Nanjing, Jiangsu 210012
P.R.China
Phone: +86-025-88014226
Email: yu.jinghai@zte.com.cn
URI: http://www.zte.com.cn/
Hao, et al. Expires May 15, 2012 [Page 18]