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 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: ::= 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: ::= 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: ::= 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: ::= [...] 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: ::= [...] 6.6 DCConfigNack This message is used to notify a rejection about the request to configure a DCC. Its format is as follows: ::= 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: ::= 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: ::= 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: ::= 6.11 Notify This message is used to notify that there is no DCC any more for the switchover. Its format is as follows: ::= < 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: ::= 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: ::= [] 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: ::= 6.15 ProtError This message is used to notify a protocol error that is detected in a received message. Its format is as follows: ::= 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]