One document matched: draft-minto-rsvp-lsp-egress-fast-protection-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC4447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4447.xml">
<!ENTITY RFC3471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC3472 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3472.xml">
<!ENTITY RFC5331 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5331.xml">
<!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-minto-rsvp-lsp-egress-fast-protection-00"
ipr="trust200902">
<front>
<title>RSVP-TE LSP egress fast-protection-00</title>
<author fullname="Jeyananth Minto Jeganathan" initials="J.M"
surname="Jeganathan">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>minto@juniper.net</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H" surname="Gredler">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author fullname="Yimin Shen" initials="Y" surname="Shen">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>yshen@juniper.net</email>
</address>
</author>
<date day="12" month="Oct" year="2012"/>
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>Egress protection</keyword>
<keyword>Egress fast reroute</keyword>
<keyword>egress local repair</keyword>
<abstract>
<t>RFC4090 defines an RSVP fast reroute mechanism for local repairing
LSP tunnel in the order of 10s milliseconds, in the event of a
downstream link or node failure. However, the mechanism does not provide
node protection for LSP egress nodes. This document describes two
methods to establish a bypass LSP from the penultimate-hop node of an
LSP to a backup egress node, which could be used to protect the LSP
against egress node failure. The methods enable local repair in the
order of 10s of millisecond, in the event of the egress node failure.
These methods are only applicable if traffic carried by the LSP could be
rerouted to ultimate destination by the backup egress node.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document define two methods that could enable fast protection
for egress node failure for RSVP-TE signaled LSP tunnels. Both methods
have a common concept of primary egress node and backup egress node for
a tunnel endpoint address. The methods differ by how tunnel endpoints
are modeled in the network. The primary egress node of an LSP (called
protected LSP) terminates the LSP in steady state, while a bypass LSP is
established from the penultimate-hop node to the backup egress node. The
penultimate-hop node, serving as a PLR (point of local repair),
redirects traffic to the backup egress node of the LSP via the bypass
LSP in the event of primary egress node failure, and the backup egress
node forwards the traffic to the ultimate destination. How the backup
egress node forwards traffic is beyond the scope this document. For one
example, the backup egress node could mirror from the primary egress
node the inner labels (e.g. layer-2/3 VPN service labels) carried by the
traffic, and forward the traffic based on those labels by using the
mechanisms specified in [pwe3-endpoint-fast-protection] and
[l3vpn-egress PE-fast-protection].</t>
<figure>
<artwork>
[R1] [R8]
\ /
[R2]---[R3]----[R4]-----[R5]---[R6]
\ / \\
[R9]-----[R10] [R7]
Protected LSP to-R6.x: [R1->R3->R4->R5->R6.x]
Protected LSP to-R6.y: [R1->R3->R4->R5->R6.y]
Protected LSP to-sec-R6.x: [R1->R3->R9->R10->R5->R6.x]
Protected LSP to-R8.z: [R2->R3->R4->R5->R8.z]
Egress-Bypass LSP Tunnel by-R7.x: [R5->R7.x]
Egress-Bypass LSP Tunnel by-R7.y: [R5->R7.y]
Egress-Bypass LSP Tunnel by-R7.z: [R5->R7.z]
x, y, z: Tunnel destination addresses.
R6 has x,y destination addresses.
Figure 1
</artwork>
</figure>
<t>In Figure 1, 4 LSPs are required egress protection. R6 and R8 are the
primary egresses for 4 LSPs, R7 is backup egress and R5 is penultimate
hop node for all LSPs. R5 establish bypass LSP to R7 for fast protection
to handle the R6 or R8 failure. Below table shows the protected LSP and
bypass LSP in R5.</t>
<texttable>
<ttcol align="center">Protected LSP</ttcol>
<ttcol align="center">Egress Bypass LSP</ttcol>
<c>to-R6.x</c>
<c>by-R7.x</c>
<c>to-R6.y</c>
<c>by-R7.y</c>
<c>to-sec-R6.x</c>
<c>by-R7.x</c>
<c>to-R8.z</c>
<c>by-R7.z</c>
</texttable>
<t>Two methods defined in the documents that enable the backup LSP to
establish to backup egress.</t>
<t><list style="letters">
<t>Proxy node method</t>
<t>Alias method</t>
</list></t>
<t>In the proxy method, an LSP endpoint address is represent as a
virtual node in the TE domain attached to the primary egress node and
the backup egress node via bidirectional point-to-point TE links. With
this representation, the penultimate-hop node of the LSP could use the
normal procedure of RSVP fast-reroute PLR to set up a bypass LSP to the
backup egress node, by avoiding the primary egress node. This methed has
the advantage of not requiring software upgrade on the penultimate-hop
node, and thus can ease the deployment this technology.</t>
<figure title="Figure 2">
<artwork>
[R1] [R8]
\ /
[R2]---[R3]----[R4]-----[R5]---[R6]---[x]
\ / \ /
[R9]-----[R10] [R7]---+
x: Tunnel destination addresses in proxy method.
</artwork>
</figure>
<t>With proxy method, topology is modeled as figure 2 in the rest of the
network for LSP destination address x which required egress protection
and R6 is primary R7 is backup.</t>
<t>In alias method, an LSP endpoint address is associated with an
dedicated IP address on the backup egress node. This IP address is
called an alias. The penultimate-hop node of the LSP may learn the alias
via IGP or configuration, and use it as the destination when computing a
path for the bypass LSP. With this method, the penultimate-hop node can
set up a bypass LSP to the backup egress node, by avoiding the primary
egress node. This method requires software upgrade penultimate-hop node,
but is flexile to support all traffic engineering constraints.</t>
<figure suppress-title="false" title="Figure 3">
<artwork>
[R1] [R8]
\ /
[R2]---[R3]----[R4]-----[R5]---[R6]x
\ / \
[R9]-----[R10] [R7](x)
x: Tunnel destination addresses in alias method.
</artwork>
</figure>
<t> In figure 3, let say x is tunnel destination address and R6 is
primary and R7 is backup then with alias method, R6 advertises x as
secondary loopback address and R5 knows x has backup either by
configuration or R7 advertisement in IGP.</t>
</section>
<section title="Specification of Requirements">
<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 RFC 2119.</t>
</section>
<section title="Terminology">
<t>PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a
detour LSP</t>
<t>PHN: Penultimate Hop Node for an LSP.</t>
<t>Primary egress node: Node terminates a LSP in steady state.</t>
<t>Primary: Primary egress node.</t>
<t>Egress Protected LSP: A Protected LSP that also required protection
from primary egress node failure</t>
<t>Backup egress node: Node could rerouted/repaired data carried in a
protected LSP</t>
<t>Backup node: Backup egress node.</t>
<t>Protector: Backup egress node.</t>
<t>Protector and Backup node are used interchangeably but convey the
same meaning.</t>
</section>
<section anchor="Proxy" title="Proxy method">
<t>In this method, an LSP endpoint address is represented as a virtual
TE node connected to a primary egress node and a backup egress node with
bidirectional TE links, as shown figure 1. With this model, node
protection establishment and bypass LSP path computation on the
penultimate hop of an LSP can follow the procedure described in
RFC4090.</t>
<figure>
<artwork> primary egress -
\ metric 1, TE metric 1, bandwidth max
\
\
\
\ metric max, TE metric max, bandwidth 0
|
proxy node [stub node]
|
/ metric max, TE metric max, bandwidth 0
/
/
/
/ metric max, TE metric max, bandwidth 0
backup egress-
Figure 4</artwork>
</figure>
<section anchor="proxy-adv"
title="Tunnel destination Advertisement in IGP ">
<t>Tunnel destination advertised as stub proxy TE node required two
parts. A node representation (proxy-node) and links to and from
primary egress and backup egress..<list>
<t>The primary advertises proxy node with two links to primary
egress and backup egress, respectively. The router ID of the proxy
node is LSP end point address. The system-ID is derived from the
LSP end point address with BCD encoding. The resulting system-ID
and router-ID MUST be unique with in IGP routing domain. Both stub
links are advertised with maximum routable metric and TE metric,
and zero bandwidth. This avoids the proxy node serve as a transit
node for any paths. The router-ID or system-ID of the protector
could be dynamically learned from IGP link state database or could
be configured in primary.</t>
<t>The primary egress advertises an unnumbered transit link to the
proxy node, with metric 1, TE metric 1, and maximum bandwidth. It
may be necessary for the primary node to have the capabilities to
advertise multiple TE unnumbered transit links between primary
node and proxy-node. The upper bound on the number of such links
is the number of the links the primary node advertises into
TE.</t>
<t>The backup egress advertises an unnumbered transit link to the
proxy node, with MAX metric, MAX TE metric, and zero bandwidth.
Other TE characteristic of the links could be configured and
advertised in to TE.</t>
</list></t>
<section title="ISIS proxy-node (Non-Normative)">
<t>Only zeroth fragment of the proxy-node is only valid. All Other
fragments SHOULD be ignored. Zeroth fragment MUST include area
address TLV and MAY include hostname TLV.</t>
<t>The set of area addresses advertised MUST be a subset of the set
of Area Addresses advertised in the protected LSP number zero at the
corresponding level. Preferably, the advertisement SHOULD be
syntactically identical to that included in the normal LSP number
zero at the corresponding level. The hostname could be set as
<tunnel-destination + protected hostname>.</t>
<t>The Overload (OL) MUST be set to 1. The Attached (ATT), and
Partition Repair (P) bits MUST be set to 0.</t>
</section>
<section title="OSPF proxy-node (Non-Normative)">
<t>The advertising router and Link State ID of router LSA be LSP end
point address. All options bits in router LSA MUST be set to zero.
The number of links MUST be 2</t>
</section>
</section>
<section title="Ingress Node Behavior">
<t>The ingress node of an LSP should follow same procedure in RFC 2205
and RFC 4090 to signal the LSP. In particular, it should set the
destination to the endpoint address (i.e. the proxy node), and the
"link protection desired" flag and the "node protection desired" flag
in SESSION_ATTRIBUTE of Path message. In path computation, it MAY
optionally set not to use MAX metric link, as another constraint, to
avoid the link between the backup egress and the proxy node.</t>
</section>
<section title="Primary Egress Node Behavior">
<t>When the primary egress node receives Path message for the LSP with
destination matching the proxy node address, it MUST append two
entities in the RRO object of Resv message, first for the proxy node
as a virtual downstream node, and second for itself as virtual transit
node. The entity for the proxy node is encoded as {proxy node address,
proxy link ID, implicit NULL}.</t>
</section>
<section title="Penultimate Hop Node">
<t>When the penultimate hop node receives Resv message from primary
egress, it sees itself as two hops away from LSP's destination rather
than one hop, based on the RRO. Thus, it can set up node protection
for the LSP by following the procedure described in RFC 4090. It
SHOULD set up a bypass LSP to the backup egress node. When computing a
path for bypass LSP, it SHOULD avoid the primary egress node and
choose a path via the backup egress node to reach the proxy node.</t>
<section title="Backup LSP Signaling during Local Repair">
<t>The penultimate hop node SHOULD uses the same procedure as
defined RFC4090 to signal the backup Path, in the event of failure
of the primary egress node.</t>
</section>
</section>
<section anchor="Proxy-backup" title="Backup Egress Node Behavior">
<t>When the backup egress node receives the Path message of the bypass
LSP, it MUST terminate the Path message based on the match bewteen the
LSP destination and the proxy node address. It SHOULD assign a
non-reserved label to the bypass LSP, and point the label to a
specific label table where the labels learned from the primary egress
node are installed. This can facilitate forwarding of traffic when the
backup egress node receives traffic over the bypass LSP during local
repair. In this case, the traffic will be carrying inner labels
assigned by the primary egress node, and a further label lookup in the
specific label table SHOULD enable the backup egress node to forward
traffic to the ultimate destination.</t>
<section title="Backup LSP Signaling during Local Repair">
<t>During local repair, the backup egress node will receive Path
message of backup LSP from the penultimate hop node. The backup
egress node SHOULD terminate the Path message, and respond with a
Resv message.</t>
</section>
</section>
<section title="Pros/Cons">
<t>Pros<list style="numbers">
<t>Protocol extension not required. Changes required only in
tunnel egress nodes. Core router software upgrade required is not
required.</t>
</list></t>
<t>Cons<list style="numbers">
<t>To support TE constrains like colors and SRLG for a protected
LSP the primary need to have capability to advertise multiple
links to between proxy and primary.</t>
<t>Bypass LSP with constrains cant be supported.</t>
<t>If ISIS used as IGP then Primary node should not configured
with overload bit.</t>
<t>if OSPF as IGP then a Proxy node could be used in transit even
if primary is down.</t>
<t>Protector could be used as primary end point in the forwarding
plane if the protected LSP established to protector instead of
primary in transient condition</t>
</list></t>
</section>
</section>
<section anchor="Alias" title="Alias model">
<t>In this model Penultimate hop node understand tunnel end point has a
backup egress which is may not protected LSP path and backup egress
could repair traffic carried protected LSP in the event of primary
egress failure. After primary egress failure PHN reroute using bypass
tunnel to backup egress. The tunnel endpoint address and backup egress
mapping could be configured in penultimate hop node or signaled through
IGP from the backup. Following table illustrate the PNH mapping primary
to backup mapping for the figure 1.</t>
<texttable align="center" anchor="Alias-Table" title="Table mapping">
<ttcol align="center">Primary Egress Router ID</ttcol>
<ttcol align="center">Backup egress router ID</ttcol>
<ttcol align="center">Backup LSP destination address.</ttcol>
<c>10.1.2.6</c>
<c>10.1.1.6</c>
<c>10.1.1.7</c>
<c>10.1.2.6</c>
<c>10.1.3.6</c>
<c>10.1.1.6</c>
<c>10.1.1.7</c>
<c>10.1.3.6</c>
<c>10.1.2.8</c>
<c>10.1.1.8</c>
<c>10.1.1.7</c>
<c>10.1.2.8</c>
</texttable>
<section title="Head-End Behavior">
<t>Ingress should follow same procedure in RFC 3209 with tunnel
endpoint address and path computation could use RFC 5786 advertised
tunnel endpoint address.</t>
</section>
<section title="Primary Egress node">
<t>Primary egress node advertises tunnel end points that required
protection using RFC 5786 in OSPF and/or IP interface addresses
TLV(132) in ISIS. These TLVs are defines as Local address
advertisement in TE. And rest of behavior is same RFC 4090.</t>
</section>
<section title="Backup egress node">
<t>When backup receives a Path message not through a bypass tunnel for
a destination address it protects with ERO constains only one self sub
objects then it MUST accept and respond with RRO objects in Resv
message. The RRO object {node ID, Ip address, label} for tunnel end
address set with {Node ID, tunnel endpoint address, non-NULL}. This
non-NULL will be used for identify LSP it protects in forwarding.
Backup could also signals protection availability for tunnel end point
addresses through IGP.</t>
<section title="Procedures for the Backup egress during Local Repair">
<t>The Backup egress sends Resv, ResvTear, and PathErr messages by
sending them directly to the address in the RSVP_HOP object, as
specified in [RSVP-TE].</t>
</section>
<section title="Processing Backup Tunnel's ERO">
<t>When backup receive Path message through a bypass tunnel with one
sub-object for destination address it protects then it should accept
ERO.</t>
</section>
</section>
<section title="Penultimate hop node">
<t>PLR learns/configured backup egress for tunnel a end point address
advertised by primary egress. When PLR setup bypass for node
protection LSP it will also lookup for the backup egress if PLR is
penultimate hop of the LSP. If backup egress is available for LSP
tunnel end point address then it setup bypass-LSP to backup egress if
it is not setup already. The constrains will be exclude egress node.
PNH could setup bypass-LSP with destination as backup egress node or
tunnel endpoint address. If the bypass tunnel endpoint address is not
the protected LSP tunnel endpoint then it also initiates backup LSP
for tunnel end point address through bypass tunnel to learn the label
to use in failure.</t>
<section title="Signaling a Backup Path">
<t>PHP SHALL uses the same procedure as defined RFC4090 to signal
the backup Path.</t>
</section>
<section title="Procedures for Backup Path Computation">
<t>PLR has to find the desired explicit route for the backup path.
This can be done using a CSPF computation. If PLR is PNH for the
protected LSP needs node protection then destination for backup path
MUST be backup egress router ID with constrain that LSP cannot
traverse the primary egress node and/or link whose failure is being
protected against. For other constrains SHOULD follow RFC4090.</t>
</section>
<section title="Signaling for Facility Protection">
<t>A PHN use one or more bypass tunnels to protect against the
failure of a egress primary node. This bypass tunnels set up in
advance or dynamically created as new protected LSPs are
signaled.</t>
<section title="Discovering Downstream Labels">
<t>To support facility backup, the PHN must determine the label
that will indicate to the backup egress that packets received with
that label should be processed by primary egress context. This can
be done by explicitly signaling backup path before failure or
setup the UHP bypass tunnel to backup egress with tunnel endpoint
address as destination.</t>
</section>
<section title="Processing Backup Tunnel's ERO ">
<t>Sub-objects belonging to abstract nodes that precede the tunnel
endpoint Point are removed. A sub-object identifying the Backup
Tunnel destination is then added.</t>
</section>
<section title="PLR Procedures during Local Repair">
<t>PHN SHALL uses the same procedure as defined RFC4090 during the
local repair.</t>
</section>
</section>
</section>
<section title="Pros/Cons">
<t>Pro<list style="numbers">
<t>Will work with any TE constrains</t>
</list></t>
<t>Cons<list style="numbers">
<t>Protocol changes required in RSVP. Also IGP extension required
to avoid PLR static protector configuration.</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations discussed in RFC 5036, RFC 5331, RFC
3209, and RFC 4090 apply to this document.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>This document leverages work done by Hannes Gredler, Yakov Rekhter
and several others on LSP tail-end protection. Thanks to Nischal Sheth,
Nitin Bahadur, Yimin shen, Ashwin Sampath and Kaliraj Vairavakkalai for
their contribution.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC5331;
<?rfc include="reference.RFC.4364"?>
<?rfc include="reference.RFC.5036"?>
<?rfc include="reference.RFC.2205"?>
<?rfc include="reference.RFC.3209"?>
<?rfc include="reference.RFC.4090"?>
<?rfc include="reference.RFC.3471"?>
<?rfc include="reference.RFC.3031"?>
<reference anchor="LDP-UPSTREAM">
<front>
<title>MPLS Upstream Label Assignment for LDP</title>
<author fullname="Rahul Aggarwal" initials="R" surname="Aggarwal">
<organization>Juniper Networks</organization>
</author>
<author fullname="Jean-Louis Le Roux" initials="J. L. Le"
surname="Roux">
<organization>France Telecom</organization>
</author>
<date year="2011"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-ldp-upstream"/>
<format target="http://tools.ietf.org/html/draft-ietf-mpls-ldp-upstream-10"
type="TXT"/>
</reference>
<reference anchor="RSVP-NON-PHP-OOB">
<front>
<title>Non PHP Behavior and out-of-band mapping for RSVP-TE
LSPs</title>
<author fullname="Zafar Ali" initials="A" surname="Ali">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="George Swallow" initials="Z" surname="Swallow">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="Rahul Aggarwal" initials="R" surname="Aggarwal">
<organization>Juniper Networks</organization>
</author>
<date year="2011"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-mpls-rsvp-te-no-php-oob-mapping"/>
<format target="http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-07"
type="TXT"/>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5286"?>
<?rfc include="reference.RFC.5714"?>
<reference anchor="pwe3-endpoint-fast-protection"
target="pwe3-endpoint-fast-protection">
<front>
<title>PW Endpoint Fast Failure Protection</title>
<author fullname="Yimin Shen" initials="Y" role="editor"
surname="Shen"/>
<author fullname="Rahul Aggarwal" initials="R" surname="Aggarwal"/>
<author fullname="Wim Henderickx"/>
<date year="2011"/>
</front>
<format target="http://tools.ietf.org/html/draft-shen-pwe3-endpoint-fast-protection-02"
type="TXT"/>
</reference>
<reference anchor="l3vpn-egress-PE-fast-protection"
target="2547-egress-PE-fast-protection">
<front>
<title>2547 egress PE Fast Failure Protection</title>
<author fullname="Jeyananth Minto Jeganathan" initials="J"
surname="Jeganathan">
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
</postal>
<email>minto@juniper.net</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="G" surname="Gredler">
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<date year="2011"/>
</front>
<format target="http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-00"
type="TXT"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 17:10:17 |