One document matched: draft-dong-mpls-frr-resource-class-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5420.xml">
<!ENTITY RFC5786 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5786.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-dong-mpls-frr-resource-class-00"
ipr="trust200902">
<front>
<title abbrev="MPLS TE FRR Resource Classification">
MPLS-TE Fast Reroute Resource Classification
</title>
<author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Building, No.3 Xinxi Rd</street>
<city>Beijing</city>
<code>100085</code>
<country>China</country>
</postal>
<email>jie.dong@huawei.com</email>
</address>
</author>
<author fullname="Mach Chen" initials="M." surname="Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Building, No.3 Xinxi Rd</street>
<city>Beijing</city>
<code>100085</code>
<country>China</country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author fullname="Curtis Villamizar" initials="C. " surname="Villamizar">
<organization>OCCNC, LLC</organization>
<address>
<email>curtis@occnc.com</email>
</address>
</author>
<date day="24" month="October" year="2011" />
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119" />.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>MPLS Traffic Engineering (TE) Fast Reroute (FRR) <xref
target="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.</t>
<t> 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.</t>
<t>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.</t>
</section>
<section title="Problem Statement">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="TE FRR Resource Class Overview">
<t>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.</t>
<t>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.</t>
<section title="Setting Default Behavior">
<t>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.</t>
<t>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.</t>
</section>
<section title="Backwards Compatibility with Legacy PLR">
<t>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.</t>
<t>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.</t>
</section>
<section title="Backwards Compatibility with Legacy Ingress">
<t>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.</t>
</section>
</section>
<section title="TE FRR Resource Class Protocol Extensions">
<t>This document defines the following extensions.
<list style="numbers">
<t>new TLVs in OSPF and IS-IS to provide a means of host or
link reliability classification.</t>
<t>new TLVs in OSPF and IS-IS to provide SRLG
classification.</t>
<t>a new alternate SRLG TLV for OSPF and IS-IS to allow
definition of SRLG that will be ignored by legacy PLR.</t>
<t>an extension to RSVP-TE to allow per LSP deviations from
default protection to be specified.</t>
</list>
</t>
</section>
<section title="IGP Extensions">
<section anchor="sect.ospf-nr-tlv"
title="OSPF Node Reliability sub-TLV">
<t>The reliability of a node is specified using a Node
Reliability sub-TLV of the Node Attribute TLV <xref
target="RFC5786" />. Length of this sub-TLV is variable.
The format is as follows:</t>
<t><figure>
<artwork align="center">
<![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure></t>
<t>The type code is TBA for Node Reliability sub-TLV.</t>
<t>The length field is set to four plus the number of SRNG
included time the size of an SRNG.</t>
<t>The Flags field is reserved for future use.</t>
<t>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.</t>
<t>The format of SRNG is common to OSPF and ISIS and is
defined in <xref target="sect.SRNG" /></t>
</section>
<section anchor="sect.ospf-lr-tlv"
title="OSPF Link Reliability sub-TLV">
<t>The reliability of link is specified using a Link Reliability
sub-TLV of the Link TLV <xref target="RFC3630" />. Length of
this sub-TLV is variable. The format is as follow:</t>
<t><figure>
<artwork align="center">
<![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure></t>
<t>The Flags field is reserved for future use.</t>
<t>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.</t>
<t>The format of Extended SRLG is common to OSPF and ISIS
and is defined in <xref target="sect.SRNG" /></t>
</section>
<section anchor="sect.isis-nr-tlv"
title="IS-IS Node Reliability TLV">
<t>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:</t>
<t><figure>
<artwork align="center">
<![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure></t>
<t>The Flags field is reserved for future use.</t>
<t>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.</t>
<t>The format of SRNG is common to OSPF and ISIS and is
defined in <xref target="sect.SRNG" /></t>
</section>
<section anchor="sect.isis-lr-tlv"
title="IS-IS Link Reliability TLV">
<t>The reliability of link is specified using a Link
Reliability sub-TLV of the TLV 22 <xref target="RFC5305"
/>. Length of this sub-TLV is variable. The format is as
follow:</t>
<t><figure>
<artwork align="center">
<![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure></t>
<t>The Flags field is reserved for future use.</t>
<t>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.</t>
<t>The format of Extended SRLG is common to OSPF and ISIS
and is defined in <xref target="sect.SRNG" /></t>
</section>
<section anchor="sect.SRNG" title="Shared Risk Node Group">
<t>The Shared Risk Node Group (SRNG) is carried within
either the OSPF Node Reliability sub-TLV (see <xref
target="sect.ospf-nr-tlv" />) or the IS-IS Node Reliability
TLV (see <xref target="sect.isis-nr-tlv" />). The SRNG is 8
bytes. The format is as follow:</t>
<t><figure>
<artwork align="center">
<![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure></t>
<t>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.</t>
<t>The Flags field is reserved for future use.</t>
<t>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.</t>
</section>
<section anchor="sect.SRLG" title="Extended Shared Risk Link Group">
<t>The Extended Shared Risk Link Group (ESRLG) is carried
within either the OSPF Link Reliability sub-TLV (see <xref
target="sect.ospf-lr-tlv" />) or the IS-IS Link Reliability
TLV (see <xref target="sect.isis-lr-tlv" />). The ESRLG is
8 bytes. The format is as follow:</t>
<t><figure>
<artwork align="center">
<![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure></t>
<t>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.</t>
<t>The Flags field is reserved for future use.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="RSVP-TE Extensions">
<section title="Resource Attribute Bit Mask">
<t>The Resource Attribute Bit Mask is defined in
LSP_ATRTRIBUTE Object. The LSP_ATRTRIBUTE is defined in <xref
target="RFC3209" /> and updated in <xref target="RFC5420"
/>. The format of the Resource Attribute Bit Mask is as
follows:</t>
<t><figure>
<artwork>
<![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure></t>
<t>The 2 bit Operation field (OP) specifies one of the
following operations. The following values are defined for
the Operation field.
<list style="hanging" hangIndent="4">
<t hangText="00">Include if any set</t>
<t hangText="01">Include if all set</t>
<t hangText="10">Exclude if any set</t>
<t hangText="11">Exclude if all set</t>
</list>
</t>
<t>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.
<list style="hanging" hangIndent="4">
<t hangText="00">Applu the mask to Node Reliability values</t>
<t hangText="01">Applu the mask to Link Reliability values</t>
<t hangText="10">Applu the mask to SRNG Reliability values</t>
<t hangText="11">Applu the mask to ESRLG Reliability values</t>
</list>
</t>
<t>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.</t>
</section>
</section>
<section title="Protocol Actions">
<t>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.</t>
<t>The action taken at a PLR for a given LSP are as follows.</t>
<t>If no protection is required, as indicated by the "protection
desired" bit in the RSVP-TE Flags SESSION_ATTRIBUTE <xref
target="RFC3209" /> not being set, then no protection path is
created at a potential PLR. This behavior is unchanged.</t>
<t>If link disjoint protection if required, as indicated by the
"protection desired" bit set and the "Node protection desired"
bit not set <xref target="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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="To Be Completed">
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="OSPF">
<t>The registry for the Node Attribute TLV is defined in <xref
target="RFC5786" />. IANA is requested to assign a new sub-TLV
codepoint for the Node Reliability sub-TLV carried in the Node
Attribute TLV.</t>
<t><figure>
<artwork><![CDATA[Value Sub-TLV Reference
----- ------- ---------
TBA Node Reliability sub-TLV this document]]></artwork>
</figure></t>
<t>The registry for the Link TLV is defined in <xref
target="RFC3630" />. IANA is requested to assign a new sub-TLV
codepoint for the Link Reliability sub-TLV carried in the Link
TLV.</t>
<t><figure>
<artwork><![CDATA[Value Sub-TLV Reference
----- ------- ---------
TBA Link Reliability sub-TLV this document]]></artwork>
</figure></t>
</section>
<section title="IS-IS">
<t>IANA is requested to assign a new TLV codepoint for Node
Reliability TLV.</t>
<t><figure>
<artwork><![CDATA[Type TLV Reference
----- ------- ---------
TBA Node Reliability sub-TLV this document]]></artwork>
</figure></t>
<t>The registry for TLV 22 is defined in <xref
target="RFC5305" />. IANA is requested to assign a new sub-TLV
codepoint for the Link Reliability sub-TLV which is carried in TLV
22.</t>
<t><figure>
<artwork><![CDATA[Value Sub-TLV Reference
----- ------- ---------
TBA Link Reliability sub-TLV this document]]></artwork>
</figure></t>
</section>
<section title="RSVP-TE">
<t>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).</t>
<t><figure>
<artwork><![CDATA[ Type: TBA
Name: Resource Attribute Bit Mask
Allowed on LSP_ATTRIBUTES: Yes
Allowed on LSP_REQUIRED_ATTRIBUTES: No]]></artwork>
</figure></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>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].</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3209;
&RFC3630;
&RFC4090;
&RFC5305;
&RFC5420;
&RFC5786;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:14:34 |