draft-ietf-pce-stateful-pce-app-02.txt   draft-ietf-pce-stateful-pce-app-03.txt 
PCE Working Group X. Zhang, Ed. PCE Working Group X. Zhang, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational I. Minei, Ed. Intended status: Informational I. Minei, Ed.
Expires: December 12, 2014 Google, Inc. Expires: April 28, 2015 Google, Inc.
June 10, 2014 October 25, 2014
Applicability of a Stateful Path Computation Element (PCE) Applicability of a Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-pce-app-02 draft-ietf-pce-stateful-pce-app-03
Abstract Abstract
A stateful Path Computation Element (PCE) maintains information about A stateful Path Computation Element (PCE) maintains information about
Label Switched Path (LSP) characteristics and resource usage within a Label Switched Path (LSP) characteristics and resource usage within a
network in order to provide traffic engineering calculations for its network in order to provide traffic engineering calculations for its
associated Path Computation Clients (PCCs). This document describes associated Path Computation Clients (PCCs). This document describes
general considerations for a stateful PCE deployment and examines its general considerations for a stateful PCE deployment and examines its
applicability and benefits, as well as its challenges and limitations applicability and benefits, as well as its challenges and limitations
through a number of use cases. PCE communication Protocol (PCEP) through a number of use cases. PCE Communication Protocol (PCEP)
extensions required for stateful PCE usage are covered in separate extensions required for stateful PCE usage are covered in separate
documents. documents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://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."
This Internet-Draft will expire on December 12, 2014. This Internet-Draft will expire on April 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 (http://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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 14
5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 15 5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 15
5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 16 5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 16
5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 17 5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 17
5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17 5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17
5.7. Resource Defragmentation . . . . . . . . . . . . . . . . 18 5.7. Resource Defragmentation . . . . . . . . . . . . . . . . 18
5.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 19 5.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 19
5.9. Impairment-Aware Routing and Wavelength Assignment (IA- 5.9. Impairment-Aware Routing and Wavelength Assignment (IA-
RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC4655] defines the architecture for a Path Computation Element [RFC4655] defines the architecture for a Path Computation Element
(PCE)-based model for the computation of Multiprotocol Label (PCE)-based model for the computation of Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
Label Switched Paths (TE LSPs). To perform such a constrained Label Switched Paths (TE LSPs). To perform such a constrained
computation, a PCE stores the network topology (i.e., TE links and computation, a PCE stores the network topology (i.e., TE links and
nodes) and resource information (i.e., TE attributes) in its TE nodes) and resource information (i.e., TE attributes) in its TE
skipping to change at page 4, line 11 skipping to change at page 4, line 13
destination. The summed capacity of these links is equivalent to destination. The summed capacity of these links is equivalent to
the maximum capacity from the source to the destination by the the maximum capacity from the source to the destination by the
max-flow min-cut theorem. max-flow min-cut theorem.
3. Overview of the Stateful PCE Protocol Extensions 3. Overview of the Stateful PCE Protocol Extensions
This section is included for the convenience of the reader, please This section is included for the convenience of the reader, please
refer to the referenced documents for details of the operation. refer to the referenced documents for details of the operation.
[I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to
enable stateful control of tunnels within and across PCEP sessions in enable stateful control of LSPs within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect tunnel compliance with [RFC4657]. It includes mechanisms to effect LSP
state synchronization between PCCs and PCEs, delegation of control state synchronization between PCCs and PCEs, delegation of control
over tunnels to PCEs, and PCE control of timing and sequence of path over LSPs to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. computations within and across PCEP sessions.
[I-D.ietf-pce-stateful-pce] applies equally to MPLS-TE and GMPLS LSPs [I-D.ietf-pce-stateful-pce] applies equally to MPLS-TE and GMPLS LSPs
and distinguishes between an active and a passive stateful PCE. A and distinguishes between an active and a passive stateful PCE. A
passive stateful PCE uses LSP state information to optimize path passive stateful PCE uses LSP state information to optimize path
computations but does not actively update LSP state. In contrast, an computations but does not actively update LSP state. In contrast, an
active stateful PCE may issue recommendations to the network. For active stateful PCE may issue recommendations to the network. For
example, an active stateful PCE may update LSP parameters in those example, an active stateful PCE may update LSP parameters in those
PCCs that delegated control over their LSPs to the PCE. PCCs that delegated control over their LSPs to the PCE.
skipping to change at page 4, line 39 skipping to change at page 4, line 41
functions are: functions are:
Stateful Capability negotiation (E-C,C-E): both the PCC and the PCE Stateful Capability negotiation (E-C,C-E): both the PCC and the PCE
must announce during PCEP session establishment that they support must announce during PCEP session establishment that they support
stateful PCE PCEP extensions. stateful PCE PCEP extensions.
LSP state synchronization (C-E): after the session between a PCC and LSP state synchronization (C-E): after the session between a PCC and
a stateful PCE is initialized, the PCE can perform path a stateful PCE is initialized, the PCE can perform path
computation and update attributes in a PCC. However, if the goal computation and update attributes in a PCC. However, if the goal
of the PCE is to provide accurate path information based on the of the PCE is to provide accurate path information based on the
most up-to-date state of the network, the PCE SHOULD wait until it most up-to-date state of the network, the PCE should wait until it
learns the state of the PCC's LSP states before doing so. learns the state of the PCC's LSP states before doing so.
LSP update request (E-C): A PCE requests the modification of one or LSP update request (E-C): A PCE requests the modification of one or
more attributes (e.g., route) on a PCC's LSP. more attributes (e.g., route) on a PCC's LSP.
LSP state report (C-E): a PCC sends an LSP state report to a PCE LSP state report (C-E): a PCC sends an LSP state report to a PCE
whenever the state of an LSP changes. whenever the state of an LSP changes.
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more LSPs; the PCE becomes the update LSP attributes on one or more LSPs; the PCE becomes the
skipping to change at page 6, line 12 skipping to change at page 6, line 17
stateful PCE, it is useful to refer to a LSP, be it delegated or not, stateful PCE, it is useful to refer to a LSP, be it delegated or not,
by a unique identifier instead of providing detailed information by a unique identifier instead of providing detailed information
(e.g., route, bandwidth etc.) associated with it, when these PCEs (e.g., route, bandwidth etc.) associated with it, when these PCEs
cooperate on path computation, such as for loading sharing. cooperate on path computation, such as for loading sharing.
4.3. PCE Survivability 4.3. PCE Survivability
For a stateful PCE, an important issue is to get the LSP state For a stateful PCE, an important issue is to get the LSP state
information resynchronized after a restart. information resynchronized after a restart.
[I-D.ietf-pce-stateful-pce] defines a synchronization function and [I-D.ietf-pce-stateful-pce] defines a synchronization function and
procedure, allowing a PCC to synchronize its LSP state with the PCE. procedure, allowing a PCC to synchronize its LSP state with the PCE
This can be applied equally to a network nodes or another PCE, and [I-D.ietf-pce-stateful-sync-optimizations] specifies
allowing multiple ways of re-acquiring the LSP database on a restart. optimizations to the synchronizations procedures. LSP state
Because synchronization may also be skipped, if a PCE implementation synchronization procedures can be applied equally to a network nodes
has the means to retrieve its database in a different way (for or another PCE, allowing multiple ways of re-acquiring the LSP
example from a backup copy stored locally), the state can be restored database on a restart. Because synchronization may also be skipped,
without further overhead in the network. A hybrid approach where the if a PCE implementation has the means to retrieve its database in a
bulk of the state is recovered locally, and a small amount of state different way (for example from a backup copy stored locally), the
is reacquired from the network, is also possible. Note that locally state can be restored without further overhead in the network. A
recovering the state would still require some degree of hybrid approach where the bulk of the state is recovered locally, and
resynchronization to ensure that the recovered state is indeed up-to- a small amount of state is reacquired from the network, is also
date. Depending on the resynchronization mechanism used, there may possible. Note that locally recovering the state would still require
be an additional load on the PCE, and there may be a delay in some degree of resynchronization to ensure that the recovered state
reaching the synchronized state, which may negatively affect is indeed up-to-date. Depending on the resynchronization mechanism
used, there may be an additional load on the PCE, and there may be a
delay in reaching the synchronized state, which may negatively affect
survivability. Different resynchronization methods are suited for survivability. Different resynchronization methods are suited for
different deployments and objectives. different deployments and objectives.
5. Application Scenarios 5. Application Scenarios
In the following sections, several use cases are described, In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of a stateful showcasing scenarios that benefit from the deployment of a stateful
PCE. PCE.
5.1. Optimization of LSP Placement 5.1. Optimization of LSP Placement
skipping to change at page 7, line 32 skipping to change at page 7, line 37
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G | | E +--------+ F +--------+ G |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: Reference topology 2 Figure 2: Reference topology 2
5.1.1. Throughput Maximization and Bin Packing 5.1.1. Throughput Maximization and Bin Packing
Because LSP attribute changes in [RFC5440] are driven by PCReq Because LSP attribute changes in [RFC5440] are driven by Path
messages under control of a PCC's local timers, the sequence of Computation Request (PCReq) messages under control of a PCC's local
resource reservation arrivals occurring in the network will be timers, the sequence of resource reservation arrivals occurring in
randomized. This, coupled with a lack of global LSP state visibility the network will be randomized. This, coupled with a lack of global
on the part of a stateless PCE may result in suboptimal throughput in LSP state visibility on the part of a stateless PCE may result in
a given network topology, as will be shown in the example below. suboptimal throughput in a given network topology, as will be shown
in the example below.
Reference topology 2 in Figure 2 and Tables 1 and 2 show an example Reference topology 2 in Figure 2 and Tables 1 and 2 show an example
in which throughput is at 50% of optimal as a result of lack of in which throughput is at 50% of optimal as a result of lack of
visibility and synchronized control across PCC's. In this scenario, visibility and synchronized control across PCC's. In this scenario,
the decision must be made as to whether to route any portion of the the decision must be made as to whether to route any portion of the
E-G demand, as any demand routed for this source and destination will E-G demand, as any demand routed for this source and destination will
decrease system throughput. decrease system throughput.
+------+--------+----------+ +------+--------+----------+
| Link | Metric | Capacity | | Link | Metric | Capacity |
skipping to change at page 9, line 28 skipping to change at page 9, line 28
established LSPs in the event of the failure of the bandwidth established LSPs in the event of the failure of the bandwidth
increase procedure detailed in [RFC3209]. This behavior is directly increase procedure detailed in [RFC3209]. This behavior is directly
implied to be correct in [RFC3209] and is often desirable from an implied to be correct in [RFC3209] and is often desirable from an
operator's perspective, because either a) the destination prefixes operator's perspective, because either a) the destination prefixes
are not reachable via any means other than MPLS or b) this would are not reachable via any means other than MPLS or b) this would
result in significant packet loss as demand is shifted to other LSPs result in significant packet loss as demand is shifted to other LSPs
in the overlay mesh. in the overlay mesh.
In addition, there are currently few implementations offering dynamic In addition, there are currently few implementations offering dynamic
ingress admission control (policing of the traffic volume mapped onto ingress admission control (policing of the traffic volume mapped onto
an LSP) at the LER. Having ingress admission control on a per LSP an LSP) at the label edge router (LER). Having ingress admission
basis is not necessarily desirable from an operational perspective, control on a per LSP basis is not necessarily desirable from an
as a) one must over-provision tunnels significantly in order to avoid operational perspective, as a) one must over-provision tunnels
deleterious effects resulting from stacked transport and flow control significantly in order to avoid deleterious effects resulting from
systems (for example for tunnels that are dynamically resized based stacked transport and flow control systems (for example for tunnels
on current traffic) and b) there is currently no efficient commonly that are dynamically resized based on current traffic) and b) there
available northbound interface for dynamic configuration of per LSP is currently no efficient commonly available northbound interface for
ingress admission control. dynamic configuration of per LSP ingress admission control.
Lack of ingress admission control coupled with the behavior in Lack of ingress admission control coupled with the behavior in
[RFC3209] may result in LSPs operating out of profile for significant [RFC3209] may result in LSPs operating out of profile for significant
periods of time. It is reasonable to expect that these out-of- periods of time. It is reasonable to expect that these out-of-
profile LSPs will be operating in a degraded state and experience profile LSPs will be operating in a degraded state and experience
traffic loss, but because they end up sharing common network traffic loss, but because they end up sharing common network
interfaces with other LSPs operating within their bandwidth interfaces with other LSPs operating within their bandwidth
reservations, thus impacting the operation of the in-profile LSPs, reservations, thus impacting the operation of the in-profile LSPs,
even when there is unused network capacity elsewhere in the network. even when there is unused network capacity elsewhere in the network.
Furthermore, this behavior will cause information loss in the TED Furthermore, this behavior will cause information loss in the TED
skipping to change at page 13, line 41 skipping to change at page 13, line 41
with knowledge of all LSPs in the domain and in the ability to with knowledge of all LSPs in the domain and in the ability to
trigger bandwidth modification of the LSP. trigger bandwidth modification of the LSP.
5.3. Bandwidth Scheduling 5.3. Bandwidth Scheduling
Bandwidth scheduling allows network operators to reserve resources in Bandwidth scheduling allows network operators to reserve resources in
advance according to the agreements with their customers, and allow advance according to the agreements with their customers, and allow
them to transmit data with specified starting time and duration, for them to transmit data with specified starting time and duration, for
example for a scheduled bulk data replication between data centers. example for a scheduled bulk data replication between data centers.
Traditionally, this can be supported by NMS operation through path Traditionally, this can be supported by network management system
pre-establishment and activation on the agreed starting time. (NMS) operation through path pre-establishment and activation on the
However, this does not provide efficient network usage since the agreed starting time. However, this does not provide efficient
established paths exclude the possibility of being used by other network usage since the established paths exclude the possibility of
services even when they are not used for undertaking any service. It being used by other services even when they are not used for
can also be accomplished through GMPLS protocol extensions by undertaking any service. It can also be accomplished through GMPLS
carrying the related request information (e.g., starting time and protocol extensions by carrying the related request information
duration) across the network. Nevertheless, this method inevitably (e.g., starting time and duration) across the network. Nevertheless,
increases the complexity of signaling and routing process. this method inevitably increases the complexity of signaling and
routing process.
A passive stateful PCE can support this application with better A passive stateful PCE can support this application with better
efficiency since it can alleviate the burden of processing on network efficiency since it can alleviate the burden of processing on network
elements. This requires the PCE to maintain the scheduled LSPs and elements. This requires the PCE to maintain the scheduled LSPs and
their associated resource usage, as well as the ability of head-ends their associated resource usage, as well as the ability of head-ends
to trigger signaling for LSP setup/deletion at the correct time. to trigger signaling for LSP setup/deletion at the correct time.
This approach requires coarse time synchronization between PCEs and This approach requires coarse time synchronization between PCEs and
PCCs. If an active stateful PCE is available, the PCE can trigger PCCs. If an active stateful PCE is available, the PCE can trigger
the setup/deletion of scheduled requests in a centralized manner, the setup/deletion of scheduled requests in a centralized manner,
without modification of existing head-end behaviors, by notifying the without modification of existing head-end behaviors, by notifying the
skipping to change at page 16, line 5 skipping to change at page 16, line 5
accessible by the stateful PCE. accessible by the stateful PCE.
5.4.2. Restoration 5.4.2. Restoration
In case of a link failure, such as a fiber cut, multiple LSPs may In case of a link failure, such as a fiber cut, multiple LSPs may
fail at the same time. Thus, the source nodes of the affected LSPs fail at the same time. Thus, the source nodes of the affected LSPs
will be informed of the failure by the nodes detecting the failure. will be informed of the failure by the nodes detecting the failure.
These source nodes will send requests to a PCE for rerouting. In These source nodes will send requests to a PCE for rerouting. In
order to reuse the resource taken by an existing LSP, the source node order to reuse the resource taken by an existing LSP, the source node
can send a PCReq message including the Exclude Route Object (XRO) can send a PCReq message including the Exclude Route Object (XRO)
with Fail (F) bit set, together with the RRO object containing the with Fail (F) bit set, together with the record route object (RRO)
current route information, as specified in [RFC5521]. containing the current route information, as specified in [RFC5521].
If a stateless PCE is exploited, it might respond to the rerouting If a stateless PCE is exploited, it might respond to the rerouting
requests separately if they arrive at different times. Thus, it requests separately if they arrive at different times. Thus, it
might result in sub-optimal resource usage. Even worse, it might might result in sub-optimal resource usage. Even worse, it might
unnecessarily block some of the rerouting requests due to unnecessarily block some of the rerouting requests due to
insufficient resources for later-arrived rerouting messages. If a insufficient resources for later-arrived rerouting messages. If a
passive stateful PCE is used to fulfill this task, the procedure can passive stateful PCE is used to fulfill this task, the procedure can
be simplified. The PCCs reporting the failures can include LSP be simplified. The PCCs reporting the failures can include LSP
identifiers instead of detailed information and the PCE can find identifiers instead of detailed information and the PCE can find
relevant LSP information by inspecting the LSP-DB. Moreover, the PCE relevant LSP information by inspecting the LSP-DB. Moreover, the PCE
skipping to change at page 20, line 41 skipping to change at page 20, line 41
path control, result in more information being available for a path control, result in more information being available for a
hypothetical adversary and a number of additional attack surfaces hypothetical adversary and a number of additional attack surfaces
which must be protected. [I-D.ietf-pce-stateful-pce] discusses which must be protected. [I-D.ietf-pce-stateful-pce] discusses
different attack vectors and defines protocol mechanisms to protect different attack vectors and defines protocol mechanisms to protect
against them. It also lays out implementation requirements for against them. It also lays out implementation requirements for
configuration capabilities that allow the operator to control the PCC configuration capabilities that allow the operator to control the PCC
behavior when faced with an attack. This document does not introduce behavior when faced with an attack. This document does not introduce
any new security considerations beyond those discussed in any new security considerations beyond those discussed in
[I-D.ietf-pce-stateful-pce]. [I-D.ietf-pce-stateful-pce].
7. Contributing Authors 7. IANA Considerations
This document does not require any IANA action.
8. Contributing Authors
The following people all contributed significantly to this document The following people all contributed significantly to this document
and are listed below in alphabetical order: and are listed below in alphabetical order:
Ramon Casellas Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7 Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860 Castelldefels, Barcelona 08860
Spain Spain
Email: ramon.casellas@cttc.es Email: ramon.casellas@cttc.es
skipping to change at page 21, line 4 skipping to change at page 21, line 8
The following people all contributed significantly to this document The following people all contributed significantly to this document
and are listed below in alphabetical order: and are listed below in alphabetical order:
Ramon Casellas Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7 Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860 Castelldefels, Barcelona 08860
Spain Spain
Email: ramon.casellas@cttc.es Email: ramon.casellas@cttc.es
Edward Crabbe Edward Crabbe
Google, Inc. Email: edward.crabbe@gmail.com
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: edc@google.com
Dhruv Dhody Dhruv Dhody
Huawei Technology Huawei Technology
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
EMail: dhruv.dhody@huawei.com EMail: dhruv.dhody@huawei.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo Telefonica Investigacion y Desarrollo
skipping to change at page 22, line 12 skipping to change at page 22, line 13
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Xiaobing Zi Xiaobing Zi
Email: unknown Email: unknown
8. Acknowledgements 9. Acknowledgements
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and
Ravi Torvi for the useful comments and discussions. Ravi Torvi for the useful comments and discussions.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-pce-questions] [I-D.ietf-pce-questions]
Farrel, A. and D. King, "Unanswered Questions in the Path Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", draft-ietf-pce- Computation Element Architecture", draft-ietf-pce-
questions-06 (work in progress), June 2014. questions-08 (work in progress), October 2014.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-08 (work in progress), February 2014. pce-09 (work in progress), June 2014.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March (PCE) Communication Protocol (PCEP)", RFC 5440, March
2009. 2009.
9.2. Informative References 10.2. Informative References
[I-D.ietf-ccamp-flexi-grid-fwk] [I-D.ietf-ccamp-flexi-grid-fwk]
Dios, O., Casellas, R., Zhang, F., Fu, X., Ceccarelli, D., Dios, O., Casellas, R., Zhang, F., Fu, X., Ceccarelli, D.,
and I. Hussain, "Framework and Requirements for GMPLS and I. Hussain, "Framework and Requirements for GMPLS
based control of Flexi-grid DWDM networks", draft-ietf- based control of Flexi-grid DWDM networks", draft-ietf-
ccamp-flexi-grid-fwk-01 (work in progress), February 2014. ccamp-flexi-grid-fwk-02 (work in progress), August 2014.
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te] [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]
Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu,
"OSPF-TE Extensions for General Network Element "OSPF-TE Extensions for General Network Element
Constraints", draft-ietf-ccamp-gmpls-general-constraints- Constraints", draft-ietf-ccamp-gmpls-general-constraints-
ospf-te-08 (work in progress), May 2014. ospf-te-08 (work in progress), May 2014.
[I-D.ietf-ccamp-wson-signal-compatibility-ospf] [I-D.ietf-ccamp-wson-signal-compatibility-ospf]
Lee, Y. and G. Bernstein, "GMPLS OSPF Enhancement for Lee, Y. and G. Bernstein, "GMPLS OSPF Enhancement for
Signal and Network Element Compatibility for Wavelength Signal and Network Element Compatibility for Wavelength
Switched Optical Networks", draft-ietf-ccamp-wson-signal- Switched Optical Networks", draft-ietf-ccamp-wson-signal-
compatibility-ospf-15 (work in progress), May 2014. compatibility-ospf-15 (work in progress), May 2014.
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-10 (work in
progress), February 2014. progress), October 2014.
[I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-01 (work in
progress), June 2014.
[I-D.sivabalan-pce-disco-stateful] [I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", draft-sivabalan-pce-disco- for Stateful PCE Discovery", draft-sivabalan-pce-disco-
stateful-03 (work in progress), January 2014. stateful-03 (work in progress), January 2014.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global Information
Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", pre-
print, 2011.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
Recovery: Protection and Restoration of Optical, SONET-
SDH, IP, and MPLS", The Morgan Kaufmann Series in
Networking, June 2004.
[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.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006. Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
 End of changes. 26 change blocks. 
83 lines changed or deleted 82 lines changed or added

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