]> Requirements for operator policy in GMPLS networks consisting of protected links Metaswitch Networks
100 Church Street Enfield Middlesex UK +44 2083661177 ben.wright@metaswitch.com
Metaswitch Networks
100 Church Street Enfield Middlesex UK +44 2083661177 jon.hardwick@metaswitch.com
Verizon
60 Sylvan Road Waltham MA 02451 USA vishnu.shukla@verizon.com
China Telecom Beijing Research Institute
118 Xizhimenneidajie Xicheng Beijing China lijj@ctbri.com.cn
General Internet Engineering Task Force template 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.
As described in , 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.
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.
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.
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 ) 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".
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.
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.
An analysis of the current GMPLS protocols against the above requirements is as follows. R1. As per , 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 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.
This memo includes no request to IANA.
TBD
Writing I-Ds and RFCs using XML Invisible Worlds, Inc.
660 York Street San Francisco CA 94110 US +1 415 695 3975 mrose@not.invisible.net http://invisible.net/
General RFC Request for Comments I-D Internet-Draft XML Extensible Markup Language This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. Guidelines for Writing RFC Text on Security Considerations All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned, or when modifications to existing values can be made. If IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. Contents Status of this Memo.......................................... 1 Generic Protection Switching - Linear trail and subnetwork protection ITU-T ""