draft-ietf-pce-inter-area-as-applicability-06.txt   draft-ietf-pce-inter-area-as-applicability-07.txt 
PCE Working Group D. King PCE Working Group D. King
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Intended status: Informational J. Meuric Intended status: Informational H. Zheng
Expires: January 21, 2017 O. Dugeon Expires: June 14, 2019 Huawei Technologies
France Telecom December 13, 2018
Q. Zhao
D. Dhody
Huawei Technologies
Oscar Gonzalez de Dios
Telefonica I+D
July 20, 2016
Applicability of the Path Computation Element to Inter-Area and Applicability of the Path Computation Element to Inter-Area and
Inter-AS MPLS and GMPLS Traffic Engineering Inter-AS MPLS and GMPLS Traffic Engineering
draft-ietf-pce-inter-area-as-applicability-06 draft-ietf-pce-inter-area-as-applicability-07
Abstract Abstract
The Path Computation Element (PCE) may be used for computing services The Path Computation Element (PCE) may be used for computing services
that traverse multi-area and multi-AS Multiprotocol Label Switching that traverse multi-area and multi-AS Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.
This document examines the applicability of the PCE architecture, This document examines the applicability of the PCE architecture,
protocols, and protocol extensions for computing multi-area and protocols, and protocol extensions for computing multi-area and
multi-AS paths in MPLS and GMPLS networks. multi-AS paths in MPLS and GMPLS networks.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on June 14, 2019.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction.................................................3
1.1. Domains.................................................4 1.1. Domains.................................................4
1.2. Path Computation........................................4 1.2. Path Computation........................................4
1.2.1 PCE-based Path Computation Procedure.................5 1.2.1 PCE-based Path Computation Procedure.................5
1.3. Traffic Engineering Aggregation and Abstraction.........5 1.3. Traffic Engineering Aggregation and Abstraction.........6
1.4. Traffic Engineered Label Switched Paths................. 1.4. Traffic Engineered Label Switched Paths.................6
1.5. Inter-area and Inter-AS Capable PCE Discovery...........6 1.5. Inter-area and Inter-AS Capable PCE Discovery...........6
1.6. Objective Functions.....................................6 1.6. Objective Functions.....................................6
2. Terminology..................................................7 2. Terminology..................................................7
3. Issues and Considerations....................................7 3. Issues and Considerations....................................7
3.1 Multi-homing.............................................7 3.1 Multi-homing.............................................7
3.2 Domain Confidentiality ..................................8 3.2 Domain Confidentiality ..................................4
3.3 Destination Location.....................................8 3.3 Destination Location.....................................4
4. Domain Topologies............................................8 4. Domain Topologies............................................4
4.1 Selecting Domain Paths...................................8 4.1 Selecting Domain Paths...................................4
4.2 Multi-Homed Domains......................................9 4.2 Domain Sizes.............................................9
4.3 Domain Topologies........................................9 4.3 Domain Diversity.........................................9
4.4 Domain Diversity.........................................9 4.4 Synchronized Path Computations...........................9
4.5 Synchronized Path Computations...........................9 4.5 Domain Inclusion or Exclusion............................9
4.6 Domain Inclusion or Exclusion............................10 5. Applicability of the PCE to Inter-area Traffic Engineering...10
5. Applicability of the PCE to Inter-area Traffic Engineering...11
5.1. Inter-area Routing......................................11 5.1. Inter-area Routing......................................11
5.1.1. Area Inclusion and Exclusion..........................11 5.1.1. Area Inclusion and Exclusion..........................11
5.1.2. Strict Explicit Path and Loose Path...................12 5.1.2. Strict Explicit Path and Loose Path...................11
5.1.3. Inter-Area Diverse Path Computation...................12 5.1.3. Inter-Area Diverse Path Computation...................11
5.2. Control and Recording of Area Crossing..................12
6. Applicability of the PCE to Inter-AS Traffic Engineering.....12 6. Applicability of the PCE to Inter-AS Traffic Engineering.....12
6.1. Inter-AS Routing........................................13 6.1. Inter-AS Routing........................................12
6.1.1. Strict Explicit Path and Loose Path...................13 6.1.1. AS Inclusion and Exclusion............................12
6.1.2. AS Inclusion and Exclusion............................13 6.2. Inter-AS Bandwidth Guarantees...........................12
6.2. Inter-AS Bandwidth Guarantees...........................13 6.3. Inter-AS Recovery.......................................13
6.3. Inter-AS Recovery.......................................14 6.4. Inter-AS PCE Peering Policies...........................13
6.4. Inter-AS PCE Peering Policies...........................14 7. Multi-Domain PCE Deployment..................................13
7. Multi-Domain PCE Deployment..................................14 7.1 Traffic Engineering Database.............................13
7.1 Traffic Engineering Database.............................15 7.1.1. Applicability of BGP-LS to PCE........................14
7.1.1 Provisioning Techniques................................16 7.2 Pre-Planning and Management-Based Solutions..............14
7.3 Pre-Planning and Management-Based Solutions..............16 8. Domain Confidentiality.......................................15
7.4 Per-Domain Computation...................................16 8.1 Loose Hops...............................................15
7.5 Cooperative PCEs.........................................16 8.2 Confidential Path Segments and Path Keys.................15
7.6 Hierarchical PCEs ......................................17 9. Point-to-Multipoint..........................................16
8. Domain Confidentiality.......................................17 10. Optical Domains.............................................16
8.1 Loose Hops...............................................17 10.1 Abstraction and Control of TE Networks (ACTN)...........17
8.2 Confidential Path Segments and Path Keys.................17 11. Policy......................................................17
9. Point-to-Multipoint..........................................18 12. Manageability Considerations................................18
10. Optical Domains.............................................18 12.1 Control of Function and Policy...........................18
10.1. PCE applied to the ASON Architecture....................18 12.2 Information and Data Models..............................19
11. Policy......................................................19 12.3 Liveness Detection and Monitoring........................19
12. TED Topology and Synchronization............................19 12.4 Verifying Correct Operation..............................19
12.1. Applicability of BGP-LS to PCE..........................20 12.5 Impact on Network Operation..............................19
13. Manageability Considerations................................20 13. Security Considerations.....................................19
13.1 Control of Function and Policy...........................20 14. IANA Considerations.........................................19
13.2 Information and Data Models..............................21 15. Acknowledgements............................................19
13.3 Liveness Detection and Monitoring........................21 16. References..................................................20
13.4 Verifying Correct Operation..............................22 16.1. Normative References....................................20
13.5 Impact on Network Operation..............................22 16.2. Informative References..................................20
14. Security Considerations.....................................22 17. Contributors................................................23
15. IANA Considerations.........................................22 18. Author's Addresses..........................................24
16. Acknowledgements............................................22
17. References..................................................22
17.1. Normative References....................................22
17.2. Informative References..................................22
18. Author's Addresses..........................................26
1. Introduction 1. Introduction
Computing paths across large multi-domain environments may Computing paths across large multi-domain environments may
require special computational components and cooperation between require special computational components and cooperation between
entities in different domains capable of complex path computation. entities in different domains capable of complex path computation. A
number of issues exist for routing in multi-domain networks, these
include:
o Often there is a lack of full topology and TE information across
domains;
o No single node has the full visibility to determine an optimal or
even feasible end-to-end path across domains;
o How to evaluate and select the exit point and next domain boundary
from a domain?
o How might the ingress node determine which domains should be used
for the end-to-end path?
Often information exchange across multiple domains is 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) [RFC4655] provides an architecture The Path Computation Element (PCE) [RFC4655] provides an architecture
and a set of functional components to address this problem space. and a set of functional components to address the problem space, and
issues highlighted above.
A PCE may be used to compute end-to-end paths across multi-domain A PCE may be used to compute end-to-end paths across multi-domain
environments using a per-domain path computation technique [RFC5152]. environments using a per-domain path computation technique [RFC5152].
The so called backward recursive path computation (BRPC) mechanism The so called backward recursive path computation (BRPC) mechanism
[RFC5441] defines a PCE-based path computation procedure to compute [RFC5441] defines a PCE-based path computation procedure to compute
inter-domain constrained Multiprotocol Label Switching (MPLS) and inter-domain constrained Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. However, Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. However,
both per-domain and BRPC techniques assume that the sequence of both per-domain and BRPC techniques assume that the sequence of
domains to be crossed from source to destination is known, either domains to be crossed from source to destination is known, either
fixed by the network operator or obtained by other means. fixed by the network operator or obtained by other means.
In more advanced deployments (including multi-area and multi- In more advanced deployments (including multi-area and multi-
Autonomous System (multi-AS) environments) the sequence of domains Autonomous System (multi-AS) environments) the sequence of domains
may not be known in advance and the choice of domains in the end-to- 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 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 optimal end-to-end path. In this case the use of the Hierarchical PCE
[RFC6805] architecture and mechanisms may be used to discover the [RFC6805] architecture and mechanisms may be used to discover the
intra-area path and select the optimal end-to-end domain sequence. intra-area path and select the optimal end-to-end domain sequence.
This document describes the processes and procedures available when This document describes the processes and procedures available when
using the PCE architecture, protocols and protocol extensions for using the PCE architecture and protocols, for computing inter-area
computing inter-area and inter-AS MPLS and GMPLS Traffic TE paths. and inter-AS MPLS and GMPLS Traffic Engineered paths.
This document does not discuss stateful PCE, active PCE, or remotely This document scope does not include discussion on stateful PCE,
initiated PCE, deployment scenarios. active PCE, remotely initiated PCE, or PCE as a central controller
(PCECC) deployment scenarios.
1.1 Domains 1.1 Domains
A domain can be defined as a separate administrative, geographic, or A domain can be defined as a separate administrative, geographic, or
switching environment within the network. A domain may be further switching environment within the network. A domain may be further
defined as a zone of routing or computational ability. Under these defined as a zone of routing or computational ability. Under these
definitions a domain might be categorized as an Antonymous System definitions a domain might be categorized as an Antonymous System
(AS) or an Interior Gateway Protocol (IGP) area (as per [RFC4726] (AS) or an Interior Gateway Protocol (IGP) area (as per [RFC4726]
and [RFC4655]). and [RFC4655]).
For the purposes of this document, a domain is considered to be a 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 collection of network elements within an area or AS that has a
sphere of address management or path computational responsibility. common sphere of address management or path computational
Wholly or partially overlapping domains are not within the scope of responsibility. Wholly or partially overlapping domains are not
this document. within the scope of this document.
In the context of GMPLS, a particularly important example of a domain In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork is the Automatically Switched Optical Network (ASON) subnetwork
[G-8080]. In this case, computation of an end-to-end path requires [G-8080]. In this case, computation of an end-to-end path requires
the selection of nodes and links within a parent domain where some the selection of nodes and links within a parent domain where some
nodes may, in fact, be subnetworks. Furthermore, a domain might be an nodes may, in fact, be subnetworks. Furthermore, a domain might be an
ASON routing area [G-7715]. A PCE may perform the path computation ASON routing area [G-7715]. A PCE may perform the path computation
function of an ASON routing controller as described in [G-7715-2]. function of an ASON routing controller as described in [G-7715-2].
It is assumed that the PCE architecture is not applied to a large It is assumed that the PCE architecture is not applied to a large
group of domains, such as Internet. group of domains, such as the Internet.
1.2 Path Computation 1.2 Path Computation
For the purpose of this document, it is assumed that the
For the purpose of this document it is assumed that the
path computation is the sole responsibility of the PCE as per the path computation is the sole responsibility of the PCE as per the
architecture defined in [RFC4655]. When a path is required the Path architecture defined in [RFC4655]. When a path has required the Path
Computation Client (PCC) will send a request to the PCE. The PCE will Computation Client (PCC) will send a request to the PCE. The PCE
apply the required constraints and compute a path and return a will apply the required constraints and compute a path and return a
response to the PCC. In the context of this document it maybe response to the PCC. In the context of this document it may be
necessary for the PCE to co-operate with other PCEs in adjacent necessary for the PCE to co-operate with other PCEs in adjacent
domains (as per BRPC [RFC5441]) or cooperate with a Parent PCE domains (as per BRPC [RFC5441]) or cooperate with a Parent PCE
(as per [RFC6805]). (as per [RFC6805]).
It is entirely feasible that an operator could compute a path across It is entirely feasible that an operator could compute a path across
multiple domains without the use of a PCE if the relevant domain multiple domains without the use of a PCE if the relevant domain
information is available to the network planner or network management information is available to the network planner or network management
platform. The definition of what relevant information is required to platform. The definition of what relevant information is required to
perform this network planning operation and how that information is perform this network planning operation and how that information is
discovered and applied is outside the scope of this document. discovered and applied is outside the scope of this document.
skipping to change at page 5, line 30 skipping to change at page 5, line 35
be a single PCE per domain, or single PCE responsible for all be a single PCE per domain, or single PCE responsible for all
domains. A PCE may or may not reside on the same node as the 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 requesting PCC. A path may be computed by either a single PCE node
or a set of distributed PCE nodes that collaborate during path or a set of distributed PCE nodes that collaborate during path
computation. computation.
[RFC4655] defines that a PCC should send a path computation request [RFC4655] defines that a PCC should send a path computation request
to a particular PCE, using [RFC5440] (PCC-to-PCE communication). to a particular PCE, using [RFC5440] (PCC-to-PCE communication).
This negates the need to broadcast a request to all the PCEs. Each This negates the need to broadcast a request to all the PCEs. Each
PCC can maintain information about the computation capabilities PCC can maintain information about the computation capabilities
of the PCEs it is aware of. The PCC-PCE capability awareness can be of the PCEs, it is aware of. The PCC-PCE capability awareness can be
configured using static configurations or by automatic and dynamic configured using static configurations or by automatic and dynamic
PCE discovery procedures. PCE discovery procedures.
Once a path computation request is received, the PCC will send a If a network path is required, the PCC will send a path computation
request to the PCE. A PCE may compute the end-to-end path 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 if it is aware of the topology and TE information required to
compute the entire path. If the PCE is unable to compute the compute the entire path. If the PCE is unable to compute the
entire path, the PCE architecture provides co-operative PCE entire path, the PCE architecture provides co-operative PCE
mechanisms for the resolution of path computation requests when an mechanisms for the resolution of path computation requests when an
individual PCE does not have sufficient TE visibility. individual PCE does not have sufficient TE visibility.
End-to-end path segments may be kept confidential through the End-to-end path segments may be kept confidential through the
application of path keys, to protect partial or full path application of path keys, to protect partial or full path
information. A path key that is a token that replaces a path segment information. A path key that is a token that replaces a path segment
in an explicit route. The path key mechanism is described in in an explicit route. The path key mechanism is described in
skipping to change at page 6, line 26 skipping to change at page 6, line 33
This document highlights the PCE techniques and mechanisms that exist This document highlights the PCE techniques and mechanisms that exist
for establishing TE packet and optical LSPs across multiple areas for establishing TE packet and optical LSPs across multiple areas
(inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and (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 within the remainder of this document, we consider all LSPs to be
constraint-based and traffic engineered. constraint-based and traffic engineered.
Three signaling options are defined for setting up an inter-area or Three signaling options are defined for setting up an inter-area or
inter-AS LSP [RFC4726]: inter-AS LSP [RFC4726]:
- Contiguous LSP o Contiguous LSP
- Stitched LSP o Stitched LSP
- Nested LSP o Nested LSP
All three signaling methods are applicable to the architectures and All three signaling methods are applicable to the architectures and
procedures discussed in this document. procedures discussed in this document.
1.5 Inter-area and Inter-AS Capable PCE Discovery 1.5 Inter-area and Inter-AS Capable PCE Discovery
When using a PCE-based approach for inter-area and inter-AS path 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 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 related to inter-AS capable PCEs located in other ASes. The PCE
discovery mechanism defined in [RFC5088] and [RFC5089] allow discovery mechanism defined in [RFC5088] and [RFC5089] facilitates
the discovery of PCEs and disclosure of information related to the discovery of PCEs, and disclosure of information related to
inter-area and inter-AS capable PCEs. inter-area and inter-AS capable PCEs.
1.6 Objective Functions 1.6 Objective Functions
An Objective Function (OF) [RFC5541], or set of OFs, specify the An Objective Function (OF) [RFC5541], or set of OFs, specifies the
intentions of the path computation and so define the "optimality" intentions of the path computation and so defines the "optimality",
in the context of that computation request. in the context of the computation request.
An OF specifies the desired outcome of a computation. An OF does not An OF specifies the desired outcome of a computation. An OF does not
describe or specify the algorithm to use, and an implementation may describe or specify the algorithm to use. Also, an implementation
apply any algorithm or set of algorithms to achieve the result may apply any algorithm, or set of algorithms, to achieve the result
indicated by the OF. [RFC5541] provides the following OFs when indicated by the OF. A number of general OFs are specified in
computing inter-domain paths: [RFC5541].
o Minimum Cost Path (MCP);
o Minimum Load Path (MLP);
o Maximum residual Bandwidth Path (MBP);
o Minimize aggregate Bandwidth Consumption (MBC);
o Minimize the Load of the most loaded Link (MLL);
o Minimize the Cumulative Cost of a set of paths (MCC).
OFs can be included in the PCE computation requests to satisfy the Various OFs may be included in the PCE computation request to
policies encoded or configured at the PCC, and a PCE may be satisfy the policies encoded or configured at the PCC, and a PCE
subject to policy in determining whether it meets the OFs included may be subject to policy in determining whether it meets the OFs
in the computation request, or applies its own OFs. included in the computation request or applies its own OFs.
During inter-domain path computation, the selection of a domain During inter-domain path computation, the selection of a domain
sequence, the computation of each (per-domain) path fragment, and sequence, the computation of each (per-domain) path fragment, and
the determination of the end-to-end path may each be subject to the determination of the end-to-end path may each be subject to
different OFs and policy. different OFs and policy.
2. Terminology 2. Terminology
This document also uses the terminology defined in [RFC4655] and This document also uses the terminology defined in [RFC4655] and
[RFC5440]. Additional terminology is defined below: [RFC5440]. Additional terminology is defined below:
skipping to change at page 7, line 49 skipping to change at page 8, line 4
SRLG: Shared Risk Link Group. SRLG: Shared Risk Link Group.
TED: Traffic Engineering Database, which contains the topology and TED: Traffic Engineering Database, which contains the topology and
resource information of the domain. The TED may be fed by Interior resource information of the domain. The TED may be fed by Interior
Gateway Protocol (IGP) extensions or potentially by other means. Gateway Protocol (IGP) extensions or potentially by other means.
3. Issues and Considerations 3. Issues and Considerations
3.1 Multi-homing 3.1 Multi-homing
Networks constructed from multi-areas or multi-AS environments Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path may have multiple interconnect points (multi-homing). End-to-end path
computations may need to use different interconnect points to avoid computations may need to use different interconnect points to avoid
single point failures disrupting primary and backup services. a single point failure disrupting both primary and backup services.
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.
3.2 Domain Confidentiality 3.2 Domain Confidentiality
Where the end-to-end path crosses multiple domains, it may be Where the end-to-end path crosses multiple domains, it may be
possible that each domain (AS or area) are administered by separate possible that each domain (AS or area) are administered by separate
Service Providers, it would break confidentiality rules for a PCE Service Providers, it would break confidentiality rules for a PCE
to supply a path segment to a PCE in another domain, thus disclosing to supply a path segment to a PCE in another domain, thus disclosing
AS-internal topology information. AS-internal topology information.
If confidentiality is required between domains (ASes and areas) If confidentiality is required between domains (ASes and areas)
belonging to different Service Providers. Then cooperating PCEs belonging to different Service Providers, then cooperating PCEs
cannot exchange path segments or else the receiving PCE or PCC will cannot exchange path segments or else the receiving PCE or PCC will
be able to see the individual hops through another domain. be able to see the individual hops through another domain.
3.3 Destination Location 3.3 Destination Location
The PCC asking for an inter-domain path computation is typically The PCC asking for an inter-domain path computation is typically
aware of the identity of the destination node. Additionally, if the aware of the identity of the destination node. If the PCC is aware
PCC is aware of the destination domain, it can supply this of the destination domain, it may supply the destination domain
information as part of the path computation request. However, information as part of the path computation request. However, if the
if the PCC does not know the egress domain this information must PCC does not know the destination domain this information must be
be determined by another method. determined by another method.
4. Domain Topologies 4. Domain Topologies
Constraint-based inter-domain path computation is a fundamental Constraint-based inter-domain path computation is a fundamental
requirement for operating traffic engineered MPLS [RFC3209] and requirement for operating traffic engineered MPLS [RFC3209] and
GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain) GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain)
environments. Path computation across multi-domain networks is environments. Path computation across multi-domain networks is
complex and requires computational co-operational entities like the complex and requires computational co-operational entities like the
PCE. PCE.
4.1 Selecting Domain Paths 4.1 Selecting Domain Paths
Where the sequence of domains is known a priori, various techniques Where the sequence of domains is known a priori, various techniques
can be employed to derive an optimal multi-domain path. If the can be employed to derive an optimal multi-domain path. If the
domains are simply-connected, or if the preferred points of domains are connected to a simple path with no branches and single
interconnection are also known, the Per-Domain Path Computation links between all domains, or if the preferred points of
[RFC5152] technique can be used. Where there are multiple connections interconnection is also known, the Per-Domain Path Computation
[RFC5152] technique may be used. Where there are multiple connections
between domains and there is no preference for the choice of points between domains and there is no preference for the choice of points
of interconnection, BRPC [RFC5441] can be used to derive an optimal of interconnection, BRPC [RFC5441] can be used to derive an optimal
path. path.
When the sequence of domains is not known in advance, the optimum When the sequence of domains is not known in advance, or the
end-to-end path can be derived through the use of a hierarchical end-to-end path will have to navigate a mesh of small domains
relationship between domains [RFC6805]. (especially typical in optical networks), the optimum path may be
derived through the application of a Hierarchical PCE [RFC6805].
4.2 Multi-Homed Domains
Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path
computations may need to use different interconnect points to avoid
single point failures disrupting primary and backup services.
4.3 Domain Topologies 4.2 Domain Sizes
Very frequently network domains are composed by dozens or hundreds of Very frequently network domains are composed of dozens or hundreds of
network elements. These network elements are usually interconnected network elements. These network elements are usually interconnected
between them in a partial-mesh fashion, to provide survivability in a partial-mesh fashion, to provide survivability against dual
against dual failures, and to benefit from the traffic engineering failures, and to benefit from the traffic engineering capabilities
capabilities from MPLS and GMPLS protocols. A typical node degree from MPLS and GMPLS protocols. The node degree (the number of
ranges from 3 to 10 (4-5 is quite common), being the node degree the neighbors per node) typically ranges from 3 to 10 (4-5 is quite
number of neighbors per node. common).
Networks are sometimes divided into domains. Some reasons for it
range from manageability to separation into vendor-specific domains.
The size of the domain will be usually limited by control plane, but
it can also be stated by arbitrary design constraints.
4.4 Domain Diversity 4.3 Domain Diversity
Whenever an specific connectivity service is required to have 1+1 Domain and path diversity may also be required when computing
protection feature, two completely disjoint paths must be established end-to-end paths. Domain diversity should facilitate the selection
in an end to end fashion. In a multi-domain environment, this can be of paths that share ingress and egress domains, but do not share
accomplished either by selecting domain diversity, or by ensuring transit domains. Therefore, there must be a method allowing the
diverse connection within a domain. The domain diversity ensures inclusion or exclusion of specific domains when computing end-to-end
diversity in the transit domain, the diverse path should be computed paths.
within the ingress and egress domain. In order to compute the path
diversity, it could be helpful to also have SRLG information in the
domains, to ensure SRLG diversity.
4.5 Synchronized Path Computations 4.4 Synchronized Path Computations
In some scenarios, it would be beneficial for the operator to rely on In some scenarios, it would be beneficial for the operator to rely on
the capability of the PCE to perform synchronized path computation. the capability of the PCE to perform synchronized path computation.
Synchronized path computations, known as Synchronization VECtors Synchronized path computations, known as Synchronization VECtors
(SVECs) are used for dependent path computations. SVECs are (SVECs) are used for dependent path computations. SVECs are
defined in [RFC5440] and [RFC6007] provides an overview for the defined in [RFC5440] and [RFC6007] provides an overview for the
use of the PCE SVEC list for synchronized path computations when use of the PCE SVEC list for synchronized path computations when
computing dependent requests. computing dependent requests.
In a H-PCE deployment a child PCE will be able to request both In H-PCE deployments, a child PCE will be able to request both
dependent and synchronized domain diverse end to end paths from its dependent and synchronized domain diverse end to end paths from its
parent PCE. parent PCE.
A non-comprehensive list of synchronized path computations include 4.5 Domain Inclusion or Exclusion
the following examples:
o Route diversity: computation of two disjoint paths from a source to
a destination (as drafted in the previous section).
o Synchronous restoration: joint computation of a set of alternative
paths for a set of affected LSPs as a consequence of a failure
event. Note that in this case, the requests will potentially
involve different source-destination pairs. In this scenario, the
different path computation requests may arrive at different time
stamps.
o Batch provisioning: It is common that the operator sends a set of
LSPs requests together, e.g in a daily of weekly basis, mainly in
case of long lived LSPs. In order to optimize the resource usage,
a synchronized path computation is needed.
o Network optimization: After some time of operation, the
distribution of the established LSP paths results in a non optimal
use of resources. Also, inter-domain policies/agreements may have
been changed. In such cases, a full (or partial) network planning
action regarding the inter-domain connections will be triggered.
This process is also known as a Global Concurrent Optimization
(GCO) [RFC5557].
4.6 Domain Inclusion or Exclusion
A domain sequence is an ordered sequence of domains traversed to A domain sequence is an ordered sequence of domains traversed to
reach the destination domain, a domain sequence may be supplied reach the destination domain. A domain sequence may be supplied
during path computation to guide the PCEs or derived via use of during path computation to guide the PCEs or derived via the use of
Hierarchical PCE (H-PCE). Hierarchical PCE (H-PCE).
During multi-domain path computation, a PCC may request During multi-domain path computation, a PCC may request
specific domains to be included or excluded in the domain sequence specific domains to be included or excluded in the domain sequence
using the Include Route Object (IRO) [RFC5440] and Exclude Route using the Include Route Object (IRO) [RFC5440] and Exclude Route
Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an
abstract node representing a domain is defined in [RFC3209], abstract node representing a domain is defined in [RFC3209].
[RFC7897] specifies new sub-objects to include or exclude domains [RFC7897] specifies new sub-objects to include or exclude domains
such as an IGP area or a 4-Byte AS number. 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, or if a specific connectivity
service required to have a 1+1 protection capability, two
completely disjoint paths must be established, Shared Risk Link
Group (SRLG) information may be provided to ensure path diversity.
5. Applicability of the PCE to Inter-area Traffic Engineering 5. Applicability of the PCE to Inter-area Traffic Engineering
As networks increase in size and complexity it may be required to As networks increase in size and complexity, it may be required to
introduce scaling methods to reduce the amount information flooded introduce scaling methods to reduce the amount of information
within the network and make the network more manageable. An IGP flooded within the network and make the network more manageable. An
hierarchy is designed to improve IGP scalability by dividing the IGP hierarchy is designed to improve IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. This restricts visibility of information to within area boundaries. This restricts visibility of
the area to routers in a single area. If a router needs to compute a the area to routers in a single area. If a router needs to compute
route to destination located in another area a method is required to the route to a destination located in another area, a method would
compute a path across area boundaries. be required to compute a path across area boundaries.
In order to support multiple vendors in a network, in cases where In order to support multiple vendors in a network, in cases where
data and/or control plane technologies cannot interoperate, it is data or control plane technologies cannot interoperate, it is useful
useful to divide the network in vendor domains. Each vendor domain is 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 an IGP area, and the flooding scope of the topology (as well as any
other relevant information) is limited to the area boundaries. other relevant information) is limited to the area boundaries.
Per-domain path computation [RFC5152] exists to provide a method of Per-domain path computation [RFC5152] exists to provide a method of
inter-area path computation. The per-domain solution is based on inter-area path computation. The per-domain solution is based on
loose hop routing with an Explicit Route Object (ERO) expansion on loose hop routing with an Explicit Route Object (ERO) expansion on
each Area Border Router (ABR). This allows an LSP to be established each Area Border Router (ABR). This allows an LSP to be established
using a constrained path, however at least two issues exist: using a constrained path, however at least two issues exist:
- This method does not guarantee an optimal constrained path. o This method does not guarantee an optimal constrained path.
- The method may require several crankback signaling messages o The method may require several crankback signaling messages
increasing signaling traffic and delaying the LSP setup. increasing signaling traffic and delaying the LSP setup.
The PCE-based architecture [RFC4655] is designed to solve inter-area The PCE-based architecture [RFC4655] is designed to solve inter-area
path computation problems. The issue of limited topology visibility path computation problems. The issue of limited topology visibility
is resolved by introducing path computation entities that are able to is resolved by introducing path computation entities that are able to
cooperate in order to establish LSPs with source and destinations cooperate in order to establish LSPs with source and destinations
located in different areas. located in different areas.
5.1. Inter-area Routing 5.1. Inter-area Routing
An inter-area TE-LSP is an LSP that transits through at least two An inter-area TE-LSP is an LSP that transits through at least two
IGP areas. In a multi-area network, topology visibility remains IGP areas. In a multi-area network, topology visibility remains
local to a given area, and a node in one area will not be able to local to a given area for scaling and privacy purposes, a node
compute an end-to-end path across multiple areas without the use in one area will not be able to compute an end-to-end path across
of a PCE. multiple areas without the use of a PCE.
5.1.1. Area Inclusion and Exclusion 5.1.1. Area Inclusion and Exclusion
[RFC5441] provides a more optimal method to specify inclusion or The BRPC method [RFC5441] of path computation provides a more optimal
exclusion of an ABR. Using this method, an operator might decide if method to specify inclusion or exclusion of an ABR. Using the BRPC
an area must be include or exclude from the inter-area path procedure an end-to-end path is recursively computed in reverse from
computation. 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.
5.1.2. Strict Explicit Path and Loose Path 5.1.2. Strict Explicit Path and Loose Path
A strict explicit Path is defined as a set of strict hops, while a 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, loose path is defined as a set of at least one loose hop and zero,
one or more strict hops. It may be useful to indicate, during the one or more strict hops. It may be useful to indicate, during the
path computation request, if a strict explicit path is required or path computation request, if a strict explicit path is required or
not. An inter-area path may be strictly explicit or loose (e.g., a not. An inter-area path may be strictly explicit or loose (e.g., a
list of ABRs as loose hops). list of ABRs as loose hops).
A PCC request to a PCE does allow the indication of if a strict A PCC request to a PCE does allow the indication of whether a strict
explicit path across specific areas ([RFC7897]) is required or explicit path across specific areas ([RFC7897]) is required or
desired, or if the path request is loose. desired, or if the path request is loose.
5.1.3. Inter-Area Diverse Path Computation 5.1.3. Inter-Area Diverse Path Computation
It may be necessary (for protection or load-balancing) to compute It may be necessary (for protection or load-balancing) to compute
a path that is diverse, from a previously computed path. There are a path that is partially or entirely diverse, from a previously
various levels of diversity in the context of an inter-area network: computed path. There are various levels of diversity in the context
of an inter-area network:
- Per-area diversity (intra-area path segments are link, node or o Per-area diversity (intra-area path segments are link, node or
SRLG disjoint. SRLG disjoint.
- Inter-area diversity (end-to-end inter-area paths are link, o Inter-area diversity (end-to-end inter-area paths are link,
node or SRLG disjoint). node or SRLG disjoint).
Note that two paths may be disjoint in the backbone area but non- Note that two paths may be disjoint in the backbone area but non-
disjoint in peripheral areas. Also two paths may be node disjoint disjoint in peripheral areas. Also, two paths may be node disjoint
within areas but may share ABRs, in which case path segments within within areas but may share ABRs, in which case path segments within
an area are node disjoint but end-to-end paths are not node-disjoint. an area is node disjoint, but end-to-end paths are not node-disjoint.
Per-Domain [RFC5152], BRPC [RFC5441] and H-PCE [RFC6805] mechanisms Per-Domain [RFC5152], BRPC [RFC5441] and H-PCE [RFC6805] mechanisms
support the capability to compute diverse across multi-area all support the capability to compute diverse paths across multi-area
topologies. topologies.
5.2. Control and Recording of Area Crossing
In some environments it be useful for the PCE to provide a PCC the
set of areas crossed by the end-to-end path. Then an operator may
either want to avoid crossing specific areas, and choose to select a
sub-optimal intra-area path. Additionally the PCE can provide the
path information and mark each segment so the PCC has visibility of
which piece of the path lies within which area. Although by
implementing Path-Key, the hop-by-hop (area topology) information is
kept confidential.
6. Applicability of the PCE to Inter-AS Traffic Engineering 6. Applicability of the PCE to Inter-AS Traffic Engineering
As discussed in section 4 (Applicability of the PCE to Inter-area As discussed in section 4 (Applicability of the PCE to Inter-area
Traffic Engineering) it is necessary to divide the network into Traffic Engineering) it is necessary to divide the network into
smaller administrative domains, or ASes. If an LSR within an AS needs 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 to compute a path across an AS boundary, it must also use an inter-AS
computation technique. [RFC5152] defines mechanisms for the computation technique. [RFC5152] defines mechanisms for the
computation of inter-domain TE LSPs using network elements along the computation of inter-domain TE LSPs using network elements along the
signaling paths to compute per-domain constrained path segments. signaling paths to compute per-domain constrained path segments.
The PCE was designed to be capable of computing MPLS and GMPLS paths The PCE was designed to be capable of computing MPLS and GMPLS paths
across AS boundaries. This section outlines the features of a across AS boundaries. This section outlines the features of a
PCE-enabled solution for computing inter-AS paths. PCE-enabled solution for computing inter-AS paths.
6.1 Inter-AS Routing 6.1 Inter-AS Routing
6.1.1. Strict Explicit Path and Loose Path 6.1.1. AS Inclusion and Exclusion
During path computation, the PCE architecture and BRPC algorithm
allow operators to specify if the resultant LSP must follow a strict
or a loose path. By explicitly specify the path, the operator
request a strict explicit path which must pass through one or many
LSR. If this behaviour is well define and appropriate for inter-area,
it implies some topology discovery for inter-AS. So, this feature
when the operator owns several ASes (and so, knows the topology of
its ASes) or restricts to the well-known ASBR to avoid topology
discovery between operators. The loose path, even if it does not
allow granular specification of the path, protects topology
disclosure as it not obligatory for the operator to disclose
information about its networks.
6.1.2. AS Inclusion and Exclusion
Like explicit and loose path, [RFC5441] allows to specify inclusion [RFC5441] allows the specifying of inclusion or exclusion of an AS
or exclusion of respectively an AS or an ASBR. Using this method, or an ASBR. Using this method, an operator might decide if an AS
an operator might decide if an AS must be include or exclude from must be include or exclude from the inter-AS path computation.
the inter-AS path computation. Exclusion and/or inclusion could also Exclusion and/or inclusion could also be specified at any step in
be specified at any step in the LSP path computation process by a PCE the LSP path computation process by a PCE (within the BRPC
(within the BRPC algorithm) but the best practice would be to specify algorithm) but the best practice would be to specify them at the
them at the edge. In opposition to the strict and loose path, AS edge. In opposition to the strict and loose path, AS inclusion or
inclusion or exclusion doesn't impose topology disclosure as ASes are exclusion doesn't impose topology disclosure as ASes are public
public entity as well as their interconnection. entity as well as their interconnection.
6.2 Inter-AS Bandwidth Guarantees 6.2 Inter-AS Bandwidth Guarantees
Many operators with multi-AS domains will have deployed MPLS-TE Many operators with multi-AS domains will have deployed MPLS-TE
DiffServ either across their entire network or at the domain edges DiffServ either across their entire network or at the domain edges
on CE-PE links. In situations where strict QOS bounds are required, on CE-PE links. In situations where strict QOS bounds are required,
admission control inside the network may also be required. admission control inside the network may also be required.
When the propagation delay can be bounded, the performance targets, When the propagation delay can be bounded, the performance targets,
such as maximum one-way transit delay may be guaranteed by providing such as maximum one-way transit delay may be guaranteed by providing
skipping to change at page 14, line 19 skipping to change at page 13, line 13
classified as EF (Expedited Forwarding) class in a DiffServ-enabled classified as EF (Expedited Forwarding) class in a DiffServ-enabled
network. In the case where the EF path is extended across multiple network. In the case where the EF path is extended across multiple
ASes, inter-AS bandwidth guarantee would be required. ASes, inter-AS bandwidth guarantee would be required.
Another case for inter-AS bandwidth guarantee is the requirement for Another case for inter-AS bandwidth guarantee is the requirement for
guaranteeing a certain amount of transit bandwidth across one or guaranteeing a certain amount of transit bandwidth across one or
multiple ASes. multiple ASes.
6.3 Inter-AS Recovery 6.3 Inter-AS Recovery
During a path computation process, a PCC request may contain a During a path computation process, a PCC request may contain the
requirement to compute a backup LSP for protecting the primary LSP, requirement to compute a backup LSP for protecting the primary LSP,
1+1 protection. A single, or multiple backup LSPs may also be used 1+1 protection. A single LSP or multiple backup LSPs may also be
for a group of primary LSPs, m:n protection. used for a group of primary LSPs, this is typically known as m:n
protection.
Other inter-AS recovery mechanisms include [RFC4090] which adds fast Other inter-AS recovery mechanisms include [RFC4090] which adds fast
re-route (FRR) protection to an LSP. So, the PCE could be used to re-route (FRR) protection to an LSP. So, the PCE could be used to
trigger computation of backup tunnels in order to protect Inter-AS trigger computation of backup tunnels in order to protect Inter-AS
connectivity. connectivity.
Inter-AS recovery needs not only LSP protection but it would also be Inter-AS recovery clearly requires backup LSPs for service
advisable to have multiple PCEs deployed for redundancy. 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.
6.4 Inter-AS PCE Peering Policies 6.4 Inter-AS PCE Peering Policies
Like BGP peering policies, inter-AS PCE peering policies is a Like BGP peering policies, inter-AS PCE peering policies is a
requirement for operator. In inter-AS BRPC process, PCE must requirement for operator. In inter-AS BRPC process, PCE must
cooperate in order to compute the end-to-end LSP. So, the AS path cooperate in order to compute the end-to-end LSP. So, the AS path
must not only follow technical constraints e.g. bandwidth must not only follow technical constraints, e.g. bandwidth
availability, but also policies define by the operator. availability, but also policies defined by the operator.
Typically PCE interconnections at an AS level must follow contract Typically PCE interconnections at an AS level must follow agreed
obligations, also known as peering agreements. The PCE peering contract obligations, also known as peering agreements. The PCE
policies are the result of the contract negotiation and govern peering policies are the result of the contract negotiation and
the relation between the different PCE. govern the relation between the different PCE.
7. Multi-domain PCE Deployment Options 7. Multi-domain PCE Deployment Options
The PCE provides the architecture and mechanisms to compute 7.1 Traffic Engineering Database and Synchronization
inter-area and inter-AS LSPs. The objective of this document is not
to reprint the techniques and mechanisms available, but to highlight
their existence and reference the relevant documents that introduce
and describe the techniques and mechanisms necessary for computing
inter-area and inter-AS LSP based services.
An area or AS may contain multiple PCEs:
- The path computation load may be balanced among a set of PCEs to
improve scalability.
- For the purpose of redundancy, primary and backup PCEs may be used.
- PCEs may have distinct path computation capabilities (P2P or P2MP).
Discovery of PCEs and capabilities per area or AS is defined in
[RFC5088] and [RFC5089].
Each PCE per domain can be deployed in a centralized or distributed
architecture, the latter model having local visibility and
collaborating in a distributed fashion to compute a path across the
domain. Each PCE may collect topology and TE information from the
same sources as the LSR, such as the IGP TED.
When the PCC sends a path computation request to the PCE, the PCE
will compute the path across a domain based on the required
constraints. The PCE will generate the full set of strict hops from
source to destination. This information, encoded as an ERO, is then
sent back to the PCC that requested the path. In the event that a
path request from a PCC contains source and destination nodes that
are located in different domains the PCE is required to co-operate
between multiple PCEs, each responsible for its own domain.
Techniques for inter-domain path computation are described in
[RFC5152] and [RFC5441], both techniques assume that the sequence of
domains to be crossed from source to destination is well known. In
the event that the sequence of domains is not well known, [RFC6805]
might be used. The sequence could also be retrieve locally from
information previously stored in the PCE database (preferably in
the TED) by Operational Support Systems (OSS) management or other
protocols.
7.1 Traffic Engineering Database 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 [RFC4655] the TED used by a PCE may be learnt
by the relevant IGP extensions.
TEDs are automatically populated by the IGP-TE like IS-IS-TE or Thus, the PCE may operate its TED is by participating
OSPF-TE. However, no information related to AS path are provided in the IGP running in the network. In an MPLS-TE network, this
by such IGP-TE. It could be helpful for BRPC algorithm as AS path would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS
helper, to populate a TED with suitable information regarding network it would utilize the GMPLS extensions to OSPF and IS-IS
inter-AS connectivity. Such information could be obtain from defined in [RFC4203] and [RFC5307]. Inter-as connectivity
various sources, such as BGP protocol, peering policies, OSS of the information may be populated via [RFC5316] and [RFC5392].
operator or from neighbor PCE. In any case, no topology disclosure
must be impose in order to provide such information.
In particular, for both inter-area and inter-AS, the TED must be An alternative method to provide network topology and resource
populated. Inter-as connectivity information may be populated via information is offered by [RFC7752], which is described in the
[RFC5316] and [RFC5392]. following section.
7.1.1 Provisioning Techniques 7.1.1 Applicability of BGP-LS to PCE
As PCE algorithms rely on information contained in the TED, it The concept of exchange of TE information between Autonomous Systems
is possible to populate TED information by means of provisioning. In (ASes) is discussed in [RFC7752]. The information exchanged in this
this case, the operator must regularly update and store all suitable way could be the full TE information from the AS, an aggregation of
information in the TED in order for the PCE to correctly compute LSP. that information, or a representation of the potential connectivity
Such information range from policies (e.g. avoid this LSR, or use across the AS. Furthermore, that information could be updated
this ASBR for a specific IP prefix) up to topology information (e.g. frequently (for example, for every new LSP that is set up across the
AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s AS) or only at threshold-crossing events.
are reserved for EF traffic). Operators may choose the type and
amount of information they can use to manage their traffic engineered
network.
However, some LSPs might be provisioned to link ASes or areas. In In an H-PCE deployment, the parent PCE will require the inter-domain
this case, these LSP must be announced by the IGP-TE in order to topology and link status between child domains. This information may
automatically populate the TED. be learnt 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.
7.3 Pre-Planning and Management-Based Solutions 7.2 Pre-Planning and Management-Based Solutions
Offline path computation is performed ahead of time, before the LSP Offline path computation is performed ahead of time, before the LSP
setup is requested. That means that it is requested by, or performed setup is requested. That means that it is requested by, or performed
as part of, a management application. This model can be seen in as part of, an OSS management application. This model can be seen
Section 5.5 of [RFC4655]. in Section 5.5 of [RFC4655].
The offline model is particularly appropriate to long-lived LSPs The offline model is particularly appropriate to long-lived LSPs
(such as those present in a transport network) or for planned (such as those present in a transport network) or for planned
responses to network failures. In these scenarios, more planning is responses to network failures. In these scenarios, more planning is
normally a feature of LSP provisioning. normally a feature of LSP provisioning.
This model may also be used where the network operator wishes to The management system may also use a PCE and BRPC to pre-plan an AS
retain full manual control of the placement of LSPs, using the PCE sequence, and the source domain PCE and per-domain path
only as a computation tool to assist the operator, not as part of an computation to be used when the actual end-to-end path is
automated network. required. This model may also be used where the operator
wishes to retain full manual control of the placement of LSPs,
The management based solutions could also be used in conjunction using the PCE only as a computation tool to assist the operator,
with the BRPC algorithm. Operator just computes the AS-Path as not as part of an automated network.
parameter for the inter-AS path computation request and let each
PCE along the AS path compute the LSP part on its own domain.
7.4 Per-Domain Computation
[RFC5152] defines the mechanism to compute per-domain path and must
be used in that condition. Otherwise, BRPC [RFC5441] or HPCE RFC6805]
will be used..
7.5 Cooperative PCEs
When PCE cooperatation is required to compute an inter-area or inter-
AS LSP, the techniques described in [RFC5441] and [RFC6805] could be
used.
7.6 Hierarchical PCEs
The H-PCE [RFC6805] proposal defines how a hierarchy of PCEs may be In environments where operators peer with each other to provide end-
used. An operator must enable a parent PCE, and a child PCE per to-end paths, the operator responsible for each domain must agree
domain (AS or area). A parent PCE can be announced in the other areas to what extent paths must be pre-planned or manually controlled.
or ASes in order for the parent PCE to contact remote child PCEs.
Reciprocally, child PCEs are announced in remote areas or ASes in
order to be contacted by a remote parent PCE. Parent and each child
PCE could also be provisioned in the TED if they are not announced.
8. Domain Confidentiality 8. Domain Confidentiality
This section discusses the techniques that co-operating 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 Confidentiality typically applies to inter-provider (inter-AS) PCE
communication. Where the TE LSP crosses multiple domains (ASes or communication. Where the TE LSP crosses multiple domains (ASes or
areas), the path may be computed by multiple PCEs that cooperate areas), the path may be computed by multiple PCEs that cooperate
together. With each local PCE responsible for computing a segment together. With each local PCE responsible for computing a segment
of the path. However, in some cases (e.g., when ASes are of the path.
administered by separate Service Providers), it would break
confidentiality rules for a PCE to supply a path segment to a In situations where ASes are administered by separate Service
PCE in another domain, thus disclosing AS-internal or area Providers, it would break confidentiality rules for a PCE to supply
topology information. a path segment details to a PCE responsible another domain, thus
disclosing AS-internal or area topology information.
8.1 Loose Hops 8.1 Loose Hops
A method for preserving the confidentiality of the path segment is 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 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 segment that must be kept confidential. The concept of loose and
strict hops for the route of a TE LSP is described in [RFC3209]. strict hops for the route of a TE LSP is described in [RFC3209].
[RFC5440] supports the use of paths with loose hops, and it is a [RFC5440] supports the use of paths with loose hops, and it is a
local policy decision at a PCE whether it returns a full explicit local policy decision at a PCE whether it returns a full explicit
path with strict hops or uses loose hops. A path computation path with strict hops or uses loose hops. A path computation
request may request an explicit path with strict hops, or request may require an explicit path with strict hops, or may allow
may allow loose hops as detailed in [RFC5440]. loose hops as detailed in [RFC5440].
8.2 Confidential Path Segments and Path Keys 8.2 Confidential Path Segments and Path Keys
[RFC5520] defines the concept and mechanism of Path-Key. A Path-Key [RFC5520] defines the concept and mechanism of Path-Key. A Path-Key
is a token that replaces the path segment information in an explicit is a token that replaces the path segment information in an explicit
route. The Path-Key allows the explicit route information to be route. The Path-Key allows the explicit route information to be
encoded and in the PCEP ([RFC5440]) messages exchanged between the encoded and in the PCEP ([RFC5440]) messages exchanged between the
PCE and PCC. PCE and PCC.
This Path-Key technique allows explicit route information to used This Path-Key technique allows explicit route information to be used
for end-to-end path computation, without disclosing internal topology for end-to-end path computation, without disclosing internal topology
information between domains. information between domains.
9. Point-to-Multipoint 9. Point-to-Multipoint
For the Point-to-Multipoint application scenarios for MPLS-TE LSP, For inter-domain point-to-multipoint application scenarios using
the complexity of domain sequences, domain policies, choice and MPLS-TE LSPs, the complexity of domain sequences, domain policies,
number of domain interconnects is magnified comparing to P2P path choice and number of domain interconnects is magnified compared to
computations. Also as the size of the network grows, the number of point-to-point path computations. As the size of the network
leaves and branches increase and it in turn puts the scalability of grows, the number of leaves and branches increase, further
the path computation and optimization into a bigger issue. A increasing the complexity of the overall path computation problem.
solution for the point-to-multipoint path computations may be A solution for managing point-to-multipoint path computations may
achieved using the PCEP protocol extension for P2MP [RFC6006] and be achieved using the PCE inter-domain point-to-multipoint path
using the inter-domain P2MP procedures defined in [RFC7334]. computation [RFC7334] procedure.
10. Optical Domains 10. Optical Domains
The International Telecommunications Union (ITU) defines the ASON The International Telecommunications Union (ITU) defines the ASON
architecture in [G-8080]. [G-7715] defines the routing architecture architecture in [G-8080]. [G-7715] defines the routing architecture
for ASON and introduces a hierarchical architecture. In this for ASON and introduces a hierarchical architecture. In this
architecture, the Routing Areas (RAs) have a hierarchical architecture, the Routing Areas (RAs) have a hierarchical
relationship between different routing levels, which means a parent relationship between different routing levels, which means a parent
(or higher level) RA can contain multiple child RAs. The (or higher level) RA can contain multiple child RAs. The
interconnectivity of the lower RAs is visible to the higher level RA. interconnectivity of the lower RAs is visible to the higher-level RA.
10.1. PCE applied to the ASON Architecture
In the ASON framework, a path computation request is termed a Route In the ASON framework, a path computation request is termed a Route
Query. This query is executed before signaling is used to establish Query. This query is executed before signaling is used to establish
an LSP termed a Switched Connection (SC) or a Soft Permanent an LSP termed a Switched Connection (SC) or a Soft Permanent
Connection (SPC). [G-7715-2] defines the requirements and Connection (SPC). [G-7715-2] defines the requirements and
architecture for the functions performed by Routing Controllers (RC) architecture for the functions performed by Routing Controllers (RC)
during the operation of remote route queries - an RC is synonymous during the operation of remote route queries - an RC is synonymous
with a PCE. with a PCE.
In the ASON routing environment, a RC responsible for an RA may In the ASON routing environment, an RC responsible for an RA may
communicate with its neighbor RC to request the computation of an communicate with its neighbor RC to request the computation of an
end-to-end path across several RAs. The path computation components end-to-end path across several RAs. The path computation components
and sequences are defined as follows: and sequences are defined as follows:
o Remote route query. An operation where a routing controller o Remote route query. An operation where a routing controller
communicates with another routing controller, which does not have communicates with another routing controller, which does not have
the same set of layer resources, in order to compute a routing the same set of layer resources, in order to compute a routing
path in a collaborative manner. path in a collaborative manner.
o Route query requester. The connection controller or RC that sends a o Route query requester. The connection controller or RC that sends a
route query message to a routing controller requesting for one or route query message to a routing controller requesting for one or
more routing path that satisfies a set of routing constraints. more routing paths that satisfy a set of routing constraints.
o Route query responder. An RC that performs path computation upon o Route query responder. An RC that performs path computation upon
reception of a route query message from a routing controller or reception of a route query message from a routing controller or
connection controller, sending a response back at the end of connection controller, sending a response back at the end of
computation. computation.
When computing an end-to-end connection, the route may be computed by 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 a single RC or multiple RCs in a collaborative manner and the two
scenarios can be considered a centralized remote route query model scenarios can be considered a centralized remote route query model
and distributed remote route query model. RCs in an ASON environment and distributed remote route query model. RCs in an ASON environment
can also use the hierarchical PCE [RFC6805] model to fully match the can also use the hierarchical PCE [RFC6805] model to match fully the
ASON hierarchical routing model. ASON hierarchical routing model.
10.1 Abstraction and Control of TE Networks (ACTN)
Where a single operator operates multiple TE domains (including
optical environments) then Abstraction and Control of TE Networks
(ACTN) framework [RFC8453] may be used to create an abstracted
(virtualized network) view of underlay interconnected domains. This
underlay connectivity then be exposed to higher-layer control
entities and applications.
ACTN describes the method and procedure for coordinating the
underlay per-domain Physical Network Controllers (PNCs), which may
be PCEs, via a hierarchical model to facilitate setup of
end-to-end connections across inter-connected TE domains.
11. Policy 11. Policy
Policy is important in the deployment of new services and the Policy is important in the deployment of new services and the
operation of the network. [RFC5394] provides a framework for PCE- operation of the network. [RFC5394] provides a framework for PCE-
based policy-enabled path computation. This framework is based on based policy-enabled path computation. This framework is based on
the Policy Core Information Model (PCIM) as defined in [RFC3060] and the Policy Core Information Model (PCIM) as defined in [RFC3060] and
further extended by [RFC3460]. further extended by [RFC3460].
When using a PCE to compute inter-domain paths, policy may be When using a PCE to compute inter-domain paths, policy may be
invoked by specifying: invoked by specifying:
- Each PCC must select which computations will be requested to a PCE; o Each PCC must select which computations will be requested to a PCE;
- Each PCC must select which PCEs it will use; o Each PCC must select which PCEs it will use;
- Each PCE must determine which PCCs are allowed to use its services o Each PCE must determine which PCCs are allowed to use its services
and for what computations; and for what computations;
- The PCE must determine how to collect the information in its TED, o The PCE must determine how to collect the information in its TED,
who to trust for that information, and how to refresh/update the whom to trust for that information, and how to refresh/update the
information; information;
- Each PCE must determine which objective functions and which o Each PCE must determine which objective functions and which
algorithms to apply. algorithms to apply.
Finally, due to the nature of inter-domain (and particularly using 12. Manageability Considerations
H-PCE based) path computations, deployment of policy should also
consider the need to be sensitive to commercial and reliability
information about domains and the interactions of services crossing
domains.
12. TED Topology and Synchronization
The PCE operates on a view of the network topology as presented by a
Traffic Engineering Database. As discussed in [RFC4655] the TED
used by a PCE may be learnt by the relevant IGP extensions.
Thus, the PCE may operate its TED is by participating
in the IGP running in the network. In an MPLS-TE network, this
would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS
network it would utilize the GMPLS extensions to OSPF and IS-IS
defined in [RFC4203] and [RFC5307].
An alternative method to provide network topology and resource
information is offered by [RFC7752], which is described in the
following section.
12.1 Applicability of BGP-LS to PCE
The concept of exchange of TE information between Autonomous Systems
(ASes) is discussed in [RFC7752]. 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 a H-PCE deployment, the parent PCE will require the inter-domain
topology and link status between child domains. This information may
be learnt 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 link selection.
13. Manageability Considerations
General PCE management considerations are discussed in [RFC4655]. General PCE management considerations are discussed in [RFC4655].
In the case of multi-domains within a single service provider In the case of multi-domains within a single service provider
network, the management responsibility for each PCE would most network, the management responsibility for each PCE would most
likely be handled by the same service provider. In the case of likely be handled by the same service provider. In the case of
multiple ASes within different service provider networks, it will multiple ASes within different service provider networks, it will
likely be necessary for each PCE to be configured and managed likely be necessary for each PCE to be configured and managed
separately by each participating service provider, with policy separately by each participating service provider, with policy
being implemented based on an a previously agreed set of principles. being implemented based on a previously agreed set of principles.
13.1 Control of Function and Policy 12.1 Control of Function and Policy
As per PCEP [RFC5440] implementation allow the user to configure As per PCEP [RFC5440] implementation allow the user to configure
a number of PCEP session parameters. These are detailed in section a number of PCEP session parameters. These are detailed in section
8.1 of [RFC5440]. 8.1 of [RFC5440].
In H-PCE deployments the administrative entity responsible for the In H-PCE deployments the administrative entity responsible for the
management of the parent PCEs for multi-areas would typically be a management of the parent PCEs for multi-areas would typically be a
single service provider. In the multiple ASes (managed by different single service provider. In the multiple ASes (managed by different
service providers), it may be necessary for a third party to manage service providers), it may be necessary for a third party to manage
the parent PCE. the parent PCE.
13.2 Information and Data Models 12.2 Information and Data Models
A PCEP MIB module is defined in [RFC7420] that describes managed A PCEP MIB module is defined in [RFC7420] that describes managed
objects for modeling of PCEP communication including: objects for modeling of PCEP communication including:
o PCEP client configuration and status, o PCEP client configuration and status,
o PCEP peer configuration and information, o PCEP peer configuration and information,
o PCEP session configuration and information, o PCEP session configuration and information,
o Notifications to indicate PCEP session changes. o Notifications to indicate PCEP session changes.
A YANG module for PCEP has also been proposed [PCEP-YANG]. A YANG module for PCEP has also been proposed [PCEP-YANG].
A H-PCE MIB module, or YANG data model, will be required to An H-PCE MIB module, or YANG data model, will be required to
report parent PCE and child PCE information, including: report parent PCE and child PCE information, including:
o parent PCE configuration and status, o parent PCE configuration and status,
o child PCE configuration and information, o child PCE configuration and information,
o notifications to indicate session changes between parent PCEs and o notifications to indicate session changes between parent PCEs and
child PCEs, and child PCEs, and
o notification of parent PCE TED updates and changes. o notification of parent PCE TED updates and changes.
section 8.4 of [RFC5440] and will not be repeated here.
13.5 Impact on Network Operation 12.3 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 [RFC5886]
provides the procedures necessary to monitor the liveliness and
performances of a given PCE chain.
12.4 Verifying Correct Operation
It is important to verify the correct operation of PCEP, [RFC5440]
specifies the monitoring of key parameters. These parameters are
detailed in [RFC5520].
12.5 Impact on Network Operation
[RFC5440] states that in order to avoid any unacceptable impact on [RFC5440] states that in order to avoid any unacceptable impact on
network operations, a PCEP implementation should allow a limit to be 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 placed on the number of sessions that can be set up on a PCEP
speaker, it may also be practical to place a limit on the rate speaker, it may also be practical to place a limit on the rate
of messages sent by a PCC and received my the PCE. of messages sent by a PCC and received my the PCE.
14. Security Considerations 13. Security Considerations
PCEP security is defined [RFC5440]. Any multi-domain operation PCEP security is defined [RFC5440]. Any multi-domain operation
necessarily involves the exchange of information across domain necessarily involves the exchange of information across domain
boundaries. This does represent a significant security and boundaries. This does represent significant security and
confidentiality risk. PCEP allows individual PCEs to maintain confidentiality risk. PCEP allows individual PCEs to maintain
confidentiality of their domain path information using path-keys confidentiality of their domain path information using path-keys
13.3 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 [RFC5886]
provides the procedures necessary to monitor the liveliness and
performances of a given PCE chain.
13.4 Verifying Correct Operation
In order to verify the correct operation of PCEP, [RFC5440] specifies
the monitoring of key parameters. These parameters are detailed in
[RFC5520].
As PCEP operates over TCP, it may also make use of TCP security As PCEP operates over TCP, it may also make use of TCP security
mechanisms, such as Transport Layer Security (TLS) and TCP mechanisms, such as Transport Layer Security (TLS) and TCP
Authentication Option (TCP-AO). Usage of these security mechanisms Authentication Option (TCP-AO). Usage of these security mechanisms
for PCEP is described in [PCEPS]. for PCEP is described in [RFC8253].
For further considerations of the security issues related PCECP and For further considerations of the security issues related to PCEP
to inter-domain path computation, see [RFC6952] and [RFC5376]. and to inter-domain path computation, see [RFC6952] and [RFC5376].
15. IANA Considerations 14. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
16. Acknowledgements 15. Acknowledgements
The author would like to thank Adrian Farrel for his review, and The author would like to thank Adrian Farrel for his review, and
Meral Shirazipour and Francisco Javier Jimenex Chico for their Meral Shirazipour and Francisco Javier Jimenex Chico for their
comments. comments.
17. References 16. References
17.1. Normative References 16.1. Normative References
17.2. Informative References 16.2. Informative References
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A.
Westerinen, "Policy Core Information Model -- Version 1 Westerinen, "Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001. Specification", RFC 3060, February 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
skipping to change at page 24, line 40 skipping to change at page 22, line 21
April 2009. April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) Path Computation Element Communication Protocol (PCEP)
for Route Exclusions", RFC 5521, April 2009. for Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding [RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding
of Objective Functions in the Path Computation Element of Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC5541, December 2008. Communication Protocol (PCEP)", RFC5541, December 2008.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path ComputationElement (PCE)-Based Monitoring Tools for Path ComputationElement (PCE)-Based
Architecture", RFC 5886, June 2010. Architecture", RFC 5886, June 2010.
[RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,
Zhao, Q., King, D., "Extensions to the Path Computation
Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC6006, September 2010.
[RFC6007] Nishioka, I., King, D., "Use of the Synchronization [RFC6007] Nishioka, I., King, D., "Use of the Synchronization
VECtor (SVEC) List for Synchronized Dependent Path VECtor (SVEC) List for Synchronized Dependent Path
Computations", RFC6007, September 2010. Computations", RFC6007, September 2010.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON). the automatically switched optical network (ASON).
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture [G-7715] ITU-T Recommendation G.7715 (2002), Architecture
and Requirements for the Automatically Switched and Requirements for the Automatically Switched
Optical Network (ASON). Optical Network (ASON).
skipping to change at page 25, line 46 skipping to change at page 23, line 18
Communication Protocol (PCEP) Management Information Communication Protocol (PCEP) Management Information
Base", December 2014. Base", December 2014.
[RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and TE S. Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", March 2016. Information using BGP", March 2016.
[RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects
for the Path Computation Element Communication Protocol for the Path Computation Element Communication Protocol
(PCEP)", June 2016. (PCEP)", June 2016.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for
the Path Computation Element Communication Protocol
(PCEP)", RFC 8253, October 2017.
[PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for
Transport for PCEP", work in progress, November 2015. Abstraction and Control of TE Networks (ACTN)", RFC8453,
August 2018.
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A [PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", work in progress, Communications Protocol (PCEP)", work in progress,
January 2016. October 2018.
18. Author's Addresses 17. Contributors
Daniel King Dhruv Dhody
Old Dog Consulting Huawei Technologies
UK Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: daniel@olddog.co.uk Email: dhruv.ietf@gmail.com
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: qzhao@huawei.com
Julien Meuric Julien Meuric
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
EMail: julien.meuric@orange-ftgroup.com Email: julien.meuric@orange-ftgroup.com
Olivier Dugeon Olivier Dugeon
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
EMail: olivier.dugeon@orange-ftgroup.com Email: olivier.dugeon@orange-ftgroup.com
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
EMail: qzhao@huawei.com
Dhruv Dhody Jon Hardwick
Huawei Technologies Metaswitch Networks
Divyashree Techno Park, Whitefield 100 Church Street
Bangalore, Karnataka 560066 Enfield, Middlesex
India United Kingdom
Email: dhruv.ietf@gmail.com Email: jonathan.hardwick@metaswitch.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica I+D Telefonica I+D
Emilio Vargas 6, Madrid Emilio Vargas 6, Madrid
Spain Spain
EMail: ogondio@tid.es Email: ogondio@tid.es
18. Author's Addresses
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Haomian Zheng
Huawei Technologies
F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhenghaomian@huawei.com
 End of changes. 127 change blocks. 
516 lines changed or deleted 360 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/