Internet Engineering Task Force H. Chen
Internet-Draft Huawei Technology, Inc.
Intended status: Standards Track February 28, 2010
Expires: September 1, 2010
Extensions to RSVP-TE for P2MP LSP Ingress Local Protection
draft-chen-mpls-p2mp-ingress-protection-00.txt
Abstract
This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting ingress nodes of
Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched
Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) networks.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2010.
Copyright Notice
Copyright (c) 2010 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
Chen Expires September 1, 2010 [Page 1]
Internet-Draft P2MP LSP Ingress Protection February 2010
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. LSP Information Message . . . . . . . . . . . . . . . . . . . 5
5.1. Format of LSP Information Message . . . . . . . . . . . . 5
5.2. Processing of LSP Information Message . . . . . . . . . . 6
6. LSP Information Confirmation Message . . . . . . . . . . . . . 6
6.1. Format of LSP Information Confirmation Message . . . . . . 7
6.2. Processing of LSP Information Confirmation Message . . . . 7
7. PATH Messages for Backup P2MP sub Tree . . . . . . . . . . . . 8
7.1. Construction of PATH Messages . . . . . . . . . . . . . . 8
7.2. Processing of PATH Messages . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chen Expires September 1, 2010 [Page 2]
Internet-Draft P2MP LSP Ingress Protection February 2010
1. Introduction
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels" RFC4090
describes two methods to protect P2P LSP tunnels or paths at local
repair points. For a P2P LSP, the local repair points may comprise a
plurality of intermediate nodes between the ingress node and the
egress node of the P2P LSP. 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.
"Extensions to RSVP-TE for P2MP TE LSPs" RFC4875 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.
The existing methods for protecting an ingress node of a P2MP LSP
that is from the ingress node to a plurality of destination nodes may
be classified into two categories. The first category uses a backup
P2MP LSP that is from a backup ingress node to the plurality of
destination nodes. The disadvantages of this class of methods
include more network resource such as computer power and link
bandwidth consumption since the backup P2MP LSP is from the backup
ingress node to the plurality of destination nodes. The second
category extends the existing methods for protecting an intermediate
node of a P2P LSP to protect an ingress node of a P2MP LSP. The
disadvantages of this class of methods 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 through using a backup P2MP sub tree. The
disadvantages in the existing methods for protecting an ingress node
of a P2MP LSP mentioned above disappear in the protection mechanism
described below.
2. Terminology
This document uses terminologies defined in RFC2205, RFC3031,
RFC3209, RFC3473, RFC4090, RFC4461, and RFC4875.
Chen Expires September 1, 2010 [Page 3]
Internet-Draft P2MP LSP Ingress Protection February 2010
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. For
the ingress node of the P2MP LSP, a backup ingress node is designated
to protect the ingress node. The backup ingress node initiates the
creation of the backup P2MP sub tree from the backup ingress node to
the next-hop nodes of the ingress node of the P2MP LSP based on the
information about the P2MP LSP. The ingress node of the P2MP LSP
sends the information about the P2MP LSP to the backup 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 that
are the same as those of the P2MP LSP, and receives and processes
RSVP-TE RESV messages that response to the PATH messages.
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
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 is delivered to the backup ingress node
from an external node or network. The forwarding entry for a 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.
On each of the next-hop nodes of the ingress node of the P2MP LSP,
the forwarding entry for the backup P2MP sub tree is created with an
inactive state or flag when the backup P2MP sub tree is set up.
When a failure of the ingress node happens, the state or flag of the
forwarding entry for the backup P2MP sub tree on the backup ingress
node is set to be active, and the forwarding entry for the backup
P2MP sub tree on each of the next-hop nodes of the ingress node is
also set to be active. Thus when the data traffic from the external
Chen Expires September 1, 2010 [Page 4]
Internet-Draft P2MP LSP Ingress Protection February 2010
node or network reaches the backup ingress node, it is imported into
the backup P2MP sub tree on the backup ingress node through the
active forwarding entry on the backup ingress node. When the data
traffic arrives at the next-hop nodes of the ingress node through the
backup P2MP sub tree that is from the backup ingress node to the
next-hop nodes of the ingress node, the data traffic is merged into
the P2MP LSP on these next-hop nodes and then transported to the
destinations of the P2MP LSP.
After the failure of the ingress node, 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, which make the P2MP LSP alive.
5. LSP Information Message
LSP information messages are used to transfer the information about a
P2MP LSP to a backup ingress node from an ingress node. This section
describes the format of an LSP information message and processing of
the message.
5.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>
Chen Expires September 1, 2010 [Page 5]
Internet-Draft P2MP LSP Ingress Protection February 2010
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 values of the RECORD_ROUTE and the
S2L sub LSP flow descriptor list describe the path that the P2MP LSP
traverses, which may be obtained from the RECORD_ROUTE object and the
S2L sub-LSP flow descriptor list in a RSVP-TE RESV message that the
ingress node of the P2MP LSP receives.
The values of the fields in the common header in a P2MP LSP
information message is similar to or the same as those in the common
header in an existing RSVP-TE message such as a PATH message that the
ingress node of the P2MP LSP sends to one of the next-hop nodes of
the ingress node. The value of the Msg Type field in the common
header in the P2MP LSP information message will be a new number such
as 68 for the LSP information message, or may be another number
assigned by Internet Assigned Numbers Authority (IANA).
5.2. Processing of LSP Information Message
The ingress node of a P2MP LSP sends a RSVP-TE LSP information
message for the P2MP LSP to a backup ingress node of the P2MP LSP.
Similar to sending an existing RSVP-TE message such as a PATH
message, the ingress node sends a updated RSVP-TE LSP information
message to the backup ingress node whenever there is a change in the
RSVP-TE LSP information message; the ingress node may send the same
RSVP-TE LSP information message to the backup ingress node every
refresh interval if there is not any change in the RSVP-TE LSP
information message.
When the backup ingress node receives the RSVP-TE LSP information
message from the ingress node, the backup ingress node stores the
information about the P2MP LSP, constructs a PATH message or a
plurality of PATH messages based on the information about the P2MP
LSP, and sends the PATH messages downstream accordingly. If the
backup ingress node does not receive any RSVP-TE LSP information
message for the P2MP LSP for a period of time such as a cleanup
timeout interval, the backup ingress node removes the information
about the P2MP LSP, constructs a PathTear message or a plurality of
PathTear messages, and sends the PathTear messages downstream
accordingly.
6. LSP Information Confirmation Message
LSP information confirmation messages are used to confirm that the
corresponding LSP information messages are received. With the
Chen Expires September 1, 2010 [Page 6]
Internet-Draft P2MP LSP Ingress Protection February 2010
confirmation messages, the refresh of the LSP information messages is
not needed. This section describes the format of an LSP information
confirmation message and processing of the message.
6.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>
<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 values of the fields in the common header in a P2MP LSP
information confirmation message is similar to or the same as those
in the common header in an existing RSVP-TE message such as a PATH
message that the ingress node of the P2MP LSP sends to one of the
next-hop nodes of the ingress node. 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).
6.2. Processing of LSP Information Confirmation Message
When the backup ingress node receives a RSVP-TE LSP information
message from the ingress node of a P2MP LSP, the backup ingress node
constructs and sends an LSP information confirmation message to the
ingress node to acknowledge the ingress node that the LSP information
message has been received.
After the ingress node receives the LSP information confirmation
message, it stops refreshing the LSP information message.
Chen Expires September 1, 2010 [Page 7]
Internet-Draft P2MP LSP Ingress Protection February 2010
7. PATH Messages for Backup P2MP sub Tree
PATH messages for a backup P2MP sub tree has the same format as PATH
messages for a P2MP LSP defined in RFC 4875. This section describes
the construction of the PATH messages for the backup P2MP sub tree,
which is followed by processing of the PATH messages.
7.1. Construction of PATH Messages
When a backup ingress node receives an LSP information message, it
checks the information about the P2MP LSP in the message to see
whether the message is a new message for the P2MP LSP or the
information in the message is changed compared with the information
in a previous message for the P2MP LSP received. If the message is a
new message or the information in the message is changed, then the
PATH messages for the backup P2MP sub tree are to be constructed as
follows.
At first, a path to the next-hop nodes of the ingress node of the
P2MP LSP is to be computed. 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 path computed and
the information message received, and sent downstream accordingly.
After sending the PATH messages, the backup ingress node receives
RESV messages from downstream nodes that response the PATH messages,
processes the RESV messages and creates forwarding state based on the
information in the RESV messages.
If a path can not be found, then the backup ingress node may tear
down the backup P2MP sub tree that is created based the previous
information message for the P2MP LSP through constructing and sending
PathTear messages downstream accordingly if the backup P2MP sub tree
exists.
Constructing a PATH message based on an LSP information message and a
computed path comprises constructing a common header and a first
group of objects such as a SESSION object, a SESSION_ATTRIBUTE object
and a TIME_VALUES object, a second group of objects such as a
RSVP_HOP object and a RECORD_ROUTE object, and a third group of
objects such as a SENDER_TEMPLATE object, an EXPLICIT_ROUTE object
and objects in an S2L sub-LSP descriptor list for the PATH message.
The common header for the PATH message may be constructed through
setting the Vers field, the Flags field and the Reserved field in the
common header of the PATH message to the corresponding values of the
Vers field, the Flags field and the Reserved field in the common
Chen Expires September 1, 2010 [Page 8]
Internet-Draft P2MP LSP Ingress Protection February 2010
header of the LSP information message. The other fields such as the
Msg Type field, RSVP Checksum field, Send_TTL field and RSVP Length
field may be set in a way similar to or same as setting them in a
normal PATH message.
The first group of objects for the PATH message may be constructed
through copying the corresponding objects from the LSP information
message. The second group of objects may be constructed in a similar
or same way for constructing them in a normal PATH message.
In the third group, the SENDER_TEMPLATE object may be constructed
through setting the tunnel sender address field, the first Reserved
field and the LSP ID field in the object to the corresponding values
of the tunnel sender address field, the first Reserved field and the
LSP ID field in the SENDER_TEMPLATE object in the LSP information
message, setting the Sub-Group Originator ID field to the TE Router
ID of the backup ingress node, and setting the second Reserved field
and the Sub-Group ID in a similar or same way for setting them in a
normal PATH message.
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 that may be obtained from the RECORD_ROUTE object and the
objects for the S2L sub-LSP flow descriptor list in the LSP
information message. Alternatively, a plurality of intermediate
nodes and links in the path from a next-hop node of the ingress node
to a destination node may be removed and thus the path from the next-
hop node to the destination may be represented just by the
destination node.
7.2. Processing of PATH Messages
The processing of PATH messages on the intermediate nodes along the
backup P2MP sub tree is the same as the processing of PATH messages
for a P2MP LSP.
On each of the next-hop nodes of the ingress node of the P2MP LSP,
after receiving a PATH message for the backup P2MP sub tree from a
upstream node, it may merge the PATH message with a number of PATH
messages that it sends to its next-hop nodes for the P2MP LSP.
Alternatively, it may generate a number of PATH messages based on the
PATH message received and sends the PATH messages to its next-hop
nodes accordingly.
Chen Expires September 1, 2010 [Page 9]
Internet-Draft P2MP LSP Ingress Protection February 2010
8. IANA Considerations
TBD
9. Acknowledgement
The author would like to thank Quintin Zhao for his valuable comments
on this draft.
10. References
10.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.
Chen Expires September 1, 2010 [Page 10]
Internet-Draft P2MP LSP Ingress Protection February 2010
10.2. Informative References
Author's Address
Huaimo Chen
Huawei Technology, Inc.
125 Nagog Technology Park
Acton, MA 01719
US
Email: Huaimochen@huawei.com
Chen Expires September 1, 2010 [Page 11]
