PCE support for Domain Diversity

The ability to compute shortest constrained TE LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous Systems (AS). In a multi-domain environment, Domain Diversity is defined in . A pair of paths are domain-diverse if they do not traverse any of the same transit domains. Domain diversity may be maximized for a pair of paths by selecting paths that have the smallest number of shared domains. Path computation should facilitate the selection of domain diverse paths as a way to reduce the risk of shared failure and automatically helps to ensure path diversity for most of the route of a pair of LSPs. This document examine a way to achieve domain diversity with existing inter-domain path computation mechanism like per-domain path computation technique , Backward Recursive Path Computation (BRPC) mechanism and Hierarchical PCE . This document also considers synchronized dependent path computations as well as non-synchronized path computation. Since independent and synchronized path computation cannot be used to apply diversity, it is not discussed in this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The terminology is as per .

As described in , a set of paths are considered to be domain diverse if they do not share any transit domains, apart from ingress and egress domains. Some additional parameters to consider would be - When a fully domain diverse path is not possible, PCE could be requested to minimize the number of shared transit domains. This can also be termed as maximizing partial domain diversity. TBD

The per domain path computation technique defines a method where the path is computed during the signaling process (on a per-domain basis). The entry Boundary Node (BN) of each domain is responsible for performing the path computation for the section of the LSP that crosses the domain, or for requesting that a PCE for that domain computes that piece of the path. Path computations are performed in a serialized and independent fashion. After the setup of primary path, a domain diverse path can be signaled by encoding the transit domain identifiers in XRO or EXRS using domain sub-objects defined in and in RSVP-TE. Note that the head end LSR should be aware of transit domain identifiers of the primary path to be able to do so. Not Applicable.

The BRPC technique involves cooperation and communication between PCEs in order to compute an optimal end-to-end path across multiple domains. The sequence of domains to be traversed maybe known before the path computation, but it can also be used when the domain path is unknown and determined during path computation. Path computations are performed in a serialized and independent fashion. After the path computation and setup of primary path, a domain diverse path computation request is sent by PCC to the PCE, by encoding the transit domain identifiers in XRO or EXRS using domain sub-objects defined in and in PCEP. Note that the PCC should be aware of transit domain identifiers of the primary path to be able to do so. Not Applicable. [Since different transit domain PCEs are involved , there is no way to achieve synchronization for domain diverse paths]. BTW describes other diversity parameters (node, link etc).

In H-PCE architecture, the parent PCE is used to compute a multi-domain path based on the domain connectivity information. The parent PCE may be requested to provide a end to end path or only the sequence of domains.

Path computations are performed in a serialized and independent fashion. After the path computation and setup of primary path, a domain diverse path computation request is sent to the parent PCE, by encoding the transit domain identifiers in XRO or EXRS using domain sub-objects defined in and in PCEP. Note that the PCC should be aware of transit domain identifiers of the primary path to be able to do so. The parent PCE should provide a domain diverse end to end path. Child PCE should be able to request dependent and synchronized domain diverse end to end paths from its parent PCE. A new flag is added in SVEC object for this (Refer ).

Path computations are performed in a serialized and independent fashion. After the primary path computation using H-PCE (involving domain-sequence selection by parent PCE and end-to-end path computation via BRPC or Per-Domain mechanisms) and setup, a domain diverse path computation request is sent to the parent PCE, by encoding the transit domain identifiers in XRO or EXRS using domain sub-objects defined in and in PCEP. Note that the PCC should be aware of transit domain identifiers of the primary path to be able to do so. The parent PCE should provide a diverse domain sequence. Child PCE should be able to request dependent and synchronized diverse domain-sequence(s) from its parent PCE. A new flag is added in SVEC object for this (Refer ). The parent PCE should reply with diverse domain sequence(s) encoded in ERO as described in .

defines SVEC object which includes flags for the potential dependency between the set of path computation requests (Link, Node and SRLG diverse). This document proposes a new flag O for domain diversity. The format of the SVEC object body is as follows:

Following new bit is added in the Flags field: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any transit domain(s) in common. The Domain Diverse O-bit can be used in Hierarchical PCE path computation to compute synchronized domain diverse end to end path or diverse domain sequences as described in . When domain diverse O bit is set, it is applied to the transit domains. The other bit in SVEC object (N, L etc) is set, should still be applied in the ingress and egress domain.

In case of non-synchronized path computation, Ingress node (i.e. a PCC) should be aware of transit domain identifiers of the primary path. So during the path computation or signaling of the primary path, the transit domain should be identified. A possible solution for path computation could be a flag in RP object requesting domain identifier to be returned in the PCEP path reply message. Further details - TBD

A new Objective function (OF) code for synchronized path computation requests is proposed: MCTD Minimize the number of Common Transit Domains. TBD Find a set of paths such that it passes through the least number of common transit domains. The MCTD OF can be used in Hierarchical PCE path computation to request synchronized domain diverse end to end paths or diverse domain sequences as described in . For non synchronized diverse domain path computation the X bit in XRO or EXRS sub-objects can be used, where X bit set as 1 indicates that the domain specified SHOULD be excluded from the path computed by the PCE, but MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints and excludes the domain.

TBD.

We would like to thank Qilei Wang for starting this discussion in the mailing list.