Selecting Domain Paths in Inter-Domain MPLS-TE and GMPLS

1. Selecting Domain Paths in Inter-Domain MPLS-TE and GMPLS Adrian Farrel, Old Dog Consulting Daniel King, Old Dog Consulting Tomonori Takeda, NTT Old Dog Consulting

2. Agenda • Existing multi-domain PCE techniques • Domain meshes • Navigating the domain mesh • Hierarchical PCE • Objective Functions • Procedures & Extensions • Advanced applications • Work to be done

3. Existing Multi-Domain PCE Techniques • PCE can be used to determine end-to-end paths in multi-domain GMPLS and MPLS-TE networks • 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 • The assumption is the sequence of domains is well known, these techniques do not suit complex domain environments • Large, meshy environments • Multi-homed and multiply interconnected domains • How do we derive an optimal end-to-end domain path sequences? • Definition of optimal will depend on policy • Optimal trees • Small number of domains crossed • Reduce the number of border routers used

4. Existing Multi-Domain PCE 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 (RFC 5441) domain sequence is already known • BRPC is good for selecting domain border nodes • Computation technique derives optimal end-to-end path • BRPC could be applied to domain selection • Functions correctly (optimal solution) • Significant scaling issues

5. Domain Meshes • Optical 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

6. Navigating the Domain Mesh • A 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.) • Commercial Constraints • The solution should provide the capability to include commercially relevant constraints such as policy, SLAs, security, peering preferences, and dollar costs

7. 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 or dynamically discovered • 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

8. Hierarchical Domain Topology Domain 5 PCE 5 Domain 1 Domain 2 Domain 3 PCE 1 PCE 2 PCE 3 BN 11 BN 21 BN 23 BN 31 BN 12 BN 22 BN 24 BN 32 S D Domain 4 PCE 4 BN 13 BN 33 BN 41 BN 42

9. Hierarchical PCE • Each Child PCE is configured with the address of its parent PCE • Typical, 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 • The Parent PCE could be configured with this information • The Parent PCE could learn about this information when they connect • Domain interconnection discovery • The Child PCE reports the following information to the Parent PCE: • Each Child PCE knows the identity of its neighbor domains • The IGP in each domain advertises inter-domain TE link capabilities • No further automated discovery is required • Multi-domain and multi-provider discovery is undesirable • Confidentiality • Security • Scalability

10. Hierarchical PCE Objective Functions • Metric objectives when computing a inter-domain paths may include: • Minimum cost path • Minimum load path • Maximum residual bandwidth path • Minimize aggregate bandwidth consumption • Limit the number of domains crossed • Policy objectives • Commercial relationships • Dollar costs of paths • Security implications • Domain reliability • Domain confidentiality • Intra-domain topologies and paths may be kept confidential • From other Child PCEs • From the Parent PCE

11. Hierarchical PCE Procedures • Hierarchical PCE, initial information exchange 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

12. Hierarchical PCE Procedures • Domain interconnectivity as seen by the Parent PCE • The Parent PCE maintains a topology map of the Child domains and their interconnectivity • Parent PCE cannot see the internal topology of Child domain PCE 5 Domain 5 Domain 1 Domain 2 Domain 3 Domain 4

13. Hierarchical PCE Procedures Domain 5 PCE 5 Domain 1 Domain 3 1. Ingress LSR sends a request to PCE1 for a path to egress 2. PCE 1 determines egress is not in domain 1 PCE 3 PCE 1 Domain 2 BN 11 PCE 2 3. PCE 1 sends computation request to parent PCE (PCE 5) 4. Parent PCE determines likely domain paths D BN 12 S 5. Parent PCE sends edge-to-edge computation requests to PCE 2 responsible for domain 2, and to PCE 4 responsible for domain 4 Domain 4 6. Parent PCE send source to edge request to PCE 1 BN 13 PCE 4 7. Parent PCE sends edge to egress request to PCE3 8. Parent PCE correlates responses and applies policy requirements 9. Parent PCE supplies ERO to PCE 1

14. Advanced Applications • Confidentiality • Simple application of PCE path-key • Parent PCE does not need to know the confidential information from domains • Point-to-multipoint • Applies to multi-domain networks • See later presentation for more information (Multicast over optical multi-domain networks) • Multi-level hierarchy • Parent PCE may itself have a parent • Regional and administrative hierarchies • Horizontal cooperation between Parents • Parent PCEs could cooperate using existing PCE cooperation techniques • Cooperation between peer geographic or administrative hierarchies

15. Work to be done • How do I know which domain contains my destination? • Discovery is impractical unless addressing identifies the domain • It is usual for the source to know the destination location • Publish framework draft as RFC • draft-king-pce-hierarchy-fwk • Minor protocol extensions • Applicability statements • Point-to-multipoint • Applicability to ASON routing (G.7715.2)

16. Questions? Please feel free to send any questions to: Adrian Farrel adrian@olddog.co.uk Daniel King daniel@olddog.co.uk Tomonori Takeda takeda.tomonori@lab.ntt.co.jp