draft-ietf-pce-p2mp-app-01.txt   draft-ietf-pce-p2mp-app-02.txt 
Network Working Group S. Yasukawa Network Working Group S. Yasukawa
Internet Draft NTT Internet Draft NTT
Category: Informational A. Farrel (Editor) Category: Informational A. Farrel (Editor)
Created: February 13, 2009 Old Dog Consulting Created: August 17, 2009 Old Dog Consulting
Expires: August 13, 2009 Expires: February 17, 2010
Applicability of the Path Computation Element (PCE) to Applicability of the Path Computation Element (PCE) to
Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering (TE) and Generalized MPLS (GMPLS) Traffic Engineering (TE)
draft-ietf-pce-p2mp-app-01.txt draft-ietf-pce-p2mp-app-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
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), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
skipping to change at page 2, line 12 skipping to change at page 2, line 12
motivation for using a PCE to compute these paths, and examines which motivation for using a PCE to compute these paths, and examines which
of the PCE architectural models are appropriate. of the PCE architectural models are appropriate.
Table of Contents Table of Contents
1. Introduction ................................................... 3 1. Introduction ................................................... 3
2. Architectural Considerations ................................... 4 2. Architectural Considerations ................................... 4
2.1. Offline Computation .......................................... 4 2.1. Offline Computation .......................................... 4
2.2. Online Computation ........................................... 4 2.2. Online Computation ........................................... 4
2.2.1. LSR Loading ................................................ 5 2.2.1. LSR Loading ................................................ 5
2.2.2. PCE Congestion ............................................. 6 2.2.2. PCE Overload ............................................... 6
2.2.3. PCE Capabilities ........................................... 6 2.2.3. PCE Capabilities ........................................... 6
3. Fragmenting the P2MP Tree ...................................... 7 3. Fragmenting the P2MP Tree ...................................... 7
4. Central Replication Points ..................................... 8 4. Central Replication Points ..................................... 8
5. Reoptimization and Modification ................................ 9 5. Reoptimization and Modification ................................ 9
6. Repair ........................................................ 10 6. Repair ........................................................ 10
7. Disjoint Paths ................................................ 11 7. Disjoint Paths ................................................ 11
8. Manageability Considerations .................................. 11 8. Manageability Considerations .................................. 11
8.1. Control of Function and Policy .............................. 11 8.1. Control of Function and Policy .............................. 11
8.2. Information and Data Models ................................. 12 8.2. Information and Data Models ................................. 12
8.3. Liveness Detection and Monitoring ........................... 12 8.3. Liveness Detection and Monitoring ........................... 12
8.4. Verifying Correct Operation ................................. 12 8.4. Verifying Correct Operation ................................. 12
8.5. Requirements on Other Protocols and Functional Components ... 12 8.5. Requirements on Other Protocols and Functional Components ... 12
8.6. Impact on Network Operation ................................. 13 8.6. Impact on Network Operation ................................. 13
9. Security Considerations ....................................... 13 9. Security Considerations ....................................... 13
10. IANA Considerations .......................................... 13 10. IANA Considerations .......................................... 13
11. Acknowledgments .............................................. 13 11. Acknowledgments .............................................. 13
12. References ................................................... 13 12. References ................................................... 14
12.1. Normative Reference ........................................ 13 12.1. Normative Reference ........................................ 14
12.2. Informative Reference ...................................... 14 12.2. Informative Reference ...................................... 14
13. Authors' Addresses ........................................... 15 13. Authors' Addresses ........................................... 15
14. Intellectual Property Statement .............................. 15 14. Full Copyright Statement ..................................... 15
15. Full Copyright Statement ..................................... 16
1. Introduction 1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. The intention network graph, and applying computational constraints. The intention
is that the PCE is used to compute the path of Traffic Engineered is that the PCE is used to compute the path of Traffic Engineered
Label Switched Paths (TE LSPs) within Multiprotocol Label Switching Label Switched Paths (TE LSPs) within Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks. (MPLS) and Generalized MPLS (GMPLS) networks.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
high-capacity to perform P2MP computations, this is not an acceptable high-capacity to perform P2MP computations, this is not an acceptable
solution because in all other senses, the ingress to a P2MP LSP is solution because in all other senses, the ingress to a P2MP LSP is
just a normal ingress LSR. just a normal ingress LSR.
Thus, there is an obvious solution which is to off-load P2MP path Thus, there is an obvious solution which is to off-load P2MP path
computations from LSRs to remotely located PCEs. Such PCE function computations from LSRs to remotely located PCEs. Such PCE function
can be provided on dedicated or high-capacity network elements (such can be provided on dedicated or high-capacity network elements (such
as dedicated servers, or high-end routers that might be located as as dedicated servers, or high-end routers that might be located as
Autonomous System Border Routers - ASBRs). Autonomous System Border Routers - ASBRs).
2.2.2. PCE Congestion 2.2.2. PCE Overload
Since P2MP path computations are resource-intensive, it may be that Since P2MP path computations are resource-intensive, it may be that
the introduction of P2MP LSPs into an established PCE network will the introduction of P2MP LSPs into an established PCE network will
cause congestion at the PCEs. That is, the P2MP computations may cause overload at the PCEs. That is, the P2MP computations may block
block other P2P computations and might even overload the PCE. other P2P computations and might even overload the PCE.
Several measures can be taken within the PCE architecture to Several measures can be taken within the PCE architecture to
alleviate this situation as described in [RFC4655]. For example, path alleviate this situation as described in [RFC4655]. For example, path
computation requests can be assigned priorities by the LSRs that computation requests can be assigned priorities by the LSRs that
issue them. Thus, the LSRs could assign lower priority to the P2MP issue them. Thus, the LSRs could assign lower priority to the P2MP
requests ensuring that P2P requests were serviced in preference. requests ensuring that P2P requests were serviced in preference.
Furthermore, the PCEs are able to apply local and network-wide policy Furthermore, the PCEs are able to apply local and network-wide policy
and this may dictate specific processing rules [RFC5394]. and this may dictate specific processing rules [RFC5394].
But ultimately a network must possess sufficient path computation But ultimately a network must possess sufficient path computation
resources for its needs and this is achieved within the PCE resources for its needs and this is achieved within the PCE
architecture simply by increasing the number of PCEs. architecture simply by increasing the number of PCEs.
Once there are sufficient PCEs available within the network, the LSRs Once there are sufficient PCEs available within the network, the LSRs
may choose between them, and may use congestion notification may choose between them, and may use overload notification
information supplied by the PCEs to spot which PCEs are currently information supplied by the PCEs to spot which PCEs are currently
over-loaded. Additionally, a PCE that is becoming over-loaded may over-loaded. Additionally, a PCE that is becoming over-loaded may
redistribute its queue of computation requests to other less-burdened redistribute its queue of computation requests to other less-burdened
PCEs within the network using the PCE cooperation model described in PCEs within the network using the PCE cooperation model described in
[RFC4655]. [RFC4655].
2.2.3. PCE Capabilities 2.2.3. PCE Capabilities
An LSR chooses between available PCEs to select the one most likely An LSR chooses between available PCEs to select the one most likely
to be able to perform the requested path computation. This selection to be able to perform the requested path computation. This selection
may be based on congestion notifications from the PCEs, but could may be based on overload notifications from the PCEs, but could also
also consider other computational capabilities. consider other computational capabilities.
For example, it is quite likely that only a subset of the PCEs in the For example, it is quite likely that only a subset of the PCEs in the
network have the ability to perform P2MP computations since this network have the ability to perform P2MP computations since this
requires advanced functionality. Some of those PCEs might have the requires advanced functionality. Some of those PCEs might have the
ability to satisfy certain objective functions (for example, least ability to satisfy certain objective functions (for example, least
cost to destination), but lack support for other objective functions cost to destination), but lack support for other objective functions
(for example Steiner). Additionally, some PCEs might not be capable (for example Steiner). Additionally, some PCEs might not be capable
of the more complex P2MP reoptimization functionality. of the more complex P2MP reoptimization functionality.
The PCE architecture allows an LSR to discover the capabilities of The PCE architecture allows an LSR to discover the capabilities of
the PCEs within the network at the same time as it discovers their the PCEs within the network at the same time as it discovers their
existence. Further and more detailed exchanges of PCE capabilities existence. Further and more detailed exchanges of PCE capabilities
can be made directly between the PCEs and the LSRs. can be made directly between the PCEs and the LSRs. This exchange of
PCE capabilities information allows a Path Computation Client (PCC)
to select thePCE that can best answer its computation requests.
3. Fragmenting the P2MP Tree 3. Fragmenting the P2MP Tree
A way to reduce the computational burden on a single PCE of computing A way to reduce the computational burden on a single PCE of computing
a large P2MP tree is to fragment or partition the tree. This may be a large P2MP tree is to fragment or partition the tree. This may be
particularly obvious in a multi-domain network (such as multiple particularly obvious in a multi-domain network (such as multiple
routing areas), but is equally applicable in a single domain. routing areas), but is equally applicable in a single domain.
Consider the network topology in Figure 1. A P2MP LSP is required Consider the network topology in Figure 1. A P2MP LSP is required
from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z. Using a from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z. Using a
skipping to change at page 8, line 30 skipping to change at page 8, line 30
M--r--y M--r--y
\ \ \ \
\ \ \ \
s z s z
Figure 1 : A P2MP Tree with Intermediate Computation Points Figure 1 : A P2MP Tree with Intermediate Computation Points
A further possibility is that LSRs at which the subtrees are stitched A further possibility is that LSRs at which the subtrees are stitched
together (K, L, and M in this example) are selected from a set of together (K, L, and M in this example) are selected from a set of
potential such points using a cooperative PCE technique such as the potential such points using a cooperative PCE technique such as the
Backward Recursive Path Computation (BRPC) mechanism [BRPC]. Indeed, Backward Recursive Path Computation (BRPC) mechanism [RFC5441].
if the LSRs K, L, and M were ASBRs or Area Border Routers (ABRs) the Indeed, if the LSRs K, L, and M were ASBRs or Area Border Routers
BRPC technique would be particularly applicable. (ABRs) the BRPC technique would be particularly applicable.
Note, however, that while these mechanisms are superficially Note, however, that while these mechanisms are superficially
beneficial, it is far from obvious how the first LSR selects the beneficial, it is far from obvious how the first LSR selects the
transit LSRs K, L, and M, nor how the leaf nodes are assigned to be transit LSRs K, L, and M, nor how the leaf nodes are assigned to be
downstream of particular downstream nodes. The computation to downstream of particular downstream nodes. The computation to
determine these questions may be no less intensive than the determine these questions may be no less intensive than the
determination of the full tree unless there is some known property of determination of the full tree unless there is some known property of
the leaf node identifiers such as might be provided by address the leaf node identifiers such as might be provided by address
aggregation. aggregation.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
be more complex. Additional constraints may be applied by the network be more complex. Additional constraints may be applied by the network
administrator so that only subsets of the egresses (or subtrees of administrator so that only subsets of the egresses (or subtrees of
the P2MP tree) are optimized at any time. In these cases, the the P2MP tree) are optimized at any time. In these cases, the
computational load of reoptimization may be considerable, but computational load of reoptimization may be considerable, but
fortunately reoptimization computations may be performed as fortunately reoptimization computations may be performed as
background activities. Splitting the P2MP tree into subtrees as background activities. Splitting the P2MP tree into subtrees as
described in Section 3 may further reduce the computation load and described in Section 3 may further reduce the computation load and
may assist with administrative preferences for partial tree may assist with administrative preferences for partial tree
reoptimization. reoptimization.
Network-wide reoptimization of multiple LSPs [GCO] can achieve far Network-wide reoptimization of multiple LSPs [RFC5557] can achieve
greater improvements in optimality within congested networks than can far greater improvements in optimality within overloaded networks
be achieved by reoptimizing LSPs sequentially. Such computation would than can be achieved by reoptimizing LSPs sequentially. Such
typically be performed offline and would usually require a dedicated computation would typically be performed offline and would usually
processor such as a PCE invoked by the NMS. require a dedicated processor such as a PCE invoked by the NMS.
6. Repair 6. Repair
LSP repair is necessary when a network fault disrupts the ability of LSP repair is necessary when a network fault disrupts the ability of
the LSP to deliver data to an egress. For a P2MP LSP, a network fault the LSP to deliver data to an egress. For a P2MP LSP, a network fault
is (statistically) likely to only impact a small subset of the total is (statistically) likely to only impact a small subset of the total
set of egresses. Repair activity, therefore, does not need to set of egresses. Repair activity, therefore, does not need to
recompute the path of the entire P2MP tree. Rather, it needs to recompute the path of the entire P2MP tree. Rather, it needs to
quickly find suitable new branches that can be grafted onto the quickly find suitable new branches that can be grafted onto the
existing tree to reconnect the disconnected leaves. existing tree to reconnect the disconnected leaves.
skipping to change at page 11, line 41 skipping to change at page 11, line 41
complexity. The computation of disjoint P2MP paths is considerably complexity. The computation of disjoint P2MP paths is considerably
more difficult and is therefore a good candidate to be offloaded to a more difficult and is therefore a good candidate to be offloaded to a
PCE that has dedicated resources. In fact, it may well be the case PCE that has dedicated resources. In fact, it may well be the case
that not all P2MP-capable PCEs can handle disjoint path requests and that not all P2MP-capable PCEs can handle disjoint path requests and
it may be necessary to select between PCEs based on their it may be necessary to select between PCEs based on their
capabilities. capabilities.
8. Manageability Considerations 8. Manageability Considerations
The use of PCE to compute P2MP paths has many of the same The use of PCE to compute P2MP paths has many of the same
manageability considerations as when it is used for P2P LSPs. There manageability considerations as when it is used for P2P LSPs
may be additional manageability implications for the size of P2MP [RFC5440]. There may be additional manageability implications for the
computation requests and the additional loading exerted on the PCEs. size of P2MP computation requests and the additional loading exerted
on the PCEs.
8.1. Control of Function and Policy 8.1. Control of Function and Policy
As already described, individual PCEs may choose to not be capable of As already described, individual PCEs may choose to not be capable of
P2MP computation, and where this function is available, it may be P2MP computation, and where this function is available, it may be
disabled by an operator, or may be automatically withdrawn when the disabled by an operator, or may be automatically withdrawn when the
PCE becomes loaded or based on other policy considerations. PCE becomes loaded or based on other policy considerations.
Further, a PCE may refuse any P2MP computation request or pass it on Further, a PCE may refuse any P2MP computation request or pass it on
to another PCE based on policy. to another PCE based on policy.
8.2. Information and Data Models 8.2. Information and Data Models
P2MP computation requests necessitate considerably more information P2MP computation requests necessitate considerably more information
exchange between the LSR and the PCE than is required for P2P exchange between the LSR and the PCE than is required for P2P
computations. This will result in much larger data sets to be computations. This will result in much larger data sets to be
controlled and modeled and will impact the utility of any management controlled and modeled, and will impact the utility of any management
data models, such as MIB modules. data models, such as MIB modules. Care needs to be taken in the
design of such data models, and the use of other management protocols
and data modelling structures, such as NETCONF / NETMOD [RFC4741]
could be considered.
8.3. Liveness Detection and Monitoring 8.3. Liveness Detection and Monitoring
PCE liveness detection and monitoring is unchanged from P2P PCE liveness detection and monitoring is unchanged from P2P
operation, but it should be noted that P2MP requests will take longer operation, but it should be noted that P2MP requests will take longer
to process than P2P requests meaning that the time between request to process than P2P requests meaning that the time between request
and response will be, on average, longer. this increases the chance and response will be, on average, longer. This increases the chance
of a communications failure between request and response and means of a communications failure between request and response and means
that liveness detection is more important. that liveness detection is more important.
8.4. Verifying Correct Operation 8.4. Verifying Correct Operation
Correct operation of any communication between LSRs and PCEs is Correct operation of any communication between LSRs and PCEs is
exactly as important as it is for P2P computations. exactly as important as it is for P2P computations.
The correct operation of path computation algorithms implemented at The correct operation of path computation algorithms implemented at
PCEs is out of scope, but nervous LSRs may make identical requests PCEs is out of scope, but LSRs that are concerned that PCE algorithms
to separate PCEs and compare the responses. might not be operating correctly may make identical requests to
separate PCEs and compare the responses.
8.5. Requirements on Other Protocols and Functional Components 8.5. Requirements on Other Protocols and Functional Components
As is clear from the PCE architecture, a communications protocol is As is clear from the PCE architecture, a communications protocol is
necessary to allow LSRs to send computation requests to PCEs, and for necessary to allow LSRs to send computation requests to PCEs, and for
PCEs to cooperate. Requirements for such a protocol to handle P2P PCEs to cooperate. Requirements for such a protocol to handle P2P
path computations are described in [RFC4657] and additional path computations are described in [RFC4657] and additional
requirements in support of P2MP computations are described in requirements in support of P2MP computations are described in
[PCE-P2MP-REQ]. The PCE Communication Protocol (PCEP) is defined in [PCE-P2MP-REQ]. The PCE Communication Protocol (PCEP) is defined in
[PCEP], but extensions will be necessary to support P2MP computation [RFC5440], but extensions will be necessary to support P2MP
requests. computation requests.
As described in the body of this document, LSRs need to be able to As described in the body of this document, LSRs need to be able to
recognize which PCEs can perform P2MP computations. Capability recognize which PCEs can perform P2MP computations. Capability
advertisement is already present in the PCE Discovery protocols advertisement is already present in the PCE Discovery protocols
[RFC5088] and [RFC5089], and can also be exchanged in PCEP [PCEP], [RFC5088] and [RFC5089], and can also be exchanged in PCEP [RFC5440],
but extensions will be required to describe P2MP capabilities. but extensions will be required to describe P2MP capabilities.
As also described in this document, the PCE needs to know the branch As also described in this document, the PCE needs to know the branch
capabilities of the LSRs and store this information in the TED. This capabilities of the LSRs and store this information in the TED. This
information can be distributed using the routing protocols as information can be distributed using the routing protocols as
described in [RFC5073]. described in [RFC5073].
8.6. Impact on Network Operation 8.6. Impact on Network Operation
The use of a PCE to perform P2MP computations may have a beneficial The use of a PCE to perform P2MP computations may have a beneficial
skipping to change at page 13, line 29 skipping to change at page 13, line 33
The use of PCE to compute P2MP paths does not raise any additional The use of PCE to compute P2MP paths does not raise any additional
security issues beyond those that generally apply to the PCE security issues beyond those that generally apply to the PCE
architecture. See [RFC4655] for a full discussion. architecture. See [RFC4655] for a full discussion.
Note, however, that P2MP computation requests are more CPU-intensive Note, however, that P2MP computation requests are more CPU-intensive
and also use more link bandwidth. Therefore if the PCE was attacked and also use more link bandwidth. Therefore if the PCE was attacked
by the injection of spurious path computation requests, it would be by the injection of spurious path computation requests, it would be
more vulnerable through a smaller number of such requests. more vulnerable through a smaller number of such requests.
It would be possible to consider applying different authorization Thus, the use of message integrity and authentication mechanisms
policies for P2MP path computation requests compared to other within the PCE protocol should be used to mitigate attacks from
requests. devices that are not authorized to send requests to the PCE. It would
be possible to consider applying different authorization policies for
P2MP path computation requests compared to other requests.
10. IANA Considerations 10. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Jerry Ash and Jean-Louis Le Roux for The authors would like to thank Jerry Ash and Jean-Louis Le Roux for
their thoughtful comments. their thoughtful comments. Lars Eggert, Dan Romascanu, and Tim Polk
provided useful comments during IESG review.
12. References 12. References
12.1. Normative Reference 12.1. Normative Reference
[RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path
Computation Element (PCE)-Based Architecture", Computation Element (PCE)-Based Architecture",
RFC 4655, August 2006. RFC 4655, August 2006.
12.2. Informative Reference 12.2. Informative Reference
[RFC4461] S. Yasukawa, Editor, "Signaling Requirements for [RFC4461] S. Yasukawa, Editor, "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs", Point-to-Multipoint Traffic Engineered MPLS LSPs",
RFC4461, April 2006. RFC4461, April 2006.
[RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element
(PCE) Communication Protocol Generic Requirements", (PCE) Communication Protocol Generic Requirements",
RFC 4657, September 2006. RFC 4657, September 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC4834] Morin, T., "Requirements for Multicast in Layer 3 [RFC4834] Morin, T., "Requirements for Multicast in Layer 3
Provider-Provisioned Virtual Private Networks Provider-Provisioned Virtual Private Networks
(PPVPNs)", RFC 4834, April 2007. (PPVPNs)", RFC 4834, April 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing [RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing
skipping to change at page 14, line 41 skipping to change at page 15, line 5
Discovery", RFC 5088, January 2008. Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, J.L., and Vasseur, J.P., Editors, "IS-IS [RFC5089] Le Roux, J.L., and Vasseur, J.P., Editors, "IS-IS
Protocol Extensions for Path Computation Element (PCE) Protocol Extensions for Path Computation Element (PCE)
Discovery", RFC 5089, January 2008. Discovery", RFC 5089, January 2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash,
J., "Policy-Enabled Path Computation Framework", J., "Policy-Enabled Path Computation Framework",
RFC 5394, December 2008. RFC 5394, December 2008.
[BRPC] J.P. Vasseur, Editor, "A Backward Recursive PCE-based [RFC5440] Vasseur, J.P, and Le Roux, J.L., Editors, "Path
Computation (BRPC) procedure to compute shortest Computation Element (PCE) Communication Protocol
inter-domain Traffic Engineering Label Switched (PCEP)", RFC 5440, March 2009.
Paths", draft-ietf-pce-brpc, work in progress.
[GCO] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path [RFC5441] J.P. Vasseur, Editor, "A Backward-Recursive PCE-Based
Computation Element Communication Protocol (PCECP) Computation (BRPC) Procedure to Compute Shortest
Requirements and Protocol Extensions In Support of Constrained Inter-Domain Traffic Engineering Label
Global Concurrent Optimization", draft-ietf-pce- Switched Paths", RFC 5441, April 2009.
global-concurrent-optimization, work in progress.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of
Global Concurrent Optimization", RFC 5557, July 2009.
[PCE-P2MP-REQ] Yasukawa, S., and Farrel, A., "PCC-PCE Communication [PCE-P2MP-REQ] Yasukawa, S., and Farrel, A., "PCC-PCE Communication
Requirements for Point to Multipoint Multiprotocol Requirements for Point to Multipoint Multiprotocol
Label Switching Traffic Engineering (MPLS-TE)", Label Switching Traffic Engineering (MPLS-TE)",
draft-yasukawa-pce-p2mp-req, work in progress. draft-yasukawa-pce-p2mp-req, work in progress.
[PCEP] Vasseur, J.P, and Le Roux, J.L., Editors, "Path
Computation Element (PCE) communication Protocol
(PCEP) - Version 1", draft-ietf-pce-pcep, work in
progress.
13. Authors' Addresses 13. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
(R&D Strategy Department) 9-11, Midori-Cho 3-Chome
3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan Musashino-Shi, Tokyo 180-8585,
Phone: +81 3 5205 5341 Japan
Email: s.yasukawa@hco.ntt.co.jp Email: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
14. Intellectual Property Statement 14. Full Copyright Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
15. Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
 End of changes. 29 change blocks. 
103 lines changed or deleted 71 lines changed or added

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