One document matched: draft-xia-pce-hybrid-network-00.txt
Network work group Hongmiao Xia
Internet Draft Dan Li
Huawei
Intended Status: Informational
Expires: December 2007 June 30, 2007
Path Computation in Multiple Autonomous Systems Networks with Path
Computation Element
draft-xia-pce-hybrid-network-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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 December 30, 2007.
Abstract
The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering in Multi-Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.
One key application of the PCE-based architecture is the computation
of inter-domain Traffic Engineering Label Switched Path (TE-LSP)
Xia & Li Expires December 30, 2007 [Page 1]
Internet-Draft Hybrid PCE Networks June 2007
paths(i.e. inter-area, inter-AS, inter-provider, etc.). In this case,
cooperation between PCEs is desirable due to the partial topology
visibility available to each separate PCE. Per-domain path
computation is another method that can be used to determine paths for
inter-domain TE-LSPs when PCE cooperation is not applied in the
network.
In practice, some Service Providers may choose not to implement PCEs
within their network that can cooperate with PCEs that are outside
their network. In this case, a scenario may exist where an LSP spans
multiple autonomous systems (ASes), some of which have PCEs capable
of cooperation with external PCEs and some of which do not. For
example, some ASes may be PCE-enabled, while others consist of just
normal LSRs.
Another scenario arises if a PCE fails or becomes unreachable. This
gives rise to the same lack of inter-PCE cooperation.
Both cases are named Hybrid PCE Networks in this document. This
document describes the specific issues introduced for end-to-end path
computation in Hybrid PCE Networks and defines extensions to the PCE
Communication Protocol (PCEP) to perform inter-domain LSP computation
in Hybrid PCE Networks.
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 [RFC2119].
Table of Contents
1. Introduction.................................................3
2. Process......................................................4
2.1. Example Scenario........................................4
2.2. Specific and Generic Cases..............................5
3. Security Considerations......................................6
4. Manageability Considerations.................................6
5. IANA Considerations..........................................6
6. Acknowledgments..............................................6
7. References...................................................6
7.1. Normative References....................................6
7.2. Informative References..................................7
8. Authors' Addresses...........................................7
9. Full Copyright Statement.....................................8
10.Intellectual Property Statement..............................8
Xia & Li Expires December 30, 2007 [Page 2]
Internet-Draft Hybrid PCE Networks June 2007
1. Introduction
The Path Computation Element (PCE) [RFC4655] provides functions of
path computation in support of traffic engineering in Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A PCE
serves path computation requests sent by Path Computation Clients
(PCC).
The PCE communication protocol (PCEP) defined in [PCEP] is designed
as a communication protocol between a PCC and a PCE, or between two
PCEs, in compliance with requirements and guidelines set forth in
[RFC4657]. Such interactions include path computation requests and
path computation replies.
One key application of the PCE-based architecture is the computation
of Label Switched Paths (LSPs) that traverse multiple Autonomous
Systems (ASes). These are referred to as inter-AS TE-LSPs. Inter-AS
MPLS TE requirements for PCEP are described in [INTERAS-TE-REQ].
When computing inter-AS LSPs, a PCE may not be able to supply a full
path because it might not have full visibility of the network
topology. Typically, a PCE can only see the topology within its own
LSA.
In this case there are two proposed path computation techniques
([RFC4726] and [RFC4655]) that involve multiple PCEs, each with
visibility into a different domain or AS.
o The per-domain computation approach [PER-DOMAIN] can be used
during LSP setup to determine the inter-domain TE LSP as it
traverses multiple domains. In this case, it is not necessary for
separate or cooperating PCEs to be used in each AS.
o The Backward Recursive Path Computation (BRPC) method [BRPC] can
also be used to compute the path of an inter-domain TE LSP. In
this case cooperating PCEs are required.
In practice, some Service Providers may choose not to implement
separate PCEs within their network, or may choose not to offer PCE
cooperation with external PCEs. Additionally, a PCE set up for inter-
PCE cooperation may fail or be unreachable
A network that contains some domains with cooperative PCEs and some
without is termed in this document a 'Hybrid PCE Network'. And a
multi-domain TE LSP may need to cross domains some of which offer
cooperating PCEs and some of which do not. Therefore, there is a
requirement to be able to compute paths as extensively as possible
Xia & Li Expires December 30, 2007 [Page 3]
Internet-Draft Hybrid PCE Networks June 2007
before signaling (using, for example, BRPC), and to rely on per-
domain computation to fill in the gaps during signaling.
This document presents PCEP extensions and procedures to enable the
computation of paths in Hybrid PCE Networks.
2. Process
2.1. Example Scenario
+---------------------------------+ +------------------+
| Provider A | | Provider B |
| PCE1 PCE2 | | |
| | | | | |
| V V | | |
| R1-----R3------R5-----R6-----|---|----R9-----R11 |
| | | / | | | | | | |
| R2-----R4---- R7---R8------|---|----R10----R12 |
| | | |
| <---AS 1---> <---AS 2---> | | <---AS 3---> |
| | | |
+---------------------------------+ +------------------+
Figure 1: Mixed Provider networks with and without PCE
Suppose provider A and B are two carrier networks. The network of
provider A is divided into two AS, AS 1 and AS 2, each of which is
deployed with a PCE. Provider B is composed of just one AS, AS 3, and
has no PCE deployed in its network (or perhaps the PCE has failed).
Assume a TE-LSP is needed between R1 and R11. The head-end node, R1,
chooses to use PCE1 to compute the path and selects BRPC as the
computation method. AS1-AS2-AS3 is provided as the AS sequence.
R1 sends a PCReq message to PCE1. PCE1 determines that PCE2 is a PCE
for AS2 and relays the PCReq message to PCE2. PCE2 finds no PCE for
the next AS to cooperate with.
If PCE2 were to just return a negative PCRep message, then this reply
would be returned to R1 and R1 could select another approach such as
the per-domain method to compute the path from R1 to R11. This is a
complete procedure, but there are two disadvantages . First, the
process falls back on the per-domain mehod which does not have such a
good chance of selecting an optimal path. Second, the process is
inefficient due to the failed BRPC attempt and the negative PCRep
message.
Xia & Li Expires December 30, 2007 [Page 4]
Internet-Draft Hybrid PCE Networks June 2007
But a combination of BRPC and per-domain path computation can be used
to increase the likelihood of achieving an optimal path. PCE2, upon
finding that there is no PCE available for AS3, can compute a Virtual
Shortest Path Tree (VSPT) [BRPC] to provide a path to each of the
entry points into AS3, or to some selected entry points into AS3 by
policy. This tree will be passed to PCE1 which will update the VSPT
and select a path. The final path supplied to R1 will include all of
the strict hops as far as AS3 (through either R9 or R10) and a loose
hop to the destination, R11. When the LSP is signaled, the boundary
node of AS3 (R9 or R10) will expand the ERO using the per-domain
approach, and the LSP will be completed.
2.2. Specific and Generic Cases
The Hybrid PCE Network can be generalized based on three specific
cases as follows:
1) Domain 1 and domain 2 have PCEs, but domain 3 does not.
This is the case described in Section 2.1. BRPC cannot be used in
all domains, but can be combined with the per-domain approach.
2) Domain 2 and domain 3 have PCEs, but domain 1 does not.
In this case, a path computation request can never be initiated
from domain 1, and he LSP must be signaled across domain 1 with a
loose hop to cover the combination of domains 2 and 3. But, when
the LSP is signaled as far as domain 2, then normal PCE process
may take place using BRPC if desired.
3) Domain 1 and domain 3 have PCEs, but domain 2 does not.
In this case, ASBRs between domain 1 and domain 3 may establish
virtual inter-AS TE links through domain 2, and PCEs in domain 1
and domain 3 may communicate and use the inter-AS TE links to
compute. If one domain has no PCE, then it can provide inter-AS TE
links for its neighboring domain which has PCEs. If domain 2 does
not have the policy to provide inter-AS TE links, then per-domain
method may still be used.
A network may be more complex than the three cases listed above, but
an arbitrarily complex series of domains may be composed as a
sequence of the specific cases. When a domain sequence is selected,
where some domains have PCEs and some do not, the sequence can be
regarded as several contiguous segments. Each segment is composed of
domains that all have a PCE or all do not. For each segment having
Xia & Li Expires December 30, 2007 [Page 5]
Internet-Draft Hybrid PCE Networks June 2007
PCEs, the BRPC method may still be used for the segment as PCE can
provide a better solution considering the resources of whole network
it serves. For each segment having not PCE, the per-domain method may
be used. So computation will not be backward to head node if some
domain has not PCE.
A PCC can set O-bit in RP object to indicate it is willing to accept
a loose path. So if a PCE find there is no PCE in downstream domain,
it check whether O-bit in RP object is set. If the flag is set, the
PCE can use the process described above. Else, it just returns an
error with corresponding reasons.
3. Security Considerations
TBD.
4. Manageability Considerations
TBD (This section is compliant with [PCE-MGBT-REQ]).
5. IANA Considerations
This document defines no new protocols or extensions and makes no
requests to IANA for registry management.
6. Acknowledgments
We would like to thank Adrian Farrel for his useful comments.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE)-based Architecture", RFC4655, august 2006.
[RFC4726] Farrel, A., Vasseur, J.P. and Ayyangar, A., " Framework for
Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC4726, November 2006.
[INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic
Engineering Requirements", RFC4216, November 2005.
Xia & Li Expires December 30, 2007 [Page 6]
Internet-Draft Hybrid PCE Networks June 2007
[PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE)
communication Protocol (PCEP)", draft-ietf-pce-pcep, work
in progress.
[PER-DOMAIN] Ayyangar, A., Vasseur, J., and Zhang, R., " A Per-domain
path computation method for establishing Inter-domain",
draft-ietf-ccamp-inter-domain-pd-path-comp-05 (work in
progress), February, 2006.
[BRPC] Vasseur, J., Ed., R. Zhang, N. Bitar, JL. Le Roux, "A Backward
Recursive PCE-based Computation (BRPC) procedure to compute
shortest inter-domain Traffic Engineering Label Switched
Paths ", draft-ietf-pce-brpc-05.txt, Work in Progress,
January 2007.
7.2. Informative References
[RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol
Generic Requirements", RFC4657, September 2006.
[PCE-MGBT-REQ] Farrel, A., "Inclusion of Manageability Sections in
PCE Working Group Drafts", draft-ietf-pce-manageability-
requirements-01 (work in progress), March 2007.
8. Authors' Addresses
Hongmiao Xia
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28973679
Email: xiahongmiao@huawei.com
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28973237
Email: danli@huawei.com
Xia & Li Expires December 30, 2007 [Page 7]
Internet-Draft Hybrid PCE Networks June 2007
9. Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
10.Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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.
Xia & Li Expires December 30, 2007 [Page 8]
Internet-Draft Hybrid PCE Networks June 2007
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".
Xia & Li Expires December 30, 2007 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 05:35:02 |