Extensions to RSVP-TE for P2MP LSP Ingress Local Protection
draft-chen-mpls-p2mp-ingress-protection-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Huaimo Chen , Ning So , Autumn Liu , Lei Liu | ||
| Last updated | 2012-10-21 | ||
| Replaced by | draft-ietf-mpls-rsvp-ingress-protection | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-mpls-p2mp-ingress-protection-07
Internet Engineering Task Force H. Chen
Internet-Draft Huawei Technologies
Intended status: Standards Track N. So
Expires: April 25, 2013 Tata Communications
A. Liu
Ericsson
L. Liu
KDDI R&D Lab Inc.
October 22, 2012
Extensions to RSVP-TE for P2MP LSP Ingress Local Protection
draft-chen-mpls-p2mp-ingress-protection-07.txt
Abstract
This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting the ingress node
of a Traffic Engineered (TE) Point-to-MultiPoint (P2MP) Label
Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) network.
Status of this Memo
This Internet-Draft is submitted to IETF 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 25, 2013.
Copyright Notice
Copyright (c) 2012 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
Chen, et al. Expires April 25, 2013 [Page 1]
Internet-Draft P2MP LSP Ingress Protection October 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. An Example of Ingress Local Protection . . . . . . . . . . 4
4.2. Set up of Backup P2MP sub Tree . . . . . . . . . . . . . . 5
4.3. Forwarding State for Backup P2MP sub Tree . . . . . . . . 5
4.4. Detection of Failure around Ingress . . . . . . . . . . . 6
5. Ingress Local Protection with FRR . . . . . . . . . . . . . . 7
6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
6.1. New RSVP-TE Messages . . . . . . . . . . . . . . . . . . . 8
6.1.1. LSP Information Message . . . . . . . . . . . . . . . 8
6.1.2. Backup LSP for One-to-One Backup . . . . . . . . . . . 9
6.1.3. Backup LSP for Facility Backup . . . . . . . . . . . . 10
6.1.4. LSP Information Confirmation Message . . . . . . . . . 11
6.2. New RSVP-TE Objects . . . . . . . . . . . . . . . . . . . 12
6.2.1. Information about Existing LSP . . . . . . . . . . . . 12
6.2.2. Desire for Locally Protecting Ingress . . . . . . . . 12
6.2.3. Backup LSP for One-to-One Backup . . . . . . . . . . . 13
6.2.4. Backup LSP for Facility Backup . . . . . . . . . . . . 13
6.3. OSPF Opaque LSA . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Chen, et al. Expires April 25, 2013 [Page 2]
Internet-Draft P2MP LSP Ingress Protection October 2012
1. Introduction
RFC4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels"
describes two methods to protect P2P LSP tunnels or paths at local
repair points. The first method is a one-to-one backup method, where
a detour backup P2P LSP for each protected P2P LSP is created at each
potential point of local repair. The second method is a facility
bypass backup protection method, where a bypass backup P2P LSP tunnel
is created using MPLS label stacking to protect a potential failure
point for a set of P2P LSP tunnels. The bypass backup tunnel can
protect a set of P2P LSPs that have similar backup constraints.
RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use
the one-to-one backup method and facility bypass backup method to
protect a link or intermediate node failure on the path of a P2MP
LSP. However, there is no mention of locally protecting an ingress
node failure in a protected P2MP LSP.
There exist two methods for protecting an ingress node of a P2MP LSP.
The first method deploys a backup P2MP LSP from a backup ingress node
to the destination nodes to protect the ingress node. The main
disadvantage of this method is that the backup P2MP LSP consumes
additional network bandwidth along the entire LSP paths. The impact
on network efficiency can be significant in case of large P2MP
deployments. In addition, the backup LSP has to be linked to the
primary LSP logically at the head-end to allow the fast switching in
case of ingress failure.
The second method extends the existing ways of protecting an
intermediate node of a P2P LSP to protect an ingress node of a P2MP
LSP. The disadvantages of this method include extra work for
refreshing PATH messages and processing RESV messages for the P2MP
LSP in the backup ingress node.
This document defines extensions to RSVP-TE for locally protecting an
ingress node of a Traffic Engineered (TE) point-to-multipoint (P2MP)
Label Switched Path (LSP) through using a backup P2MP sub tree. The
new method overcomes the disadvantages described above. It can also
be applied for protecting an ingress node of a TE point-to-point
(P2P) LSP since a TE P2P LSP can be considered as a special case of a
TE P2MP LSP.
2. Terminology
This document uses terminologies defined in RFC2205, RFC3031,
RFC3209, RFC3473, RFC4090, RFC4461, and RFC4875.
Chen, et al. Expires April 25, 2013 [Page 3]
Internet-Draft P2MP LSP Ingress Protection October 2012
3. Conventions Used in This Document
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.
4. Mechanism
This section briefly describes a solution that locally protects an
ingress node of a P2MP LSP through using a backup P2MP sub tree. We
start with a simple example, and then present different parts of the
solution, which includes the creation of the backup P2MP sub tree,
the forwarding state for the backup P2MP sub tree, and the detection
of a failure in the ingress node.
4.1. An Example of Ingress Local Protection
Figure 1 below illustrates an example of using a backup P2MP sub tree
to locally protect the ingress of a P2MP LSP. The P2MP LSP to be
protected is from ingress node R1 to three egress/leaf nodes: L1, L2
and L3. The backup P2MP sub tree used to protect the ingress node R1
is from backup ingress node Ra to the next hop nodes R2 and R4 of the
ingress node R1 along the P2MP LSP.
The traffic from source S may be delivered to both R1 (the primary
ingress of the LSP) and Ra (the backup ingress node designated to
protect the primary ingress). R1 introduces the traffic into the
P2MP LSP, which is sent to the egress/leaf nodes L1, L2 and L3 along
the P2MP LSP. Ra normally does not put the traffic into the backup
P2MP sub tree, which is from Ra to R2 and R4.
There may be a BFD session between ingress node R1 and backup ingress
node Ra. Ra uses this BFD session to detect the failure of ingress
R1. When Ra detects the failure of R1, it imports the traffic from
the source S into the backup P2MP sub tree. The traffic from the sub
tree is merged into the P2MP LSP at R2 and R4, and then sent to the
egress/leaf nodes L1, L2 and L3 along the P2MP LSP. The time for
switching the traffic after R1 fails is within tens of milliseconds.
Chen, et al. Expires April 25, 2013 [Page 4]
Internet-Draft P2MP LSP Ingress Protection October 2012
[R2]======[R3]=====[L1]
// |
// |
// |
// |
// /
// /
// /
+---[R1]======[R4]====[R5]=====[L2]
| ! / / \\
| ! / / \\
[S]--| ! / / \\
| ! / / \\
| !/ / \\
+---[Ra]---[Rb] \\
\\
\\
[L3]
Figure 1: P2MP sub Tree for Locally Protecting Ingress
After the failure of the ingress node R1, the refresh of the PATH
messages for the ingress node is not needed. Each of the next-hop
nodes of the ingress node will receive the PATH messages and the
refresh of the PATH messages for the backup P2MP sub tree from the
backup ingress node Ra, which make the P2MP LSP alive.
4.2. Set up of Backup P2MP sub Tree
For the ingress node of the P2MP LSP, a backup ingress node is
designated to protect it. The ingress node sends the P2MP LSP
information to the backup ingress node. The backup ingress node
initiates the creation of the backup P2MP sub tree from itself to the
next-hop nodes of the ingress node.
The backup ingress node sets up the backup P2MP sub tree in a way
similar to setting up a P2MP tree or LSP from the signaling's point
of view. It constructs and sends RSVP-TE PATH messages along the
path for the backup P2MP sub tree with the final destinations (i.e,
egress/leaf nodes) matching the P2MP LSP. It receives and processes
RSVP-TE RESV messages that response to the PATH messages.
4.3. Forwarding State for Backup P2MP sub Tree
The forwarding state for the backup P2MP sub tree is different from
that for a P2MP LSP. After receiving the RSVP-TE RESV messages for
the backup P2MP sub tree, the backup ingress node creates a
Chen, et al. Expires April 25, 2013 [Page 5]
Internet-Draft P2MP LSP Ingress Protection October 2012
forwarding entry with an inactive state or flag. This forwarding
entry with an inactive state or flag is called an inactive forwarding
entry. In a normal operation, this inactive forwarding entry is not
used to forward any data traffic to be transported by the P2MP LSP,
even though the data traffic may be delivered to the backup ingress
node from an external node such as source node S in the above example
or network. The forwarding entry for the P2MP LSP is with an active
state or flag. Thus when the data traffic from the external node or
network reaches the ingress node of the P2MP LSP, it is imported into
the P2MP LSP tunnel through the active forwarding entry on the
ingress node.
When the ingress node fails, the inactive forwarding entry on the
backup ingress node is changed to active. Thus when the data traffic
from the external node reaches the backup ingress node, it is
imported into the backup P2MP sub tree. When the traffic arrives at
the next-hop nodes through the backup P2MP sub tree, it is merged
into the P2MP LSP to be transported to the destinations.
4.4. Detection of Failure around Ingress
There can be two different failure scenarios involving the ingress
node of a P2MP LSP that need to be detected.
o The failure of the ingress node (e.g. R1 of figure 1).
o The failure of the link between the source node and the ingress
node (e.g. the link between node S and node R1 in figure 1).
A failure of the ingress node can be detected through a BFD session
between the ingress node and the backup ingress node in MPLS
networks. A failure of the link between the source node and the
ingress node can be detected by a BFD session running over the link
and to the backup ingress via the ingress.
In the GMPLS networks where the control plane and data plane are
physically separated, the detection and localization of failures in
the physical layer can be achieved by introducing the link management
protocol (LMP) or assisting by performance monitoring devices.
After the backup ingress node detects any failure involving the
ingress node, it imports the traffic from the source node into the
backup P2MP sub tree. The traffic from the backup ingress node via
the sub tree is merged into the P2MP LSP on the next-hop nodes of the
ingress of the P2MP LSP, and then transported to the egress/leaf
nodes of the P2MP LSP.
Chen, et al. Expires April 25, 2013 [Page 6]
Internet-Draft P2MP LSP Ingress Protection October 2012
5. Ingress Local Protection with FRR
RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use
RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" (FFR
for short) to locally protect failures in a link or intermediate node
of a P2MP LSP. However, there is not any standard that locally
protects the ingress of the P2MP LSP. The ingress local protection
mechanism described above fills this gap. Thus, through using the
ingress local protection and the FRR, we can locally protect the
ingress node , all the links and the intermediate nodes of a P2MP
LSP. The traffic switchover time is within tens of milliseconds
whenever the ingress, any of the links and the intermediate nodes of
the P2MP LSP fails.
The ingress node of the P2MP LSP can be locally protected through
using the ingress local protection. All the links and all the
intermediate nodes of the P2MP LSP can be locally protected through
using the FRR.
RFC 4090 defines fast reroute extensions to RSVP-TE for local
protection of P2P TE LSP in MPLS networks. RFC 4090, which is for
local protection of P2P TE LSP, has a few of limitations or issues
when it is used for local protection of P2MP TE LSP.
For example, locally protecting an intermediate node of a P2MP TE LSP
requires, when the protected node is a branch LSR, a set of P2P Next-
Next-Hop (NNHOP) Bypass tunnels toward all LSRs downstream to the
protected node. When the protected node fails, the PLR has to
replicate traffic on each of the P2P bypass tunnels. If there are K
next-next-hops, this may lead to K times of the traffic on some
links, which is not acceptable.
To overcome these limitations, draft "P2MP MPLS-TE Fast Reroute with
P2MP Bypass Tunnels" proposes extensions to FRR procedures defined in
RFC4090 to locally protect links and intermediate nodes of a P2MP TE
LSP with P2MP bypass tunnels.
Note that the methods for locally protecting all the links and the
intermediate nodes of a P2MP LSP are out of scope of this document.
6. Protocol Extensions
This section describes a few of ways to extend the existing protocols
for supporting TE LSP ingress local protection. Three approaches are
discussed. The first one mainly uses a couple of new RSVP-TE
messages. The second one adds some new objects into existing RSVP-TE
messages. The third one mainly uses OSPF opaque LSAs.
Chen, et al. Expires April 25, 2013 [Page 7]
Internet-Draft P2MP LSP Ingress Protection October 2012
6.1. New RSVP-TE Messages
This sub section presents two types of messages: LSP information
message and LSP information confirmation message.
LSP information messages are used to transfer the information about a
P2MP LSP to a backup ingress node from an ingress node. The
destination address of the LSP information message is that of the
backup ingress node.
LSP information confirmation messages are used to confirm that the
corresponding LSP information messages are received. In addition,
the state of the backup P2MP sub tree and the action of switching
over of traffic are communicated with the parimary ingress through
the messages.
6.1.1. LSP Information Message
6.1.1.1. Format of LSP Information Message
The format of a P2MP LSP information message is illustrated below.
<LSP Information Message> ::=
<Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
<RECORD_ROUTE>
<S2L sub LSP flow descriptor list>
The formats and values of the objects in a P2MP LSP information
message are similar to or the same as those of the corresponding
objects defined in RFC4875.
The value of the Msg Type field in the common header in the P2MP LSP
Chen, et al. Expires April 25, 2013 [Page 8]
Internet-Draft P2MP LSP Ingress Protection October 2012
information message will be a new number to be assigned by Internet
Assigned Numbers Authority (IANA).
The <EXPLICIT_ROUTE> and <S2L sub-LSP descriptor list> contains the
path from the backup ingress node to the next hops of the primary
ingress, and then to the egresses. If the path from the backup
ingress node to the next hops of the primary ingress is loose, the
detailed path from the backup ingress node to the next hops needs to
be computed.
The <RECORD_ROUTE> and <S2L sub LSP flow descriptor list> comprises
the information about the path that the LSP traversed.
6.1.1.2. Processing of LSP Information Message
Similar to sending an existing RSVP-TE message such as a PATH
message, the primary ingress MUST send a updated RSVP-TE LSP
information message to the backup ingress whenever there is a change
in the RSVP-TE LSP information message. It MAY send the same RSVP-TE
LSP information message to the backup ingress every refresh interval
if there is no change.
When the backup ingress receives the RSVP-TE LSP information message
from the primary ingress, it stores the LSP information, provides and
maintains local protection for the primary ingress according to the
inforamtion in the information message.
6.1.2. Backup LSP for One-to-One Backup
When the backup ingress receives the LSP inforamtion message with the
request for protection via the one-to-one backup method from the
primary ingress, it constructs PATH messages, and sends the PATH
messages downstream accordingly. If it has not received any RSVP-TE
LSP information message for an extended period of time (e.g. a
cleanup timeout interval) and the BFD session between the primary
ingress and backup ingress is up, it SHALL remove the information
about the P2MP LSP, constructs PathTear messages, and send the
PathTear messages downstream accordingly.
When the BFD session between the primary ingress and backup ingress
is down, the backup ingress MUST keep the information about the P2MP
LSP and the state of the backup P2MP sub tree even though it has not
received any RSVP-TE LSP information message for an extended period
of time. It refreshes the PATH messages downstream for the backup
P2MP sub tree.
Chen, et al. Expires April 25, 2013 [Page 9]
Internet-Draft P2MP LSP Ingress Protection October 2012
6.1.2.1. Construction of PATH Messages
When the backup ingress node receives a P2MP LSP information message,
it checks to see if anything has been changed. If the message is a
new message or the information in the message has been changed, then
the PATH messages for the backup P2MP sub tree are to be constructed
as follows.
First, a path to the next-hop nodes of the ingress node HAS to be
computed if the path from the backup ingress to the next hops is
loose. The path MUST satisfy the constraints for the P2MP LSP and
not go through the ingress node.
If a path is computed successfully, then the PATH messages for the
backup P2MP sub tree are constructed based on the computed path and
the information message received, and sent downstream accordingly.
After sending the PATH messages, the backup ingress node receives
RESV messages from downstream nodes responding to the PATH messages.
It then processes the RESV messages and creates forwarding state
based on the information in the RESV messages.
If a path can not be found, the backup ingress node SHALL tear down
the backup P2MP sub tree created based the previous information
message.
The construction of a PATH message on a backup ingress node for a
backup P2MP sub tree is similar to the construction of a normal PATH
message on an ingress node for a P2MP LSP. It is based on LSP
information messages and a computed path for the backup P2MP sub
tree. The backup ingress node refreshes the PATH message to its
downstream nodes when the refresh reduction is not enabled.
The EXPLICIT_ROUTE object and the objects in the S2L sub-LSP
descriptor list for the PATH message may be constructed through
combining the path computed to the next-hop nodes of the ingress node
and the path from the next-hop nodes to the destination nodes of the
P2MP LSP obtained from the RECORD_ROUTE object and the objects for
the S2L sub-LSP flow descriptor list in the LSP information messages.
6.1.3. Backup LSP for Facility Backup
The backup ingress selects or creates a backup P2MP LSP tunnel from
itself to the next hop nodes of the primary LSP when it receives the
LSP inforamtion message with a request for protection via the
Facility backup method from the primary ingress.
If there exists a backup P2MP LSP tunnel from the backup ingress to
the next hop nodes of the P2MP LSP that satisifies the constraints
Chen, et al. Expires April 25, 2013 [Page 10]
Internet-Draft P2MP LSP Ingress Protection October 2012
given in the inforamtion message from the (primary) ingress, then
this tunnel is selected; otherwise, a new backup P2MP LSP tunnel from
the backup ingress to the next hop nodes of the P2MP LSP will be
created.
After having a backup P2MP LSP tunnel, the backup ingress assigns an
inner label (or upstream label) using upstream label assignment
procedures for the primary LSP.
To signal the backup P2MP LSP, a backup LSP's PATH message is sent to
each of the next hop nodes of the primary ingress of the protected
LSP. This PATH message MUST include an Upstream Assigned Label
object carrying the upstream label and an RSVP-TE P2MP LSP TLV within
an IF_ID RSVP object, carrying the session object of the P2MP Bypass
tunnel.
When the backup ingress detects a failure in the primary ingress of
the protected P2MP LSP, it has to imports the traffic for the
protected P2MP LSP into the backup P2MP bypass tunnels using the
upstream label assigned for this protected P2MP LSP as an inner
label. The backup ingress MUST send PATH messages for the protected
P2MP LSP.
6.1.4. LSP Information Confirmation Message
6.1.4.1. Format of LSP Information Confirmation Message
The format of a P2MP LSP information confirmation message is
illustrated below.
<LSP Information Confirmation Message> ::=
<Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <RRO>
<sender descriptor>
The formats and values of the objects in a P2MP LSP information
confirmation message are similar to or the same as those of the
corresponding objects defined in RFC4875.
The value of the Msg Type field in the common header in the P2MP LSP
information confirmation message will be a new number such as 69 for
the LSP information confirmation message, or may be another number
assigned by Internet Assigned Numbers Authority (IANA).
Chen, et al. Expires April 25, 2013 [Page 11]
Internet-Draft P2MP LSP Ingress Protection October 2012
6.1.4.2. Processing of LSP Information Confirmation Message
When the backup ingress node receives a RSVP-TE LSP information
message from the ingress node, it SHALL construct and send an LSP
confirmation message to the ingress node to acknowledge the message
received. If the backup LSP for locally protecting the primary
ingress is available, the backup ingress node sets "local protection
available" flag in the IPv4 (or IPv6) address sub-object of the RRO
for the primary ingress and SHOULD send the updated confirmation
message to the primary ingress.
The backup ingress node sets the "node protection" flag if the backup
path protects against the failure of the primary ingress node, and,
if the path does not, it clear the "node protection" flag.
The backup ingress node sets "bandwidth protection" flag if the
backup path offers a bandwidth guarantee, and, if the path does not,
it clear the "bandwidth protection" flag.
6.2. New RSVP-TE Objects
A desire for creating a backup LSP to locally protect the (primary)
ingress of a P2MP LSP can be sent to a backup ingress from the
primary ingress in a PATH message, which comprises the information
about the P2MP LSP and the desire.
6.2.1. Information about Existing LSP
There are <style> and <flow descriptor list> normally in a RSVP-TE
RESV message. They are "new" to a PATH message. The primary ingress
of the P2MP LSP MAY add them into the PATH message to be sent to the
backup ingress for locally protecting the (primary) ingress after it
receives a RESV message.
<style> and <flow descriptor list> contains the information about the
path that the LSP traverses. In fact, we may just add <RECORD_ROUTE>
and <S2L sub LSP flow descriptor list> into the PATH message instead
of <style> and <flow descriptor list>.
The primary ingress MUST send a updated PATH message to the backup
ingress whenever there is a change in the message. It MAY send the
same message to the backup ingress every refresh interval if there is
no change.
6.2.2. Desire for Locally Protecting Ingress
A desire for locally protecting the (primary) ingress of a P2MP LSP
MAY be implied by the "new" objects in the PATH message sent from the
Chen, et al. Expires April 25, 2013 [Page 12]
Internet-Draft P2MP LSP Ingress Protection October 2012
primary ingress to the backup ingress.
It would be better to explicitly indicate the desire in the PATH
message through using a new flag or new object.
The (primary) ingress of the LSP MAY request Ingress Local Protection
by setting a bit in the Attributes Flags TLV. It is RECOMMENDED to
use the LSP_REQUIRED_ATTRIBUTES object for the TLV.
A backup ingress that supports the Attributes Flags TLV and
recognizes this bit MUST support Ingress Local Protection.
6.2.3. Backup LSP for One-to-One Backup
When the backup ingress receives the PATH message with the request
for Ingress Local Protection and the request for protection via the
one-to-one backup method from the primary ingress, it stores the
information in the message, constructs a PATH message for a backup
LSP, and sends the PATH message downstream accordingly. If it has
not received any PATH message from the primary ingress for an
extended period of time (e.g. a cleanup timeout interval) and the BFD
session between the primary ingress and backup ingress is up, it
SHALL remove the information, constructs a PathTear message, and send
the PathTear message downstream accordingly.
The PATH message constructed for the backup LSP contains an
EXPLICIT_ROUTE object and the objects in the S2L sub-LSP descriptor
list. These objects represent a path from the backup ingress to the
next-hop nodes of the primary ingress, and to the destination nodes
of the P2MP LSP. The backup path from the backup ingress to the
next-hop nodes of the primary ingress may be computed by the backup
ingress. The path segment from the next-hop nodes of the primary
ingress to the destination nodes of the P2MP LSP may be from the
RECORD_ROUTE object and the objects for the S2L sub-LSP flow
descriptor list in the PATH message received from the primary
ingress.
6.2.4. Backup LSP for Facility Backup
The backup ingress selects or creates a backup P2MP LSP tunnel from
itself to the next hop nodes of the primary LSP when it receives a
PATH message with a request for Ingress Local Protection and a
request for protection via the Facility backup method from the
primary ingress.
If there exists a backup P2MP LSP tunnel from the backup ingress to
the next hop nodes of the P2MP LSP that satisifies the constraints
given in the PATH message from the (primary) ingress, then this
Chen, et al. Expires April 25, 2013 [Page 13]
Internet-Draft P2MP LSP Ingress Protection October 2012
tunnel is selected; otherwise, a new backup P2MP LSP tunnel from the
backup ingress to the next hop nodes of the P2MP LSP will be created.
After having a backup P2MP LSP tunnel, the backup ingress assigns an
inner label (or upstream label) using upstream label assignment
procedures for the primary LSP.
To signal the backup P2MP LSP, a backup LSP's PATH message is sent to
each of the next hop nodes of the primary ingress of the protected
LSP. This PATH message MUST include an Upstream Assigned Label
object carrying the upstream label and an RSVP-TE P2MP LSP TLV within
an IF_ID RSVP object, carrying the session object of the P2MP Bypass
tunnel.
When the backup ingress detects a failure in the primary ingress of
the protected P2MP LSP, it has to imports the traffic for the
protected P2MP LSP into the backup P2MP bypass tunnels using the
upstream label assigned for this protected P2MP LSP as an inner
label. The backup ingress MUST send PATH messages for the protected
P2MP LSP.
6.3. OSPF Opaque LSA
The information about a P2MP LSP may be transferred through using an
OSPF Opaque LSA.
On the ingress node, RSVP-TE needs to be changed to send the
information to OSPF when there is a change on the information about
the P2MP LSP. OSPF needs to be changed to receive the information
about the P2MP LSP from RSVP-TE and distribute the information in
Opaque LSA to the OSPF on the backup ingress node.
On the backup ingress node, OSPF needs to be changed to receive the
information in Opaque LSA from the ingress ndoe and send the
information to RSVP-TE. RSVP-TE needs to be changed to receive the
information about the P2MP LSP from OSPF.
7. IANA Considerations
TBD
8. Acknowledgement
The authors would like to thank Richard Li, Rahul Aggarwal, Olufemi
Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, Yimin Shen,
Ronhazli Adam and Quintin Zhao for their valuable comments and
Chen, et al. Expires April 25, 2013 [Page 14]
Internet-Draft P2MP LSP Ingress Protection October 2012
suggestions on this draft.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[P2MP FRR]
Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux,
"P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels",
draft-leroux-mpls-p2mp-te-bypass , March 1997.
Chen, et al. Expires April 25, 2013 [Page 15]
Internet-Draft P2MP LSP Ingress Protection October 2012
9.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
Authors' Addresses
Huaimo Chen
Huawei Technologies
Boston, MA
USA
Email: huaimo.chen@huawei.com
Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ning.so@tatacommunications.com
Autumn Liu
Ericsson
CA
USA
Email: autumn.liu@ericsson.com
Lei Liu
KDDI R&D Lab Inc.
2-1-15
Ohara Fujimino-shi, Saitama
Japan
Email: le-liu@kddilabs.jp
Chen, et al. Expires April 25, 2013 [Page 16]