One document matched: draft-king-pce-hierarchy-fwk-02.txt
Differences from draft-king-pce-hierarchy-fwk-01.txt
Network Working Group D. King
Internet-Draft Old Dog Consulting
Intended Status: Informational A. Farrel
Created: October 25, 2009 Old Dog Consulting
Expires: March 25, 2010
The Application of the Path Computation Element Architecture to the
Determination of a Sequence of Domains in MPLS & GMPLS
draft-king-pce-hierarchy-fwk-02.txt
Abstract
Computing optimum routes for Label Switched Paths (LSPs) across
multiple domains in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) and Generalized MPLS (GMPLS) networks presents a problem
because no single point of path computation is aware of all of the
links and resources in each domain. A solution may be achieved using
the Path Computation Element (PCE) architecture.
Where the sequence of domains is known, a priori, various techniques
can be employed to derive an optimum path. If the domains are
simply- connected, or if the preferred points of interconnection are
also known, the Per-Domain Path Computation technique can be used.
Where there are multiple connections between domains and there is
no preference for the choice of points of interconnection, the
Backward Recursive Path Computation Procedure (BRPC) can be used to
derive an optimal path.
This document examines techniques to establish the optimum path when
the sequence of domains is not known in advance. The document
provides mechanisms that allow the optimum sequence of domains to be
selected, and the optimum end-to-end path to be derived.
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.
King and Farrel [Page 1]
draft-king-hierarchy-fwk-01.txt October 2009
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
King and Farrel [Page 2]
draft-king-hierarchy-fwk-01.txt October 2009
Contents
1. Introduction..................................................4
1.1 Problem Statement............................................4
1.2 Definition of a Domain............. .........................5
1.3 Requirements.................................................5
1.3.1 Metric Objectives..........................................6
1.3.2 Domain Diversity...........................................6
1.3.3 Domain Path Diversity......................................7
1.3.4 Existing Traffic Engineering Constraints...................7
1.3.5 Commercial Constraints.....................................7
1.3.6 Domain Confidentiality.....................................7
1.4 Terminology..................................................7
2. Per Domain Path Computation...................................8
3. Backward Recursive Path Computation...........................9
3.1. Applicability of BRPC when the Domain Path is not Known.....10
4. Hierarchical PCE..............................................10
5. Hierarchical PCE Procedures...................................11
5.1 Objective Functions..........................................11
5.2 Maintaining Domain Confidentiality...........................12
5.3 PCE Discovery................................................12
5.4 Domain Traffic Engineering Abstraction.......................13
5.5 Determination of Destination Domain .........................13
5.6 Hierarchical PCE Examples....................................14
5.6.1 Hierarchical PCE Initial Information Exchange..............16
5.6.2 Hierarchical PCE End-to-End Path Computation Procedure
Example..........................................................16
6. Hierarchical PCE Applicability................................17
6.1 Antonymous Systems...........................................18
6.2 ASON architecture (G-7715-2).................................18
6.3 IGP Areas....................................................18
7. Management Considerations ....................................18
7.1 Control of Function and Policy...............................18
7.1.1 Child PCE..................................................18
7.1.2 Parent PCE.................................................19
7.1.3 Policy Control.............................................19
7.2 Information and Data Models..................................19
7.3 Liveness Detection and Monitoring............................19
7.4 Verifying Correct Operation..................................19
7.5. Impact on Network Operation.................................20
8. Security Considerations ......................................20
9. IANA Considerations ..........................................20
10. Acknowledgements ............................................20
11. References ..................................................20
11.1. Normative References.......................................20
11.2. Informative References ....................................20
12. Authors' Addresses ..........................................22
12. Intellectual Property Consideration .........................22
13. Disclaimer of Validity ......................................22
14. Full Copyright Statement ....................................22
King and Farrel [Page 3]
draft-king-hierarchy-fwk-01.txt October 2009
1. Introduction
The capability to compute, establish and control end-to-end inter-
domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
and Generalized Multiprotocol Label Switching (GMPLS) paths, using a
Path Computation Element is well known. The Path Computation Element
(PCE) architecture is defined in [RFC4655]. The methods for
establishing and controlling inter-domain MPLS and GMPLS are
documented in [RFC4726]
In a multi-domain environment, the determination of an en-to-end
traffic engineered path is a problem because no single point of path
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 path computation technique [RFC5152]. Alternatively, the
backward recursive path computation (BRPC) mechanism [RFC5441]
allows multiple PCEs to collaborate in order to select an optimal
end-to-end path that crosses multiple domains. Both mechanisms
assume that the sequence of domains to be crossed between ingress
and egress in known in advance.
A domain can be defined as a separate administrative, geographic, or
switching environment within the network. A domain may be further
defined as a zone of routing or computational ability. Under these
definitions a domain might be categorized as an Antonymous System
(AS) or an Interior Gateway Protocol (IGP) area [RFC4726] and
[RFC4655]. Domains are connected through ingress and egress
boundary nodes (BNs). A more detailed definition is given in
Section 1.2.
This document examines techniques to establish the optimum path when
the sequence of domains is not known in advance. It describes the
architecture and mechanisms necessary to allow the optimum sequence
of domains to be selected and the optimum end-to-end path to be
derived.
The model described in this document is applicable to environments
with small groups of domains (where visibility is limited from the
ingress Label Switching Router - LSR). Applying the hierarchical
PCE model to large groups of domains such as the Internet, is not
feasible or relevant.
1.1 Problem Statement
Using a PCE to compute a path between nodes within a single domain is
relatively straightforward. Computing an end-to-end path when the
source and destination nodes are located in different domains
requires co-operation between multiple PCEs, each responsible for
its own domain.
King and Farrel [Page 4]
draft-king-hierarchy-fwk-01.txt October 2009
Both techniques, assume that the sequence of domains to be crossed
from source to destination is well known. No explanation is given in
[RFC4655] of how this sequence is generated or what criteria may be
used for the selection of paths between domains. In small clusters
of domains, such as simple cooperation between adjacent ISPs, this
selection process is not complex. In more advanced deployments
(such as optical networks constructed from multiple sub-domains,
or multi-AS environments) the choice of domains in the end-to-end
domain sequence can be critical to the determination of an optimum
end-to-end path.
This document introduces the concept of a hierarchical PCE
architecture and shows how to coordinate PCEs in peer domains in
order to derive an optimal end-to-end path. The work is currently
scoped to operate with a small group of domains and there is no
intent to apply this model to a large group of domains, e.g., to the
Internet.
1.2 Definition of a Domain
A domain is defined in [RFC4726] as any collection of network
elements within a common sphere of address management or path
computational responsibility. Examples of such domains include
IGP areas and Autonomous Systems. Wholly or partially overlapping
domains are not within the scope of this document.
In the context of GMPLS, a particularly important example of a domain
is the ASON subnetwork [G-8080]. In this case, computation of an
end-to-end path requires the selection of nodes and links within a
parent domain where some nodes may, in fact, be subnetworks.
Furthermore, a domain might be an ASON routing area [G-7715]. A PCE
may perform the path computation function of an ASON routing
controller as described in [G-7715-2].
This document assumes that the selection of a sequence of domains for
an end-to-end path is in some sense a hierarchical path computation
problem. That is, where one mechanism is used to determine a path
across a domain, a separate mechanism (or at least a separate set
of paradigms) is used to determine the sequence of domains.
1.3 Assumptions and Requirements
Networks are often constructed from multiple domains. These
domains are often interconnected via multiple interconnect points.
Its assumed that the sequence of domains for an and-to-end path is
not always well-known.
King and Farrel [Page 5]
draft-king-hierarchy-fwk-01.txt October 2009
The traffic engineering properties of a domain cannot be seen from
outside the domain. Traffic engineering aggregation or abstraction,
hides information and can leads to failed path setup or the selection
of suboptimal end-to-end paths [RFC4726]. The aggregation process
may also have significant scaling issues for networks with many
possible routes and multiple TE metrics. Flooding TE information
breaks confidentiality and does not scale in the routing protocol.
The primary goal of this document is to define how to derive optimal
end-to-end multi-domain paths when the sequence of domains is not
known in advance. The solution needs to be scalable and to maintain
internal domain topology confidentiality while providing the optimal
end-to-end path.
1.3.1 Metric Objectives
The definition of optimality is dependent on policy and will be
based on a single objective or a group objectives. An objective
is expressed as an objective function [RFC5541] and may be requested
on a path computation request. The following objective functions are
identified in this document for manipulating the path metrics for
inter-domain path computation, but the list may be expanded in
future versions of this document:
* Minimize the cost of the path [RFC5541]
* Select a path using links with the minimal load [RFC5541]
* Select a path that leaves the maximum residual bandwidth [RFC5541]
* Minimize aggregate bandwidth consumption [RFC5541]
* Minimize the Load of the most loaded Link [RFC5541]
* Minimize the Cumulative Cost of a set of paths [RFC5541]
* Minimize the number of border routers used
* Limit the number of domains crossed
See Section 5.1 for further discussion of objective functions.
1.3.2 Domain Diversity
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
are domain-diverse if they only share the same domains at the ingress
and egress (the ingress and egress domains). Domain diversity may be
maximized for a pair of paths by selecting paths that have the
smallest number of shared domains. (Note that this is not the same
as finding paths with the greatest number of distinct domains!)
Path computation should facilitate the selection of paths that share
ingress and egress domains, but do not share any transit domains.
This provides a way to reduce the risk of shared failure along any
path, and automatically helps to ensure path diversity for most of
the route of a pair of Label Switched Paths (LSPs).
King and Farrel [Page 6]
draft-king-hierarchy-fwk-01.txt October 2009
This, domain path selection should provide the capability to include
or exclude specific domains and specific border nodes.
1.3.3 Existing Traffic Engineering Constraints
Any solution should take advantage of typical traffic engineering
constraints (hop count, bandwidth, lambda continuity, path cost,
etc.) to meet the service demands expressed in the path computation
request [RFC4655].
1.3.4 Commercial Constraints
The solution should provide the capability to include commercially
relevant constraints such as policy, SLAs, security, peering
preferences, and dollar costs.
Additionally it may be necessary for the service provider to
request that specific domains are included or excluded based on
commercial relationships, security implications, and reliability.
1.3.5 Domain Confidentiality
A key requirement is the ability to maintain domain confidentiality
when computing inter-domain end-to-end paths. When required by local
policy, a PCE should not need to disclose to any other PCE the intra-
domain paths it computes or the internal topology of the domain it
serves.
1.3.6 Limiting Resource Aggregation
It is important to minimise the amount of aggregation within the
solution. There should be no associated computation burden or
requirement to aggregate and abstract traffic engineering link
information.
1.3.7 Domain Interconnection Discovery
To support large mesh domain topologies, the solution should allow
the discovery and selection of domain inter-connections. Pre-
configuration of preferred domain interconnections should also be
supported for network operators that have bilateral agreement, and
preference for the choice of points of interconnection.
1.4 Terminology
This document uses PCE terminology defined in [RFC4655], [RFC4875],
and [RFC5440]. Additional terms are defined below.
Domain Path: The sequence of domains for a path.
King and Farrel [Page 7]
draft-king-hierarchy-fwk-01.txt October 2009
Ingress Domain: The domain that includes the ingress LSR of a path.
Transit Domain: A domain that has an upstream and downstream
neighbor domain for a specific path.
Egress Domain: The domain that includes the egress LSR of a path.
Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could
either be Area Border Routers (ABRs) or Autonomous System Border
Routers (ASBRs). They are defined here more generically as
Boundary Nodes (BNs).
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n)
on a path.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1)
on a path.
Parent Domain: A domain higher up in a domain hierarchy such
that it contains other domains (child domains) and potentially other
links and nodes.
Child Domain: A domain lower in a domain hierarchy such that it has
a parent domain.
Parent PCE: A PCE responsible for selecting a path across a parent
domain and any number of child domains by coordinating with Child
PCEs and examining a topology map that shows domain inter-
connectivity.
Child PCE: A PCE responsible for computing the path across one or
more specific (child) domains. A child PCE maintains a relationship
with at least one Parent PCE.
OF: Objective Function: A set of one or more optimization
criteria used for the computation of a single path (e.g., path cost
minimization), or the synchronized computation of a set of paths
(e.g., aggregate bandwidth consumption minimization, etc.). See
[RFC4655] and [RFC5541].
2. Per Domain Path Computation
The per-domain path computation method for establishing inter-Domain
TE-LSPs [RFC5152] defines a technique whereby the path is
computed during the signalling process on a per-domain basis. The
entry BN of each domain is responsible for performing the path
computation for a section of the LSP that crosses the domain or for
requesting that a PCE for that domain computes the path.
King and Farrel [Page 8]
draft-king-hierarchy-fwk-01.txt October 2009
During per domain path computation, each
computation results in the best path across the domain to provide
connectivity to the next domain in the domain sequence (usually
indicated in signalling by an identifier of the next domain or the
identity of the next entry BN). Ultimately per domain path
computation may lead to sub-optimal paths.
In the case that the domain path (in particular, the sequence of
border nodes) is not known the PCE must select an exit BN based on
some determination of how to reach the destination that is outside
the domain for which the PCE has computational responsibility.
[RFC5152] suggest that this might be achieved using the IP
shortest path as advertise by BGP. Note, however, that the
existence of an IP forwarding path does guarantee the presence of
sufficient bandwidth, let alone an optimal TE path. Furthermore in
many GMPLS systems inter-domain IP routing will not be present.
Thus, per domain path computation may require a number of significant
crankback routing attempts to establish even a sub-optimal path.
Note also that the PCEs in each domain may have different computation
capabilities, run different path computation algorithms, and apply
different sets of constraints and optimization criteria, etc. This
can result in the end-to-end path being inconsistent and sub-
optimal.
Per domain path computation can suit simply-connected domains
where the preferred points of interconnection are known.
3. Backward Recursive Path Computation
The Backward Recursive Path Computation (BRPC) [RFC5441] procedure
involves the cooperation and communication between PCEs in order to
compute an optimal end-to-end path across multiple domains. The
sequence of domains to be traversed can either be determined before
or during the path computation. In the case where the sequence of
domains is known, the ingrss PCC (Path Computation Client) sends a
path computation requests to the PCE responsible for the ingress
domain. This request is forwarded between PCEs, domain-by-domain,
to the PCE responsible for the egress domain. The PCE in the egress
domain creates a set of optimal paths from all of the domain entry
BNs to the egress LSR. This set is represented as a Virtual
Shortest Path Tree (VSPT) (a tree of potential paths), and the PCE
passes it back to the previous PCE on the domain path. As the VSPT
is passed back toward the ingress domain each PCE computes the
optimal paths from its entry BNs to its exit BNs that connect to
the rest of the tree. It adds these paths to the VSPT and passes
the VSPT on until the PCE for the ingress domain is reached and
computes paths from the ingress LSR to connect to the rest of the
tree. The ingress PCE then selects the optimal end-to-end path
which it returns to the initiating PCC.
King and Farrel [Page 9]
draft-king-hierarchy-fwk-01.txt October 2009
BRPC may suit environments where multiple connections exist between
domains and there is no preference for the choice of points of
interconnection. It is best suited to scenarios where the domain
path is known in advance, but can also be used when the domain path
is not known.
3.1. Applicability of BRPC when the Domain Path is Not Known
As described above BRPC can be used to determine an optimal
inter-domain path when the sequence is known. Even when the sequence
of domains is not known BRPC could be used as follows.
- PCC sends a request to the PCE for the ingress domain (the ingress
PCE)
- The ingress PCE sends the path computation request direct to the
PCE responsible for the domain containing the destination node
(egress PCE)
- The egress PCE computes an egress VSPT and passes it to a PCE
responsible for each of the adjacent (potentially upstream)
domains.
- Each PCE in turn constructs a VSPT and passes it on to all of its
neighboring PCEs.
- When the ingress PCE has received a VSPT from each of its
neighboring domains it is able to select the optimum path.
Clearly this mechanism (which could be called path computation
flooding) has significant scaling issues. It could be improved by
the application of policy and filtering, but such mechanisms are not
simple and would still leave scaling concerns.
4. Hierarchical PCE
In the hierarchical PCE architecture, a Parent (hierarchical)
PCE maintains a domain topology map. The domain topology map contains
the Child domains (seen as vertices in the topology) and their
interconnections (links in the topology). The Parent PCE has no
information about the content of the Child domains , that is, the
Parent PCE does not know about the resource availability within
the Child domains, nor about the availability of connectivity
across each domain. The Parent PCE is aware of the TE capabilities
of the interconnections between Child domains as these
interconnections are links in its own topology map.
King and Farrel [Page 10]
draft-king-hierarchy-fwk-01.txt October 2009
Each Child domain has at least one PCE capable of computing paths
across the domain. These PCEs are known as Child PCEs and have a
relationship with the Parent PCE. Each Child PCE also knows the
identity of the domains that neighbor its own domain. A Child PCE
only knows the topology of the domains that it serves and does not
know the topology of other Child domains. Child PCEs are also not
aware of the general domain mesh connectivity beyond the
connectivity of the domains it serves to their immediate neighbors.
The Parent PCE builds the domain topology map either from
configuration or from information received from each Child PCE. This
tells it how the domains are interconnected including the traffic
engineering (TE) properties of the domain interconnections, but the
Parent PCE does not know the contents of the Child domains. Discovery
of the domain topology and domain interconnections is discussed
further in Section 5.3.
When a multi-domain path is needed, the ingress PCE sends a request
to the parent PCE (using the PCE Protocol [RFC5440]). The Parent PCE
selects a set of candidate domain paths based on the domain topology
and the state of the inter-domain links. It then sends computation
requests to the Child PCEs responsible for each of the domains on
the candidate domain paths.
Each Child PCE computes its path segment or a set of candidate
segments and sends the results to the Parent PCE. The Parent PCE uses
this information to select path segments and concatenate them to
derive the optimal end-to-end inter-domain path. The end-to-end path
is then sent to the Child PCE which received the initial path request
and this passes the path on to the PCC that issues the original
request.
5. Hierarchical PCE Procedures
5.1 Objective Functions and Policy
Deriving the optimal end-to-end domain path sequence is dependent on
the policy applied during domain path computation. An Objective
Function (OF) [RFC5541], or set of OFs may be applied in order to
define the policy being applied to the domain path computation.
The OF specifies the desired outcome of the computation. It does
not describe the algorithm to use. When computing end-to-end inter
-domain paths, required OFs may include:
- Minimum cost path
- Minimum load path
- Maximum residual bandwidth path
- Minimize aggregate bandwidth consumption
- Minimize the number of border routers used
King and Farrel [Page 11]
draft-king-hierarchy-fwk-01.txt October 2009
The number of domains crossed
- Minimum number of transit domains
The objective function may be requested by the PCC, the ingress
domain PCE (according to local policy), or maybe applied by the
Parent PCE according to inter-domain policy.
5.2 Maintaining Domain Confidentiality
A Parent PCE is aware of the domain topology and the nature of
the connections between domains, but is not aware of the content of
the domains. This is the case for reasons of scaling and
confidentiality.
Information about the content of Child domains is not shared for
scaling and confidentiality reasons. This means that one Child PCE
cannot know the topology of another Child domain. Child PCEs also do
not know the general domain mesh connectivity, this information is
only known by the Parent PCE.
As described in the earlier sections of this document, PCEs can
exchange path information in order to construct an end-to-end inter-
domain path. Each per-domain path fragment reveals information about
the topology and resource availability within a domain. Some
management domains or ASes will not want to share this information
outside of the domain (even with a trusted parent PCE). In order to
conceal the information, a PCE may replace a path segment with a path
-key [RFC5520]. This mechanism effectively hides the content of a
segment of a path.
5.3 PCE Discovery
It is a simple matter for each Child PCE to be configured with the
address of its Parent PCE. Typically, there will only be one or two
Parents of any Child.
The Parent PCE also needs to be aware of the Child PCEs for all Child
domains that it can see. This information is most likely to be
configured (as part of the administrative definition of each
domain).
Consideration of discovery of the relationships, between Parent PCEs
and Child PCEs, is for future study. Mechanisms that rely on
advertising or querying PCE locations across domain or provider
boundaries are undesirable for security, scaling, commercial, and
confidentiality reasons.
King and Farrel [Page 12]
draft-king-hierarchy-fwk-01.txt October 2009
The Parent PCE also needs to know the inter-domain connectivity.
This information could be configured with suitable policy and
commercial rules, or could be learned from the Child PCEs as
described in Section 4.
In order for the Parent PCE to learn about domain interconnection
the Child PCE will report the identity of its neighbor domains. The
IGP in each neighbor domain can advertise its inter-domain TE
link capabilities [RFC5316], [RFC5392]. This information can be
collected by the Child PCEs and forwarded to the Parent PCE, or the
Parent PCE could participate in the IGP in the Child domains.
5.4 Domain Traffic Engineering Abstraction
The Parent PCE maintains a domain topology map of the Child domains
and their interconnectivity. Where inter-domain connectivity is
provided by TE links the capabilities of those links must also be
known to the Parent PCE. Furthermore the Parent domain
may contain nodes and links in its own right. Therefore, the
Parent PCE maintains a traffic engineering database (TED) for
the Parent domain in the same way that any PCE does.
The Parent domain may just be the collection of Child domains and the
inter-domain links, or it may contain nodes and links in its own
right.
The mechanism for building the parent TED is likely to rely heavily
on administrative configuration and commercial issues. However in
models such as ASON, it is possible to consider a separate instance
of an IGP running within the parent domain where the participating
protocol speakers are the nodes directly present in that domain and
the PCEs (routing controllers) responsible for each of the Child
domains.
5.5 Determination of Destination Domain
The PCC asking for an inter-domain path computation is aware of the
identity of the destination node by definition. If it knows the
egress domain it can supply this information as part of the path
computation request. However, if it does not know the egress domain
this information must be determined by the Parent PCE.
In some specialist topologies the Parent PCE could determine the
destination domain based on the destination address, for example from
configuration. However, this is not appropriate for many multi-domain
addressing scenarios. In IP based multi-domain networks the
Parent PCE may be able to determine the destination domain by
participating in inter-domain routing. Finally, the Parent PCE could
issue specific requests to the Child PCEs to discover if they contain
the destination node, but this has scaling implications.
King and Farrel [Page 13]
draft-king-hierarchy-fwk-01.txt October 2009
This topic will require further study.
5.6 Hierarchical PCE Examples
Figure 1 shows four interconnected domains within a fifth
Parent domain. Each domain contains a PCE.
- Domain 1 is the ingress domain and Child PCE 1 is able to compute
paths within the domain. Its neighbors are Domain 2 (with Child PCE
2) and Domain 4 (with Child PCE 4. The domain also contains the
source LSR (S) and three egress border nodes (BN11, BN12, and
BN13).
- Domain 2 is served by Child PCE 2. Its neighbors are Domain 1
(with Child PCE 1) and Domain 3 (with Child PCE 3). The domain also
contains four border nodes (BN21, BN22BN23, and BN24).
- Domain 3 is the egress domain and is served by Child PCE 3. Its
neighbors are Domain 2 (with Child PCE 2) and Domain 4 (with Child
PCE 4). The domain also contains the destination LSR (D) and three
ingress border nodes (BN31, BN32, and BN33).
- Domain 4 is served by Child PCE 4. Its neighbors are Domain 2
(with Child PCE 2) and Domain 3 (with Child PCE 3). The domain also
contains two border nodes (BN41 and BN42).
All of these domains are encompassed within Domain 5 which is served
by the Parent PCE (PCE 5).
King and Farrel [Page 14]
draft-king-hierarchy-fwk-01.txt October 2009
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | Domain 4 | |
| | | |
| ---------------- |
| |
-----------------------------------------------------------------
Figure 1 : Sample Hierarchical Domain Topology
Figure 2, shows the view of the domain topology as seen by the
Parent PCE (PCE 5). This view is an abstracted topology; PCE 5 is
aware of domain connectivity but not of the internal topology within
each domain.
King and Farrel [Page 15]
draft-king-hierarchy-fwk-01.txt October 2009
----------------------------
| Domain 5 |
| ---- |
| |PCE5| |
| ---- |
| |
| ---- ---- ---- |
| | |---| |---| | |
| | D1 | | D2 | | D3 | |
| | |---| |---| | |
| ---- ---- ---- |
| \ ---- / |
| \ | | / |
| ----| D4 |---- |
| | | |
| ---- |
| |
----------------------------
Figure 2 Abstract Domain Topology as Seen by the Parent PCE
5.6.1 Hierarchical PCE Initial Information Exchange
Based on the Figure 1 topology. The following is an illustration of
the initial hierarchical PCE information exchange.
1. Child PCE 1, the PCE responsible for Domain 1, is configured
with the location of its Parent PCE (PCE5).
2. Child PCE 1 establishes contact with its Parent PCE.
3. Child PCE 1 listens to the IGP in its domain and learns its
inter-domain connectivity. That is, it learns about the links BN11-
BN21, BN12-BN22, and BN13-BN41.
4. Child PCE 1 reports its neighbor domain connectivity to its Parent
PCE (i.e., PCE5).
5. Child PCE 1 reports any change in the resource availability on its
inter-domain links to its Parent PCE (i.e., PCE5).
Each Child PCE performs steps 1 through 5 so that the Parent PCE can
create an abstracted domain topology view as shown in Figure 2.
5.6.2 Hierarchical PCE End-to-End Path Computation Procedure
The procedure below is an example of a source PCC requesting an
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
connected to its Parent PCE and exchanged the initial information
required for the Parent PCE to create its abstracted domain
topology view as described in Section 5.6.1.
King and Farrel [Page 16]
draft-king-hierarchy-fwk-01.txt October 2009
1. The source PCC (the ingress LSR in our example), sends a request
to the PCE responsible for its domain (PCE1) for a path to the
destination LSR.
2. PCE 1 determines the destination, is not in domain 1.
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.
5. PCE 5 determines the likely domain paths according to the domain
interconnectivity and TE capabilities between the domains. For
example, three domain paths (S-BN11-BN21-D2-BN23-BN31-D, S-BN11-BN21-
D2-BN24-BN32-D, and S-BN13-BN41-D4-BN42-BN33-D) are determined.
6. PCE 5 sends edge-to-edge path computation requests to PCE 2
which is responsible for Domain 2 (e.g., BN21-BN23 and BN21-BN24)
and to PCE 4 for Domain 4 (e.g., BN41-BN42).
7. PCE 5 sends source-to-edge path computation requests to PCE 1
which is responsible for Domain 1(e.g., S-BN11 and S-BN13).
8. PCE 5 sends edge-to-egress path computation requests to PCE3
which is responsible for Domain 3 (e.g., BN31-D, BN32-D, and BN33-D).
9. PCE 5 correlates all the computation responses from each Child PCE
and applies any requested and locally configured policies.
10. PCE 5 then selects the optimal end-to-end multi-domain path
that meets the policies and objective functions, and supplies the
resulting path to PCE 1.
11. PCE 1 forwards the path to the PCC (the ingress LSR).
6. Hierarchical PCE Applicability
As per [RFC4655], PCE can inherently support inter-domain path
computation. A domain represents any collection of entities that are
grouped for a particular purpose, e.g., geography, technology,
policy, and routing responsibility. Examples of domains include IGP
areas, Autonomous Systems (ASes).
Hierarchical PCE can be applied to inter-domain environments,
including Antonymous Systems and IGP areas. The hierarchical PCE
procedures make no distinction between, Antonymous Systems and IGP
area applications, although it should be noted that the TED
maintained by a parent PCE must be able to support the concept of
Child domains connected by inter-domain links or directly connected
at border nodes.
King and Farrel [Page 17]
draft-king-hierarchy-fwk-01.txt October 2009
6.1 Antonymous Systems
TBD
6.2 ASON architecture (G-7715-2)
The Parent PCE mechanism fits well within the ASON routing
architecture. It can be used to provide paths across subnetworks,
and to determine end-to-end paths in networks constructed from
multiple subnetworks or Routing Areas (RAs). The Routing Controllers
each implement a PCE that can be queried by any Network Element (NE)
within the RA for which the routing controller has responsibility.
When an inter-domain path is needed, the routing controllers use the
hierarchical PCE model to fully match the hierarchical routing model
of ASON.
This topic will require further study and updated accordingly.
6.3 IGP Areas.
TBD
7. Management Considerations
General PCE management considerations are discussed in [RFC4655]. In
the case of the hierarchical PCE architecture, there are additional
management considerations.
The management responsibility of the Parent PCEs must be determined.
In the case of multi-domains (e.g., IGP areas or multiple ASes)
within one service provider network, the management responsibility
of the Parent PCEs might be handled by the service provider. In
the case of multiple ASes within different service provider
networks, it may be necessary for a third-party to manage the
Parent PCEs according to commercial and policy agreements from each
of the participating service providers.
The following management consideration sections require continued
consideration and will be discussed in further revisions of this
document.
7.1 Control of Function and Policy
7.1.1 Child PCE
Support of the hierarchical procedure will be controlled by the
management organization responsible for each Child PCE. A Child PCE
must be configured with the address of its Parent PCE in order for
it to interact with its Parent PCE. The Child PCE must also be
authorized to peer with the Parent PCE.
King and Farrel [Page 18]
draft-king-hierarchy-fwk-01.txt October 2009
7.1.2 Parent PCE
The Parent PCE must only accept path computation requests from
authorized Child PCEs. If a Parent PCE receives requests from an
unauthorized Child PCE, the request should be dropped.
This means that a Parent PCE must be configured with the identities
and security credentials of all of its Child PCEs, or there must be
some form of shared secret that allows an unknown Child PCE to be
authorized by the Parent PCE.
7.1.3 Policy Control
It may be necessary to maintain a policy module on the Parent PCE
[RFC5394]. This would allow the Parent PCE to apply commercially
relevant constraints such as SLAs, security, peering preferences, and
dollar costs.
It may also be necessary for the Parent PCE to limit end-to-end path
selection by including or excluding specific domains based on
commercial relationships, security implications, and reliability.
7.2 Information and Data Models
TBD (monitoring of parent/child relationships, the use of PCEP
between parent and child, and the parent TED)
7.3 Liveness Detection and Monitoring
The hierarchical procedure requires interaction with multiple PCEs.
Once a Child PCE requests an end-to-end path, a sequence of events
occurs that requires interaction between the Parent PCE and each
Child PCE. If a Child PCE is not operational, and an alternate
transit domain is not Available, then a failure must be reported.
7.4 Verifying Correct Operation
Verifying the correct operation of a Parent PCE can be performed by
monitoring a set of parameters. The Parent PCE implementation should
provide the following parameters:
Parameters monitored by the Parent PCE:
o Number of Child PCE requests.
o Number of successful hierarchical PCE procedures completions on a
per-PCE-peer basis.
o Number of hierarchical PCE procedure completion failures on a per-
PCE-peer basis.
o Number of hierarchical PCE procedure requests from unauthorized
Child PCEs.
King and Farrel [Page 19]
draft-king-hierarchy-fwk-01.txt October 2009
7.5. Impact on Network Operation
The hierarchical PCE procedure is a multiple-PCE path computation
scheme. Subsequent requests to and from the Child and Parent PCEs do
not differ from other path computation requests and should not have
any significant impact on network operations.
8. Security Considerations
The hierarchical PCE procedure relies on PCEP and inherits the
security requirements defined [RFC5440]. Any multi-domain
operation necessarily involves the exchange of information across
domain boundaries. This is bound to represent a significant
security and confidentiality risk especially when the Child
domains are controlled by different commercial concerns.
The hierarchical PCE architecture makes use of PCE policy
[RFC5394] and the security aspects of the PCE communication protocol
documented in [RFC5440]. It is expected that the Parent PCE will
require all Child PCEs to use full security when communicating with
the Parent and that security will be maintained by not supporting the
discovery by a Parent of Child PCEs.
Confidentiality may be enhanced by the use of Path Keys [RFC5520].
Further considerations of the security issues related to inter-AS
path computation see [RFC5376].
9. IANA Considerations
This document makes no requests for IANA action.
10. Acknowledgements
The authors would like to acknowledge Fatai Zhang and Quintin Zhao
for their valuable comments and suggestions.
11. References
11.1 Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
11.2. Informative References
[RFC5152] Vasseur, J.P., Ed., Ayyangar, A., Ed., and R. Zhang,
"A Per-domain path computation method for computing
Inter-domain Traffic Engineering (TE) Label Switched
Path (LSP)",
King and Farrel [Page 20]
draft-king-hierarchy-fwk-01.txt October 2009
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest
inter-domain Traffic Engineering Label Switched
Paths", RFC5441, April 2009.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC5440, March 2009.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726,
November 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)",
RFC 5152, February 2008.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008.
[RFC5376] Bitar, N., et al., "Inter-AS Requirements for the
Path Computation Element Communication Protocol
(PCECP)", RFC 5376, November 2008.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 2008.
[RFC5541] Roux, J., Vasseur, J., and Y. Lee, "Encoding
of Objective Functions in the Path
Computation Element Communication
Protocol (PCEP)", RFC5541, December 2008.
[RFC5520] Brandford, R., Vasseur J.P., and Farrel A., "Preserving
Topology Confidentiality in Inter-Domain Path
Computation Using a Key-Based Mechanism
RFC5520, April 2009.
King and Farrel [Page 21]
draft-king-hierarchy-fwk-01.txt October 2009
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON).
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture
and Requirements for the Automatically
Switched Optical Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON
routing architecture and requirements for remote route
query.
12. Authors' Addresses
Daniel King
Old Dog Consulting
Email: daniel@olddog.co.uk
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
King and Farrel [Page 22]
draft-king-hierarchy-fwk-01.txt October 2009| PAFTECH AB 2003-2026 | 2026-04-23 16:04:47 |