CCAMP Working Group Internet Draft Young Hwa Kim Document: draft-kim-ccamp-cc-protection-02.txt byung Ho Yae Expires: November 2003 Jin Ho Hahm ETRI Jun Kyun Choi ICU Jae Cheol Ryou CNU March 2003 Requirements for Protecting Control Channels 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 the one of standby CCs when a failure occurs about the active CC. It defines terminology, base concepts for CC protection, necessities and considerations of CC protection that should be primarily noted in order to complete the mechanism of CC protection. Kim et al [Page 1] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 Table of Contents 1. Terminology....................................................2 2. Introduction...................................................3 3. Signaling Modes and Signaling Transport Configurations.........3 4. C-path and PGs.................................................4 5. Necessities for CC Protection..................................5 6. CC Protection Considerations...................................6 7. Functions provided in CCPP.....................................7 Security Considerations...........................................7 References........................................................8 Acknowledgments...................................................8 Author's Addresses................................................8 1. Terminology 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. Some terms used throughout this document are listed below. Active Control Channel (ACC) : A physical control channel which is currently carrying a logical control channel. An active control channel becomes a standby control channel when it is not carrying a logical control channel. Bearer Channel (BC) : Channels used to provide the unidirectional or bidirectional transmission capability for clients of optical transport networks. Control Channel Protection Protocol (CCPP) : A new protocol used to protect control channels between adjacent nodes in GMPLS. Control Channel (CC) : A pair of mutually reachable interfaces that are used to enable communication between nodes for routing, signaling, and link management. Control Path (C-path) : A path used to carry any one of several control information as routing, signaling, link management, and protection protocols. Logical Control Channel (LCC) : Kim, et al [Page 2] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 A group of one or more control paths, all of different types, including the control path for control channel protection protocol (CCPP). Physical Control Channel (PCC) : Timeslots or wavelengths which have been assigned for logical control channel. A physical control channel not used for carrying bearer channels. Protection Group (PG) : group of control channels using the same type of signaling transport configuration. Standby Control Channel (SCC) : Physical control channels which are not carrying a logical control channel, but are use for the protection of logical control channels. Once it is used carry a logical control channel, a standby control channel becomes an active control channel, and is controlled under allocated priority. 2. Introduction A CC is a pair of mutually reachable interfaces that are used to carry control packets between nodes for routing, signaling and link management, see [LMP]. In traditional MPLS, there is an implicit one-to-one association of a CC to a bearer channel (BC). Under the one-to-one association between CCs and BCs, the protection of CCs may be resolved using the protection scheme of BCs. There is no need of using the scheme to protect CCs. However, as indicated in [GMPLS-ARCH], the CCs 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 CCs between adjacent nodes to be physically diverse from the associated data-bearing links is that the configuration of a CC does not necessarily correlate to the one of the data-bearing links, and vice-versa. Consequently, the mechanism for CC protection could be used not in in-fiber(or in-band) network configurations but in out- of-fiber(or out-of-band) network configurations. 3. Signaling Modes and Signaling Transport Configurations In case of in-fiber signaling, the control scope of CC is limited to a single fiber bearing the CC. However, out-of-fiber signaling does not mean only the configuration that the CC has to be different from Kim, et al [Page 3] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 the fiber including BCs. That is, the signaling also includes that the CCs within the fiber including BCs may also control BCs within other fibers, in addition to the configuration physically separated from the fiber including BCs. 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: - In associated mode, signaling messages related to traffic between two network elements are transferred over signaling links that directly connect the two network elements; - In non-associated mode, 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 used may vary with time and network conditions; - In quasi-associated mode, 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. In addition to signaling modes, as indicated in [O-UNI], types of signaling transport configurations to transport signaling messages are as follows: - In in-fiber type, signaling messages are carried over a CC embedded in the data-carrying optical link between network elements; - In out-of-fiber type, signaling messages are carried over a dedicated CC between adjacent nodes, separate from the data-bearing optical links. 4. C-path and PGs C-path includes information types of GMPLS protocols for routing, signaling, and link management. OSPF and IS-IS extensions are candidates for routing, CR-LDP and RSVP-TE are ones for signaling, and LMP is a candidate for link management. The proposed CCPP is another candidate for link management. In the signaling transport configuration of out-of-fiber type, associated, non-associated, and quasi-associated modes could be applied to GMPLS based networks. For the mechanism of CC protection, Kim, et al [Page 4] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 three PGs may be considered, and it is assumed that an higher PG is applied based on the general transmission speed of control packets. For a example, CCs of associated mode could be PG-1, CCs of quasi- associated mode could be PG-2, and finally CCs of non-associated mode could be PG-3. CCs within the same PG and other PGs could be switched via automatic operation or operator intervention based on priority assigned to each CC. They are assigned their supporting PGs, priorities within the own PG, logical CC identifiers, and C-paths on which peer entities have to verify their protection attributes between nodes through automatic operation. 5. Necessities for CC Protection There could be following advantages of out-of-fiber signaling over in-fiber signaling: - Basically, in-fiber signaling requires more resources such as HDLC controllers, whereas out-of-fiber signaling may reduce the number of these resources; - In case of in-fiber signaling it looks that there is no room for protecting CCs. However, out-of-fiber signaling may apply the various and effective S/W based protection schemes according to the protection methodology; - In-fiber signaling is difficult to separate control plane from transport plane, whereas out-of-fiber signaling is easy to separate control plane; - 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. When out-of-fiber signaling is used, CCs may be shared to control several fibers. If there is no protection of CCs on that situation, a failure of the ACC may cause the problem like temporary suspension of control entities although they are running well. If recovery of the failed CC 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 CCs may result in the effect such as unwanted connection teardown. Eventually, in order to provide the stable and responsible communication environment between control entities of control plane in out-of-fiber signaling, the protection mechanism of CCs is needed under the current network configurations without addition of H/W based facilities. Kim, et al [Page 5] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 For the support of concepts such as link bundling, explicit BC identification, and non-impact between failures of CCs and BCs, 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 CC does not cause failure of BCs. 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 CC. In the end, it may degrade the quality of service from the view-point of connection control. As indicated in [LMP], there may not be any ACCs available while the data links are still in use. For many applications, it is unacceptable to tear down connections on the reason that there is no available CC. And, on this situation, the traffic that is using the data links under the failed CC may no longer be guaranteed to the same level of service. In [LMP], it is said that the TE link is in a degraded state. CCs are also very important as much as BCs. If there is no ACC 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 CCs are recovered. In that there is no path to exchange any control packets between adjacent nodes, control entities that are running well may not provide potential and eminent services of control plane any more. 6. CC Protection Considerations First of all, the design of protection protocol for CCs depends upon the identification of appropriate requirements. The following items are the requirements to be applied preferentially for the protection protocol proposed, CCPP: - Using the neighbor discovery provided by LMP, the configuration of CCs is resolved. In case of in-fiber signaling, automatic configuration of CCs is possible. However, In case of out-of-fiber signaling, there is still no automatic configuration mechanism of CCs, and the work for the automatic configuration is in progressing in IETF. LMP has very close relation to the protection of CCs due to CC configuration and hello initiation in the neighbor discovery. If the automatic configuration of CCs for out-of-fiber signaling supports several signaling types using LMP, more natural mechanisms for protecting CCs may be supported. Here, there may be a discussion whether LMP is performed first, or the protection protocol proposed is performed first. On nature of a protection protocol, it is desirable to first of all perform CCPP than LMP and other GMPLS Kim, et al [Page 6] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 protocols. In any case, this item needs the negotiation with the LMP community for more efficient protection of CCs. - Reverting mode on recovery may cause the unnecessary protection operation within the same PG. Although the priority of an CC is lower than that of another CC 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 PG. However, recovery between PGs is different from that within the same PG. It is desirable to take reverting mode than non-reverting mode to provide more quality of service (QoS); - The CCPP operates not over TCP or raw IP but over UDP. 7. Functions provided in CCPP The functions provided in CCPP are follows: - The function of negotiation for protection attributes is the optional one provided in CCPP that an entity negotiates the protection attributes such as PGs, CCs, priorities, and C-paths with the other; - The function of inquiry into protection attributes is the one that an entity request the information of protection attributes to the other to compare the own attributes; - As a primary function of CCPP, it is the automatic switchover of CCs on which an entity requests a switchover of the ACC to SCC about the LCC without operator's intervention when a failure in the ACC occurs; - As other primary function of CCPP, it is the non-automatic switchover of CCs on which an operator requests a switchover of the ACC to SCC about the LCC; - The function of reset for sequence number of CCPP is the one that indicates the peer entity that a misalignment of state variables has occurred and that all state variables shall be set to zero; - The function of notification on protocol error is the one that indicates that a protocol error has been identified in a received CCPP message. 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 7] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 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. Acknowledgments The authors would like to speak that base concepts for protecting CCs in GMPLS are cited from the protection protocol of G.965 document in ITU-T. 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 Kim, et al [Page 8] Internet Draft draft-kim-ccamp-cc-protection-02.txt March 2003 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 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 9]