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 ConsultingAdrian Farrel, Old Dog Consulting

75th IETF Stockholm

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

Existing Techniques• Per domain

– With per domain the sequence of domains is known.– Domain border nodes are also usually known.– Computation technique builds path segments across individual domains.– Domain choice is only possible with crankback.– The mechanism does not guarantee an optimal path.

• BRPC– Current definition, RFC5441, domain sequence is already known.– BRPC is good for selecting domain border nodes.– Computation technique derives optimal end-to-end path.– BRPC can be applied to domain selection.

• Functions correctly (optimal solution) • Significant scaling issues

75th IETF Stockholm

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 2 Domain 5

Domain 3

Domain 4

Domain 1

75th IETF Stockholm

Navigating the Domain Mesh• A PCE-based computation 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• Domain diversity should facilitate the selection of paths that share ingress and

egress domains, but do not share transit domains .• Domain path selection should provide the capability to include or exclude specific

border nodes.

– Existing Traffic Engineering Constraints • The solution should take advantage of typical traffic engineering constraints (hop

count, bandwidth, lambda continuity, path cost, etc.).

75th IETF Stockholm

Hierarchical PCE• 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

• 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

Hierarchical PCE: initial information exchange

Example used in draft-king-pce-hierarchy-fwk-01

Domain 1PCE 1

BN 11

BN 12

BN 13

PCE 5Domain 5

1. Child PCE configured for its Parent PCE.2. Child PCE listens to Child IGP and learns inter-domain connectivity.

3. Child PCE establishes contact with Parent PCE.

4. Child PCE reports neighbor domain connectivity.

5. Child PCE reports inter-domain link status change.

75th IETF Stockholm

Hierarchical PCE: Domain interconnectivity (Parent PCE)

Domain 5

Domain 1

PCE 5

Domain 2 Domain 3

Domain 4

Example used in draft-king-pce-hierarchy-fwk-01

Hierarchical PCE Procedure

Domain 1

PCE 1

S

BN 11

BN 12

BN 13

PCE 5 Domain 5

Domain 2

PCE 2

Domain 4

PCE 4

Domain 3

PCE 3

D

1. Ingress LSR sends a request to PCE1 for a path

to egress.2. PCE 1 determines egress is not in domain 1.

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.

4. Parent PCE determines likely

domain paths.

8. Parent PCE correlates responses and applies policy requirements.

9. Parent PCE supplies ERO to PCE 1.

6. Parent PCE send source to

edge request to PCE 1.7. Parent PCE sends edge to egress request to PCE3 .

75th IETF Stockholm

Example used in draft-king-pce-hierarchy-fwk-01

Summary & Next Steps

• Draft will continue to evolve:- Administration and Policy are key areas for discussion.- Applicability to various environments should also be discussed.

• Authors would like to request this work becomes a WG document.

• Feedback requested on the mailing list!

75th IETF Stockholm