draft-ietf-pce-hierarchy-fwk-04.txt   draft-ietf-pce-hierarchy-fwk-05.txt 
Network Working Group D. King (Ed.) Network Working Group D. King (Ed.)
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended Status: Informational A. Farrel (Ed.) Intended Status: Informational A. Farrel (Ed.)
Expires: 28 November 2012 Old Dog Consulting Expires: 29 January 2013 Old Dog Consulting
28 June 2012 29 August 2012
The Application of the Path Computation Element Architecture to the The Application of the Path Computation Element Architecture to the
Determination of a Sequence of Domains in MPLS and GMPLS Determination of a Sequence of Domains in MPLS and GMPLS
draft-ietf-pce-hierarchy-fwk-04.txt draft-ietf-pce-hierarchy-fwk-05.txt
Abstract Abstract
Computing optimum routes for Label Switched Paths (LSPs) across Computing optimum routes for Label Switched Paths (LSPs) across
multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS
networks presents a problem because no single point of path networks presents a problem because no single point of path
computation is aware of all of the links and resources in each computation is aware of all of the links and resources in each
domain. A solution may be achieved using the Path Computation domain. A solution may be achieved using the Path Computation
Element (PCE) architecture. Element (PCE) architecture.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on 28 November 2012. This Internet-Draft will expire on 29 August 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
4.6.2 Hierarchical PCE End-to-End Path Computation 4.6.2 Hierarchical PCE End-to-End Path Computation
Procedure Example.........................................17 Procedure Example.........................................17
4.7 Hierarchical PCE Error Handling...........................19 4.7 Hierarchical PCE Error Handling...........................19
4.8 Hierarchical PCEP Protocol Extensions.....................19 4.8 Hierarchical PCEP Protocol Extensions.....................19
4.8.1 PCEP Request Qualifiers.............................19 4.8.1 PCEP Request Qualifiers.............................19
4.8.2 Indication of H-PCE Capability......................20 4.8.2 Indication of H-PCE Capability......................20
4.8.3 Intention to Utilize Parent PCE Capabilities........20 4.8.3 Intention to Utilize Parent PCE Capabilities........20
4.8.4 Communication of Domain Connectivity Information....20 4.8.4 Communication of Domain Connectivity Information....20
4.8.5 Domain Identifiers..................................21 4.8.5 Domain Identifiers..................................21
5. Hierarchical PCE Applicability................................21 5. Hierarchical PCE Applicability................................21
5.1 Antonymous Systems and Areas..............................21 5.1 autonomous Systems and Areas..............................21
5.2 ASON architecture (G-7715-2)..............................22 5.2 ASON architecture (G-7715-2)..............................22
5.2.1 Implicit Consistency Between Hierarchical PCE and 5.2.1 Implicit Consistency Between Hierarchical PCE and
G.7715.2..................................................23 G.7715.2..................................................23
5.2.2 Benefits of Hierarchical PCEs in ASON...............24 5.2.2 Benefits of Hierarchical PCEs in ASON...............24
6. A Note on BGP-TE..............................................24 6. A Note on BGP-TE..............................................24
6.1 Use of BGP for TED Synchronization........................25 6.1 Use of BGP for TED Synchronization........................25
7. Management Considerations ....................................25 7. Management Considerations ....................................25
7.1 Control of Function and Policy............................25 7.1 Control of Function and Policy............................25
7.1.1 Child PCE...........................................25 7.1.1 Child PCE...........................................25
7.1.2 Parent PCE..........................................26 7.1.2 Parent PCE..........................................26
skipping to change at page 4, line 7 skipping to change at page 4, line 7
expressed as requirements in [RFC4105] and [RFC4216]. This capability expressed as requirements in [RFC4105] and [RFC4216]. This capability
may be realized by a Path Computation Element (PCE). The PCE may be realized by a Path Computation Element (PCE). The PCE
architecture is defined in [RFC4655]. The methods for establishing architecture is defined in [RFC4655]. The methods for establishing
and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in
[RFC4726]. [RFC4726].
In this context, a domain can be defined as a separate In this context, a domain can be defined as a separate
administrative, geographic, or switching environment within the administrative, geographic, or switching environment within the
network. A domain may be further defined as a zone of routing or network. A domain may be further defined as a zone of routing or
computational ability. Under these definitions a domain might be computational ability. Under these definitions a domain might be
categorized as an Antonymous System (AS) or an Interior Gateway categorized as an autonomous System (AS) or an Interior Gateway
Protocol (IGP) area [RFC4726] and [RFC4655]. Domains are connected Protocol (IGP) area [RFC4726] and [RFC4655]. Domains are connected
through ingress and egress boundary nodes (BNs). A more detailed through ingress and egress boundary nodes (BNs). A more detailed
definition is given in Section 1.2. definition is given in Section 1.2.
In a multi-domain environment, the determination of an end-to-end In a multi-domain environment, the determination of an end-to-end
traffic engineered path is a problem because no single point of path traffic engineered path is a problem because no single point of path
computation is aware of all of the links and resources in each computation is aware of all of the links and resources in each
domain. PCEs can be used to compute end-to-end paths using a per- domain. PCEs can be used to compute end-to-end paths using a per-
domain path computation technique [RFC5152]. Alternatively, the domain path computation technique [RFC5152]. Alternatively, the
backward recursive path computation (BRPC) mechanism [RFC5441] backward recursive path computation (BRPC) mechanism [RFC5441]
skipping to change at page 6, line 45 skipping to change at page 6, line 45
o Minimize the cost of the path [RFC5541] o Minimize the cost of the path [RFC5541]
o Select a path using links with the minimal load [RFC5541] o Select a path using links with the minimal load [RFC5541]
o Select a path that leaves the maximum residual bandwidth [RFC5541] o Select a path that leaves the maximum residual bandwidth [RFC5541]
o Minimize aggregate bandwidth consumption [RFC5541] o Minimize aggregate bandwidth consumption [RFC5541]
o Minimize the Load of the most loaded Link [RFC5541] o Minimize the Load of the most loaded Link [RFC5541]
o Minimize the Cumulative Cost of a set of paths [RFC5541] o Minimize the Cumulative Cost of a set of paths [RFC5541]
o Minimize or cap the number of domains crossed o Minimize or cap the number of domains crossed
o Disallow domain re-entry o Disallow domain re-entry
See Section 5.1 for further discussion of objective functions. See Section 4.1 for further discussion of objective functions.
1.3.2 Diversity 1.3.2 Diversity
1.3.2.1 Physical Diversity 1.3.2.1 Physical Diversity
Within a Carrier's Carrier environment MPLS services may share common Within a Carrier's carrier environment MPLS services may share common
underlying equipment and resources, including optical fiber and underlying equipment and resources, including optical fiber and
nodes. An MPLS service request may require a path for traffic that is nodes. An MPLS service request may require a path for traffic that is
physically disjointed from another service. Thus, if a physical link physically disjointed from another service. Thus, if a physical link
or node fails on one of the disjoint paths, not all traffic is lost. or node fails on one of the disjoint paths, not all traffic is lost.
1.3.2.2 Domain Diversity 1.3.2.2 Domain Diversity
A pair of paths are domain-diverse if they do not transit any of the A pair of paths are domain-diverse if they do not transit any of the
same domains. A pair of paths that share a common ingress and egress same domains. A pair of paths that share a common ingress and egress
are domain-diverse if they only share the same domains at the ingress are domain-diverse if they only share the same domains at the ingress
skipping to change at page 13, line 13 skipping to change at page 13, line 13
o Minimize aggregate bandwidth consumption o Minimize aggregate bandwidth consumption
o Minimize or cap the number of transit domains o Minimize or cap the number of transit domains
o Disallow domain re-entry o Disallow domain re-entry
The objective function may be requested by the PCC, the ingress The objective function may be requested by the PCC, the ingress
domain PCE (according to local policy), or applied by the parent PCE domain PCE (according to local policy), or applied by the parent PCE
according to inter-domain policy. according to inter-domain policy.
More than one OF (or a composite OF) may be chosen to apply to a More than one OF (or a composite OF) may be chosen to apply to a
single computation provided they are not contradictory. Composite OFs single computation provided they are not contradictory. Composite OFs
may include weightings and preferences for the fulfillment of pieces may include weightings and preferences for the fulfilment of pieces
of the desired outcome. of the desired outcome.
4.2 Maintaining Domain Confidentiality 4.2 Maintaining Domain Confidentiality
Information about the content of child domains is not shared for Information about the content of child domains is not shared for
scaling and confidentiality reasons. This means that a parent PCE is scaling and confidentiality reasons. This means that a parent PCE is
aware of the domain topology and the nature of the connections aware of the domain topology and the nature of the connections
between domains, but is not aware of the content of the domains. between domains, but is not aware of the content of the domains.
Similarly, a child PCE cannot know the internal topology of another Similarly, a child PCE cannot know the internal topology of another
child domain. Child PCEs also do not know the general domain mesh child domain. Child PCEs also do not know the general domain mesh
skipping to change at page 18, line 7 skipping to change at page 18, line 7
Each child PCE performs steps 1 through 5 so that the parent PCE can Each child PCE performs steps 1 through 5 so that the parent PCE can
create a domain topology view as shown in Figure 2. create a domain topology view as shown in Figure 2.
4.6.2 Hierarchical PCE End-to-End Path Computation Procedure 4.6.2 Hierarchical PCE End-to-End Path Computation Procedure
The procedure below is an example of a source PCC requesting an The procedure below is an example of a source PCC requesting an
end-to-end path in a multi-domain environment. The topology is end-to-end path in a multi-domain environment. The topology is
represented in Figure 1. It is assumed that the each child PCE has represented in Figure 1. It is assumed that the each child PCE has
connected to its parent PCE and exchanged the initial information connected to its parent PCE and exchanged the initial information
required for the parent PCE to create its domain topology view as required for the parent PCE to create its domain topology view as
described in Section 5.6.1. described in Section 4.6.1.
1. The source PCC (the ingress LSR in our example), sends a request 1. The source PCC (the ingress LSR in our example), sends a request
to the PCE responsible for its domain (PCE 1) for a path to the to the PCE responsible for its domain (PCE 1) for a path to the
destination LSR (D). destination LSR (D).
2. PCE 1 determines the destination is not in domain 1. 2. PCE 1 determines the destination is not in domain 1.
3. PCE 1 sends a computation request to its parent PCE (PCE 5). 3. PCE 1 sends a computation request to its parent PCE (PCE 5).
4. The parent PCE determines that the destination is in Domain 3. 4. The parent PCE determines that the destination is in Domain 3.
(See Section 5.5). (See Section 4.5).
5. PCE 5 determines the likely domain paths according to the domain 5. PCE 5 determines the likely domain paths according to the domain
interconnectivity and TE capabilities between the domains. For interconnectivity and TE capabilities between the domains. For
example, assuming that the link BN12-BN22 is not suitable for the example, assuming that the link BN12-BN22 is not suitable for the
requested path, three domain paths are determined: requested path, three domain paths are determined:
S-BN11-BN21-D2-BN23-BN31-D S-BN11-BN21-D2-BN23-BN31-D
S-BN11-BN21-D2-BN24-BN32-D S-BN11-BN21-D2-BN24-BN32-D
S-BN13-BN41-D4-BN42-BN33-D S-BN13-BN41-D4-BN42-BN33-D
skipping to change at page 19, line 8 skipping to change at page 19, line 8
11. PCE 1 forwards the path to the PCC (the ingress LSR). 11. PCE 1 forwards the path to the PCC (the ingress LSR).
Note that there is no requirement for steps 6, 7, and 8 to be carried Note that there is no requirement for steps 6, 7, and 8 to be carried
out in parallel or in series. Indeed, they could be overlapped with out in parallel or in series. Indeed, they could be overlapped with
step 5. This is an implementation issue. step 5. This is an implementation issue.
4.7 Hierarchical PCE Error Handling 4.7 Hierarchical PCE Error Handling
In the event that a child PCE in a domain cannot find a suitable In the event that a child PCE in a domain cannot find a suitable
path to the egress. The child PCE should return the relevant path to the egress, the child PCE should return the relevant
error to notify the parent PCE. Depending on the error response the error to notify the parent PCE. Depending on the error response the
parent PCE can elect to: parent PCE can elect to:
o Cancel the request and send the relevant response back to the o Cancel the request and send the relevant response back to the
initial child PCE that requested an end-to-end path; initial child PCE that requested an end-to-end path;
o Relax some of the constraints associated with the initial path o Relax some of the constraints associated with the initial path
request; request;
o Select another candidate domain and send the path request to the o Select another candidate domain and send the path request to the
child PCE responsible for the domain. child PCE responsible for the domain.
skipping to change at page 21, line 29 skipping to change at page 21, line 29
Autonomous System, but becomes ambiguous in a path that crosses Autonomous System, but becomes ambiguous in a path that crosses
multiple Autonomous Systems). multiple Autonomous Systems).
5. Hierarchical PCE Applicability 5. Hierarchical PCE Applicability
As per [RFC4655], PCE can inherently support inter-domain path As per [RFC4655], PCE can inherently support inter-domain path
computation for any definition of a domain as set out in Section 1.2 computation for any definition of a domain as set out in Section 1.2
of this document. of this document.
Hierarchical PCE can be applied to inter-domain environments, Hierarchical PCE can be applied to inter-domain environments,
including Antonymous Systems and IGP areas. The hierarchical PCE including autonomous Systems and IGP areas. The hierarchical PCE
procedures make no distinction between, Antonymous Systems and IGP procedures make no distinction between, autonomous Systems and IGP
area applications, although it should be noted that the TED area applications, although it should be noted that the TED
maintained by a parent PCE must be able to support the concept of maintained by a parent PCE must be able to support the concept of
child domains connected by inter-domain links or directly connected child domains connected by inter-domain links or directly connected
at boundary nodes (see Section 3). at boundary nodes (see Section 3).
This section sets out the applicability of hierarchical PCE to three This section sets out the applicability of hierarchical PCE to three
environments: environments:
o MPLS traffic engineering across multiple Autonomous Systems o MPLS traffic engineering across multiple Autonomous Systems
o MPLS traffic engineering across multiple IGP areas o MPLS traffic engineering across multiple IGP areas
o GMPLS traffic engineering in the ASON architecture o GMPLS traffic engineering in the ASON architecture
5.1 Antonymous Systems and Areas 5.1 autonomous Systems and Areas
Networks are comprised of domains. A domain can be considered to be Networks are comprised of domains. A domain can be considered to be
a collection of network elements within an AS or area that has a a collection of network elements within an AS or area that has a
common sphere of address management or path computational common sphere of address management or path computational
responsibility. responsibility.
As networks increase in size and complexity it may be required to As networks increase in size and complexity it may be required to
introduce scaling methods to reduce the amount information flooded introduce scaling methods to reduce the amount information flooded
within the network and make the network more manageable. An IGP within the network and make the network more manageable. An IGP
hierarchy is designed to improve IGP scalability by dividing the hierarchy is designed to improve IGP scalability by dividing the
 End of changes. 13 change blocks. 
15 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/