Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic EngineeringOld Dog Consultingdaniel@olddog.co.uk华为技术有限公司松山湖华为溪流背坡村H1东莞广东523808中国zhenghaomian@huawei.comPCE Working Group
The Path Computation Element (PCE) may be used for computing services
that traverse multi-area and multi-Autonomous System (multi-AS) Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.
This document examines the applicability of the PCE architecture,
protocols, and protocol extensions for computing multi-area and
multi-AS paths in MPLS and GMPLS networks.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Domains
. Path Computation
. PCE-Based Path Computation Procedure
. Traffic Engineering Aggregation and Abstraction
. Traffic-Engineered Label Switched Paths
. Inter-area and Inter-AS-capable PCE Discovery
. Objective Functions
. Terminology
. Issues and Considerations
. Multihoming
. Destination Location
. Domain Confidentiality
. Domain Topologies
. Selecting Domain Paths
. Domain Sizes
. Domain Diversity
. Synchronized Path Computations
. Domain Inclusion or Exclusion
. Applicability of the PCE to Inter-area Traffic Engineering
. Inter-area Routing
. Area Inclusion and Exclusion
. Strict Explicit Path and Loose Path
. Inter-Area Diverse Path Computation
. Applicability of the PCE to Inter-AS Traffic Engineering
. Inter-AS Routing
. AS Inclusion and Exclusion
. Inter-AS Bandwidth Guarantees
. Inter-AS Recovery
. Inter-AS PCE Peering Policies
. Multi-domain PCE Deployment Options
. Traffic Engineering Database and Synchronization
. Applicability of BGP-LS to PCE
. Pre-planning and Management-Based Solutions
. Domain Confidentiality
. Loose Hops
. Confidential Path Segments and Path-Keys
. Point to Multipoint
. Optical Domains
. Abstraction and Control of TE Networks (ACTN)
. Policy
. Manageability Considerations
. Control of Function and Policy
. Information and Data Models
. Liveness Detection and Monitoring
. Verifying Correct Operation
. Impact on Network Operation
. Security Considerations
. Multi-domain Security
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
Introduction
Computing paths across large multi-domain environments may
require special computational components and cooperation between
entities in different domains capable of complex path computation.
Issues that may exist when routing in multi-domain networks include the
following:
There is often a lack of full topology and TE information across
domains.
No single node has the full visibility to determine an optimal or
even feasible end-to-end path across domains.
Knowing how to evaluate and select the exit point and next domain
boundary from a domain.
Understanding how the ingress node determines which domains should
be used for the end-to-end path.
An information exchange across multiple domains is often limited due to
the lack of trust relationship, security issues, or scalability
issues, even if there is a trust relationship between domains.
The Path Computation Element (PCE) provides an architecture
and a set of functional components to address the problem space and the
issues highlighted above.
A PCE may be used to compute end-to-end paths across multi-domain
environments using a per-domain path computation technique .
The so-called backward recursive PCE-based computation (BRPC) mechanism
defines a path computation procedure to compute
inter-domain constrained Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.
However,
both per-domain and BRPC techniques assume that the sequence of
domains to be crossed from source to destination is known, either
fixed by the network operator or obtained by other means.
In more advanced deployments (including multi-area and multi-Autonomous System (multi-AS) environments), the sequence of domains
may not be known in advance, and the choice of domains in the end-to-end
domain sequence might be critical to the determination of an
optimal end-to-end path. In this case, the use of the hierarchical PCE
architecture and mechanisms may be used to discover the
intra-area path and select the optimal end-to-end domain sequence.
This document describes the processes and procedures available when
using the PCE architecture and protocols for computing inter-area
and inter-AS MPLS and GMPLS Traffic-Engineered paths.
The scope of this document does not include discussions of deployment
scenarios for stateful PCE, active PCE, remotely initiated PCE, or
PCE as a central controller (PCECC).
Domains
Generally, a domain can be defined as a separate administrative,
geographic, or switching environment within the network. A domain
may be further defined as a zone of routing or computational ability.
Under these definitions, a domain might be categorized as an
Autonomous System (AS) or an Interior Gateway Protocol (IGP) area
(as per and ).
For the purposes of this document, a domain is considered to be a
collection of network elements within an area or AS that has a
common sphere of address management or path computational
responsibility. Wholly or partially overlapping domains are not
within the scope of this document.
In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork
. In this case, 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 subnetworks. Furthermore, a domain might be an
ASON routing area . A PCE may perform the path computation
function of an ASON Routing Controller as described in .
It is assumed that the PCE architecture is not applied to a large
group of domains, such as the Internet.Path Computation
For the purpose of this document, it is assumed that path computation is the sole responsibility of the PCE as per the
architecture defined in . When a path is required, the Path
Computation Client (PCC) will send a request to the PCE. The PCE
will apply the required constraints, compute a path, and return a
response to the PCC. In the context of this document, it may be
necessary for the PCE to cooperate with other PCEs in adjacent
domains (as per BRPC ) or with a parent PCE
(as per ).
It is entirely feasible that an operator could compute a path across
multiple domains without the use of a PCE if the relevant domain
information is available to the network planner or network management
platform. The definition of what relevant information is required to
perform this network planning operation and how that information is
discovered and applied is outside the scope of this document.PCE-Based Path Computation Procedure
As highlighted, the PCE is an entity capable of computing an
inter-domain TE path upon receiving a request from a PCC. There could
be a single PCE per domain or a single PCE responsible for all
domains. A PCE may or may not reside on the same node as the
requesting PCC. A path may be computed by either a single PCE node
or a set of distributed PCE nodes that collaborate during path
computation.
According to , a PCC should send a path computation request
to a particular PCE using (PCC-to-PCE communication).
This negates the need to broadcast a request to all the PCEs. Each
PCC can maintain information about the computation capabilities
of the PCEs it is aware of. The PCC-PCE capability awareness can be
configured using static configurations or by automatic and dynamic
PCE discovery procedures.
If a network path is required, the PCC will send a path computation
request to the PCE. A PCE may then compute the end-to-end path
if it is aware of the topology and TE information required to
compute the entire path. If the PCE is unable to compute the
entire path, the PCE architecture provides cooperative PCE
mechanisms for the resolution of path computation requests when an
individual PCE does not have sufficient TE visibility.
End-to-end path segments may be kept confidential through the
application of Path-Keys to protect partial or full path
information. A Path-Key is a token that replaces a path segment
in an explicit route. The Path-Key mechanism is described in
.Traffic Engineering Aggregation and Abstraction
Networks are often constructed from multiple areas or ASes that are
interconnected via multiple interconnect points. To maintain
network confidentiality and scalability, the TE properties of each area
and AS are not generally advertised outside each specific area or AS.
TE aggregation or abstraction provide a mechanism to hide information
but may cause failed path setups or the selection of suboptimal end-
to-end paths . The aggregation process may also have
significant scaling issues for networks with many possible routes
and multiple TE metrics. Flooding TE information breaks
confidentiality and does not scale in the routing protocol.
The PCE architecture and associated mechanisms provide a solution
to avoid the use of TE aggregation and abstraction.Traffic-Engineered Label Switched Paths
This document highlights the PCE techniques and mechanisms that exist
for establishing TE packet and optical Label Switched Paths (LSPs) across multiple areas
(inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and
within the remainder of this document, we consider all LSPs to be
constraint based and traffic engineered.
Three signaling options are defined for setting up an inter-area or
inter-AS LSP :
Contiguous LSP
Stitched LSP
Nested LSP
All three signaling methods are applicable to the architectures and
procedures discussed in this document.Inter-area and Inter-AS-capable PCE Discovery
When using a PCE-based approach for inter-area and inter-AS path
computation, a PCE in one area or AS may need to learn information
related to inter-AS-capable PCEs located in other ASes. The PCE
discovery mechanism defined in and facilitates
the discovery of PCEs and disclosure of information related to
inter-area and inter-AS-capable PCEs.Objective Functions
An Objective Function (OF) or a set of OFs specifies the
intentions of the path computation and so defines the "optimality"
in the context of the computation request.
An OF specifies the desired outcome of a computation. It does not
describe or specify the algorithm to use. Also, an implementation
may apply any algorithm or set of algorithms to achieve the result
indicated by the OF. A number of general OFs are specified in
.
Various OFs may be included in the PCE computation request to
satisfy the policies encoded or configured at the PCC, and a PCE
may be subject to policy in determining whether it meets the OFs
included in the computation request or whether it applies its own OFs.
During inter-domain path computation, the selection of a domain
sequence, the computation of each (per-domain) path fragment, and the
determination of the end-to-end path may each be subject to different
OFs and policies.
Terminology
This document also uses the terminology defined in and
. Additional terminology is defined below:
ABR:
IGP Area Border Router -- a router that is attached to more than
one IGP area.
ASBR:
Autonomous System Border Router -- a router used to connect
together ASes of a different or the same Service Provider via one or more inter-AS links.
Inter-area TE LSP:
A TE LSP whose path transits through two or more
IGP areas.
Inter-AS MPLS TE LSP:
A TE LSP whose path transits through two or
more ASes or sub-ASes (BGP confederations)
SRLG:
Shared Risk Link Group.
TED:
Traffic Engineering Database, which contains the
topology and resource information of the domain. The TED may be fed
by Interior Gateway Protocol (IGP) extensions or potentially by other
means.
Issues and ConsiderationsMultihoming
Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multihoming). End-to-end path
computations may need to use different interconnect points to avoid
a single-point failure disrupting both the primary and backup services.Destination Location
A PCC asking for an inter-domain path computation is typically
aware of the identity of the destination node. If the PCC is aware
of the destination domain, it may supply the destination domain
information as part of the path computation request. However, if the
PCC does not know the destination domain, this information must be
determined by another method.Domain Confidentiality
When the end-to-end path crosses multiple domains, it may be possible that
each domain (AS or area) is administered by separate Service Providers.
Thus, if a PCE supplies a path segment to a PCE in another domain, it may
break confidentiality rules and could disclose AS-internal topology
information.
If confidentiality is required between domains (ASes and areas)
belonging to different Service Providers, then cooperating PCEs
cannot exchange path segments; otherwise, the receiving PCE or PCC will
be able to see the individual hops through another domain.
This topic is discussed further in of this document.Domain Topologies
Constraint-based inter-domain path computation is a fundamental
requirement for operating traffic-engineered MPLS and
GMPLS networks in inter-area and inter-AS (multi-domain)
environments. Path computation across multi-domain networks is
complex and requires computational cooperational entities like the
PCE.Selecting Domain Paths
Where the sequence of domains is known a priori, various techniques
can be employed to derive an optimal multi-domain path. If the
domains are connected to a simple path with no branches and single
links between all domains or if the preferred points of
interconnection are also known, the per-domain path computation
technique may be used. Where there are multiple connections
between domains and there is no preference for the choice of points
of interconnection, BRPC can be used to derive an optimal
path.
When the sequence of domains is not known in advance or the
end-to-end path will have to navigate a mesh of small domains
(especially typical in optical networks), the optimum path may be
derived through the application of a hierarchical PCE .Domain Sizes
Very frequently, network domains are composed of dozens or hundreds of
network elements. These network elements are usually interconnected
in a partial-mesh fashion to provide survivability against dual
failures and to benefit from the traffic-engineering capabilities
of MPLS and GMPLS protocols. Network operator feedback in the
development of the document highlighted that the node degree (the number
of neighbors per node) typically ranges from 3 to 10 (4-5 is quite
common).Domain Diversity
Domain and path diversity may also be required when computing
end-to-end paths. Domain diversity should facilitate the selection
of paths that share ingress and egress domains but do not share
transit domains. Therefore, there must be a method allowing the
inclusion or exclusion of specific domains when computing end-to-end paths.Synchronized Path Computations
In some scenarios, it would be beneficial for the operator to rely on
the capability of the PCE to perform synchronized path computation.
Synchronized path computations, known as Synchronization VECtors
(SVECs), are used for dependent path computations. SVECs are
defined in , and provides an overview of the
use of the PCE SVEC list for synchronized path computations when
computing dependent requests.
In hierarchical PCE (H-PCE) deployments, a child PCE will be able to request both
dependent and synchronized domain-diverse end-to-end paths from its
parent PCE.Domain Inclusion or Exclusion
A domain sequence is an ordered sequence of domains traversed to
reach the destination domain. A domain sequence may be supplied
during path computation to guide the PCEs or are derived via the use of
hierarchical PCE (H-PCE).
During multi-domain path computation, a PCC may request
specific domains to be included or excluded in the domain sequence
using the Include Route Object (IRO) and Exclude Route
Object (XRO) . The use of Autonomous Number (AS) as an
abstract node representing a domain is defined in .
specifies new subobjects to include or exclude domains
such as an IGP area or a 4-byte AS number.
An operator may also need to avoid a path that uses specified nodes
for administrative reasons. If a specific connectivity service is
required to have a 1+1 protection capability, two separate disjoint
paths must be established.
A mechanism known as
Shared Risk Link Group (SRLG) information may be used to ensure
path diversity.Applicability of the PCE to Inter-area Traffic Engineering
As networks increase in size and complexity, it may be required to
introduce scaling methods to reduce the amount of information
flooded within the network and make the network more manageable. An
IGP hierarchy is designed to improve IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. This restricts visibility of
the area to routers in a single area. If a router needs to compute
the route to a destination located in another area, a method would
be required to compute a path across area boundaries.
In order to support multiple vendors in a network in cases where
data or control-plane technologies cannot interoperate, it is useful
to divide the network into vendor domains. Each vendor domain is
an IGP area, and the flooding scope of the topology (as well as any
other relevant information) is limited to the area boundaries.
Per-domain path computation exists to provide a method of
inter-area path computation. The per-domain solution is based on
loose hop routing with an Explicit Route Object (ERO) expansion on
each Area Border Router (ABR). This allows an LSP to be established
using a constrained path. However, at least two issues exist:
This method does not guarantee an optimal constrained path.
The method may require several crankback signaling messages, as per
, increasing signaling traffic and delaying the LSP setup.
PCE-based architecture is designed to solve inter-area
path computation problems. The issue of limited topology visibility
is resolved by introducing path computation entities that are able to
cooperate in order to establish LSPs with the source and destinations
located in different areas.Inter-area Routing
An inter-area TE-LSP is an LSP that transits through at least two
IGP areas. In a multi-area network, topology visibility remains
local to a given area for scaling and privacy purposes. A node
in one area will not be able to compute an end-to-end path across
multiple areas without the use of a PCE.Area Inclusion and Exclusion
The BRPC method of path computation provides a more optimal
method to specify inclusion or exclusion of an ABR. Using the BRPC
procedure, an end-to-end path is recursively computed in reverse from
the destination domain towards the source domain. Using this method,
an operator might decide if an area must be included or excluded from
the inter-area path computation.Strict Explicit Path and Loose Path
A strict explicit path is defined as a set of strict hops, while a
loose path is defined as a set of at least one loose hop and zero or
more strict hops. It may be useful to indicate whether a strict explicit path is required during the path computation request. An inter-area path may be strictly explicit or loose (e.g., a
list of ABRs as loose hops).
A PCC request to a PCE does allow indication of whether a strict
explicit path across specific areas () is required or
desired or whether the path request is loose.Inter-Area Diverse Path Computation
It may be necessary to compute a path that is partially or entirely
diverse from a previously computed path to avoid fate sharing of
a primary service with a corresponding backup service. There are
various levels of diversity in the context of an inter-area network:
Per-area diversity (the intra-area path segments are a link, node, or
SRLG disjoint).
Inter-area diversity (the end-to-end inter-area paths are a link,
node, or SRLG disjoint).
Note that two paths may be disjointed in the backbone area but non-disjointed in peripheral areas. Also, two paths may be node disjointed
within areas but may share ABRs, in which case path segments within
an area are node disjointed but end-to-end paths are not node disjointed.
Per-domain , BRPC , and H-PCE mechanisms
all support the capability to compute diverse paths across multi-area
topologies.Applicability of the PCE to Inter-AS Traffic Engineering
As discussed in (), it is necessary to divide the network into
smaller administrative domains, or ASes. If an LSR within an AS needs
to compute a path across an AS boundary, it must also use an inter-AS
computation technique. defines mechanisms for the
computation of inter-domain TE LSPs using network elements along the
signaling paths to compute per-domain constrained path segments.
The PCE was designed to be capable of computing MPLS and GMPLS paths
across AS boundaries. This section outlines the features of a
PCE-enabled solution for computing inter-AS paths.Inter-AS RoutingAS Inclusion and Exclusion allows the specification of AS or
ASBR inclusion or exclusion. Using this method, an operator might decide whether an AS
must be included or excluded from the inter-AS path computation.
Exclusion and/or inclusion could also be specified at any step in
the LSP path computation process by a PCE (within the BRPC
algorithm), but the best practice would be to specify them at the
edge. In opposition to the strict and loose path, AS inclusion or
exclusion doesn't impose topology disclosure as ASes and their
interconnection are public
entities.Inter-AS Bandwidth Guarantees
Many operators with multi-AS domains will have deployed the MPLS-TE
Diffserv either across their entire network or at the domain edges
on CE-PE links. In situations where strict QoS bounds are required,
admission control inside the network may also be required.
When the propagation delay can be bounded, the performance targets,
such as maximum one-way transit delay, may be guaranteed by providing
bandwidth guarantees along the Diffserv-enabled path. These
requirements are described in .
One typical example of the requirements in is to provide
bandwidth guarantees over an end-to-end path for VoIP traffic
classified as an EF (Expedited Forwarding) class in a Diffserv-enabled
network. In cases where the EF path is extended across multiple
ASes, an inter-AS bandwidth guarantee would be required.
Another case for an inter-AS bandwidth guarantee is the requirement to guarantee a certain amount of transit bandwidth across one or
multiple ASes.Inter-AS Recovery
During a path computation process, a PCC request may contain the
requirement to compute a backup LSP for protecting the primary LSP, such as
1+1 protection.
A single LSP or multiple backup LSPs may also be
used for a group of primary LSPs; this is typically known as m:n
protection.
Other inter-AS recovery mechanisms include , which adds Fast
Reroute (FRR) protection to an LSP. So, the PCE could be used to
trigger computation of backup tunnels in order to protect inter-AS
connectivity.
Inter-AS recovery clearly requires backup LSPs for service
protection, but it would also be advisable to have multiple PCEs
deployed for path computation redundancy, especially for service
restoration in the event of catastrophic network failure.Inter-AS PCE Peering Policies
Like BGP peering policies, inter-AS PCE peering policies are required for
an operator. In an inter-AS BRPC process, the PCE must
cooperate in order to compute the end-to-end LSP. Therefore, the AS path
must not only follow technical constraints, e.g., bandwidth
availability, but also the policies defined by the operator.
Typically, PCE interconnections at an AS level must follow the agreed
contract obligations, also known as peering agreements. The PCE
peering policies are the result of the contract negotiation and
govern the relation between the different PCEs.Multi-domain PCE Deployment OptionsTraffic Engineering Database and Synchronization
An optimal path computation requires knowledge of the available
network resources, including nodes and links, constraints,
link connectivity, available bandwidth, and link costs. The PCE
operates on a view of the network topology as presented by a
TED. As discussed in , the TED used by a PCE may be learned
by the relevant IGP extensions.
Thus, the PCE may operate its TED by participating
in the IGP running in the network. In an MPLS-TE network, this
would require OSPF-TE or ISIS-TE . In a GMPLS
network, it would utilize the GMPLS extensions to OSPF and IS-IS
defined in and . Inter-AS connectivity
information may be populated via and .
An alternative method to providing network topology and resource
information is offered by , which is described in the
following section.Applicability of BGP-LS to PCE
The concept of the exchange of TE information between Autonomous Systems
(ASes) is discussed in . The information exchanged in this
way could be the full TE information from the AS, an aggregation of
that information, or a representation of the potential connectivity
across the AS. Furthermore, that information could be updated
frequently (for example, for every new LSP that is set up across the
AS) or only at threshold-crossing events.
In an H-PCE deployment, the parent PCE will require the inter-domain
topology and link status between child domains. This information may
be learned by a BGP-LS speaker and provided to the parent PCE.
Furthermore, link-state performance, including delay, available
bandwidth, and utilized bandwidth, may also be provided to the parent
PCE for optimal path link selection.Pre-planning and Management-Based Solutions
Offline path computation is performed ahead of time before the LSP
setup is requested. That means that it is requested by or performed
as part of an Operation Support System (OSS) management application.
This model can be seen in .
The offline model is particularly appropriate for long-lived LSPs
(such as those present in a transport network) or for planned
responses to network failures. In these scenarios, more planning is
normally a feature of LSP provisioning.
The management system may also use a PCE and BRPC to pre-plan an AS
sequence, and the source domain PCE and per-domain path
computation to be used when the actual end-to-end path is
required. This model may also be used where the operator
wishes to retain full manual control of the placement of LSPs,
using the PCE only as a computation tool to assist the operator and
not as part of an automated network.
In environments where operators peer with each other to provide end-to-end
paths, the operator responsible for each domain must agree on the
extent to which paths must be pre-planned or manually controlled.Domain Confidentiality
This section discusses the techniques that cooperating PCEs
can use to compute inter-domain paths without each domain
disclosing sensitive internal topology information (such as
explicit nodes or links within the domain) to the other domains.
Confidentiality typically applies to inter-provider (inter-AS) PCE
communication.
Where the TE LSP crosses multiple domains (ASes or areas), the path may be
computed by multiple PCEs that cooperate together, with each local PCE
responsible for computing a segment of the path.
With each local PCE responsible for computing a segment
of the path.
In situations where ASes are administered by separate Service
Providers, it would break confidentiality rules for a PCE to supply
path segment details to a PCE responsible for another domain, thus
disclosing AS-internal or area topology information.Loose Hops
A method for preserving the confidentiality of the path segment is
for the PCE to return a path containing a loose hop in place of the
segment that must be kept confidential. The concept of loose and
strict hops for the route of a TE LSP is described in . supports the use of paths with
loose hops; whether it returns a full explicit
path with strict hops or uses loose hops is a
local policy decision at a PCE. A path computation
request may require an explicit path with strict hops or may allow
loose hops, as detailed in .Confidential Path Segments and Path-Keys defines the concept and mechanism
of a Path-Key. A Path-Key
is a token that replaces the path segment information in an explicit
route. The Path-Key allows the explicit route information to be
encoded and is contained in the Path Computation Element Communication Protocol (PCEP) () messages exchanged between the
PCE and PCC.
This Path-Key technique allows explicit route information to be used
for end-to-end path computation without disclosing internal topology
information between domains.Point to Multipoint
For inter-domain point-to-multipoint application scenarios using
MPLS-TE LSPs, the complexity of domain sequences, domain policies,
and the choice and number of domain interconnects is magnified compared to
point-to-point path computations. As the size of the network
grows, the number of leaves and branches increases, further
increasing the complexity of the overall path computation problem.
A solution for managing point-to-multipoint path computations may
be achieved using the PCE inter-domain point-to-multipoint path
computation procedure.Optical Domains
The International Telecommunication Union (ITU) defines the ASON
architecture in . defines the routing architecture
for ASON and introduces a hierarchical architecture. In this
architecture, the Routing Areas (RAs) have a hierarchical
relationship between different routing levels, which means a parent
(or higher level) RA can contain multiple child RAs. The
interconnectivity of the lower RAs is visible to the higher-level RA.
In the ASON framework, a path computation request is termed a route
query. This query is executed before signaling is used to establish
an LSP, which is termed a Switched Connection (SC) or a Soft Permanent
Connection (SPC).
defines the requirements and
architecture for the functions performed by Routing Controllers (RC)
during the operation of remote route queries. An RC is synonymous
with a PCE.
In the ASON routing environment, an RC responsible for an RA may
communicate with its neighbor RC to request the computation of an
end-to-end path across several RAs. The path computation components
and sequences are defined as follows:
Remote route query. An operation where a Routing Controller
communicates with another Routing Controller, which does not have
the same set of layer resources, in order to compute a routing
path in a collaborative manner.
Route query requester. The connection controller or RC that sends a
route query message to a Routing Controller that requests one or
more routing paths satisfying a set of routing constraints.
Route query responder. An RC that performs the path computation
upon reception of a route query message from a Routing Controller or
connection controller, and sends a response back at the end of the
computation.
When computing an end-to-end connection, the route may be computed by
a single RC or multiple RCs in a collaborative manner, and the two
scenarios can be considered a centralized remote route query model
and a distributed remote route query model. RCs in an ASON environment
can also use the hierarchical PCE
model to fully match the
ASON hierarchical routing model.Abstraction and Control of TE Networks (ACTN)
Where a single operator operates multiple TE domains (including
optical environments), an Abstraction and Control of TE Networks
(ACTN) framework may be used to create an abstracted
(virtualized network) view of underlay-interconnected domains. This
underlay connectivity is then exposed to higher-layer control
entities and applications.
ACTN describes the method and procedure for coordinating the
underlay per-domain Provisioning Network Controllers (PNCs), which may
be PCEs, via a hierarchical model to facilitate setup of
end-to-end connections across interconnected TE domains.Policy
Policy is important in the deployment of new services and the
operation of the network. provides a framework for PCE-based policy-enabled path computation. This framework is based on
the Policy Core Information Model (PCIM) as defined in and
further extended by .
When using a PCE to compute inter-domain paths, policy may be
invoked by specifying the following:
Each PCC must select which computations it will request from a PCE.
Each PCC must select which PCEs it will use.
Each PCE must determine which PCCs are allowed to use its services
and for what computations.
The PCE must determine how to collect the information in its TED,
whom to trust for that information, and how to refresh/update the
information.
Each PCE must determine which objective functions and algorithms to apply.
Manageability Considerations
General PCE management considerations are discussed in .
In the case of multi-domains within a single service provider
network, the management responsibility for each PCE would most
likely be handled by the same service provider. In the case of
multiple ASes within different service provider networks, it will
likely be necessary for each PCE to be configured and managed
separately by each participating service provider, with policy
being implemented based on a previously agreed set of principles.Control of Function and Policy
As per , PCEP implementation allows the user to configure
a number of PCEP session parameters. These are detailed in .
In H-PCE deployments, the administrative entity responsible for the
management of the parent PCEs for multi-areas would typically be a
single service provider. In multiple ASes (managed by different
service providers), it may be necessary for a third party to manage
the parent PCE.Information and Data Models
A PCEP MIB module is defined in ,
which describes managed
objects for modeling PCEP communication, including:
PCEP client configuration and status.
PCEP peer configuration and information.
PCEP session configuration and information.
Notifications to indicate PCEP session changes.
A YANG module for PCEP has also been proposed .
An H-PCE MIB module or YANG data model will be required to
report parent PCE and child PCE information, including:
Parent PCE configuration and status.
Child PCE configuration and information.
Notifications to indicate session changes between parent PCEs and
child PCEs.
Notification of parent PCE TED updates and changes.
Liveness Detection and Monitoring
PCEP includes a keepalive mechanism to check the liveliness of a PCEP
peer and a notification procedure allowing a PCE to advertise its
overloaded state to a PCC. In a multi-domain environment,
provides the procedures necessary to monitor the liveliness and
performance of a given PCE chain.Verifying Correct Operation
It is important to verify the correct operation of PCEP.
specifies the monitoring of key parameters. These parameters are
detailed in .Impact on Network Operation states that in order to avoid any unacceptable impact on
network operations, a PCEP implementation should allow a limit to be
placed on the number of sessions that can be set up on a PCEP
speaker and that it may also be practical to place a limit on the rate
of messages sent by a PCC and received by the PCE.Security Considerations
PCEP security considerations are discussed in and .
Potential vulnerabilities include spoofing, snooping, falsification,
and using PCEP as a mechanism for denial of service attacks.
As PCEP operates over TCP, it may make use of TCP security
encryption mechanisms, such as Transport Layer Security (TLS) and TCP
Authentication Option (TCP-AO). Usage of these security mechanisms
for PCEP is described in , and recommendations and best
current practices are described in .Multi-domain Security
Any multi-domain operation necessarily involves the exchange of
information across domain boundaries. This represents a
significant security and confidentiality risk.
It is expected that PCEP is used between PCCs and PCEs that belong to the
same administrative authority while also using one of the aforementioned
encryption mechanisms.
Furthermore, PCEP allows
individual PCEs to maintain the confidentiality of their domain path
information using path-keys.IANA Considerations
This document has no IANA actions.ReferencesNormative ReferencesRSVP-TE: Extensions to RSVP for LSP TunnelsThis document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ExtensionsThis document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) RequirementsThis document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. This memo provides information for the Internet community.A Path Computation Element (PCE)-Based ArchitectureConstraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.A Framework for Inter-Domain Multiprotocol Label Switching Traffic EngineeringThis document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). This memo provides information for the Internet community.A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. [STANDARDS-TRACK]Path Computation Element (PCE) Communication Protocol (PCEP)This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched PathsThe ability to compute shortest constrained Traffic Engineering Label Switched Paths (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 IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based MechanismMultiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLSComputing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document is not an Internet Standards Track specification; it is published for informational purposes.Informative ReferencesPolicy Core Information Model -- Version 1 SpecificationThis document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS-TRACK]Policy Core Information Model (PCIM) ExtensionsThis document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS-TRACK]Traffic Engineering (TE) Extensions to OSPF Version 2This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.Fast Reroute Extensions to RSVP-TE for LSP TunnelsThis document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]Crankback Signaling Extensions for MPLS and GMPLS RSVP-TEIn a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]OSPF Protocol Extensions for Path Computation Element (PCE) DiscoveryThere are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]IS-IS Protocol Extensions for Path Computation Element (PCE) DiscoveryThere are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]IS-IS Extensions for Traffic EngineeringThis document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic EngineeringThis document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation.No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic EngineeringThis document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]Policy-Enabled Path Computation FrameworkThe Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. This memo provides information for the Internet community.Extensions to the Path Computation Element Communication Protocol (PCEP) for Route ExclusionsThe Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]A Set of Monitoring Tools for Path Computation Element (PCE)-Based ArchitectureA Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK]Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path ComputationsA Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not an Internet Standards Track specification; it is published for informational purposes.Architecture for the automatically switched optical networkITU-TArchitecture and requirements for routing in the automatically switched optical networksITU-TASON routing architecture and requirements for remote route queryITU-TAnalysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design GuideThis document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched PathsThe ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) ModuleThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGPIn a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)The ability to compute shortest constrained Traffic Engineering Label Switched Paths (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 System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers.PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.This document updates RFC 5440 in regards to the PCEP initialization phase procedures.Framework for Abstraction and Control of TE Networks (ACTN)Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.A YANG Data Model for Path Computation Element Communications Protocol (PCEP)This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration and state data.Work in ProgressAcknowledgements
The author would like to thank for his
review and and for their comments.ContributorsHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comHuawei Technologies125 Nagog Technology ParkActonMA01719United States of Americaqzhao@huawei.comFrance Telecom2, avenue Pierre-MarzinLannion Cedex22307Francejulien.meuric@orange.comFrance Telecom2, avenue Pierre-MarzinLannion Cedex22307Franceolivier.dugeon@orange.comMetaswitch Networks100 Church StreetEnfieldEN2 6BQUnited Kingdomjonathan.hardwick@metaswitch.comTelefonica I+DEmilio Vargas 6MadridSpainoscar.gonzalezdedios@telefonica.comAuthors' AddressesOld Dog Consultingdaniel@olddog.co.uk华为技术有限公司松山湖华为溪流背坡村H1东莞广东523808中国zhenghaomian@huawei.com