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.

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.
[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

[RFC2629]	Rose, M.T., "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.
[I-D.narten-iana-considerations-rfc2434bis]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet-Draft draft-narten-iana-considerations-rfc2434bis-09, March 2008.
[G.808.1]	, , "Generic Protection Switching - Linear trail and subnetwork protection", Recommendation G.808.1, December 2003.

Authors' Addresses