Internet DRAFT - draft-guobl-pce-rsvp
draft-guobl-pce-rsvp
Network Working Group BL. Guo
Internet-Draft SG. Huang
Intended status: Informational BUPT
Expires: April 22, 2011 DJ. Wang
ZY. Wang
H. Ma
ZTE Corporation
October 19, 2010
RSVP-TE Extension for path computation based on PCE architecture in
inter-layer and inter-domain network
draft-guobl-pce-rsvp-00
Abstract
The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in multi-domain Multi-
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. In this context, the ability to compute Traffic
Engineering Label Switched Paths (TE LSPs) in MPLS and GMPLS networks
across multiple domains has been identified as a key requirement.
This document specifies the routing and wavelength assignment (RWA)
procedures and potential extensions for the use of Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in PCE
based MPLS-TE packet networks and GMPLS packet and non-packet
networks to support a flexible establishment and maintenance of Label
Switched Paths that cross domain boundaries or cross layers.
Status of this Memo
This Internet-Draft is submitted 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 22, 2011.
Copyright Notice
Guo, et al. Expires April 22, 2011 [Page 1]
Internet-Draft RSVP-TE Extension October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. RWA Mechanisms in PCE based Multi-domain and Multi-layer
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Separated Path Computation Process and RSVP Process
with Explicit End to End Route Information . . . . . . . . 4
2.2. Coordinated Path Computation Process and RSVP Process
with Loose Route Information . . . . . . . . . . . . . . . 5
3. Detailed Extension for Border Node Procedure . . . . . . . . . 6
4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 7
5. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Attribute Flags for LSP_Attributes Object . . . . . . . . . . 8
8. New Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9
10.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 9
10.2. New Error-Type And Error-Value . . . . . . . . . . . . . . 9
10.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. Other Authors . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Yongli Zhao . . . . . . . . . . . . . . . . . . . . . . . 10
12.2. Jie Zhang . . . . . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
13.2. INFORMAL References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Guo, et al. Expires April 22, 2011 [Page 2]
Internet-Draft RSVP-TE Extension October 2010
1. Introduction
1.1. Introduction
[RFC4726] defines the framework for inter-domain Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) (inter-area and inter-AS
TE), and the technique for establishing an inter-domain Generalized
MPLS (GMPLS) TE Label Switched Path (LSP) has been provided by
[RFC5152], whereby the path is computed during the signaling process
on a per-domain basis by the entry boundary node of each domain (each
node responsible for triggering the computation of a section of an
inter-domain TE LSP path is always along the path of such TE LSP).
The employment of PCE in MPLS and GMPLS multi-domain network provides
a great flexibility for routing and resources reserving problem.
This document presents the potential integrated routing and singling
procedure in PCE based MPLS and GMPLS multi-domain network and
defines the RSVP-TE protocol extensions necessary to support the
routing and singling approaches of end-to-end inter-domain TE LSP..
Three different signaling methods for inter-domain RSVP-TE signaling
are identified in [RFC4726]. Contiguous LSPs are achieved using the
procedures of [RFC3209] and [RFC3473] to create a single end-to-end
LSP that spans all domains. Nested LSPs are established using the
techniques described in [RFC4206] to carry the end-to-end LSP in a
separate tunnel across each domain. Stitched LSPs are established
using the procedures of [LSP-STITCHING] to construct an end-to-end
LSP from the concatenation of separate LSPs each spanning a domain.
For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space
or path computation responsibility. Examples of such domains include
Autonomous Systems, Interior Gateway Protocol (IGP) routing areas,
and GMPLS overlay networks.
This document is subject to all the assumption described in RFC5152.
Several of the new features described in this document were motivated
by the requirements for traffic engineering over MPLS [RFC5441].
1.2. Requirements Language
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 [RFC2119].
Guo, et al. Expires April 22, 2011 [Page 3]
Internet-Draft RSVP-TE Extension October 2010
1.3. Terminology
AS: Autonomous System.
ASBR: Autonomous System Border Router. A router used to connect
together ASs of a different or the same Service Provider via one or
more inter-AS links.
ERO: Explicit Route Object.
LSR: Label Switching Router.
TE link: Traffic Engineering link.
TED: Traffic Engineering Database.
The notion of contiguous, stitched and nested TE LSPs is defined in
[RFC4726] and will not be repeated here.
2. RWA Mechanisms in PCE based Multi-domain and Multi-layer Network
2.1. Separated Path Computation Process and RSVP Process with Explicit
End to End Route Information
In multi-domain and multi-layer network, when the head-end router
receives the path computation request, it would communicate with the
PCE in its own domain. One possible routing approach is to provide
strict hop with ERO of the end-to-end path by cooperation between
PCEs with different TE visibility, then start the RSVP singling
approach defined in [RFC5151].
In this case, it is not necessary to extend the RSVP with inter-
domain extension (RFC5151) and the singling method depends on the
configuration of ingress node and intermediate node or other policies
applied.
Furthermore, the whole resources reservation procedure for such end-
to-end path belongs to the same RSVP Session.
Guo, et al. Expires April 22, 2011 [Page 4]
Internet-Draft RSVP-TE Extension October 2010
End to +-----+ +----+
End LSP Req| |Request | |
+--------->| PCE |________\|PCE |
| +----->| | /| |
| | | |/_______ | |
| | +-----+\ +----+
| | Responce|
| |Explicit Route |
| | |
| | |
| | |
| | Signaling Protocol|
| |with Explicit Route|
| \ / Information |
+---------+ +------+ | +------+
| |-->| | |\ | |
|Head-End |---|Border|------ |Border|
| Node | | Node |----|/-| Node |
+---------+ +------+ | +------+
| Domain 1 | Domain 2
cooperation between different layer or domain
2.2. Coordinated Path Computation Process and RSVP Process with Loose
Route Information
[RFC5151] defines a per-domain path computation technique for
establishing inter-domain TE MPLS and GMPLS LSPs. Per-domain
computation applies where the full path of an inter-domain TE LSP
cannot be or is not determined at the ingress node of the TE LSP, and
is not signaled across domain boundaries.
After receiving the end-to-end multi-domain or multi-layer path
request from any one PCC, an alternative approach of end-to-end path
computation is to get a loose route first from the PCE with local
visibility (not including the ERO in remote domain), then the
singling message which carries the loose hop information arrive the
next domain and trigger the intra domain path computation by local
PCE (shown in Fig.2) (dynamically computed based on the instant
information of the network or static/fixed route). It implies an
extension of the RSVP singling message, e.g. including the path
computing request information restricted/specified by the head-end
node, as well as the message type that could be used to trigger a
path computing request.
Guo, et al. Expires April 22, 2011 [Page 5]
Internet-Draft RSVP-TE Extension October 2010
End to +-------+_Request_\ +------+
End LSP Req| | / | |
+------------>| PCE |/__Responce_| PCE |
| +-------->| |\ +--->| |
| | | | | +--| |
| | +-------+ | | +------+
| | | | |
| |Loose Route |Seg- | |Explicit
| | |ment | |Route
| | |LSP | |
| | |Req | |Signaling
| | Signaling Protocol| | |Protocol
| | with Loose Route| | |with Explicit
| \ / Information | |\|/RouteInformation
+---------+ +-------+ | +-------+ +--------+
| |->| | _|_\ | | | |
|Head-End |--| Border| | / |Border |- |Adjacent|
| Node | | Node |__|___| Node | | Node |
+---------+ +-------+ | +-------+ +--------+
| Domain 1 | Domain 2
cooperation between different layer or domain
3. Detailed Extension for Border Node Procedure
The ERO that an ASBR receives in the Path message was supplied by the
ingress node of the TE LSP and may have been updated by other nodes
(for example, other domain border nodes) as the Path message was
propagated.
Based on the Separated Path Computation Process and RSVP Process,
which carries with Explicit End to End Route Information, it is
unnecessary for the Border Nodes to make any additional process
except the ERO process described in RFC5151. Actually, the Border
Nodes don!_t need to do any path computation related action for the
individual resource reservation purpose, without consideration of the
path reoptimization and failure crackback.
If the ingress node choose coordinated path computation process and
RSVP process, which carries with loose hops, and the ERO subobject
identifies a TE link formed by the advertisement of an H-LSP or LSP
segment (whether numbered or unnumbered), contiguous signaling MUST
NOT be used. The node MUST use either nesting or stitching according
to the capabilities of the LSP that forms the TE link, the parameters
signaled in the Path message, and local policy. If there is a
Guo, et al. Expires April 22, 2011 [Page 6]
Internet-Draft RSVP-TE Extension October 2010
conflict between the capabilities of the LSP that forms the TE link
indicated in the ERO and the parameters on the Path message, the
domain border node SHOULD send a PathErr message with error code
"Routing Problem"/"ERO conflicts with inter-domain signaling
method",.
What!_s more, in this case, an ERO in a Path message received by a
domain border node may have a loose hop as the next hop. This may be
an IP address or an AS number. So, the ERO MUST be expanded to
determine the path to the next hop using some form of a path request
or path querying message, according to the path computation process
applied in the ingress node.
The LSP Setup Failure processing, RRO Processing and Notify Message
Processing are subject to the definition in [RFC5151].
4. RSVP-TE Signaling Extensions
The following RSVP-TE signaling extensions are defined to enable
inter-domain LSP setup in multi-domain and multi-layer MPLS or GMPLS
enabled network.
In many network environments, there may be a network-wide policy that
determines which one of the three inter-domain LSP techniques is
used. In these cases, no protocol extensions are required.
However, in environments that support more than one technique, an
ingress node may wish to constrain the choice made by domain border
nodes for each inter-domain TE LSP that it originates.
When the ingress node deploys the separated path computation process,
contiguous singling scheme would not be supported, and nested or
stitched could be chosen freely according to the configuration of
node or domain; as the opposite, for coordinated path computation
process, it is suitable for contiguous singling scheme.
At the ASBR, RSVP message could trigger a path computation request or
a routing looking up message to check the static path/route already
stored in each PCE. The chosen of message type depends on the
constraints in PathReq of ingress node. Also, there already have
some definition in RFC5151 for the path request message, but it is
necessary to extend for the looking up message.
5. PCEP Extension
when PCC submit a path computation request to PCE, the PathReq
Guo, et al. Expires April 22, 2011 [Page 7]
Internet-Draft RSVP-TE Extension October 2010
message should include the related RWA strategy information, one of
which is to return an ERO of the end-to-end path and the other isn!_t
(just loose hops). In particular, there are two potential strategies
to implement the loose hop option, looking up the static route
information but without distributed among the whole network or the
path computing dynamically after the reservation singling arrives.
6. IANA Considerations
[RFC4420] defines the LSP_Attributes object that can be used to
signal required attributes of an LSP. The Attributes Flags TLV
includes Boolean flags that define individual attributes.
This document defines a new bit in the TLV that can be set by the
PCC/head-end router of an inter-domain TE LSP to define the RWA
approach:RWA of LSP bit.
This flag is set by the PCC/head-end router that originates a Path
request to set up an inter-domain TE LSP if it requires that the
coordinated path computation and RSVP process with loose hop
information This flag bit is only to be used in the Attributes Flags
TLV.IANA has made the code point allocations described in the
following sections.
7. Attribute Flags for LSP_Attributes Object
A new bit has been allocated from the "Attributes Flags" sub-registry
of the "RSVP TE Parameters" registry.
Bit| Name |Attribute | Path |RRO |Reference
No | |Flags Path| Flags Resv| |
---+------+----------+-----------+----+--------
4 C-LSP Yes No Yes [RFC5150]
Attribute Flags for LSP_Attributes Objec
8. New Error Codes
New RSVP error codes/values have been allocated from the "Error Codes
and Globally-Defined Error Value Sub-Codes" sub-registry of the "RSVP
Parameters" registry.
For the existing error code "Policy control failure" (value 2), two
new error values have been registered as follows:103 = Inter-domain
Guo, et al. Expires April 22, 2011 [Page 8]
Internet-Draft RSVP-TE Extension October 2010
policy failureGBP[not]104 = Inter-domain explicit route rejected
For the existing error code "Routing Problem" (value 24), two new
error values have been registered as follows:28 = Contiguous LSP type
not supportedGBP[not]29 = ERO conflicts with inter-domain signaling
method
9. Security Considerations
TBD.
10. IANA Consideration
10.1. New Flags Of The RP Object
A new flag of the RP object is defined in this document, which
contains 2 bits.
VSPG Flags
Bit Number Name Flag Reference
23 VSPG
24 0: from source PCE to middle PCE this document
1: from destination PCE to middle PCE
Bit 24 is valid under the assumption that bit 23 is
valid
10.2. New Error-Type And Error-Value
A new Error-Type is defined in this document (Error-Type and Error-
value to be assigned by IANA).
Error-type Meaning Reference
14 DRPC procedure completion failure this document
Error-value
1: DRPC procedure not supported by one or more PCEs
along the domain path
Guo, et al. Expires April 22, 2011 [Page 9]
Internet-Draft RSVP-TE Extension October 2010
10.3. New Flag Of The NO-PATH-VECTOR TLV
A new flag of the NO-PATH-VECTOR TLV defined in is specified in this
document.
Bit number Name Flag Reference
5 DRPC Path computation chain unavailable this document
11. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
12. Other Authors
12.1. Yongli Zhao
BUPT
No.10,Xitucheng Road,Haidian District
Beijing
100876
P.R.China
+8613811761857
yonglizhao@bupt.edu.cn
http://www.zte.com.cn
12.2. Jie Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing
100876
P.R.China
+8613911060930
Guo, et al. Expires April 22, 2011 [Page 10]
Internet-Draft RSVP-TE Extension October 2010
lgr24@bupt.edu.cn
http://www.bupt.edu.cn/
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4874] Lee, CY. and S. De , "Exclude Routes Extension to Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)",
RFC 4874, April 2007.
13.2. INFORMAL References
[RFC3209] Awduche, D., "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.
[RFC4206] Kompella, K. and Y. Rekhter., "LSP Hierarchy with
Generalized MPLS TE", RFC 4206, October 2005.
[RFC4420] Farrel., A., "Encoding of Attributes for Multiprotocol
Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using RSVP-TE", RFC 4420, February 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, ovember 2006.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, J., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February 2008.
[RFC5152] Vasseur, J., Ayyangar, A., and R. Zhang, "Extensions to
RSVP for LSP Tunnels", RFC 5152, February 2008.
Guo, et al. Expires April 22, 2011 [Page 11]
Internet-Draft RSVP-TE Extension October 2010
Authors' Addresses
Bingli Guo
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613488793951
Email: alonggnola@gmail.com
URI: http://www.bupt.edu.cn/
Shangguo Huang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613693578265
Email: shghuang@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Dajiang Wang
ZTE Corporation
12/F ZTE Plaza East Huayuan Road, Haidian District
Beijing 100191
P.R.China
Phone: +8613811795408
Email: wang.dajiang@zte.com.cn
URI: http://www.zte.com.cn/
Zhenyu Wang
ZTE Corporation
12/F ZTE Plaza East Huayuan Road, Haidian District
Beijing 100191
P.R.China
Phone: +8613911266628
Email: wang.zhenyu@zte.com.cn
URI: http://www.zte.com.cn/
Guo, et al. Expires April 22, 2011 [Page 12]
Internet-Draft RSVP-TE Extension October 2010
Heng Ma
ZTE Corporation
12/F ZTE Plaza East Huayuan Road, Haidian District
Beijing 100876
P.R.China
Phone: +8613366607720
Email: ma.heng@zte.com.cn
URI: http://www.zte.com.cn/
Guo, et al. Expires April 22, 2011 [Page 13]
