Network working group J. Dong
Internet Draft M. Chen
Intended status: Standards Track C. Liu
Expires: April 25, 2011 Huawei Technologies
S. Luo
China Telecom
October 25, 2010
Flexible MPLS-TE Fast Reroute
draft-dong-mpls-rsvp-te-plr-designation-01.txt
Abstract
This document defines RSVP-TE extensions which enable the ingress
node to designate particular LSRs along the path as Points of Local
Repair (PLRs) of the protected LSP, and further indicate the
protection type of each PLR. These mechanisms could enhance the
control over the establishment of backup LSPs, achieve more flexible
TE FRR and also could save the resources needed for establishing and
maintaining unnecessary backup LSPs.
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 April 25, 2011.
Dong, et al. Expires April 25, 2011 [Page 1]
Internet-Draft Designation of PLRs in TE FRR October 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
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document ........................... 3
3. Problem Statement ........................................... 3
4. Possible Solutions .......................................... 4
4.1. SERO Based Mechanism ................................... 4
4.2. ERO Based Mechanism .................................... 5
4.2.1. Extensions to IPv4 Prefix Subobject ............... 5
4.2.2. Extensions to IPv6 Prefix Subobject ............... 6
4.2.3. Backward Compatibility ............................ 6
5. Selection of PLRs and Protection Type ....................... 7
6. Operations of ERO Based Mechanism ........................... 7
6.1. Operation of Head End .................................. 7
6.2. Operation of Other LSRs ................................ 7
7. Security Considerations ..................................... 7
8. IANA Considerations ......................................... 7
9. References .................................................. 7
9.1. Normative References ................................... 7
9.2. Informative References ................................. 8
Authors' Addresses ............................................. 9
1. Introduction
Currently the fast reroute mechanisms of RSVP-TE [RFC4090] enable the
ingress node of protected LSP to indicate whether local protection is
desired and whether node protection is desired for this LSP. However,
such indication is relevant to the whole LSP, the ingress node cannot
indicate which LSRs on the path are required to be Points of Local
Repair (PLRs), and the protection type of each PLR.
Dong, et al. Expires April 25, 2011 [Page 2]
Internet-Draft Designation of PLRs in TE FRR October 2010
This document describes possible solutions for PLR designation in TE
fast reroute, and defines simple extensions to RSVP-TE to achieve
flexible TE FRR which is backward compatible with RFC 4090.
These mechanisms could provide the operators with more control of the
backup LSPs, this is useful when only a subset of the LSRs on the
path are required to operate as PLRs. Also, this could avoid
unnecessary signaling and bandwidth reservation for protection of
components which are not quite likely to fail. Thirdly, this could
relieve the burden on LSRs which may not have enough resources to
perform local protection functions.
2. 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 [RFC2119].
3. Problem Statement
RFC 4090 has defined mechanisms to establish local protection for a
particular LSP. The fast reroute mechanisms of RFC 4090 enable the
ingress node of the protected LSP to indicate whether local
protection is desired and what protection type is needed for this LSP.
However, such specification is at the granularity of LSP level, the
ingress node cannot explicitly designate which LSRs along the path
are required to be PLRs, and the protection type on each PLR.
In some networks some of the links and nodes can be more reliable
than the others, e.g. some links may reside in the same building or
have redundancy in the physical layer, and some nodes can have good
redundancy in both data plane and control plane. Thus there are fewer
requirements to protect such links and nodes on LSP level.
Based on the reliability information of the network and service
providers' local policy, the operators may prefer to protect only a
subset of the links and nodes along the path, thus the ingress node
needs to specify particular LSRs as PLRs, and the protection type on
each PLR. This can be helpful in many aspects. Firstly, this enables
the operators to setup the backup LSPs they need in a more
controllable way. Secondly, this could avoid unnecessary signaling
and bandwidth reservation for protection of links and nodes which are
unlikely to fail. Thirdly, this could relieve the burden on LSRs
which may not have enough resources to perform local protection
functions.
Dong, et al. Expires April 25, 2011 [Page 3]
Internet-Draft Designation of PLRs in TE FRR October 2010
This document describes possible solutions for PLR designation, and
defines simple extensions to RSVP-TE to achieve flexible TE FRR which
is backward compatible with RFC 4090.
4. Possible Solutions
4.1. SERO Based Mechanism
GMPLS Segment Recovery [RFC4873] provides one mechanism to specify
segment recovery LSPs using SECONDARY_EXPLICIT_ROUTE Object (SERO).
An SERO can indicate a recovery LSP's initiator and terminator,
standard ERO semantics can optionally be used in SERO to explicitly
control the recovery LSP, and a new subobject called Protection is
defined to indicate the type of protection or restoration to be
provided. Another new Object called SECONDARY_RECORD_ROUTE Object
(SRRO) is also defined for this procedure. Detailed mechanisms are
specified in section 4 of RFC 4873.
For MPLS networks which support extensions and Objects defined for
GMPLS such as SERO, SRRO and PROTECTION, and the operators desire to
explicitly specify the path of the recovery LSPs, the SERO based
mechanism can be used. Currently there is no detailed specification
about the combination use of MPLS-TE FRR [RFC4090] and GMPLS segment
recovery [RFC4873]. This section only gives some brief instructions
to this mechanism, detailed specification is for further study.
Association between protected LSP and backup LSP: according to RFC
4090, the association is based on the same SESSION Object and the
same LSP ID in SENDER_TEMPLATE Object, the only field that varies is
the IPv4 (or IPv6) tunnel sender address in SENDER_TEMPLATE Object.
The ASSOCIATION Object defined in [RFC4872] MUST not be used.
Designation of PLR and MP: SERO is used to indicate the PLR and the
Merge point (MP) of the backup LSP, and optionally to explicitly
specify the path of the backup LSP. Note that explicitly designating
PLR and MP implies the protection type of TE FRR, i.e. Node
Protection or Link Protection.
The PROTECTION subobject in SERO is used to create the PROTECTION
object for the recovery LSP. For TE fast reroute, the protection type
SHOULD be set to 0x04 (1:N Protection with Extra-Traffic).
Note a node receiving a Path message containing one or more SEROs
SHOULD examine each SERO to see if it indicates a local branch point.
In scenarios where many backup LSPs are specified using SEROs, this
may bring extra burden to nodes which do not have enough control
plane resources.
Dong, et al. Expires April 25, 2011 [Page 4]
Internet-Draft Designation of PLRs in TE FRR October 2010
4.2. ERO Based Mechanism
For MPLS networks which do not support the RSVP extensions for GMPLS,
the SERO based mechanism may not be applicable. And for operators
which do not desire to explicitly specify each node of the backup
LSPs, the procedures of SERO based mechanism seems a bit complicated.
This section defines simple extensions to Explicit_Route Object (ERO)
to achieve flexible PLR designation and protection type indication.
The Explicit_Route Object (ERO) is extended to carry information of
PLR designation and type of local protection. The low order bits of
the Reserved field in IPv4 prefix and IPv6 prefix subobjects are used
as flags to indicate whether the LSR represented by the subobject
should operate as a PLR and the desired protection type.
4.2.1. Extensions to IPv4 Prefix Subobject
Two new flags are defined in this subobject. The structure of
extended IPv4 prefix subobject is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Reserved |P|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P: Local Protection flag. The P bit indicates whether this subobject
is designated as a PLR. It will be set to 0 if the node is designated
to be a PLR for the protected LSP, and set to 1 otherwise. If the
"Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is
not set, no local protection will be used for the whole LSP, and the
value of the P bit is insignificant.
N: Node Protection flag. The N bit indicates whether node protection
is required for this subobject. It will be set to 1 if node
protection is desired, and set to zero if the protection type is
indicated by the Node Protection Flag in the SESSION_ATTRIBUTE Object.
Note the N bit makes sense only when the "Local Protection Desired"
flag in the SESSION_ATTRIBUTE Object is set and the above P bit is
set to 0.
Dong, et al. Expires April 25, 2011 [Page 5]
Internet-Draft Designation of PLRs in TE FRR October 2010
4.2.2. Extensions to IPv6 Prefix Subobject
Two new flags are defined in this subobject. The structure of
extended IPv6 prefix subobject is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Reserved |P|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P: Local Protection flag. The P bit indicates whether this subobject
is designated as a PLR. It will be set to 0 if the node is designated
to be a PLR for the protected LSP, and set to 1 otherwise. If the
"Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is
not set, no local protection will be used for the whole LSP, and the
value of the P bit is insignificant.
N: Node Protection flag. The N bit indicates whether node protection
is required for this subobject. It will be set to 1 if node
protection is desired, and set to zero if the protection type is
indicated by the Node Protection Flag in the SESSION_ATTRIBUTE Object.
Note the N bit makes sense only when the "Local Protection Desired"
flag in the SESSION_ATTRIBUTE Object is set and the above P bit is
set to 0.
4.2.3. Backward Compatibility
The P bit and N bit are designed to be backward compatible with
current protection mechanisms. LSRs which do not support this
extension will treat these bits as reserved bit and ignore the value
of them. When both the 2 bits are set to 0 by head end LSR, the
protection behavior of all other LSRs on the path (no matter support
this extension or not) is the same as current TE FRR mechanisms.
Dong, et al. Expires April 25, 2011 [Page 6]
Internet-Draft Designation of PLRs in TE FRR October 2010
5. Selection of PLRs and Protection Type
The selection of PLRs and the protection type on each PLR are based
on the reliability information of the network and local policy of the
service provider. Service providers may have knowledge about which
links and nodes in the network are more reliable, and which nodes are
not suitable to be PLRs. This kind of information may be obtained by
some information advertisement mechanism, or through methods outside
the scope of protocols. Based on this information, the operator or
the ingress node could designate a subset of LSRs as PLRs and specify
the protection type.
6. Operations of ERO Based Mechanism
6.1. Operation of Head End
Based on the result of PLR selection and the required protection type
on each PLR, the head-end LSR SHOULD appropriately set the P bit and
N bit in corresponding ERO subobjects in the PATH message.
6.2. Operation of Other LSRs
On receipt of a PATH message, the LSR SHOULD check the "Local
Protection Desired" and "Node protection desired" flags in the
SESSION Attribute Object along with the P bit and N bit in
corresponding ERO subobjects, and perform local protection based on
these flags.
If some LSR on the path needs to add subobjects to the ERO, it MAY
set the P bit and N bit of the subobjects based on local policy.
7. Security Considerations
This document does not introduce new security issues.
8. IANA Considerations
There is no IANA action required by 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.
Dong, et al. Expires April 25, 2011 [Page 7]
Internet-Draft Designation of PLRs in TE FRR October 2010
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4090] Pan, P., Swallow, G. and Atlas, A., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC4090, May 2005.
9.2. Informative References
[RFC4872] Lang, J.P., Rekhter, Y. and Papadimitriou, D., "RSVP-TE
Extensions in Support of End-to-End GMPLS Recovery", RFC
4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, A.,
"GMPLS Segment Recovery", RFC 4873, May 2007.
Dong, et al. Expires April 25, 2011 [Page 8]
Internet-Draft Designation of PLRs in TE FRR October 2010
Authors' Addresses
Jie Dong
Huawei Technologies Co.,Ltd
Huawei Building, No.3 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
EMail: dongjie_dj@huawei.com
Mach(Guoyi) Chen
Huawei Technologies Co.,Ltd
Huawei Building, No.3 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
EMail: mach@huawei.com
Chun Liu
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.
Hai-Dian District
Beijing, 100095
P.R. China
EMail: liuchuner1981@huawei.com
SongFeng Luo
China Telecom
109 West Zhongshan Ave,
Tianhe District, Guanghou, 510630, P.R.C
EMail: luosf08@163.com
Dong, et al. Expires April 25, 2011 [Page 9]