| Network Working Group | J. Dong |
| Internet-Draft | M. Chen |
| Intended status: Standards Track | Huawei Technologies |
| Expires: April 27, 2012 | C. . Villamizar |
| OCCNC, LLC | |
| October 25, 2011 |
MPLS-TE Fast Reroute Resource Classification
draft-dong-mpls-frr-resource-class-00
This document describes simple and backward compatible extensions to Fast-Reroute (FRR) MPLS Traffic Engineering (TE). The purpose of these extensions include the following. These extensions provide a classification of SRLG to support LSP with differing protection requirements. These extensions allow highly reliable nodes or links, typically resources with redundancy at a lower layer, to be identified to allow LSP to optionally not consider these resources as potential points of failure.
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].
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 27, 2012.
Copyright (c) 2011 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.
MPLS Traffic Engineering (TE) Fast Reroute (FRR) [RFC4090] is widely used for protecting MPLS-TE LSPs from local failures. TE FRR implementations today can consistently achieve redirection of traffic from a single resource failure to other local resources in 10s of milliseconds. TE FRR can therefore provide high availability for service carried on the TE LSP.
The existing TE FRR defines several protection and switching modes which are designed to apply to a all protected LSP regardless of what kind of availability is required by the service. Protection must accomodate the most strict protection requirements of any service carried, even though protection of low probability failures are not appropriate for other services. Where this occurs, the result can be greater requirements for network resources and higher network costs.
This document first describes the flexibility limitations in existing TE FRR that are addressed and then proposes a flexible TE FRR mechanism to address them.
MPLS-TE LSPs may be used to carry services which require different levels of availability. MPLS-TE FRR mechanism defined in [RFC4090] can only provide the same local protection level for LSPs regardless of the availability requirement of the services.
In some cases network nodes with sufficient internal redundancy mechanisms could be considered sufficiently immune to node failures for most services. Similarly, some links could also be considered sufficiently redundant for most services. Examples of reliable links are link bundle and multipath links that do not use common media, such as parallel physical links deployed within a provider facility. Thus for most services such nodes and links could be considered sufficiently reliable that they do not need be protected at LSP level.
A subset of LSP may require extremely high availability. Commonly cited examples include communications among emergency first responders (police, fire, etc) and application for which loss of connectivity may result in large financial losses (financial services, e-commerce, trading). These services may require protection against Shared Risk Link Group (SRLG) which would be expected to cause failure in extremely rare circumstances. This same high level of protection is unnecessary for most services.
In order to provide different levels of local protection for different kinds of services, a more flexible TE FRR mechanism is required. Resource classes and resource class affinity are proposed to address this.
To support different levels of local protection, a classification of node and link reliability is defined. This information is carried in the TE link state database (TED). A classification may be associated with a node, a link, or an SRLG. Extensions are defined for OSPF-TE and ISIS-TE.
To support a decision at the point of local repair (PLR), an extension is defined for RSVP-TE. The requirements of a specific LSP is defined in the RSVP-TE PATH message. The requirements are expressed as changes from a default behavior.
Signaling can be reduced by configuring a default behavior at potential PLR. If the majority of services do not requirement protection from relatively reliable nodes and/or links, setting configured defaults to this behavior allows a small reduction in the size of RSVP-TE PATH messages.
Using a new TLV to define SRLG which are disabled by default can improve backward compatibility with respect to legacy PLR in cases where it is preferred that these legacy PLR ignore these low probability SRLG for all LSP. Using the SRLG extensions understood by the legacy PLR allows these PLR to consider low probability SRLG for all LSP, with extension affecting only the PLR implementing this specification.
Legacy PLR will ignore distinctions between relatively reliable nodes or links and low probability SRLG and those which are relatively unreliable. These PLR may choose protection paths which error on the side of providing more protection for some services than is required. At worst, this has an impact on network cost, but still would represent a lower cost than if the extensions were unavailable at all nodes.
SRLG can be defined such that legacy PLR either always consider the SRLG or always ignore the SRLG. Only the PLR implementing this specification will be able to selectively apply classes of SRLG on a per LSP basis.
Legacy Ingress will not provide any extensions which allow LSP to be treated differently from the default. In a brownfield installation the defaults can be set to provide the level of protection that had been available. Extensions can then be used by LSR implementing this specification to indicate LSP which require some protection, but less than this default, or more protection than this default.
This document defines the following extensions.
The reliability of a node is specified using a Node Reliability sub-TLV of the Node Attribute TLV [RFC5786]. Length of this sub-TLV is variable. The format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Node Classification Bit Map |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero or more SRNG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type code is TBA for Node Reliability sub-TLV.
The length field is set to four plus the number of SRNG included time the size of an SRNG.
The Flags field is reserved for future use.
The 3 octet Node Classification Bit Map is a bit map which may be used by operator to specify inclusion of the node in a set of operator defined classifications.
The format of SRNG is common to OSPF and ISIS and is defined in Section 5.5
The reliability of link is specified using a Link Reliability sub-TLV of the Link TLV [RFC3630]. Length of this sub-TLV is variable. The format is as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Link Classification Bit Map |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero or more Extended SRLG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Flags field is reserved for future use.
The 3 octet Link Classification Bit Map is a bit map which may be used by operator to specify inclusion of the link in a set of operator defined classifications.
The format of Extended SRLG is common to OSPF and ISIS and is defined in Section 5.5
The reliability of node is specified using a Node Reliability TLV with TLV Type TBA. Length of this TLV is variable. The format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Node Classification Bit Map |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero or more SRNG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Flags field is reserved for future use.
The 3 octet Node Classification Bit Map is a bit map which may be used by operator to specify inclusion of the node in a set of operator defined classifications.
The format of SRNG is common to OSPF and ISIS and is defined in Section 5.5
The reliability of link is specified using a Link Reliability sub-TLV of the TLV 22 [RFC5305]. Length of this sub-TLV is variable. The format is as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Link Classification Bit Map |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero or more Extended SRLG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Flags field is reserved for future use.
The 3 octet Link Classification Bit Map is a bit map which may be used by operator to specify inclusion of the link in a set of operator defined classifications.
The format of Extended SRLG is common to OSPF and ISIS and is defined in Section 5.5
The Shared Risk Node Group (SRNG) is carried within either the OSPF Node Reliability sub-TLV (see Section 5.1) or the IS-IS Node Reliability TLV (see Section 5.3). The SRNG is 8 bytes. The format is as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Node Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | SRNG Classification Bit Map |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Shared Risk Node Group Number (SRLG) is a 32 bit number used to specify the inclusion of the node within a set of nodes which share a common resource that therefore can be expected to fail simultaneously if that resource becomes unavailable. The SRLG is a operator assigned number which identified the resource.
The Flags field is reserved for future use.
The 3 octet SRNG Classification Bit Map is a bit map which may be used by operator to specify inclusion of the SRNG in a set of operator defined classifications.
The Extended Shared Risk Link Group (ESRLG) is carried within either the OSPF Link Reliability sub-TLV (see Section 5.2) or the IS-IS Link Reliability TLV (see Section 5.4). The ESRLG is 8 bytes. The format is as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Shared Risk Link Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | SRLG Classification Bit Map |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Extended Shared Risk Link Group Number (ESRLG) is a 32 bit number used to specify the inclusion of the link within a set of links which share a common resource that therefore can be expected to fail simultaneously if that resource becomes unavailable. The SRLG is a operator assigned number which identified the resource.
The Flags field is reserved for future use.
The 3 octet SRLG Classification Bit Map is a bit map which may be used by operator to specify inclusion of the SRLG in a set of operator defined classifications.
The Extended Shared Risk Link Group Number (ESRLG) may be given the same number as an advertised SRLG when the desired behavior for legacy PLR is to have the legacy PLR always protect against failure of the ESRLG. If the desired behavior for legacy PLR is to have the legacy PLR never protect against failure of the ESRLG, then the ESRLG number must not conflict with an SRLG number.
The Resource Attribute Bit Mask is defined in LSP_ATRTRIBUTE Object. The LSP_ATRTRIBUTE is defined in [RFC3209] and updated in [RFC5420]. The format of the Resource Attribute Bit Mask is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP| Ap| Resv | Resource Attribute Bit Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 2 bit Operation field (OP) specifies one of the following operations. The following values are defined for the Operation field.
The 2 bit Apply field (Ap) is a bit map which indicates which context the bit mask is applied to. The following values are defined for the Apply field.
The 3 octet Resource Attribute Bit Mask is a bit mask applied to the 2 octet resource classifications specified for nodes, links, SRNG, or ESRLG. The Apply field indicates which type of resource classification to apply the mask to. The Operation field indicates what action to take as a result of the mask operation.
The Node Reliability (see ) and Link Reliability (see ) are assigned to nodes and links according to configuration on the LSR advertising the containing TLV. The Resource Attribute Bit Mask is assigned according to configuration on the ingress LSR for a given LSP.
The action taken at a PLR for a given LSP are as follows.
If no protection is required, as indicated by the "protection desired" bit in the RSVP-TE Flags SESSION_ATTRIBUTE [RFC3209] not being set, then no protection path is created at a potential PLR. This behavior is unchanged.
If link disjoint protection if required, as indicated by the "protection desired" bit set and the "Node protection desired" bit not set [RFC4090], then the protection path must be disjoint with respect to all links and SRLG, except those ESRLG added or links or SRLG removed as a result of applying the Resource Attribute Bit Masks for the LSP.
If node disjoint protection if required, as indicated by the "protection desired" bit set and the "Node protection desired" bit set, then the protection path must be disjoint with respect to all nodes, links, and SRLG, except SRNG or ESRLG added or nodes, links or SRLG removed as a result of applying the Resource Attribute Bit Masks for the LSP.
The action taken in the absense of any Resource Attribute Bit Masks in all cases is identical to the action that would be taken by a legacy PLR. Inclusion of one or more Resource Attribute Bit Mask modifies this behavior.
An LSP may have many Resource Attribute Bit Masks. It may be more efficient to define a container for the Resource Attribute Bit Masks and include that container in the LSP_ATTRIBUTES. Whether to use such a container rather than include multiple Resource Attribute Bit Masks directly in the LSP_ATTRIBUTES is up for discussion.
The registry for the Node Attribute TLV is defined in [RFC5786]. IANA is requested to assign a new sub-TLV codepoint for the Node Reliability sub-TLV carried in the Node Attribute TLV.
Value Sub-TLV Reference ----- ------- --------- TBA Node Reliability sub-TLV this document
The registry for the Link TLV is defined in [RFC3630]. IANA is requested to assign a new sub-TLV codepoint for the Link Reliability sub-TLV carried in the Link TLV.
Value Sub-TLV Reference ----- ------- --------- TBA Link Reliability sub-TLV this document
IANA is requested to assign a new TLV codepoint for Node Reliability TLV.
Type TLV Reference ----- ------- --------- TBA Node Reliability sub-TLV this document
The registry for TLV 22 is defined in [RFC5305]. IANA is requested to assign a new sub-TLV codepoint for the Link Reliability sub-TLV which is carried in TLV 22.
Value Sub-TLV Reference ----- ------- --------- TBA Link Reliability sub-TLV this document
IANA is requested to assign a new type codepoint for the "Resource Attribute Bit Mask" TLV in the Attribute TLV Space. It is carried in the LSP_ATTRIBUTES object (class = 197, C-Type = 1).
Type: TBA
Name: Resource Attribute Bit Mask
Allowed on LSP_ATTRIBUTES: Yes
Allowed on LSP_REQUIRED_ATTRIBUTES: No
The function described in this document does not create any new security issues for the OSPF and IS-IS protocols and does not introduce any new security issues above those identified in [RFC3209] and [RFC4090].
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3209] | Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. |
| [RFC3630] | Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. |
| [RFC4090] | Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. |
| [RFC5305] | Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. |
| [RFC5420] | Farrel, A., Papadimitriou, D., Vasseur, JP. and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. |
| [RFC5786] | Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, March 2010. |