CCAMP Working Group Internet Draft Diego Caviglia Document: draft-caviglia-mp2cp-00.txt Marconi Francesco Lazzeri Marconi Expires: May 2004 November 2003 GRSVP-TE signaling extension to move Management created LSP to Control Plane 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 object for carrying GRSVP-TE labels, namely Mp2Cp Label object. This new object SHOULD be used in order to move under the Control Plane (CP) domain LSPs that were created by the Management Plane (MP). The result of using Mp2Cp Label in GRSVP-TE is that, at the end of the signaling flow, an LSP that was created by Management Plane is moved under to Control Plane domain. Conventions used in this document Caviglia Expires - May 2004 [Page 1] draft-caviglia-mp2cp-00.txt November 2003 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. Signaling......................................................2 3. Path Message...................................................3 3.1 Procedures.................................................3 3.2 Mp2Cp Label................................................4 3.3 PathErr....................................................4 3.4 RSVP Message Formats.......................................4 4. Security Considerations........................................5 References........................................................6 Author's Addresses................................................6 1. Introduction The usage of a GMPLS control plane in already existent network, it is foreseen to be not a green field application in the sense that MP created circuits and GMPLS created ones will coexist together. At present there is no way for a Carrier Operator that wants to associate GMPLS information to an already existent circuit to do that. A new object is proposed in this memo, namely Mp2Cp Label. This object and the associated procedures permits to associate Control Planes information to a circuit that was created by the Management Plane. The basic idea is in some way similar to Restart Procedure that uses the Recovery Label, Section 4.3 RFC 3473 [3], in the sense that the cross 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 Path message, that is, the message flow is left unmodified (Path, Resv and Resv Confirm). At the end of the signaling the LSP is totally in charge of the Control Plane. 2. Signaling Signaling uses the same messages as usual, Path, Resv and Resv Confirm, also the processing of the messages is the same but the fact Caviglia Expires - May 2004 [Page 2] draft-caviglia-mp2cp-00.txt November 2003 that in the Data Plane the cross connection are already present, only GRSVP-TE information need to be associated to them. In order to support mp2cp Label the ERO object in the Path message MUST to be filled with all the relevant information of the LSP, that is, up to the Label level. That can be done by means of the Label ERO subobject [3]. In case of unnumbered links please refer to [4]. The filling of the ERO up to the Label Level should be not a problem because the LSP already exist in the Network and the MP should have all the required information. Given the above GRSVP-TE state can be associated to the existing cross connection during the Path processing. Resv and Resv Confirm messages are processed as usual. 3. Path Message This Section covers the procedure needed to manage a Path message containing a Mp2Cp Label object. 3.1 Procedures A node receiving a Path message containing a Mp2Cp Label checks if there is a Data Plane cross connection between the resources indicated by the message. The information required in order to perform the check are carried by the Mp2Cp Label in the sender descriptor and, as usual, by the ERO Label sub-object inside the ERO object. If yes then a GRSVP-TE state is associated with the cross connection. From now on that cross connection is part of an LSP managed by the Control Plane instead of part of a connection managed by the Management Plane. If no the node performs an additional check. If both the two resources (Termination Connection Point/Connection Point in case of SONET/SDH Networks) indicated by the Path message are free then: - the cross connection in the Data Plane is performed and, - the associated GRSVP-TE state is created. If the two resources are used in a way that is different from the one indicated by the Path message then a PathErr with a particular Error Caviglia Expires - May 2004 [Page 3] draft-caviglia-mp2cp-00.txt November 2003 AdoptingFailed (Error Code and Error Value TBA) MUST be generated. AdoptingFailed indicates that the moving of an LSP from the MP to the CP has failed. Management of PathErr with AdoptingFailed error is described in the following Section. The following example illustrates the three possible cases. The cross connection to be moved under the control plane is made 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 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: a PathErr with AdoptingFailed MUST be sent Upstream. For bi-directional LSPs, the upstream label is carried as usual by the UPSTREAM_LABEL. In this case the processing is the same as described above. 3.2 Mp2Cp Label The format of a mp2cp_Label object is identical to a Generalized Label. A mp2cp_Label object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of the label being suggested. 3.3 PathErr When a node receives a PathErr with AdoptingFailed as error only the GRSVP-TE state associated to the cross connection have to be deleted but the cross connection MUST NOT be deleted. 3.4 RSVP Message Formats This section presents the RSVP message related formats as modified by Caviglia Expires - May 2004 [Page 4] draft-caviglia-mp2cp-00.txt November 2003 this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs. Unmodified formats are not listed. Again, MESSAGE_ID and related objects are defined in [5]. The format of a Path message is as follows: ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] The format of the sender description for unidirectional LSPs is: ::= [ ] [ ] [ ] [ ] [ ] The format of the sender description for bidirectional LSPs is: ::= [ ] [ ] [ ] [ ] [ ] 4. Security Considerations This document does not introduce any additional Security issues. For GRSVP-TE Security please refer to [3]. Caviglia Expires - May 2004 [Page 5] draft-caviglia-mp2cp-00.txt November 2003 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 Resource ReserVation Protocol-Traffic Engineering (RSVP- TE) Extensions", RFC 3473, January 2003. 4 Kompella, K., "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. 5 Berger, L., "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001 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 Caviglia Expires - May 2004 [Page 6] draft-caviglia-mp2cp-00.txt November 2003 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. 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. Caviglia Expires - May 2004 [Page 7]