Internet DRAFT - draft-wright-ccamp-op-policy-prot-links
draft-wright-ccamp-op-policy-prot-links
Internet Engineering Task Force B. Wright, Ed.
Internet-Draft J. Hardwick
Intended status: Informational Metaswitch Networks
Expires: December 03, 2013 V. Shukla
Verizon
J. Li
China Telecom Beijing Research Institute
June 2013
Requirements for operator policy in GMPLS networks consisting of
protected links
draft-wright-ccamp-op-policy-prot-links-00
Abstract
This document describes policy options required by network operators
in networks including APS links or links with an inherent protection
capability. It also identifies gaps in the current GMPLS standards
which may prevent these policy options from being implemented.
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 December 03, 2013.
Copyright Notice
Copyright (c) 2013 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
Wright, et al. Expires December 03, 2013 [Page 1]
Internet-Draft draft-wright-ccamp-op-policy-prot-links-00 June 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Protected Links . . . . . . . . . . . . . . . . . . . . . . . 2
3. Operator requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. Operational considerations . . . . . . . . . . . . . . . 4
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
As described in [RFC4202], GMPLS networks frequently contain links
which have an inherent protection capability, for example SONET APS
links or abstract links which represent a bundle of lower layer LSPs.
An operator may wish to configure different policies which, in the
event of a failure that causes a change in the available protection
capability of a link, affect both path computation and provisioned
services. This draft describes some of these policy behaviors, and
identifies where these behaviours cannot be implemented using
existing GMPLS standards.
1.1. 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 RFC 2119 [RFC2119].
2. Protected Links
A link can be said to have an inherent protection capability if, in
the event of a data plane failure affecting some part of the link,
the link can continue to carry data. We call links which have an
inherent protection capability "Protected Links". Figure 1 below
shows an example of a Protected Link.
Wright, et al. Expires December 03, 2013 [Page 2]
Internet-Draft draft-wright-ccamp-op-policy-prot-links-00 June 2013
Logical Protected Link
|
+--------+ v +--------+
| |====================| |
| NE A | | NE B |
| |--------------------| |
| |--------------------| |
+--------+ ^ +--------+
|
Lower Layer LSPs providing protection
Figure 1: Diagram showing an example of a protected link
In this example, a bundle of LSPs transport data between the two
network elements, as described in [RFC4201]. These LSPs are
advertised as a single link into the client layer IGP. A protection
scheme (such as 1+1, as described in [RFC4427]) can be configured for
the link bundle to ensure that if one link in the bundle fails,
traffic will be unaffected because other links in the bundle carry
the data. Hence the link in the client layer has its own protection
capabilities, which it can advertise as per [RFC4202]. However,
failures of lower-layer LSPs can mean that, whilst the overall link
bundle is still able to carry traffic, the protection capabilities
that are still configured, are no longer present. Such links are
referred to as "Protection Impaired".
3. Operator requirements
Operators have the following requirements which SHOULD be met in
networks containing Protection Impaired links.
R1. It SHOULD be possible to include or exclude a Protection
Impaired link from a path computed for an LSP, depending on the
type of service that will use the LSP. For example, an operator's
policy may allow LSPs corresponding to high priority unprotected
services to be provisioned over the Protection-Impaired Link, but
prevent lower priority LSPs from using it (because once the
failure has been repaired, bandwidth on a high-value protected
link would be used for low-priority LSPs).
R2. Depending on the service-level of a given LSP, it SHOULD be
possible to configure a policy to reroute an existing LSP when a
link it traverses becomes Protection Impaired (for example, if
there are other links available which still have currently active
protection capabilities). If the fault is repaired, then it
SHOULD be possible to automatically revert the LSP to the original
path.
Wright, et al. Expires December 03, 2013 [Page 3]
Internet-Draft draft-wright-ccamp-op-policy-prot-links-00 June 2013
3.1. Operational considerations
It is often advantageous to centralize policy configuration on as few
network elements as possible. This makes network-wide policy changes
easier to implement for operators. For example, in networks where
Path Computation is performed by only a subset of the network
elements (e.g. PCEs), it is preferable that the policy configuration
relating to Path Computation is applied solely to those network
elements.
4. Gap Analysis
An analysis of the current GMPLS protocols against the above
requirements is as follows.
R1. As per [RFC4202], the current link protection type can be
advertised by the OSPF-TE or ISIS-TE protocols so elements performing
Path Computation can understand the currently available protection
type. Per-Network Element level policy can determine the how the
protection type is set when the link is advertised. However, there
is no way currently to advertise both the configured link protection
type and the current link protection type. Therefore, it is not
possible to implement the Path Computation behavior described above
if a different policy is required for different LSPs.
R2. A node which detects a failure MAY use the procedures defined in
[RFC5712] to inform the head-end LSR. The head-end LSR MAY then
elect to use this as a trigger to perform Path Computation to
determine whether an alternative route exists and possibly re-route
the LSP. However, there is no similar mechanism to inform the head-
end LSR when a failure has been cleared.
5. Contributors
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Wright, et al. Expires December 03, 2013 [Page 4]
Internet-Draft draft-wright-ccamp-op-policy-prot-links-00 June 2013
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC5712] Meyer, M. and JP. Vasseur, "MPLS Traffic Engineering Soft
Preemption", RFC 5712, January 2010.
8.2. Informative References
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and
subnetwork protection", Recommendation G.808.1, December
2003.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", draft-narten-iana-
considerations-rfc2434bis-09 (work in progress), March
2008.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
Authors' Addresses
Ben Wright (editor)
Metaswitch Networks
100 Church Street
Enfield, Middlesex
UK
Phone: +44 2083661177
Email: ben.wright@metaswitch.com
Wright, et al. Expires December 03, 2013 [Page 5]
Internet-Draft draft-wright-ccamp-op-policy-prot-links-00 June 2013
Jon Hardwick
Metaswitch Networks
100 Church Street
Enfield, Middlesex
UK
Phone: +44 2083661177
Email: jon.hardwick@metaswitch.com
Vishnu Shukla
Verizon
60 Sylvan Road
Waltham, MA 02451
USA
Email: vishnu.shukla@verizon.com
Junjie Li
China Telecom Beijing Research Institute
118 Xizhimenneidajie
Xicheng, Beijing
China
Email: lijj@ctbri.com.cn
Wright, et al. Expires December 03, 2013 [Page 6]
