1. Daniel King, Old Dog Consulting Adrian Farrel, Old Dog Consulting
The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS draft-king-pce-hierarchy-fwk-01.txt
Daniel King, Old Dog Consulting
Adrian Farrel, Old Dog Consulting
75th IETF Stockholm

2. Motivation
Using a PCE to compute a path between nodes within a single domain is relatively straightforward.
Using a PCE to compute paths across multiple domains requires an additional technique:
per-domain path computation techniques
Devolve the computation of a path segment to each domain entry point.
Suits simply-connected domains and where the preferred points of interconnection are known.
Backwards Recursive Path Computation (BRPC)
Allow the PCEs to collaborate to select an optimal end-to-end path that crosses multiple domains.
Suits environments where multiple connections exist between domains and there is no preference for the choice of points of interconnection.
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance.
Provide mechanisms that allow the optimum sequence of domains to be selected and the optimum end-to-end path to be derived.
75th IETF Stockholm

3. Navigating the Domain Mesh
Networks constructed from multiple sub-domains, or multi-AS environments often have multiple interconnect points.
In an ASON subnetwork the 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 subnetwork.
The traffic engineering properties of a domain cannot be seen from outside the domain.
TE aggregation or abstraction hides information and leads to failed path setup.
Flooding TE information breaks confidentiality and does not scale in the routing protocol and in the aggregation process.
Domain 3
Domain 1
Domain 2
Domain 5
Domain 4
75th IETF Stockholm

4. Requirements
Any solution needs to be scalable and maintain confidentiality while providing the optimal path. It also needs consider a number of factors:
Domain and Path Diversity
Traffic Engineering Constraints
Commercial constraints
Minimize or negate additional protocols
Be “scalable”
Any solution should avoid:
Flooding information
Disclose internal domain topologies

5. Hierarchical PCE
Hierarchical PCE provides the optimum path when the sequence of domains is not known in advance.
The Parent PCE maintains a topology map.
The nodes are the Child domains.
The map contains the inter-domain links.
The TE capabilities of the links are also known.
Parent PCE knows the identify and location of the child PCEs responsible for the Child domains.
Statically configured
Parent PCE maintains domain confidentiality
A Parent PCE is aware of the topology and connections between domains, but is not aware of the contents of the domains.
Child domains are completely confidential.
One child cannot know the topology of another Child.
Child domains do not know the general domain mesh connectivity.
75th IETF Stockholm

6. Hierarchical PCE: Initial information exchange
Example used in draft-king-pce-hierarchy-fwk-01
2. Child PCE listens to Child IGP and learns inter-domain connectivity.
1. Child PCE configured for its Parent PCE.
Domain 5
PCE 5
Domain 1
3. Child PCE establishes contact with Parent PCE.
PCE 1
BN 11
BN 12
4. Child PCE reports neighbor domain connectivity.
BN 13
5. Child PCE reports inter-domain link status change.
75th IETF Stockholm

7. Hierarchical PCE: Domain interconnectivity (Parent PCE)
Example used in draft-king-pce-hierarchy-fwk-01
Domain 5
PCE 5
Domain 1
Domain 2
Domain 3
Domain 4

8. Hierarchical PCE: Procedure
Example used in draft-king-pce-hierarchy-fwk-01
1. Ingress LSR sends a request to PCE1 for a path to egress.
Domain 5
7. Parent PCE sends edge to egress request to PCE3 .
6. Parent PCE send source to edge request to PCE 1.
PCE 5
Domain 1
Domain 3
3. PCE 1 sends computation request to parent PCE (PCE 5).
5. Parent PCE sends edge-to-edge computation requests to PCE 2 responsible for domain 2 and PCE 4 responsible for domain 4.
2. PCE 1 determines egress is not in domain 1.
PCE 3
PCE 1
Domain 2
BN 11
PCE 2
4. Parent PCE determines likely domain paths. D
BN 12 S
Domain 4
BN 13
PCE 4
8. Parent PCE correlates responses and applies policy requirements.
9. Parent PCE supplies ERO to PCE 1.
75th IETF Stockholm

9. Summary & Next Steps
The authors believe the work is timely and relevant.
Draft will continue to evolve:
Evaluating requirements.
Administration and Policy will be key.
Applicability to various environments should also be discussed.
Feedback requested on the mailing list or via unicast.
75th IETF Stockholm