Internet DRAFT - draft-kim-ccamp-accp-protocol
draft-kim-ccamp-accp-protocol
CCAMP Working Group Young Hwa Kim
Internet-Draft ETRI
Expires: April 14, 2006
October 15, 2005
Automatic Control Channel Protection Protocol for Resilience of
Control Channels
<draft-kim-ccamp-accp-protocol-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The configuration of control channels with a higher reliability would
be an important factor for the more stable provision of communication
environment in non-(G)MPLS and (G)MPLS networks. This document
specifies an automatic control channel protection (ACCP) protocol
that runs between a pair of nodes and is used to support the
resilience capability of control channels. The ACCP protocol is based
on the concept of common channel signaling in ITU-T and the current
Kim Expires April 14, 2006 [Page 1]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
control channel management function of LMP in IETF. This ACCP
protocol provides functions such as identification of direct and
indirect control channels, automatic and forced switchover of those
channels, and so on for the resilience of control channels.
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Overview of ACCP Protocol......................................4
4. Functions of ACCP Protocol.....................................5
4.1 Identification of PG-1 and PG-3 Control Channels..........5
4.2 Identification of Detour Control Channels.................6
4.3 Automatic Switchover......................................7
4.4 Forced Switchover.........................................8
4.5 Recovery from Failure.....................................8
4.6 Notification of Control Channel Unavailability............8
4.7 Inquiry of Switchover Attributes..........................9
4.8 Hello Initiation..........................................9
4.9 Notification of Protocol Errors...........................9
5. Finite State Machine of ACCP Protocol..........................9
6. Message Formats of ACCP Protocol..............................12
6.1 Config...................................................13
6.2 ConfigAck................................................13
6.3 ConfigNack...............................................14
6.4 DCConfig.................................................14
6.5 DCConfigAck..............................................14
6.6 DCConfigNack.............................................14
6.7 Hello....................................................15
6.8 Switchover...............................................15
6.9 SwitchoverAck............................................15
6.10 SwitchoverNack...........................................15
6.11 Notify...................................................15
6.12 SAInqry..................................................16
6.13 SAInqryAck...............................................16
6.14 SAInqryNack..............................................16
6.15 ProtError................................................16
7. Object Definitions of ACCP Protocol...........................16
7.1 CCID Class...............................................17
7.2 MESSAGE_ID Class.........................................17
7.3 NODE_ID Class............................................17
7.4 CONFIG Class.............................................18
7.5 HELLO Class..............................................18
7.6 CC_PROPERTY Class........................................18
7.7 SWITCHOVER_TYPE Class....................................19
7.8 SWITCHOVER_ATTR Class....................................19
Kim Expires April 14, 2006 [Page 2]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
7.9 ADDI_INFO_INDICATOR Class................................20
7.10 SEQUENCE_NUMBER Class....................................20
7.11 PROT_ERROR Class.........................................21
7.12 REJECT_CAUSE Class.......................................22
8. Security Considerations.......................................23
9. IANA Considerations...........................................23
10. References...................................................23
10.1 Normative References.....................................23
10.2 Informative References...................................23
Author's Addresses...............................................23
Intellectual Property Statement..................................24
1. Introduction
Control channels are responsible for carrying packets generated from
routing protocols, signaling protocols, LMP, and etc. The
configuration of control channels with a higher reliability would be
an important factor for the more stable provision of communication
environment in non-(G)MPLS and (G)MPLS networks.
As described in [CPR-REQTS], the control channels could be configured
as the dedicated use for the control or as the shared use with data
channels. Those channels could be created via direct and indirect
interfaces between physically adjacent nodes. Then, there might be a
possibility that the creation of control channels between physically
distant nodes could be made via this process.
The current mechanisms for supporting the resilience of control
channels include the MPLS 1+1 protection described in [ITU-G7712] and
an extension of the control channel management in LMP. This document
is a protocol specification, called automatic control channel
protection (ACCP) for the latter. As a part of the effort, the ACCP
protocol has applied the concept of common channel signaling to IP
networks, in which the signaling system has three types of signaling
modes, associated mode, quasi-associated mode, and non-associated
modes described in [ITU-G870].
In the eventual ACCP protocol, the distribution of control packet
types into more than one control channel SHOULD be possible because
of the physical restriction such as different transmission rates. The
switchover function of control channels SHOULD in advance know
control packet types that a control channel carries for this case. In
order to simplify this issue, it is assumed that only one control
channel carries all control packets in the current step.
2. Terminology
Kim Expires April 14, 2006 [Page 3]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [11] and indicate requirement levels
for compliant implementations.
3. Overview of ACCP Protocol
The ACCP protocol provides functions for supporting the resilience of
control channels as follows:
- Identification of PG-1 and PG-3 control channels;
- Identification of detour control channels;
- Automatic switchover;
- Recovery from failure;
- Notification of control channel unavailability;
- Inquiry of switchover attributes;
- Hello initiation; and
- Notification of protocol errors.
General rules applied in the ACCP protocol for supporting the
resilience of control channels are as follows:
1) In order to support the protection and switchover capability,
two or more control channels SHOULD be configured over direct or
indirect interfaces between adjacent nodes;
2) A system SHOULD designate a transmission media such as fast-
Ethernet, Synchronous Digital Hierarchy - Regenerator Section
(SDH-RS), Synchronous Digital Hierarchy - Multiplex Section
(SDH-MS), Gigabit Ethernet (GbE), and etc into a protection
group among PG-1 and PG-3 to use them as control channels;
3) The protection and switchover attributes about each control
channel managed in the system are include local control channel
identifier, remote control channel identifier, detour control
channel identifier, transmission media, control channel type,
protection group, adjacent node identifier, control channel
status, and etc;
4) The attributes shall be endured as long as there is no new full-
fledged configuration between adjacent nodes.
From the view-point of protocol, the ACCP protocol has several
features for supporting the resilience of control channels as
follows:
Kim Expires April 14, 2006 [Page 4]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
1) This protocol applies three PGs, the PG-1 in which control
channels are directly connected between adjacent nodes, the PG-2
in which control channels are indirectly connected between
adjacent nodes according to a predefined route, and the PG-3 in
which control channels are connected via an internal or external
IP network;
2) This protocol uses multicast scheme for a reliable switchover;
3) This protocol can seamlessly provide services of a control
network until direct and indirect control channels of 2L ('L'
means the number of directly-connected links between adjacent
nodes) suffer from failures if a PG-3 control channel is
additionally kept;
4) Control channels over a detour route between adjacent nodes do
not use additional control channels, but use the current ACC
between directly connected nodes;
5) The protocol could be applied for the in-fiber in-bend/out-of-
bend configuration as well as the out-of-fiber configuration in
non-(G)MPLS and (G)MPLS.
Attributes of each control channel for the purpose, which are managed
via internal and external operations in each node, are as follows:
- Local control channel identifier : internal
- Remote control channel identifier : external
- Detour control channel identifier : external
- Transmission media type : internal
- Control channel type : external (among "active" or "standby")
- Protection group : internal (among "PG-1" or "PG-3")
- Adjacent node identifier : external
- Control channel status : internal (among "down" or "up")
4. Functions of ACCP Protocol
4.1 Identification of PG-1 and PG-3 Control Channels
This function allows two adjacent nodes to configure the
communication environment of PG-1 and PG-3 control channels. Its
procedure to identify active and standby control channels differs
from the way how to connect physical links between nodes. That is, in
case of point-to-point connection, control channels are identified
using a multicast address, and in other cases, they are identified
using an unicast address.
Kim Expires April 14, 2006 [Page 5]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
The originating node sends Config messages and waits responses from
its peer over control channels without relation to the type of
control link (point-to-point or multiple-access). At this point, the
node SHOULD indicate its protocol capability about the DCC
configuration.
After receiving the Config message, the terminating node determines
the Active Control Channel (ACC), Standby Control Channel (SCC) and
protocol capability used between adjacent nodes, and replies to the
configuration request with a ConfigAck message including these
objects in case of a successful response to be sent. Then, there may
be a possibility that the terminating node can receive one or more
Config messages from the same originating node. Accordingly, the node
returns a ConfigAck message in case that control channels can be used
as ACC and SCC, or returns a ConfigNack message including a proper
cause, which are based on the protocol capability received from the
peer node as needed.
With the request and response of control channel configuration, the
originating and terminating nodes can grasp the peer node identifier,
its type, and so on of each control channel.
4.2 Identification of Detour Control Channels
This function is used to configure a more powerful control network
after the identification of PG-1 and PG-3 control channels. This is
to establish a detour route using PG-1 or PG-3 control channels over
one or more transit nodes between adjacent nodes. Note that the
detour route is established using ACCs of the PG-1 or PG-3 configured
previously between other adjacent nodes.
For the dynamic designation of DCCs between adjacent nodes, the
originating node sends to its relay node a DCConfig message that
includes local and remote node identifiers. In order to support this
function, the originating node SHOULD complete the identification of
PG-1 and PG-3 control channels within the own node, and use other
ACCs except for the ACC that is directly connected to the terminating
node. Consequently, the originating node multicasts the DCConfig
message as many as the number of the other ACCs.
After receiving the DCConfig message, the transit node makes sure
that the own is not a terminating node for the message, relays the
message towards the terminating node. At this point, the node appends
the own node identifier to the relay node list. Then, sending a
DCConfig message to a succeeding node or sending a response message
to the previous node, the node applies the message sending rule as
follows:
Kim Expires April 14, 2006 [Page 6]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
1) If the hop-counter value estimated from the relay node list
exceeds the maximum threshold that can be different every
network topology (in case of the full mesh, tentatively 3), the
transit node returns a DCConfigNack message;
2) If the node to which the transit node wants to forward the
message is not the terminating one but the originating one, the
transit node returns a DCConfigNack message towards the
direction from which the message was received;
3) After sending a DCConfig message towards a terminating node, if
the transit node receives a DCConfig, then the node responds
with a DCConfigNack message;
4) After returning a response message towards the original node, if
the transit node receives a DCConfig message, the node returns a
DCConfigNack message towards the direction from which the
message was received;
5) If there is an ACC directly connected to the terminating node,
the transit node sends a DCConfig message over the control
channel;
6) When not being capable of sending a DCConfig message to the
terminating node, the transit node multicasts the DCConfig
message over one or more other ACCs.
Lastly, when the terminating node receives the first DCConfig
message, if the node responds to the request with a DCConfigAck
message, then the node SHOULD respond to the subsequent requests
with DCConfigNack messages.
A transit node that received the DCConfigAck message appends the own
node identifier to the relay node list, and updates a routing table
in order to forward control packets over the Detour Control Channel
(DCC). Then, the node relays the message towards the originating
node.
While configuring PG-1 and PG-3 control channels and DCCs, only the
ACC can carry control packets of signaling and routing protocols.
4.3 Automatic Switchover
When a failure on the ACC in use occurs, this function is used to
switchover to a control channel that first responds to the switchover
request (called multicast switchover).
Kim Expires April 14, 2006 [Page 7]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
Switchover messages are multicast via all standby control channels
except for the current ACC between adjacent nodes. Especially, when
switchover group messages are exchanged over a detour route, they
have to be forwarded at the IP layer of a transit node, and have not
to be gone up the application layer.
The originating node that requests the automatic switchover sends to
its terminating node a Switchover message with an indication of
switchover type, "automatic switchover". Then, the terminating node
SHOULD reply to the request with a SwitchoverAck message for a
successful response or SwitchoverNack message for an unsuccessful
response. When switchover group messages are exchanged over a detour
route, they have to be forwarded at the IP layer of a transit node,
and have not to be gone up the application layer.
4.4 Forced Switchover
Differently from the automatic switchover, this function is used to
switchover a control channel compulsorily for the purpose of
operation and administration via an intervention of operator.
The originating node that requests a forced switchover sends to its
terminating node a Switchover message with an indication of
switchover type, "forced switchover". Then, the terminating node
SHOULD reply to the request with a SwitchoverAck message for a
successful response or SwitchoverNack message for an unsuccessful
response. Like the automatic switchover, when switchover group
messages are exchanged over a detour route, they have to be forwarded
at the IP layer of a transit node, and have not to be gone up the
application layer.
4.5 Recovery from Failure
On recovery from the previous failure, the control channel performs
the process of connectivity verification of the control channel using
the identification of PG-1 and 3 control channels. Then, the control
channel becomes a SCC.
4.6 Notification of Control Channel Unavailability
This function is used to notify that there is no ACC to forward
control packets towards the terminating node due to subsequent
failures of other ACCs. This is called, DCC full down. A Notify
message is used for the notification. If the node that is notified
the unavailability of control channels is not the original node, this
process of relaying the Notify message is repeated until the original
node receives the message.
Kim Expires April 14, 2006 [Page 8]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
4.7 Inquiry of Switchover Attributes
This function is used to retrieve the protection and switchover
attributes of control channels over an ACC between adjacent nodes,
which are kept in its peer.
The protection and switchover attributes of control channels can be
classified into the ACC attributes and SCC ones. Accordingly, the
original node and its terminating node can identify if the own node
has the same attributes with its peer except for DCC related
contents.
The node that requests protection and switchover attributes of
control channels send a SAInqry message to its peer. The node that
receives the message responds to the request with a SAInqryAck
message for a successful response or SAInqryNack message for an
unsuccessful response.
4.8 Hello Initiation
This function is the same one to that in the LMP specification.
4.9 Notification of Protocol Errors
A functional entity supporting the resilience of control channels
SHOULD check protocol error conditions as a general rule before
acting upon a message after receiving the message from the peer
entity. If there is no protocol error within the received message,
resultant operations would be performed. However, if a protocol error
occurs, the receiving entity SHOULD notify the sending entity of the
situation using ProtError message, and there is no action against the
received message.
5. Finite State Machine of ACCP Protocol
The next job is to define a finite state machine that includes states
and events to perform the protection and switchover functions needed
to provide the resilience capability in IP based control networks.
States used in the ACCP protocol are defined as follows:
Down: Same to the LMP specification
Ready: State for exchanging Hello intervals and protection
attributes, and for identifying active and standby
control channels
Kim Expires April 14, 2006 [Page 9]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
Active: Same to the LMP specification, additionally state that
an active control channel is designated
Standby: State that a control channel is waiting for converting
into an active control channel
SoWaiting: State that a control channel is waiting for a response
to switchover request for being an active control
channel
Up: Same to the LMP specification, additionally state that
control packets can be exchanged, and a switchover can
occur
GoingDown: Same to the LMP specification
Events used in the ACCP protocol are defined as follows:
01) evAdminDown: Refer to the LMP specification
02) evBringUp: Refer to the LMP specification
03) evCCDn: Refer to the LMP specification
04) evConf: Event indicating that Config has been received from a
remote node
05) evConfDone: Event indicating that Config has been received from
a remote node
06) evConfErr: Refer to the LMP specification
07) evConfRetTimer: Refer to the LMP specification
08) evDCConf: Event indicating that DCConfig has been received from
a remote node
09) evDCConfDone: Event indicating that DCConfigAck has been
received from a remote node
10) evDCConfErr: Event indicating that DCConfigNack has been
received from a remote node
11) evDCConfTimer: Event indicating that a timer for starting DCC
configuration has expired
12) evDCConf2Timer: Event indicating that a timer for waiting DCC
configuration has expired
Kim Expires April 14, 2006 [Page 10]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
13) evDownTimer: Refer to the LMP specification
14) evHelloRcvd: Refer to the LMP specification
15) evHelloRetTimer: Refer to evHelloRet of the LMP specification
16) evHoldTimer: Refer to the LMP specification
17) evInqry: Event indicating that SAInqry has been received from a
remote node
18) evInqryDone: Event indicating that SAInqryAck has been received
from a remote node
19) evInqryErr: Event indicating that SAInqryNack has been received
from a remote node
20) evInqryReq: Event indicating that a local user hopes to
identify switchover attributes of an ACC from the remote
21) evNbrGoesDn: Refer to the LMP specification
22) evNoti: Event indicating that Notify has been received from a
remote node
23) evNotiReq: Event indicating that Notify has to be issued to a
remote node
24) evNWTimer: Event indicating that a negotiation-waiting timer
has expired
25) evProtErr: Event indicating that ProtError has been received
from a remote node
26) evProtErrOccurred: Event indicating that a protocol error has
occurred
27) evSeqNumErr: Refer to the LMP specification
28) evSo: Event indicating that Switchover has been received from a
remote node
29) evSoCompleted: Event indicating that switchover has performed
successfully due to CC down or operator request
30) evSoDone: Event indicating that SwitchoverAck has been received
from a remote node
31) evSoErr: Event indicating that SwitchoverNack has been received
Kim Expires April 14, 2006 [Page 11]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
from a remote node
32) evSoReq: Event indicating that switchover has to be performed
via intervention of an operator, or due to ACC's down
33) evSoTimer: Event indicating that the a switchover timer has
expired
Here, there are several differences between the ACCP protocol and the
current LMP about events and state transitions described in the LMP
document. First, in case of evBringUp and evHoldTimer events, the
ACCP protocol sends Config messages periodically and do not wait for
the receipt of a Config message. There is a reason why the
designation of a role per control channel causes unnecessary
overheads to an operator.
In the Active state, the state machine SHOULD make transition to the
Up state only after receiving a normal Hello message. Generally, the
status of control channels can be reflected using the Operation
Administration and Maintenance (OAM) function of a lower layer.
However, if the lower layer of the local has no problem but the
protocol engine in the remote has a problem, the local can not detect
whether the lower layer in the remote has a problem, the protocol
engine in the remote has a problem, or indirect links between the
local and the remote have problems without using a fast-keep
mechanism. Consequently, it is appropriate to estimate these
situations as a control channel down. For the detection of this
situation, Hello messages SHOULD be exchanged each other.
The resultant Finite State Machine (FSM) of using states and events
above needs further study.
6. Message Formats of ACCP Protocol
Messages used in the ACCP protocol in order to support control
networks with the resilience capability in IP-based networks are as
follows:
Config: Request about the configuration of a PG-1/3 CC
ConfigAck: Agreement about the configuration request of a
PG-1/3 CC
ConfigNack: Rejection about the configuration request of a
PG-1/3 CC
DCConfig: Request about the configuration of detour route
DCConfigAck: Agreement about the configuration request of
detour route
Kim Expires April 14, 2006 [Page 12]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
DCConfigNack: Rejection about the configuration request of detour
route
Hello: Support of fast keep-alive mechanism
Notify: Identification of the non-existence of control
channels available
ProtError: Notification of a protocol error
SAInqry: Request of the switchover attributes
SAInqryAck: Agreement about the request of switchover
attributes
SAInqryNack: Rejection about the request of switchover
attributes
Switchover: Request about the switchover
SwitchoverAck: Agreement about the switchover request
SwitchoverNack: Rejection about the switchover request
6.1 Config
In addition to the Config message defined in the LMP specification,
CC_PROPERTY and ADDI_INFO_INDICATOR objects are included to tell the
property and the capability of the control channel or the own node.
Its format is as follows:
<Config Message> ::=
<Common Header> <LOCAL_CCID> <MESSAGE_ID> <LOCAL_NODE_ID>
<CONFIG> <CC_PROPERTY> <ADDI_INFO_INDICATOR>
6.2 ConfigAck
In addition to the ConfigAck message defined in the LMP
specification, CC_PROPERTY and ADDI_INFO_INDICATOR objects are
included. Its format is as follows:
<ConfigAck Message> ::=
<Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<CC_PROPERTY>
Kim Expires April 14, 2006 [Page 13]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
6.3 ConfigNack
In addition to the ConfigNack message defined in the LMP
specification, CC_PROPERTY, ADDI_INFO_INDICATOR, and REJECT_CAUSE
objects are included. Its format is as follows:
<ConfigNack Message> ::=
<Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
<CC_PROPERTY> <REJECT_CAUSE>
6.4 DCConfig
This message is used to request the configuration of a DCC.
LAST_LOCAL_NODE_ID, LAST_REMOTE_NODE_ID, CC_PROPERTY, and
RELAY_NODE_ID objects are included. While traversing nodes towards
the last remote node, a relay node adds the own node identifier to
the RELAY_NODE_ID list. Its format is as follows:
<DCConfig Message> ::=
<Common Header> <MESSAGE_ID> <CONFIG>
<LAST_LOCAL_NODE_ID> <LAST_REMOTE_NODE_ID>
[<RELAY_NODE_ID>...]
6.5 DCConfigAck
This message is used to notify an agreement about the request to
configure a DCC. RELAY_NODE_ID objects are the same to the ones in
the previously received DCConfig message. Its format is as follows:
<DCConfigAck Message> ::=
<Common Header> <MESSAGE_ID_ACK> <LAST_LOCAL_NODE_ID>
<LAST_REMOTE_NODE_ID> [<RELAY_NODE_ID>...]
6.6 DCConfigNack
This message is used to notify a rejection about the request to
configure a DCC. Its format is as follows:
<DCConfigNack Message> ::=
<Common Header> <MESSAGE_ID_ACK> <CONFIG> <REJECT_CAUSE>
Kim Expires April 14, 2006 [Page 14]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
6.7 Hello
This message is the same to the one defined in the LMP specification.
6.8 Switchover
This message is used to request the automatic or forced switchover to
a particular control channels. Its format is as follows:
<Switchover Message> ::=
<Common Header> <MESSAGE_ID> <LOCAL_CCID> <LOCAL_NODE_ID>
<SEQUENCE_NUMBER> <SWITCHOVER_TYPE>
6.9 SwitchoverAck
This message is used to notify an agreement about the request of
automatic or forced switchover to a particular control channel. Its
format is as follows:
<SwitchoverAck Message> ::=
<Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<SEQUENCE_NUMBER>
6.10 SwitchoverNack
This message is used to notify a rejection about the request of
automatic or forced switchover to one or more control channels. Its
format is as follows:
<SwitchoverNack Message> ::=
<Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<SEQUENCE_NUMBER> <REJECT_CAUSE>
6.11 Notify
This message is used to notify that there is no DCC any more for the
switchover. Its format is as follows:
<Notify Message> ::=
<Common Header> <LOCAL_CCID> < REMOTE_CCID>
Kim Expires April 14, 2006 [Page 15]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
6.12 SAInqry
This message is used to request the protection and switchover
attributes for one or more control channels, which have been kept in
its peer. Its format is as follows:
<SAInqry Message> ::=
<Common Header> <MESSAGE_ID>
6.13 SAInqryAck
This message is used to notify an agreement about the request of
protection and switchover attributes for one or more control
channels. Its format is as follows:
<SAInqryAck Message> ::=
<Common Header> <MESSAGE_ID_ACK> <ACC_SWITCHOVER_ATTR>
[<SCC_SWITCHOVER_ATTR>]
6.14 SAInqryNack
This message is used to notify a rejection about the request of
protection and switchover attributes for one or more control
channels. Its format is as follows:
<SAInqryNack Message> ::=
<Common Header> <MESSAGE_ID_ACK> <REJECT_CAUSE>
6.15 ProtError
This message is used to notify a protocol error that is detected in a
received message. Its format is as follows:
<ProtError Message> ::=
<Common Header> <PROT_ERROR>
7. Object Definitions of ACCP Protocol
Objects used in the ACCP protocol in order to support control
networks with the resilience capability in IP-based networks are as
follows:
Kim Expires April 14, 2006 [Page 16]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
ADDI_INFO_INDICATOR: Additional capability to be supported
CC_TYPE: Type of control channel
CCID: Control channel identifier channel
CONFIG: Hello time-interval
HELLO: Sending and receiving sequence numbers
MESSAGE_ID: Sending Message identifier
NODE_ID: Node identifier
PROT_ERROR: Code-points of a protocol error
REJECT_CAUSE: Code Cause of rejection
SEQUENCE_NUMBER: Code Identification of message duplication
SWITCHOVER_ATTR: Attribute Type of protection and switchover
7.1 CCID Class
This object is the same to the one defined in the LMP specification.
7.2 MESSAGE_ID Class
This object is the same to the one defined in the LMP specification.
7.3 NODE_ID Class
This object defined in the LMP specification adds LAST_LOCAL_NODE_ID,
LAST_REMOTE_NODE_ID, and RELAY_NODE_ID types.
C-Type = 3, LAST_LOCAL_NODE_ID
C-Type = 4, LAST_REMOTE_NODE_ID
C-Type = 5, RELAY_NODE_ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kim Expires April 14, 2006 [Page 17]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
Node_ID: 32 bits
This identifies a last local node, last remote node, or
relay node.
7.4 CONFIG Class
This object is the same to the one defined in the LMP specification.
7.5 HELLO Class
This object is the same to the one defined in the LMP specification.
7.6 CC_PROPERTY Class
This object indicates the general information of a control channel,
including its type, the physical media, and the protection group.
Class = 21
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Type | CC_Media | PG_Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Type: 8 bits
This type indicates the type of control channel to be
identified.
CC_Type = 1, Active
CC_Type = 2, Standby
CC_Media: 8 bits
This indicates the physical transmission characteristic of
a control channel.
CC_Media = 1, SONET section or SDH Regenerator Section
CC_Media = 2, SONET line or SDH Multiplex Section
CC_Media = 3, VC-11 or VC-12 SONET/SDH Timeslot
CC_Media = 4, VC-3 SONET/SDH Timeslot
CC_Media = 5, VC-4 SONET/SDH Timeslot
CC_Media = 10, 10/100 Ethernet
CC_Media = 15, Giga Ethernet
CC_Media = 20, PoS
Kim Expires April 14, 2006 [Page 18]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
CC_Media = 30, WDM
PG_Type: 8 bits
This indicates the type of protection group (PG-1/2/3) to
which a control channel belongs.
PG_Type = 1, PG-1
PG_Type = 3, PG-3
PG_Type = 21, DCC with PG-2
PG_Type = 22, DCC with PG-3
7.7 SWITCHOVER_TYPE Class
This object indicates the general information of the switchover,
including its type and cause.
Class = 22
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| So_Type | Cause | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So_Type: 8 bits
This indicates the type of switchover.
So_Type = 1, Automatic switchover
So_Type = 2, Forced switchover
Cause: 8 bits
So_Type = 1, Automatic switchover
Cause = 1, ACC failed
So_Type = 2, Forced switchover
Cause = 1, Operator request
This identifies the cause why the switchover occurs.
7.8 SWITCHOVER_ATTR Class
This object indicates the switchover attributes of an ACC or SCC.
Class = 23
C-Type = 1, ACC_SWITCHOVER_ATTR
This indicates switchover attributes of the ACC.
C-Type = 2, SCC_SWITCHOVER_ATTR
This indicates switchover attributes of the SCC.
Kim Expires April 14, 2006 [Page 19]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_CC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_CC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacent_Node_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Property |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local_CC_ID: 32 bits
This identifies the control channel on which a node sends
messages.
Remote_CC_ID: 32 bits
This identifies the control channel on which a node
receives messages.
Adjacent_Node_ID: 32 bits
This identifies the node to which a control channel has
been connected remotely.
CC_Property: See above.
7.9 ADDI_INFO_INDICATOR Class
Class = 24
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addi_Info_Indicator | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addi_Info_Indicator: 16 bits
This indicates the additional capabilities supported by the
node sending this object.
Flag 1 (bit 1) set to 1 if the node supports the DCC
configuration.
Flag 2 to Flag 16 set to 0 and reserved for future use.
This object is negotiable.
7.10 SEQUENCE_NUMBER Class
Kim Expires April 14, 2006 [Page 20]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
Class = 25
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq_No | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Seq_No: 8 bits
The sequence number is used by the receiving node to
distinguish between a message received for first time and a
message that has already been received via other control
channels. This number is coded in modular operation from 0
and 255. Note that any message is not used to reset the
sequence number.
7.11 PROT_ERROR Class
This object indicates a detailed protocol error detected after a node
received a message from a remote node.
Class = 26
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE_Type | Cause | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PE_Type: 8 bits
Type = 0, Undefined
Type = 1, Message header
Type = 2, Object header
Type = 3, Object content
Cause: 8 bits
Type = 0, Undefined
Cause = 0, Undefined
Type = 1, Message header
Cause = 0, Undefined
Cause = 1, Undefined version
Cause = 2, Undefined flags
Cause = 3, Undefined message type
Cause = 4, Wrong message length
Kim Expires April 14, 2006 [Page 21]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
Type = 2, Object header
Cause = 0, Undefined
Cause = 1, Undefined C-Type
Cause = 2, Undefined class
Cause = 3, Wrong object length
Cause = 4, Out-of-sequence object
Type = 3, Object content
Cause = 0, Undefined
Cause = 1, Undefined ADDI_INFO_INDICATOR
Cause = 2, Undefined CC_TYPE
Cause = 3, Undefined CCID
Cause = 4, Undefined CONFIG
Cause = 5, Undefined HELLO
Cause = 6, Undefined MESSAGE_ID
Cause = 7, Undefined NODE_ID
Cause = 8, Undefined REJECT_CAUSE
Cause = 9, Undefined SEQUENCE_NUMBER
Cause = 10, Undefined SWITCHOVER_ATTR
Cause = 11, Undefined SWITCHOVER_TYPE
7.12 REJECT_CAUSE Class
This object indicates a detailed reject cause included in the
unsuccessful acknowledgement after a node received some kind of
request of configuration, switchover, and so on from a remote node.
Class = 27
C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RJ_Type | Cause | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RJ_Type: 8 bits
RJ_Type = 0, Undefined
RJ_Type = 1, Config related
RJ_Type = 2, DCConfig related
RJ_Type = 3, SAInqry related
RJ_Type = 4, Switchover related
Cause: 8 bits
RJ_Type = 0, Undefined
Cause = 0, Undefined
Kim Expires April 14, 2006 [Page 22]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
RJ_Type = 1, Config request
Cause = 0, Undefined
RJ_Type = 2, DCConfig related
Cause = 0, Undefined
RJ_Type = 3, SAInqry related
Cause = 0, Undefined
RJ_Type = 4, Switchover related
Cause = 0, Undefined
Cause = 1, Switchover completed
8. Security Considerations
This document does not introduce any new security considerations.
9. IANA Considerations
This document does not contain any IANA actions.
10. References
10.1. Normative References
[LMP] J. Lang, et al, "Link Management Protocol," IETF, draft-ietf-
ccamp-lmp-10.txt, October 2003.
[CPR-REQTS] Young Hwa Kim, and et al "Requirements for the Resilience
of Control Plane in GMPLS," IETF, draft-kim-ccamp-cpr-reqts-
01.txt, November 2005.
10.2. Normative References
[ITU-G870] ITU-T, "Requirements for Automatic Switched Transport
Networks (ASTN)," G.807, July 2001.
[ITU-G7712] ITU-T, "Architecture and Specification of Data
Communications Network," G.7712, March 2003.
Author's Addresses
Young Hwa Kim
yhwkim@etri.re.kr
ETRI 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea
Kim Expires April 14, 2006 [Page 23]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Kim Expires April 14, 2006 [Page 24]
draft-kim-ccamp-accp-protocol-00.txt October 15, 2005
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kim Expires April 14, 2006 [Page 25]
