CCAMP Working Group Young Hwa Kim Internet Draft byung Ho Yae Document:draft-kim-ccamp-interaction-grsvpte-lcas-01.txt Jin Ho Hahm Expires: August 2004 Avri Doria Dong Yong Kwak ETRI Jun Kyun Choi ICU February 2004 Interaction between GMPLS RSVP-TE and LCAS 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 interaction aspects between a signaling protocol and the LCAS. The signaling protocol handled by IETF could be GMPLS RSVP-TE. GMPLS CR-LDP requires further study for this draft. The LCAS protocol handled by ITU-T is a protocol that is used to change the bandwidth capacity of a virtual concatenated signal used by transport networks (i.e. SDH and OTN), which should be initiated Kim et al Expires - August 2004 [Page 1] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 only in a unidirection by EMS or NMS systems. However, the GMPLS signaling protocol have a feature of being capable of controlling bi- directional connections on a LSP. In current, there is no interaction between the signaling protocol and the LCAS. In this document, when a signaling protocol such as the GMPLS RSVP-TE and the LCAS are used together within a single node and a bi-directional connection is required on the same route, relevant requirements and encoding methods are identified. Table of Contents 1. Summary for Sub-IP Area........................................2 2. Conventions Used in This Document..............................3 3. Main Changes from The Previous Version.........................3 4. Introduction...................................................3 5. Review of GMPLS RSVP-TE, LMP and LCAS..........................5 6. Interaction requirements.......................................8 7. Proposal of the draft..........................................9 Security Considerations..........................................10 References.......................................................10 Author's Addresses...............................................11 1. Summary for Sub-IP Area 1.1. Related Documents - RFC3473, "GMPLS RSVP-TE Extensions", Jan. 2003. - draft-ietf-ccamp-lmp-10.txt, "Link Management Protocol (LMP)", Oct. 2003. - RFC3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC3471, Jan. 2003. 1.2. Where Does it Fit in the Picture of the Sub-IP Work This work fits in the CCAMP WG. 1.3. Why Is It Targeted at This WG This draft is targeted at the CCAMP WG because this draft specifies interaction requirements for a signaling protocol of the control plane in GMPLS. These requirements have no impact on the LCAS at all. As such it is believed to fit within the charter because it deals with an upgrade of the signaling protocol such as the GMPLS RSVP-TE. 1.4. Justification of Work Kim, et al [Page 2] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 The CCAMP WG should consider this document as the LCAS is fit for GMPLS and the WG handles GMPLS. In addition, the draft addresses upgrades of a signaling protocol such as the GMPLS RSVP-TE to help the initiation process of egress node by EMS or NMS systems. 2. 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 UNI and NNI refer to [G.807]. And terms such as member and VCG refer to [G.7042]. 3. Main Changes from The Previous Version Several changes from the previous version (*00.txt) are as follows: - Update of the LCAS operation indication in the section, Interaction requirements; - Addition of the response of an initiation request in the section, Interaction requirements; - Addition of the NMS's bi-directional request in the section, Proposal of the draft; - Update of how to encode the LCAS operation indication in the section, Proposal of the draft; - Addition of error codes for an unsuccessful response of a LCAS operation in the section, Proposal of the draft; - Addition of an co-author. 4. Introduction As described in [G.7042], LCAS is a link capacity adjustment scheme that should be used to increase or decrease the capacity of a container that is transported in an SDH/OTN network using Virtual Concatenation(VC). The operation of LCAS is unidirectional under control of EMS or NMS systems. This means that in order to bi- directionally add or delete members the procedure has to be repeated in the opposite direction. The scheme uses the K4 overhead byte for lower order LCAS of VC-m-Xv (m=11,12,2) and the H4 overhead byte for Kim, et al [Page 3] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 higher order LCAS of VC-n-Xv (n=3,4) in SDH to exchange control packets. In OTN, the scheme uses VC overhead (VCOH 1/2/3) in the information structure, optical channel payload unit (OPUk, k = 1/2/3). From the view-point of implementation, LCAS is a layer 1 based protocol, differently from signaling protocols. From the view-point of IETF, it is said that the LCAS-related path computation performed by NMS could be performed within a network element as well if routing functions are used to exchange the information of network topology and link status. However, for convenience' sake we assume that the path computation is performed in NMS. As an example using LCAS, we could take the following figure. NMS could initiate an increase or decrease command to indicate addition or deletion of members to the ingress node(Node1) for the downstream direction (links La/e/i) and to the egress node(Node4) for the upstream direction (links Ll/h/d/b) over a LSP. +===========+ +----------------------+ NMS +----------------------+ | +---+===========+---+ | | | | | | | | | | | | | | | | | | | | | +---------+ +-----------+ +-----------+ +---------+ + Node1 La+------>+Lc Node2 Le+------>+Lg Node3 Li+------>+Lk Node4 + + Lb+<------+Ld Lf+<------+Lh Lj+<------+Ll + +---------+ +-----------+ +-----------+ +---------+ (Ingress) (Egress) <------------------------ NNI -------------------------> We could assume a LSP with a bi-direction of the same route for respective direction. The SONET/SDH based transport network is a typical example. As described in [GMPLS-ARCH], GMPLS allows connection control of bi-directional symmetric LSPs. However, in current, GMPLS signaling protocols have no knowledge about the LCAS application. As such, although GMPLS signaling protocols have the capability of bi-directional connection, the ingress and egress nodes have to initiate requests of the connection setup and release to the respective direction. However, as indicated in [GMPLS-ARCH], these two unidirectional paths have several disadvantages such as latency delay, control overhead, complicated route selection, and so on. Kim, et al [Page 4] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 This document describes interaction aspects to resolve the inconsistency between a signaling protocol and LCAS .The signaling protocol handled by IETF could be GMPLS RSVP-TE. GMPLS CR-LDP requires further study for this draft. When a signaling protocol such as GMPLS RSVP-TE and LCAS are used together within a node and the bi- directional connection is requested over the same route, the relevant requirements are identified to avoid the initiation process of egress node by EMS or NMS systems. 5. Review of GMPLS RSVP-TE, LMP and LCAS To support the interaction capability between a signaling protocol and LCAS, the GMPLS signaling protocol and link management protocol should provide several functions such as connection control of bi- directional LSP, explicit routing, route recoding, component indication of downstream and upstream interfaces, link property correlation, link connectivity verification, and LCAS operation indication. As indicated in [GMPLS-ARCH], most of these features have been supported by the signaling protocol and link management protocol except for the LCAS operation indication. For examples, As indicated in [RFC3473], a bi-directional LSP setup is indicated by the presence of an Upstream Label in the Path message. Explicit routing about the path taken by an LSP is controlled by using an Explicit Route Object (ERO) in the message. Up-to-date detailed path information on a hop-by-hop basis during the LSP setup process is collected via route recoding mechanism of using Record Route Object (RRO) in [RFC3209]. Component indication of downstream and upstream interfaces is resolved using the IF_ID RSVP_HOP object. In addition, property correlation and connectivity verification about component interfaces connected between a pair of nodes are supported by [LMP]. The link capacity adjustment scheme had been standardized in Nov. 2001 by ITU-T, and the scheme have included LCAS operations such as addition, deletion, and temporary removal of one or more members that they may have effects on the LSP control. But, we think the temporary removal does not influence the LSP control. The GMPLS signaling protocol still have no opportunity to add these LCAS-related feature(s). Here, we could think the advantages that we could obtain from the inclusion of the LCAS operation indication into the signaling protocol. To address the advantages, we will use information flows diagram that are based on the figure above. The first situation is not to apply the indication of LCAS setup in the signaling protocol on which requires a bi-directional LSP. The Kim, et al [Page 5] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 figure shows simple information flows when using GMPLS RSVP-TE as a signaling protocol. +=======+ +========+ +==========+ +========+ + NMS + + Node 1 + + Node 2/3 + + Node 4 + +=======+ +========+ +==========+ +========+ |In. cmd.(uni) | | | |--------------->|Path(RSVP-TE) | | | |---------------->|Path(RSVP-TE) | | | |---------------->| | | |Resv(RSVP-TE) | | |Resv(RSVP-TE) |<----------------| | |<----------------| | | | | | | |ADD(LCAS) | | |---------------------------------->| | | OK(LCAS)| | |<----------------------------------| | |EOS(LCAS) | | |---------------------------------->| | | | In. cmd.(uni) | |--------------------------------------------------->| | | | Path(RSVP-TE)| | |Path(RSVP-TE) |<----------------| | |<----------------| | | |Resv(RSVP-TE) | | | |---------------->|Resv(RSVP-TE) | | | |---------------->| | | ADD(LCAS)| Kim, et al [Page 6] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 | |<----------------------------------| | |OK(LCAS) | | |---------------------------------->| | | EOS(LCAS)| | |<----------------------------------| This figure above is the procedure that is performed after NMS's requests with an Increase command of each direction. Of course, in this diagram more detailed LCAS procedures and GMPLS RSVP-TE procedures are omitted. In addition, Increase commands for the respective downstream (ds) and upstream (us) could be issued at the same time by NMS. The important thing is that the respective direction should apply the own individual LSP procedure. Possible disadvantages in this case are identified in [GMPLS-ARCH]. Another important drawback is difficult to meet real-time protection requirements. Then, to avoid the problem we could consider the second situation to use the indication of LCAS setup in the signaling protocol. +=======+ +========+ +==========+ +========+ + NMS + + Node 1 + + Node 2/3 + + Node 4 + +=======+ +========+ +==========+ +========+ |In. cmd.(bi) | | | |--------------->|Path(RSVP-TE) | | | |---------------->|Path(RSVP-TE) | | | |---------------->| | | |Resv(RSVP-TE) | | |Resv(RSVP-TE) |<----------------| | |<----------------| | | | | | | |ADD(LCAS) | | |---------------------------------->| | | OK(LCAS)| | |<----------------------------------| | |EOS(LCAS) | | |---------------------------------->| | | | | | ADD(LCAS)| | |<----------------------------------| | |OK(LCAS) | | |---------------------------------->| | | EOS(LCAS)| | |<----------------------------------| Kim, et al [Page 7] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 This figure above is the procedure that is performed after NMS's requests with an INCREASE command for bi-directional setup. Of course, in this figure as well more detailed LCAS procedures and GMPLS RSVP- TE procedures are omitted. In addition, ADD control packets in the ingress and egress nodes could be issued at a proper time that has nothing to do with the opposite's condition. 6. Interaction requirements When using the second procedure with the LCAS operation indication, we could have three considerations, the NMS's bi-directional request for a LCAS operation, how to encode the LCAS operation indication, and the unsuccessful response of an initiation request. 6.1. NMS's bi-directional request For the first consideration, we may exchange opinions between ITU-T and IETF in order to initiate a LCAS operation in a bi-direction at a once only under the assumption that the bi-directional connection is established over the same route and a pair of component interfaces for downstream and downstream traffic. 6.2. LCAS operation indication For the second consideration, the Path message has to include the indication of requesting the initiation of LCAS operation to the opposite direction by an egress node. The LCAS operation indication has no impact on transit nodes and has to be transparently delivered to an egress node. If the current specification of GMPLS RSVP-TE would have included relevant object(s) to add the indication, we could resolve the problem statement easily. And, if we wouldn't find out relevant object(s) in the current documents, we could define a new object with the LCAS operation indication. For the case to use an object among the current objects, we could consider the extension of ADMIN_STATUS object in [RFC3471]. As indicated in the document, the information is currently used in two ways, for the indication of administrative state with respect to a particular LSP, and for the indication of a request to set an LSP's administrative state. However, it looks like these uses don't fit to the LCAS operation indication. As such, we could think the expansion of its use to include the LCAS operation indication. In addition, we could consider the SESSION_ATTRIBUTE object. The SESSION_ATTRIBUTE object can be added to aid in session identification and diagnostics. Especially, using the flags field with 8 bits of this object, options such as a local repair mechanism of transit routers, the inclusion of label information, and the use Kim, et al [Page 8] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 of SE Style could be indicated. In current, three of those bits are assigned in [RFC3209]. A further two bits are assigned in [FRR] for fast re-reroute functionality. We could use the sixth bit of this field to initiate the LCAS operation by an egress node. In other alternative, it is to include the LCAS operation indication to a new object for RSVP-TE messages. A good solution is to use the mechanism addressed in [ATTRI]. 6.3. Response of an initiation request For the third consideration, we have to consider the response of an initiation request of the LCAS operation. An egress node could accept or reject the request of the LCAS operation such as addition or deletion of one or members. In the case of rejection, there are two possibilities implicit and explicit rejection. The implicit rejection means that an egress node could not perform the LCAS operations because the node does not run the LCAS protocol, and the explicit rejection means that an egress node could not perform the LCAS operations due to a resource problem or other causes although the node do run the LCAS protocol. On the receipt of successful or unsuccessful result about the initiation request of the LCAS operation, the ingress node would take an appropriate action such as an notification to its maintenance system or an actual start-up of the LCAS operation towards the egress node. 7. Proposal of the draft 7.1. NMS's bi-directional request We think this requirement is not so actual a problem if there is an internal agreement between control and management planes for the LCAS operation to be initiated by the GMPLS RSVP-TE in an egress node not by EMS or NMS systems. Also, there is no need to modify the LCAS specification for the interaction between the LCAS and GMPLS RSVP-TE. The important thing is that an original initiation for the LCAS operation by a management system, and the unidirectional nature of the LCAS operation is remain unchanged. In a sense, this requirement looks like a implementation issue. 7.2. LCAS operation indication Ahead of this contribution, we have already the mechanism in used to process signaling attributes to be imposed on the path between an ingress and egress nodes. If the mechanism gets an agreement from the CCAMP WG, we propose to use the Attribute flags addressed in [ATTRI] for the LCAS operation indication. More detailed encoding rules should be clarified, based on the requirement described in the Kim, et al [Page 9] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 previous chapter. One consideration for the encoding rules of the LCAS operation indication is that how many bits should be used to identify the LCAS operations such as addition and deletion of members. We think that only a single bit could identify a LCAS operation using setup or release information of a LSP in which the setup information mean the LCAS addition operation, and the release operation mean the LCAS deletion operation. Then, it is appropriate for the LSP attributes flag of [ATTRI] to include a bit with "LCAS operation". 7.3. Response of an initiation request Although there is no need to indicate an accept of the LCAS operation within a response to the Path message, in the case of failure, the response should include one of rejection causes of the LCAS operation. Possible error codes are such as the following, and other codes could be added: - "Unsupported LCAS protocol" : when an egress node do not support the LCAS protocol. - "Not performable LCAS operation" : when an egress node could not perform the LCAS operation due to a resource contention or other causes. Security Considerations This document proposes enhancements of GMPLS RSVP-TE for an interaction between the LCAS and the GMPLS RSVP-TE. It does not introduce any new direct security issues and the reader is referred to the security considerations expressed in [RFC2205], [RFC3209] and [RFC3473]. References [G.707] ITU-T Recommendation G.707, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)", Aug. 2002. [G.709] ITU-T Recommendation G.709, "Interfaces for the optical transport network (OTN)", Feb. 2001. [G.807] ITU-T Recommendation G.807, "Requirements for Automatic Switched Transport Networks (ASTN)", Jul. 2001. [G.7042] ITU-T Recommendation G.7042, "LINK CAPACITY ADJUSTMENT SCHEME(LCAS) FOR VIRTUAL CONCATENATED SIGNALS", Nov. 2001. Kim, et al [Page 10] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 [GMPLS-ARCH] Eric Mannie, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Internet Draft, draft-ietf-ccamp-gmpls- architecture-07.txt, Aug. 2002. [LMP] J. Lang, et al, "Link Management Protocol", Internet Draft, draft-ietf-ccamp-lmp-10.txt, Oct. 2003. [GMPLS-SIG] Lou Berger, et al, "Generalized MPLS Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling- 09.txt, Aug. 2002. [RFC2205] R. Braden, L. Zhang, et al, "Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification", RFC2205, Sep. 1997. [RFC3209] D. Awduche, L. Berger, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, Dec. 2001. [RFC3471] L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC3471, Jan. 2003. [RFC3473] L. Berger, "GMPLS Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC3473, Jan. 2003. [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, Internet Draft, work in progress. [ATTRI] Adrian Farrel, Dimitri Papadimitriou, Jean-Philippe Vasseur, Arthi Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP- TE", draft-ietf-mpls-rsvpte-attributes-02.txt, Internet Draft, work in progress. 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 Kim, et al [Page 11] Internet Draft draft-kim-interaction-grsvpte-lcas-01.txt February 2004 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 Dong Yong Kwak ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, 305-350 Phone: +82 42 860 5148 E-mail: dykwak@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 Kim, et al [Page 12]