Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 CCAMP Working Group Internet Draft Young Hwa Kim Document: draft-kim-ccamp-cc-protection-00.txt Sun Hee Yang ETRI Jun Kyun Choi ICU Jae Cheol Ryou CNU Expires: May 2003 November 2002 Requirements of Control Channels Protection Protocol 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. 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 proposes a protocol used to protect control channels between adjacent nodes in GMPLS. Control channels are used to carry several control packets that include signaling related, routing related, or link management related information. The protocol may be used not in in-fiber(or in-band) network configurations but in out-of-fiber(or out-of-band) network configurations. Because this proposal is a first document for specifying the protocol used to protect control channels, it has no full contents for the specification to be proposed. Instead, this document focuses on basic Kim, et. al. [Page 1] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 concepts, necessity and requirements to be analyzed for protecting control channels. If we agree with this proposal including necessity and requirements for protecting control channels, we may proceed further works for the protection of control channels. 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. Table of Contents 1. Introduction.....................................................2 1.1 Basic concepts for this proposal.............................3 1.1.1 Signaling transport configurations.....................3 1.1.2 Signaling types........................................3 1.1.3 C-path and C-channel...................................4 1.1.4 Protection group.......................................4 1.2 Necessity for protecting control channels....................5 1.3 Requirements in protecting control channels..................6 2. Future works for this proposal...................................8 Security Considerations.............................................8 References..........................................................9 Author's Addresses..................................................9 1. Introduction A control channel is a pair of mutually reachable interfaces that are used to enable communication between nodes for routing, signaling and link management, see [LMP]. 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 between control and data channels, the protection of control channels may be resolved using the protection scheme of data channels. There is no need of using the scheme to protect control channels. However, as indicated in [GMPLS-ARCH], the control channels between two adjacent nodes are no longer required to use the same physical medium as the data-bearing links between those nodes. A consequence of allowing the control channels between adjacent nodes to be Kim, et. al. [Page 2] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 physically diverse from the associated data-bearing links is that the configuration of a control channel does not necessarily correlate to the one of the data-bearing links, and vice-versa. 1.1 Basic concepts for this proposal The following concepts are basic contents needed for this proposal. 1.1.1 Signaling transport configurations As indicated in [O-UNI], types of signaling transport configurations to transport signaling messages are as follows: - In-fiber: Signaling messages are carried over a communication channel embedded in the data-carrying optical link between network elements; - Out-of-fiber: Signaling messages are carried over a dedicated communication link between adjacent nodes, separate from the data-bearing optical links. Here, we would like to comment only a point about these signaling configurations. In case of in-fiber signaling, the control scope of control channel is limited to a single fiber bearing the control channel. However, out-of-fiber signaling does not mean only the configuration that the control channel has to be different from the fiber bearing data channels. That is, the signaling also includes that the control channel within the fiber bearing data channels may also control data channels within other fibers, in addition to the configuration physically separated from the fiber bearing data channels. 1.1.2 Signaling types As indicated in [G.807], a signaling 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 signaling network shall be based upon common channel signaling, thereby allowing a network operator the capability of developing a separate signaling network. Common channel signaling links are associated with user channels in the following ways: - Associated: Signaling messages related to traffic between two Kim, et. al. [Page 3] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 network elements are transferred over signaling links that directly connect the two network elements; - Non-associated: Signaling messages between two network elements A and B are routed over several signaling links, whilst traffic signals are routed directly between A and B. The signaling links links used may vary with time and network conditions; - Quasi-associated: Signaling messages between nodes A and B follow a predetermined routing path over several signaling links whilst the traffic channels are routed directly between A and B. 1.1.3 C-path and C-channel [G.965] implicitly defines the C-path as "a layer 2 data link type to carry any one of several control information such as Control protocol, Link control protocol, PSTN Signaling protocol, Protection protocol, BCC protocol, etc". In addition, [G.965] defines the C- channel as "a 64 kbit/s time slot or communication channel on a V5.2 interface provisioned to carry communication paths". In this proposal, similar concepts with those of C-path and C-channel in [G.965] are applied except for the protocols applied and the 64 kbit/s time slot. GMPLS includes several protocols for routing, signaling, and link management. This proposal includes these GMPLS protocols as the protocols applied for the C-path, and uses the concept of control channel for the C-channel without modification. For the C-path, additionally, the protection protocol proposed should be added. Consequently, we may define the terminology of C-path and C-channel as the following: - C-path: A path used to carry any one of several control information such as routing, signaling, link management, and protection protocols; - C-channel: A pair of mutually reachable interfaces that are used to enable communication between nodes for routing, signaling, and link management. 1.1.4 Protection group A concept called the protection group may be needed for the protection of control channels. This concept is similar to that of [G.965], however, we have to consider the GMPLS environment being capable of supporting several signaling types of control channels. Kim, et. al. [Page 4] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 Switchover within a protection group can be performed using automatic operation, Switchover between protection groups can be performed using operator intervention. For a example, we may define the protection group as the following: - Protection group(PG): A group of control channels using the same type of signaling transport configuration. 1.2 Necessity for protecting control channels Before considering the necessity for the protection of control channels, we would like to address the following advantages of out-of-fiber signaling over in-fiber signaling: - Resource usage: Basically, in-fiber signaling requires more resources such as HDLC controllers, whereas out-of-fiber signaling may reduce the number of these resources; - Protection scheme: In case of in-fiber signaling it looks that there is no room for protecting control channels. However, out-of- fiber signaling may apply the various and effective S/W based protection schemes according to the protection methodology; - Separation from transport plane: In-fiber signaling is difficult to separate control plane from transport plane, whereas out-of-fiber signaling is easy to separate control plane. This may be a starting point of separation of call and connection; - Provision of GMPLS features: In-fiber signaling may provide only GMPLS features within a single fiber, and not provide the extended features such as connection control beyond a single fiber, whereas out-of-fiber signaling may provide these features easily. We think that out-of-fiber signaling has more advantages than in-fiber signaling. Then, when out-of-fiber signaling is used, control channels may be shared to control several fibers. If there is no protection of control channel on that situation using out-of- fiber signaling, failures of control channel may cause the problem like temporary suspension of control entities. If the repair of the failed control channel takes long time, the failure will result in the out-of-service of the control plane. In particular, in case of RSVP variant protocols, the failure of control channels may result in the effects such as unwanted connection teardown. In order to provide the stable and responsible communication environment of control plane in out-of-fiber signaling, we have to consider the physical and logical protection mechanisms of control channels. We may get the simple protection effect using the proposed protection protocol under Kim, et. al. [Page 5] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 the current network configurations without addition of H/W based facilities. For the support of concepts such as link bundling, explicit data channel identification, and non-impact between failures of control and data channels, the separation between control channels and data ones has been introduced in MPLS and GMPLS, see [GMPLS-ARCH] and [GMPLS-SIG]. This situation means that failure of control channels 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 channels. In the end, it may degrade the quality of service from the view-point of connection control and recovery. In addition, 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 a link that is carrying user traffic simply because the control channel is no longer available. However, the traffic that is using the data links may no longer be guaranteed the same level of service. In [LMP], it is said that the TE link is in a Degraded state. We think that we had better avoid this situation as possible as we can. We think that control channels are also very important as much as data channels. If there is no active control channel between adjacent nodes, although the fault handling procedures of protocols such as [GMPLS-RSVP] are supported, these special procedures are of no use until the failed control channels are recovered. In that there is no path to exchange any control messages between adjacent nodes, control plane entities that are running well may not provide potential and eminent services of control plane any more. We think that any kind of the protection mechanism of control channels may be useful in order to reduce at a maximum the possibility of full failure of control channel. 1.3 Requirements in protecting control channels We think that first of all the design of protection protocol for control channels depends upon the identification of appropriate requirements. The following items may be the requirements to be preferentially handled; - Types of protection group: At a glance, we may think a protection group per a signaling type. Also, we may consider several protection groups within the associated signaling type. In any case if we can define valid protection groups, they will be a cornerstone for Kim, et. al. [Page 6] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 protecting control channels. Our proposal is that the associated signaling type is designated to PG-1, then, non- and quasi- associated signaling types are designated to PG-2 within only optical transport networks. In addition, because there may be a possibility of being capable of external IP networks to exchange IP control packets, we may designate the scenario using external IP networks as PG-3; - Support of non- and quasi- associated signaling types in GMPLS: In present, we may not assert that non- and quasi- associated signaling types be supported in GMPLS as well. However, we may consider these types if reliable transport networks are more important than waste of network resources. In all optical environment to support these signaling types, we may have to resolve the routing problem for signaling packets. For more thorough protection of control channels, it is appropriate to keep in mind the possibility using these signaling types; - Support of concepts such as variant, logical C-channels, and etc in V5: Dependent upon the methodology for protecting control channels, we may apply these concepts to the specification of protection protocol. Or, because appliance of these concepts makes the network operation and administration more complex, we may exclude these concepts. However, as a side effect due to the exclusion, the specification for protecting control channels may become more complex because automatic signaling processing is needed to resolve several provisioning rules. Our proposal is that to reduce the overhead of operation and administration it is to exclude to these concepts in the protection of control channels; - Relationship with LMP: The one among the functions supported in LMP is the neighbor discovery. Using this function, the configuration of control channels is resolved. In case of in-fiber signaling, automatic configuration of control channels is possible. However, In case of out-of-fiber signaling, we still have no automatic configuration mechanism of control channels, and the work for the automatic configuration is in progressing in IETF. In any case, we think that LMP has very close relation to the protection of control channels due to its neighbor discovery of control channels configuration and hello operations. If the automatic configuration of control channels for out-of-fiber signaling supports several signaling types using LMP, we may provide more natural mechanisms in the specification for protecting control channels. Here, there may be a discussion whether LMP is performed first, or the protection protocol proposed is performed first. Our proposal is that the protection protocol proposed is performed after LMP in order to use the features of LMP such as automatic configuration of control channels and Hello operations; Kim, et. al. [Page 7] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 - Low protocols for protecting control channels: The protection protocol proposed may operate over UDP or raw IP. Our proposal is for the protection protocol to be performed over UDP by the same reason with LMP; - Reverting or non-reverting on recovery: The reverting mode on recovery may cause the unnecessary protection operation. Although the priority of control channel is lower than that of control channel recovered from failure, it is appropriate to keep the current status as it is for more simple protection operation. 2. Future works for this proposal If this proposal is agreed, we may think the following items as future works for the creation of specification about the control channel protection protocol(CCPP): - Requirements: First of all the requirements above have to be analyzed in detail, if needed, other requirements may be reviewed; - Functions supported: After identifying the requirements, we have to define the overall functions to switchover an active control channel to a standby control channel; - Procedures definition: After determining the functions to be supported, we have to define normal and abnormal procedures for the functions; - Objects definition: Because this is a new protocol, we have to take care of the definition of objects. If functions and procedures are not valid, the definition of objects may be also useless. For the creation of the specification of protecting control channels, the important works may be requirements identification, functions and procedures definition. If we do these works systematically, the work of objects definition may be trivial. In the next meeting, we are scheduled to contribute the draft specification including functions, procedures, and object definitions for protecting control channels based on requirements above. Security Considerations Security issues are not considered in this proposal. However, It looks that the security considerations mentioned in [LMP] may be also applied in this protocol. Kim, et. al. [Page 8] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 References [G.807] ITU-T Recommendation G.807, "Requirements for Automatic Switched Transport Networks (ASTN)", Jul. 2001. [G.965] ITU-T Recommendation G.965, "V-Interfaces at the digital local exchange (LE) ? V5.2 interface (Based on 2048 kbit/s) for the support of access network (AN)", Mar. 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. [LMP] J. Lang, et al, "Link Management Protocol", Internet Draft, draft-ietf-ccamp-lmp-06.txt, Sep. 2002. [GMPLS-SIG] Lou Berger, et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling-09.txt, Aug. 2002. [GMPLS-RSVP] Lou Berger, et al, "Generalized MPLS Signaling - RSVP- TE Extensions", Internet Draft, draft-ietf-mpls-generalized-rsvp-te-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 Sun Hee Yang ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, 305-350 Phone: +82 42 860 5231 E-mail: shyang.etri.re.kr Jun Kyun Choi Information and Communications University (ICU) Kim, et. al. [Page 9] Internet Draft draft-kim-ccamp-cc-protection-00.txt November 2002 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 10]