CCAMP Working Group Internet Draft Diego Caviglia Document: draft-caviglia-mp2cpcp2mp-00.txt Marconi Francesco Lazzeri Marconi Nicola Ciulli Consorzio Pisa Ricerche Expires: September 2004 April 2004 GRSVP-TE signaling extension to move Management created LSP to Control Plane and vice versa. 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 memo introduces a new flag in the Administrative Status object, namely the ŸFake÷ flag. This flag SHOULD be used in order to move under the Control Plane (CP) domain LSPs that were created by the Management Plane (MP), and vice versa. The result of the Fake flag in GRSVP-TE is twofold: at the end of the set-up signaling flow, an LSP that was created by Management Plane is moved under to Control Plane domain. Similarly, at the end of a deletion procedure the LSP that was under the Control Plane domain is moved under the Management Plane domain. CavigliaExpires - September 200 [Page 1] draft-caviglia-mp2cp&cp2mp-00.txt April 2004 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 [2]. Table of Contents 1. Introduction...................................................2 2. Overview.......................................................3 2.1 Association - LSP SetUp....................................3 2.2 Disassociation - LSP Tear Down.............................4 3. Association Procedures.........................................4 3.1 Association Failure........................................5 3.2 Disassociation.............................................5 4. RSVP Message Formats...........................................6 4.1 Object Modification........................................6 4.1.1 Administrative Status Object 6 5. Security Considerations........................................7 References........................................................7 Author's Addresses................................................8 1. Introduction The deployment of a GMPLS control plane in already existent networks is likely not to be a green field application in the sense that Management-Plane(MP)-created circuits and GMPLS-created ones will coexist together. In this scenario, a Network Operator might need to move MP-create LSPs under the control of the GMPLS plane, and vice- versa. At present no GMPLS mechanism are available, for a Carrier Operator, to associate/disassociate GMPLS information to an already existent LSP. In order to accomplish this, a new flag for the Administrative Status Object (RFC 3471[3] and RFC 3473 [4]) is proposed in this memo, namely the ŸFake÷ flag. When this flag is set during a set-up signaling, it allows to associate GMPLS state to an existing SDH circuit (already up and carrying traffic), and thus to move the resulting LSP under the Control Plane domain. The same flag, when used during a deletion procedures, it allows to disassociate GMPLS information from an LSP- triggered SDH circuit, thus moving it to the Management Domain without affecting the traffic. Association procedure is in some way similar to the Restart Procedure, (Section 4.3 RFC 3473 [4]), in the sense that the cross CavigliaExpires - September 200 [Page 2] draft-caviglia-mp2cp&cp2mp-00.txt April 2004 connection in the Data Plane are already present and only GMPLS information has to be associated to it. The modification proposed in this document refers only to Administrative Status object, that is, the message flow is left unmodified for both set-up and deletion. 2. Overview Signaling uses the same messages as usual, and the processing of the messages is the same, as well, with the only exception that no operations have to be performed in the Data Plane: the LSP cross- connections donËt have to be either created (set-up phase), nor deleted (deletion phase). Within this memo we postulate that the resource availability check about the requested cross connection are performed at the receipt of the Path message. 2.1 Association - LSP SetUp In order to support the association of SDH circuits, the ERO object in the Path message MUST to be filled in with all the relevant information to identify the existing circuit, that is, TE-link and Component Link specification, up to the Label level. This can be done by means of the object and procedures defined in [5]. The ERO detailed information (the full circuit Ÿdescription÷) should be provided by the MP entity in charge of the adoption of the circuit. From the start of the signaling procedure, until the moment when the G.RSVP-TE ResvConf message is received, each TNE involved in the LSP set-up SHOULD maintain information about the fact that an adoption procedure is ongoing. This information MIGHT be used in case of adoption set-up failures. If an adoption fails, a normal signaling procedure will follow (based on PathErr and/or PathTear and/or ResvErr) and will result in removing the GMPLS LSP state. It is RECOMMENED that the TNE will leave in place the Data Plane resource associations (i.e. the circuit cross-connection): in case of adoption failure, the Data Plane tear-down procedures should follow the same rules as in a normal LSP Ÿadoption-release÷ deletion phase. Failures during the Association of an LSP are managed as usual but the fact that TNEs receiving error messages, with Path State Removed set, do not delete the cross connection in the data plane but only their GMPLS associated information. CavigliaExpires - September 200 [Page 3] draft-caviglia-mp2cp&cp2mp-00.txt April 2004 Each TNE involved in the adopted LSP MAY dismiss any information about the adoption after the last signaling tier (Resv or ResvConf messages); if this happens, from that moment on the LSP will be regarded as a normal GMPLS-created circuit. 2.2 Disassociation - LSP Tear Down Disassociation of GMPLS information from an LSP that is under control of the Control Plane is done as described in Section 7.2.1 of the RFC 3473 [4] but the fact that also the Fake flag of the Administrative Status object is set. 3. Association Procedures This Section covers the procedure needed to manage an association procedure, that is, a set-up where Path message contain an Administrative Status object with the Fake flag set. In the following, the association of a bidirectional LSP is taken into consideration; the case of unidirectional case can be easily inferred from that. A node receiving a Path message containing an Administrative Status object with the Fake flag set checks if there is a Data Plane cross connection between the resources indicated by the message: í If yes, then a GRSVP-TE state is associated with the cross connection. í If no, the node attempts the same operations involved in a normal LSP set-up: o If both the two resources indicated by the Pat message are free then: o The cross connection in the Data Plane is performed and, o the associated GRSVP-TE state is created. The information about the fact that the signaling is about an association is maintained by the TNE up to the receipt of the Resv Confirm. In the second case, if the Data Plane resources set-up fails (e.g. because the two resources are used in a way that is different from CavigliaExpires - September 200 [Page 4] draft-caviglia-mp2cp&cp2mp-00.txt April 2004 the one indicated by the Path message), then the TNE takes usual actions to announce the problem: í a PathErr with Path State Removed flag set SHOULD be sent to the previous node; í Any GMPLS LSP state information is deleted, but actual cross connection in the data plane MIGHT not be. The following example illustrates the four possible cases[NC1]. The cross connection to be moved under the control plane is made up of Timeslot A and B. The symbol <----> means that the two Timeslots are cross connected. Data Plane Control Plane Case 1 A<---->B NoInformation Case 2 A B NoInformation Case 3 A<---->C NoInformation Case 4 C<---->B NoInformation - Case 1: no actions are taken in the Data Plane, GRSVP-TE state is associated to the cross connection; - Case 2: the cross connection is created in the Data Plane and the GRSVP-TE state is associated to it; - Case 3 and 4: a PathErr with Path State Removed flag set should be sent upstream. 3.1 Association Failure When a node receives a PathErr with Path State Removed set checks if the LSP it refers to is a under Association procedure if yes then no actions are performed in the data plane while the GMPLS status information is removed and the cross connection is moved under the NMS controls. The same applies for ResvErr and PathTear messages. 3.2 Disassociation Disassociation follows a normal LSP tear-down procedure as described in Section 7.2.1 of the RFC 3473 [4] with Fake bit is set in the Admin Status object. CavigliaExpires - September 200 [Page 5] draft-caviglia-mp2cp&cp2mp-00.txt April 2004 Fake bit set means that no actions have to be performed in the data plane, only GMPLS state information have to be deleted. At the end of the Disassociation procedure the GMPLS associated information is deleted and the LPS is moved under the NMS control. 4. RSVP Message Formats This memo does not introduce any modification in RSVP messages. 4.1 Object Modification This memo introduces a new flag into the Administrative Status object. 4.1.1 Administrative Status Object The use of the Admin_Status Object is optional. It uses Class-Number 196 (of form 11bbbbbb). The format of the Admin_Status Object is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(196)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |F|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reflect (R): 1 bit When set, indicates that the edge node SHOULD reflect the object/TLV back in the appropriate message. This bit MUST NOT be set in state change request, i.e., Notify, messages. Reserved: 28 bits This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. Testing (T): 1 bit When set, indicates that the local actions related to the "testing" mode should be taken. CavigliaExpires - September 200 [Page 6] draft-caviglia-mp2cp&cp2mp-00.txt April 2004 Administratively down (A): 1 bit When set, indicates that the local actions related to the "administratively down" state should be taken. Deletion in progress (D): 1 bit When set, indicates that that the local actions related to LSP teardown should be taken. Edge nodes may use this flag to control connection teardown. Fake signaling (F): 1 bit When set, indicates that an Association/Disassociation procedure is ongoing. 5. Security Considerations This document does not introduce any additional Security issues. For GRSVP-TE Security please refer to [3]. IANA Consideration This memo introduces a new GRSVP-TE object type and a new Error Code Error Value couple. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 Berger, L., " Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003 4 Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP- TE) Extensions", RFC 3473, January 2003. 5 Zamfir, A., " Component Link Recording and Resource Control for GMPLS Link Bundles", draft-zamfir-explicit-resource-control- bundle-03, February 2004. CavigliaExpires - September 200 [Page 7] draft-caviglia-mp2cp&cp2mp-00.txt April 2004 Author's Addresses Diego Caviglia Marconi Via A. Negrone 1/A Phone: +390106003738 Email: diego.caviglia@marconi.com Francesco Lazzeri Marconi Via A. Negrone 1/A Phone: +390106002703 Email: francesco.lazzeri@marconi.com Nicola Ciulli Consorzio Pisa Ricerche Corso Italia, 116 Phone: +39-050-915811 Email: n.ciulli@cpr.it Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. CavigliaExpires - September 200 [Page 8] draft-caviglia-mp2cp-00.txt April 2004 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. CavigliaExpires - September 2004 [Page 9]