Network Working Group Diego Caviglia IETF Internet Draft Marconi Proposed Status: Informational Expires: August 2005 Dino Bramanti Marconi Nicola Ciulli Nextworks February 2005 GRSVP-TE signaling extension for LSP ownership handover from Management Plane to Control Plane and vice versa. draft-caviglia-mp2cpcp2mp-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This memo introduces a new flag in the Administrative Status object, namely the "Handover" flag, and defines its use within GRSVP-TE signaling. This flag SHOULD be used in order to allow LSPs, originally created and controlled by the Management Plane (MP), to be transferred to Control Plane (CP) domain and vice-versa. The result Caviglia et al. Expires - August 2005 [Page 1] draft-caviglia-mp2cpcp2mp-02 February 2005 of the Handover flag use in GRSVP-TE is that, at the end of the setup signaling flow, an LSP that was created thru Management Plane operations is moved under Control Plane domain and control. Conversely, at the end of a deletion procedure, the LSP that was under the Control Plane domain is moved back to the Management Plane domain. Both the above procedure are not traffic affecting and can be performed with "in service traffic". 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. LSP Adoption/Release.............................................4 2.1 Overview.....................................................4 2.2 LSP Adoption phase: association of GMPLS information to a MP born LSP - LSP SetUp.........................................4 2.2.1 Association Procedure....................................5 2.2.2 Association Failure Handling.............................6 2.3 LSP Release phase- disassociation of GMPLS information to a MP born, CP adopted LSP - LSP Tear Down......................7 3. RSVP Message Formats.............................................7 3.1 Object Modification..........................................7 3.1.1 Administrative Status Object.............................7 4. Security Considerations..........................................8 5. IANA Considerations..............................................8 6. Normative References.............................................8 7. Informational References.........................................9 8. Acknowledgements.................................................9 9. Author's Addresses...............................................9 10. Intellectual Property Rights Notices............................9 11. Full Copyright Statement.......................................10 1. Introduction The use of a GMPLS control plane over networks that are already in service can't be considered of course as a green field application. This means that in a transport network control scenario LSPs created and owned by Management Plane and LSPs signaled and owned by means of GMPLS Control Plane have to coexist. In such a situation it is possible that a network operator wants to move to Control Plane an LSP created by and belonging to Management Plane. In a similar fashion, the opposite operation is also needed. In this memo let's Caviglia et al. Expires - August 2005 [Page 2] draft-caviglia-mp2cpcp2mp-02 February 2005 call "LSP adoption" the procedure that is aimed at moving an LSP born in Management Plane to Control Plane. Let's call "LSP release" the opposite procedure aimed at moving back the LSP from Control Plane to Management Plane. At present there is no way for a Carrier Operator that wants to associate/disassociate GMPLS information to an already existent LSP. In particular there is no way to inject LSP information and visibility from Management Plane to Control Plane (and the other way back) by means of standard G.RSVP-TE signaling flow. A new flag in the Administrative Status Object (RFC 3471[3] and RFC 3473 [4]), named Handover flag, is proposed in this memo as a mean to make possible necessary information exchange between GMPLS enabled nodes, in order to implement and support the functionality introduced above. Handover flag SHOULD be used during a signaling set-up (tear down, when performing opposite operation) and allows the association of LSP-related GMPLS information (at Control Plane level) to a circuit originated by Management Plane actions and formerly not visible and "known" to Control Plane itself. Data plane flow related to such LSP is unaware of this transfer of control from MP to CP (and back). It is worth taking into account that affected LSP may already be carrying traffic, which hasn't to be perturbed neither during MP to CP LSP handover, nor during dual CP to MP control transfer. The procedure here described is based (in case of MP to CP LSP handover, for instance) on the collection of information owned by Management Plane and related to a LSP originated in MP. This detailed information about route and resources used by the LSP is passed to Control Plane, which gets it to signal the LSP. When signaling the CP adopted LSP, Handover flag is set in order to make recognizable that signal flow and instruct GMPLS nodes about it. GMPLS nodes have to handle that LSP in such a way that, at the end of signaling, it is a full effect Control Plane owned LSP. Conversely, CP to MP migration is signaled over CP by relevant G.RSVP-TE tear down messages with Handover flag set. This is in some way similar to the Restart Procedure, (Section 4.3 RFC 3473 [4]), in the sense that the cross connection in the Data Plane are already present and it is only needed relevant GMPLS information 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. Caviglia et al. Expires - August 2005 [Page 3] draft-caviglia-mp2cpcp2mp-02 February 2005 2. LSP Adoption/Release 2.1 Overview In LSP association/release procedure here introduced, GRSVP-TE signaling messages and flow is used as normal and the processing of the messages is exactly the same as usual, except for the fact that no operation has to be performed over Data Plane. This means that the cross connection, which is assumed to be physically already in place in Data Plane, hasn't to be actually created (set-up phase)_ nor deleted (deletion phase) during signaling flow used to move LSP control from MP to CP (or CP to MP) . Such signaling messages are marked and recognizable for this purpose by Handover flag setting. When the LSP is adopted either by CP or MP, i.e. at the end of signaling with Handover flag set, normal CP procedures or MP procedures have to take their place as usual when needed. This means that a LSP originated in MP, signaled in CP with Handover flag on and hence passed to CP, can be deleted by usual and relevant Control Plane signaling flows (i.e. with Handover flag not set). The same applies when a LSP belongs to Management Plane. In other words, after those LSP handover procedures have taken place, the LSP is not different from the other LSP owned by handover destination entity, and it has to be treated with usual rules of that entity. 2.2 LSP Adoption phase: association of GMPLS information to a MP born LSP - LSP SetUp In order to support the adoption of a LSP, the ERO object in the Path message MUST be filled with all the LSP relevant information, that is, down to the Label level. That can be done by means of the object and procedures defined in [5]. The filling of the ERO down to the Label Level, including Component Link identifier when necessary, is possible as we are assuming the LSP already exists in the Network and the MP has all the associated information. Management Plane is the entity holding LSP information and passing it over to CP during adoption. Signaling set-up related to the LSP adoption contains the Handover flag of the Administrative State Object set. Upon reception of GRSVP-TE Path with Handover flagged Admin Status object, i.e. during signaling set-up, a node SHOULD associate LSP info at CP level to the existing cross connection. The information about the fact that a LSP adoption procedure is ongoing on the LSP should be maintained by the TNE until Resv Confirm message is received at the node. That information is needed in case of failures during the association set-up. Caviglia et al. Expires - August 2005 [Page 4] draft-caviglia-mp2cpcp2mp-02 February 2005 Resv and Resv Confirm messages following Path (all with Handover flag set) are processed as usual and, after Resv Confirm processing, the LSP is completely under the CP domain. This means that any memory about the fact that previously was under the MP is lost. Failures during the Adoption of an LSP are managed as usual, except 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. 2.2.1 Association Procedure This Section covers the procedure needed to manage a LSP Adoption procedure, that is, a GRSVP-TE signaling set-up where Path message contain an Administrative Status object with the Handover flag set. In the following the adoption of a bidirectional LSP is taken into consideration. The case of unidirectional LSP can be easily derived from that. A node receiving a Path message containing an Administrative Status object with the Handover flag set is informed about the fact that a LSP adoption procedure is ongoing. The node assumes that a Data Plane connection related to the info carried in Path Message is already in place. The node SHOULD check however if there is an actual Data Plane cross connection between the resources indicated by the message: - If yes then a GRSVP-TE state is associated with the cross connection and relevant CP data structures of LSP are created. - If no, that is the resources are used in a way that is different from the one indicated by the Path message then: o a PathErr with Path State Removed flag set should be generated o GMPLS state information is deleted but actual cross-connection in the data plane are not. In order to be able to cope with a failure during described procedure, the information about the fact that the ongoing signaling flow is concerning an LSP adoption is maintained by the TNE until the receipt of the Resv Confirm. In such a way Management Plane holds LSP related info until Handover flagged signaling session has successfully ended. The following example illustrates the possible Adoption cases either successful or failed. Caviglia et al. Expires - August 2005 [Page 5] draft-caviglia-mp2cpcp2mp-02 February 2005 The cross connection to be moved under the control plane involves Timeslot A and B. This means that Handover flagged signaling refers to A-B xconnection over Data Plane. The symbol <----> means that the two Timeslots are actually cross connected over Data Plane. | Data Plane| Control Plane| Management Plane| Notes --------------------------------------------------------------------- Case 1 | A<---->B | No info yet | LSP info present| OK for MP to CP | | | | LSP handover --------------------------------------------------------------------- Case 2 | A<---->C | No info yet | LSP info present| NOK for MP to | CP LSP handover --------------------------------------------------------------------- Case 1: - LSP info in Management Plane is present and describes A-B connection. - LSP is not visible yet over Control Plane. - A-B connection is actually present over Data Plane. - GRSVP-TE state (related to involved LSP) is associated to the cross connection after Handover flagged signaling flow (Path/Resv/resvConfirm with Handover flag set). - No actions are taken in the Data Plane. - At the end LSP is completely under CP control. Case 2: - LSP info in Management Plane is present and describes A-B connection. - LSP is not visible yet over Control Plane. - A-B connection is not actually present over Data Plane and relevant resources are used within other context (A is x-connected to C). - GRSVP-TE state (related to involved LSP) is not associated to the cross connection after Handover flagged signaling flow. - A PathErr with Path State Removed flag set should be sent Upstream. - No actions are taken in the Data Plane. - At the end LSP stays completely under MP control as before. 2.2.2 Association Failure Handling When a node receives a PathErr with Path State Removed checks if the LSP it refers to is involved in an Adoption procedure, whose track is kept until successful end of signaling flow has been carried on as stated above. If yes, then no actions are performed over the data plane, while GMPLS status information about involved LSP over Control Plane is deleted and the cross connection ownership is moved back under the NMS controls. Caviglia et al. Expires - August 2005 [Page 6] draft-caviglia-mp2cpcp2mp-02 February 2005 The same applies for PathTear message. 2.3 LSP Release phase- disassociation of GMPLS information to a MP born, CP adopted LSP - LSP Tear Down This Section covers the procedure needed to manage a LSP Release procedure (as a dual, opposite procedure respect to Adoption described above). Such a procedure is performed at a signaling level as described in Section 7.2.1 of the RFC 3473 [4]. LSP tear down flow is carried on as usual, except that Handover flag is set in Administrative Status Object like it was during set-up (adoption) case. Nodes receiving G.RSVP-TE tear down messages with Handover flag set, have to process such messages as usual, but they have to behave in a special way respect to Data Plane. As a perfect dual situation of the Adoption described before, no actions at all have to be performed over the data plane. This means that the node has to carry on tear down signaling procedure but it SHOULD NOT clear x-connection related to affected LSP. As a consequence of the Release 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. 3. RSVP Message Formats This memo does not introduce any modification in RSVP messages. 3.1 Object Modification This memo introduces a new flag into the Administrative Status object. 3.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 |H|L|I|C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Caviglia et al. Expires - August 2005 [Page 7] draft-caviglia-mp2cpcp2mp-02 February 2005 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. Handover signaling (H): 1 bit When set, indicates that an Association/Disassociation procedure is ongoing. The other flag are defined in the following documents: R-bit [RFC3471] L-bit [E2E] I-bit [ALARM] C-bit [ASON] T-bit [RFC3471] A-bit [RFC3471] D-bit [RFC3471] Where: [RFC3471] RFC3471 [E2E] draft-ietf-ccamp-gmpls-recovery-e2e-signaling [ALARM] draft-ietf-ccamp-gmpls-alarm-spec [ASON] draft-ietf-ccamp-gmpls-rsvp-te-ason 4. Security Considerations This document does not introduce any additional Security issues. For GRSVP-TE Security please refer to [3]. 5. IANA Consideration This memo introduces a new GRSVP-TE object type and a new Error Code Error Value couple. 6. Normative 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. Caviglia et al. Expires - August 2005 [Page 8] draft-caviglia-mp2cpcp2mp-02 February 2005 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. 7. Informational References 5 Zamfir, A., " Component Link Recording and Resource Control for GMPLS Link Bundles", draft-zamfir-explicit-resource-control-bundle-03, February 2004. 8. Acknowledgements Adrian Farrel provided editorial assistance to prepare this draft for publication. 9. Author's Addresses Diego Caviglia Marconi Via A. Negrone 1/A Phone: +390106003738 Email: diego.caviglia@marconi.com Dino Bramanti Marconi Via Moruzzi 1 C/O Area Ricerca CNR, Pisa Email: dino.bramanti@marconi.com Nicola Ciulli Nextworks Corso Italia n. 116, 56125 Pisa (Italy) Email: n.ciulli@nextworks.it 10. Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Caviglia et al. Expires - August 2005 [Page 9] draft-caviglia-mp2cpcp2mp-02 February 2005 Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 11. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 et al. Expires - August 2005 [Page 10]