CCAMP Working Group Internet Draft Young Hwa Kim Document: draft-kim-ccamp-interaction-grsvpte- byung Ho Yae lcas-00.txt Jin Ho Hahm Expires: February 2004 Avri Doria ETRI Jun Kyun Choi ICU November 2003 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 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 - November 2003 [Page 1] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 only in a unidirection by EMS or NMS systems. However, the GMPLS signaling protocol has a feature of being capable of establishing bi- directional connections over a LSP. In current, there is no interaction between the signaling protocol and LCAS. In this document, 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 help the initiation process of egress node by EMS or NMS systems. Table of Contents 1. Summary for Sub-IP Area........................................2 2. Conventions Used in This Document..............................3 3. Introduction...................................................3 4. Review of GMPLS RSVP-TE, LMP and LCAS..........................4 5. Interaction requirements.......................................7 6. Proposal of the draft..........................................8 Security Considerations...........................................9 References........................................................9 Author's Addresses...............................................10 1. Summary for Sub-IP Area 1.1. Summary See the Abstract above. 1.2. 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.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 interaction requirements for a signaling protocol of the control plane in GMPLS. These requirements have no impact on LCAS at all. As Kim, et al [Page 2] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 such it is believed to fit within the charter because it deals with an upgrade of the signaling protocol such as GMPLS RSVP-TE. 1.5. Justification of Work The CCAMP WG should consider this document as LCAS is fit for GMPLS and the WG handles GMPLS. In addition, the draft addresses an upgrade of the signaling protocol such as GMPLS RSVP-TE to help the initiation process of egress node by EMS or NMS systems. 2. Conventions Used in This Document Terms such as UNI and NNI refer to [G.807]. And terms such as member and VCG refer to [G.7042]. 3. 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 remove 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 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. Kim, et al [Page 3] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 +===========+ +----------------------+ 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 establishment of bi-directional symmetric LSPs. However, in current, GMPLS signaling protocols have no knowledgement about the LCAS application. As such, although GMPLS signaling protocols have the capability of bi-directional establishment, the ingress and egress nodes have to initiate establishment requests 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. 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. 4. 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 bi-directional LSP establishment, explicit routing, route recoding, component indication of downstream and upstream interfaces, link property correlation, link connectivity verification, and LCAS establishment indication. As Kim, et al [Page 4] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 indicated in [GMPLS-ARCH], most of these features have been supported by the signaling protocol and link management protocol except for LCAS establishment 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]. However, the link capacity adjustment scheme had been standardized in Nov. 2001 by ITU-T. As such, the GMPLS signaling protocol still have no opportunity to add LCAS-related feature(s). Here, we could think that how much it is valuable to include LCAS establishment indication into the signaling protocol. If there may be special advantages, it may be no use considering the LCAS establishment indication. To show an example scenario, we will use information flows diagram that are based on the figure above. The first situation is not to apply the LCAS establishment indication in the signaling protocol on which requires a bi-directional LSP. The figure shows simple information flows when using GMPLS RSVP-TE as a signaling protocol. Kim, et al [Page 5] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 +=======+ +========+ +==========+ +========+ + 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)| | |<----------------------------------| | |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 LCAS establishment indication in the signaling protocol. Kim, et al [Page 6] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 +=======+ +========+ +==========+ +========+ + 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)| | |<----------------------------------| This figure above is the procedure that is performed after NMS's requests with an Increase command for bi-directional establishment. 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. 5. Interaction requirements When using the second procedure with the LCAS establishment indication, we could have two considerations, NMS's bi-directional request for LCAS control and definition of LCAS establishment indication. For the first consideration, to begin with, we have to exchange opinions between ITU-T and IETF in order to be capable of initiating the LCAS control 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. Kim, et al [Page 7] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 For the second consideration, Path message has to include the indication of requesting the initiation of LCAS control to the opposite direction by 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 establishment indication. For a example of the first approach, 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 establishment indication. As such, we could think that its use is extended to include the LCAS establishment indication. 6. Proposal of the draft Based on the procedures and requirements described above, the draft proposes to include the LCAS establishment indication extending the use of ADMIN_STATUS object as follows: In the third usage of Administrative Status Information, the information indicates a request to initiation of LCAS operation to the opposite direction by an egress node. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |L|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reflect (R): 1 bit, refer to [RFC3471] Reserved: 27 bits, refer to [RFC3471] LCAS establishment (L): 1 bit When set, indicates that the initiation of LCAS operation to the opposite direction should be taken by an egress node. Testing (T): 1 bit, refer to [RFC3471] Administratively down (A): 1 bit, refer to [RFC3471] Deletion in progress (D): 1 bit, refer to [RFC3471] Kim, et al [Page 8] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 Security Considerations Security issues are not considered in this proposal. However, It looks like that the security considerations mentioned in [RFC3472] or [RFC3473] may be applied in this draft as well. 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. [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. Kim, et al [Page 9] Internet Draft draft-kim-interaction-grsvpte-lcas-00.txt Nov. 2003 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 Kim, et al [Page 10]