Upload
everett-conway
View
216
Download
2
Tags:
Embed Size (px)
Citation preview
Page 1iPOP2009, Tokyo, Japan
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
Page 2iPOP2009, Tokyo, Japan Old Dog Consulting
Agenda
• Existing multi-domain PCE techniques
• Domain meshes
• Navigating the domain mesh
• Hierarchical PCE– Objective Functions– Procedures & Extensions
• Advanced applications
• Work to be done
Page 3iPOP2009, Tokyo, Japan Old Dog Consulting
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
Page 4iPOP2009, Tokyo, Japan Old Dog Consulting
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
Page 5iPOP2009, Tokyo, Japan Old Dog Consulting
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 2Domain 2 Domain 5Domain 5
Domain 3Domain 3
Domain 4Domain 4
Domain 1Domain 1
Page 6iPOP2009, Tokyo, Japan Old Dog Consulting
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
Page 7iPOP2009, Tokyo, Japan Old Dog Consulting
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
Page 8iPOP2009, Tokyo, Japan Old Dog Consulting
Domain 1PCE 1
S
BN 11
BN 12
BN 13
Domain 5
Hierarchical Domain Topology
PCE 5
Domain 2PCE 2
Domain 4PCE 4
Domain 3PCE 3
D
BN 21
BN 22
BN 23
BN 24
BN 31
BN 32
BN 41
BN 42
BN 33
Page 9iPOP2009, Tokyo, Japan Old Dog Consulting
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
Page 10iPOP2009, Tokyo, Japan Old Dog Consulting
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
Page 11iPOP2009, Tokyo, Japan Old Dog Consulting
Hierarchical PCE Procedures
• Hierarchical PCE, initial information exchange
Domain 1PCE 1
BN 11
BN 12
BN 13
PCE 5
Domain 5
1. Child PCE configured for its Parent PCE1. Child PCE configured for its Parent PCE2. Child PCE listens to Child IGP and learns inter-domain connectivity2. Child PCE listens to Child IGP and learns inter-domain connectivity
3. Child PCE establishes contact with Parent PCE3. Child PCE establishes contact with Parent PCE
4. Child PCE reports neighbor domain connectivity4. Child PCE reports neighbor domain connectivity
5. Child PCE reports inter-domain link status change5. Child PCE reports inter-domain link status change
Page 12iPOP2009, Tokyo, Japan Old Dog Consulting
• 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
Hierarchical PCE Procedures
Domain 5
Domain 1
PCE 5
Domain 2 Domain 3
Domain 4
Page 13iPOP2009, Tokyo, Japan Old Dog Consulting
Domain 1
S
Hierarchical PCE Procedures
PCE 1
BN 11BN 11
BN 12BN 12
BN 13BN 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 egress2. 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 to 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 17. Parent PCE sends edge to egress request to PCE3
Page 14iPOP2009, Tokyo, Japan Old Dog Consulting
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
Page 15iPOP2009, Tokyo, Japan Old Dog Consulting
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)
Page 16iPOP2009, Tokyo, Japan Old Dog Consulting
Questions?
Please feel free to send any questions to:
Adrian Farrel [email protected]
Daniel King [email protected]
Tomonori Takeda [email protected]