draft-ietf-pce-p2mp-app-00.txt   draft-ietf-pce-p2mp-app-01.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: August 8, 2008 Old Dog Consulting Created: February 13, 2009 Old Dog Consulting
Expires: February 8, 2009 Expires: August 13, 2009
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-00.txt draft-ietf-pce-p2mp-app-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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-Drafts. Internet-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."
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Extensions to the MPLS and GMPLS signaling and routing protocols have Extensions to the MPLS and GMPLS signaling and routing protocols have
been made in support of point-to-multipoint (P2MP) Traffic Engineered been made in support of point-to-multipoint (P2MP) Traffic Engineered
(TE) Label Switched Paths (LSPs). (TE) Label Switched Paths (LSPs).
This document examines the applicability of PCE to path computation This document examines the applicability of PCE to path computation
for P2MP TE LSPs in MPLS and GMPLS networks. It describes the for P2MP TE LSPs in MPLS and GMPLS networks. It describes the
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
1. Introduction ................................................... 3
2. Architectural Considerations ................................... 4
2.1. Offline Computation .......................................... 4
2.2. Online Computation ........................................... 4
2.2.1. LSR Loading ................................................ 5
2.2.2. PCE Congestion ............................................. 6
2.2.3. PCE Capabilities ........................................... 6
3. Fragmenting the P2MP Tree ...................................... 7
4. Central Replication Points ..................................... 8
5. Reoptimization and Modification ................................ 9
6. Repair ........................................................ 10
7. Disjoint Paths ................................................ 11
8. Manageability Considerations .................................. 11
8.1. Control of Function and Policy .............................. 11
8.2. Information and Data Models ................................. 12
8.3. Liveness Detection and Monitoring ........................... 12
8.4. Verifying Correct Operation ................................. 12
8.5. Requirements on Other Protocols and Functional Components ... 12
8.6. Impact on Network Operation ................................. 13
9. Security Considerations ....................................... 13
10. IANA Considerations .......................................... 13
11. Acknowledgments .............................................. 13
12. References ................................................... 13
12.1. Normative Reference ........................................ 13
12.2. Informative Reference ...................................... 14
13. Authors' Addresses ........................................... 15
14. Intellectual Property 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.
[RFC4655] defines various deployment models that place PCEs [RFC4655] defines various deployment models that place PCEs
differently within the network. The PCEs may be colocated with the differently within the network. The PCEs may be collocated with the
Label Switching Routers (LSRs), may be part of the management system Label Switching Routers (LSRs), may be part of the management system
that requests the LSPs to be established, or may be positioned as one that requests the LSPs to be established, or may be positioned as one
or more computation servers within the network. or more computation servers within the network.
Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
documented in [RFC4461] and signaling protocol extensions for documented in [RFC4461] and signaling protocol extensions for
setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE
networks are considered in support of various features including networks are considered in support of various features including
layer 3 multicast VPNs [RFC4834], video distribution, etc. layer 3 multicast VPNs [RFC4834], video distribution, etc.
Fundamental to the determination of the paths for P2MP LSPs within a Fundamental to the determination of the paths for P2MP LSPs within a
network is the selection of branch points. Not only is this selection network is the selection of branch points. Not only is this selection
constrainted by the network topology and available network resources, constrained by the network topology and available network resources,
but it is determined by the objective functions that may be applied but it is determined by the objective functions that may be applied
to path computation. For example, one standard objective is to to path computation. For example, one standard objective is to
minimize the total cost of the tree (that is, to minimize the sum of minimize the total cost of the tree (that is, to minimize the sum of
the costs of each link traversed by the tree) to produce what is the costs of each link traversed by the tree) to produce what is
known as a Steiner Tree. Another common objective function requires known as a Steiner Tree. Another common objective function requires
that the cost to reach each leaf of the P2MP tree is minimized. that the cost to reach each leaf of the P2MP tree is minimized.
The selection of branch points within the network is further The selection of branch points within the network is further
complicated by the fact that not all LSRs in the network are complicated by the fact that not all LSRs in the network are
necessarily capable of performing branching functions. This necessarily capable of performing branching functions. This
skipping to change at page 2, line 54 skipping to change at page 4, line 5
Additionally, network policies may dictate specific branching Additionally, network policies may dictate specific branching
behavior. For example, it may be decided that for certain types of behavior. For example, it may be decided that for certain types of
LSP in certain types of network, it is important that no branch LSR LSP in certain types of network, it is important that no branch LSR
is responsible for handling more than a certain number of downstream is responsible for handling more than a certain number of downstream
branches for any one LSP. This might arise because the replication branches for any one LSP. This might arise because the replication
mechanism used at the LSRs is a round-robin copying process that mechanism used at the LSRs is a round-robin copying process that
delays the data transmission on each downstream branch by the time delays the data transmission on each downstream branch by the time
taken to replicate the data onto each previous downstream branch. taken to replicate the data onto each previous downstream branch.
Alternatively, administrative policies may dictate that replication Alternatively, administrative policies may dictate that replication
should be concentrated on specific key replication nodes behaving should be concentrated on specific key replication nodes behaving
like IP mlticast rendezvous points (perhaps to ensure appropriate like IP multicast rendezvous points (perhaps to ensure appropriate
policing of receivers in the P2MP tree, or perhaps to make protection policing of receivers in the P2MP tree, or perhaps to make protection
and resilliency easier to implement). and resiliency easier to implement).
Path computation for P2MP TE LSPs presents a significant challenge Path computation for P2MP TE LSPs presents a significant challenge
because of the complexity of the computations described above. because of the complexity of the computations described above.
Determining disjoint protection paths for P2MP TE LSPs can add Determining disjoint protection paths for P2MP TE LSPs can add
considerably to this complexity, while small modifications to a P2MP considerably to this complexity, while small modifications to a P2MP
tree (such as adding or removing just one leaf) can completely change tree (such as adding or removing just one leaf) can completely change
the optimal path. Reoptimization of a network containing multiple the optimal path. Reoptimization of a network containing multiple
P2MP TE LSPs requires considerable computational resources. All of P2MP TE LSPs requires considerable computational resources. All of
this means that an ingress LSR might not have sufficient processing this means that an ingress LSR might not have sufficient processing
power to perform the necessary computations, and even if it does, the power to perform the necessary computations, and even if it does, the
skipping to change at page 3, line 52 skipping to change at page 5, line 6
placements are significantly sub-optimal. See Section 5 for further placements are significantly sub-optimal. See Section 5 for further
discussions of reoptimization. discussions of reoptimization.
2.2. Online Computation 2.2. Online Computation
Online path computation is performed on-demand as LSRs in the network Online path computation is performed on-demand as LSRs in the network
determine that they need to know the paths to use for LSPs. Thus, determine that they need to know the paths to use for LSPs. Thus,
each computation is triggered by a request from an LSR. each computation is triggered by a request from an LSR.
As described in [RFC4655], the path computation function for online As described in [RFC4655], the path computation function for online
computation may be colocated with the LSR that makes the request, or computation may be collocated with the LSR that makes the request, or
may be present in a computation-capable PCE server within the may be present in a computation-capable PCE server within the
network. The PCE server may be another LSR in the network, a network. The PCE server may be another LSR in the network, a
dedicated server, or a functional component of an NMS. Furthermore, dedicated server, or a functional component of an NMS. Furthermore,
the computation is not necessarily achieved by a single PCE operating the computation is not necessarily achieved by a single PCE operating
on its own, but may be the result of cooperation between several on its own, but may be the result of cooperation between several
PCEs. PCEs.
The remainder of this document makes frequent reference to these The remainder of this document makes frequent reference to these
different online models in order to indicate which is more different online models in order to indicate which is more
appropriate in different P2MP scenarios. appropriate in different P2MP scenarios.
skipping to change at page 5, line 21 skipping to change at page 6, line 26
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 congestion at the PCEs. That is, the P2MP computations may
block other P2P computations and might even overload the PCE. block 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 [PCE-POLICY]. 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 congestion 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
skipping to change at page 6, line 13 skipping to change at page 7, line 20
can be made directly between the PCEs and the LSRs. can be made directly between the PCEs and the LSRs.
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 exgress LSRs s, t, u, v, w, x, y, and z. Using from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z. Using a
a single PCE model, LSR A may request the entire path of the tree and single PCE model, LSR A may request the entire path of the tree and
this may be supplied by the PCE. Alternatively, the PCE that is this may be supplied by the PCE. Alternatively, the PCE that is
consulted by LSR A may only compute the first fragment of the tree consulted by LSR A may only compute the first fragment of the tree
(for example from A to K, L, and M) and may rely on other PCEs to (for example from A to K, L, and M) and may rely on other PCEs to
compute the three smaller trees from K to t, u and v, from L to w and compute the three smaller trees from K to t, u and v, from L to w and
x, and from M to s, y, and z. x, and from M to s, y, and z.
The LSR consulted by A may simply return the first subtree and leave The LSR consulted by A may simply return the first subtree and leave
LSRs K, L, and M to invoke PCEs in their turn in order to complete LSRs K, L, and M to invoke PCEs in their turn in order to complete
the signaling. Alternatively, the first PCE may cooperate with other the signaling. Alternatively, the first PCE may cooperate with other
PCEs to collect the paths for the later subtrees and return them PCEs to collect the paths for the later subtrees and return them
in a single computaiton response to PCE A. The mechanisms for both of in a single computation response to PCE A. The mechanisms for both of
these approaches are described in the PCE architecture [RFC4655]. these approaches are described in the PCE architecture [RFC4655].
t t
/ /
/ /
n--u n--u
/ /
/ /
e--f--h--K--o--v e--f--h--K--o--v
/ /
skipping to change at page 6, line 50 skipping to change at page 8, line 27
j x j x
\ \
\ \
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 futher 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 [BRPC]. Indeed,
if the LSRs K, L, and M were ASBRs or Area Border Routers (ABRs) the if the LSRs K, L, and M were ASBRs or Area Border Routers (ABRs) the
BRPC technique would be particularly applicable. 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
skipping to change at page 7, line 25 skipping to change at page 9, line 5
4. Central Replication Points 4. Central Replication Points
A deployment model for P2MP LSPs is to use centralized, well-known A deployment model for P2MP LSPs is to use centralized, well-known
replication points. This choice may be made for administrative or replication points. This choice may be made for administrative or
security reasons, or because of particular hardware capability security reasons, or because of particular hardware capability
limitations within the network. Indeed, this deployment model can be limitations within the network. Indeed, this deployment model can be
achieved using P2P LSPs between ingress and replication point, and achieved using P2P LSPs between ingress and replication point, and
between replication point and each leaf so as to achieve a P2MP between replication point and each leaf so as to achieve a P2MP
service without the use of P2MP MPLS-TE. service without the use of P2MP MPLS-TE.
The motivations for this type of deployment are beyond the sope of The motivations for this type of deployment are beyond the scope of
this document, but it is appropriate to examine how PCE might be used this document, but it is appropriate to examine how PCE might be used
to support this model. to support this model.
In Figure 2, a P2MP service is required from ingress LSR a to egress In Figure 2, a P2MP service is required from ingress LSR a to egress
LSRs m, n, o, and p. There are four replication-capable LSRs in the LSRs m, n, o, and p. There are four replication-capable LSRs in the
network: D, E, J, and K. network: D, E, J, and K.
When LSR a consults a PCE it could be given the full P2MP path from When LSR a consults a PCE it could be given the full P2MP path from
LSR a to the leaves, but in this model, the PCE simply returns a P2P LSR a to the leaves, but in this model, the PCE simply returns a P2P
path to the first replication point (in this case LSR D). LSR D will path to the first replication point (in this case LSR D). LSR D will
skipping to change at page 7, line 52 skipping to change at page 9, line 32
/ /
/ /
a--b--c--D--g--J--n a--b--c--D--g--J--n
\ \ \ \
\ \ \ \
E h K o E h K o
\ \
\ \
l--p l--p
Figure 2 : Using Centralised Replication Points Figure 2 : Using Centralized Replication Points
In this model of operation it is quite likely that the PCE function In this model of operation it is quite likely that the PCE function
is located at the replication points which will be high-capacity is located at the replication points which will be high-capacity
LSRs. One of the main features of the computation activity is the LSRs. One of the main features of the computation activity is the
selection of the replicaiton points (for example, why is LSR D selection of the replication points (for example, why is LSR D
selected in preference to LSR E, and why is LSR J chosen over LSR selected in preference to LSR E, and why is LSR J chosen over LSR
K?). This selection may be made on solely on the basis of path K?). This selection may be made on solely on the basis of path
optimization as it would be for a P2MP computation, but may also be optimization as it would be for a P2MP computation, but may also be
influenced by policy issues (for example, LSR D may be able to give influenced by policy issues (for example, LSR D may be able to give
better security to protect against rogue leaf attachment) or network better security to protect against rogue leaf attachment) or network
loading concerns (for example, LSR E may already be handling a very loading concerns (for example, LSR E may already be handling a very
large amount of traffic replication for other P2MP services). large amount of traffic replication for other P2MP services).
5. Reoptimization and Modification 5. Reoptimization and Modification
skipping to change at page 8, line 38 skipping to change at page 10, line 20
P2P path from the branch point to the new egress. This is a P2P path from the branch point to the new egress. This is a
relatively simple computation and can be achieved by reverse path relatively simple computation and can be achieved by reverse path
CSPF much as in the manner of some multicast IP routing protocols. CSPF much as in the manner of some multicast IP routing protocols.
However, repeated addition to and removal from a P2MP LSP will almost However, repeated addition to and removal from a P2MP LSP will almost
certainly leave it in a suboptimal state. The tree shape that was certainly leave it in a suboptimal state. The tree shape that was
optimal for the original set of destinations will be distorted by the optimal for the original set of destinations will be distorted by the
changes and will not be optimal for the new set of destinations. changes and will not be optimal for the new set of destinations.
Further, as resource availability changes in the network due to other Further, as resource availability changes in the network due to other
LSPs being released or network resources being brough online, the LSPs being released or network resources being brought online, the
path of the P2MP LSP may become sub-optimal. path of the P2MP LSP may become sub-optimal.
Computing a new optimal path for the P2MP LSP is as simple as Computing a new optimal path for the P2MP LSP is as simple as
computing any optimal P2MP path, but selecting a path that can be computing any optimal P2MP path, but selecting a path that can be
applied within the network as a migration from the existing LSP may applied within the network as a migration from the existing LSP may
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
skipping to change at page 9, line 19 skipping to change at page 10, line 50
processor such as a PCE invoked by the NMS. 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 diconnected leaves. existing tree to reconnect the disconnected leaves.
In fact, immediately after a network failure there may be a very In fact, immediately after a network failure there may be a very
large number of path computations required in order to restore large number of path computations required in order to restore
multiple P2P and P2MP LSPs. The PCEs will be heavily loaded, and it multiple P2P and P2MP LSPs. The PCEs will be heavily loaded, and it
is important that computation requests are restricted to only the is important that computation requests are restricted to only the
'essential'. 'essential'.
In this light it is useful to note that the simple repair In this light it is useful to note that the simple repair
computations described in the first paragraph of this section may be computations described in the first paragraph of this section may be
applied to achieve a first repair of the LSPs, while more applied to achieve a first repair of the LSPs, while more
skipping to change at page 11, line 4 skipping to change at page 12, line 41
PCEs is out of scope, but nervous LSRs may make identical requests PCEs is out of scope, but nervous LSRs may make identical requests
to separate PCEs and compare the responses. 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 Communicaiton 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 [PCEP], but extensions will be necessary to support P2MP computation
requests. 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
recognise 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 [PCEP],
but extensions will be required to describe P2MP capablities. 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
impact on network operation if it can offload processing from the impact on network operation if it can offload processing from the
skipping to change at page 12, line 45 skipping to change at page 14, line 37
2007. 2007.
[RFC5088] Le Roux, J.L., and Vasseur, J.P., Editors, "OSPF [RFC5088] Le Roux, J.L., and Vasseur, J.P., Editors, "OSPF
Protocol Extensions for Path Computation Element (PCE) Protocol Extensions for Path Computation Element (PCE)
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,
J., "Policy-Enabled Path Computation Framework",
RFC 5394, December 2008.
[BRPC] J.P. Vasseur, Editor, "A Backward Recursive PCE-based [BRPC] J.P. Vasseur, Editor, "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest Computation (BRPC) procedure to compute shortest
inter-domain Traffic Engineering Label Switched inter-domain Traffic Engineering Label Switched
Paths", draft-ietf-pce-brpc, work in progress. Paths", draft-ietf-pce-brpc, work in progress.
[GCO] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path [GCO] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path
Computation Element Communication Protocol (PCECP) Computation Element Communication Protocol (PCECP)
Requirements and Protocol Extensions In Support of Requirements and Protocol Extensions In Support of
Global Concurrent Optimization", draft-ietf-pce- Global Concurrent Optimization", draft-ietf-pce-
global-concurrent-optimization, work in progress. global-concurrent-optimization, work in progress.
[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.
[PCE-POLICY] Bryskin, I., Papadimitriou, D., and Berger, L.,
"Policy-Enabled Path Computation Framework",
draft-ietf-pce-policy-enabled-path-comp, work in
progress.
[PCEP] Vasseur, J.P, and Le Roux, J.L., Editors, "Path [PCEP] Vasseur, J.P, and Le Roux, J.L., Editors, "Path
Computation Element (PCE) communication Protocol Computation Element (PCE) communication Protocol
(PCEP) - Version 1", draft-ietf-pce-pcep, work in (PCEP) - Version 1", draft-ietf-pce-pcep, work in
progress. progress.
13. Authors' Addresses 13. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
(R&D Strategy Department) (R&D Strategy Department)
3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
Phone: +81 3 5205 5341 Phone: +81 3 5205 5341
Email: s.yasukawa@hco.ntt.co.jp Email: s.yasukawa@hco.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. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF Trust takes no position regarding the validity or scope of
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in any IETF Document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights.
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of Intellectual Property disclosures made to the IETF
assurances of licenses to be made available, or the result of an Secretariat and any assurances of licenses to be made available, or
attempt made to obtain a general license or permission for the use of the result of an attempt made to obtain a general license or
such proprietary rights by implementers or users of this permission for the use of such proprietary rights by implementers or
specification can be obtained from the IETF on-line IPR repository at users of this specification can be obtained from the IETF on-line IPR
http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- any standard or specification contained in an IETF Document. Please
ipr@ietf.org. 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 15. Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to the rights, licenses and restrictions This document is subject to BCP 78 and the IETF Trust's Legal
contained in BCP 78, and except as set forth therein, the authors Provisions Relating to IETF Documents
retain all their rights. (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
This document and the information contained herein are provided on an All IETF Documents and the information contained therein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
 End of changes. 30 change blocks. 
50 lines changed or deleted 102 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/