CCAMP Working Group Internet Draft Young Hwa Kim Document: draft-kim-ccamp-cc-protection-03.txt byung Ho Yae Expires: November 2003 Jin Ho Hahm Avri Doria ETRI Jun Kyun Choi ICU March 2003 Requirements for Providing Resilience of Control Plane in GMPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document describes base requirements for protecting control channels(CCs) for GMPLS. It provides guidelines needed in order to switchover an active CC to one of standby CCs when a failure occurs about the active CC. It defines terminology, base concepts, necessities, and considerations that should be noted primarily in order to complete the mechanism of CC protection. This document describes requirements for providing resilience capabilities of control plane in GMPLS whose control channel can be separated from the data channel. This contribution, as a document that proposes the Kim, et al Expires - November 2003 [Page 1] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 necessity about resilience of control plane like that of transport plane, handles related terminologies, base concepts, possible configurations, necessities and requirements, additional considerations including the relationship with other protocol such as LMP. Table of Contents 1. Summary for Sub-IP Area........................................2 2. Main Changes from The Previous Version.........................3 3. Conventions Used in This Document..............................3 4. Introduction...................................................3 5. Control Networks...............................................4 6. Concepts for Resilience of Control Plane.......................6 7. Necessities for Resilience of Control Plane....................6 8. Requirements for Resilience of Control Plane...................8 9. Functions for Resilience of Control Plane.....................10 Security Considerations..........................................10 References.......................................................10 Author's Addresses...............................................11 1. Summary for Sub-IP Area 1.1. Summary See the Abstract above. 1.2. Related Documents draft-ietf-ccamp-gmpls-architecture-03.txt, Aug. 2002. draft-ietf-ccamp-lmp-08.txt, Mar. 2003. draft-ietf-mpls-generalized-signaling-09.txt, Aug. 2002. 1.3. Where Does it Fit in the Picture of the Sub-IP Work This work fits in the CCAMP WG. 1.4. Why Is It Targeted at This WG This draft is targeted at the CCAMP WG because this draft specifies requirements for the resilience capabilities of the control plane in GMPLS. As such it is believed to fit within the charter because it deals with multi-layer protection and restoration mechanisms that have not yet been specified. A resultant specification from this Kim, et al [Page 2] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 requirements could involve a new protocol or an extension to the Link Management Protocol (LMP). 1.5. Justification of Work The WG should consider this document as it addresses requirements for the resilience capabilities of control channels that have not been addressed. These are link management mechanisms that have a direct relation to GMPLS protocols such as [LMP]. 2. Main Changes from The Previous Version Several changes from the previous version (*02.txt) are as follows: - Addition of the section 1 (Summary) and 2 (Changes); - Overall contents modification, from the section 3 to the section 9 to focus on requirements - Deletion of terms in the section 3, move and re-description to the section 6; - Addition of the signaling communication network (SCN) concept within the automated switched transport network (ASTN) in the section 5; - Re-description of the section 8 and 9. 3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Terms such as ASTN, UNI, and NNI used in this document refer to [G.807]. 4. Introduction As described in [LMP], a control channel is a pair of mutually reachable interfaces that are used to carry control packets between nodes for routing, signaling and link management. In addition to the transport of control packets between nodes within a network, it is possible to do transparent relay of routing information between neighboring networks those control channels. A control entity is the functional process responsible for running signaling, link management, Kim, et al [Page 3] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 and routing protocols. The term 'Control plane' represents aspects of control networks comprise those control channels and control entities used to transport control packets for signaling, link management, and routing. The survivability of the control plane refers to the ability of a control network to maintain an acceptable level of control services during one more failures of one or more control channels or control entities. The survivability of control channels is covered in this document. The survivability of control entities is beyond the scope in this document. In traditional MPLS, there is an implicit one-to-one association of a control channel to a data channel. Under the one-to-one association 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:1 protection or by using control plane re-routing capabilities. In other words, where there is fate sharing, i.e. when control channels are not separated from the data channels, there is no need to consider the specific resilience capabilities for the control plane. However, as indicated in [GMPLS-ARCH], a control channel can be separated from the data channel. 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. Consequently, it means there may be a need for considering resilience capabilities for these control channels. If there is no protection mechanism allowing dynamic configuration of control channels between relevant nodes, nodes have to determine alternative control channels based on the operator intervention via the management plane. This results in the degradation of the service provided by a control network. In the end, to resolve these problems in control networks, GMPLS nodes have to be provided with resilience capabilities. First, however, we have to define a framework or guideline for protecting control channels. This document describes basic concepts of control networks, related terminologies, requirements, and functions to be provided. Following acceptance of the requirements. Then, the protection mechanisms of control channels will be covered in a separate specification, or in an extension of the LMP specification. 5. Control Networks As indicated in [G.807], a control network supports the control plane by the act of transferring service-related information between the user and the network and also between network entities. The control network is based upon common control channels, thereby allowing a Kim, et al [Page 4] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 network operator the capability of developing a separate control network. Common control channels are associated with data channels in the following ways (the following is based on the description contained in [G.807]) : - In associated mode, control messages related to traffic between two network elements are transferred over control channels that directly connect the two network elements; - In non-associated mode, control messages 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 channels used may vary with time and network conditions; - In quasi-associated mode, control messages 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. In addition to these control modes, as indicated in [O-UNI], types of network configurations to transport control messages are as follows: - In in-fiber type, control messages are carried over a control channel embedded in the data-carrying optical link between network elements; - In out-of-fiber type, control messages are carried over a dedicated control channel between adjacent nodes, which is separated from the data-bearing optical links. In the case of out-of-fiber type, we can consider a situation that control channels within a fiber that includes data channels can control data channels in that fiber. This scenario is a variant to the configuration where the control channel is physically separated from the fiber including the data channels. A similar concept with a control network is found in the signaling communication network (SCN) within the automated switched transport network (ASTN) in ITU-T. As indicated in [G.7712], there may be several physical implementations for the SCN. For example, embedded control channels (ECC) interfaces, LAN interfaces, and WAN interfaces are possible. Here, there is an important reason for the survivability function of control plane: as described in the recommendation, common to each topology, is that alternative diverse paths exist between the communication entities (i.e., the ASTN capable network elements). That is, network elements themselves of ASTN may keep alternative control channels such as ECC interfaces, LAN interfaces, and WAN interfaces. Of course, in case of ECC, there may be several direct and indirect interfaces between nodes. Kim, et al [Page 5] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 6. Concepts for Resilience of Control Plane To provide the resilience capabilities of control channels, several protection concepts for a higher layer could be introduced. For example, these include control packet path, active and standby control channels, physical control channels, protection groups, etc. This section defines these terminologies. Other concepts may also required and can be identified in the future. - Control information type : It is the control information type such as routing, signaling, and link management in GMPLS. In more detail, OSPF, IS-IS, and BGP variants are candidates for routing, CR-LDP and RSVP-TE are ones for signaling, and LMP and the protection protocol to be proposed are candidates for link management. - Active control channels : these are physical control channels which are currently carrying the control information type. An active control channel becomes a standby control channel when it can not carry the control information due to a failure. - Standby control channels : they are physical control channels which are not carrying the control information. Once any of standby control channels is used to carry the control information, the standby control channel becomes an active control channel. - Physical control channels : they are timeslots or wavelengths which have been assigned a control channel identifier to carry control information. A physical control channel could not be used for carrying data traffic. - Protection group : It is a group of physical control channels using the same type of network configuration or belonging to similar aspects within the same network configuration. 7. Necessities for Resilience of Control Plane As indicated in [LMP], a control network could keep at the same time in-fiber and out-of-fiber configurations. In general, there may be several advantages of out-of-fiber over in- fiber such as the followings: - When using the overhead bytes of SONET/SDH as a control channel, in-fiber may require more resources such as HDLC controllers whereas out-of-fiber could reduce the number of these resources; Kim, et al [Page 6] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 - In case of only in-fiber, it looks that there is no room or no need for protecting control channels. However, out-of-fiber may apply the various and effective software based protection schemes; - In-fiber is difficult to separate control plane from transport plane, whereas out-of-fiber is easy to separate control plane; - Because in-fiber provides the connection control function only within a single fiber, in-fiber could not provide the connection control function beyond a single fiber, whereas out-of-fiber has no restriction about the number of fibers for the connection control function. When the out-of-fiber configuration is used, control channels may be shared to handle several fibers. If there is no protection of control channels at that situation, a failure of the active control channel may cause the problem like temporary suspension of control entities although they are running well. If the recovery of failed control channel takes a long time, the failure will result in loss of service of the control plane. In case of RSVP variant protocols, 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 [G.7712], such a failure may impact restoration when ASTN is used to provide restoration of existing connections. It is therefore critical for the control network to provide resiliency when transporting restoration messages. Consequently, to provide the resilience capabilities of control plane, it is reasonable to use out-of-fiber rather than in-fiber for GMPLS. In addition, for the support of concepts such as link bundling, explicit data channel identification, and non-impact between failures of control channels and data channels, the separation between control plane and transport plane has been introduced in MPLS and GMPLS, see [GMPLS-ARCH] and [GMPLS-SIG]. This situation means that failure of control channel does not cause failure of data channels. However, if there is no recovery even beyond the time limits in RSVP or LMP, it may result in the deletion of previously established connections, or invoke operator intervention to manually treat the failure of control channel. It may degrade the quality of service from the view-point of connection control. As indicated in [LMP], there may not be any active control channels available while the data links are still in use. For many applications, it is unacceptable to tear down connections. And, at this situation, the data links under the failed control channel may not be guaranteed the same level of service with that of control channel before a failure. In [LMP], it is said that the TE link is in a degraded state. Eventually, in order to provide the stable and reliable communication environment between control entities of control plane in the out-of- Kim, et al [Page 7] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 fiber configuration, the protection mechanism of control channels could be applied under the current network configurations without the addition of hardware based facilities. 8. Requirements for Resilience of Control Plane To introduce resilience capabilities into control plane, several requirements have to be identified. These include configuration of control networks, priorities in control channels, choice between reverting and non-reverting modes, relation to LMP, and so on. 8.1. Configuration of Control Networks To simplify the approach to the problem domain of the resilience of control plane, we assume that a single control channel carries all control packets such as routing, signaling, and link management. The support of resilience capabilities of control plane requires either that the number of active control channels between two nodes has to be greater than one, or there has to be a single active control channel and more than one standby control channel. The important thing is that a pair of adjacent nodes should be configured to know which of the mechanisms is being used. If there are several simultaneous active control channels between two nodes with the same control network configuration, at least two control channels among them could be used to carry the same control messages with different sequence numbers on which a receiving node ignores the control packet that arrives late. In this case, the resilience capabilities of control plane are sufficient with more than two simultaneous active control channels and the processing capability of sequence numbers in routing, signaling, and link management protocols. However, we have to take into account the CPU processing ability and unnecessary overhead because at least twice as many control packets are generated and at least half of them are ignored. The more appropriate environment for control plane resilience is for a control network to keep a single active control channel and several standby control channels at a time. Then, when a failure on the active control channel occurs, based on the provisioning rules such as protection group and standby control channels list, it can switch the failed control channel over to one of standby control channels that becomes a active control channel. Of course, the switch-over has to be possible via automatic operation or operator intervention. Kim, et al [Page 8] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 The separation of control packet types into more than one control channels requires is also possible and requires investigation. But, regardless of separation and non-separation of control packet types, the protection function of control channels should know about which control channel carries which control packet types. 8.2. Configuration of Control Networks If there is more than a single protection group within a control network, we could assume the priority between protection groups. As a simple example, control channels of associated mode could be PG-1, control channels of quasi-associated mode could be PG-2, and finally control channels of non-associated mode could be PG-3. Here, we could assume that PG-1 is assigned the highest priority, PG-2 is assigned the higher priority, and PG-3 is assigned the lowest priority, based on factors such as network configuration and transmission speed of control channels. Control channels within the same and other protection groups could be switched via automatic operation or operator intervention based on provisioning rules assigned to each control channel. 8.3. Reverting and Non-reverting Modes Reverting mode may cause the unnecessary protection operation within the same protection group. Although the priority of an control channel is lower than that of another control channel recovered from failure, it is appropriate to keep the current status for more simple protection operation. That is, non-reverting mode shall be applied within the same protection group. However, recovery between protection groups is different from that within the same protection group. It is preferable to use reverting mode than non-reverting mode to provide better quality of service (QoS) from the perspective of the control plane. 8.4. Relation to LMP Using the neighbor discovery of LMP, the configuration of control channels is resolved. In case of in-fiber type, automatic configuration of control channels is possible. However, In case of out-of-fiber type, there is still no automatic configuration mechanism of control channels, and the work for the automatic configuration is progressing in IETF. If the automatic configuration of control channels for out-of-fiber is supported, more natural mechanisms for protecting control channels may be supported. In addition, there may be a dispute whether LMP is performed first, or the protection function of control channels is performed first. It is desirable to first of all perform the protection function than LMP and other GMPLS protocols. As a whole, LMP has several procedures which are relevant for the support of resilience capabilities of Kim, et al [Page 9] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 control plane. The relation of protection to LMP requires investigation. 9. Functions for Resilience of Control Plane The possible functions to be provided for the resilience of control plane include but are not limited to: - The function of negotiating the control network configuration; - The function of negotiating protection attributes such as control modes, standby control channels list, and etc about a control channel; - The function of inquiry into the protection attributes that an entity requests the information of protection attributes to the other to compare with the own attributes; - The function of automatic switchover that an entity requests a switchover of the active control channel to one of standby control channels without operator's intervention when the active control channel suffers a failure, or on the reverting recovery; - The function of manual switchover of a control channel through the operator intervention. Security Considerations Security issues are not considered in this proposal. However, It looks that the security considerations mentioned in [LMP] may be applied in this protocol at the same. References [G.807] ITU-T Recommendation G.807, "Requirements for Automatic Switched Transport Networks (ASTN)", Jul. 2001. [G.7712] ITU-T Recommendation G.7712, "Architecture and Specification of Data Communications Network", Oct. 2001. [O-UNI] OIF, OIF2000.125.7, "User Network Interface (UNI) 1.0 Signaling Specification", Oct. 2001. [GMPLS-ARCH] Eric Mannie, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Internet Draft, draft-ietf-ccamp-gmpls- architecture-03.txt, Aug. 2002. Kim, et al [Page 10] Internet Draft draft-kim-ccamp-cc-protection-03.txt March 2003 [LMP] J. Lang, et al, "Link Management Protocol", Internet Draft, draft-ietf-ccamp-lmp-08.txt, Mar. 2003. [GMPLS-SIG] Lou Berger, et al, "Generalized MPLS Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling- 09.txt, Aug. 2002. Author's Addresses Young Hwa Kim ETRI 61 Gajeong-dong, Yuseong-gu, Daejeon, 305-350 Phone: +82 42 860 5819 E-mail: yhwkim@etri.re.kr Byung Ho Yae ETRI 61 Gajeong-dong, Yuseong-gu, Daejeon, 305-350 Phone: +82 42 860 5819 E-mail: bhyae@etri.re.kr Jin Ho Hahm ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, 305-350 Phone: +82 42 860 6048 E-mail: jhhahm.etri.re.kr Avri Doria ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, 305-350 Phone: +82 42 860 1019 E-mail: avri@etri.re.kr Jun Kyun Choi Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yuseong, Daejeon, 305-732 Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Jae Cheol Ryou Dept. of Computer Science, Chungnam National University (CNU) 220 Gung-dong, Yuseong-gu, Daejeon, 305-764 Phone: +82 42 821 7443 E-mail: jcryou@home.cnu.ac.kr Kim, et al [Page 11]