Internet DRAFT - draft-roch-ccamp-combined-recovery-reqts
draft-roch-ccamp-combined-recovery-reqts
Network Working Group Evelyne Roch
Internet Draft Lyndon Ong
Intended status: Informational Ciena
March 5, 2012
Requirements for Combined Protection and Restoration
draft-roch-ccamp-combined-recovery-reqts-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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 September 5, 2012.
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
(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.
Abstract
Roch Expires September 5, 2012 [Page 1]
Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012
This Internet-Draft proposes requirements for combinations of
rerouting and protection schemes that are of interest to carrier
networks.
Table of Contents
1. Introduction and Problem Statement.............................2
2. Maintenance operations of protected services...................2
3. Combined restoration and protection schemes....................4
3.1. Second Level Restoration..................................4
3.2. Always on protection......................................5
4. Security Considerations........................................6
5. IANA Considerations............................................6
6. Acknowledgments................................................7
1. Introduction and Problem Statement
Combination of protection and rerouting mechanisms allow carriers
to:
- Perform maintenance activities on the protected/protection LSPs
while maintaining the protection.
- Offer services with higher availability by automatically combining
restoration and protection schemes.
This document defines use cases for the combination of protection
and rerouting mechanisms that are of interest to carriers that could
be candidates for support in GMPLS.
2. Maintenance operations of protected services
The first area to consider is the combination of maintenance
activities with the protection and restoration schemes. For example,
it is possible to perform maintenance operation on one of the legs
of a 1+1 connection but the operator may want to maintain the 1+1
protection during the maintenance activity. Temporarily or
permanently rerouting the traffic of one of the legs for maintenance
purposes requires proper support in the signaling procedures.
The requirement is to support up to 3 related LSPs that have
resources reserved but of which at most 2 are instantiated end-to-
end in the data plane.
Consider the following network topology:
Roch Expires September 5, 2012 [Page 2]
Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012
B --- C --- D
/ \
A --- E --- F --- Z
\ /
G --- H --- I
The detailed signaling scenario for rerouting is as follows:
- Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z)
LSPs are both established and neither of them has a failure
condition.
- A third LSP (A-G-H-I) is established with resources reserved and
established on nodes G, H and I but reserved only at nodes A and
Z.
- The LSP that is put under maintenance is de-activated by keeping
the resources reserved but no established at nodes A and Z while
maintaining resources reserved and established at nodes B, C and
D if maintenance is applied to working LSP or nodes E and F if
maintenance is applied to protecting LSP.
- The maintenance LSP is activated by establishing the resources
for the maintenance LSP at nodes A and Z.
- At this stage, if this is a permanent reroute operation, the
original working or protecting LSP is torn down. Otherwise, the
LSP is maintained for reversion at a later stage.
The reversion stage:
- The maintenance LSP is deactivated by de-establishing the
resources for the maintenance LSP at nodes A and Z.
- The original LSP (working or protecting) is activated at nodes A
and Z by establishing resources (working or protecting) at nodes
A and Z.
- The maintenance LSP is torn down.
Roch Expires September 5, 2012 [Page 3]
Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012
3. Combined restoration and protection schemes
In order to provide higher reliability, some service levels may
combine restoration and protection. Two combinations that are useful
to operators are included here. These combinations may require more
than two LSPs to be associated together in case of make-before-break
or when reversion is desired. Signaling extensions that support
combined protection and restoration are required by identifying the
type of recovery as a combination of protection (e.g. 1+1 bi-
directional) and restoration types (e.g. full rerouting). The
signaling extensions should also provide an indication of the
relationship between the two mechanisms to distinguish the following
scenarios:
- Second level restoration: offers protection against dual failures
in the case of protected services. It offers the option to
restore the LSP if both working and protection LSPs fail.
- Always on protection: offers the assurance of fast protection
even after a failure by restoring the failed leg of a protected
service.
3.1. Second Level Restoration
The requirement is to support up to 3 related LSPs that have
resources reserved but of which at most 2 are instantiated end-to-
end in the data plane. When both the working and protecting LSPs are
under failure condition, this triggers restoration.
Consider the following network topology:
B --- C --- D
/ \
A --- E --- F --- Z
\ /
G --- H --- I
The detailed signaling scenario for rerouting is as follows:
- Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z)
LSPs are both established and both are under failure condition.
Roch Expires September 5, 2012 [Page 4]
Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012
- One of the original LSPs (working or protecting), as determined
by the head-end local policy is deactivated at the A and Z nodes
while maintaining the resources reserved.
- A restoration LSP (A-G-H-I) is established with resources
reserved and established.
- At this stage, if this is non-revertive restoration, the original
working or protecting LSP is torn down. Otherwise, the LSP is
maintained for reversion at a later stage.
The reversion stage:
- The restoration LSP is deactivated by de-establishing the
resources for the restoration LSP at nodes A and Z.
- The original LSP (working or protecting) is activated at nodes A
and Z by establishing resources (working or protecting) at nodes
A and Z.
- The restoration LSP is torn down.
3.2. Always on protection
The requirement is to support up to 4 related LSPs that have
resources reserved but of which at most 2 are instantiated end-to-
end in the data plane. When one of the working or protecting LSPs is
under failure condition, this triggers restoration of that LSP.
Consider the following network topology:
B --- C --- D
/ \
A --- E --- F --- Z
\ \ / /
\ G --- H --- I /
\ /
J ------- L
The detailed signaling scenario for rerouting is as follows:
Roch Expires September 5, 2012 [Page 5]
Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012
- Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z)
LSPs are both established and at least one is under failure
condition. For the purpose of this example, let's assume working
has failed.
- The failed LSP (working in this example), is deactivated at the A
and Z nodes while maintaining the resources reserved.
- A restoration working LSP (A-G-H-I) is established with resources
reserved and established.
- At this stage, we have 3 LSPs that are associated but only 2 are
established end-to-end in the data plane. If this is a non-
revertive restoration, the working LSP (A-B-C-D-Z) is torn down.
Otherwise, it is maintained until reversion.
- If the second original LSP also fails (protecting LSP in this
example), it is also deactivated at the A and Z nodes while
maintaining the resources reserved and a restoration protecting
LSP (A-J-L-Z) is established with resources reserved and
established. Similarly to the previous bullet, if this is a non-
revertive restoration, the protecting LSP is torn down.
Otherwise, it is maintained until reversion.
The reversion stage:
- The working or protecting restoration LSP is deactivated by de-
establishing the resources for the restoration LSP at nodes A and
Z.
- The original LSP (working or protecting) is activated at nodes A
and Z by establishing resources (working or protecting) at nodes
A and Z.
- The working or protecting restoration LSP is torn down.
4. Security Considerations
None identified at this time
5. IANA Considerations
None identified at this time
Roch Expires September 5, 2012 [Page 6]
Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012
6. Acknowledgments
The authors would like to thank members of the OIF Network & Operations
WG and the CCAMP co-chairs for their comments and suggestions to this
document.
Roch Expires September 5, 2012 [Page 7]
Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012
Authors' Addresses
Evelyne Roch
Ciena
Email: eroch@ciena.com
Lyndon Ong
Ciena
Email: lyong@ciena.com
Roch Expires September 5, 2012 [Page 8]
