Stateful Path Computation
Element (PCE) Inter-domain ConsiderationsHuawei TechnologiesDivyasree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comHuawei TechnologiesBantian, Longgang DistrictShenzhen518129P.R.Chinazhang.xian@huawei.com
Routing
PCE Working Group
A stateful Path Computation Element (PCE) maintains information about
Label Switched Path (LSP) characteristics and resource usage within a
network in order to provide traffic engineering path calculations for its
associated Path Computation Clients (PCCs). Furthermore, PCEs are used to
compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains.This document describes general considerations for the deployment of stateful PCE(s)
in inter-domain scenarios including inter-area and inter-AS. The inter-layer considerations
will be described in a separate document. This document does not specify any extentions to PCEP.The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients' (PCCs) requests. describes
general considerations for a stateful PCE deployment and examines its
applicability and benefits, as well as its challenges and limitations
through a number of use cases.
describes a set of extensions to PCEP to
provide stateful control. A stateful PCE has access to not only the
information carried by the network's Interior Gateway Protocol (IGP),
but also the set of active paths and their reserved resources for its
computations. The additional state allows the PCE to compute
constrained paths while considering individual LSPs and their
interactions.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 motivation for PCE
development. 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).This document presents general considerations for stateful PCE(s) deployment
in multi-domain scenarios.A stateful PCE maintains two sets of information for use in path
computation. The first is the Traffic Engineering Database (TED)
which includes the topology and resource state in the network.
The second is the LSP State Database (LSP-DB), in which a PCE stores
attributes of all active LSPs in the network, such as their paths
through the network, bandwidth/resource usage, switching types and
LSP constraints. This state information allows the PCE to compute
constrained paths while considering individual LSPs and their
inter-dependency. applies
equally to MPLS-TE and GMPLS LSPs
and distinguishes between an active and a passive stateful PCE. A
passive stateful PCE uses LSP state information to optimize path
computations but does not actively update LSP state. In contrast, an
active stateful PCE may issue recommendations to the network. For
example, an active stateful PCE may update LSP parameters for those
LSPs that have been delegated control over to the PCE by its PCCs.The capability to compute the routes of end-to-end inter-domain
MPLS-TE LSPs is expressed as requirements in
and and may be
realized by PCE(s). PCEs may use one of the following mechanisms to
compute end-to-end paths: a per-domain path computation technique ;a Backward-Recursive PCE-based Computation (BRPC) mechanism
;a Hierarchical PCE mechanism ;This document examines the stateful PCE inter-domain considerations
for all of these mechanisms.The population of the LSP-DB using information received from PCCs
(ingress LSR) is supported by the stateful PCE extensions defined in
, i.e., via LSP state
report messages.The inter-domain LSP state is synchronized to the ingress-PCE from
the ingress LSR (PCC), but this PCC cannot synchronize to other PCEs
(in transit or egress domains), thus other mechanism must be investigated for
this purpose.Either the boundary node of the other domains, would need to synchronize the state of
LSP passing though it to the PCE, or a mechanism for synchronization of inter-domain
LSPs between the PCEs is required. The former would require small change in the
existing state synchronization and reporting where a border node acts as a PCC.
The later could use the mechanism described in
can be used between the PCEs to synchronize the inter-domain LSP state between each
other. Further section provide various considerations for this choice. There are multiple models to perform PCE-based inter-domain path
computation:
A single PCEMultiple PCEs
without inter-PCE communicationwith inter-PCE communicationThis section describe stateful PCE considerations for each
of these deployment models.In this model, inter-domain path computation is
performed by a single stateful PCE that has topology visibility into all
domains. The inter-domain LSP state is synchronized to the PCE from
the ingress LSR (PCC) itself. The PCC may also choose to delegate
control over this LSP to the PCE. Thus this model is similar to a
single domain in all aspects.Following figure show an example of inter-area case comprising
of Area 0,1 and 2. A single stateful PCE is deployed for all areas.
In this model, PCE has visibility into the topology (TED) of all
domains as well as the state of all active LSPs (LSP-DB) including
inter-domain LSPs. This model is thus well suited to take advantage
of all stateful PCE capabilities.It should be noted that in some deployments, a single stateful PCE may not be
possible because of administrative and confidentiality concerns.In this model, there is at least one PCE per domain,
and each PCE has topology (TED) visibility restricted to its own domain.
The inter-domain LSP state is synchronized to the ingress-PCE from
the ingress LSR (PCC), but this PCC may not be able to synchronize
to other PCEs
(in transit or egress domains). This PCC may also choose to delegate
control over this LSP to the Ingress-PCE, which may issue
inter-domain path computation or re-optimization request to
other PCEs. An inter-domain LSP that originates in a domain, is
synchronized to the PCE in that domain. A new procedure is needed
to synchronize state of inter-domain LSP that do not originate in
the domain. In other words, inter-domain LSP state should also be
synchronized to transit and egress PCEs as the inter-domain LSP
traverse through those domains.Following figure show an example of inter-AS case comprising
of AS 100 and AS 200. A stateful PCE is deployed per AS.
In order to conceal the information, a PCE may use path-key based
confidentiality mechanisms as per .This section further describes considerations with respect to
each of the inter-domain path computation techniques.The per domain path computation technique
is based on Multiple PCE Path Computation without Inter-PCE
Communication Model as described in .
It 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.The ingress LSR would synchronize the state to the ingress
PCE, further the entry boundary nodes should also synchronize the state of
inter-domain LSP to transit and egress PCEs. Note that the BN on the
path of an LSP can probably see the path (through the Record
Route object in RSVP-TE signaling ) and
knows the bandwidth reserved for the LSP. Thus each
entry BN along the path could be made responsible to synchronize
the LSP state to the transit/egress PCE(s).Since the stateful PCE(s) do not communicate during this
inter-domain path computation technique and each entry BN would perform
path computation via Path Computation Request (PCReq) and Reply (PCRep) messages,
a passive
stateful PCE is well suited for this case.In case of delegation to the ingress PCE (active stateful PCE), it would be capable of
loose path computation only and make updates to the ingress LSR with
this limited visibility. The entry BN would perform
path computation via Path Computation Request and Reply messages (and thus rely on
the passive stateful mode). Thus the
inter-domain LSP is delegated only to the ingress PCE.The BRPC technique is based on
Multiple PCE Path Computation with Inter-PCE Communication Model
as described in . It 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 may be
known before the path computation, but it can also be used when the
domain path is unknown and determined during path computation.As described in , the entry boundary nodes
may synchronize the state of inter-domain LSPs to transit and egress
PCEs. An alternative approach may be for each PCE to synchronize the state
along the path across domains, i.e., each PCE would report the
state to the next PCE(s) in the adjacent domain along the domain
sequence of the inter-domain path. A mechanism described in
can be
utilized to synchronize between inter-domain PCEs.Some path segment in the end to end path may also be
hidden via path-key as per during state
synchronization.In case of passive path computation request to the ingress PCE
from the ingress LSR the BRPC path computation procedure is applied
to compute end-to-end path by using PCReq and PCRep
messages among stateful PCE(s) in passive mode. In case of delegation to the ingress PCE (active stateful PCE), the
ingress PCE may trigger the end-to-end path computation via the same
BRPC procedure using the path computation request and
reply messages among stateful PCE(s) (acting in passive mode). For
re-optimization the ingress PCE still rely on the same
BRPC procedure triggered by the ingress PCE. Ultimately the inter-domain LSP
is delegated to the ingress PCE and only the ingress PCE can
trigger end-to-end (E2E) path re-optimization with help of
transit/egress PCE using the BRPC procedure, based on the result
the ingress PCE would issue updates to the inter-domain LSP.
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.As described in and , the entry boundary nodes
may synchronize the state of inter-domain LSP to transit and egress
child PCEs. In this case, it might not be possible to synchronize state to the
parent PCE.
If the parent PCE provides the sequence of domains and BRPC
procedure is used to get the E2E path, each PCE may be responsible to synchronize the state
along the path across domains similar to .
An alternative approach may be for ingress PCE to synchronize
LSP state with the Parent PCE and it may further synchronize the state
to the child PCE(s) along the path across domains, i.e. parent PCE would report the
state to the child PCE(s) along the domain
sequence. A mechanism described in
can be
utilized to synchronize between the child and the parent PCE.Some path segment in the end to end path may also be
hidden via path-key as per during state synchronization.In case of passive path computation request to the ingress PCE
from the ingress LSR, the H-PCE path computation procedure is applied
to compute sequence of domains or end-to-end path by using PCReq and
PCRep messages among stateful PCE(s) in passive mode. In case of delegation to the ingress PCE (active stateful PCE), the
ingress child PCE may further delegate to parent PCE. See for
details. As noted in this document, the inter-domain LSP
is delegated to the ingress PCE and only the ingress PCE can issue updates to
the inter-domain LSP. The ingress PCE is responsible to trigger E2E path
re-optimization.Thus the ingress PCE can recommend updation for all aspects of the inter-domain LSP
including the segment of path in another domain (which it may have computed
with the help of other cooperating PCEs). These interaction between PCEs
for the inter-domain path computation are done using PCReq/PCRep messages
(i.e., in a passive mode).The transit/egress PCE cannot update any attribute of the inter-domain LSP
on its own as it may not have any interaction with the ingress LSR. A mechanism
may be developed for transit/egress PCE to inform the ingress PCE
to trigger E2E re-optimization and choose to update the inter-domain LSP based
on the result. Also the ingress PCE may use combination of local information
and events along with some external mechanism (management / monitoring interface)
to trigger E2E path re-optimization.
Though ingress PCE can recommend update for path segments in other domains,
the entry boundary node of that domain can apply policy control during signalling
as explained in and . describes setup,
maintenance and teardown of PCE-initiated LSPs under the stateful
PCE model, without the need for
local configuration on the PCC. Similar to LSP updation,
the inter-domain LSP can be initiated by the ingress PCE using the
PCInitiate message to the ingress LSR. Note that per-domain LSP may
also be initiated by respective domain's PCE and stitched together
but this is out of scope for this document.The security considerations are as per and
. Any multi-domain operation
necessarily involves the exchange
of information across domain boundaries. This may represent a
significant security and confidentiality risk especially when the
domains are controlled by different commercial entities. PCEP
allows individual PCEs to maintain confidentiality of their domain
path information by using path-keys .Mechanisms defined in this document do not imply any new control of
function and policy requirements. describes the PCEP MIB, there are no new MIB Objects
for this document.Mechanisms defined in this document do not imply any new liveness detection
and monitoring requirements in addition to those already listed in
.Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
.Mechanisms defined in this document do not imply any new requirements
on other protocols.Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in
.This is an informational document and has no IANA considerations.The authors would like to that Young Lee, Haomian Zheng, Fatai Zhang for this comments.