CCAMP Working Group Rakesh Gandhi
Internet-Draft Zafar Ali
Intended status: Standards Track Gabriele Maria Galimberti
Expires: April 18, 2013 Cisco Systems, Inc.
October 15, 2012
RSVP-TE Extensions For Signaling GMPLS Restoration LSP
draft-gandhi-ccamp-gmpls-restoration-lsp-00
Abstract
Generalized Multi-Protocol Label Switching (GMPLS) RSVP-TE recovery
signaling extensions are specified in [RFC4872] and [RFC4873]. In
transport networks, there are requirements where GMPLS recovery
scheme need to employ restoration LSP while keeping resources for the
working and/ or protecting LSPs reserved in the network. Currently
GMPLS recovery procedures do not address these requirements. This
document proposes RSVP-TE extensions for GMPLS recovery with
restoration LSP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
gandhi, et al. Expires April 18, 2013 [Page 1]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5
3.1. Signaling Procedure . . . . . . . . . . . . . . . . . . . 5
3.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . . 6
3.3. Protection Switchover . . . . . . . . . . . . . . . . . . 7
3.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative references . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
gandhi, et al. Expires April 18, 2013 [Page 2]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to
include support for different switching technologies [RFC3471]
[RFC3473]. These switching technologies provide several protection
schemes [RFC4426][RFC4427] (e.g. 1+1, 1:N and M:N). GMPLS RSVP-TE
signaling has been extended to support various recovery schemes to
establish Label Switched Paths (LSPs) [RFC4872][RFC4873], typically
working LSP and protecting LSP. [RFC4427] Section 7 specifies various
schemes for GMPLS restoration.
In GMPLS recovery schemes currently considered, restoration LSP is
signaled after the failure has been detected and notified on the
working LSP. These schemes assume that working LSP is removed from
the network before restoration LSP is signaled. In transport network,
as working LSP are typically signaled over a nominal path, there are
many scenarios where service providers would like to keep resources
associated with the working LSP reserved. This is to make sure that
the service (working LSP) can use the nominal path when the failure
is repaired. Consequently, in transport networks one can employ a
recovery scheme where a new restoration LSP is signaled while working
LSP and/ or protecting LSP are not torn down in control plane due to
a failure. Restoration LSP differs from a secondary LSP in the way
that secondary LSP does not reserve resources in the data plane and
is not able to carry any traffic until it is refreshed whereas
restoration LSP does reserve resources and is able to carry traffic.
One example of the recovery scheme considered in this draft is 1:R
recovery. 1:R recovery is exemplified in Figure 1. In this example,
working LSP on path A-B-C-Z is pre-established. Typically after a
failure detection and notification on the working LSP, a second LSP
on path A-H-I-J-Z is established as a restoration LSP. Unlike
protection LSP, restoration LSP is signaled on as needed basis.
A --- B --- C --- Z
\ /
H --- I --- J
Figure 1: An example of 1:R recovery scheme
During failure, working LSP resources are not released and working
and restoration LSPs coexist in the network. Nonetheless, working and
restoration LSPs can share network resources. Typically when failure
is recovered on the working LSP, restoration LSP is no longer
required and torn down (e.g. revertive mode).
gandhi, et al. Expires April 18, 2013 [Page 3]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
Another example of the recovery scheme considered in this draft is
1+1:R. In 1+1:R, a restoration LSP is signaled for the working LSP
and/ or the protecting LSP after the failure has been detected and
notified on the working LSP or the protecting LSP. The 1+1:R recovery
is exemplified in Figure 2. In this example, working LSP on path A-B-
C-Z and protecting LSP on path A-D-E-F-Z are pre-established. After a
failure detection and notification on a working LSP or protecting
LSP, a third LSP on path A-H-I-J-Z is established as a restoration
LSP. The restoration LSP in this case provides protection against a
second order failure. Restoration LSP is torn down when the failure
on the working or protecting LSP is repaired.
D --- E --- F
/ \
A --- B --- C --- Z
\ /
H --- I --- J
Figure 2: An example of 1+1:R recovery scheme
[RFC4872] Section 14 defines PROTECTION object for GMPLS recovery
signaling. The PROTECTION object is used to identify primary and
secondary LSPs using S bit and protecting and working LSPs using P
bit. However, the PROTECTION object does not have a way to identify
restoration LSP or signal protection type for the type of recovery
considered by this document. This document defines a new flag in the
RSVP PROTECTION object [RFC4872] [RFC4873] to identify the GMPLS
restoration LSP and new LSP flags to signal LSP protection types
addressed by this draft.
2. 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 [RFC2119].
gandhi, et al. Expires April 18, 2013 [Page 4]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
3. Signaling Extensions
3.1. Signaling Procedure
The PROTECTION object [RFC4873] [RFC4872] format has been defined as
follows. A new bit named T bit is defined in this object to indicate
GMPLS restoration LSP.
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(37) | C-Type(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O|T|Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Restoration (T) : 1 bit
When set to 1, this bit indicates that the request LSP is a
restoration LSP. Working LSP is signaled with P bit set to 0 and T
bit set to 0. Protecting LSP is signaled with P set to 1 and T bit
set to 0.
When a restore LSP is signaled due to a failed protecting LSP, P
bit and T bit MUST be set to 1. When a restore LSP is signaled due
to failed working LSP, P bit is set to 0 and T bit is set to 1.
When T bit is set to 1 and S bit set 1 is permitted but usage is
outside the scope of this document.
gandhi, et al. Expires April 18, 2013 [Page 5]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
LSP (Protection Type) Flags: 6 bits
Indicates the desired end-to-end LSP protection type. Following new
values are defined in this document in addition to the ones defined
in [RFC4872].
0x20 (TBD) (Full) Rerouting with Restoration (1:R)
0x21 (TBD) 1:N:R Protection with Extra-Traffic with Restoration
0x22 (TBD) 1+1:R Unidirectional Protection with Restoration
0x23 (TBD) 1+1:R Bidirectional Protection with Restoration
The procedure for signaling all other fields in the PROTECTION object
is specified in [RFC4872] and does not change other than specified in
this section. As P bit and S bit are preserved when using restoration
LSP, LSP protection types and LSP recovery procedures defined in
[RFC4872] and [RFC4873] apply. Specifically, protection schemes
defined in [RFC4872] namely 1+1 unidirectional protection, 1+1
bidirectional protection, (full) LSP rerouting, 1:N protection with
extra-traffic do not change with the introduction of the restoration
LSP.
A GMPLS recovery scheme "Rerouting without Extra-Traffic with
Restoration LSP" is outside the scope of this document.
When using a GMPLS recovery mode, where working or protecting LSP are
destroyed, and restoration LSP assumes the role of a working LSP or a
protecting LSP, restoration LSP RSVP Path message MUST be refreshed
by clearing the T-bit in the PROTECTION object.
3.2. Resource Sharing
Resource sharing may be desired between working LSP and restoration
LSP or protecting LSP and restoration LSP. Resource sharing is
typically achieved using the make-before-break procedures defined in
[RFC3209]. It may not be desired to share resources between a working
LSP and a protecting LSP. ASSOCIATION object with association type
"resource sharing" defined in [RFC4873] is used to identify LSPs that
can share resources by matching ASSOCIATION objects in the LSPs. When
ASSOCIATION object is signaled with association type "resource
sharing", reservation style present in the LSP is ignored and for all
matching LSPs with identical ASSOCIATION objects are requested to
share resources. For LSPs with non matching ASSOCIATION object or
absence of the ASSOCIATION object, reservation style [FF/SE] present
in the LSP is used for resource sharing as per [RFC3209].
gandhi, et al. Expires April 18, 2013 [Page 6]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
3.3. Protection Switchover
Specific use case of the restoration LSP with protection switchover
is outside the scope of this document. Also, protecting switching co-
ordination (PSC) [RFC6378] mechanism is outside the scope of this
document.
3.4. Compatibility
The PROTECTION object has already been defined with class numbers in
the form 11bbbbbb, which ensures compatibility with non-supporting
nodes. Per [RFC2205], nodes not supporting this extension will ignore
the object or the new T bit and LSP flag but forward it, unexamined
and unmodified, in all messages resulting from this message.
4. IANA Considerations
IANA is requested to administer assignment of new values for
namespace defined in this document and summarized in this section.
Within the current document, one new flag is defined in the
PROTECTION object.
Value Type
----- -----
T bit (TBD) Restoration LSP Type
Within the current document, following new LSP flags are defined in
the PROTECTION object.
0x20 (TBD) (Full) Rerouting with Restoration (1:R)
0x21 (TBD) 1:N:R Protection with Extra-Traffic with Restoration
0x22 (TBD) 1+1:R Unidirectional Protection with Restoration
0x23 (TBD) 1+1:R Bidirectional Protection with Restoration
gandhi, et al. Expires April 18, 2013 [Page 7]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
5. Security Considerations
This document introduces no additional security considerations. For a
general discussion on MPLS and GMPLS related security issues, see the
MPLS/GMPLS security framework [RFC5920]. In addition, the
considerations specified in [RFC4872] and [RFC4873] will apply.
6. Acknowledgement
The authors would like to thank George Swallow for the discussion on
the GMPLS restoration.
7. References
7.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC6378] Weingarten, Y., Bryant, S. Osborne, E. Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011
gandhi, et al. Expires April 18, 2013 [Page 8]
Internet-Draft RSVP-TE Signaling for Restoration LSP October 15, 2012
7.2. Informative References
[RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors,
"Generalized Multiprotocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March 2006.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching, RFC 4427, March 2006.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Rakesh Gandhi
Cisco Systems, Inc.
Email: rgandhi@cisco.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Gabriele Maria Galimberti
Cisco Systems, Inc.
Email: ggalimbe@cisco.com
gandhi, et al. Expires April 18, 2013 [Page 9]