Selecting Domain Paths in InterDomain MPLSTE 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

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 2
Domain 5
Domain 1
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
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
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_at_olddog.co.uk
• Daniel King daniel_at_olddog.co.uk
• Tomonori Takeda takeda.tomonori_at_lab.ntt.co.jp