CCAMP Working Group Young Hwa Kim Internet-Draft ETRI Expires: April 14, 2006 October 15, 2005 Requirements for the Resilience of Control Plane 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 resilience of control plane refers to the ability of control plane to continue its operation even under failure conditions of Kim Expires April 14, 2006 [Page 1] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 control components such as control entities, control nodes, and control channels. This document describes requirements for providing the resilience capability of control plane (in other words, control network) in non-(G)MPLS and (G)MPLS. This contribution, as a document that proposes a framework to provide the resilience capability of control plane, include terminologies, basic concepts of control networks, possible configurations, necessities and requirements, additional considerations including the relationship with other protocol such as LMP for the resilience of control plane. Table of Contents 1. Introduction...................................................2 1.1 Terminology for Resilience of Control Channels............3 2. Terminology....................................................4 3. Control Networks...............................................4 4. Necessities for Resilience of Control Channels.................7 5. Requirements for Resilience of Control Channels................8 5.1 Requirements for MPLS 1+1 LSPs.............................8 5.2 Requirements for LMP-CCM Extension.........................8 6. Functions for LMP-CCM Extension................................9 6.1 Identification of PG-1 and PG-3 Control Channel............9 6.2 Identification of Detour Control Channels.................10 6.3 Automatic Switchover......................................10 6.4 Forced Switchover.........................................10 6.5 Recovery from Failure.....................................10 6.6 Notification of Control Channel Unavailability............10 6.7 Inquiry of Switchover Attributes..........................11 6.8 Hello Initiation..........................................11 6.9 Notification of Protocol Errors...........................11 7. Security Considerations.......................................11 8. IANA Considerations...........................................11 9. References....................................................11 9.1 Normative References......................................11 9.2 Informative References....................................12 Author's Addresses...............................................12 Intellectual Property Statement..................................12 1. Introduction There are three components in control plane, which are control entities, control nodes, and Control Channels (CCs). As described in [LMP], a control channel is a pair of mutually reachable interfaces can be used to exchange the control plane information such as link provisioning and fault management information, path management and Kim Expires April 14, 2006 [Page 2] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 label distribution information, and network topology and state distribution information. In addition to the exchange of control packets between nodes within a network, it may be possible to do transparent relay of routing and signaling information over those control channels between neighboring networks. A control entity is a functional process responsible for running link management, routing protocols or signaling functions. A control node means a physical node keeping various control entities. Best-effort based IP networks use routing protocols such as OSPF and BGP in order to forward data packets. In this situation, control packets generated by routing protocols are processed in the layer 3 as the same way that data packets exchanged by ordinary users are done in the layer. It means that channels carrying data and control packets share the fate. MPLS based IP networks upgraded from the best-effort based IP networks use routing and signaling protocols to establish LSPs that are determined for more effectively forwarding data packets. However, their control packets are still processed in the layer 3, and the fate of control channels is the same to that of data channels as well. Then, GMPLS based IP networks come to be capable of handling control channels separated from data channels. It means that channels carrying data and control packets do not have an impact upon each other. Several control channels such as SONET/SDH DCC channels and Ethernet OAM channels defined by the OIF, MPLS based LSPs applied as dedicated control channels, public IP networks, out-of-fiber based dedicated control channels, and so on can be configured independent from data channels for the purpose. In the end, a node can configure control channels of sharing the own fate with data channels or of separating the fate from data channels according to network requirements. It is an important thing that possible alternative paths exist between the communicating entities. Here, a network can provide protection and switchover functions of various levels based on configuration schemes and physical characteristics of paths to be used to exchange control packets between adjacent nodes. To effectively use these alternative paths between nodes, this document describes requirements for the resilience of control networks, which include terminologies, basic concepts of control networks, possible configurations, necessities and requirements, additional considerations, and so on. In this current document, only the resilience part of control channels is covered, the parts of control entities and control nodes need a further study. 1.1 Terminology for Resilience of Control Channels Kim Expires April 14, 2006 [Page 3] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 To provide the resilience capabilities of control channels, several terms layer should be introduced. For examples, these include control packet types, active and standby control channels, physical control channels, protection groups (PGs), and etc, which are not exhaustive. - Control packet types: Control information such as routing, signaling, and link management in GMPLS. In more detail, Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), and Border Gateway Protocol (BGP) variants are candidates for routing, Constraint-Based Routing Label Distribution Protocol (CR-LDP) and resource ReSerVation Protocol with Traffic Engineering (RSVP-TE) are ones for signaling, and Link Management Protocol (LMP) and the protocol proposed here are candidates for link management. - Active control channels: Physical control channels which are currently carrying the control information. An active control channel becomes a standby control channel when it can not carry the control information due to a failure. - Standby control channels: Physical control channels which are not currently carrying the control information, but can carry them upon the failure of active control channel. Once one of standby control channels is used to carry the control information, the standby control channel becomes an active control channel. - Physical control channels: Physical links used to carry control information, for examples, a separate wavelength or fiber, an Ethernet link, an Internet Protocol (IP) tunnel through a separate management network, or the overhead bytes of a data link. In this proposal, as a more extended concept, all links of in-fiber in-bend, in-fiber out-of-bend, and out-of-fiber can be physical control channels. - Protection group: A set of physical control channels using the same type of network configuration or belonging to similar aspects within the control network configuration. 2. Terminology 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 and indicate requirement levels for compliant implementations. 3. Control Networks Kim Expires April 14, 2006 [Page 4] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 In current IP networks, there is no explicit concept of control network. Instead there is the implicit concept of that. However, the terminology, called "control plane", gets acquainted in the IP world. The control plane represents aspects of control networks comprising control channels, control entities and control nodes used to transport control packets of signaling, link management, and routing protocols. In a sense of terminology, control plane is a set of communicating entities that are responsible for the establishment of connections including set-up, release, supervision and maintenance. A control plane is supported by a signaling network, in other words, a control network. In traditional IP networks or MPLS networks, there is an implicit one-to-one association of a control channel to a data channel. Under the one-to-one association between control channels and data channels, the protection of control channels may be resolved using the protection schemes for data channels such as 1+1, 1:1, and 1:N protections. In other words, where there is fate sharing, failures of data channels could instantly influence the own control channels. However, as described in [GMPLS-ARCH], a control channel can be separated from the data channel in GMPLS. To allow for the control channels between adjacent nodes to be separated from the associated data-bearing links means that there is not a one-to-one association between a control channel and a data channel. It means that failures of data channels could not influence the own control channels any more. As indicated in [ITU-G807], a control network (as a narrow meaning, signaling network) supports control plane by the act of transferring service-related information between the user and the network and also between network entities. The control network can be constructed using common control signaling, thereby allowing a network operator to have the capability of developing a separate control network. According to this document, control channels are associated with data channels in the following ways: - Associated mode in which control packets between network elements are transferred over control channels that directly connect the network elements such as transport channels; - Quasi-associated mode in which control packets between nodes A and B follow a predetermined routing path over several control channels while the traffic channels are routed directly between A and B; - Non-associated mode in which control packets between two network elements A and B are routed over several control channels, while traffic signals are routed directly between A and B. The control Kim Expires April 14, 2006 [Page 5] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 channels used may vary with time and network conditions. This mode has two types of control channels, non-associated mode with internal network and non-associated mode with external network. The internal case says that control channels are connected each other under the similar configuration of its transport network, but the external case says that control channels are connected each other via other network that is definitely different from the configuration of its transport network. On the one hand, as defined by the Optical Internet Forum (OIF), control channel configurations to carry control packets over Synchronous Optical NETwork (SONET) and Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), and Ethernet include two types of the following: - In-fiber configuration in which control packets are carried over a control channel embedded in the data-carrying link between network elements; - Out-of-fiber configuration in which control packets are carried over a dedicated control channel between adjacent nodes, which is separated from the data-bearing links. In the case of in-fiber configuration above, we can expand this configuration and apply it to the out-of-fiber configuration that a control channel within a fiber that includes transport channels can handle transport channels in the fiber itself as well as other fibers. In addition, a similar concept to a control network can be found in the Signaling Communication Network (SCN) within the Automatic Switched Transport Network (ASTN) in [ITU-G7712]. There may be several physical implementations for the SCN. For example, Embedded Control Channels (ECC) interfaces, Local Area Network (LAN) interfaces, and Wide Area Network (WAN) interfaces are possible. Then, there is an important indication for the resilience of control plane. Common to each topology is that alternative diverse paths exist between the entities. Although a failure occurs over a signaling link between adjacent nodes on the topology, one or more alternative paths disjointed or indifferent to the failed link can be identified. To use the most of possible control channels would have an important role for the resilience of control plane. Here, the resilience of control plane refers to the ability of a control network to maintain an acceptable level of control services during failures of communicating entities. Also, the resilience of control channels means the protection and switchover capability that can configure one or more signaling routes between adjacent nodes within a control network or between control networks, and allow Kim Expires April 14, 2006 [Page 6] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 control packets to be exchanged within a threshold against the failure of one or more control channels. 4. Necessities for Resilience of Control Channels As recognized in the IP world, IP routing protocols have slow convergence time due to the hello interval and expiration times for the normal operation of IP networks. Under this situation, fast and reliable recovery is very difficult from one or more failures occurred over interfaces between adjacent nodes. Then, why is the fast and reliable recovery of control channels needed? There is a reason that the failure of control channels would affect new connection set-up, connection tear-down, and fault report. In addition, control channels could include control packets for link management protocol, routing protocols as well as control packets of other IP control protocols, according to the application level into those. In this circumstance, the fast and reliable communication environment would be a very important factor in controlling IP networks stably. However, if there is no resilience capability of control channels even though there is a possibility being capable of sufficiently using the nature of a network, the early determination that there are no more control channels within a network may cause problems like the communication suspension between control entities even though data channels are running well. When RSVP variant protocols are used between adjacent nodes, if there is no self-refresh procedure, the failure of control channels may result effects such as unwanted connection teardown. In particular, as described in [ITU-G7712], such a failure that could not transport ASTN messages over the SCN may impact restoration when ASTN is used to provide restoration of existing connections. It is therefore critical for a control network to provide the resilience of control channels that could sufficiently use direct and indirect ones between adjacent nodes. Those channels could be classified into two groups roughly, direct (similar to the associated mode) and indirect interfaces. More specifically, the indirect case could be classified into indirect interfaces using direct interfaces (similar to the quasi-associated mode) and other indirect interfaces including internal or external networks (similar to the non-associated modes). Here, a network can provide protection and switchover functions of various levels based on configuration schemes and physical characteristics of links to be used to exchange control packets between adjacent nodes. For examples, for the resilience of control channels, the control channel management (CCM) function of LMP could Kim Expires April 14, 2006 [Page 7] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 be extended, or MPLS 1+1 LSPs using the dual-feed and selection scheme could be applied. 5. Requirements for Resilience of Control Channels To introduce resilience capabilities into control channels, several requirements have to be identified according to schemes addressed above. 5.1 Requirements for MPLS 1+1 LSPs For this scheme, control entities should establish two LSPs to be used as control channels using signaling protocol such as a RSVP or LMP variant protocol. Control packets shall be sent with the same sequence number and the same contents over two LSPs between adjacent nodes. The sequence number shall be used as the identifier for packet 1+1 protection, and is located after the 4-bytes MPLS encapsulation header. Then, a receiving node of these control packets would ignore a control packet that arrives late with the same sequence number. This section is based on [ITU-G7712]. 5.2 Requirements for LMP-CCM Extension 1) Configuration of control networks The support of the resilience capability of control networks though the LMP extension requires either that the number of control channels between adjacent nodes has to be greater than one, and there has to be at least one active control channel and more than one standby control channel. The important point is that adjacent nodes that want to exchange control packets should in advance know their physical characteristics of control channels and control modes such as associated, non-associated, or quasi-associated. For this scheme, it is to keep a single active control channel and one or more standby control channels. When a failure occurs at an active control channel, a node would switch the failed control channel over to the one of standby control channels using provisioning rules and negotiation results between nodes. Then, one among several standby control channels turns into an active control channel instead of the previous active control channel. The distribution of control packet types into more than one control channel may be possible, but this case requires further study. For this case, the switchover function of control channels should in advance know control packet types that a control channel carries. In order to simplify our approach in the problem domain, it is assumed Kim Expires April 14, 2006 [Page 8] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 that a single control channel carries all control packets such as routing, signaling, and link management. 2) Protection Groups of Control Networks We assign control channels of the associated mode to the PG-1, assign control channels of the quasi-associated mode to the PG-2, and finally assign control channels of the non-associated mode to the PG- 3. Such as, a set of data channels in a transport network can be PG-1 and PG-2 control channels. In addition, the PG-3 control channels have to be able to control security options according to its network environment. Nodes over a PG-3 route might not detect the condition of an unavailable control channel because they do not have the function of control channel management. On a failure of control channel over the detour route, there may be a situation that the availability of a control channel can not be guaranteed within a proper timing limit. Also, different addressing scheme of control channels among PGs can be applied, and the same addressing scheme of control channels within a PG should be applied. 3) Relay of Control Packets in a Transit Node In other modes except for the associated mode, there is a possibility that control packets can be traversed via one or more transit nodes in order to guarantee the safe transfer of control packets between real adjacent nodes. In this case, if a node is not the destination node of being capable of receiving control packets, the node must relay those packets over a control channel connected with a succeeding node. 6. Functions for LMP-CCM Extension 6.1 Identification of PG-1 and PG-3 Control Channel 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 9] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 6.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. 6.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). 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. 6.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. 6.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. 6.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 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 message is repeated until the original node receives the message. Kim Expires April 14, 2006 [Page 10] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 6.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. 6.8 Hello Initiation This function is the same one to that in the LMP specification. 6.9 Notification of Protocol Errors A functional entity for the resilience of control networks 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 a message, and there is no action against the received message. 7. Security Considerations This document does not introduce any new security considerations. 8. IANA Considerations This document does not contain any IANA actions. 9. References 9.1 Normative References [LMP] J. Lang, et al, "Link Management Protocol," IETF, draft-ietf- ccamp-lmp-10.txt, October 2003. [GMPLS-ARCH] Eric Mannie, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", rfc3945, May 2003. Kim Expires April 14, 2006 [Page 11] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 9.2 Informative 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 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea 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 Kim Expires April 14, 2006 [Page 12] draft-kim-ccamp-cpr-reqts-01.txt October 15, 2005 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 Funding for the RFC Editor function is currently provided by the Internet Society. Kim Expires April 14, 2006 [Page 13]