Old Dog Consulting by sdfwerte


									                  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

iPOP2009, Tokyo, Japan                                       Page 1

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

        iPOP2009, Tokyo, Japan             Old Dog Consulting   Page 2
Existing Multi-Domain PCE Techniques

 •   PCE can be used to determine end-to-end paths in multi-domain GMPLS and MPLS-TE
      –   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
      –   Backwards Recursive Path Computation (BRPC)
            • Allow the PCEs to collaborate to select an optimal end-to-end path that crosses multiple
            • 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

          iPOP2009, Tokyo, Japan                                          Old Dog Consulting             Page 3
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

         iPOP2009, Tokyo, Japan                                       Old Dog Consulting   Page 4
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

                                                     Domain 3

          Domain 1            Domain 2                                     Domain 5

                                                     Domain 4

•   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

         iPOP2009, Tokyo, Japan                                            Old Dog Consulting               Page 5
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

         iPOP2009, Tokyo, Japan                                   Old Dog Consulting          Page 6
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

          iPOP2009, Tokyo, Japan                                         Old Dog Consulting            Page 7
Hierarchical Domain Topology

                                   Domain 5   PCE 5

          Domain 1                 Domain 2                  Domain 3
           PCE 1                    PCE 2                      PCE 3
                     BN       BN              BN      BN
                     11       21              23      31

                     BN       BN              BN      BN
             S       12       22              24      32         D

                                   Domain 4
                                    PCE 4

            BN                                                   BN
                              BN              BN
            13                                                   33
                              41              42

     iPOP2009, Tokyo, Japan                           Old Dog Consulting   Page 8
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
            • 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

          iPOP2009, Tokyo, Japan                                         Old Dog Consulting   Page 9
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

          iPOP2009, Tokyo, Japan                                       Old Dog Consulting   Page 10
Hierarchical PCE Procedures

 •    Hierarchical PCE, initial information exchange
                                                               2. Child PCE listens to Child IGP and learns
       1. Child PCE configured for its Parent PCE              inter-domain connectivity

                                                        Domain 5            PCE 5

                                                    Domain 1
                                                      PCE 1                                 3. Child PCE establishes
                                                                                            contact with Parent PCE


                                                                BN                         4. Child PCE reports neighbor
                                                                12                         domain connectivity

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

             iPOP2009, Tokyo, Japan                                                   Old Dog Consulting               Page 11
Hierarchical PCE Procedures

 •   Domain interconnectivity as seen by the Parent PCE
      – The Parent PCE maintains a topology map of the Child domains and their

                                                 PCE 5
                                      Domain 5

              Domain 1                Domain 2                Domain 3

                                      Domain 4

 •   Parent PCE cannot see the internal topology of Child domain

         iPOP2009, Tokyo, Japan                               Old Dog Consulting   Page 12
Hierarchical PCE Procedures

1. Ingress LSR sends a
request to PCE1 for a path                             PCE 5       Domain 5
to egress                              Domain 1                                         Domain 3
2. PCE 1 determines egress
is not in domain 1                       PCE 1                                              PCE 3
3. PCE 1 sends computation                        BN      Domain 2
request to parent PCE (PCE 5)                              PCE 2
4. Parent PCE determines likely
domain paths                                      BN
5. Parent PCE sends
edge-to-edge computation                   S
requests to PCE 2 responsible
for domain 2, and to PCE 4
responsible for domain 4
6. Parent PCE send source to
edge request to PCE 1                                     Domain 4
7. Parent PCE sends edge to
                                          BN                   PCE 4
egress request to PCE3                    13

8. Parent PCE correlates
responses and applies policy

 9. Parent PCE supplies ERO to PCE 1

           iPOP2009, Tokyo, Japan                                      Old Dog Consulting           Page 13
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

          iPOP2009, Tokyo, Japan                                            Old Dog Consulting         Page 14
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)

          iPOP2009, Tokyo, Japan                                             Old Dog Consulting   Page 15

 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

      iPOP2009, Tokyo, Japan                         Old Dog Consulting   Page 16

To top