Internet DRAFT - draft-caviglia-mp2cp
draft-caviglia-mp2cp
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:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...
]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender description for unidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
[ <MP2CP LABEL> ]
The format of the sender description for bidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
[ <MP2CP LABEL> ]
<UPSTREAM_LABEL>
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]
