Title: Selecting Domain Paths in InterDomain MPLSTE and GMPLS
1Selecting Domain Paths in Inter-Domain MPLS-TE
and GMPLS
- Adrian Farrel, Old Dog Consulting
- Daniel King, Old Dog Consulting
- Tomonori Takeda, NTT
2Agenda
- Existing multi-domain PCE techniques
- Domain meshes
- Navigating the domain mesh
- Hierarchical PCE
- Objective Functions
- Procedures Extensions
- Advanced applications
- Work to be done
3Existing 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
4Existing 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
5Domain 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
6Navigating 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
7Hierarchical 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
8Hierarchical 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
9Hierarchical 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
10Hierarchical 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
11Hierarchical 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
12Hierarchical 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
13Hierarchical 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
14Advanced 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
15Work 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)
16Questions?
- 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