One document matched: draft-takacs-ccamp-revertive-ps-00.txt
Network Working Group A. Takacs
Internet-Draft B. Tremblay
Intended status: Standards Track Ericsson
Expires: January 8, 2009 July 7, 2008
GMPLS RSVP-TE recovery extension for data plane initiated reversion
draft-takacs-ccamp-revertive-ps-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Takacs & Tremblay Expires January 8, 2009 [Page 1]
Internet-Draft GMPLS revertive protection signalling July 2008
Abstract
RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873].
Currently these extensions cannot signal request for revertive
protection to the remote endpoint. This document defines a new bit
to signal this request and a new field to specify a wait-to-restore
interval.
Takacs & Tremblay Expires January 8, 2009 [Page 2]
Internet-Draft GMPLS revertive protection signalling July 2008
Requirements Language
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
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. PROTECTION object extension . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Takacs & Tremblay Expires January 8, 2009 [Page 3]
Internet-Draft GMPLS revertive protection signalling July 2008
1. Introduction
Reversion refers to the process of moving normal traffic back to the
original working LSP after the failure is cleared and the path is
repaired [RFC4426][RFC4427][RFC4872]. Reversion is desirable since
the protection path may not be optimal from a routing and resource
consumption point of view, additionally, moving traffic back to the
working LSP allows the protection resources to be used to protect
other LSPs. On the other hand, reversion requires that the working
resources remain allocated during failure. The operator needs to
have the choice between revertive and non-revertive protection to
balance the pros and cons in a given situation.
[RFC4426] and [RFC4872] describes control plane signalling procedures
for reversion. This signaling can be used to initiate the actual
reversion in the data plane; or simply to synchronise control plane
states after data plane actions. This latter case, when
independently from the control plane, data plane mechanisms
autonomously initiate reversion is not detailed further in the
documents.
[RFC4426] and [RFC4872] assumed that signalling the revertive
property of protection is not needed between protection endpoints.
This assumption holds for uni- and bidirectional LSPs in the
following cases.
o The control plane is responsible to execute reversion and trigger
data plane switch-over.
o In the case of data plane initiated reversion there is a dedicated
protocol for protection switching (e.g., Automatic Protection
Switching (APS)) synchronising the switch-over of the data plane
endpoints.
In these cases, only one side: the ingress LER needs to be provided
with information about the revertive property of protection. Hence,
there is no need to signal any information in RSVP-TE to the remote
endpoint.
However, GMPLS may be applied in a scenario where the data plane
autonomously executes reversion but it has no mechanism to
communicate the revertive property of protection between the
endpoints. Such an example is protection switching of bidirectional
connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under
standardisation in IEEE). In this case revertiveness needs to be
signalled by RSVP-TE during LSP establishment to properly setup the
remote data plane endpoint. Further, although wait-to-restore (WTR)
intervals may be pre-configured, it may be beneficial to signal the
Takacs & Tremblay Expires January 8, 2009 [Page 4]
Internet-Draft GMPLS revertive protection signalling July 2008
desired WTR value as well.
Takacs & Tremblay Expires January 8, 2009 [Page 5]
Internet-Draft GMPLS revertive protection signalling July 2008
2. PROTECTION object extension
In [RFC4872] and [RFC4873] the PROTECTION object is specified to
support end-to-end and segment recovery. This document introduces a
new bit: "V" Revertive; to signal that the protection requested is to
be revertive. The "V" bit can only be set if the "N" Notification is
set as well. Once the data plane autonomously initiated reversion,
it notifies the control plane which then can invoke the signalling
specified in [RFC4872] to syncronise control plane LSP states to
reflect the actual path taken by normal traffic.
In order that traffic is not switched back and fort between worker
and protection LSPs during transients, a wait to restore (WTR) timer
is usually applied delaying the reversion until the recovered path is
considered stable again. To support autonomous data plane recovery,
the wait to restore time can be signalled in the new WTR field. The
WTR field defines the wait to restore delay in minutes. The
additions to the PROTECTION object are depicted below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O|V| Reserved| LSP Flags | Reserved | WTR | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V - Revertive bit, when set the protection is to be revertive, and if
supported the data plane should be configured to autonomously execute
reversion.
WTR - Wait to Restore, it specifies the WTR delay before reversion in
minutes.
Takacs & Tremblay Expires January 8, 2009 [Page 6]
Internet-Draft GMPLS revertive protection signalling July 2008
3. IANA Considerations
This document specifies a new bit "V" and a new field "WTR" to be
carried in the PROTECTION object.
Takacs & Tremblay Expires January 8, 2009 [Page 7]
Internet-Draft GMPLS revertive protection signalling July 2008
4. Security Considerations
This document introduces no new security issues. The considerations
in [RFC4872] and [RFC4873] apply.
Takacs & Tremblay Expires January 8, 2009 [Page 8]
Internet-Draft GMPLS revertive protection signalling July 2008
5. References
[IEEE-PBBTE]
"IEEE 802.1Qay Draft Standard for Provider Backbone
Bridging Traffic Engineering", work in progress.
[RFC4426] "Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March 2006.
[RFC4427] "Recovery (Protection and Restoration) Terminology for
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4427, March 2006.
[RFC4872] "RSVP-TE Extensions in Support of End-to-End Generalized
Multi-Protocol Label Switching (GMPLS) Recovery",
RFC 4872, May 2007.
[RFC4873] "GMPLS Segment Recovery", RFC 4873, May 2007.
Takacs & Tremblay Expires January 8, 2009 [Page 9]
Internet-Draft GMPLS revertive protection signalling July 2008
Authors' Addresses
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: attila.takacs@ericsson.com
Benoit Tremblay
Ericsson
8400 Decarie.
Montreal, Quebec H4P 2N2
Canada
Email: benoit.c.tremblay@ericsson.com
Takacs & Tremblay Expires January 8, 2009 [Page 10]
Internet-Draft GMPLS revertive protection signalling July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Intellectual Property
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.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Takacs & Tremblay Expires January 8, 2009 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 16:02:34 |